AIM实施方法论Word文件下载.docx
《AIM实施方法论Word文件下载.docx》由会员分享，可在线阅读，更多相关《AIM实施方法论Word文件下载.docx（13页珍藏版）》请在冰豆网上搜索。
它是一套设想中的、理想的业务规范，实施人员（包括客户高层管理者）认为，企业按照这样的规范做业务，可以达到优秀的经营目标。
当然，这是理想”，毕竟每个企业都有自己的特殊点，有些特殊点甚至是企业生存、获利的关键，CRP就是标准与个
性的磨合与相互妥协的过程。
Template阶段就是要制作这个标准模板”，关于制作的方法及注意事项，后面会有详细的论述。
…
Pre-CRP
如果不清楚企业的当前业务、期望，对标准模板的匹配程度心中没底，则有必要设置Pre-CRP
阶段，对企业进行调研，对模板进行必要的调整。
*
CRP1将模板与企业实际业务和期望进行对比，寻找差异，并确定差异的解决方法。
关注如下三个
方面•
"
■"
.E"
H
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（UserAcceptanceTest）,也称作试运行。
UAT开始前，主数据应该已经整理完毕，并且使用与上线时相同的方法，输入到系统中。
在UAT中，模拟上线情况，对企业全部的业务进行测试。
虽然测试仍以业务为线索，但是UAT中除了关注业务外，还要关注各个部门、用户之间的配合程度，关注主要的单据和报
表在实际业务中的适用情况。
-…
UAT既是测试，也是部门、用户之间的磨合。
UAT结束后，要进行上线判定，考虑如下几个方面：
1）系统对业务的处理步骤和结果，是否可以接受？
2）余留的差异，对企业的运营影响，是否足够小？
•…
3）部门、用户之间的配合是否流畅？
4）报表、单据是否适用？
vi
5）上线所需的主数据是否准备完成？
6）上线切换计划是否可行？
H%I3-如果企业最终不能成功使用新系统，则前面各阶段的工作将付诸流水。
我们必须纠正重方
案、轻上线”的做法，鼓足最后一股劲，确保企业上线成功。
5.
当截止UAT的各个阶段均顺利完成时，上线的成败主要取决于上线计划的合理性及执行力。
一份列出了上线全部明细任务的清单是非常有帮助的，清单上要列出各个任务的说明、工作
量、负责人、开始时间、预计完成时间、复核人等。
对于初次负责项目上线的PM,简单把
别人或其他项目上的资料拿来复制一份是不够的，应该请有经验的高级顾问帮忙把把关。
这个阶段还应包括上线切换完成后第一个月的业务处理支持、月结支持（个别不采购这项服
务的项目除外）。
按CRP实施一个项目，需要完成多少文档？
各个具体的项目，答案会有些差别。
在这一切，
按我个人的理解，列出一份文档清单。
考虑到沟通上的方便，文档名称的编码尽量与AIM（版本3.0）保持一致。
声明：
本节的文档规则仅为我个人的观点，未得到任何官方的认可，它可能与某些公司、某些人的规则或习惯有冲突。
建议的文件名规则：
项目英文简称_（子项目英文简称）_文档编号_文档说明_区分字符一版本.后缀其中乎项目英文简称”是可选项。
文档编号”是CR010、MD050、DO070这样的代码；
文档说明”是一串简洁的英文单词，
用于说明该文档的作用，如"
SOA、aFunctionalDesign"
、"
UserManual"
等。
区分字符"
是为了使文件名唯一化而填写的，例如，项目中可能用多个DO070（操作手册），为了区分这些文件，可以使用模块名、业务名作为区分字符”。
例1,某项目英文简称为HAIF，该项目上编写的关于金税接口的第一版功能设计书，可
以命名为HAIF_MD050_FunctionalDesign_GoldenTaxIF_V1.0.doc。
•
例2,某大型项目MFO按实施地点分为若干个子项目，其中某个地点的简称（子项目简
称或公司简称）为AB，该项目编写的应付发票维护的操作手册第1.1版，可以命名为
MFO_AB_DO070_UserManual_APInvoiceMaintain_V1.1.doc。
强烈建议：
避免在文件名中使用双字节字符，特别是在与其他国家人员合作的情况下，双字
节字符在其他语言的操作系统上可能显示为乱码。
用WORD、EXCEL，还是其他？
MSOFFICE用户众多，但也不排除某些企业内部统一使用WPS的情况，好在目前这些编
辑器之间具有一定的兼容性，我们不必要针对客户的情况安装新的编辑器。
然而，在项目之
初，项目经理还是应花时间与客户方项目经理统一一下文档的格式，以使用MSOFFICE为
例，有些企业喜欢用WORD，而有些企业则特别喜欢用EXCEL,确定好工具之后，还要确
定版本，某些顾问比较喜欢新潮，总是安装最新版的工具，如果直接保存为WORD2007,
则客户使用WORD2003就可能打不开顾问所写的文档。
大家约定一个版本，高版本的用
户，在保存文件时，请选择低版本兼容格式。
（如果客户不喜欢尝试新的文档格式，没必要
强求他们改变，顾问应该顺应客户在这方面的习惯。
）…
&
bP+WHV&
a8"
【项目管理】
1.CR010:
SOA
上面的字符由两段组成，“:
之前的是艾档编号”，之后是文档说明”。
SOA的全称是Scope,Objectives,andApproach,它定义项目的范围、目标、实施方法，确保顾问与客户双方在这些方面有共同的认识。
这个文档应该在商务谈判阶段完成。
双方就这份
文档达成一致后，才开始具体的项目实施工作。
2.CR020:
Regulation
在AIM中，CR020的说明是"
DefineControlandReportingStrategies,Standards,andProcedures，”在CR020之外，还有CR030、QM010、RM010、RM025等文档，每份文档专注于一个目标，我感觉写这么多文档太麻烦（每份文档都要有一套封面、修改历史、目标等三页，实际内容可能只有一页，浪费），因此，除非客户要求严格遵守AIM文档体系（我还
没遇到过），我就把这些内容全部写在CR020中，如项目成员结构图、汇报流程、作息制度、日常办公守则、会议制度、质量检查标准、文件服务器、信息安全，等等。
3.CM020ocumentControl…
列出项目实施所需的文档（输入），以及要完成的文档（输出）清单。
如前所述，每个项目中的文档可能有所差异，项目经理要根据项目特点，确定项目清单。
.一.
有的商务合同中包括了提交物”清单，但是这并非项目文档的全部。
项目经理应该在项目筹备阶段完成这份清单，清单中除了文档名称外，还要有时间（使用时
间或完成时间），对于输出文档，要有模板。
项目经理要取得客户方项目经理对此文档的认可，然后交给全部项目成员，确保各成员对文
档有共同的理解，避免风格不同的文档在项目上出现。
—
4.WM020:
WBS…
详细的项目计划，包括细化的任务说明、所需资源、起止时间、提交物等。
MSProject是制
作与追踪WBS的专业化工具，但是它很贵，如果没有这个软件，可以考虑使用EXCEL,或开源的项目管理软件，有些开源软件与MSProject基本功能相当，甚至可以兼容MSProject的某种文档格式。
5.CR040:
RiskControl
描述风险的处理流程，并包括一个风险处理模板，使用模板填写风险内容，以及建议的规避
/Ir/\（J,k,b-B#X1v&
b4hh%L3r!
u6s
6.CR060:
ChangeManagement
描述变更管理流程（如业务范围的变更、开发完成后功能需求的变更等），提包括一个变更
处理模板，使用模板填写变更内容，以及对应变更所需要的估算工作量。
6.'
_
7.PJM11:
WeeklyReport
在AIM中，将PJM01~PJM10定义为项目管理的其他文档，我延用它的序列，从编号11开始，定义一些其他的项目管理文档。
WeeklyReport,项目周报，填写本周工作的总结，整个项目的汇总周报由项目经理编写，项
目经理可指定小组负责人，编写小组的周报。
8.PJM07eriodEndReport
各阶段结束时的总结报告，如果要编写月度报告，也使用这个格式。
9.PJM12:
MeetingMemo
会议纪要。
10.PJM02rojectmemo
项目备忘录。
11.PJM13:
IssuesSheet
课题台账。
在项目实施过程中，项目管理、业务、系统、资源等各方面出现的问题，为了防止被遗忘，
应该把它们记录到课题台账中O
对于每个课题，要记录概述（标题）、说明（文字较多时可以使用附件）、影响程度、提出者、提出日期、期望的解决期限。
项目经理会同相关负责人研讨新课题后，确定课题的负责人。
课题的负责人应保持对课题进度的监督，及时更新课题的状态O
在课题被解决后，填写解决方法、实际解决日期。
原则上，由课题的提出者确认、关闭课题。
【业务调研及方案】
1.RD020:
BusinessResearchQuestionnaire
业务调研问卷。
2.BP040:
CurrentBusinessModel
描述企业当前的业务处理模式、客户对将来业务的需求。
根据业务调研的结果，制作此文档。
3.BP080:
FutureBusinessModule
描述企业未来的业务处理流程。
4.BR100:
Setups
记录系统的设置参数。
在AIM中，BR110用于记录系统安全相关的设置（如菜单、职责），我认为也可以把这些内容归入BR100的范畴。
当然，有的客户也会坚持系统的常规设置与安全设置在文档编号上分开，以便分配至不同的部门或用户。
建议在CRP的各个阶段分别维护一份设置文档，以便事后返查。
先确定设置文档，然后根据文档设置系统，是一种好的习惯，可以防止在设置过程中产生遗漏。
5.RD050:
BusinessRequirementScenarios
CRP脚本。
该文档按业务流程编写，对于每个业务流程，说明要进行哪些方面的测试，例如，输入哪几种类型的数据、输出哪些报表、关键的确认点有哪些。
在执行CRP（如CRP1、CRP2）时，按此脚本逐一进行确认，并填写结果（形成文档BR030）。
由于各个CRP阶段的侧重点不同，因此，要分别制作每个阶段的RD050°
（也有的人嫌麻烦，只制作一份RD050，然后，增加几列，标出哪些内容CRP1使用、哪些内容CRP2使用）。
..
JIV■―T,odF（o
有的项目中使用TE040编写CRP脚本，我的定义是，TE040专用于追加开发程序的测试（AIM的定义也类似），RD050是完整的业务流程测试脚本。
6.PT040erformanceTestScripts
性能测试脚本。
有的项目特别关注业务流程，却忽视系统性能。
这对于业务量不大的企业，可能没什么影响，但是，如果企业每天都生成大量的数据、用户很多、工作地点分散、网络容量有限，就需要进行性能测试，以避免上线后系统界面打开缓慢、并发请求不能按时结束、
数据不能导出等影响业务进展的情况。
….
性能测试要关注两点：
1）用户的数量；
2）数据库中历史数据的多少。
对于追加开发的程序，
特别要考虑性能问题。
7.TA系列文档…
如果服务条款中包括硬件、网络，则要制作TA系统文档，如TA120（服务器平台与网络结
构）、TA110（系统能力规划），需要时，可参考AIM相关模板，这里就不列出了。
差异分析】
1.BR030:
MappedBusinessRequirements
CRP的结果，也可称为Fit/Gap汇总表。
它记录的是新业务流程（BP080）与企业当前业务和需求之间的匹配结果，两者之间有吻合的部分，也有存在差异的部分。
对于差异，要提出
建议的处理方案。
按照RD050的内容，进行差异分析，并把结果填入BR030o
我们在做CRP的时候，会以“BP08内新系统完全匹配”为前提，如果在CRP过程中，确实
发现某些应在新系统中处理的环节，新系统的处理方式或结果不尽人意，也要记录入BR030
中。
在AIM中，将报表的适用性分析写在BR070中，我的习惯是把报表也纳入BR030,因为
报表也是业务流程分析中的一项内容。
2.PT120eformanceTestResult
根据PT040,执行性能测试，并把测试结果写入PT120,对于性能不佳的部分，给出改善建
议。
—
【补充开发】
1.MD010:
ApplicationExtensionStrategy
定义开发过程中应遵守的规则。
2…
有些项目不重视这份文档，拿到开发任务后，即分工至技术人员进行开发。
这样的结果是，不同技术人员根据自己的习惯编写程序，程序风格各不相同，给集成和后续维护带来麻烦。
因此，花时间确定这份文档是很有必要的。
制作这份文档并不会花费很多时间，公司在大型项目中，已积累了相关的资料，只要把与当
前项目有关的内容抓过来，做做简单的加工整理就行了，毕竟开发规范通用性较强。
这份文档编制完成后，所有技术人员必须熟悉并遵守它，否则，还是达不到期望的效果。
2.MD020:
ExtensionDefinitionandEstimates
概要定义客户化程序要实现的功能，并估算开发时间（包括设计、代码编写、测试、文档制
作、维护）。
AIM3.0的MD020模板中有一个估算工作量的计算表格，使用VBA代码编写，
用户选择好客户化程序的难度级别，表格中即自动算出各项任务的工作量。
3.MD050:
ExtensionFunctionDesign
详细写出客户化程序要实现的功能、数据处理逻辑、界面布局、输出内容及格式、使用方法。
对该文档的签字，确保了顾问与用户对客户化程序达到了共同的认识。
4.MD060atabaseExtensions
定义客户化数据库对象，如数据表、视图、说明弹性域、值集等。
5.MD070:
ExtensionTechnicalDesign
根据MD050的要求，列出技术实现方法，如程序结构、技术逻辑等。
编码人员根据MD070编写具体的程序代码。
6.MD120:
InstallationRoutines
客户化程序的安装手册，列出客户化程序的安装步骤、安装方法。
7.TE040:
SystemTestScript
系统测试脚本。
在这份脚本中，列出要对客户化程序做哪些方面的测试，使用什么数据、按什么步骤进行测试，验收的标准是什么。
系统测试由功能顾问，通常是由设计该程序MD050的顾问来执行。
在AIM3.0中，还有TE020（单元测试）、TE030（连接测试），这两类测试是由开发人员执
行的，测试通过后，再交付功能顾问测试。
由于功能顾问测试时，不可避免地也要验证这方
面的内容（尽管可能不是特别完整），而且多数客户不要求提交TE020、TE030的结果，因
此，AIM中将这两份测试文档列为可选项”。
8.TE110:
SystemTestResult
记录系统测试的结果。
3…"
.
通常的作法是，在TE040中有实测结果”这样一个空白列，把TE040复制后改名为TE110,把测试结果填入这个空白列。
对于实测结果与MD050不一致的功能点，记为BUG,要求开发人员修改程序。
在测试过程中，如果实测结果与MD050一致，但是顾问或用户希望修改功能定义，则记为
需求变更”，先修改MD050，再由开发人员修改程序。
在项目的某个时间点（通常为UAT
开始前）之后，需求变更”需要非常严谨的审批。
【培训用户】…
1.AP140:
UserLearningPlan
培训计划。
在这份计划中，说明用户如何掌握新业务、新系统。
它应该包括对管理层的概念培训、对关键用户的培训、对最终用户的培训。
它应该定义培训的时间、培训方法、考核标准。
-
2.DO070:
UserGuide
用户手册。
-…
按照业务流程，详细写出该业务的处理方法，包括系统内的操作、系统外的处理。
一.
为了使用方面，用户手册应该按岗位分组。
有些项目中以系统功能为单元编写手册，涉及的主要是系统功能，这样的手册，应称之为系
统参考手册，文档代码为DO060。
我认为在项目实施中，DO070是必须的，DO060可以省
略（用联机帮助代替）。
除非实施合同中有特别的规定，否则，我会安排关键用户制作DO070,作为对他们培训的
考核内容之一。
3.DO030:
Glossary
实施一个新的系统，必须会出现一些用户陌生的专业词汇，AIM建议专门制作一份文档，
记录这些词汇。
如果只是从系统”角度来解释，这份文档很好做，因为ORACLE提供了术语清单（我不清楚SAP有没有，应该也有吧）。
我认为，这样的一份文档，不应仅仅是系统词汇，应该还包括客户方的业务专用术语。
作为
顾问，刚进入这个企业时，也会遇到一些新鲜的名词，把它们记录下来，从业务角度给出解释，作为经验积累、作为后续支持者的参考资料，是很有意义的。
即使是系统词汇，如果可以结合客户企业的业务和习惯说法给出解释说明，会比照抄
ORACLE的术语表更有意义。
•…
4.其他
培训考试题、考分汇总表，这些文档使用什么编号？
我从AIM中没有找到，要么，在AP
序列中自定义吧，如AP210、AP220。
【移行初始数据】…
1.CV010ataConversionRequirements•
列出要移行的数据清单、数据要求、移行时间及顺序。
有些项目在上线后，发现某些初始数据被遗漏了，导致企业的正常生产受到较大影响。
如果
事先有一份经详细研讨确认的移行清单，就可以避免这样的问题。
2.CV020:
ConversionStandards
移行规范。
对于每一类要移行的数据，说明数据格式、数据整理方法、导入方法、验证方法。
3.其他
如果要为移行编写一些专用程序，如供应商上传、物料清单上传等，涉及到功能设计、系统
测试，建议与客户化程序一样，使用TE系列文档（AIM在CV系列中专门列了一套），文档内容可以适当简化。
【上线处理实际业务】…
1.PM010:
TransitioinStrategy
上线策略。
它包括上线计划、投入的资源、可预见的意外及对应措施、支持团队。
2.PM060roductionSupportInfrastructure
支持方法。
一套高效、有力的支持流程，对于新系统的正常运转是非常重要的。
在上线之前，项目组应该确定运行支持方法，并写在这份文档中，它包括如下内容：
出了问
题该找谁、紧急的联络方式、支持团队的工作时间、在线帮助系统的使用方法等。
（”3、P,%@+V+]
【其他】
上面的文档已经不少了，可是，在项目中，可能还会发现某些文档在上面的清单中找不到。
例如，要移行的科目余额，用EXCEL提供的，它也是一份文档，有也留存价值，文档名用
升级会员 