集成项目实施主要风险规避点

在软件行业中，一个成功的大型集成类软件项目需要从多个方面进行管理把控，如：技术管理、人员管理、进度管理、沟通管理、风险管理等；

项目风险规避一直都是项目管理的重要问题之一，不同类型的项目会有不同风险产生，有效的风险管理可以大大降低项目中风险事件的发生几率，将对项目的负面影响减少到最低。

本文主要从集成项目的特性入手，进行剖析存在的风险及规避方式。

一、集成项目特性

很多项目在风险分析上，除掉不可抗力，项目类型的特性往往也是风险点产生的诱因之一，在具体列举集成项目有哪些风险之前，首先了解下集成项目具备哪些特性，根据特性逐步分析。

1. 场景多

集成类项目为多种类型项目的统称，根据不同的应用场景，可以拆分或组合成不同的解决方案，如：统一应用集成方案、统一门户集成方案、数据治理集成方案、SOA综合集成方案等。

而对于同一种方案，根据不同用户的业务特殊性和行业要求，通常不会直接用标准方案进行项目实施，都会不同程度上的对产品功能进行定制或扩展，对方案进行对应的调整，提供差异化的解决方案，包括产品的组合、技术架构等，也就是所谓的个性化定制。

2. 产品杂

软件集成项目中，主要用来解决异构应用系统之间的功能、信息、数据的有效传递，过程中对用户、数据等进行有效的治理。

所集成的产品为客户购入的不同厂商、不同平台、不同技术、不同语言的应用，甚至是与其它集成类平台产品相结合，多品牌产品共同进行项目的实施，需要对所用产品本身的兼容性、开发程度、厂商的配合性等进行综合平衡。

3. 牵扯广

进入集成项目阶段的企业很少处在信息化建设初期，通常已经具备较为完善的IT基础设施环境，所处阶段称之为整合阶段，处在整体信息化建设的中后期，项目中会接触不同行业客户的各类软件、平台产品；

这就需要对不同行业、业务场景、厂商的软件/平台类产品有对应的了解和实战经验，要求对不同软件、平台、硬件、网络都有涉猎；

同时IT领域技术发展迅速，项目中一定会接触到前沿技术的应用及融合，这些都很考验实施方产品、方案及团队的软硬实力。

4. 周期长

如上所述，集成类项目与应用系统实施项目周期不同，集成类项目虽然也需要使用对应的产品，但并不像市面上大多数HR、财务、库存等应用系统一样，现场实施安装1-2天后即可完成；

根据不同项目类型，需要实施人员驻场实施3-8个月，难度较高的项目甚至需要分阶段、分期数进行，涉及前期需求调研、功能设计，中期实施开发、上线测试、后期项目终验、运维服务等一系列工作，项目进行中不可预见因素较多，一定程度上加大了项目的实施难度。

二、项目风险剖析

当一个事物的特性越明显，其中隐藏的一些问题也会相对明显，在大型集成项目的实施过程中，不可预见的因素很多，需要经常面临已知、未知的风险，若想从源头管控这些风险，就需要对风险加以分析、管控和防范。

1. 场景多

具体表现为业务场景多，需求不同，解决方案所用产品也各不相同，造成需求理解偏差，产品搭配不合理，业务把控不准，需求蔓延等现象。

1.1 需求理解偏差

• 需求场景类似，但具备行业性及差异化，造成需求把握不准；
• 需求调研不全面、设计不严谨，没有涵盖客户全面需求；
• 没有发现客户潜在需求或表述不明确的需求，没有进行需求引导；
• 需求整理之后没有与客户反复确认，造成需求纰漏；
• 缺乏详细功能设计，实现方式、技术难点、约束条件不明确；

1.2 项目需求蔓延

• 实施方没有进行需求封闭，理顺当下项目实施范围；
• 实施方没有讲明或客户方不明确需求变更对项目的影响；
• 项目实施前存在待建系统，随着系统建成产生集成需求（通常很多客户不愿承认这种现象为需求蔓延）；
• 客户方随着项目深入，加深对项目的理解，从而提出更多需求；

1.3 产品方案不配

• 实施方不具备支撑解决方案落地的产品，二次外包，无法把控项目进度；
• 实施方个别产品无法匹配客户需求，外采结合打单，产品之间不兼容；
• 实施方产品不具备当前客户个性化需求，扩展能力差，缺乏二次开发能力；

2. 产品杂

具体表现为百家产品，品牌各异，每个项目需要进行多方面协调、沟通，一旦沟通协调不力、各方配合不到位就会造成项目推进困难，项目进度缓慢等现象。

2.1 各方配合不力

• 客户方各部门之间的数据源头与协作业务梳理等工作配合性差；
• 伙伴对产品/项目的技术支持、项目进度推进、节点推进验收等配合性差；
• 被集成商担心产品影响力受损，不愿响应或配合提供接口或数据；
• 被集成商最近与客户没有商机上的往来项目，不愿参与配合工作；
• 客户使用产品版本过低或时间过久，联系不到原厂商或旧版本不在维护范围；
• 内部团队成员间默契较弱、自我意识强配合能力差、分工不利造成项目延期；

2.2 相关意识缺失

• 不会利用多方沟通渠道去协调解决问题，选择默默承受问题，不愿沟通解决；
• 关键时刻不能站出来与客户或被集成厂商进行谈判，表明情况和立场；
• 不愿表明事实真相，试图用拖延或简略汇报掩盖；
• 沟通过程中出现偏差，造成信息失真，不利于沟通事项的顺利推进；
• 沟通方法存在问题，缺乏沟通技巧、交互不明确、无引导性、无重点；

2.3 协调能力不足

• 对于项目中的困难，无法有效协调内部或外部人员对项目进行协助支持；
• 对项目过程中人与人之间的关系和矛盾处理能力弱，处事过于激进或平和；
• 无法明确掌握每个阶段所需要协调的重点事宜，错失协调或沟通的良机；

3. 牵扯广

具体表现为项目涉及行业多、业务广，需要接触不同层面的技术产品或架构理念，如果业务知识浅显、技术能力、实战经验欠缺，就无法顺利交付项目。

3.1 业务知识欠缺

• 实施人员对客户所在行业业务不了解，无法有效理顺客户业务流程；
• 没有回归业务，比起业务更重视技术功能上的实现，从而脱离项目本质；
• 对客户所用系统不了解，包括系统的功能、语言、版本、数据库等信息；
• 功能无法与业务进行正确的对照，无法辨别客户需求中的错误，被动实施；

3.2 实战经验薄弱

• 没有承接过类似行业或集成类型的项目，整体业务及项目流程不够熟悉；
• 实施人员对项目所用实施产品熟悉度不够，无法灵活运用；
• 实施人员对于项目里程碑、沟通方式、人际关系、协调合作等拿捏不准；
• 按照计划进行不变通，没有充分为预见风险或为解决潜在的风险预留时间；

3.3 产品功能缺陷

• 产品功能远达不到项目中要求，无法直接用于项目，需要后期扩展；
• 实施过程花费时间解决产品功能缺陷，或用其它不熟练的工具弥补产品缺陷；
• 在项目中孵化产品新功能或升级产品功能，产品扩展开发工作量增加，时间成本花费较多；
• 产品存在安全性问题，无法满足项目中安全方面需求；
• 与其它同类型产品集成、兼容性差，实施厂商缺乏底层代码级管控能力；

4. 周期长

具体表现为项目规模较大、周期较长，无论是人力、物力都会有一定程度的消耗，容易受地理环境、周围因素、消极情绪等影响。

4.1 交付体系混乱

• 没有完备的项目交付体系，对项目中的人员管理、沟通管理、技术管理、计划管理、文档管理、风险管理、交付管理能力弱；
• 缺少项目整体/细分计划，随着项目各个里程碑节点进行与变动，对应计划调整、应对能力差；
• 没有综合项目管理机制，在不断的摸索中完善机制，无法识别和管理风险；
• 难点攻克时期，缺少团队人员支撑，内部协调能力弱，无良好的应对手段；
• 缺少项目考核机制，对于项目奖惩不明确，关键问题难以问责及及时总结；

4.2 人员产生变动

• 项目周期长，长期出差缺乏归属感与公司脱节，造成热情耗尽消极怠工或人员离职，寻找更好的出路；
• 无法适应在项目中来自客户方与公司内部所带来的压力，自认能力不足，失去挑战精神，不愿意再去承担重任；
• 拖期过长，需要将项目人员进行召回，替换能力相符的人员进行补充；
• 人员岗位所致，需要同时兼顾多个项目，项目稳定后撤场换人；
• 项目成员之间能力、短板差异较大，无法胜任当前工作，内部进行人员替换；
• 家庭原因、自身生病或不可抗力因素导致调岗或离职；

4.3 超出预期成本

• 进度不顺利，实施方租房、人天成本（通常在项目估算金额前会对相关费用打出余量）超出预期，导致项目利润减少或变负；
• 项目周期内建设成果无法正式运行或见效，客户方产生不满情绪，消极配合；

三、项目风险规避

对于项目风险从根本上讲，是不可能完全消除的，总会有一些未知的、不确定性的风险等待项目成员；

因此风险总是存在的，面对风险能做到的就是尽最大限度的去规避，规避不是指知道存在的风险之后，刻意避开不去触碰即可，而是需要掌握应对的方法，解决已知风险，并通过一系列的措施将未知风险控制在一定范围内。

通过上述对项目风险的剖析，总结归类从以下几个角度针对性进行集成项目风险规避。

1. 建立项目体系

注重项目体系的建立，保证项目从初期到各个里程碑节点，后期验收运维等一系列过程进行监督、把控、保障项目的平稳交付，以便于更好的攻克项目难题，应对风险，保障进度。

• 建议将公司产品、团队、过程进行一体化管理，注重项目案例的沉淀及相关交付物的归档，建立一套相同场景可复用的标准体系；
• 建立项目PPMO管理委员会，设立关键人员，从项目初期售前开始介入，包括需求调研、项目实施进行专项支撑，直到项目验收运维；
• 对项目的每一个环节都严格制定标准，如：集成标准、接口标准、计划标准、文档标准、验收标准、项目管理标准、制度标准等；
• 设立项目双周滚动周报、人员日报机制，严格把控项目人员工作计划及内容，及时发展项目中出现的问题，加以控制解决；
• 加强客户的项目参与度，从项目开始，每周定时为用户发送项目周报，并定期召开项目会议，保持良好的沟通，信息一致，及时沟通存在问题；
• 对于项目中需要攻克的难点，由公司指派专人进行专项支撑，项目人员负责进度推进，专项人员进行解决并告知成果；
• 建立项目考核制度，明确项目中的奖惩规则，规则是可追溯可考核的；

2. 需求分析到位

很多项目拖期或需求蔓延都来源于前期对于客户的需求把控不到位，没有明确、及时引导、封闭需求，所以在项目前期的需求调研及把控方面需要掌握一定的方式方法。

• 进行深度调研，多方面与客户进行深入沟通，调研后及时撰写需求调研文档并进行内部详细评审，对于不明确内容进行校正，并与客户确认；
• 对于不明确需求，反复与客户进行确认，直至双方没有异议，并认可，出具最终需求说明文档；
• 有意识的控制及引导客户的需求范围，以专业角度给出建议，删除没必要的需求，保留有必要的需求；
• 与客户一同进行外部需求评审会议，进行需求确认，并在会议中进行需求固化、封闭，双方认可后，将最终需求文件与客户签字确认；
• 需求确认会议上表明什么是需求蔓延及哪些范围算在需求蔓延内，做好边界管控，并告知客户需求蔓延对项目造成的影响及需走的流程等事宜；
• 需求明确后根据文档进行功能设计，详细且周全，从技术实现、应用功能、注意事项、攻克难点等多方面进行考虑；
• 从客户角度理解需求及实现方式，模拟回归用户的真实用途，制定合理的准确的功能设计，之后进行内部评审，通过后即可实施；
• 对于后期需求蔓延，有必要且可以容易完成的需求，可以顺手解决积累良好的印象，对于没必要的需求可以引导其放在二期进行；

3. 产品方案完备

很多公司的产品及方案都是在项目中不断打磨出来的，一个好的项目既能为公司带来利益，也会对公司的产品及方案有所帮助，但企业不能仅依靠在项目中去完善升级产品或方案，平时也要注重积累，不断的打磨升级。

• 找准企业的基因及核心竞争力，对于核心产品的质量进行严格把控及打磨，制定详细的升级计划；
• 新产品设计需要进行全方面考虑，包括产品的应用领域、客户需求、产品特性、核心特点、性能安全、灵活性、兼容性等一系列前提；
• 具备升级意识，随着技术发展与项目中客户的需求进行完善产品，好的部分进行源码复用，成为产品的标准功能，升级产品能力；
• 注重打造种类齐全且彼此之间可以相互支撑的产品套件，如不具备这种能力，至少保证产品线也能够组成至少一个完整的解决方案；
• 寻找共同打单合作伙伴需要多方面选型，注重产品的把控性、整体性及与自身方案、理念的融合性；

4. 人才培养储备

人员的能力及稳定性是影响项目成败关键的问题之一，实施方需要在日常工作中对人员的项目管理能力、技术能力等各方面进行培训，而不是在项目中去现锻炼，项目中试错、学习、成长固然没有错，但应该有所准备和积累后再去执行。

• 建立人员培训体系，快速培养项目人员的产品知识与基本技能，将日常工作当做项目形式，了解项目工作同时培养项目感觉；
• 培养项目人员学习公司全线产品使用及原理，具备产品的快速扩展能力，同时了解对应的解决方案，便于在项目中对产品的组合与拆分，将客户的需求快速对应；
• 培养项目人员自主提升意识，主动对项目涉及的行业知识、业务、相关信息化系统进行学习，加深知识储备与业务流程的理解；
• 培养项目人员主动汇报与协调意识，积极主动汇报项目中存在的问题，及时与客户、伙伴、公司内部进行沟通交互，协调解决问题，同时加强能力、经验的积累提升；
• 培养项目人员时刻具备项目风险意识，以项目计划为基础，将预知风险进行罗列（技术、产品、人员等），从而进行评估，并预留缓冲时间，对项目进行严格把控，每一个关键节点及实施情况烂熟于心，保证可追溯，及时发现风险；
• 进行项目人员备份，尽可能避免将项目中所有重头工作全部交付于项目经理一人手中，项目实行正副经理制度，保持两者工作透明，便于一人离职平滑替换；平时加强同类型人才的培养与储备，建立人才梯队；
• 对项目人员进行安全防范培训，明确项目出差过程中常见问题及解决方式；

集成项目的风险管理一直是各个实施方不断在研究和攻克的问题，项目中的风险严重的可以导致集成项目的拖期、超出预算、甚至做成烂尾；

而对于大型的集成项目来说，风险难以避免只能面对，在风险面前能做的就是不断完善现有的项目交付体系、人员培训管理体系、升级优化产品及方案，提高综合实力，根据经验加强项目中风险管控制度与预测能力，未雨绸缪在风险来临之际从容应对。

本文素材来自互联网