linux项目实施总结,[转载]SAP项目实施总结

项目还没结束，但很多经验已经可以开始总结了。对于这个项目，不完善的地方有很多，有我们自己的问题，也有用户的问题。从顾问自己的角度去看――我们可以做的更好。

我们的SAP的项目包括以下的部分：

项目前期调研

SAP产品入门培训

企业需求确定(蓝图)

系统配置

顾问内部测试

用户操作培训

用户单元测试

用户集成测试

项目最终培训

系统交付与支持

从我参与的情况来看，有几个部分是需要所有SAP实施顾问尤其是初级顾问应该注意的：

1、完整的培训文档

从我们的流程来看，培训至少是包括三个部分的：SAP产品模块的标准培训(一般采用LEVEL 2的标准培训资料)、产品配置以后的操作培训、系统交付前的最终培训。

其中SAP产品模块的培训很多顾问采用的是SAP LEVEL2的标准培训文档，这类文档能很清楚的把SAP的功能模块描述清楚，同时由于顾问反复对这类文档进行讲解也容易掌握培训的时间(一般是每个模块5天)，配合IDES或其他的培训环境，用户也能快速的掌握SAP的基本操作。

2、产品配置好以后的培训

这部分培训基本上是指导用户在系统上进行操作。在我们这个阶段的实施过程中是指导用户根据已配好的模拟环境进行操作。当然用户的操作培训的具体数据也是结合他们实际的业务数据来进行的。

3、项目最终培训

项目交付前的培训大多是KEY USER对END USER的培训。只是在国内的企业中很少有明确的KEY USER跟END USER之分。各部门经理因工作繁忙往往只能参加业务蓝图的讨论，更多的所谓KEY USER实际上还是最终的操作用户。当然也有很多企业抽调了部分业务人员，组成了内部的顾问团队。很多时候客户也会要求顾问对KEY USER进行培训，这无疑加重了顾问的负担，也降低了客户在上线后自我完善的能力。

对于一个有一定经验的SAP顾问来说，大体上文档并不算什么问题，一个两个项目，甚至通过个人的渠道都能弄到。但问题是：如何将文档精细化，更贴近这个项目的USER。

SAP项目实施的难点分析

在SAP实施的过程中作为顾问很厌烦几种USER。

1、刨根问底的人

有好学的心是好的，但对于SAP这样庞大的系统没有哪个顾问对所有的业务形态、所有的栏位、所有的模块都能一一讲清楚。所以顾问特别厌烦这样的USER――甚至比那些有些愚钝的用户更厌烦。因为他们的好奇心往往会在系统中(尤其是测试系统中)录入大量的垃圾数据，有可能会影响到项目(培训)的进度，因为这些不确定的数据会影响到其他人的操作，耽误实施的进程――而他们往往会振振有辞的说：你怎么能这样糊弄我？

2、愚钝的用户

反复培训仍不能理解系统操作的人。相信每个项目都会有个别这样的人。比如我们这次的集成测试中某位用户就让我们大伤脑筋。由于系统文档上说明的遗漏，有些简单的操作她/他都无法进行下去――而这些操作在上一个步骤中已经执行过的，这仅仅是重复执行同样的操作而已。

3、繁忙的用户

和上述两种人相比繁忙的用户大概更多。因为实际的工作繁忙，他们没有时间参加培训，只能利用晚上或者其他加班时间参加。而这时就需要顾问们加班加点的培训了，而培训的效果也远涩于正常的培训，加重了顾问的负担。

下面我将就如何与上述三种人进行沟通的经验与大家分享：

对于繁忙的用户需要顾问投入更多的时间与精力――这是没有办法的事情，我相信绝大多数的顾问即使有怨言也会忠实的履行自己的职责。而我认为最好的方法却是：在用户群中挖掘可以充当教练的用户，来协助自己完成工作。说到这点，我最大的感慨是：当产品交付以后仍有很多问题需要解决，而你没有一个很好的可以协调的窗口将会给自己的工作带来很大的麻烦。对某个有潜质的用户进行深入挖掘是个利人利己的好事。当然这也要求顾问本身有良好的心态，不要怕人家抢自己的饭碗。

对于愚钝的用户则更要费心的指导。当然也并非没有技巧可讲，这技巧就是：将培训标准化。对此我的体会就是：顾问在做内部测试的时候留意同时制作相关的培训文档。并将操作规范化――我比较喜欢在做测试的同时制作相应的培训录像。这样在做后续的培训指导时可以让用户按我的操作录像一步一步的操作，省去了个别指导的麻烦。由于顾问本身对SAP的操作驾轻就熟，该点哪个字段，该如何操作都可以很快速轻松的进行――省却了用户乱点产生错误的问题。

对于喜欢刨根问底的用户，则必须注意处理的艺术。如果处理不当，这类用户很可能会成为刺头。我觉得应该从以下几个方面进行处理：

首先应该确认操作的基本步骤：何时该做什么，建立操作的标准。当有了操作的标准以后顾问可以“你的操作不规范”为由推脱。

其次应该在用户最初几次发问中说明培训的顺序：第一步是了解SAP的操作，然后才是理解SAP系统，最后去研究系统中的具体字段和流程。没有打好基础很难有本质上的提高，凡事要一步一步来。

最后应告知用户：何时会做深入的培训。我并不认为顾问可以糊弄用户，但同时也不认为：顾问应倾囊相授。在保证项目顺利进行的前提下顾问只是教授应该教的东西，至于其他额外的知识就看用户跟顾问之间的关系以及顾问的心情了。打工并非卖身。所以深入的培训，尤其是某些配置方面的高级培训，顾问可以在项目进行的最后安排时间单独处理。然而在项目的初期和中期为了保障项目的顺利进行绝不能调用户的胃口，做太多的讲解。用户根基没有打牢靠之前过多的好奇心只会对项目造成伤害。

说到这点，我相信有很多用户会不满意了：我用业余时间学习不可以吗？这点我个人的感受是：培训首先会耽误顾问的时间，打乱顾问的整体计划跟安排。其次用户在了解到某些“高深的操作以后”对于那些日常性操作的兴趣自然就散失了――而这对ERP项目的损害是最大的。正如自学SAP的过程中很多学员期望从配置开始入手，而往往在学习了很长的时间后却依然不得其门而入。在我看来，学习SAP的后台配置是需要对SAP产品和实际业务有深入的了解的前提下才能进行的。如果仅仅是了解某个地方有什么TCODE，而不能将一连串的功能穿起来，只能是事倍功半。

关于文档

SAP实施的过程中顾问除了培训外做的最多的工作就是写文档了。对于文档我有以下的一些感慨：

作为一个成熟的顾问应该拥有一套比较完整而规范的文档――除了自己所掌握的模块以外同时应包括有其他主要/常用模块的全套文档。

在这里为什么会强调“全套”二字？因为没有哪个顾问能真正拥有“全套”的东西，即使是有也不过是内容相对全面一点罢了。在实施的过程中顾问必须交付一套相对成熟的文档给客户。如果某位顾问的文档比较切合该客户的需求，那么大家可以参照同一种格式的文档来修改――修改文档的速度是远快于重新写的。尤其是格式统一的前提下，省却了调整、调整、再调整的麻烦。顾问之间相互共享资料对于加快项目的进程减少自己工作的强度也是有帮助的。

其次交付的文档也必须注意这样一个问题：没有哪个文档能把系统所有的配置都讲清楚。对于某些标准或常用配置，很多文档上是不会进行描述的。但一旦你对某个操作或者配置进行了描述烦请一定要描述清楚，否则会被用户揪出小辫子，麻烦的事就多了。而对于用户我同样的也要提醒这样一点：没有哪个顾问手头的文件能把整个SAP系统讲清楚的，即使是上千页的PA培训教材。如果你真想找这样的文件，麻烦你先把HELP看清楚，每个栏位每个栏位的看吧――如果你觉得自己比较闲的话。当然最好是看原版德文版的。

其三，在内部测试的过程中一定要记录自己测试的过程并形成录像。做录像是本人的一大爱好。我一直觉得在交付文档的过程中能同时交付该企业SAP具体操作的录像本身也是顾问敬业的一种表现。操作的录像首先制定了用户操作的标准，这比任何文字性的东西都来的更直观更全面。如果能再配上些描述或者说明的文字就太完美了。同时做录像也方便顾问自己――总不可能一次就把所有的功能都配好吧，在录像的过程中你也同时记录了自己曾在哪些地方出现过差错，方便对问题对问题的追溯。

一个项目做下来生成数十个培训操作录像，对于顾问自己也是种财富。未来实施SAP的过程中或许还能用上。这也是顾问自身积累的过程。

有人说：SAP的项目做到两三个或者三五个顾问就成熟了。然而我并不这样认为。除了那些该配的配置以外顾问更应该深入的研究SAP的产品，测试可能出现的业务场景，并一一记录。浮躁的中国ERP咨询行业是需要更多的知识沉淀来提升的。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9333231/viewspace-376665/，如需转载，请注明出处，否则将追究法律责任。