ardim-
序
现在的中国，做软件咨询这行业的人已经烂大街了。
很多人从做技术转过来，SAP功能玩得很熟。
有的人从企业转去咨询公司，原先的业务很精通。
也有些人一毕业就能进咨询公司，一个项目接一个项目。
所有这些人，在这个圈子里混的人，对于怎么做项目，大多都能侃两句，说个1，2，3
什么Blueprint啦，Build啦，Testing啦，这些实施过程中的阶段，大家都说得出，都知道。
可是，大家真的都了解怎么做项目吗？
真的知道一个Deployment需要做的事有哪些吗？
真的知道一个Program中各个Deployment之间的联系吗？
真的知道为什么要这样做吗？
一，从最细节做起
我刚做项目的时候，是一个外企的Roll Out，PM是马来西亚人。
当时每个Team要做Status Report，Status Report是用PPT做的，有专门的模板
每周开会，大家在一起一个一个Team Review
PM在开会的时候，会盯住Report的格式。
增加一个页面不能用Ctrl C + Ctrl V，一定要在PPT里insert一个页面，这样才能最完整地Copy模板
每个页面的每个文本框的字体大小要符合模板
分行，分段，页数，日期格式，要符合模板
Report的内容里，一定要有准确的数字，本周计划完成几个，实际完成几个，绝对不能用百分比来糊弄过去要做的任务，要有PIC（Person in Charge），Target Day。
在描述一个事的时候，不能用“我们”“他们”之类的词。“我们”是谁？“他们”又是谁？
最后，还要写好revision history。
当时我们，特别是中国的同事，觉得好麻烦啊。花那么多时间看这些细节做什么。
字体不一样又不会有事。每个工作的完成情况，要精确到具体数字，统计起来也很花时间
不过，久而久之也就习惯了。
若干年以后，当我看到另一个国企项目的Status Report。
那个国企项目的Status Report，也有模板，但是很简单
而具体的报表内容，完全没有上面我提到的要求
结果就是，我完全看不懂。
另外，不同的Team的report要汇总在一起，如果字体不一样，换页的时候你会很明显看到差别。
Status Report只是一个小东西。但是对于细节的认真却是非常重要的。
任何一件事，谁去做，谁来review，怎么做，什么时候完成。。。
你如果不讲清楚，别人也不会知道，结果肯定是事情做不好，要不就Delay。
所以，要做好一个项目，首先请认真对待细节。
二，Logistics
这里的Logistic是指后勤，是项目中为大家提供的生活工作服务。
为什么要说这个呢？
因为作为一个Deployment，最开始的事情，是PM要解决Logistic方面的问题。
现在做一个项目，成员大多是从不同地方来的。那么住宿应该怎么安排？
通常的，PM要找几家当地的宾馆谈谈价格，有时客户那里也拿得到协议价。
住的地方不能离客户太远，上下班会花很多时间，打车费用也贵
住的地方不能离市区太远，顾问出差不能与世隔绝，也要考虑生活便利
住的地方的房型怎么样，是1个人一套还是2个人一套
2个人的话，人员怎么安排？不是随便2个男人就可以安排在一起的。
要考虑这2个人是否能相处。
往返机场，往返客户那里，找什么样的交通方式？
找固定的出租车司机还是随便在马路上打车？
要知道，安全是第一位的！
吃饭的话，Team Member有没有忌口，有没有国外的习惯
在客户那里，办公在什么地方，
一个项目20个人左右，加上Key User，怎么坐？
一般会说一个Team做一起，那么Team和Team之间的交流呢？
FI和CO要近一些，PP最好和MM近一些
顾问和Key User最好隔着坐，不要顾问只管自己，这样方便沟通
办公的地方，出入证明，电话，传真，打印机，复印机，饮水机，网络，空调，投影机，会议室
等等这些资源都要安排好。
把Team Member的名字贴在位子上方便别人找到
做一个通讯录，最好打印出来发给每个人
......
其实要说清楚Logistic的事情，实在是太多了。
可是你知道吗，这是PM要负责的事情
因为这时候项目还没有开始，人员还没来。
而且很多牵涉到费用，PM需要控制成本。
当然有的时候PM会找人帮忙，等项目开始以后让某个人来管。
但是，这始终是作为一个Deployment开始所要做的事
也许很多PM做这个比较随便，甚至很舍得花钱。
但我想说的是，事情做得好不好，关键还是在细节。
安排的资源有没有考虑别人的感受想法。
要考虑如何才能大家不用抱怨环境差，开心地工作。
三，Global Template
让我以一个Global的Program为例子吧。
什么是Template
通常的，在一个跨国企业实施SAP的时候，要面对的是不同国家，不同工厂
不同分公司业务也不一样，有些是生产型的工厂，有些是贸易公司
那么作为跨国企业，一般都是要把业务整合在一个系统里。
在SAP里就是1个Client，里面分多个Company Code
Company Code就是单独的分公司
所以在开始真正实施SAP之前，就要考虑整个企业（Client）的架构
包括统一的业务流程，统一的解决方案，统一的数据格式
这样一些统一的东西，就叫Template
我们自己的说法，也叫Global Template
等设计完了这些之后，再去一个一个工厂实施
在工厂实施过程中，肯定会碰到和Template不一样的需求，这时候也可以再修改Template.
Template包括哪些内容
首先是组织结构
要控制这样一个Template，就要有一个专门的Team来管理，GT Team (Global Template Team)
这个Team里每个人是一方面的专家，比如FI，MM。这些Team Member面对的客户的人，是整个企业这一级别的BPO（Business Process Owner），比如CFO。
在每个Deployment实施过程中，Deployment Team碰到的需要更改Template的需求，都要报告给GT Team，由GT Team负责协调其他Deployment，看是否能做这样一个修改
比如说某个Deployment想在物料主数据里用某个字段来放一些参考信息。
可不可以呢？这就要考虑，这个字段在SAP的标准功能的用途是什么，
物料主数据是被所有工厂都通用的，其他Deployment实施的时候会否用这个字段
这个字段在系统的报表里会不会被用到
......
Template的重点是Blueprint Design
物料主数据的命名规则是什么？
什么物料用什么物料类型？
集团的科目怎么定义？
Cost Center，Profit Center，Product Hierarchy
要不要用Material Ledger
要不要用Split Valuation
Document Type用哪些？Number Range是多少？
......
统一的Process
比如采购申请，谁提申请，谁批准
比如生产订单发料，是Issue to Order，还是Backflush，还是都可以
......
统一的权限控制
设置Common Roles，Deployment只要Copy 这些 Roles就可以了
......
Template也包括程序开发
有些report是整个企业都会用到的，那么就在Template里做好
到Deployment时期只要用就可以了
......
还有Document Template
所有的文档的格式，Status Report，Data Conversion Template，To Be Process，
当然包括我一开始提到的字体大小，分行分段等等，都是在Template里定义
怎么做一个Template
很遗憾，我没有做过Template，所以这部分我说得不仔细
做Template也是个单独的项目
一般在Program开始后，在Deployment开始前
企业会召集很多人，有顾问有用户，用户可能来自各个工厂
过程也象做项目一样，业务调研，蓝图设计，系统搭建，文档准备等等
为什么要做Template
很难想象，如果没有Template，怎么为企业实施一个整合的SAP系统
Template的好不好，还是取决于细节
当我一开始看到Template所做的文档，我很惊讶，居然把项目中要用的文档都做得那么详细
很多时候，我们只要Copy过来，改几个字就可以用了
看着Template，就可以很轻松地去工厂实施。
所以，一个好的，详细的Template，是整个Program成功的前提
四，Capture Local Input
有了Template，接下来就是去分公司/工厂做Deployment了
前面提到，不同的工厂业务不一样，Template不一定完全适用
所以在开始Deployment的第一个阶段就是Capture Local Input，中文来说就是收集当地的需求
那么怎么来收集需求呢？
首先要准备介绍资料。介绍SAP系统，介绍Template的设计
介绍资料一般用PPT做，用于在Workshop上跟用户讲解
其中的重点是，要用用户看的懂得方式去介绍。
我看到过一些人写的资料，包括培训材料，完全是走技术路线
说说用到哪些功能，T-code怎么样，在系统中产生什么Document，就结束了
可是，另外的，可以写一些：
1.名词解释
2.企业有什么Policy，来让我们决定Template的设计
3.原来的业务流程是什么，Template会改变什么，有什么Benefit
4.对于权限有什么影响，对应于业务上的什么部门的什么岗位
要记住我们在Template的基础上做实施，就是要做好功课，才去工厂Capture Local Input
介绍资料之后，还要有一个Question List
哪些物料类型会用到？
不能直接问有没有产成品，原材料。
可以问，有没有Packaging Material，比如Chip Board，Wood Pallets，Wood Containers
有没有Petrochemicals，比如Fuels，Industrial Chemicals，Lubricant
......
哪些Payment Term会用到？
比如见票30天付款，见票60天付款
......
在Template的基础上，就不要问很基础的问题了，要跟实际业务相关，能直接帮助之后系统设计的问题
在Capture Local Input阶段，通常会召集不同部门用户来开Workshop
召集的用户人员，范围，需要仔细研究
一个用户不能同时参加MM和FI的2个Session。所以有必要的话时间要错开
有的Workshop，需要BPO参加，要事先打好招呼发invitation
有的Workshop需要不同Function Team一起讨论，称为Integration Session
经过Workshop，要把Local Inputs记录下来，成为Local Inputs List
在这个List里，当然的，要包括
1.简短的一句话来描述这个Inputs
2.详细介绍
3.谁提出来的
4.提出的日期
5.对应的BPO是谁
6.分类，这个每个项目可能不同定义
7.需求类型，这是个Config相关的需求，还是Data Conversin相关的需求
8.是否影响Global Template
9.Priority，这个Priority有专门的定义，不是用户说High就是High的
10.谁负责跟踪这个需求
11.可能的解决方案
12.状态，Open还是Closed
这里要提到的是，记录的需求多没关系，只要跟踪好，稍后跟用户确认，状态Closed掉就可以了
就怕2种用户，说话太多和说话太少
这阶段嘛，项目经验还是很重要的。很多需求在Workshop时就可以砍掉了
另外，报表的需求也要在这阶段收集
重点是在这阶段就要做rationalization，合理化。
要知道，开发的需求搞得越多越烦，一定要砍掉，砍掉，砍掉。
最后，PM需要每天开会，Review Status
今天收集了多少local inputs, High的多少
不断地跟踪状态。
结束的时候，Local input list要跟BPO确认，作为下一阶段Blueprint Design的依据
五，Blueprint Design
Blueprint Design阶段，主要的时间在针对Local Input来讨论Solution
也就是说，收集到需求，都要在这一阶段找到解决方案
其中，有3个文档是最重要的
它们是Blueprint，To Be Process和Data Conversion Approach。
什么是Blueprint？
有一些比较概念性的介绍，比如这是系统的设计，解决方案....
实际的，这是一系列Word文档
每个文档对应一个模块，里面详细介绍各个功能设计
文档里要包括对于这一功能的需求介绍，详细的需求分析和解决方案，对于这一个Deployment的特别的结论
比如说，Physical Inventory 库存盘点
1.用户的需求是什么？保证库存准确率？和财务的Balance一致？
2.详细的需求呢？库存准确率是按Plant level还是Storage Location level？要不要用Cycle Count？
3.解决方案呢？A, B, C分类怎么定义？库存调整的Reason Code用哪些？
4.关于这一个Deployment，和Template有什么不一样的地方？
关于To Be Process，大家肯定看过到很多了
只是，这里要强调一下文档的规范
使用的符号，标注的方式，页眉页脚，都要根据Template来做
不然人家也很难看懂啊
Data Conversion Approach，简称DCT，是对于Data Conversion指导性的文档
里面包括，在这一个Deployment有哪些Conversion Items。
原始数据是哪里？数据量有多大？谁提供？谁协调？谁确认？
现有的SAP数据上传模板可不可以用？
原始数据怎么转成SAP的数据模板？字段怎么对应？比如在老系统里某字段的字符长度大于SAP的字段长度，怎么解决？
......
这3个文档，是Blueprint Design阶段的关键
整理好这3个文档以后，要跟BPO review，并且sign-off
作为下一阶段Build 系统的依据
除此之外，要开发的东西的列表也要在这一阶段确定下来。
项目实施，是一环接一环的，
你收集的需求不完全或者不准，那么你的Blueprint Design肯定也不完善
你Blueprint 阶段还留下一些需求没有解决方案，如果这样开始Build系统的话，以后肯定有问题要返工
每一阶段完成的标志是BPO Confirm。Sign-off以后不能随便改。
当然不是说不能有新的需求，也有的客户不重视sign-off
但是作为PM，要坚持这样的approach，要guide用户按这样的approach来合作
制订这样的approach，是项目管理中最重要的事。
六，Build and Testing
研究技术问题是中国人的强项。
很多强人对SAP的配置很熟悉，知道能不能在SAP里能实现某个功能
但是，光了解技术，要做Consultant是不够
首先介绍一下系统环境
在SAP里，不同的Client就是不同的环境
通
常的，有一个做Config的Client，一个做Development的Client，一个Sandbox的Client（随便改随便用）还有一个
SIT的Client，一个UAT的Client，Training的Client，Mock
Conversion的Client，Production的正式Client，User Support的Client
做Config的Client不能做任何Transaction，做好配置以后能自动传到Development Client
在Development Client里做Component Test
Development Client同时也是做开发的Client
因为在Config的Client里，如果做任何Transaction，有可能有的配置改不了
比如Number Range，你做了一个transaction，号码就跳了一个了
而Development需要测试程序，所以Development Client需要测试的数据
在做配置的时候，首先，要有一个Config List
这是一个Excel 文件，包括所有SAP IMG里面所有的配置项
单独用一列来标识，哪些Config 需要在这一个Deployment里做，哪些是Cross Client的，哪些是Corss Company Code。还要记录Transport Request号码
另外，当然是Config Notes了，相信大家看到过很多
Transport是Basis控制的，这方面要跟Basis协调好
谁提request，谁approve，什么时候传
一般在大的项目里，不是你想改就改配置的
要经过GT Team Approve
Testing分Component Test，SIT和UAT
Component Test就是你做好了配置，要去测试环境里试一下配置可不可以用，这部分不需要用户参与SIT和UAT都取决于你的Blueprint Design阶段
Testing Script来源于To Be Process
跟用户确定过哪些流程，当然就要在系统里都试一下
比如创建个物料主数据，做个销售订单。。。。
SIT和UAT的Testing Script都需要跟BPO确认
SIT和UAT的Testing Script结果都需要User Sign-off
SIT和UAT的区别在于
UAT的范围大于等于SIT，有些To Be Process比较简单，很少用到，那么跟BPO确认一下，SIT测了以后，UAT就不用再测了
SIT和UAT的用户范围不一样，SIT参与的用户是Key User，UAT参与的用户是Selected End User
还有Integration Test，是指有些流程是牵涉到3个以上模块的
比如Make to Stock，Make to Order
Integration Test在SIT和UAT阶段都会存在
Testing Script，Testing Data要事先准备好，
安排测试的时候，要注意用户的时间不能冲突，有的用户参加Integration Test和某个模块的Tesing，那么时间上要分开
七，Data Conversion
Data Conversion不只是上线前把数据导进去而已，而是贯穿整个项目实施过程所要做的事
一定要有一个专门的Leader，来负责盯这部分工作。
在Capture Local Input的时候，要确定Data Gathering Scope
对于每个模块，有哪些Conversion Items，数据源是哪里？谁提供数据，谁负责收集，谁Approve，数据量估计多少
在Blueprint Design阶段，要完成3个文档
DCA（Data Conversion Approach），DMM（Data Mapping Matrix）还有DCT（Data Conversion Template）
DCA里面要详细描述每一个Conversion Item怎么样导入SAP系统中
要怎么详细呢？
比如说，用户现在的数据要清理吧，那么怎么清理呢？
采购订单没有收货的怎么处理？收完的？收了一半的？发票先收了的？发票收了一半的？
数据怎么从用户的系统导出来？手工还是有工具？工具谁准备？谁测试？
DMM是用于Mapping用户系统和SAP的字段的
不同系统中，即使同样的字段，字符长度也可能不一样，更不用说一些物料参数了
DCT是用于上传到SAP之前的模板，基本上DCT里的字段完全对应SAP里的字段了
在Build and Testing阶段，要做Conversion Tools Build & Test
这个好理解，就是开始按照之前的DCA来做事
在这一阶段，同时要展开的是Mock Conversion
通常的，Mock Conversion会有3次，Mock 1，Mock 2和FDR
为什么搞这么多次呢？
Mock
1的目标比较简单，可以只准备Go Live的30~50%的数据，生产型的企业可以准备一个完整的BOM。这样的Mock
Conversion，可以为SIT准备基本的数据，可以估计上传数据的时间，可以测试上传工具，可以保证用户了解Data Conversion全过程
Mock 2的要求就比较高一点，数据量要求Go Live的75%左右。
Mock 2的数据要为UAT做准备，需要取一个月底的时间，可以核对财务和物流的余额
FDR就是Full Dress Rehearsal，完全模拟上线的情况
上传数据的量和时间安排都要参考Cut Over的要求来做
而且FDR过程中的数据需要Sign-off，总之要模拟上线。
同时，很多这一阶段准备的数据也可以用在Cut Over的时候，比如Material Master，不用重复准备了。
Data Conversion是很重要的工作，可以通过它来熟悉用户的系统
没有经过好的Mock Conversion，怎么能保证上线能顺利进行呢？
最后，在系统上线前，那就是最终的Data Conversion。要安排好Conversion Plan
每一个Conversion Item，哪一天Upload，顺序是什么，有没有dependency
估计需要多少时间上传，数据量？谁负责上传？以及任何相关问题的跟踪。
八，Authorization
在实施项目的时候，权限是谁来实施的呢？
不是Basis，是Function Team。
Basis应该负责具体在系统中创建Role以及transport之类的工作。
但是关于决定需要哪些role，分别有什么权限，应该是Function Team的工作。因为Function Team会了解业务，知道Role应该怎么设置
权限的实施也不简单
首先，作为Global Template，已经有一套Common Role，在做Deployment的时候，就是要把这些Common Role copy as Local Role，有一些更改的作为Variant Roles
1 在做Blueprint Design的时候，要做Legal Entity Map onto Role
在这一个Deployment用到几个Company Code, Plant，哪些Common Role会用到，要列出来
2.Confirm SAP Tcode to Role Mapping
同样的，经过Blueprint Design，哪些T Code会被用到也应该知道了，要检查Commone Role里面是否都包括还有一些本地的开发会有新的T-code可能要加进去。
任何改变都需要创建Variant Role
3 Confirm Roles to User ID Mapping
这
是一个Excel文件，首先要用一个Sheet列出所有的用户信息，名字，ID，Department，E-mail之类。还有Role
Description，这个文件给用户看，当然要让用户知道每个role是做什么事，不要技术性的描述。还有SOD
Control，根据Sarbanes-Oxley所制订的审核原则，要用户知道什么role和什么role冲突。后面是重点，User ID
Mapping to Roles，这个不用多说了
这个文件应该交给Key User去完成，最后要BPO sign-off
不同的Team可能用Corss Team的权限要求，比如MM User想要财务的权限，
这就需要Authorization Leader去协调
4 接下来就是交给Basis Team去创建Roles了，技术方面的东西就不说了
5 权限测试
分2种测试，单独的Role测试和基于User ID的测试
为每一个Role创建一个ID，一个ID只有一个role，登录以后测这个Role的权限
为每一个User创建一个ID，在测试系统里，按照Function的操作测试用户的权限
6 最后，就是上线的权限准备了，
把Role传到生产系统里，在生产系统里创建ID，设置有效时间等等
这里要提到的是，权限的更改是正常的业务流程，只有要改T-code之类要transport的才是Issue
这在上线以后要特别区分开。
nicehost-
ERP实施入门
1.初次调研：
主要的目的就是ERP软件提供商的实施顾问人员能够对企业各个部门的业务流程初步了解，能收集到各个部门业务流的所有单据，和各个部门人员的认识，了解他们对ERP的认识和期望，以便制订工作计划。
2.系统培训：
主要的目的就是能够让企业所有人员认识到什么是ERP，并在企业中应用ERP系统能给企业带来如何的效益，另外就是ERP软件的各个系统的功能培训。
3.流程拟定：
主要的目的是实施顾问人员根据自己对该企业的了解结合自己或所在公司对企业所在行业的累积经验，结合ERP系统拟定出一个符合企业需求的业务流程，能在系统中得到合理的体现；这是一个非常重要的阶段，一个企业的管理能否从此通过ERP得到提升，流程能否更完善，就需*这个流程拟定了。
4.编码原则：
主要的目的是企业能在实施顾问人员的指导下，制定企业应用ERP的基本原则，其中包括物料的编码原则、供应商、客户的编码原则、产品结构（包括BOM架阶）的分阶建立等。
5.资料收集：
主要的目的是企业的人员在熟悉了各项编码原则的基础上，收集企业应用ERP管理所需要的基本资料，包括物料资料、供应商、客户、部门、人员等收集。
6.流程测试：
主要的目的是企业的人员测试流程拟定的合理性，并使用企业实际的业务流程来测试ERP系统的功能完善性，和操作的方便性。
7.期初导入：
主要的目的是搜集ERP系统上线的期初数据，并在实施顾问人员的指导下录入ERP系统，为企业正式应用ERP系统奠定夯实的基础。
8.上线辅导：
主要的目的是将企业的实际业务数据在ERP系统中处理，一般在系统上线的第一、二个月的时间里面，有必要的又模式进行，以防企业人员在上线期初操作不熟练所造成错误。
9.月结辅导：
主要的目的是在应用系统一个自然月后，通过ERP系统来跑出企业管理所需要的各种报表、检验报表的完善性，数据的准确性。
当然，一个企业中要成功实施一个ERP系统，单纯的*以上九个步骤是远远不够的，ERP的实施是一个非常规范的过程，所以，我们在这里将这过程分作为两大块。
一、以实施文档全面贯穿实施过程：
作为实施顾问人员，在实旋的过程中，应将各种标准的实施文档提交给企业，以确保ERP实施项目的质量进行，也就是说，顾问与企业之间的工作与文档的制作息息相关，可见文档在实施进程中的重要性非同一般。
那么，文档到底对整个实施工作有怎样的作用呢？首先，我们大致将ERP实施中的文档作为一个分类：
? 分阶段实施计划文档
? 分阶段目标设置文档
? 标准业务流程文档
? 标准编码、标准数据文档
? 标准参数设置文档
? 功能操作指南文档
这些文档将会伴随着ERP实施的各个阶段逐渐充实、完善；也同时记载了整个实施的过程和成果；那好，现在我们来分析一下这些文档的价值所在：
1.书面化的文档有助于实施人员与企业人员明确了解各自的职责，信息互通，共同把握实施过程的节奏。
2.标准业务流程文更有助于双方明晰业务流程，有效配合业务流程的重组和优化。
3.标准编码、数据文档及标准参数设置文档是实施中不可缺少的基础资料，可有效减少重复工作，避免对正常工作的影响。
4.功能操作指南文档可帮助最终用户规范化操作，加强培训效果。
前面我们曾经提到，ERP的实施工作可能长达数年不定，在这个时间跨度中，企业在最初实施ERP时确定的ERP项目的人员，也许难免要发生一些变化，那么，在发生变化时，ERP实施文档就可以承担起指导双方快速工作的标准文档的作用；还有，当实施完成后，企业的运行过程将是更漫长的过程，那么实施的标准文档就将成为企业实施信息化的公共载体了，成这指导企业后续工作的航标，和企业在后续人员培训方面提供详尽的素材。
二、培训全面贯穿实施过程：
在ERP实施的过程中，培训始终是作为一条主线的，具体点说吧，在系统实施过程中，培训对象包括以下四类：
企业领导层、核心小组(项目负责人)、技术小组、最终用户
1.企业领导层培训，对高层的培训主要是ERP管理理念的培训，通常会由软件提供商安排较资深顾问师对企业领导层进行ERP管理思想的培训，使得企业领导层能够从总体上理解ERP系统的理念、流程和功能。
2.核心小组（包括项目负责人、部门经理）的培训，对於这一类的培训内容包括ERP系统的管理思想概念、ERP系统的具体功能以及ERP系统各种报表的应用。
3.技术小组培训，技术小组的成员主要包括参与ERP系统及相关Database和网络安装、设置及管理的信息部门成员。培训的主要目标是提供ERP系统的设计结构，各个模块的关联关系与数据库结构，系统问题处理等。
4.最终用户培训，培训目的是使用户了解ERP系统后新的业务前景、目标以及带来的好处，使用户能清楚的了解到ERP是什么，怎样通过它提高个人及整体的业务表现，使用户发角其工作内容的变化及ERP将如何融入其日常工作。同时向用户提供从现状到未来迁移过程中通用的术语，提导用户如何使用ERP完成其工作。
ERP的实施过程中的培训作为实施的一条主线，既体现了ERP实施很高的附加值，又充分体现了ERP实施过程中的知识转移。把ERP从半成品到成品的过程实质就是知识转移的过程，其中包含企业的管理诊断，实施战略的选择，业为流程的设定，对企业需求的恰到好处的分析。
上述中，企业信息化是一个长期的过程，在这个过程中，成熟完善的ERP系统是信息化成功的前提，严谨科学的实施方式是保证ERP成功上线的关键。