在众多的企业信息化建设项目中，有好几单涉及到了业务流程的重整，每做一次类似的项目，都感觉自己死过一次，今天把它翻出来，也算是揭了自己的伤疤，"业务流程重整"，听起来很简单，实际操作过程中确非常艰难，为什么？
业务流程重整，于公，则意味着部门的重新规划，部门职能的重新划分，岗位职能的重新划分；于私，则意味着很多用户，甚至包括各级领导的责权利的重新分配；于公的立场上，相对而言好处理，这些仅仅只是工作量的问题；而于私的立场上，每个员工都会有一定的私心，都希望责任小、权力大、获利多，当业务模型的重整伤及个人的核心利益时，大部分选择的并不是默默承受，而会以各种各样的借口进行阻挠，而替罪的羔羊，绝大部分会指向乙方的项目团队，核心的这个人就是倒霉蛋-我了，伤不起啊。
业务流程重组，其中大部分是缺乏考虑，从主要负责人（老板）甲方乙方的项目经理，行业专家，他们的工作界面本身对企业的了解太少，调整后的工作量评估目前仍以头（意外管理特点，大多数决定从拍拍他的头，美国曰：经验），因此，业务流程改革基本在摸着石头过河的状态，和国家的手段调整将很多，周期会很长。在我们的软件的变化也很多；而乙方的项目经理有进步和成本的考虑，遇到这种状况，基本将请示领导，是否我们能陪客户这样玩。
随着开发实施周期长，除了发展成本的考虑外，内在的风险也不容忽视：首先，团队成员的工作热情不可能一生，说："一鼓作气，再而失败，三和喷泉；因此如何搞好建设项目管理团队，但其工作效率的团队成员保持在一定程度上，也是一个难点问题；其次，根据经验，稳定的团队成员一般在一年左右，满足员工离职，许多公司的人员补充进展不足，甚至到快，成员的磨合还需要一段时间，没有人做的磨合期。如果遇到大规模的人事变动，项目经理经常哭死。
随着开发实施周期长，客户的人员变化也将导致增加的工作量，随着人事变动的不同影响工程项目本身的危害也越来越大，最大的，当然，是赞助商的流动重组，人如果变化的基本手段，前做所有的工作基本无效。
