解读企业信息化之流程重组

　　在众多的企业信息化建设项目中，有好几单涉及到了业务流程的重整，每做一次类似的项目，都感觉自己死过一次，今天把它翻出来，也算是揭了自己的伤疤，“业务流程重整”，听起来很简单，实际操作过程中确非常艰难，为什么？

 

　　1、业务流程重整，于公，则意味着部门的重新规划，部门职能的重新划分，岗位职能的重新划分；于私，则意味着很多用户，甚至包括各级领导的责权利的重新分配；于公的立场上，相对而言好处理，这些仅仅只是工作量的问题；而于私的立场上，每个员工都会有一定的私心，都希望责任小、权力大、获利多，当业务模型的重整伤及个人的核心利益时，大部分选择的并不是默默承受，而会以各种各样的借口进行阻挠，而替罪的羔羊，绝大部分会指向乙方的项目团队，核心的这个人就是倒霉蛋-我了，伤不起啊；

 

　　2、业务流程的重整，大部分是缺乏考量的，从甲方的主要负责人（老板本人）到乙方的项目经理、行业专家，本身对企业各岗位的工作界面了解太少，对调整后的工作量评估仍处于拍脑袋的状态（偶们的管理特色，大部分决策来自于拍脑袋，美其名曰：经验），因此，业务流程重整基本处于摸着石头过河的状态，而这种状态意味着调整会很多，周期会很长。从而造成我们软件的变更同样会很多；而乙方的项目经理有进度和成本考量，遇到这种状态，基本就要请示领导，是不是可以陪客户这么玩；

 

　　3、随着开发/实施周期长，除了进度成本考量外，团队内部的风险也不容忽视：其一，团队成员的工作热情不可能从一而终，俗语说：一鼓作气，再而衰，三而竭；因此项目经理如何搞好团队建设，然团队成员的工作效率保持在一定程度，同样也是一个艰难的课题；其二，从经验上看，团队成员的稳定性一般在1年左右，而遇到员工离职，很多公司的人员补充的进度不足，即使是进人快，成员的磨合也需要一段时间，缺人期怎么办，磨合期怎么办。遇到大规模的人员变动，项目经理经常哭死；

 

　　4、随着开发/实施周期长，客户方的人员变更同样也会导致工作量的增加，随着所变更的人员对项目影响力的不同，对项目本身的危害也越来越大，最大的当然是流程重组的发起人了，如果这个人变更，那么基本意味着前面所做的所有工作基本无效。

 

　　由此我们可以看出，企业的业务流程重组项目，对于乙方而言，风险巨大，从进度、成本、质量、团队建设、干系人管理等等方面都有巨大的冲击，而这种冲击，很多时候都有可能导致项目的终止，甲乙方项目经理在处理类似的项目时，经常是如履薄冰，小心应付，那么该怎么应付类似的项目呢？（这里只敢说应付，不敢说应对）：

 

　　1、甲乙方项目经理需成为朋友关系，之所以要私交，是因为很多时候在公共场合，很多话题是无法深入的，尤其是涉及部分领导隐私底线的话题，只有在和对方项目经理真正成为朋友的情况下，在某些轻松写意的环境下，才能开诚布公的讨论；

 

　　2、加强沟通，从客户方的流程重组发起人到本方的主管领导，应当密切沟通；

 

　　a、从流程定义开始，双方在讨论流程定义的有效性的同时，同样也要讨论流程定义（包括涉及岗位的工作界面）的可行性（甚至要将部分领导岗位的调整后导致的个人利益的丧失而导致的反对声音都需要作为可行性分析的栏目），对于由于流程重组会带来的危害要从重考量，并制定相应的风险应对计划；风险识别和应对计划同样需要与本方的领导沟通，因为应对计划中可能会导致项目的成本、进度的剧增，因此需要获得领导的认同；

 

　　b、在实施过程中，遇到任何问题，都需要团队成员，包括甲方项目经理密切沟通，争取在事态没有衍化严重之前就处理掉；

 

　　3、细化行动计划，多做备选方案，将可能的风险尽可能的考虑进去；

 

　　4、多做项目日志，日志尽可能详尽，这些将会是下一步行动计划的参照，同时也是给各级领导（甲乙方）汇报的基础，同时是他们做出决策的依据；

 

　　5、尽可能多做小碎步调整，哪怕出现一些细微的变化，马上要予以重视，由于涉及面广，因此要多做细微的调整，逐步逐步的实施；

 

　　6、为了给团队和客户增强信息，我们在排定优先级时，尽可能将容易实现并见效快的功能放在前面；

 

　　7、敏捷模式可能比常规瀑布型（或多次迭代型）更有效，因为他出版本快，变更的风险小；

 

（wy）