CRP实施方法论

本文转载自：https://blog.csdn.net/Jasper2008/article/details/4698339

CRP的名词解释，摘自ORACLE AIM 3.0 的用户手册 A75149-01的第G-10页：
Conference Room Pilot (CRP): A system test in an environment set up to simulate the future production environment.
在ORACLE AIM 3.0 的用户手册 A75150-01的第3-89页，对CRP进行了更为详细的描述：# d' q) i7 V, Z5 T  n* J" x, I
You can perform testing of business alternatives in a formal conference room pilot (CRP) or use a more informal approach as a follow-on to mapping activities. In either case, you must test around any identified functionality gaps because it is likely that no final alternative has been designed or built to bridge those gaps.& a9 R  F1 m" D. f4 y
A CRP is a technique for evaluating a proposed alternative that simulates actual business processes in a controlled environment. It is often performed in an actual conference room so that all participants will be close together and delays will be minimized. A CRP can reveal missed problems and issues of processes tested in isolation.4 k' q& m. G5 v9 ^
A conference room pilot is usually run by business area or some other, wider grouping of business processes. This means that multiple mapping teams must be ready at the same time in order to begin. As with most testing strategies, a CRP consists of iterations, converging on a practical and feasible alternative. Once all testing is complete and confirmed, you can document final setups and selected alternatives.

这段文字解释了CRP的含义、执行方法，以及它的结果。

什么是CRP（会议室导航）?

CRP用于帮助项目组建立业务流程模型。通过CRP还将发现软件与现实的差异（gap），并进一步调整软件配置。CRP的焦点是理解软件，以及组织、制度需求。
在CRP过程中，项目组会按实现业务中可能出现的数据演示功能与流程。CRP关注于按步骤展示：新系统如何实现当前业务流程。 包括与案例有关的所有界面、报表、程序，并得到用户对系统的建议。这一过程将反映以下问题，并形成文档:

• 软件与需求差异
• 对组织的影响
• 对制度与业务流程的影响
• 安全性问题
• 审批与监控机制
• CRP完成后的修改措施，项目仍然在设计阶段。

CRP将确保组织为将要使用新系统带来的变化做好准备。此外，CRP也会反映出未来支持与培训中的一些需求。

CRP可以创造性的解决一些问题，以满足各方需求。例如，软件的功能差异，即CRP参与者想象中的业务流程运作方式与软件能力之间的差异。要解决这个问题，要么变更流程，要么修改软件。因此，开放的沟通环境非常重要，需要管理人员、功能人员、技术人员、开发团队与用户代表的介入。同时，所有参与者都必须能开放的接受改变业务方式与流程，以实现项目总原则——不对软件做功能开发。

在CRP前，项目组要接受系统培训，以理解系统的界面、路径，从而关注于最终业务人员如何使用系统。此外，所有参与者都需求经过CRP过程及概念的 培训。CRP不是用户培训，系统测试，或对最终系统的精确演示。CRP是系统设计阶段的一个环节，项目小组由此得到用户反馈。

当CRP完成后，项目组可以形成：完整的业务流程图、对所有软件差异的汇总，以及如何通过特定的方法解决差异、需求、业务流程报告。认真管理与执行CRP是项目成功的关键，因为CRP的反馈体现了对业务需求的详细理解，将指导系统实现。
CRP不是...

• 用户培训环节。用户不用在自己的电脑上一步步的跟着做。
• 大规模的数据转移过程，将大量正式业务数据导入CRP环境。
• 应用开发联系会议(JAD) 或是原型的建模过程。不要在会议中讨论或配置系统值、代码。
• 项目组毫无准备开会。在CRP之前可能的流程、初始配置都要准备好。
• 系统测试或是详细功能演示。参与人要清楚项目还处于设计阶段，想要得到的是关键问题的反馈。

CRP 是...

• 预先编写好脚本，妥善准备好的工作。.
• 项目组用预先配置好的系统，用多个真实的业务情境，演示软件功能与流程。
• 用小规模的样本数据做演示。通常这些数据只要手工录入。
• 向用户提出问题，并收到关于预想中的。
• 找出需要在CRP结束后解决的功能差异、业务制度中的关键问题，并编制出文档。

 

在AIM用户手册中，这段文字出现在 Business Requirement Mapping 一章中，这么说，ORACLE 是把 CRP看作AIM方法论中某一阶段的一种技术，而不是一种独立的方法论。

那么，为什么业界一直在说CRP实施方法论呢？

抛开争议，既然业界认可CRP实施方法论，而且我们过去不少项目及将来不少项目都用CRP实施方法论，那么，我们不妨暂时抛开“CRP是不是独立实施方法论”这一争议，暂时不管AIM中的说明（我们只引用它对CRP三个字母的名词解释），先认可它是一种独立的实施方法论，试着整理一下它的知识体系。
我本人在2001年开始接触CRP这个名词，那时是在杭州，从松下的日方实施人员口中听说的，在那之前，我只知道 Quick-HAND方法论。由于语言方面的原因，开始阶段没搞明白CRP是什么东西，就跟着日方的意思做下去了。逐渐地，慢慢了解了这个名词，以及这种实施方法。
有一种说法，说CRP是相对于“传统”实施方法论而言的。这种说法把“传统”实施方法定义为“调研 → 蓝图设计 → 实现 → 测试 → 上线”几个步骤，而把CRP定义为“CRP1 → CRP2 → CRP3 → UAT → 上线”，表现看来，差别似乎是，CRP节省了长期的调研和蓝图设计阶段，不用编写解决方案。依我看来，这种说法并不准确，要想做好CRP，并不能完全排斥调研，也省不了蓝图设计（比如追加开发的内容，没有调研和蓝图设计是不可能完成的）。我认为，它们的区别在于，CRP强调“标准模板”，即在实施之前就有一套“标准模板”，在实施过程中，以“量衣裁体”为主，必要时改改模板；而“传统”实施方法则是“量体裁衣”为主，改要时改改体形。理论上讲，任何项目都可以使用任何一种实施方法，只是效果不同，没有绝对的优劣。
根据我的理解，可以把CRP定义为“一种以CRP手段为核心的实施方法论”，这里所说的“CRP手段”，就可以引用ORACLE AIM用户手册中那几百字的文字说明了。
比照AIM，CRP实施方法论应该有如下知识体系：
1) 实施阶段的划分；
2) 每个阶段的目的、任务清单、工作方法说明、成果物；
3) 成果物模板；
4) 实施团队的组织结构。

 

【阶段划分】
实施过程中包括哪几个阶段？要完成哪些任务？根据我个人的经验，将其归纳在如下表格中。
在以上表格定义的阶段中，CRP1、CRP2、UAT、GoLive四个阶段是必需的。
如果CRP2之后，仍然有不少待解决和验证的差异，不能进入UAT阶段，那么，可能需要执行CRP3，甚至CRP4。这种情况的出现，会对项目管理产生较大的风险，因为通常在项目筹划时，不会预先留出CRP3、CRP4的时间，在CRP2之后增加这些阶段，可能会导致项目延期。因此，在实施过程中，要努力提升CRP1、CRP2的效率和效果，避免中途增加CRP3。CRP1特别好的情况下，CRP2可能也会被跳过。
如果对客户的业务情况及需求不甚了解，不清楚在CRP1中会产生多少差异，建议在CRP1之前设置一个Pre-CRP阶段，对客户当前业务及需求进行调研，如果得到允许，可以根据调研结果，适当调整将要用于CRP1的模板。如果在CRP1时发生许多重大差异，会降低用户对模板的兴趣，甚至在争论中产生抵触情绪。[c4（要确保模板中的每一项规定都是“合理”的，这个“理”，可以是总公司或客户高层的统制思想，可以是行业经验，但不可以仅仅是“系统如此”。）]
集团公司实施一套统一的系统时，通常需要根据集团的业务特点，制订一套模板，而不是把系统标准功能或相似企业的经验资料直接拿来进行实施。（让一个大集团照抄其他公司的标准，或者强推系统功能，是伤面子的。）这时，就会多出一个“Template”阶段。也有的集团在实施时，选一家子公司，一边实施，一边做模板，这样的方法，看起来好像会减少总的实施周期，并且避免模板严重偏离业务现实，但是，它会使得模板中有过多的该子公司的个性化影子，对后续的推广不利，因此，我个人不喜欢这种模式。我喜欢设置一个相对独立的“Template”阶段，从全局角度制作模板（这时，要防止“闭门造车”式的模板制作方法，如果你弄了一辆起重机当模板去轿车厂做CRP，等着挨骂吧）。

 

【阶段定义】

Template

CRP实施的核心工具是“业务模板”，有时也称为“标准模板”、“标准”、“全球标准”（集团公司喜欢这么叫）。它是一套设想中的、理想的业务规范，实施人员（包括客户高层管理者）认为，企业按照这样的规范做业务，可以达到优秀的经营目标。当然，这是“理想”，毕竟每个企业都有自己的特殊点，有些特殊点甚至是企业生存、获利的关键，CRP就是标准与个性的磨合与相互妥协的过程。
Template 阶段就是要制作这个“标准模板”，关于制作的方法及注意事项，后面会有详细的论述。

Pre-CRP

如果不清楚企业的当前业务、期望，对标准模板的匹配程度心中没底，则有必要设置Pre-CRP阶段，对企业进行调研，对模板进行必要的调整。

CRP1

将模板与企业实际业务和期望进行对比，寻找差异，并确定差异的解决方法。关注如下三个方面：

 1) 模板中描述的业务处理规范，与企业当前处理方法相比，有什么不同之处？对于不同点，企业能否采纳模板规范？

2) 模板中有哪些业务是该企业目前不存在，且将来一定时间内也不会出现的？

 3) 企业的实际业务中，有哪些是模板中未涉及的。

对于不同点（即差异），处理原则为：
1) 企业接受模板中的规范。
2) 企业保留自己的个性特点，模板也不予对应。
3) 该差异在集团中具有一定的共性，按企业需求修改模板。

在这个阶段，还要包括如下任务：
1) 向企业用户（主要是参与CRP1的关键用户）讲解系统基本概念，并通过CRP分析，让他们了解系统的基本操作。

2) 确定要移行的主数据（也称为静态数据），发出数据收集表，请关键用户安排人员开始收集主数据。
3) 如果差异解决方法中涉及补充开发，在确定开发需求后，开始着手进行功能设计、技术设计。原则上，所有的补充开发应在CRP2中进行测试。

CRP2
CRP1中的差异均被解决之后（补充开发可以稍晚），开始CRP2。

CRP2的重点是验证差异的解决方案，如果在开始时有的补充开发尚未完成，可以在上半阶段验证标准功能部分，下半阶段验证补充开发功能。

要注意的是，CRP2中不可以只测试差异部分，而是要测试全部业务，以避免差异解决方案对原来无差异的业务的影响。与CRP1的区别是，对于CRP1中无差异的业务，只要测试结果与CRP1时相同，就无需再关注。

CRP2中可能还会出现一些新的差异（包括CRP1差异中解决方案不合适的部分），CRP2结束后要对差异进行一次判定，如果认为差异对业务的影响可以接受，则进入UAT阶段，否则，要插入CRP3阶段。

在CRP2中，对于已确定的业务规范，要开始着手对最终用户进行培训，包括学习新的业务规范、学习系统操作。

UAT
UAT（User Acceptance Test），也称作试运行。

UAT开始前，主数据应该已经整理完毕，并且使用与上线时相同的方法，输入到系统中。

在UAT中，模拟上线情况，对企业全部的业务进行测试。虽然测试仍以业务为线索，但是UAT中除了关注业务外，还要关注各个部门、用户之间的配合程度，关注主要的单据和报表在实际业务中的适用情况。

UAT既是测试，也是部门、用户之间的磨合。

UAT结束后，要进行上线判定，考虑如下几个方面：

1) 系统对业务的处理步骤和结果，是否可以接受？

2) 余留的差异，对企业的运营影响，是否足够小？

 3) 部门、用户之间的配合是否流畅？

4) 报表、单据是否适用?

 5) 上线所需的主数据是否准备完成？

 6) 上线切换计划是否可行？

如果企业最终不能成功使用新系统，则前面各阶段的工作将付诸流水。我们必须纠正“重方案、轻上线”的做法，鼓足最后一股劲，确保企业上线成功。

当截止UAT的各个阶段均顺利完成时，上线的成败主要取决于上线计划的合理性及执行力。一份列出了上线全部明细任务的清单是非常有帮助的，清单上要列出各个任务的说明、工作量、负责人、开始时间、预计完成时间、复核人等。对于初次负责项目上线的PM，简单把别人或其他项目上的资料拿来复制一份是不够的，应该请有经验的高级顾问帮忙把把关。

这个阶段还应包括上线切换完成后第一个月的业务处理支持、月结支持（个别不采购这项服务的项目除外）。

(按CRP实施一个项目，需要完成多少文档？各个具体的项目，答案会有些差别。在这一切，按我个人的理解，列出一份文档清单。考虑到沟通上的方便，文档名称的编码尽量与AIM (版本3.0) 保持一致。

声明：本节的文档规则仅为我个人的观点，未得到任何官方的认可，它可能与某些公司、某些人的规则或习惯有冲突。

 

建议的文件名规则：

项目英文简称_(子项目英文简称)_文档编号_文档说明_区分字符_版本.后缀

其中“子项目英文简称”是可选项。

“文档编号”是CR010、MD050、DO070这样的代码；“文档说明”是一串简洁的英文单词，用于说明该文档的作用，如“SOA”、“Functional Design”、“User Manual”等。“区分字符”是为了使文件名唯一化而填写的，例如，项目中可能用多个DO070（操作手册），为了区分这些文件，可以使用模块名、业务名作为“区分字符”。

例1， 某项目英文简称为 HAIF，该项目上编写的关于金税接口的第一版功能设计书，可以命名为 HAIF_MD050_Functional Design_GoldenTaxIF_V1.0.doc。

例2， 某大型项目 MFO 按实施地点分为若干个子项目，其中某个地点的简称（子项目简称或公司简称）为AB，该项目编写的应付发票维护的操作手册第1.1版，可以命名为 MFO_AB_DO070_User Manual_AP Invoice Maintain_V1.1.doc。

强烈建议：避免在文件名中使用双字节字符，特别是在与其他国家人员合作的情况下，双字节字符在其他语言的操作系统上可能显示为乱码。

用WORD、EXCEL，还是其他？

MS OFFICE 用户众多，但也不排除某些企业内部统一使用WPS的情况，好在目前这些编辑器之间具有一定的兼容性，我们不必要针对客户的情况安装新的编辑器。然而，在项目之初，项目经理还是应花时间与客户方项目经理统一一下文档的格式，以使用MS OFFICE为例，有些企业喜欢用WORD，而有些企业则特别喜欢用EXCEL，确定好工具之后，还要确定版本，某些顾问比较喜欢新潮，总是安装最新版的工具，如果直接保存为 WORD 2007，则客户使用WORD 2003就可能打不开顾问所写的文档。 大家约定一个版本，高版本的用户，在保存文件时，请选择低版本兼容格式。(如果客户不喜欢尝试新的文档格式，没必要强求他们改变，顾问应该顺应客户在这方面的习惯。)

 

【项目管理】
1. CR010: SOA

上面的字符由两段组成，“:”之前的是“文档编号”，之后是“文档说明”。

SOA的全称是Scope, Objectives, and Approach，它定义项目的范围、目标、实施方法，确保顾问与客户双方在这些方面有共同的认识。这个文档应该在商务谈判阶段完成。双方就这份文档达成一致后，才开始具体的项目实施工作。

2. CR020: Regulation

在AIM中，CR020的说明是“Define Control and Reporting Strategies, Standards, and Procedures”，在CR020之外，还有CR030、QM010、RM010、RM025等文档，每份文档专注于一个目标，我感觉写这么多文档太麻烦（每份文档都要有一套封面、修改历史、目标等三页，实际内容可能只有一页，浪费），因此，除非客户要求严格遵守AIM文档体系（我还没遇到过），我就把这些内容全部写在CR020中，如项目成员结构图、汇报流程、作息制度、日常办公守则、会议制度、质量检查标准、文件服务器、信息安全，等等。

3. CM020 Document Control

列出项目实施所需的文档（输入），以及要完成的文档（输出）清单。如前所述，每个项目中的文档可能有所差异，项目经理要根据项目特点，确定项目清单。

有的商务合同中包括了“提交物”清单，但是这并非项目文档的全部。

项目经理应该在项目筹备阶段完成这份清单，清单中除了文档名称外，还要有时间（使用时间或完成时间），对于输出文档，要有模板。
项目经理要取得客户方项目经理对此文档的认可，然后交给全部项目成员，确保各成员对文档有共同的理解，避免风格不同的文档在项目上出现。

4. WM020:WBS5 _0

详细的项目计划，包括细化的任务说明、所需资源、起止时间、提交物等。MS Project 是制作与追踪WBS的专业化工具，但是它很贵，如果没有这个软件，可以考虑使用EXCEL，或开源的项目管理软件，有些开源软件与MS Project基本功能相当，甚至可以兼容MS Project的某种文档格式。

5. CR040: Risk Control

描述风险的处理流程，并包括一个风险处理模板，使用模板填写风险内容，以及建议的规避方法。

6. CR060: Change Management

描述变更管理流程（如业务范围的变更、开发完成后功能需求的变更等），提交包括一个变更处理模板，使用模板填写变更内容，以及对应变更所需要的估算工作量。

7. PJM11: Weekly Report

在AIM中，将PJM01 ~ PJM10 定义为项目管理的其他文档，我延用它的序列，从编号11开始，定义一些其他的项目管理文档。

Weekly Report，项目周报，填写本周工作的总结，整个项目的汇总周报由项目经理编写，项目经理可指定小组负责人，编写小组的周报。

8. PJM07: Period End Report

各阶段结束时的总结报告，如果要编写月度报告，也使用这个格式。
9. PJM12: Meeting Memo

会议纪要。
10. PJM02: Project memo
项目备忘录。

11. PJM13: Issues Sheet

课题台账。

在项目实施过程中，项目管理、业务、系统、资源等各方面出现的问题，为了防止被遗忘，应该把它们记录到课题台账中。

对于每个课题，要记录概述（标题）、说明（文字较多时可以使用附件）、影响程度、提出者、提出日期、期望的解决期限。

项目经理会同相关负责人研讨新课题后，确定课题的负责人。

课题的负责人应保持对课题进度的监督，及时更新课题的状态。

在课题被解决后，填写解决方法、实际解决日期。

原则上，由课题的提出者确认、关闭课题。

 

【业务调研及方案】

1. RD020: Business Research Questionnaire

业务调研问卷。

2. BP040: Current Business Model

描述企业当前的业务处理模式、客户对将来业务的需求。根据业务调研的结果，制作此文档。

3. BP080: Future Business Module

描述企业未来的业务处理流程。

4. BR100: Setups

记录系统的设置参数。
在AIM中，BR110用于记录系统安全相关的设置（如菜单、职责），我认为也可以把这些内容归入BR100的范畴。当然，有的客户也会坚持系统的常规设置与安全设置在文档编号上分开，以便分配至不同的部门或用户。

建议在CRP的各个阶段分别维护一份设置文档，以便事后返查。先确定设置文档，然后根据文档设置系统，是一种好的习惯，可以防止在设置过程中产生遗漏。

5. RD050: Business Requirement Scenarios

CRP脚本。该文档按业务流程编写，对于每个业务流程，说明要进行哪些方面的测试，例如，输入哪几种类型的数据、输出哪些报表、关键的确认点有哪些。

在执行CRP（如CRP1、CRP2）时，按此脚本逐一进行确认，并填写结果（形成文档BR030）。

由于各个CRP阶段的侧重点不同，因此，要分别制作每个阶段的RD050。（也有的人嫌麻烦，只制作一份RD050，然后，增加几列，标出哪些内容CRP1使用、哪些内容CRP2使用）。

有的项目中使用 TE040 编写CRP脚本，我的定义是，TE040专用于追加开发程序的测试（AIM的定义也类似），RD050是完整的业务流程测试脚本。

6. PT040: Performance Test Scripts

性能测试脚本。有的项目特别关注业务流程，却忽视系统性能。这对于业务量不大的企业，可能没什么影响，但是，如果企业每天都生成大量的数据、用户很多、工作地点分散、网络容量有限，就需要进行性能测试，以避免上线后系统界面打开缓慢、并发请求不能按时结束、数据不能导出等影响业务进展的情况。性能测试要关注两点：1）用户的数量；2）数据库中历史数据的多少。对于追加开发的程序，特别要考虑性能问题。

7. TA系列文档

如果服务条款中包括硬件、网络，则要制作TA系统文档，如TA120（服务器平台与网络结构）、TA110（系统能力规划），需要时，可参考AIM相关模板，这里就不列出了。

 

【差异分析】
1. BR030: Mapped Business Requirements

CRP的结果，也可称为 Fit/Gap 汇总表。它记录的是新业务流程（BP080）与企业当前业务和需求之间的匹配结果，两者之间有吻合的部分，也有存在差异的部分。对于差异，要提出建议的处理方案。

按照RD050的内容，进行差异分析，并把结果填入BR030。

我们在做CRP的时候，会以“BP080与新系统完全匹配”为前提，如果在CRP过程中，确实发现某些应在新系统中处理的环节，新系统的处理方式或结果不尽人意，也要记录入BR030中。

在AIM中，将报表的适用性分析写在 BR070中，我的习惯是把报表也纳入BR030，因为报表也是业务流程分析中的一项内容。

2. PT120: Performance Test Result

根据PT040，执行性能测试，并把测试结果写入PT120，对于性能不佳的部分，给出改善建议。

 

【补充开发】

1. MD010: Application Extension Strategy

定义开发过程中应遵守的规则。

有些项目不重视这份文档，拿到开发任务后，即分工至技术人员进行开发。这样的结果是，不同技术人员根据自己的习惯编写程序，程序风格各不相同，给集成和后续维护带来麻烦。因此，花时间确定这份文档是很有必要的。

制作这份文档并不会花费很多时间，公司在大型项目中，已积累了相关的资料，只要把与当前项目有关的内容抓过来，做做简单的加工整理就行了，毕竟开发规范通用性较强。

这份文档编制完成后，所有技术人员必须熟悉并遵守它，否则，还是达不到期望的效果。

2. MD020: Extension Definition and Estimates

概要定义客户化程序要实现的功能，并估算开发时间（包括设计、代码编写、测试、文档制作、维护）。AIM 3.0 的 MD020模板中有一个估算工作量的计算表格，使用VBA代码编写，用户选择好客户化程序的难度级别，表格中即自动算出各项任务的工作量。

3. MD050: Extension Function Design

详细写出客户化程序要实现的功能、数据处理逻辑、界面布局、输出内容及格式、使用方法。对该文档的签字，确保了顾问与用户对客户化程序达到了共同的认识。

4. MD060: Database Extensions

定义客户化数据库对象，如数据表、视图、说明弹性域、值集等。

5. MD070: Extension Technical Design

根据MD050的要求，列出技术实现方法，如程序结构、技术逻辑等。编码人员根据MD070编写具体的程序代码。

6. MD120: Installation Routines

客户化程序的安装手册，列出客户化程序的安装步骤、安装方法。

7. TE040: System Test Script

系统测试脚本。在这份脚本中，列出要对客户化程序做哪些方面的测试，使用什么数据、按什么步骤进行测试，验收的标准是什么。系统测试由功能顾问，通常是由设计该程序MD050的顾问来执行。  

在AIM 3.0 中，还有TE020（单元测试）、TE030（连接测试），这两类测试是由开发人员执行的，测试通过后，再交付功能顾问测试。由于功能顾问测试时，不可避免地也要验证这方面的内容（尽管可能不是特别完整），而且多数客户不要求提交TE020、TE030的结果，因此，AIM中将这两份测试文档列为“可选项”。

8. TE110: System Test Result

记录系统测试的结果。

通常的作法是，在TE040中有“实测结果”这样一个空白列，把TE040复制后改名为TE110，把测试结果填入这个空白列。

对于实测结果与MD050不一致的功能点，记为BUG，要求开发人员修改程序。

在测试过程中，如果实测结果与MD050一致，但是顾问或用户希望修改功能定义，则记为“需求变更”，先修改MD050，再由开发人员修改程序。在项目的某个时间点（通常为UAT开始前）之后，“需求变更”需要非常严谨的审批。

 

【培训用户】

1. AP140: User Learning Plan

培训计划。在这份计划中，说明用户如何掌握新业务、新系统。

它应该包括对管理层的概念培训、对关键用户的培训、对最终用户的培训。

它应该定义培训的时间、培训方法、考核标准。

2. DO070: User Guide

用户手册。

按照业务流程，详细写出该业务的处理方法，包括系统内的操作、系统外的处理。

为了使用方面，用户手册应该按岗位分组。

有些项目中以系统功能为单元编写手册，涉及的主要是系统功能，这样的手册，应称之为系统参考手册，文档代码为DO060。我认为在项目实施中，DO070是必须的，DO060可以省略（用联机帮助代替）。

除非实施合同中有特别的规定，否则，我会安排关键用户制作DO070，作为对他们培训的考核内容之一。

3. DO030: Glossary 

实施一个新的系统，必须会出现一些用户陌生的专业词汇，AIM建议专门制作一份文档，记录这些词汇。
如果只是从“系统”角度来解释，这份文档很好做，因为ORACLE提供了术语清单（我不清楚SAP有没有，应该也有吧）。
我认为，这样的一份文档，不应仅仅是系统词汇，应该还包括客户方的业务专用术语。作为顾问，刚进入这个企业时，也会遇到一些新鲜的名词，把它们记录下来，从业务角度给出解释，作为经验积累、作为后续支持者的参考资料，是很有意义的。

即使是系统词汇，如果可以结合客户企业的业务和习惯说法给出解释说明，会比照抄ORACLE的术语表更有意义。

4. 其他

培训考试题、考分汇总表，这些文档使用什么编号？我从AIM中没有找到，要么，在AP序列中自定义吧，如AP210、AP220。

 

【移行初始数据】

1. CV010: Data Conversion Requirements

列出要移行的数据清单、数据要求、移行时间及顺序。

有些项目在上线后，发现某些初始数据被遗漏了，导致企业的正常生产受到较大影响。如果事先有一份经详细研讨确认的移行清单，就可以避免这样的问题。

2. CV020: Conversion Standards

移行规范。

对于每一类要移行的数据，说明数据格式、数据整理方法、导入方法、验证方法。

3. 其他

如果要为移行编写一些专用程序，如供应商上传、物料清单上传等，涉及到功能设计、系统测试，建议与客户化程序一样，使用TE系列文档（AIM 在CV系列中专门列了一套），文档内容可以适当简化。

 

【上线 处理实际业务】

1. PM010: Transition Strategy

上线策略。

它包括上线计划、投入的资源、可预见的意外及对应措施、支持团队。

2. PM060: Production Support Infrastructure

支持方法。

一套高效、有力的支持流程，对于新系统的正常运转是非常重要的。

在上线之前，项目组应该确定运行支持方法，并写在这份文档中，它包括如下内容：出了问题该找谁、紧急的联络方式、支持团队的工作时间、在线帮助系统的使用方法等。

【其他】

上面的文档已经不少了，可是，在项目中，可能还会发现某些文档在上面的清单中找不到。例如，要移行的科目余额，用EXCEL提供的，它也是一份文档，也有留存价值，文档名用什么代码呢？遇到这种情况，可以从前面的列表中找个相似的，如CV020，或者在同一系列中自己编个号（尽量不要与AIM重叠），如CV210。

 

CRP在非EBS项目中应用的案例:

京港地铁将CRP的方法纳入到了信息系统的建设实施中，让业务人员充分参与到系统建设中，并在参与的过程中理解信息系统当中包含的理念，让用户在系统建设实施的过程中就接受并熟悉信息系统。逐渐地，京港地铁发展出了自己的应用系统项目管理方法论，CRP成为了其中关键的一环。这种方法论在未来也将在京港地铁其他信息系统的建设中发挥作用。

“你希望做什么？”常常在进行IT项目之初，IT 人员都会这样问业务人员。在京港地铁进行第一个信息化项目——人力资源系统的时候，也是如此。但是作为一家新成立的公司，对于究竟想要什么，往往业务人员也不甚清楚。

　　后来，京港地铁将CRP的方法纳入到了信息系统的建设实施中，让业务人员充分参与到系统建设中，并在参与的过程中理解信息系统当中包含的理念，让用户在系统建设实施的过程中就接受并熟悉信息系统。逐渐地，京港地铁发展出了自己的应用系统项目管理方法论，CRP成为了其中关键的一环。这种方法论在未来也将在京港地铁其他信息系统的建设中发挥作用。

引入CRP

“作为一家新公司，京港地铁对自有的东西并不是很熟悉，因此CRP方法对京港地铁来说是比较适合的。” 港铁资讯系统经理（中国及国际）林泽荫认为。

　　CRP其实就是这样一个过程，首先有一个标准的系统，其中可能包含着很多国际的最佳实践，如此一来就不需要先询问用户想要什么了，实施团队就可以告诉用户这是标准流程，可以在一定的范围内进行修改。修改之后再询问用户的意见，如此往复。“对于我们这样的新公司，我觉得这种方法是很适合的。”北京京港地铁有限公司信息技术部经理黄颖俊说，“因为我们就是一张白纸，既然是标准流程，我们如果觉得不错就可以照着做。”因为新公司的很多业务并不明确，那么最好的方法就是按照国际标准来做。

　　利用CRP的方法，京港地铁的业务人员充分地参与到了系统的建设实施中。在京港地铁进行CRP过程时，实施团队所做的第一件事情是问业务人员你都在做些什么业务，然后他把业务人员提到的所有业务都记录下来，之后，实施人员就花大概一周的时间向业务人员讲述他的那些工作如何在系统流程里面做。这个时候是第一轮的CRP。

　　这一周的讲述过去后，业务人员可能会觉得系统中有些地方不太好，或者有些地方是有冲突的，因此实施人员就要对信息系统进行修改，修改完之后再跟业务部门讲一遍。

　　“在做信息系统项目的时候，其实业务部门人员比IT人员累多了。”黄颖俊说，“因为他们要不断地把自己的业务说出来，然后还要想未来还将有什么业务。”在京港地铁，一般来说都会进行三轮CRP，每轮CRP大概会用一个月的时间，让用户有更多的时间去了解业务。在第一轮CRP中，基本上是由实施团队人员来讲、操作、解释；到了第二轮就是实施团队讲，业务部门进行操作；到了第三轮，就完全都是业务部门的人讲和操作。

　　“经过这样三轮CRP之后，用户验收环节就会进行得很快了。”黄颖俊说。

　　成就系统的实施方法

　　经过3年左右时间的信息系统建设和实施，京港地铁逐渐发展出了自己的应用系统项目管理方法论。“从需求分析到项目计划、功能分析、设计、构建、UAT、生产、总结，不管项目大小都按这个环节来做。”黄颖俊说。

　　其中在功能分析、设计流程中就包含着CRP的过程。用户交流、关键用户培训和匹配就是一轮CRP，CRP之后就会进入设计阶段，修改一些设计和业务流程，修改之后再进行匹配，如此往复，相当于进行三轮CRP就进入到了开发、测试和用户验收阶段。从开发、测试再到用户验收差不多也要进行三轮，“这样基本上系统的问题就不大了。”黄颖俊认为。

　　京港地铁的整个应用系统项目管理方法与港铁相差无几。“我们只是缺少一个产品选择阶段。”黄颖俊说，“因为我们大部分的系统用的都是港铁的。”

　　有了整个一套应用系统项目管理方法，京港地铁在未来的信息系统建设中也会得心应手，能够让用户在系统建设实施过程中就理解并接受。