CRP实施方法论

CRP实施⽅法论
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的含义、执⾏⽅法，以及它的结果。

⽤于帮助项⽬组建⽴业务流程模型。

通过还将发现软件与现实的差异（gap），并进⼀步调整软件配置。

的焦点是理解软件，以及组织、制度需求。

在过程中，项⽬组会按实现业务中可能出现的数据演⽰功能与流程。

关注于按步骤展⽰：新系统如何实现当前业务流程。

包括与案例有关的所有界⾯、报表、程序，并得到⽤户对系统的建议。

这⼀过程将反映以下问题，并形成⽂档:
软件与需求差异
对组织的影响
对制度与业务流程的影响
安全性问题
审批与监控机制
完成后的修改措施，项⽬仍然在设计阶段。

可以创造性的解决⼀些问题，以满⾜各⽅需求。

例如，软件的功能差异，即参与者想象中的业务流程运作⽅式与软件能⼒之间的差异。

要解决这个问题，要么变更流程，要么修改软件。

因此，开放的沟通环境⾮常重要，需要管理⼈员、功能⼈员、技术⼈员、开发团队与⽤户代表的介⼊。

同时，所有参与者都必须能开放的接受改变业务⽅式与流程，以实现项⽬总原则——不对软件做功能开发。

在前，项⽬组要接受系统培训，以理解系统的界⾯、路径，从⽽关注于最终业务⼈员如何使⽤系统。

此外，所有参与者都需求经过过程及概念的 培训。

不是⽤户培训，系统测试，或对最终系统的精确演⽰。

是系统设计阶段的⼀个环节，项⽬⼩组由此得到⽤户反馈。

当完成后，项⽬组可以形成：完整的业务流程图、对所有软件差异的汇总，以及如何通过特定的⽅法解决差异、需求、业务流程报告。

认真管理与执⾏是项⽬成功的关键，因为的反馈体现了对业务需求的详细理解，将指导系统实现。

不是...
⽤户培训环节。

⽤户不⽤在⾃⼰的电脑上⼀步步的跟着做。

⼤规模的数据转移过程，将⼤量正式业务数据导⼊环境。

或是原型的建模过程。

不要在会议中讨论或配置系统值、代码。

项⽬组毫⽆准备开会。

在之前可能的流程、初始配置都要准备好。

系统测试或是详细功能演⽰。

参与⼈要清楚项⽬还处于设计阶段，想要得到的是关键问题的反馈。

是...
预先编写好脚本，妥善准备好的⼯作。

.
项⽬组⽤预先配置好的系统，⽤多个真实的业务情境，演⽰软件功能与流程。

⽤⼩规模的样本数据做演⽰。

通常这些数据只要⼿⼯录⼊。

向⽤户提出问题，并收到关于预想中的。

找出需要在结束后解决的功能差异、业务制度中的关键问题，并编制出⽂档。

在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
⽀持⽅法。