一、发挥用户执行力的优势

　　在政府单位，虽然部门与部门之间会有扯皮的现象。但是同一个部门上下级之间，执行力却是很高的。这比一般企业要高的多。笔者在政府单位执行了多个信息化项目之后，这是给我的一个很深刻的印象。一般领导上午交待的命令，下面的员工会马上落实。

　　在OA办公自动化项目推动中，这种执行力是非常必要的。作为项目实施团队，应该巧妙的借助这种力量，来推动项目的进度。如笔者在实施项目时，一般都会让单位的一把手来作为项目的负责人。虽然一把手经常会没有时间。但是就是挂着个名，也要把他挂上。每次一个决议，或者一个通知，只要领导签了字，其效力就好像是圣旨一样，能够很快的被落实下去。

　　既然在政府单位中有这个执行力的优势，那么我们就需要尽量的发挥这个优势。在不得已的时候有二把手来担任项目负责人时，最好也能够从一把手那边获取尚方宝剑，以增加决议的效率，将执行力贯彻到实处。

　　二、加大项目的考核力度

　　国有国法，家有家规。在信息化项目中，一套行之有效的考核制度是少不了的。政府单位一般都是财大气粗的。在实际项目中，往往可以为OA信息化办公项目申请到一笔可观的项目资金。俗话说，重赏之下必有勇夫。根据笔者的经验，在政府单位中，由于有资金作为保障，为此项目的考核制度比较好操作。

　　如在项目推进过程中，可以充分贯彻多奖少罚的政策。一般奖励与惩罚的比例在8：2之间。如罚款200元，那么奖励就要在800元。项目经理可以在项目的各个环节中设置奖金。如项目会议全勤奖、需求调研突出员工奖、业务流程梳理突出贡献奖、项目团队奖、项目经理奖等等。虽然说奖赏并不是目的，但是通过物质的奖励，确实可以在很大程度上激发用户的积极性，保障项目的正常实施。

　　不过在制定考核制度时，笔者还是建立要多奖少罚。有条件的企业，最好能够做到多奖不罚。毕竟信息化项目带来的额外工作，需要占用员工大量的时间，有些甚至是加班加点完成的。另外需要注意的是，在条件允许的情况下，最好考核的体现能够在当天即生效。如某个关键环节的工作完成了，在完成当天就根据考核制度给与相关的奖励。这可以提高kao核制度的效果。

　　三、不可忽视关键用户的力量

　　政府企业单位是一个铁饭碗。通常情况下，用户很少有流动。这与一般的企业单位员工高流动率是一个明显的对比。员工的高度稳定性，对于信息化项目推进来说(包括OA办公自动化项目)，是一笔很宝贵的财富。

　　既然在政府单位中有这么一个优势，那么项目团队当然不能够忽视。笔者认为，在项目推进过程中，项目经理应该在最大程度内发挥关键用户的力量。这是什么意思呢?如实施顾问在需求调研、系统培训等各个环节中，只需要跟企业的中高层管理人员打交道即可。从项目团队的组成上来看，就是项目组管理人员以及关键用户即可。而终端用户的培训，则可以由关键用户来完成。

　　虽然在一般企业单位中，也可以贯彻这种实施方法。但是效果并不是很理想。由于员工流动比较大的关系，一个关键用户还没有培训完成，这个用户就可能已经走了。或者说，项目刚上线，关键用户就离职了，等等。所有很多情况下，实施顾问还需要对终端用户去培训。但是由于实施顾问的时间是固定的，所以实施顾问忙于培训，而很少有时间在流程优化等方面下功夫了。而在政府事业单位中，这种情况就很少发生。关键用户一般都不会发生变化。为此实施顾问就可以抽身出来，做流程优化等附加值更高的工作。

　　四、部门之间的协调工作需要重视

　　政府部门的垂直指挥线效率是很高的。一般执行领导的决定都不会guo夜。但是跨部门之间的作业，扯皮的现象就会比较严重。在实施项目过程中，笔者对于上级给下级的任务并不是很担心，担心的就是部门之间的协作问题。

　　如经过业务分析，可能认为某个业务另外一个部门做更加合适。遇到这种情况时，实施顾问需要特别的谨慎。虽然从总体上来说，这么调整可以提高工作效率。但是从部门来说，无疑是增加了一个部门的工作量、而减少了另外一个部门的工作量。遇到这种情况时，除非有特别的必要，否则的话，最好不要这么操作。因为理想虽然是好的，但是在具体操作时，会遇到很大的难度。

　　如果经过领导研究讨论之后，确实需要更改的，那么最好能够协同这两个部门的共同上级来推行新的流程与操作方式。这可以有效的避免两个部门之间扯皮的现象，从而保障新的流程能够得到具体的落实。这与普通企业的项目实施不同。一般企业比较看重整体的效果。虽然部门之间也会出现互相推托的现象，但是远远没有政府单位这么严重。

　　五、流程限制要比较固化

　　在政府部门中，办事的流程一般固定的都比较严格。如审批某张单据，需要经过多少流程，就必须要经过多少步骤。少一步都不可以。这对于实施OA办公自动化系统时，即是一个优势，也是一个挑掌。优势是流程固定了，在系统中只需要进行相关的设置即可。由于少了用户机动的环节，中间犯错误的机会就少。此时OA办公自动化系统的效果就比较容易体现。

　　对OA系统的挑战就是系统要有比较灵活的实现机制。 用户提出来要怎么操作，就要怎么操作。根据笔者的经验，一般它们都不会接纳变通的处理方法。如果系统中无法按用户现有的需求实现，就需要进行大量的二次开发。而过多的二次开发，对于系统后续的升级也会遇到比较大的困扰。为此笔者建议，从系统选型时，就最好选择那些平台型的产品。会后续项目的实施奠定一个良好的基础。