如何在erp实施上尽快入门？

贴出来希望这点文字可以抛砖引玉，有经验的人一起探讨一下。

我下面的方法是针对SAP的项目，所以关于其他软件，或者是特别的软件开发项目，可能有不一样的地方。

序

现在的中国，做软件咨询这行业的人已经烂大街了。

很多人从做技术转过来，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

这在上线以后要特别区分开。

九、Training and Change Management

Training，通常的我们会想到Key User Training和End User Training

可是想得仔细些，仍然有很多事情需要注意

1.有哪些课程？

通常和To Be Process是联系在一起的。创建销售订单是一个培训，审批采购订单是另一个培训

当然也可以根据需要，有一些Integration的培训课程

2.有哪些课程需要在这个Deployment做？

这个Deployment需要哪些To Be Process，就需要哪些Training

3.怎么确定参加谁来参加什么培训？

根据权限的安排。有创建采购订单的权限，就参加维护采购订单的培训

不可以按用户的喜好，什么想多学一点，搞到后来就是安排不过来

4.Traing Agenda怎么安排？

首先，估计每个课程需要多少时间，再看参加的人员是否重复，还要考虑教室的安排

5.培训材料怎么准备？

当然要用用户看得懂的话，这个谁都想得到，关键是怎么写

有的人习惯的技术工作，是写不出“用户看得懂的话”的

可以写什么呢？比如这个课程的业务背景，Blueprint Design，谁来做，根据客户的什么Policy，原来怎么样现在怎么样，有什么Benefit……

6.关于反馈

认真点做培训，当然要收集反馈意见，

不只是用户对讲师的意见，还有用户自己的Evaluation

7.其他要注意的

谁发邀请给用户来参加培训？什么时候发？

教室大小，有没有足够的位子？有没有计算机？网络？投影仪？白板？水？

培训材料的打印？签到？

演示用什么Client？用什么ID？用什么数据？谁准备？

什么是Change Management？

Change Management做些什么事？

我还是直接点，说说Change Management要做的事，你就知道什么是Change Management了

1. Focus Gp Workshop

要协调一开始的收集Local Input工作，安排会议，教室，安排人员等等

2. Localize Training Material

培训材料不可能每个Deployment都准备，Global Template应该已经有了

要把这些培训材料改成符合local design的，Change Management是协调者

3. Train The Trainer

这个大家经常听到，就是要教培训的人, Function Team的人讲课要注意什么

4. Change Readiness Survey

准备各种各样的Survey，包括对培训的Feedback

5. Pre Go live Briefing

Go Live之前要通知大家吧，要告诉所有人，即使没有参与这个项目的人发生了什么

6. Go Live booklet

小册子，要包括一些上线后的注意事项

比如新的流程开始了，有谁是联系人

7. Go Live Event

这个比较轻松，准备一些活动

8. Regular communication to the employees

定期让用户知道项目情况，比如用黑板报

9. External communication

上线前要跟供应商，客户沟通好，告诉对方我们上系统了，新的采购订单，销售订单的格式有没有变

10. Go Live Communication Letter

正式上线要Announce一下，发个邮件。

十、RICEF

RICEF就是Report, Interface, Conversion, Enhancement, Form，SAP中开发的几个内容。

本节和技术无关，只是说在项目中怎么来实施RICEF

首先，在Capture Local Input阶段要收集RICEF Requirement

用户需要什么报表，什么接口，

Priority是什么，Complexity是什么，Frequency是什么，每天用还是每月用一次

对于这些Requirement要进行分析

SAP的Standard报表可不可以用？GT Template里的报表可不可以用？

这个Requirement是完全新的开发，还是在已经有的开发上的修改

这个开发只影响这一个Deployment，还是影响整个Program

这个需求是一个Business Requirement还是Legal Requirement

谁提的需求，对应的BPO是谁？

估计的开发Man/Day是多少？

上面这些考虑的因素都要都固定的标准，比如Complexity，怎么样算容易？怎么样算困难?

报表用到1个table算容易？用到4~5个table算困难？

这都要development team先做好相关文档

收集Requirement的同时，就要做rationalization，砍掉不必要的需求

千万记住，越多开发，到后期就越麻烦。

有的人觉得给客户多做开发，到以后客户就离不开这家咨询公司了

可是，做项目不应该是这样的，挣钱不是靠大量的开发的。

等到rationalization之后，Blueprint阶段就要跟BPO确认RICEF List

定下来具体会做哪些开发。

是Go Live前需要还是上线后1个月需要。

确定RICEF List以后，也是为了确定Go Live之前不要变出其他需求而影响Go Live

虽然通常用户会有新的需求出来，但是实施的时候可以说那些新的需求我们另外再处理

如果不确定这个RICEF List，那么怎么样才算做完呢？永远做不完了。

确定RICEF List之后，就要联系Development Team，安排开发计划

一般Development Team和Deployment Team是分开的2个Team

对于开发人员的安排，要计算的是Man/Day

比如总共3个ABAPer，100个Man/Day，怎么安排？

虽然报表说是Go Live的时候需要，但是不能Go Live前才做好，因为还要测试之类的事。

应该设定的目标是UAT之前做好开发。

Function Design什么时候可以做完？什么时候Sign-off？FD Sign-off之后才能开发。

每个RICEF估计要多少时间开发？

即使所有报表做完，也要留一个人做bug fix，这也要算在Man/Day里

做好计划以后，要跟Function Team沟通，安排相关的人员写Function Design

控制跟踪进度。

Function Design有没有写完？有没有Sign-off？

Coding in Progress？Coding Completed？Unit Test in Progress？Unit Test Completed？

UAT什么时候开始？UAT Sign-off什么时候？

Deployment Team需要一个RICEF Leader去协调，组织相关的事情，跟踪进度。

有的时候，报表需求影响整个Program，还要去Global Template审批

比如PO form，各个工厂都用同一个程序，你改这个程序可能会影响其他工厂的。

最后，要把这些RICEF全部开发完，要handover给support team.

给他们文档，解释function design.

十一、Cut Over

做完一个项目，印象最深的通常是Cut Over

一方面Cut Over比较接近项目的尾声，另一方面Cut Over会很忙，加班比较多

Cut Over不只是Data Conversion，还包括很多很多其他事项

Cut Over有4个阶段：Plan，Prepare，Execute和Deploy

Plan很好理解，Prepare就是协调准备Cut Over的内容，比如准备上线的小册子

Execute就是正式上线切换所做的事，比如数据导入的操作

Deploy就是启用新的业务流程

主要的Activity有6个方面

1.Process & System Readiness

这当然是说项目实施方面的Delivery。

Business Issue要解决，系统配置要传到生产系统里，

报表要开发好，权限要分配好

2.Data Readiness

对于数据切换的工作

数据传到系统里，BPO sign-off

3.People Readiness

用户培训做好，用户调研做好

告诉用户上线后的支持流程

4.Technical Infrastructure Readiness

客户端要装好，生产环境，测试环境要准备好

用户ID，系统备份准备好

5.Physical Environment Readiness

用户的工作环境准备好，上线后支持人员的环境准备好

一些手工填写的申请单的格式有没有更新好

6.External Parties Readiness

供应商，客户是否准备好了？

政府机关，审计公司有没有准备好？

然后，我们需要有一个Check List和一个Detail Schedule

Check List中，对于上面提到的6个方面，把具体的Avtivity列出来

对应的Timeline，PIC，Status

Detail Schedule一般是指Go Live前1个月的每一天要做的事情和Data Upload那几天要做的事情，精确到分钟

为了完成Cut Over，我们还需要有很好的组织结构

首先要有一个Cut Over Leader来协调所有事情

然后6个方面的Activity每一个方面都要有人负责

负责人要同时有Deployment Team的人，和用户的人

让每个人知道自己应该在什么时间做什么事情

Cut Over的时间安排，可以从Go Live往前推

什么时候系统可以准备好？接着数据上传。

数据上传后要做Shakedown Test，就是在生产系统测试一下

之后就是Go No Go Meeting，评估Cut Over Avtivity是不是都做好了

之后，可能还有一些Data Catch up, Month End Close

什么时候Go Love？什么时候老系统Shut Down？

Cut Over有很多事，通常会加班。

但是加班并不是必须的，我就经历过没有加班，周末也休息的Cut Over

重点在于计划要做得好，大家配合。

十二、Support

Go Live之后，项目组通常会有一段时间的On Site Support

可是这Support也是有讲究的，不只是解决问题而已

首先是组织结构，通常做项目的人想得到的，是End User的问题先找Key User，Key User找顾问。

那么这样就要分清楚每个部门对应的人员。以及联系方式。

除此之外，还需要有一个Support Leader来协调和统计Support的问题

有问题总是要记录下来，但是怎么记录呢？记录在哪里？什么样的问题要记录呢？

我以前的项目是用SAP Solution Manager

在Solution Manager里面，用户可以自己创建Support Message，选好模块以后，系统就会关联上对应的顾问

同时还有很多选项，比如Priority和Type。

这样的方式很有用

因为，让用户去写Support Message，而且要求用户写得详细，这样，用户有的小问题，可能只是操作不知道，就懒得记在Solution Manager里了

用户自己也会知道，只有正式的Issue才需要记录下来。记录下来的Issue才会跟踪处理。

关于Priority，需要事先确定什么是High，什么是Low，不能用户自己感觉自己说了算

关于Type更有用了，怎么分清一个Issue和一个Change Request呢？

比如报表问题，有的用户发现报表有错误，这是Issue，有的用户说报表要增加1个字段，这是Change Request

怎么分清一个Issue和一个正常的业务呢？

比如用户权限问题，有的只要给用户加一个Role就可以了，这是正常的业务流程；有的是要改Role的设置，要Tranasport的，这是Issue

这些都要在Type里面区分开来。

还有比如创建一个物料主数据这样的事，就更不能当做Issue了。

对于Support来说，首要目标是减少Issue，不能有High的Issue，其他的么Change Request之类存在是很正常的。

对于Support的统计，也不能只限于解决多少Issue方面。还有对系统的Stabilization 分析

每一天，创建了多少物料主数据？创建了多少Vendor？创建了多少PO？

这些都要进行统计，要综合起来看

想想如果用户这一天，没有一个Issue，但是一个PO也没做过，这算有没有问题呢？

Support最后的工作，就是要Handover给长期的Support Team

你不想一直在这家客户做下去吧。

在Handover的时候，当然要准备好Handover Check List

列出项目过程中做过的文档，然后开Handover Session，给长期的Support Team解释Solution

一般Handover的时候要求所有High的Issue都要Closed

十三、Evaluation

通常的，项目会上线的，通常的，上线后，人走了。

可是，怎么知道这项目做得好不好呢？这项目带给客户的是什么呢？

实施ERP项目的意义是什么呢？

对于正规的项目实施来说，Go Live，人走了，并不是结束。

3个月后，应该会有Senior的人来做Implementation Review，看看项目实施的情况。

怎么来Review？

因为去Review的人不多，而且是Senior Manager，我本人并没有这方面的经验。

所以只能根据看到的一些文档做解释

我印象最深的是RICEF。

之前我们提到，RICEF是开发的东西的总称。通常用户提出需求，顾问给用户开发。

Review的时候，就可以看每一个报表的使用率有多少，系统里可以记录每个T-code运行的次数。

想想，一个客户化的报表，一个月只使用2～3次，说明什么？

说明这报表是不重要的，这个开发是多余的，需求分析是错误的

除此之外，还可以

看看上线之后3个月有多少Issue

上线之后系统的使用情况，具体做了多少订单，多少凭证

是不是所有的业务都做到系统里去了。

能不能及时关帐

Project Cost方面，这个项目的花费和之前的计划差多少？

客户化开发花了多少钱？

项目的交付的文档全不全。

在评价一个项目做得好不好的时候，其实在任何工作时，要尽量用具体的数字来说明问题，

这样才有说服力，别人才能清楚地了解情况

任何好，比较满意，80%之类的词都是模棱两可的，那只是在捣浆糊

后记

谢谢你看完这个帖子，这只是我的一点工作体会。

对我来说，把这些写出来也是个整理的过程。

发在这样的论坛，比较轻松，不用去追究理论上的项目管理是怎么样的

其实我想说的，是一种做事的态度。

我遇到过很多顾问，即使是在一流的公司里，也有很多人不知道怎么做项目

做事没有计划，不知道怎么handle客户，文档做不来，细节不考虑

我写的这些东西，我所说的做事方法，如果周围多一点人按这样的方式去做事，我也会轻松很多

可惜的是，即使你看完这个文章，你只能了解个大概，仍然不会去做项目。

比如我说High/Medium/low要有定义，那么怎么定义呢？

因为那些细节，只有你真正去做，才会理解，最终成为你自己的东西

可是没关系，我只是希望能多一点人，理解我所说的态度，

在自己的工作岗位上，认真仔细，做好自己