文 / 冯 燕
近年来，中国的汽车市场迎来了爆发式的增长，从2010年开始，中国一跃成为世界规模第一的汽车生产国，成为全球最具活力的汽车市场之一，全国各省市先后出台了促进汽车产业发展的规划，各大汽车厂商也纷纷跑马圈地，产能成倍地增长。这意味着汽车厂商在迎来千载难逢的市场机遇的同时，也必将面临着激烈的市场竞争。
本文将通过对北京汽车股份有限公司（以下简称“北京汽车”）零部件采购现状的分析，运用项目管理的方法来规划和实施采购信息化系统建设，同时和大家分享项目实施过程中在范围管理、沟通管理和质量管理方面的一些经验。
一、北京汽车零部件采购现状
2010年9月，北京汽车正式成立，虽然有不少有经验、背景的人才加入，但是对北汽自主品牌来说，从研发、采购到生产的全过程还是像个蹒跚学步的小孩，一点点在摸索中成长。就零部件采购来说，其存在的主要问题是：整车厂以自身利益为中心, 不顾零部件企业的实际情况和利益, 用零部件企业的大量库存来换取自身的零库存, 并把价格战的压力推向零部件企业, 导致汽车行业整体供应链竞争力减弱；信息沟通的手段和工具落后，主要还是采用传统方式( 电话、传真、信件、E - mail）与供应商进行信息交流, 使信息不能及时传达, 导致采购效率低下, 企业对市场的反应速度迟滞, 造成生产与市场的脱节, 而供应商为了适应由于信息不畅造成的需求变化, 只得加大库存量, 导致流动资金占用过多；零部件定点和开发认可进度风险管控困难，成本对标与统计完全靠手工台账处理，人员流失导致数据信息流失，这种状态已经严重制约了采购业务的开展，尤其是在整车行业竞争如此激烈的大环境下，要求规范采购业务流程、提高工作效率、与供应商协同合作、共同发展的呼声越来越高，采购信息化管理也就势在必行。
二、北京汽车采购信息化系统分阶段实施计划
2011年下半年，在北京汽车各方领导的大力支持下，采购中心协同信息技术部开始规划零部件采购信息化系统，即SRM（Supplier Relationship Management，供应商关系管理）系统，这个系统是一种不断优化供应商选择，缩短采购周期，贯彻集中采购，并实现与供应商建立和维持长久、紧密伙伴关系的管理思想和软件技术解决方案。笔者作为该项目的项目经理有幸参与了整个规划和实施过程。根据采购实际业务开展的紧迫程度，将系统规划实施分成三个阶段进行，具体安排见下表。
三、北京汽车采购信息化系实施过程的管理模式
1.项目组织类型选择
由于采购SRM系统开发与实施涉及多个部门，如生产部门、零部件采购部门、供应商管理部门、财务部门、信息技术部、软件开发商等，根据项目需要每个部门需要安排一名关键用户，对参与项目的关键用户的要求是对部门业务熟悉且表达能力强，同时需求调研阶段和测试阶段需要全程参与，其余时间还是要参与到部门事务中去，所以项目的组织类型选择矩阵式管理。矩阵式管理较其他组织结构相比，至少有三大优点：一是提高工作效率，由于采用了灵活的组织结构，在资源上进行了共享，当项目出现的时候，可以马上调集与之相匹配的资源，组建跨功能部门的项目团队，提高了团队执行力，减少了沟通环节，加快了信息的共享，提高了反应速度，矩阵式管理使各个部门的管理聚焦到公司的业务发展上，更加有利于公司的战略实施；二是资源得到共享，在矩阵式的组织结构中，各个部门的资源得到了共享，使资源得到了充分的利用，减少了以前出现的“忙的忙死，闲的闲死”的情况，根据研究表明，采用矩阵式的管理模式比采用传统组织结构的管理模式要减少20%的资源；三是更加有利于人才的发展，采用矩阵式管理模式并不会影响到人才的晋升通道，而且采用跨部门的协作模式，有利于提高员工的综合能力的培养。矩阵式管理更加有利于人员的团队合作精神，避免了以前的部门本位主义。
2.项目的范围管理
项目范围是指为了达到项目目标，项目所规定要完成的工作及过程。利益相关方必须在产品方面达成共识，也要在如何完成这一项目达成一致的意见。项目范围管理是指对项目包括什么与不包括什么定义与控制的过程。这个过程用于确保项目团队和利益相关者对作为项目结果的项目产品以及生产这些产品所用到的过程有一个共同的理解，简单地说，项目范围管理就是为项目划定一个界限，划定哪些方面是属于项目应该做的，哪些是不应该包括在项目之内的，定义项目的工作边界，确定项目的目标和主要的项目可交付成果。
针对SRM项目实施来说，需求调研阶段生成的需求文档就是对系统开发范围的界定，这个也是整个项目实施中的重点和难点，一般会占整个开发周期三分之一的时间。“磨刀不误砍柴工”，前期需求越明确，后续开发返工才会越少，进度才越有保障。否则有可能开发出来的产品和业务部门想要的内容南辕北辙，项目只能以延时或是失败告终。需求调研阶段，首先根据立项报告中的功能模块定义，规定好每个模块的调研时间，也就是确认需求调研计划和参与人员，当然时间是很紧凑的了。然后，我们组织关键用户和软件公司开发顾问一起进行头脑风暴，每个人根据自己业务的实际需要，提出需要哪些功能，业务流程应该是什么样的，页面该如何展示，审批流程应该是什么样的等等，开发顾问会详细记录这个需求内容，同时对讨论未决事项确定责任人，需要找相关领导确认明确需求，并生成会议纪要下发再次征询意见。讨论会后，需要关键用户将模块的业务流程进行梳理，生成模块的流程图。每个模块大概都需要三轮需求讨论才能定第一稿需求文档。由于关键用户一般都是业务骨干，但不是部门经理，没有决定权。第一稿确定后，需要集中各部门领导进行宣讲和征询意见，根据领导的意见再次修改后审批完成才能最终定稿。需求文档必须明确标记每个模块需要哪些页面、页面功能和字段有哪些、页面功能之间的关系、权限的设定、审批流等详细信息。同时为了以防万一，担心开发人员理解有误，需要软件开发商根据需求文档提供系统界面原型，作为需求调研阶段另一个交付物，界面原型同样需要关键用户和相关领导审批通过才能生效，这也是需求调研阶段的双保险，根据以往的经验，这样做后续开发过程中的分歧会比较少。
当然，再完善的需求也很难避免由于各种原因而出现需求变更或新增需求（范围变更）的问题。针对需求变化，首先需要提出部门提交变更申请单，项目组内部进行综合评估，首先判断这个需求是否真的有必要体现，如果需要，就要看需求变更对其他功能的影响，影响有多大；如果该变更不开发将影响其他业务流程，那一定要在本期上线前开发完成，否则系统无法使用。这种情况就需要调整开发计划，形成新的项目计划基线。如果该变更是单独功能，不影响其他功能的使用，看开发进度是否允许，时间充裕可以上线前开发；否则协商后可以系统上线后开发，但规定好具体完成时间。如果经项目组评估后觉得功能根本没必要体现，需求变更不予实施。变更申请单需要层级审批后，由开发经理评估费用和时间进度，按计划执行。变更申请单由信息技术部存档，作为项目收尾时结算的依据。
3.项目的沟通模式
项目沟通主要是项目团队与其他组织、项目团队成员之间的信息传递和理解。项目沟通贯穿于项目的整个生命周期，在确认系统需求阶段需要沟通；在项目计划阶段制定各类计划时需要沟通；系统开发和实施阶段需要沟通；在系统测试阶段需要沟通，以及上线运维阶段都需要沟通；可见沟通在整个项目实施过程中的重要地位，有效的沟通对项目的成功具有重要的意义。如果沟通不畅，相关人员不能理解项目经理的意图，无法做到上传下达，最终会导致项目混乱甚至失败。另一方面，项目团队内部及其与外部环境之间的信息沟通可以使项目组及时准确地获取项目的进展情况，对项目进行合理的组织和控制，因为只有以准确、完整、及时的信息为依据，项目组才能做出正确的决策和合理的计划。
针对SRM项目来说，采用的是轮式沟通渠道模式，就是项目经理作为信息中心分别与项目中不同类型角色发生联系，集中汇集和传递来自各个部门的信息，但是不同角色之间彼此之间不发生联系，只分别掌握本部门的情况，接受主管人员的指令并反馈信息。沟通的方式主要以书面沟通的形式，会议上沟通讨论的以会议纪要为准，个别沟通的内容以邮件为准，或是根据项目要求提交各类报告，这些信息可以长期保存且信息描述周密、逻辑性强，不容易产生误解和纠纷。但是缺点是耗费的时间比口头沟通要多，同时无法保证接收者是否能够正确理解，综合两者的优缺点，我们最终采用的沟通方式是以书面沟通为主，口头和书面相结合的方式，每次口头沟通后会落实到文字上双方认可再实施，保证沟通的有效性。
4.项目的质量管理
项目质量管理是为满足项目利益相关者的需要而开展的项目管理活动。针对SRM项目的质量管理就是软件功能测试，包括单元测试和集成测试。由于我们此次合作的软件开发商没有专业的测试团队，只是开发人员交换测试，一方面由于时间进度紧而测试不充分，另一方面对别人开发的模块需求不清晰测不出业务流程的正确与否。所以到单元测试和集成阶段，关键用户就要参与进来，每个关键用户测试自己所熟悉的领域，除了对页面字段功能进行验收外，还要对功能之间的业务逻辑进行验证，这样开发与测试并行进行，有利于保证进度。但是从另一方面来看，我们收到的最初的交付物错误百出，通过问题清单的形式发给开发经理进行修改和再次发布验证。虽然我们验证的比较充分，但是这样项目组面对的工作量就会成倍的增加。建议以后最好选有专业测试团队的软件开发商，让其分担项目组的测试工作量。
四、小结
最终采购信息化系统SRM项目分阶段都如期完成，每个项目上线后都会进行项目总结和经验分享，让项目组成员在业务能力上能得到很好的提升。有效地运用项目管理的方法和工具对项目成功实施至关重要，但是也要活学活用。作为一名合格的项目经理，是在不断学习中成长起来的，要善于从每个项目中总结经验才能不断进步。
（作者单位：北京汽车股份有限公司）