AIM实施方法论

1、比照AIM，CRP实施方法论应该有如下知识体系：1) 实施阶段的划分；2) 每个阶段的目的、任务清单、工作方法说明、成果物；3) 成果物模板；4) 实施团队的组织结构。【阶段划分】实施过程中包括哪几个阶段？要完成哪些任务？根据我个人的经验，将其归纳在如下表格中。在以上表格定义的阶段中，CRP1、CRP2、UAT、GoLive四个阶段是必需的。如果CRP2之后，仍然有不少待解决和验证的差异，不能进入UAT阶段，那么，可能需要执行CRP3，甚至CRP4。这种情况的出现，会对项目管理产生较大的风险，因为通常在项目筹划时，不会预先留出CRP3、CRP4的时间，在CRP2之后增加这些阶段，可能会导致项目

2、延期。因此，在实施过程中，要努力提升CRP1、CRP2的效率和效果，避免中途增加CRP3。CRP1特别好的情况下，CRP2可能也会被跳过。如果对客户的业务情况及需求不甚了解，不清楚在CRP1中会产生多少差异，建议在CRP1之前设置一个Pre-CRP阶段，对客户当前业务及需求进行调研，如果得到允许，可以根据调研结果，适当调整将要用于CRP1的模板。如果在CRP1时发生许多重大差异，会降低用户对模板的兴趣，甚至在争论中产生抵触情绪。c4（要确保模板中的每一项规定都是“合理”的，这个“理”，可以是总公司或客户高层的统制思想，可以是行业经验，但不可以仅仅是“系统如此”。）集团公司实施一套统一的系统时，

3、通常需要根据集团的业务特点，制订一套模板，而不是把系统标准功能或相似企业的经验资料直接拿来进行实施。（让一个大集团照抄其他公司的标准，或者强推系统功能，是伤面子的。）这时，就会多出一个“Template”阶段。也有的集团在实施时，选一家子公司，一边实施，一边做模板，这样的方法，看起来好像会减少总的实施周期，并且避免模板严重偏离业务现实，但是，它会使得模板中有过多的该子公司的个性化影子，对后续的推广不利，因此，我个人不喜欢这种模式。我喜欢设置一个相对独立的“Template”阶段，从全局角度制作模板（这时，要防止“闭门造车”式的模板制作方法，如果你弄了一辆起重机当模板去轿车厂做CRP，等着挨骂吧

4、）。阶段定义】8 e-   F7 J& u  s' F& c; R) lTemplate3 b; l$   K( 4 v, H, . o7 f7 CRP实施的核心工具是“业务模板”，有时也称为“标准模板”、“标准”、“全球标准”（集团公司喜欢这么叫）。它是一套设想中的、理想的业务规范，实施人员（包括客户高层管理者）认为，企业按照这样的规范做业务，可以达到优秀的经营目标。当然，这是“理想”，毕竟每个企业都有自己的特殊点，有些特殊点甚至是企业生存、获利的关键，CRP就是标准与个性的磨合与相互妥协的过程。Templa

5、te 阶段就是要制作这个“标准模板”，关于制作的方法及注意事项，后面会有详细的论述。6 C% J+ k( Y5 F: M- u/ HPre-CRP如果不清楚企业的当前业务、期望，对标准模板的匹配程度心中没底，则有必要设置Pre-CRP阶段，对企业进行调研，对模板进行必要的调整。* CRP1将模板与企业实际业务和期望进行对比，寻找差异，并确定差异的解决方法。关注如下三个方面：3 k7 q/ g' F9 J  R" E" H0 k' b. Y1) 模板中描述的业务处理规范，与企业当前处理方法相比，有什么不同之处？对于不同点，企业能否采纳模板规

6、范？2) 模板中有哪些业务是该企业目前不存在，且将来一定时间内也不会出现的？! k$ u) n8 D, K6 C4 % ! t" R3) 企业的实际业务中，有哪些是模板中未涉及的。7 M& c- t" o; g/ h9 K对于不同点（即差异），处理原则为：1) 企业接受模板中的规范。2) 企业保留自己的个性特点，模板也不予对应。3) 该差异在集团中具有一定的共性，按企业需求修改模板。# |! N; x& v+ O% O在这个阶段，还要包括如下任务：1) 向企业用户（主要是参与CRP1的关键用户）讲解系统基本概念，并通过CRP分析，让他们了解系统的基本操作。&

7、quot; D) k5 F! K7 I9 q$ T2) 确定要移行的主数据（也称为静态数据），发出数据收集表，请关键用户安排人员开始收集主数据。3) 如果差异解决方法中涉及补充开发，在确定开发需求后，开始着手进行功能设计、技术设计。原则上，所有的补充开发应在CRP2中进行测试。+ u  K; C4 W) t. RCRP2CRP1中的差异均被解决之后（补充开发可以稍晚），开始CRP2。3 ; y. N8 X0 ( ?6 CRP2的重点是验证差异的解决方案，如果在开始时有的补充开发尚未完成，可以在上半阶段验证标准功能部分，下半阶段验证补充开发功能。2 T# y& D/

8、g0 K& 要注意的是，CRP2中不可以只测试差异部分，而是要测试全部业务，以避免差异解决方案对原来无差异的业务的影响。与CRP1的区别是，对于CRP1中无差异的业务，只要测试结果与CRP1时相同，就无需再关注。$ y( q! N$ b' Q, I9 p# bCRP2中可能还会出现一些新的差异（包括CRP1差异中解决方案不合适的部分），CRP2结束后要对差异进行一次判定，如果认为差异对业务的影响可以接受，则进入UAT阶段，否则，要插入CRP3阶段。6 Q7 N  P2 S- m2 X7 W在CRP2中，对于已确定的业务规范，要开始着手对最终用户进行培训，包括

9、学习新的业务规范、学习系统操作。: a% ' ?: 0 fUATUAT（User Acceptance Test），也称作试运行。; w  l% ?7 I. UAT开始前，主数据应该已经整理完毕，并且使用与上线时相同的方法，输入到系统中。在UAT中，模拟上线情况，对企业全部的业务进行测试。虽然测试仍以业务为线索，但是UAT中除了关注业务外，还要关注各个部门、用户之间的配合程度，关注主要的单据和报表在实际业务中的适用情况。, W. w' H& % t( 8 T* hUAT既是测试，也是部门、用户之间的磨合。( K) T2 R7 p5 u* MUAT结束

10、后，要进行上线判定，考虑如下几个方面：1) 系统对业务的处理步骤和结果，是否可以接受？2) 余留的差异，对企业的运营影响，是否足够小？% w/ g& K. c; g. d8 G# o# b3) 部门、用户之间的配合是否流畅？4) 报表、单据是否适用?  C' G6 V. r8 # v/ I5) 上线所需的主数据是否准备完成？8 n. Y; u+ g# a) K3 C- j# u' 6) 上线切换计划是否可行？H% k3 如果企业最终不能成功使用新系统，则前面各阶段的工作将付诸流水。我们必须纠正“重方案、轻上线”的做法，鼓足最后一股劲，确保企业上线成功

11、。5 z; |/ x) 1 b/ L当截止UAT的各个阶段均顺利完成时，上线的成败主要取决于上线计划的合理性及执行力。一份列出了上线全部明细任务的清单是非常有帮助的，清单上要列出各个任务的说明、工作量、负责人、开始时间、预计完成时间、复核人等。对于初次负责项目上线的PM，简单把别人或其他项目上的资料拿来复制一份是不够的，应该请有经验的高级顾问帮忙把把关。这个阶段还应包括上线切换完成后第一个月的业务处理支持、月结支持（个别不采购这项服务的项目除外）。. R& o7 ; 3 h- E* m# H' E( L按CRP实施一个项目，需要完成多少文档？各个具体的项目，答案会有些差别。在这

12、一切，按我个人的理解，列出一份文档清单。考虑到沟通上的方便，文档名称的编码尽量与AIM (版本3.0) 保持一致。声明：本节的文档规则仅为我个人的观点，未得到任何官方的认可，它可能与某些公司、某些人的规则或习惯有冲突。建议的文件名规则：项目英文简称_(子项目英文简称)_文档编号_文档说明_区分字符_版本.后缀其中“子项目英文简称”是可选项。5 U7 W# b1 B% d% K6 l+ E) h“文档编号”是CR010、MD050、DO070这样的代码；“文档说明”是一串简洁的英文单词，用于说明该文档的作用，如“SOA”、“Functional Design”、“User Manual”等。“区

13、分字符”是为了使文件名唯一化而填写的，例如，项目中可能用多个DO070（操作手册），为了区分这些文件，可以使用模块名、业务名作为“区分字符”。例1， 某项目英文简称为 HAIF，该项目上编写的关于金税接口的第一版功能设计书，可以命名为 HAIF_MD050_Functional Design_GoldenTaxIF_V1.0.doc。( m1 : P3 P5 V% M, k+ 5 n! 例2， 某大型项目 MFO 按实施地点分为若干个子项目，其中某个地点的简称（子项目简称或公司简称）为AB，该项目编写的应付发票维护的操作手册第1.1版，可以命名为 MFO_AB_DO070_User Manua

14、l_AP Invoice Maintain_V1.1.doc。强烈建议：避免在文件名中使用双字节字符，特别是在与其他国家人员合作的情况下，双字节字符在其他语言的操作系统上可能显示为乱码。) S( r1 y$ j; 1 F& P! Z用WORD、EXCEL，还是其他？  2 W0 i% c  i" VMS OFFICE 用户众多，但也不排除某些企业内部统一使用WPS的情况，好在目前这些编辑器之间具有一定的兼容性，我们不必要针对客户的情况安装新的编辑器。然而，在项目之初，项目经理还是应花时间与客户方项目经理统一一下文档的格式，以使用MS O

15、FFICE为例，有些企业喜欢用WORD，而有些企业则特别喜欢用EXCEL，确定好工具之后，还要确定版本，某些顾问比较喜欢新潮，总是安装最新版的工具，如果直接保存为 WORD 2007，则客户使用WORD 2003就可能打不开顾问所写的文档。 大家约定一个版本，高版本的用户，在保存文件时，请选择低版本兼容格式。(如果客户不喜欢尝试新的文档格式，没必要强求他们改变，顾问应该顺应客户在这方面的习惯。)8 t4 " H& : W& b) P+ W! H! V& a  r8 |/ _【项目管理】1. CR010:SOA7 2 d6 - m3 ! z1

16、 a+ U9 z上面的字符由两段组成，“:”之前的是“文档编号”，之后是“文档说明”。SOA的全称是Scope, Objectives, and Approach，它定义项目的范围、目标、实施方法，确保顾问与客户双方在这些方面有共同的认识。这个文档应该在商务谈判阶段完成。双方就这份文档达成一致后，才开始具体的项目实施工作。6 m* d4 |/ b; m4 K4 2. CR020:Regulation在AIM中，CR020的说明是“Define Control and Reporting Strategies, Standards, and Procedures”，在CR020之外，还有CR03

17、0、QM010、RM010、RM025等文档，每份文档专注于一个目标，我感觉写这么多文档太麻烦（每份文档都要有一套封面、修改历史、目标等三页，实际内容可能只有一页，浪费），因此，除非客户要求严格遵守AIM文档体系（我还没遇到过），我就把这些内容全部写在CR020中，如项目成员结构图、汇报流程、作息制度、日常办公守则、会议制度、质量检查标准、文件服务器、信息安全，等等。3. CM020ocument Control! W" l9 o- t& u9 W5 O: Y) # C4 I4 D列出项目实施所需的文档（输入），以及要完成的文档（输出）清单。如前所述，每个项目中的文档可能有所

18、差异，项目经理要根据项目特点，确定项目清单。6 Q) V; v7 h5 y* B6 d& H1 有的商务合同中包括了“提交物”清单，但是这并非项目文档的全部。) 8 R) H1 |4 S$ o/ M/ _  S项目经理应该在项目筹备阶段完成这份清单，清单中除了文档名称外，还要有时间（使用时间或完成时间），对于输出文档，要有模板。项目经理要取得客户方项目经理对此文档的认可，然后交给全部项目成员，确保各成员对文档有共同的理解，避免风格不同的文档在项目上出现。6 B* O" g0 C! q+ h; k6 b4. WM020:WBS5 _0 Y" U/

19、s; Y1 L3 5 d3 N详细的项目计划，包括细化的任务说明、所需资源、起止时间、提交物等。MS Project 是制作与追踪WBS的专业化工具，但是它很贵，如果没有这个软件，可以考虑使用EXCEL，或开源的项目管理软件，有些开源软件与MS Project基本功能相当，甚至可以兼容MS Project的某种文档格式。  J; W$ w6 E2 w% r/ B5. CR040:Risk Control1 a! h, V; r  描述风险的处理流程，并包括一个风险处理模板，使用模板填写风险内容，以及建议的规避方法。) k, b/ B# x1 v&

20、 b4 h: h% L3 r! u6 s6. CR060:Change Management描述变更管理流程（如业务范围的变更、开发完成后功能需求的变更等），提包括一个变更处理模板，使用模板填写变更内容，以及对应变更所需要的估算工作量。6 y+ u, S- m  g! v' _7. PJM11:Weekly Report在AIM中，将PJM01 PJM10 定义为项目管理的其他文档，我延用它的序列，从编号11开始，定义一些其他的项目管理文档。Weekly Report，项目周报，填写本周工作的总结，整个项目的汇总周报由项目经理编写，项目经理可指定小组负责人，编写小组

21、的周报。8. PJM07eriod End Report各阶段结束时的总结报告，如果要编写月度报告，也使用这个格式。9. PJM12:Meeting Memo- L  8 b. z& f. J8 : g会议纪要。10. PJM02roject memo项目备忘录。$ + M) e, J+ M$ t1 D11. PJM13:Issues Sheet: d8 v4 q( 3 l8 C& H( A& l0 ( o课题台账。3 X/ : 3 % Q7 C$ X0 j1 T在项目实施过程中，项目管理、业务、系统、资源等各方面出现的问题，为了防止被遗忘，应该把它

22、们记录到课题台账中。对于每个课题，要记录概述（标题）、说明（文字较多时可以使用附件）、影响程度、提出者、提出日期、期望的解决期限。! M9 f1 W/ o! i: h/ K项目经理会同相关负责人研讨新课题后，确定课题的负责人。# l  w0 W* P4 / l# X$ d1 J& O课题的负责人应保持对课题进度的监督，及时更新课题的状态。在课题被解决后，填写解决方法、实际解决日期。原则上，由课题的提出者确认、关闭课题。【业务调研及方案】1. RD020:Business Research Questionnaire业务调研问卷。4 8 N7 s' n: M%

23、 N3 h2. BP040:Current Business Model描述企业当前的业务处理模式、客户对将来业务的需求。根据业务调研的结果，制作此文档。3. BP080:Future Business Module描述企业未来的业务处理流程。4. BR100:Setups记录系统的设置参数。在AIM中，BR110用于记录系统安全相关的设置（如菜单、职责），我认为也可以把这些内容归入BR100的范畴。当然，有的客户也会坚持系统的常规设置与安全设置在文档编号上分开，以便分配至不同的部门或用户。/ M9 r5 j8 A& j, R建议在CRP的各个阶段分别维护一份设置文档，以便事后返查。先

24、确定设置文档，然后根据文档设置系统，是一种好的习惯，可以防止在设置过程中产生遗漏。5. RD050:Business Requirement Scenarios* ?+ ) |8 U3 K4 g& ' 1 jCRP脚本。该文档按业务流程编写，对于每个业务流程，说明要进行哪些方面的测试，例如，输入哪几种类型的数据、输出哪些报表、关键的确认点有哪些。. p+ y8 % X- M, u在执行CRP（如CRP1、CRP2）时，按此脚本逐一进行确认，并填写结果（形成文档BR030）。由于各个CRP阶段的侧重点不同，因此，要分别制作每个阶段的RD050。（也有的人嫌麻烦，只制作一份RD05

25、0，然后，增加几列，标出哪些内容CRP1使用、哪些内容CRP2使用）。4 Z% J0 ) v7 n6 T$ o. d, F( o: z有的项目中使用 TE040 编写CRP脚本，我的定义是，TE040专用于追加开发程序的测试（AIM的定义也类似），RD050是完整的业务流程测试脚本。! d7 & s4 I1 U& A  R0 6. PT040erformance Test Scripts性能测试脚本。有的项目特别关注业务流程，却忽视系统性能。这对于业务量不大的企业，可能没什么影响，但是，如果企业每天都生成大量的数据、用户很多、工作地点分散、网络容量有限，就需

26、要进行性能测试，以避免上线后系统界面打开缓慢、并发请求不能按时结束、数据不能导出等影响业务进展的情况。$ # g1 F$ W9 j- k0 M; t2 性能测试要关注两点：1）用户的数量；2）数据库中历史数据的多少。对于追加开发的程序，特别要考虑性能问题。7. TA系列文档* W9 e* J* , - k3 5 ?+ v如果服务条款中包括硬件、网络，则要制作TA系统文档，如TA120（服务器平台与网络结构）、TA110（系统能力规划），需要时，可参考AIM相关模板，这里就不列出了。差异分析】1. BR030:Mapped Business RequirementsCRP的结果，也可称为 Fit

27、/Gap 汇总表。它记录的是新业务流程（BP080）与企业当前业务和需求之间的匹配结果，两者之间有吻合的部分，也有存在差异的部分。对于差异，要提出建议的处理方案。按照RD050的内容，进行差异分析，并把结果填入BR030。我们在做CRP的时候，会以“BP080与新系统完全匹配”为前提，如果在CRP过程中，确实发现某些应在新系统中处理的环节，新系统的处理方式或结果不尽人意，也要记录入BR030中。在AIM中，将报表的适用性分析写在 BR070中，我的习惯是把报表也纳入BR030，因为报表也是业务流程分析中的一项内容。, S1 W; c/ L4 w$ 2. PT120eformance Test

28、Result根据PT040，执行性能测试，并把测试结果写入PT120，对于性能不佳的部分，给出改善建议。$ L5 D; O8 O2 【补充开发】1. MD010:Application Extension Strategy4 r4 G( C2 d* d4 定义开发过程中应遵守的规则。2 L8 G, X# K  T7 B有些项目不重视这份文档，拿到开发任务后，即分工至技术人员进行开发。这样的结果是，不同技术人员根据自己的习惯编写程序，程序风格各不相同，给集成和后续维护带来麻烦。因此，花时间确定这份文档是很有必要的。制作这份文档并不会花费很多时间，公司在大型项目中，已积累了相关

29、的资料，只要把与当前项目有关的内容抓过来，做做简单的加工整理就行了，毕竟开发规范通用性较强。这份文档编制完成后，所有技术人员必须熟悉并遵守它，否则，还是达不到期望的效果。2. MD020:Extension Definition and Estimates概要定义客户化程序要实现的功能，并估算开发时间（包括设计、代码编写、测试、文档制作、维护）。AIM 3.0 的 MD020模板中有一个估算工作量的计算表格，使用VBA代码编写，用户选择好客户化程序的难度级别，表格中即自动算出各项任务的工作量。3. MD050:Extension Function Design$ p/ c1 & J!

30、I' J6 q/ D/ E, k详细写出客户化程序要实现的功能、数据处理逻辑、界面布局、输出内容及格式、使用方法。对该文档的签字，确保了顾问与用户对客户化程序达到了共同的认识。8 ?+ k4 K+ K% m  t" w2 P7 x4. MD060atabase Extensions定义客户化数据库对象，如数据表、视图、说明弹性域、值集等。, i% v1 s2 j, R; W8 N( W& o$ x5. MD070:Extension Technical Design根据MD050的要求，列出技术实现方法，如程序结构、技术逻辑等。编码人员根据MD07

31、0编写具体的程序代码。6. MD120:Installation Routines+ " P- I* A1 o* & 客户化程序的安装手册，列出客户化程序的安装步骤、安装方法。7 V# x' U5 V0 n* r7. TE040:System Test Script系统测试脚本。在这份脚本中，列出要对客户化程序做哪些方面的测试，使用什么数据、按什么步骤进行测试，验收的标准是什么。系统测试由功能顾问，通常是由设计该程序MD050的顾问来执行。  A& a3 H" m7 P) o/ d$ y在AIM 3.0 中，还有TE020（单元测

32、试）、TE030（连接测试），这两类测试是由开发人员执行的，测试通过后，再交付功能顾问测试。由于功能顾问测试时，不可避免地也要验证这方面的内容（尽管可能不是特别完整），而且多数客户不要求提交TE020、TE030的结果，因此，AIM中将这两份测试文档列为“可选项”。8. TE110:System Test Result记录系统测试的结果。3 H, e$ t3 k6 _" S6 _9 a通常的作法是，在TE040中有“实测结果”这样一个空白列，把TE040复制后改名为TE110，把测试结果填入这个空白列。对于实测结果与MD050不一致的功能点，记为BUG，要求开发人员修改程序。在测试过

33、程中，如果实测结果与MD050一致，但是顾问或用户希望修改功能定义，则记为“需求变更”，先修改MD050，再由开发人员修改程序。在项目的某个时间点（通常为UAT开始前）之后，“需求变更”需要非常严谨的审批。【培训用户】! o5 i3 q- Z6 S- Y# e9 C# _1. AP140:User Learning Plan0 n" v% l! ) L培训计划。在这份计划中，说明用户如何掌握新业务、新系统。它应该包括对管理层的概念培训、对关键用户的培训、对最终用户的培训。7 c# T: M: O5 i7 k" k* B0 $ W* q它应该定义培训的时间、培训方法、考核标准

34、。/ U1 i: Y! l" y; i% m1 _; D2. DO070:User Guide" f7 v7 M! y. ?2 f4 K1 Z8 |3 3 a用户手册。. - X+ D+ t: |按照业务流程，详细写出该业务的处理方法，包括系统内的操作、系统外的处理。2 q$ s, M/ b+ + J: f' G为了使用方面，用户手册应该按岗位分组。6 Y; D7 X& |! T' 3 h% i有些项目中以系统功能为单元编写手册，涉及的主要是系统功能，这样的手册，应称之为系统参考手册，文档代码为DO060。我认为在项目实施中，DO070是必须的，DO

35、060可以省略（用联机帮助代替）。' j2 u1 Q! Y0 D6 ) j, o- o8 H除非实施合同中有特别的规定，否则，我会安排关键用户制作DO070，作为对他们培训的考核内容之一。! y0 z1 H7 V$ G7 d* h9 f3. DO030:Glossary  L3 F+ _; E+ R+ h3 t9 q9 9 E/ w1 G实施一个新的系统，必须会出现一些用户陌生的专业词汇，AIM建议专门制作一份文档，记录这些词汇。如果只是从“系统”角度来解释，这份文档很好做，因为ORACLE提供了术语清单（我不清楚SAP有没有，应该也有吧）。我认为，这样的一份文档，不应仅仅是系统词汇，应该还包括客户方的业务专用术