在软件行业中，一个成功的大型集成类软件项目需要从多个方面进行管理把控，如：技术管理、人员管理、进度管理、沟通管理、风险管理等；项目风险规避一直都是项目管理的重要问题之一，不同类型的项目会有不同风险产生，有效的风险管理可以大大降低项目中风险事件的发生几率，将对项目的负面影响减少到最低。
本文主要从集成项目的特性入手，进行剖析存在的风险及规避方式。
一、集成项目特性很多项目在风险分析上，除掉不可抗力，项目类型的特性往往也是风险点产生的诱因之一，在具体列举集成项目有哪些风险之前，首先了解下集成项目具备哪些特性，根据特性逐步分析。
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. 需求分析到位很多项目拖期或需求蔓延都
