一份完整的ERP项目实施规范

实施步骤

以签订合同为标志，项目进入实施阶段，实施步骤分为项目启动、实施规划、教育培训、系统初始、系统并行、项目结束六个阶段，每个阶段需要完成特定的任务，达成预定的目标，形成阶段工作成果。如图所示：

1.1项目启动(Project Startup)

1.1.1 项目交接

目标：完成从售前到实施的正式交接，项目经理开始全面负责项目的实施。

任务：项目经理正式任命后，项目经理应要求项目售前经理填制《项目交接表》，进行正式的书面交接。

要求：

(1) 项目经理要尽可能详细的了解项目背景、项目售前过程、并将售前文档收集齐全，交接内容应以书面交接为主。

(2) 做为具有法律效力的合同，项目经理应在交接时认真审核，对于以下12条内容应特别注意：

• 合同实施的产品模块是否确定、站点数是否有限制；
• 是否具有二次开发内容、是否限制二次开发工作量；
• 有无硬件、网络系统转包或集成第三方软件；
• 项目实施范围是否明确；
• 双方的权利和责任描述是否清晰；
• 项目的验收方式：是否分阶段分模块验收；
• 是否有规定的实施完成时间限制；
• 验收标准是否已经确定；
• 回款方式和回款时间是否明确；
• 是否有其他会引起歧义的描述，有无特别针对我方的约束；
• 合同中的哪些描述可能会给项目带来风险；
• 有哪些特别的附件。发现其中的问题应尽快向售前经理、事业部经理、商务代表反映，以求在项目前期解决。

角色：项目经理、售前经理

输出：《项目交接表》

1.1.2 项目组织

目标：项目双方成立联合项目组，各种资源准备齐全，项目正式启动。

任务：

(1) 成立项目组

项目经理应根据实施规模、实施周期和项目范围向部门主管经理提出书面申请,提出对 项目组中各角色的能力要求和条件。 项目组织可以分为项目领导小组、实施小组、职能业务小组；项目领导小组一般由公司高层领导、事业部经理、大区经理组成；实施小组由项目经理、实施经理、开发经理、商务代表、实施人员组成；职能业务小组可以划分为二次开发小组（包括软件经理、二次开发人员）、财务实施小组（包括实施经理、相关实施人员）、物流实施小组（包括实施经理、相关实施人员）组织结构如下：

组织成员具体职责如下：

项目经理具体职责如下：

(1) 与项目经理应协助用户方项目负责人在项目启动初期也要成立项目领导小组、实施小组、业务小组三级组织结构，明确各自职责分工，并要求对方项目组成员能够为该项目投入必要的精力 。

为了便于协调，同时也是为了增进用户的项目参与意识，双方可以成立联合项目小组， 共同来推动项目，但双方人员的任务分工必须要明确。 项目经理需要编制《项目组织结构表》，让双方项目组成员了解该项目人员的构成、联系方式、各自职责分工等。

(2)准备设备资源

项目经理应准备好项目组所需的机器设备、工具盘、产品说明书、实施资料等，如果 缺少相关资源，及时向部门主管经理提出书面申请，对于暂时不能到位的关键资源，应提出最晚到位时间。

(3)召开项目启动大会

为使用户方相关部门高度重视该项目，为下一步实施扫清障碍，项目经理应要求用户召开 项目启动大会；用户方项目领导小组、实施小组成员必须参加，由其项目负责人讲述项目的作用和意义、项目人员组织、工作要求等，项目经理、实施经理列席参加。另外，乙方项目经理也应召开项目启动内部会议，在会上跟项目组成员讲解合同背景、售前方案、用户要求、所用产品、实施截止时间、对项目组成员的要求等。

输出：《项目组织结构表》

要求：

(1) 项目经理必须了解项目组成员的工作能力，确认他们能承担各自的任务，并书面明确各自的职责和要求，如果认为某成员无法胜任工作要求，要及时提出更换申请；

(2) 项目经理要注意提醒用户方项目负责人，项目实施小组中必须由业务部门的积极参与，不能单纯依靠计算机中心的维护人员。

1.2 实施规划(Layout of Implement)

在该阶段主要完成的任务：实施方案制订、现场调研、实施计划制订、预算计划制订。该阶段任务完成的质量好坏将直接影响项目的后续实施和项目验收，项目经理应高度重视该阶段。1.2.1 实施方案制订

目标：根据项目合同、用户的实际情况，项目经理组织制订项目总体实施方案，使用户了解项目实施的整体工作流程，并认同项目实施过程中的一些做法，做为指导项目实施的章程。

输出：《项目实施方案》

角色：项目经理、实施经理、用户方项目经理

要求：

(1) 实施方案中应明确以下几点：

• 项目目标、实施范围、实施模块
• 项目大致的实施步骤
• 项目各阶段应交付的工作成果
• 项目实施的前提
• 用户需要为配合项目而采取的措施和投入的资源
• 项目管理的内容

(2) 该实施方案在现场调研后，如果项目目标、实施范围等发生变化，要注意调整。

1.2.2 现场调研

目标：详细了解用户的业务流程和现状，归纳用户需求，进一步确认项目的实施范围和二次开发范围，对问题进行分析，提出解决方案，形成项目调研报告，做为指导下阶段项目实施的重要依据。

步骤：

(1) 制定调研计划 可以首先跟用户方项目负责人或者是对企业总体业务流程非常熟悉的管理人员交流下，由其介绍企业的概况、组织结构、总体业务流程、对上项目的想法等，在对企业整体有一个大致了解的基础上，项目经理再跟用户方项目负责人协商制订调研计划，确定调研时间、调研对象、调研方式，让用户提前安排时间和人力。

(2) 准备调研提纲和问卷 调研小组应事先准备调研提纲和问卷，并提前下发，要求用户在规定时间内书面整理完成调研提纲和问卷中的内容，调研小组根据收集的内容可以进行针对性、重点性的调研，避免现场无目的性的随意调研。

(3) 召开调研动员会议在正式调研之前，项目经理可以提议用户方项目经理召开一个会议，让相关部门领导和业务骨干参加，宣布调研的目的、意义及需要配合的事项等，在会上可以把调研提纲和问卷下发，让被调研部门提前准备。

(4) 现场调研 现场调研可以在收集的调查问卷、提纲的基础上，按业务流的顺序进行调研，每次调研交流可能会涉及多个部门人员参加，应注意多方收集与项目有关的资料，并核对信息的真实性；与用户方的领导、业务人员要进行广泛的接触，了解他们的真实想法。

(5) 整理调研报告 根据调研结果，调研人员需要详细认真地整理编写调研报告。该报告是今后指导项目实施的根本依据。所以应切实可行，真正为项目的下一步实施起到指导作用，而不是流于形式。

(6) 现场回访 在整理调研资料的过程中，可能会发现某些业务流程、单据流转了解的不够详细，存在疑惑的地方，这就需要调研人员有重点的再进行现场回访，以确认、核实信息的准确性。

(7) 完善调研报告调研人员现场回访后，需要充实、完善调研报告。

(8) 确认调研报告 经过修改完善后，提交、讲解调研报告，最终和用户共同确认调研报告。

输出：《调研计划》《项目调研提纲》《项目调研问卷》《项目调研报告》

要求：

(1) 对于 ERP 项目，在签订正式合同前，一般已经进行售前调研，所以实施调研时必须结合售前调研结果，把握重点，控制调研时间，不要引起用户反感；

(2) 调研小组要尽可能多采用直观的图表、流程图、问卷形式，让用户按照我们的要求，自己书面描述出现有业务流程以及对系统的需求，这样获取的信息可能会更真实；

(3) 通过调研必须明确用户需求，并分析出存在的问题，提出解决方案，如果有二次开发，项目经理、实施经理需要配合软件经理界定出二次开发范围和工作量；

(4) 项目调研报告必须由双方项目经理签字并盖章认可。

1.2.3 实施计划制订

目标：制订总体实施计划，做为指导项目实施的行动指南。

输出：《项目总体实施计划》

(1) 在实施过程中，要在总体实施计划的框架下，逐步分解为阶段性计划、周计划，形成三级计划体系：

总体实施计划：

• 需要完成哪些任务、预期目标；
• 完成计划的开始时间和结束时间
• 每项任务所需要的资源（包括双方所配备的人力和设备）
• 按计划实施的前提条件

在整个项目期间，该计划极谨慎地变更。

阶段实施计划：

• 各阶段工作内容、各阶段任务分解与详细任务描述
• 各任务起止时间
• 协同人员及协同工作内容（落实到部门或岗位）

该计划于各阶段工作正式启动前双方确认，对于各阶段的工作关键路线上的任务起止时间、涉及多方的协同工作，应谨慎变更。

周工作计划：根据阶段计划的实际执行进度而制定，该计划可以包含在项目周报中，一般于每周五下午确认：

• 下一周每天的各项任务
• 详细时间与地点
• 协同人员及协同工作内容（落实到具体人）要求用户项目实施小组将计划及时下达到相关部门和责任人，以便用户合理安排各自在下周的业务工作时间，避免日常业务与项目工作的相互冲突。

(2) 如果项目中有二次开发内容，制订实施计划时一定要跟软件经理商量，考虑二次开发进度，合理的安排实施进度，确定好实施中的工作次序，比如是同时实施财务模块和业务模块，还是先实施财务，后实施业务，保证计划的切实可行。

(3) 制订计划时，要考虑资源（人力、时间）制约。如财务部每月月底要准备财务结算，不能抽过多时间；客户本身基础数据比较混乱，可能整理基础数据的工作要花费很长时间；

(4) 制订计划，一定要留有余地。在实施过程中会遇到各种事先没有预计到的问题，像程序问题、二次开发延长都可能导致项目拖期，制订计划应该考虑到，过于紧凑的计划往往不能按期完成；

(5) 双方实施小组要定期检查计划完成情况，对于计划没有按时完成的情况，应分析原因，是用户方造成的，还是我方造成的，如果是我方造成的，应跟用户解释，以取得用户的理解，并及时调整下一步的实施计划；

(6) 要求双方项目经理签字确认，做为指导项目实施的重要依据。

1.2.4 预算计划制订

目标：在签订合同现场调研后，项目经理制订项目费用预算计划，做为项目成本控制和考核的依据。

任务：由公司项目评审组根据项目立项报告进行项目评审，确定该项目的费用预算计划和实施成本。

输出：《项目费用预算计划》

1.3 教育培训(Education and Teach)

在该阶段主要完成以下任务：企业中高层培训、关键用户培训、系统管理员培训、最终用户培训培训是分层次、分对象、分阶段的，所以该阶段任务实际上是贯穿于项目实施的各个阶段，而不是独立的一个阶段，同时也是实现技术转移和知识转移的过程；高质量的培训，等于项目成功了一半，项目经理应特别重视。

1.3.1 企业中高层培训

1.3.2关键用户培训关键用户是指企业的实施小组成员、业务骨干，他们是项目实施的主要推动者，必须高度重视对他们的培训。

1.3.3 系统管理员培训

1.3.4最终用户培训

输出：《培训计划》《培训总结》《培训调查表》

角色：培训讲师、最终用户对培训总体要求：

• 明确培训目的和要达到的效果；
• 培训资料（讲义、练习题）要结合企业业务，准备充分；
• 培训讲师可以考虑项目组以外的人员来培训，只要保证效果即可。
• 制定合理的培训计划（对象、时间、地点、方式等）
• 必须订立严格的考核标准，一方面要评估学员的培训效果，可以通过考试、练习等方式来实现；另一方面也要评估培训老师的培训效果，不要走形式。

1.4 系统初始 (System Commencement)

在该阶段主要完成以下任务：系统安装、基础数据准备、工作准则拟订、系统初始化。

1.4.1 系统安装

目标：帐套创建完毕，各工作站所用软件安装完毕，能够联接帐套。

任务：检查客户网络环境是否建立；机器配置是否符合要求；安装数据库系统、数据库调优；安装工作站软件；确认各工作站所装的软件能否正常使用。

输出：《安装环境及配置内容清单》

要求：

(1) 在安装软件之前，实施经理应确认用户的硬件设施是否到位，网络是否连通，如果用户没有按规定时间完成硬件配置及网络建设，应跟用户方项目经理协商，明确硬件系统可以正常使用的最晚截止时间，并且项目经理可以考虑暂时让部分实施人员退出客户现场，如果因此造成实施计划不能按时完成，双方协商后，相应的变更实施计划。

(2) 软件安装完毕后，应要求用户在《安装环境及配置内容清单》上签字确认。

1.4.2 基础数据准备

目标：基础数据准备齐全，双方认为可以据此进行初始化工作。

任务：

(1) 确定基础数据准备范围、时间什么时间必须完成，准备什么时间的数据，准备哪些数据。

(2) 明确数据准备的责任人 要求用户自己准备基础数据，明确责任人，并保证数据的完整性、正确性，实施人员只提供数据准备的要求、格式并加以指导培训。

(3) 培训基础数据的准备方法由实施经理给用户培训基础数据的含义，应按什么格式和要求来准备。

(4) 监督数据准备的质量和进度在准备过程中，实施人员要经常检查数据的合理性和合规性，发现不符合要求的地方，立即纠正，保证数据的准备质量。

输出：《基础数据准备表》《编码规则表》

(1) 实施人员可以结合软件的系统要求，对编码规则、基础数据准备的内容提出建议，但不要替用户去准备，以免将来出现问题时无法分清责任。

(2) 基础数据的准备时间长短、数据的质量直接影响项目的进展，要提醒客户高度重视。

1.4.3 工作准则拟订

目标：通过业务模拟，确定系统的操作规程、数据备份制度等，作为指导系统正常运行的依据。随着用户对软件了解熟悉程度的加深，二次开发功能的增加，由用户来不断完善，实施人员可以指导，最终形成一个适合用户的 ERP 系统工作准则。

输出（不限以下内容）：

角色：实施经理、用户方项目实施小组

要求：

(1) 我方项目实施小组可以首先制订出一个大纲，然后指导用户实施小组和职能组在这个大纲基础上不断完善，但不要完全代替用户编制；

(2) 工作准则应做为项目最终验收的成果之一，要求用户必须编制。

1.4.4 系统初始化

目标：系统初始化数据初始完毕，数据准确、符合系统要求。

任务：

(1) 整理初始化设置文档在初始化之前，需要准备一份《系统初始化设置文档》。设置文档是项目实施中一份关键文档，必须要完成，有以下作用：.

• 确保设置正确。如果没有一份书面文档，一面想一面设置，容易出错。
• 更正有依据。设置完成后，万一出现问题（系统出错、或有人更改了设置），可以查看设置文档，很快进行修改。

对客户来说，文档是知识的积累和转移。在客户分子公司较多时，需要先试点后推广，有了设置文档，推广工作就可以节约很多时间。

(2) 录入静态数据由实施人员按照数据准备表，指导用户进行静态数据的录入工作，一定要保证数据录入的正确性和完整性。

(3) 录入动态数据在静态数据录入完毕之后，由实施人员按照数据准备表监督指导动态数据的录入工作，一定要保证数据录入的正确性和完整性。

(4) 确定系统参数在跟用户充分讲解系统参数含义，使客户完全理解含义后，确定系统参数。一旦确定，不得允许一般人员任意改动，也不赞成实施人员随意改动数据库。

(5) 核对数据基础数据输入系统之后，下面工作就是要核对数据，核对方法可以是从 ERP 系统把数据以各种方式输出，和输入的数据进行核对。

输出：《系统初始化设置文档》

(1) 在客户准备好并录入各种基础数据后，比如物料目录，各类期初余额，必须让用户签字确认，以免发生数据不准确时客户方领导对程序产生质疑的情况；

(2) 在初始化之前，必须给用户详细讲解各模块系统参数设置的含义和初始化的意义，因为有的参数一旦使用，将不允许再随意修改，所以必须提醒用户慎重使用某些软件功能；

(3) 如果为了节省初始时间，实施经理需要通过 PB 等工具或开发程序来帮助用户导入基础数据时，必须验证导入后数据的正确性，并且考虑风险。

1.5 系统并行（System Concurrence）

在该阶段主要完成的任务:试运行、系统并行、系统切换。

1.5.1 试运行

目标：系统初始化完成后，完成系统启用月份的业务录入。

任务：实施小组指导最终用户完成系统启用月份的业务录入，并随时解决运行中出现的问题。

要求：

(1) 为了减少实施风险，在系统试运行之前必须进行充分的实战性业务模拟和软件功测试；

(2) 在该阶段可能会暴露出许多问题，实施经理应重点关注用户业务流程在系统中的实现程度，分清问题轻重缓急；

(3) 对于分子公司较多的用户，一定要先做好试点，提炼出一套可复制的实施方案后，再逐步推广。

1.5.2 系统并行

目标：保证手工帐或老系统跟新系统数据的一致性，现行业务严格按照流程及时、正确地录入，及时解决运行中发现的问题，使系统逐渐稳定运行。

任务：

• 巩固强化培训操作 指导用户方项目实施小组以工作准则与规范为教材对最终用户进行反复的强化培训，保证最终用户按系统岗位职责熟练操作与自身业务有关的功能。
• 系统维护保障 对系统运行中新发现的问题通过现场维护、电话、E-MAIL 多种方式及时解决；保证新系统的稳定。
• 操作规程完善 在系统并行期间，指导用户完善操作规程，最终形成一套适合用户自身需要的业务管理制度。
• 二次开发程序调整、测试 对于二次开发后的程序，在系统并行阶段要做好流程的调整、程序测试工作。

输出：《系统阶段总结报告》

要求：

(1) 在这个阶段，项目组成员可以在适当的时机，部分撤出客户现场。并在适当时间，由项目实施经理与项目经理共同向用户提交、确认项目实施过程中的有关资料，确认合同中所列条款是否完成，是否还存在遗留问题。

(2) 在并行之前，要根据项目实施情况，做好切实可行的并行策略。并行会增加用户的工作量，应尽量减少并行工作时间，并做好最终用户的思想工作。并行时间越短，ERP 项目的成功率就越大。有几个方面原因：

• 并行时期，工作量是很大的，时间长了，业务人员都干疲了，甚至会对 ERP 系统产
• 生反感情绪。
• 并行时期业务部门一般都是先做旧系统，再做 ERP 系统，这时他们并没有习惯看
• ERP 系统的数据，而仍是以旧系统数据为准，所以 ERP 系统的数据有可能得不到及
• 时跟踪，时间长了，ERP 系统数据的垃圾会越来越多，甚至变成了一套无用的系统。
• 并行时期，为核对 ERP 系统余额与旧系统余额，必须指定截数点，将业务停下来进
• 行核对。当出现差异时还需调整，这是要花费一定的时间的，所以每月都会有补数、
• 录数的过程，相当于经常要将多天的工作压在一、两天内补做完成，如果月月如此，
• 业务人员会很累的。所以并行时间不能拖太长，最好不要超过三个月。

1.5.3 系统切换

目标：确认系统输出的结果正确无误，能够满足业务处理的需要，可以完全或部分甩掉手工帐或老系统，新系统独立运行。

任务:检查各个系统的运行情况，符合切换标准的可以甩手工帐或停止使用老系统。

输出:《项目运行情况总结报告》《系统切换标准》

角色：双方项目实施小组

要求：在系统切换前，要全面检查系统的运行情况，并进行总结，制订系统切换标准，可以分系统分步骤的逐步进行切换，最终停止使用手工帐或停止使用老系统。

1.6 项目结束(Project end)

1.6.1 项目验收

目标：阶段实施或总体实施结束，双方在验收报告上签字。

任务：

(1) 实施总结：要与用户共同形成；

(2) 组织成立验收小组；

(3) 验收准备：验收内容与验收标准（包括：系统目标、需求分析与规格说明、用户应用报告、文档规范与完整情况等）、验收小组、验收方式、验收程序等；

(4) 组织验收；

输出：《阶段验收报告》《项目总体验收报告》

角色：双方领导小组、项目实施小组主要成员

要求：在验收前，用户可能会提出一些问题和需求要求在验收前解决，但不要承诺所有问题都在验收前解决,可以跟用户协商哪些是验收前必须解决的,哪些可以验收后通过正常升级维护来解决,跟用户书面确认；当然,有关问题和需求要首先跟软件经理沟通一下,考虑自身的开发能力,不要轻易承诺，必要时可以考虑我们商务人员出面协调。

1.6.2 售后交接

目标：项目总体验收后，项目经理组织项目组成员完成与售后维护人员的交接，标志项目实施结束，进入项目售后维护阶段。

任务：项目总结、项目资料存档、把该项目的所有文档整理后，交项目信息员存档。项目经理应把该所负责项目的用户联系方式、所用产品、网络配置、帐套设置、是否为特殊版本、做了哪些特殊改动等情况详细整理，单独形成文档，以便于服务热线、事业部开发人员、大区技术人员售后维护。

输出：《项目实施总结报告》《 项目情况一览表》

角色：项目经理、售后维护人员

2 项目管理(Project Management)

项目管理贯穿于项目的整个生命周期，对项目的整个过程进行管理。主要包括范围管理、时间管理、沟通管理、质量管理、费用管理、风险管理、人力资源管理、档案管理、交接管理、变更控制。

2.1 范围管理(Scope Management)

目标：使项目在合同和双方认可的范围完成。

任务：

(1) 确定实施范围。在合同的基础上，通过在实施规划阶段的制订实施方案、现场调研、制订实施计划等活动进一步明确实施范围，项目经理应特别注意以下几点：

• 需要实施的单位是否明确

如果客户有分子公司，需要明确分子公司是否需要实施，因为多实施一个单位，我方的实施成本就会增加；要每个单位要实施几套帐是否明确。因为客户可能因为各种原因，一个单位有几套帐（单位名称是一个，但却有几套帐），对于实施人员来说，多实施一套帐，就会造成工作量成倍增加，实施周期延长，维护成本也相应增加。每个单位的安装模块名称及站点数是否明确。不同的单位、不同的帐套安装的模块数和站点数可能会不同。

• 明确二次开发范围

如果合同中饭明确规定需要做部分二次开发，在调研后必须以需求报告形式确定二次开发范围和工作量，实施过程中必须严格控制二次开发在需求报告范围之内，如果实施过程中，用户提出需求报告以外的需求，需要根据工作量大小决定是否单独另外收费。

(2) 控制范围变更范围变更的原因是多方面的，比如用户要求增加新功能、用户组织结构调整导致实施单位需要重新建帐初始化等。项目经理在管理过程中必须通过项目阶段总结报告等来分析和预测可能出现的范围变更，在发生变更时遵循规范的变更程序来管理变更。

2.2 时间管理(Time Management)

目标：控制项目的整体进度，保证项目按计划完成。

输出：《项目实施计划》《项目周报》《项目阶段总结》《项目实施总结报告》

要求：

(1) 项目经理应制订出切实可行的实施计划，并在执行过程中进行跟踪与控制，对计划完成情况要注意自查，对计划没有完成的原因必须进行自我分析，计划变更后要注意调整总体实施计划；

(2) 项目经理要充分考虑影响项目进度的各种因素，并根据优先级,分清轻重缓急,排除不良因素的干扰，保证项目实施的平稳进行；

(3) 为全面了解项目的真实情况，为下一步工作或验收做好准备，项目经理要定期（比如：项目基础数据初始完毕，业务处理进行一段时间后，验收前等）到企业的各个部门全面了解产品的实施情况，认真收集关键用户和最终用户的意见，不要一味的依靠实施人员的口头汇报和用户计算机中心人员的反映；

(4) 项目经理应在每个项目阶段结束后向事业部和用户的项目领导小组以书面形式进行阶段总结，汇报项目进展情况、存在问题及下一步计划，使公司和用户了解项目的进展情况；

(5) 对于二次开发的内容，项目经理要主动与软件经理协商二次开发的解决方案、解决时间，并要求软件经理定期汇报二次开发的计划及完成情况，并定期向用户方项目经理通报二次开发的完成情况，尤其是对于双方可能会产生意见分歧的二次开发内容，一定要跟客户早沟通，双方确认后再进行二次开发，避免和减少客户的需求变更。

2.3 沟通管理(Communications Management)

目标：通过交流与沟通，使合同关联方各个层次的人员之间以及项目组内部，对项目本身以及项目实施过程出现的问题达成共识，建立相互信任的合作关系，共同推动项目的进展。

任务：

(1) 制订沟通计划为避免沟通管理的混乱，在实施计划制订后，项目经理需要编制《项目沟通计划》，作为沟通管理的指导性文档。其中应该确定哪些信息需要沟通（沟通内容，比如用户需求的反馈、紧急问题的反馈、阶段报告、计划变更等），在什么时间（沟通时间）将信息提供给什么人（沟通对象），以及如何将信息提供给他们（沟通渠道，如电子邮件、传真、个别交谈及现场管理等），正式的交流都应该留有文档.

(2) 执行沟通计划按沟通计划中的内容执行,并将信息准确、及时的发送到相应的沟通对象；要注意在项目过程中及时关注项目中出现的各种问题和冲突，如果是由于沟通不利造成的或者是可以通过良好的沟通解决的，应及时修改相应的沟通策略。

输出：《项目沟通计划》《项目阶段总结报告》《备忘录》《会议纪要》《项目周报》

要求：

(1) 项目经理可以与用户方项目组每周五下午举行一次项目例会，共同探讨项目实施中遇到的问题，协调资源，安排下周计划。

(2) 做为与公司内外沟通的主要方式之一----《项目周报》必须认真填写，对于对外周报应要求用户方项目经理签字确认，对内周报应由项目经理编制，一般周五下午报送项目周报，最迟周一上午必须报送给项目信息员，同时抄送软件经理和相关行业产品经理。如果项目经理不在客户现场，可以委托实施经理负责编制项目实施周报，但项目经理必须最终审核并上报。

(3) 在每一个相对阶段结束后，项目经理应填写阶段性项目总结报告，具体时机项目经理或实施经理可以根据实际情况把握。月末要向本部门项目信息员报送项目预算计划、回款计划。

(4) 对于项目实施过程中发生的重要事件，比如：

• 用户没有在规定时间内整理好基础数据，从而影响实施进度；
• 项目经理认为某项软件功能，受各种因素影响，用户暂时无法使用，但用户方坚持使
• 用；
• 用户方部门结构调整或对方项目领导小组成员发生变动，从而可能会影响项目进度；
• 双方因为某些观点或想法存在严重分歧，最后经过协商达成一致意见；
• 项目经理应该及时通过备忘录形式详细记录该事件，将来双方如果发生意见分歧或合同纠纷时，可以备查，在必要时，可以以公司的名义向对方发公函，要求对方确认事件。

项目经理应注意协调解决项目组其他成员遇到的各种困难和问题，鼓舞士气，定期召开座谈会，了解项目组成员的想法，使项目团队保持昂扬的斗志，努力为项目组创造良好的工作环境。

(5) 项目经理要经常提醒项目组成员，不要忽视最终用户的感受，最终用户是系统的具体操作者，他们的工作积极性、对系统的认同程度，对项目的顺利实施会起重要作用。

(6) 项目经理要多跟用户的项目负责人、一线人员宣传我们的开发流程、项目实施流程，让用户了解、认同我们的做法，并且要多站在用户的立场想问题，加深用户对我们的信任和理解。

(7) 项目经理、实施经理、软件经理要注意了解客户最希望解决的问题是什么，抓住客户的关键流程，分清问题的主次，先解决客户最棘手的问题，多站在用户的立场进行换位思考。

(8) 项目经理及所有项目组成员在实施过程中既要与用户保持良好的合作关系, 又要维护公司的形象和利益。

2.4 风险管理（Risk Management）

目标：避免或降低项目风险，减少风险发生时对项目的影响，保证项目实施成功。

任务：

(1) 风险识别识别潜在风险是一项十分关键的任务，项目经理必须花费足够的时间，高质量的完成这项任务。根据项目的性质，从潜在的事件及其后果、潜在的后果及其产生的原因来检查风险，按照风险的特征进行归档，评估风险对项目在整体上产生的影响，包括：影响范围、持续时间，对项目质量可能造成的损害、解决风险所需要的资源和成本等，然后收集、整理可能风险形成项目风险列表。

(2) 风险分析

识别出潜在的风险后，需要分析风险发生的可能性，评估风险对项目的影响程度，风险在什么程度上是可控的？依据可能性与影响评定优先级。

风险等级：

A 级——有机大可能发生风险，并且风险一旦发生对项目将造成致命影响。

B 级——很可能发生风险，或者风险发生后会产生严重后果。

C 级——有可能发生风险，风险发生后对项目产生影响，但不会造成项目停滞。

D 级——风险发生可能性不大，或者风险发生对项目的影响很小。

E 级——几乎不可能发生，或者发生风险对项目的影响及其轻微。

(3) 风险对策根据风险性质和项目对风险的承受能力制定相应的防范计划，即风险应对。制定风险应对策略主要考虑以下四个方面的因素：可规避性、可转移性、可缓解性、可接受性。风险的应对策略在某种程度上决定了采用什么样的项目实施方案。对于应“规避”或“转移”的风险在项目策略与计划时必须加以考虑，例如使用稳定成熟的软件，抽调有经验的人员进项目组，由代理商承担售后维护服务等。

(4) 风险控制制定了风险防范计划后，风险并非不存在，在项目执行过程中，需要时刻监督风险的发展与变化情况，并确定随着某些风险的消失而带来的新的风险。风险控制包括两个层面的工作：一是跟踪已识别风险的发展变化情况，包括在整个项目周期内风险产生的条件和导致的后果变化。二是根据风险的变化情况及时调整风险应对计划，并对已发生的风险、遗留风险和新增风险及时识别、分析，并采取适当的应对措施。对于已发生过和已解决的风险也应及时从风险监控列表调整出去。 最有效的风险监控工具之一就是“前 10 个风险列表”，它是一种简便易行的风险监控活动，是按“风险值”大小将项目的前 10 个风险作为控制对象，密切监控项目的前 10 个风险。每次风险检查后，形成新的“前 10 个风险列表”。

输出：《项目风险列表》

要求：项目经理和实施经理必须要有风险管理意识，注意参考以上提到的风险种类，识别出项目实施过程中的潜在风险，发现后及时提出解决措施。要与用户创造一种共担风险、共享成功的氛围。

2.5 质量管理(Quality Management)

目标：保证项目实施质量、开发质量满足指定标准。

任务：

1） 编制质量标准：包括整理制定与项目有关的质量标准和规范，用户需求描述，软件实现的功能及特色，输出结果，软件可靠性核可维护性；

2） 建立质量保证体系：项目质量管理需要规范化、制度化，对项目进行整体绩效的预先评估，监控特定的项目结果如出具各里程碑监督报告，完成某个项目任务后应提交方案、计划、技术文件、管理文件、总结、报告等文档。

3） 树立质量管理意识：质量管理不是某个人或几个人专门负责的事情，而是与全体项目组成员的工作密切相关，项目经理要不断给双方项目组成员灌输质量管理意识。

输出：《项目质量管理标准》

要求：

(1) 建立质量管理标准。在项目规划阶段，项目经理必须跟用户方项目经理协商，建立双方认可的项目质量管理标准，并在实施过程中严格执行；

(2) 推行任务单管理制度。项目经理可以在实施过程中推行任务单管理制度，由项目经理给组员下达任务单，完成任务后经客户签字后上交给项目经理，对没有上交任务单者视为未完成；

(3) 建立问题反馈和报告机制。以减少信息的中间传递环节，确定问题的反馈方式和流程，对于问题的结果要及时跟用户沟通，使问题能最短的时间内解决，不要隐瞒，不要回避，不能报喜不报忧；每个阶段结束后，项目经理必须向部门主管领导、用户提交阶段总结报告，并同时抄送项目信息员、软件经理；

(4) 建立问题台帐。对于二次开发功能、补丁程序在正式使用前，实施经理必须先做测试，测试合格后再更新到客户所有工作站，保证所有工作站程序的一致，建立并登记项目问题台帐；

(5) 建立用户签字制度。如果在规定的时间内没有解决问题和需求，一定要跟用户解释，取得用户的谅解，对于需求或重要问题解决后，一定要让用户确认后书面签字；对关键点必须让用户书面确认或以备忘录形式记录；

(6) 指导建立系统维护制度。在项目实施前期，实施经理要指导用户建立完善的数据安全备份和系统权限管理制度。并要求对方专人负责。

(7) 实行分阶段分模块验收。由于项目实施的模块一般都比较多，涉及用户部门也比较多，为了便于项目成果的尽快体现和项目合同款的及时结算，项目经理要注意把握时机，进行分阶段分模块的验收，比如财务系统运行一段时间比较稳定后，可以考虑先进行财务系统的验收，物流系统运行比较稳定后，再跟用户协商对物流系统的验收，实践证明，分阶段的验收比项目实施完成后，再进行总体验收，效果会更好一些。

2.6 人力资源管理(Human Resource Management)

目标：保证所有项目关系人的能力和积极性都得到最有效发挥和利用。

范围：项目组织的成立、组织规划、项目团队建设等。

任务：

(1) 组织成立项目小组项目经理应对项目组成员角色提出需求层次，确定实施过程中项目组成员的安排,并根据不同阶段会同实施经理提出实施人员的增减要求，让已经完成任务的人员及时退出或暂时退出项目组，避免人力资源和成本的浪费；对用户需要明确其项目组成员，并要求对方确保对实施项目的时间投入；

(2) 组织实施人员按计划和各自分工实施项目经理应明确项目组成员的职责分工，明确协作方式，并且要使项目组成员愿意为该项目服务，通过实施该项目能得到能力提升，体现出个人价值；对项目小组以外的相关人员，及时通知、落实配合工作的时间、人员、目标。

(3) 搞好项目团队建设，做好交流沟通工作团队建设活动包括为提高团队运作水平而进行的管理和采用的专门的、重要的个别措施。例如：尽早明确项目团队的方向、目标和任务，同时为每个人明确其职责和角色；邀请团队成员积极参与解决问题和做出决策；积极放权，使成员进行自我管理和自我激励；增加项目团队成员的非工作沟通和交流的机会，如工作之余的聚会、郊游等，提高团队成员之间的了解和交流。这些措施作为一种间接效应，可能会提高团队的运作水平。团队建设活动没有一个确定的定式，主要是根据实际情况进行具体的分析和组织。

(4) 做好绩效考核与激励工作绩效考核是通过对项目团队成员工作业绩的评价，来反映成员的实际能力以及对某种工作职位的适应程度。激励则是运用有关行为科学的理论和方法，对成员的需要予以满足或限制，从而激发成员的行为动机，激发成员充分发挥自己的潜能，为实现项目目标服务。项目经理应按项目考核办法中的规定做好对项目组成员的工作评价工作，并做到公平、公开、公正。

(5) 建立内部培训机制项目组中，每个人掌握的技能都是有限的，从项目成本出发，项目组的每一个成员不可能都是具有同样高水平的，肯定是分层次组合的，这就需要项目组建立内部培训机制，使项目组成员尽可能的做到一专多能，这样既减少项目成本，也会降低因项目组成员变动而带来的风险，同时使项目组成员不断得到能力提升。

2.7 费用管理(Cost Management)

目标：使项目成本控制在总体预算内。

2.8 档案管理(Records Management)

目标：项目实施和管理过程的完整记录。

作用：

• 帮助项目人员规范信息的保存、流动以及能及时得到帮助或指导；
• 以备事后对历史情况的查询或回顾，解决纠纷的重要依据；
• 项目经验教训的书面记载；
• 项目人员变更时的工作交接；
• 项目验收时的重要成果之一。

任务：项目经理应收集、整理与项目有关的所有资料, 建立完整的档案目录，项目结束之后，所有项目文档必须交项目信息员存档，一是供查询；二是作为公司知识库的组成部分。

输出：项目生命周期的所有技术和管理文档。

要求：

(1) 项目经理要注意内外有别，对于内部文档、机密文档应严格保密，不要让无关人员查阅；

(2) 文档编写工具：文档使用 Microsoft Word 编写、报表使用 Microsoft Excel 编制、计划和日程安排使用 Microsoft Project 编写、各种流程图使用 Microsoft Visio编写；

(3) 双方项目经理要指定专人负责项目档案的整理存档，建立完整的项目档案；

(4) 重要的项目文档必须要求用户方项目经理签字甚至盖章，对于重要的邮件也要作为文档进行存档备份

(5) 项目经理应定期在指定的公司服务器目录上将项目文档存放；

(6) 在项目结束后，项目经理应将所有项目技术和管理文档（包括电子和书面文档）交由项目信息员统一存档保管。

2.9 变更控制( Change Control)

任务：

(1) 制定规范的变更控制流程 项目经理应考虑如何控制各种变更，制订出规范的变更流程。

(2) 进行变更影响分析 一定要让用户意识到各种变更对项目进展所带来的影响。

(3) 对变更理由进行评估

• 是否有必要变更
• 是否能够变通实现
• 如果不变更会对项目带来何种影响

(4) 变更申请与评审 项目经理应根据变更的内容，向能处理变更的相关人员提交变更申请单或变更申请报告；

(5) 变更执行 变更通过后要及时通知公司有关部门，按变更后的内容执行；

输出：《项目变更流程》《变更申请单》《变更评审记录》《项目问题需求反馈表》

要求：

(1) 对于需求变更，要想把其范围控制到最小，必须从一开始就要充分调研，明确项目需求、目标、约束限制，并要求书面确认；在实施过程中项目实施小组要注意控制用户的需求在二次开发的范围和工作量之内；要分清哪些是合理需求，哪些是不合理或者意义不大的需求，不能用户要求什么我们就做什么，该说‘不’的要说‘不’，当然要注意沟通技巧；

(2) 对于确认是合理的需求，在实施方面确实无变通的解决办法，可以书面记录该需求，并要求用户方项目经理和提出者签字确认，然后按反馈流程反映给软件经理或相关维护部门，但是在没有跟开发部门协商之前，项目经理或实施经理不要向用户承诺在什么时间一定能解决，以免在承诺期内没有解决，从而给实施工作带来被动；

(3) 要让用户充分理解因为需求变更或对方部门结构调整、人员调整等事件会更整个项目进度带来的影响，并且应该以书面形式加以记录；

(4) 如果项目发生比较大的变更，造成项目无法按计划推动下去，经相关领导批准并跟用户协商后，可以暂停项目实施，让实施人员完全或部分撤出用户现场，减少不必要的成本支出。

2.10 交接管理(Connect Management)

目标：保证项目工作的连续性，使项目不因当事人的变动而中断，始终处于可控范围内。

范围：项目售前经理和项目经理之间的交接、项目组成员变更而进行的工作交接、项目验收后项目经理与售后维护人员进行的交接任务：

• 做好项目启动前，售前经理与项目经理之间的交接工作；
• 做好项目组成员变更而进行的交接工作；

项目组成员，尤其是项目组主要成员因为工作变动或其他原因，中途退出项目组，必须做好项目书面交接工作，使后来者尽快熟悉项目情况，进入角色；(3) 项目验收后项目经理与售后维护人员进行的交接。