IT变革管理和项目管理方法论

首先，格雷斯发起的是一个管理信息化项目，是一个他本人从来没有从事过的项目，项目的独特性决定了实现项目目标的风险性；同时，这并不是一个简单的项目，而是一个涉及到组织运作体系转变以及员工行为模式转变的变革项目，这样的变革通常会引起组织内部的剧烈震荡。

要想解决格雷斯目前存在的问题，他需要得到变革管理和项目管理方法论的双重指导。

1、变革项目相关问题的管理

项目开始之前，公司现有的基于手工的财务系统还在正常的运行之中，虽然制作年报需要很长的时间，大不了多花一些时间，还是可以应付老板的检查要求。现在要上一套新的财务系统，这并不是一个简单的软件开发与实施的问题，而是涉及到公司改变部门现有运作流程和工作方法的文化变革问题。从历史的经验来看，大量的组织变革项目最终都以失败告终的，因此要想取得项目的成功，就必须遵循变革项目运行的规律，采用适当的变革管理方法论来指导实践。变革项目的成功包括组织转变与人员转变两个方面（如图1所示），并且需要确保这两个方面的转变达到高度的统一。

组织转变可能会涉及到公司战略、组织架构、工作流程、部门和员工的绩效考核方式、项目管理模式等方面的内容，要采用新的系统代替手工系统，需要企业中层和高层对这些系统进行怎样的改变取得高度统一的共识。从案例中我们发现，由于业务的发展，数据在不断地增加，员工不知道这些数据是从哪里来，也不知道这些数据之间是什么关系，其它业务部门的新业务产生了哪些新的数据和数据类型？这些数据问题很可能与公司的战略、组织结构以及工作流程存在密切关系，如果新系统没有反映这种情况，必然造成系统的混乱。

与组织转变比较起来，人员转变更加复杂也更加困难。财务总监的初衷是要解放生产力、提高工作效率，但是这个想法是否能够得到大家的认同是值得怀疑的，在整个变革过程中，员工将表现出怀疑、保守、迷惑、受挫、责备、否认、混乱、焦虑、抵制等各种对变革不利的情绪，尤其是当他们遇到挫折、对变革的前景产生怀疑的时候，他们甚至会起来反对或者退出；从这个项目的执行过程可以看出，两本帐的问题是项目面对的核心问题，财务部门的员工因为害怕出现老板检查而无法应对的状况，不敢放弃手工系统，他们对新系统没有信心（技术方面），对变革的方法以及变革的过程充满了困惑；关键时刻缺乏解决和研究问题的积极性，有问题就可能直接找到财务总监。也许正是这些情绪妨碍了项目取得进展，而正确的做法应该是加强对这些情绪的管理。

另外，变革过程中间取得的任何成果都只是短暂的，变革的过程需要取得这些短期成效，比如系统调试通过，两套帐能够暂时对起来、员工经过培训和指导可以独立操作系统了；这种时候员工往往会产生放松情绪，比如没有仔细深究下去就放心地让实施顾问离开，这种时候要求变革团队能够认清形势，坚持并巩固变革成果。在变革成果没有得到巩固之前，新的工作方法以及基于这种方法的新企业文化其实并没有形成。

2、项目范围和质量管理问题

信息化项目要想取得成功，必须严格遵守项目范围和质量管理的流程（如图2），清楚地界定项目的范围以及该项目要达到的最终目标，其中包括项目应该包括哪几个阶段、每个阶段应该交付什么成果、这些交付成果之间的关系、每项成交付果的技术和质量标准、完成这些交付成果的绩效要求、以及项目要达成的最终愿景（业务目标）等，项目领导者应该将这些目标准确、及时、完整的传达给整个项目的全部干系人，包括公司老板以及一般员工，使他们对项目是什么以及为什么的问题产生非常明确和直观的认识。同时，随着项目的进展，严格按照项目的质量计划开展质量保证和质量控制活动，并针对项目的各种中间交付成果进行验收核实，对项目过程中发生的范围变更进行有效的控制和管理。

从案例材料可以看出，员工经过培训之后，他们似乎可以对系统进行操作了，但他们对系统并没有很深入的理解，不知道系统数据是怎么来的，数据之间是什么关系。如果没有对系统的完整理解，就是对系统的知其然而不其所以然，这种情况下，员工就不可能独立主动地思考和解决系统中发生的各种问题，一旦发生误操作，往往会造成系统数据的一致性、准确性和完整性问题，在以数据为基础的信息系统中，数据错误有时可能导致整个系统的失真。此外，大家觉得咨询公司的项目实施文档太复杂，看不懂；使用的过程中，发现手工帐和系统帐对不起来，他们不知道是操作不当，还是方案有问题；即使是作为财务总监的格雷斯，虽然他对业务问题了如指掌，但是业务到了系统中以后是如何运作的，他心里也没有底。员工经过培训和指导可以独立操作系统，这并不表明他们已经可以驾御所有的系统问题，这个时候让实施顾问离开显然是不合适的。

这些问题表明，项目领导层在项目范围和质量管理方面可能存在以下三个方面的问题：1、项目在员工培训的内容与要求、项目技术文档、项目实施文档以及其他实施成果等阶段性或最终交付成果方面没有作出清楚的定义与沟通；2、没有严格履行项目的质量计划与控制措施，3、没有进行完整的项目阶段控制点的范围验收核实和范围变更控制。由于这些问题没有及时发现并得到适当解决，项目绩效的负偏差不断扩大，系统累计的错误越来越多，以至于根本查不出错误的源头所在，最终整个系统的数据自然就乱了。

3、项目风险管理问题

从案例中可以发现，执行过程中发生了不少令格雷斯始料不及的事情，比如，咨询公司提交方案和系统上线已经12个月后，公司财务部门还是两条腿走路；有些员工忍受不了白天手工做帐、晚上还要将数据录入系统这样的高强度工作而选择了离职；在没有手工帐可以核对的情况下，系统数据间的勾稽关系出现了混乱，不知道这些数据是否正确，用户对系统越来越没底。如果当初知道会发生这些意外的话，应该可以通过适当的方式解决这些问题，这就是一个风险管理的问题（图3、风险管理的过程）。

首先，项目组需要建立风险管理的意识，制定风险管理职责和相应的管理计划，风险管理意识的有无往往对这种变革项目产生很大的影响；然后按照计划识别项目过程中可能发生的风险，通常项目工作分解结构是识别项目风险的有效工具，通过该工具可以识别提交各种交付成果过程中可能发生的风险或者可能出现的困难，比如本案例中，当格雷斯为了吸取教训决定破釜沉舟，不给员工留任何后路，下令所有的员工必须丢掉手工帐，迫使他们去彻底理解系统的时候，这样做最终会发生怎样的风险呢？

识别风险后并不是马上就制定风险应对计划，而是首先对这些识别出来的风险进行分析和排序，识别出需要优先考虑的风险，至少需要重点考虑排在前十位的风险事项，成熟的项目管理团队针对特定的项目通常都会建立起经过排序的风险检查表，比如说许多公司将领导与员工参与度作为管理信息化项目最大的风险，这实际上也是造成所有变革类项目失败的最大风险；制定风险应对计划并执行是项目成功的关键。对该项目而言，风险应对措施至少应该包括选择恰当的手工帐和自动帐并行的时间、建立合理的数据稽核机制、咨询顾问离开时间或离开方式选择、问题识别和解决机制以防止问题扩大或重复发生、建立领导和员工的参与计划并确保用户对系统的正确掌握和理解等。最后要对应对措施的有效性以及风险发生的变化进行全过程监控。

总之，困扰格雷斯的是一个与项目管理和变革管理相关的典型问题，解决这些问题需要有具体可操作的实施方法论的指导，其中范围管理、质量管理与风险管理是与项目管理有关的三个方面，这并不是说项目管理的其它方面（如进度管理）不重要，而只是关注的焦点不同罢了。同时要注意这是一个复杂的变革项目，需要发现变革项目中一些规律性的问题，采用正确的方法加以解决。如果要建议几点具体的行动步骤，应该可以包括如下几点：1、重新进行项目干系人分析，并制定相应的管理计划；2、制定问题的识别与解决机制，防止类似的问题扩大化或者重复发生；3、长时间外包某些技术性很强的实施工作以转移风险；4、对项目的交付成果加强质量控制和范围验收核实工作。

来源：AMT