前言

最近，我所带的项目风险很高，目前项目风险已经转化为时间进度严重滞后的问题。按照项目最初规划和实施方案，项目开发周期为5个月，开始时间点为2015年1月份，预估开发工作量为100~120人月，项目进度甘特图简图如下图所示：

如今6月份是上线时间，而由于各种客观原因，没有人力实施，实际投入与离上线还有些差距，因此，为了按新计划实施项目，被逼转型提出了业务外包解决方案。
基于业务外包的进度计划调整为下图所示甘特图。

业务外包方案

项目概况

系统建设方案是使用OpenText Cordys产品做为管理支撑系统的统一PaaS平台，基于此平台搭建办公流程能力服务平台和信息类专业应用。
系统架构及技术使用设计如下表所示：

由于系统系统平台及其所采用的BPM产品技术专业性比较强，而产品厂家服务支撑中心又不擅长业务方面的实施，所以业务外包采用分包方案，以平台产品为核心的系统能力平台和以平台外围应用开发的业务应用两部分。

业务外包分标一：系统能力平台的范围及要求

系统能力平台分标由基础能力平台、系统接口及流程能力平台等三部分构成，围绕着OpenText Cordys BOP 4产品开发基础服务和二次封装。

Webservice接口

系统能力平台对外主要提供Webservice API，业务应用分包方使用。

技术要求

系统能力平台分包方需具有原厂服务授权，其技术人员需具有此产品的开发、实施经验，主要技术有：

• 基于平台二次封装开发Webservice （使用Java语言）
• 掌握平台及BPM技术，熟悉BPMN规范
• 能完成平台产品的部署实施
• 能掌握Garner所定义的多租户模型，并按需求设计支持多租户的PaaS平台
• JavaScript （使用JQuery）
• HTML + CSS （使用Bootstrap及HTML5）
• 基于平台开发业务密切的Webservice （使用Java语言）
• 接口协议为Soap Webservice
• 数据格式包括：XML、JSON （需要解析开发）
• 数据库为Oracle和MongDB

业务外包分标二：业务应用的范围及要求

业务应用分标由阳光大厅、专业信息及流程能力平台信息服务等三部分组成，围绕用户业务开发应用和实施，也是基于办公流程能力二次开发平台进行业务实施。

业务应用的范围

业务应用的范围如下表所示，范围主要是用户的业务及大量界面展现内容，从业务视角看：

• 业务（流程及信息）信息与业务运行信息的全生命周期管理
• 部分专业信息，例如：业务通知、信息上报、安全生产信息管理等
• 平台层面信息管理服务，例如论坛、信息专栏管理、信息发布与展现等
• 能力平台中的表单快速开发工具

主页——我的办公桌面

主页——阳光大厅界面

界面设计简明明细（片段）

业务应用分包方接手发包方的详细设计，并按自身技术特点，补充及优化设计（较大的调整，需经发包方认可）。

技术要求

系统平台属于SOA架构，基于平台产品提供的SOA Grid（ESB）和Web服务（Apache HTTP）进行设计开发，部分业务应用需支持SaaS模型，主要具体开发技术有：

• JavaScript （使用JQuery）
• HTML + CSS （使用Bootstrap及HTML5）
• 基于平台开发业务密切的Webservice （使用Java语言）
• 接口协议为Soap Webservice
• 数据格式包括：XML、JSON （需要解析开发）
• 数据库为Oracle和MongDB

分工界面及其他工作安排

分工界面

注：分包一是指系统能力平台分包，分包二是指业务应用分包。

项目管理参照公司CMMI规范执行，执行标准为三级。

沟通与协调管理方案

1、沟通形式
（1）会议
会议分为周例会、里程碑会议、评审会议，周例会是非常重要的正式沟通形式，三方主要管理、开发人员都要出席，由发包方项目经理指定例会主持和记录人员，会议结束后，由会议主持者负责通过邮件发出会议纪要给与会人员，如果没有疑异，等同签字确认，并按会议精神执行，如果有疑虑，本着平等、友好方式协商处理。
（2）邮件
（3）其他形式

2、沟通效率
对于三方沟通有效性和效率做出如下规则：
（1）首先，在相关分包协议上归档沟通效率考核机制，明确相关责任方，以及处理办法；
（2）主要规则如下：

• 对沟通会议安排计划，并设置会议时限，超时10%扣分
• 每次沟通会议，都需要形成有效的会议纪要，各方按约定执行，违反者按违反任务模式处理
• 对于邮件沟通，必须在一个工作日内容答复（注：答复不同于解决，需要答复后续处理计划或内容）
• 对于沟通冲突及时上报给项目经理，以及升级到公司，直至商务层面
• 按CMMI 3级规则，形成项目沟通计划、沟通记录。

3、冲突处理办法
（1）由直接责任人承担相关各方损失，损失定义如下：
任务或时间进度超期超过8%为底限，超过者承担相关损失。
（2）客户端与服务端接口纠纷定义规则如下：
接口BUG率转化为任务或时间进度方式处理，同时，也按质量目标进行考核。
（3）冲突仲裁责任人为技术经理，升级顺序为项目经理、公司专家组，直至按合同约定其他方式仲裁。

4、沟通对象及层级约定
（1）技术层面内容，系统能力平台分包方与业务应用分包方可以直接组织沟通，按沟通管理办法执行，涉及到设计及变更内容，需要发包方参与；
（2）技术人员可以直接点对点沟通；
（3）重大技术事项由分包方项目经理与发包方技术经理直接沟通；
（4）项目重大事项由分包方项目经理与发包方项目经理沟通；
（5）涉及到合同等商务事项，由发包方项目经理协调处理。

其他工作安排

其中，公文管理瘦身及优化、通用办公迁移重建、业务流程实施等内容不做业务外包，由公司协调内部资源，上线时逐步自行完成。

1、关于开发环境约定

• 由发包方提供系统平台开发环境，技术人员开发终端由分包方自行解决
• 由发包方提供工作场地，各方必须有驻场人员
• 工作纪律执行发包方公司规定，各方自行管理

2、其他

分包的风险及应对措施

分包商数量的增加不仅会降低生产率，减缓工作进程，更重要的是可能会增加未来系统的维护工作量。

开发进度风险

由于软件系统中存在业务应用依赖系统能力平台的情况，系统能力平台的开发进度直接影响到业务应用开发。

应对措施：系统能力平台分包开发计划，按比业务应用提前一周执行，但不能提前过多，避免工作脱节。

沟通风险

多家分包单位，易出现相互推诿的风险，沟通不畅、沟通效率低的风险。

应对措施：详见本文中“沟通与协调管理方案”内容。

分包接口风险

对软件系统拆分多个分包，易出现拆分不合理、分包界限不清晰的风险，相互见接口定义不准确、不清晰的风险。

应对措施：从项目组设计能力、分包商开发能力来分析，此风险需要接受，但是，是可以降低风险的。

• 一是由项目组主持接口定义，分包方参与讨论、定义，减少误解等原因带来的风险
• 二是本着友好协商的原则，分包方相互协助，共同化解接口矛盾

分包商在项目执行过程中的地位问题

从道理上讲，在项目的执行工程中，分包商应该完全服从项目发包者的意志，因为他们签合同的对象是发包者，在工作上是向发包者负责，而不是向用户负责。

在开发阶段

分包商做为开发者，地位及定位比较清晰，直接做为驻场开发人员参与项目开发，很少接触到用户和客户，不足为虑。

在上线、业务实施阶段

分包开发、实施人员势必要参与系统部署、培训、业务实施需求获取分析等工作内容，将直接面对客户和用户。为此，项目组将定义上述工作原则。

• 提高服务意思，明确服务范围
• 有责任和义务获取需求，听取用户意见，但不能发布个人意见，或者超范围引导用户，并及时向规定相关负责人反馈信息，例如把用户实施需求反馈给需求负责人
• 在实施阶段，把分包开发人员、实施人员需要把自己定位为项目组成员，按发包方项目组员行为准则执行。

启动采购需求

采购方式定义如下：

• 公开招标，是指招标人以招标公告的方式邀请不特定的法人或者其他组织投标，通过评标确定供应商的采购方式。
• 邀请招标，是指招标人以投标邀请书的方式邀请特定的法人或者其他组织投标，通过评标确定供应商的采购方式。
• 竞争性谈判，是指选择至少三家供应商，通过竞争性谈判，确定最终供应商的采购方式。
• 单一来源采购，是指从某一特定供应商处采购货物、工程和服务的采购方式。

采购流程定义如下：

注：采购需求阶段由采购需求部门负责提出采购需求，组织编制技术规范。采购需求主要内容包括：项目信息、需求物资（服务类及委托外包业务），采购预算、供应商推荐意见等。

软件开发需要执行标准和规范，在开发过程的不同阶段，在开发方式和步骤上应该追求一致性和连贯性，分包商应该选择相对比较固定的软件开发合作伙伴。

定向采购招标

从项目实施的连续性角度和专业行角度看，系统能力平台分包，项目组推荐原系统平台现场服务厂商。
原系统平台现场服务厂商已经参与了项目的需求开发、系统设计、软件开发到人员培训等工作，对项目的业务需求及技术实现有更清晰的把握，后续项目的合作也会更顺畅

公开招标采购

业务应用分包拟采用公开招标方式，入围条件是有开发办公系统或业务流程系统的项目经验，如使用过系统平台产品，可以优先加分。

技术规范书

招标所使用的技术规范书，由以下文档构成：

• 《软件需求说明书》
• 《概要设计》
• 《数据库设计》
• 《Webservice API及规范》
• 《界面原型设计》
• 各个模块的功能设计

先写到这里，采购的路还很长，预祝采购过程顺利。