刚刚参加完为市场部开发的“营销费用管理平台”的验收会，在会上，市场部的领导对该项目的实施效果大加赞赏。项目顺利通过验收，可谓“完胜”，Sam的心情大好。
经过3个月的系统试运行，市场部数额庞大的营销费用变得清晰了——每一笔费用都可以准确的追溯到预算、计划、执行、报销各步骤的具体情况，同时还可以看到该笔费用在执行过程中与各方签订的合同情况；并且系统还记录了每个步骤的修改、变更以及相关人员的审核审批记录。一旦审核人员发现疑点，可以轻松的追查到所有相关的责任人，以前让人头痛的费用管理变得不那么可怕了，相反可以为管理者提供清晰可靠的决策依据，帮助管理者随时掌握营销费用的使用情况，再结合销售部门的销售数据，可以准确的了解到投入的营销费用对销售业绩作出的贡献。
翻开手中的验收报告，Sam的思绪不由得飘回了半年前刚接到项目的时候，那时的心情可远没有现在的轻松呀。
图1. 营销费用管理平台的主要流程
2.缘起
刚刚接下了为市场部开发一套管理系统的任务。
回到办公室，Sam翻开了以前的项目档案，发现3年前信息部门曾经开发过一个类似的信息系统给市场部，但是由于正好赶上公司的业务方向调整和组织结构变动，系统刚刚上线就面临下马的窘况。究其原因，很大程度上是因为软件的设计不够灵活，流程都是固化在软件里的，根本无法适应业务的调整，而重新修改代码的代价又太高，工期也无法保证，所以只好放弃。
放下手中的项目档案，Sam感到压力重重。市场部是公司主要的“消费大户”，每年在市场营销上的投入高达几千万，却是当下唯一一个没有成功实施信息系统的部门，一直依靠人工的方式在管理，没有谁能说得清这么多钱到底花在了哪里，是不是获得了预期的效果。
以目前市场部费用管理的情况来看，其业务流程混乱，计划变更频繁，合同管理松散，费用报销严重滞后，工作效率低下；总部对各分公司的费用管理和控制基本处于半失控的状态，没有什么手段和依据来限制分公司对费用的使用；管理者对营销费用的花费和收效知之不详，在制定费用预算时往往只能“跟着感觉走”，没有确实可信的数据可供参。
Sam犯了难，这个项目到底该怎么做呢？
3.谋定
考虑再三，Sam觉得还是应该仔细分析一下这个项目的整体情况，然后再决定自己该采取怎样的措施来进行，尽量减低项目风险，避免失败。
图2. 项目推进过程中需要注意的5点
市场部作为公司营销策略的制定者和执行者，其营销行为的成功与否，对整个供应链的销售、生产、采购等环节都有着直接或间接的影响，其重要性毋庸置疑。市场部本身的业务繁多，包括营销策略的制定、市场公关、创意企化、费用管理等等，从信息化的难易程度、紧迫性和重要性来看，对数额巨大的营销费用的监管无疑是重中之重。所以，项目的切入点就选择费用管理这块业务。
根据目前信息化的发展趋势和业务需要，Sam将项目明确的定位为“市场营销费用管理平台”，把建立起一个包括“预算管理—＞计划制定—＞计划变更管理—＞合同管理—＞费用报销”在内的营销费用全周期管理的闭环回路为目标，开发出一套灵活完善的营销费用管理平台。
这个项目的难点主要在于对业务的理解和把握上，既要考虑到现有的业务流程，也要兼顾到对流程的优化，既要符合基层用户的习惯，也要满足高层领导的汇总和分析的需要。
因此，在技术上不宜采用没有经过实践检验的新技术和新工具，而选择采用上一个版本的技术架构，并重用其它系统中已经成熟的权限管理模块。
鉴于市场部现有业务流程的论乱，在项目初期，恐怕没有人能够提出一份全面细致的业务需求。为了与业务人员充分沟通，也为了尽量降低项目风险，Sam决定采用原型法来配合需求分析阶段的工作。
因为市场部，尤其是分公司的市场人员对信息系统的认识和接受能力普遍比较差，通过原型的开发，可以将空泛的业务流程具体化、形象化，更加直观的展现在用户面前，让用户可以亲身感受到系统实施之后将会给自己的工作所带来的改变，逐步培养他们使用系统的习惯，以及通过系统来解决实际问题的能力。
由于在需求分析阶段使用的系统原型，采用了上一个版本成熟的技术架构及模块复用，故而可以将其一直迭代到代码开发阶段，直至系统交付，即“迭代原型法”的开发模式。
如上所述，采用“迭代原型法”有一个很明显的优势，可以尽量在项目早期发现问题。降低在项目后期发生需求变更的风险。
不过，该方法也存在一个缺点，很容易在开发过程中陷入对细节的无止境的纠缠当中，从而导致需求蔓延和需求“镀金”。在这一点上，项目经理一定要注意对项目的管理，定期进行检查点回顾，时刻注意检查项目进度，一旦发现“蔓延”的趋势必须及时修正，保证主要功能和流程的开发进度，将风险消灭在萌芽状态。
为了保证系统最终能够成功上线，必须注意项目实施过程中所采取的方法和步骤。
费用管理的业务涉及到总部市场和全国所有的分公司，系统的最终用户遍布全国，而且人员众多，水平参差不齐，因此想要在所有分公司一次性的同时上线，几乎是不可能的。
比较合理的方式是，首先在总部市场和北京分公司做试点，因为在同一个办公地点，并且员工计算机水平也比较高，技术人员培训和调试起来都比较方便。等到系统稳定运行了一个月之后，再向全国推广，因为有了总部和北京分公司的成功经验，可以达到一点带面的示范效果，会大大降低实施风险。
4.“诡计”
以上都是在项目进行过程中必须要考虑和解决的问题，都是光明正大的措施和手段。但是，除了要做到以上这几点之外，作为一名项目经理，在管理这样一个复杂的，容易反复的，而且曾经有过失败经历的项目时，Sam还必须要在适当的时机耍一些无伤大雅的“阴谋诡计”，来保证项目的顺利进行。简单点说，就是：
项目初期，用户刚刚开始接触原型，界面风格、操作模式、按钮设置等是用户最直观的感受，尤其是对于以前没有使用过信息系统的市场人员来说，这些操作层面的简便性、易用性将直接影响到他们对系统的感受。
所以，为了让用户能够比较容易的接受，项目经理要尽可能的按照用户的操作习惯来修改，在这一时期，只要能让他们习惯于使用系统，项目经理都可以最大程度的妥协。
到了项目中期，系统的界面风格和基本流程已经确定，在这一阶段，要“怀柔”与“高压”并用。
怀柔——对于一个双方有争议的功能需求，项目经理可以保留自己的意见，按照用户的想法来做，但是一定要事先强调自己的看法，并指出用户的想法可能存在的风险。等到功能实现之后，用户会发现，这样做果然是会出问题的。在这个时候，项目经理在用户心中的专业权威就树立起来了，以后再出现争议的时候，用户就会充分信任并尊重项目经理的意见。
高压——当项目经理在用户心中成为了一个权威之后，对于一些开发成本很高而使用价值不大的功能需求，项目经理就可以利用这一点来向用户“高压”一下，取消或者放到项目二期、三期的时候再作。
当然，“怀柔”和“高压”都不能滥用，对于开发成本很高的功能使用怀柔政策，很容易造成资源浪费和进度落后；而过多的使用高压政策也是十分不明智的，就像“狼来了”一样，同一招用多了也就不灵了。
在后期的实施过程中，项目经理要学会威逼利诱。
对先期的试点人员威逼——对于第一个吃螃蟹的人，困难是可想而知的，为了保证不会半途而废，除了对其加强培训之外，取得高层领导的支持，通过强制手段保证系统真正用起来并且能够用下去，是十分必要的。
对后期跟进的人员利诱——前期的成功经验已经摆在那里，项目经理所作的就是将使用系统治后带来的工作效率的提高，工作量的降低，流程透明度的增加充分的介绍给未来的用户，使他们对系统的应用充满信心。
一个项目不可能将所有的业务需求一次完成，通常的做法是将一个项目分解成两到三个阶段来完成，在完成初期最基础的功能之后，还要继续进行项目的二期、三期。
如果说，项目的一期阶段完成了信息系统的从无到有，项目的二期、三期就是对业务的整合和流程的完善。在一期阶段，业务部门最为需求的提供者，对项目的方向起主导作用，最后的交付产品也大多是对现有流程的忠实再现和信息化。如果在这时信息部门想对业务流程提出改进建议，阻力会非常大。然而在二期、三期阶段，由于业务部门已经习惯了信息系统的使用，已经离不开它了，这时如果信息部门从企业信息化的角度出发，对整个业务流程提出自己的改进建议和方案，业务部门一定会给与充分的重视，推进过程也会比较顺利。
所以说，项目经理学会耍点手腕，必要的时候来点阴谋诡计也是十分必要的。
总之，项目经理要充分认清信息系统建设周期中各个阶段的特点，以保证自己在适当的时间做出适当的决定，在不同的阶段采取不同的措施，保证项目始终立于不败之地。
《中国计算机用户》2007年30期 发表
收藏
分享
有用
无用