ITPub博客

首页 > Linux操作系统 > Linux操作系统 > SAP实施,转

SAP实施,转

原创 Linux操作系统 作者:Flourish2004 时间:2011-04-04 21:53:28 0 删除 编辑

SAP 实施方法论

作者 Benjamin2011 15:02 | Permalink 静态链接网址 | Comments 最新回复 (0) | Trackback 引用 (0) | 一般分类

SAP 实施方法论(SAP Implementation Methodology)

今天俺心血来潮在此特分享项目实施心得,希望有助于大家学习,当然哪里不对,请博友们多多包涵和多多指导。

SAP 实施主要分成五个阶段

1) 项目准备阶段(Project Preparation)

完成工作:

a) 建立项目指导委员会(Project steering committee

由客户和顾问团队双方组成,如设立项目总监(大多数是两方的大老板或高管担任),变更委员会成员,双方的项目经理等等

b) SOW Statement of work

投标项目合同的时候,项目范围比较大,合同或标书大多指出实施哪些模块,大体上实现哪些功能,或帮助客户解决哪些重要问题,而SOW则更具体,更细致,这个是顾问团队与客户团队围绕标书或者合同的范围来定义,SOW是实施的指导手册,也是实施后验收的手册,这个需要顾问方和客户方共同遵守和执行的。SOW写得好坏与否,一定程度上决定项目实施质量。

c) 变更管理 Change Management

有时候,顾问比较厌烦一些不停的增加需求和追加功能的客户,感觉没完没了的做,而站在客户角度既然给了钱,多加需求,多加功能是应该的,其实不然,项目实施应该在SOW指导下进行,SOW范围里要做的,顾问应该竭尽全力为客户实施,而SOW 范围外呢?客户是上帝,客户提出SOW之外的难道不做?如果不做就无法做下去了,怎办?对于这种情况我真碰到的挺多,对于客户增加需求的欲望可以理解。所以需要建立变更管理的机制,超出SOW范围的需求,先提出变更请求(Change Request),由项目委员会评估实现的难度,必要性,人天,及是否会影响项目进度等,最后决议是否在本期实施中实现

变更管理是一套机制和制度,这个是项目实施的驾驶者,这驾驶者可以保证项目不会偏离航道而顺利的到达目的地。

d) 项目组织架构,人员的职能与职责 Project organizationResponsibilities

这个容易理解,安排顾问人员和关键用户

e) 安排工作场所,办公用具;确定顾问的作息时间及服饰要求,最好制定项目实施的行为规范

由客户方提供舒适工作场所和准备办公用具如白板,油笔,打印机,复印机,文件夹等.

顾问方根据客户的工作时间和行业特性,确定顾问的作息时间,规定顾问的服饰要求,最好有一行为规范作为指导。

f) 制定项目计划

一般以顾问方的项目经理按SOW要求先制定, 在初期,项目经理根据经验完成一个大体上的时间表(Draft Planning),最主要就是在哪个时候需要交付哪些文件,每个阶段(Milestone)的时间, 接下来再与模块顾问一起制定详细的项目计划,可以精细到人天。通常会有两个版本,一个是PPT格式,另外一个是Project 格式,PPT格式用于汇报,而Project是用于管理。

SOW是指导说明书,而项目计划就是工作的执行安排了。项目计划可以随着项目的实施情况有所调整。

g) 起动大会(Kickoff Meeting

以上万事俱备之后,可以召开项目的启动大会,注意的地方就是项目实施需要涉及到的部门,经理或主管以上级别最好到场参加,目的就在于让他们领导们知道有这一项目准备实施,初步了解项目的情况。

起动大会一般由顾问方的项目经理主持,通常先请客户方的高层领导(项目负责人)和顾问方的领导发表讲话,之后由顾问的项目经理介绍项目情况,项目实施的目的,项目的组织成员,项目计划等。

h) 系统管理员(BASIS)进场

服务器到场后,系统管理员(BASIS)开始设置SAP环境,网络环境,安装SAP服务器。一般来说,刚开始的时候只会安装一台开发配置系统(DEV),条件允许会安装一台SAP培训系统(IDES)。

i) 关键用户培训(USER Training

各模块顾问给关键用户介绍SAP系统功能和标准流程(Overview Training),目的在于给关键用户先有总体认识,为日后蓝图阶段打好基础

j) 宣传项目

客户方应在企业内部多作宣传,达到公司上下都知道有这一项目的存在,体现公司上层领导对项目的重视。

以上事宜完成后,可以进入第二个阶段----蓝图阶段

SAP 实施方法论 --蓝图阶段 Blue Print

作者 Benjamin2011 12:53 | Permalink 静态链接网址 | Comments 最新回复 (0) | Trackback 引用 (0) | 一般分类

1) 蓝图阶段(Blue Print)

a) 文档模版(Document Template)和文件存放的目录结构(Directory Structure)

由双方项目经理设计文档的模版如WordPPTVisio,并且在文件服务器上设置好目录结构,如下图:

b) 现状调研(As Is

顾问准备调研文档,接着与关键用户一起到各业务部门进行访谈,访谈对象一般是业务部门的领导和业务骨干,主要了解目前的业务流程,控制点,需要解决的问题等等,此调研目的是如实地反映目前现状,顾问为主体访谈者,关键用户作会议记录,每次调研完毕后,当天或明早发布会议记录给所有与会人员。跟着顾问和关键用户一起起草现状流程清单,流程图和需求并与业务部门进行确认。

在现状调研结束时,各模块需要交付现状流程清单,流程图,流程说明文档,初步需求清单等。

c) 未来蓝图(To-Be

顾问根据现状调研的结果,结合SAP功能,先起草未来业务蓝图,包括未来的流程清单,流程图,跟着与业务部门一起讨论和修改,存在差异点或问题未解,先记录在差异清单(Gaps List)或问题清单(Issues List)。这个是反复讨论和修改的阶段,花的时间和精力很多,一般占到项目整体时间的30%~40%

有些企业上系统不是单单把原应用系统替换成SAP,还很重视流程改造,会把BPRBusiness Process Reorganization)业务流程重组与To Be一起做,不过个人建议BPR不要与To-Be 搀和在一起,因为做BPR需要不单单只是顾问的项目经验,还需要行业经验,而SAP顾问重项目实施,重实现,而BPR更着重的是战略性,方向性,指导性,做BPR应该有一组有着丰富的行业经验的行业顾问来做,而不是由SAP顾问来担当。

d) 定义主数据编码规则和各字段内容

蓝图阶段初中期开始讨论和定义主数据编码规则和各字段内容,包括物料主数据、客户主数据、供应商主数据。编码规则根据行业特性,采用自动编码或手工编码。

e) 多开研讨会(Workshop

多开研讨会,集思广益,研究重要问题和需求,要三多,多听,多想,多讨论,切勿闭门造车。

f) 收集开发需求(Development List

在蓝图的中后期需要开展收集开发需求工作,开发需求包括系统增强,自定义应用程序,接口程序,输出表单,数据上载程序,用户报表等等,并且评估优先级别,和人天

g) 边谈流程边边演示(Demo)

谈流程的过程中, 有时候因为SAP很多功能比较抽象,口述难以理解,说了半天,用户也不清不楚的,最好的办法是结合系统演示,给用户加深印象, 易于理解. 边谈流程边演示是在蓝图中常用的方法之一.

h) 蓝图验收 (Blue print Sign-off)

蓝图验收是项目的重要里程碑, 各模块此时需要交付未来流程清单,流程图(Visio),流程说明文档(Word),差异分析(Gap Analysis,问题清单(Issue List),开发清单等.

前三者通常打印出来,装订成书,分别让各个相关部门负责人签署.

有些项目因为时间紧,客户不验收就转到下个阶段,这样风险会很大,我是不赞成这样做.要弄清楚到底是何原因不签署,是流程有问题?还是政治问题?前者流程仍存在问题而继续去做,可想而知将来还是会反反复复的.政治问题大多数是钱的问题,一般来说蓝图验收作为项目的里程碑,也是客户付款的依据,所以这原因就由顾问公司的销售,老板去解决,顾问一般听老板号令好了

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

下一篇: 最动听的声音
请登录后发表评论 登录
全部评论

注册时间:2009-01-06

  • 博文量
    149
  • 访问量
    174769