第一篇：sap实施过程

sap 项目实施过程了解

三、项目实施过程说明

SAP为独立实施的项目提供了面向过程的、清晰的、准确的实施路标。这个路标起到了项目向导的作用，用来确定步骤，明确转折点，并且通常用来设定整个项目的进度，使得可以使用最优的预算和资源，快速高质量的生成一个新的系统。ASAP路标包括下面几个阶段：项目准备，业务蓝图，实现，最后准备以及上线支持。

1、项目准备阶段

项目准备阶段主要是建立项目组织，包括项目团队、角色和职责。这一阶段确定系统实施的目标。还要确定项目的基本构造，包括硬件、网络要素。执行正式安装的规模和指标，并且初始化SAP系统。1.1 定义项目目标和范围

SAP项目的任务和目标须与公司未来3-5年内的任务和目标一致。指导委员会的重要责任就是决定SAP项目的实施范围。SAP推荐使用“大爆炸”的方式，即公司一次性实施SAP大部分标准的功能和针对公司的特定行业解决方案。只有通过“大爆炸”的方法才能使公司将SAP系统所获取的信息作为一项资源来使用，如人力、材料、资金，而不是把SAP当作是记录和报表系统。一个综合系统的真正优势只有在公司的所有实施点和办公业务都在SAP平台上运行时才能得到真正的体现。

1.2确定项目组织和资源

建立项目资源计划，项目资源需求包含以下几点：

在合适的阶段分配和支付财务预算；

获取并按照计划来配备相关的系统硬件、软件、网络系统；

选出业务骨干，这些人是他们所在部门的主要成员，并且被任命为功能团队成员，他们被赋予为系统进行全面调试和对最终用户进行培训的任务；

1.3 定义风险控制策略 SAP实施项目是一个标准软件包的实施，主要风险包括： 合适资源的缺乏；

在实施范围和系统功能的问题上缺乏清晰性，完备性和明确性； 需求获取和分析

理解SAP系统所提供的功能 功能上的差距评估和分析 正确配置和定制SAP系统 SAP系统的综合测试

数据风险，特别是各种主数据的准确性

通过制定有效的风险控制策略来控制上述可能的风险。

1.4准备项目计划

建立项目工作计划：项目经理制定项目的主工作计划，包括各阶段的完成时间点以及要提交的主要工作产品。

建立项目组培训计划：针对关键用户和最终用户的系统培训。

1.5项目启动

项目一般由一个发起会议来正式启动，参加这个会议的有管理人员、控制委员会成员、SAP顾问和小组成员。在项目启动大会上介绍项目的目标、项目组的组织成员及职责以及项目的主要工作计划。

1.6项目培训

模块顾问根据培训计划，执行项目组培训。

1.7开发、测试机系统准备 安装开发机、测试机系统，并给所有的项目组成员安装SAP桌面登录系统。

2、蓝图设计阶段

业务蓝图阶段主要处理需求的归档和最终的确定。小组成员和顾问在不同的业务活动领域内进行访谈，并召开项目讨论会，以获得各业务流程的确定需求。当前业务与未来业务的任何差别都必须进行识别，并要寻找和设计合适的解决方案。这个阶段最后输出企业蓝图文档，详细说明设计后的流程，包括公司结构和业务流程的文本和图形说明文件。一旦确定和验证了所有这些信息之后，蓝图就可以作为所有后续阶段的基础。

2.1 AS-IS业务流程调研

制定调研计划，确定调研的时间以及参加的人员，输出文档：调研计划；

设定调研提纲，根据访谈的人员的岗位，设定调研的内容，输出文档：调研问卷；

执行业务调研，根据调研计划，访谈岗位的人员，了解业务现状以及期望未来可达到的管理目标，输出文档：会议纪要；

完成业务调研文档，根据访谈的内容，整理形成公司AS-IS现状业务文档，输出文档：现状业务流程图，现状报告，包括如下内容： 现有系统的Landscape 组织架构 现状业务流程图 收集的现状报表、表单 业务主数据现状等；

2.2 TO-BE业务流程设计

根据现状业务以及未来管理的期望，组织跨模块讨论，编制TO-BE业务流程报告，然后对未来业务流程进行模块小组内讨论，然后提交指导委员会进行评审；输出文档：TO-BE业务蓝图文档。未来业务流程文档包括如下内容：

确定未来系统的组织架构，比如设定公司代码、成本控制范围、利润中心、成本中心、工厂、仓库、销售组织、采购组织等组织架构。

编制业务流程文档，设定未来业务流程如何在部门间的流转，单据如何控制。

2.3开发需求确认

在讨论和编制业务蓝图的过程中，涉及到需要开发的业务需求，则需要确认各模块的开发需求，输出文档：开发计划。

2.4主数据的收集方案及计划

讨论确认需要收集什么样的主数据，以及主数据的收集内容及计划安排，输出文档，主数据收集模版、主数据收集计划。

2.5业务蓝图的汇报及签署

业务蓝图编制完成后，在模块内部进行讨论完善，然后组织跨模块的讨论，最后对指导委员会进行业务流程汇报。输出文档：TO-BE文档签字文件。

3、实现阶段

实现的目标就是使用IMG并基于企业蓝图文档来配置系统，此外还需要定义数据导入策略、导入程序、开发报表。3.1系统配置

系统配置策略，确定系统的配置传输策略，确定开发机、测试机、生产机等。

系统配置，模块顾问根据业务蓝图的要求，配置系统，并进行测试，输出文档：系统配置文档。3.2测试

单元测试，系统配置完成后，即可进入单元测试阶段，单元测试由关键用户来执行，输出文档：单元测试文档，单元测试问题记录单； 集成测试，单元测试完成后，进行跨模块的集成测试，由顾问来规划集成测试案例场景，集成测试由关键用户来执行，输出文档：集成测试文档，集成测试问题记录单；

3.3开发

在该阶段同时进行开发任务，由开发组leader来根据各顾问提交的开发需求，制定开发计划，输出文档：开发计划文档；

各模块顾问或关键用户根据开发计划来编制开发需求文档，输出文档：开发需求说明书；

开发顾问开发完成后，通知顾问进行开发功能的测试，输出文档：开发测试文档。3.4数据收集

在该阶段数据组根据主数据收集计划，同步执行主数据的收集任务，输出文档：业务主数据。比较重要的主数据包括：物料主数据、BOM、客户、供应商、客户、资产、设备等主数据。

4、最终准备阶段

最终准备阶段目的是使系统和公司为实施SAP做好准备。这个阶段强化了前面阶段的所有活动。发现并解决所有异常情况和配置错误。关键用户负责编写未来系统的操作手册并培训最终用户。此外还需要检查所有程序切换和交互界面，进行容量测试和压力测试，并测试用户的接受程度。4.1最终用户培训

培训最终使用系统的用户，由关键用户来执行，关键用户针对最终用户的培训，需要编制用户手册作为培训教材。输出文档：用户操作手册，培训计划。根据培训计划执行最终用户培训，培训主要包括业务流程讲解以及上机操作业务。

4.2权限设计

模块顾问根据未来业务岗位权限要求，在系统中设置权限，然后在最终用户培训过程中可以根据实际岗位来测试权限。输出文档：角色权限设计文档，权限测试结果文档。4.3上线策略制定及批准

模块顾问制定上线策略以及数据导入计划，包括静态数据和动态数据的导入。输出文档：上线策略、数据导入计划。

由各业务决策组讨论和批准上线策略及数据导入计划。

4.4生产系统的准备

生产系统的安装和准备。由系统管理员将SAP配置传输到生产机。

4.5静态数据的检查和导入

由关键用户对静态主数据进行最后的检查和确认，然后执行数据导入，并将系统导入前的数据和导入后从系统下载的数据进行对比，确认无误后，签字。输出文档：数据检查表。

5、上线支持阶段 5.1上线前盘点

由各业务部门进行上线前盘点工作，并对盘点数据按照要求的格式提供。输出文档：盘点业务数据。

5.2盘点数据检查和导入

由财务部门对盘点的数据进行最后检查，确认无误后，由关键用户或顾问执行导入，并将系统导入前的数据和导入后从系统下载的数据进行对比，确认无误后，签字。输出文档：数据检查表。

5.3系统切换

静态数据和动态数据导入系统后，按照项目计划进行系统的切换，新的业务将在SAP平台上进行操作和管理。5.4上线后支持

关键用户和顾问负责指导和解决业务操作过程中出现的问题，每天及时记录发生的问题，并记录解决的办法，每天项目组开会讨论出现的问题，并及时指导解决。输出文档：上线问题记录表。

5.5月结支持

上线一个月后，顾问要指导和支持系统的月结，及时解决月结中出现的问题，确保月结顺利完成。然后顾问团队撤出客户现场，以后改为远程支持

第二篇：SAP的项目实施方法论

第一章 1.1 SAP的项目实施方法论

ASAP 路线图

ASAP 路线图提供了面向过程的，清晰而又简明的项目实施过程中所必须经历的各个阶段。

在R/3 实施过程中,使用该路线图即可清楚地知道目前正处于哪一步,下一步又将干什么。除了告诉项目实施过程中所要经历的各个阶段外，还就每一阶段完整地提供下列信息:      阶段工作开始前所需要的各项准备工作。

阶段工作所要取得的目标是什么，结果的形式又是什么。阶段工作的实现过程以及如何去完成这些过程。阶段工作结束前如何对阶段工作的结果进行检查。

阶段工作开始前及进行的过程中所需要的各项技术支持工作。

第一步：项目准备

项目准备的目的是定义项目目标，例如，当成功实施项目后，需要达到一个怎么样的目标？成功实施后，哪些重要的指标会得到提升？然后需要确定实施范围。进而可以确定实施的进度，包括资源的分配情况。

项目准备阶段主要的任务      初始项目计划 项目流程 项目开始

技术方面的需求计划，包括硬件配置计划 项目准备阶段的质量检查

第二步：业务蓝图

成功进行项目准备之后，业务蓝图阶段会对初始的项目目标、项目进度安排以及实施顺序进行细化。同时将定义企业结构以及业务过程。业务蓝图是该阶段最重要的文档，其中记录了所有的业务需求，以及实施的方案。

项目准备阶段主要的任务 

业务蓝图阶段的项目管理 

初始的项目小组培训 

建立系统运行环境 

业务组织结构



业务过程的定义何质量检查 第三步：系统实现

当在业务蓝图阶段定义了所有需要实施的业务过程，并得到了客户的认可以后，实现阶段就开始了。在该阶段，根据业务蓝图中的客户需求，所有的用户和顾问将开始配置系统。项目组每周的例会能够尽可能地保证项目始终保持正确的轨道，并且使出现的问题得到及时的解决。对一些标准系统无法提供的功能和界面的开发保证了一个完整的业务解决方案。在最后的集成测试阶段，将对所有的业务过程进行测试和确认，由此将进入后续个阶段——最后准备和上线。

项目实现阶段主要的任务 

实现阶段项目小组的培训 

基本方针的确定 

系统管理 

最后设置和确认 

开发转换程序 

开发应用程序接口 

建立报表



进行权限设定，并开始文档管理 

最后的集成测试



建立最终用户文档和培训文档 

实现阶段的质量检查 第四步：最后准备

集成测试完成之后，将要为最后的上线进行准备。因此，需要处理何解决所有在集成测试中出现的问题，以确保平稳上线。进行上线前的检查。在此之后，将会进行新老系统之间的切换，这保证了为您的业务提供一个稳定的系统。

项目准备阶段主要的任务 

最后准备阶段的项目管理 

最终用户培训 

系统管理 

详细项目计划 

切换



最后准备间断的质量检查 第五步：上线及上线后的支持

上线及上线后的支持阶段使系统成为一个实际应用中的系统，并确保其具有稳定的操作性能。该阶段包括了问题解答和用户帮助。用户帮助体系将从系统第一天真正运作开始，直到用户建立起自己内部的支持小组。并且，系统在运作过程中受到的负荷上的压力也将通过对一些关键性能指标的分析得到。

项目准备阶段主要的任务 

生产支持 

上线

 KPI获取和评估

1.2 各实施阶段结果 完整的项目实施必然要具备高质量的文档。不过传统的实施过程中又有造成过多的时间在文档上而造成实施时间及费用的消耗。ASAP的指针思想是：按照文档的生命周期长短赋予其重要性，对于生命周期长的文档相应地多投入力量。如业务流程手册，用户操作手册等。

ASAP为每个阶段定出了应完成的工作及期待的结果。其中除了文档外还有系统，接口程序等。以下是部分结果的范例。

第二章 2.1 SAP 培训体系

SAP培训体系

SAP 培训部――专门提供SAP 产品专业培训的源头，主要是通过相关培训服务的提供，帮助我们的新老客户及合作伙伴快速、系统地了解和掌握博大精深的SAP 产品，省时高效地完成项目的实施与维护，达到先利其器、后善其事的目的。SAP培训的优势在于：

 全球同步的教育训练与培训产品研发  与产品的版本实时同步的专业培训资料  预定和使用SAP德国提供专业的培训系统  SAP独家全球共用的培训实施方法论 SAP 中国培训部在北京和上海分设培训中心，有出色的师资队伍及精良的硬件设施；同时身在SAP 的得天独厚优势，保证我们自由地下载最新的培训资料、及时向德国预定相应的培训专用系统和在SAP实施领域为客户选择合适的师资资源。

目前我们的培训方式主要分为三种：  SAP 顾问学院

主要通过约30 天左右的集中强化学习和模拟项目练习，使学员对某一特定模块的功能有一个系统全面的认识，从而掌握实施项目的基本技能。在此课程内容结束后，学员可以通过参加联到德国的认证考试，申请由SAP 德国总部颁发的应用咨询顾问资格证书。

到目前为止，SAP中国培训部已成功举办了若干期顾问学院，帮助400余名学员在8个领域取得了顾问资格认证。我们培训的通过率约为87%，高居全球认证通过率的前列。 SAP 标准培训

SAP 教育训练研发机构针对SAP 产品的功能划分为三个等级，并把具体功能细化整理成不同的课程，对之以相应的标准课号和标准的培训资料内容。

第一级培训提供对R/3系统环境的总体介绍

第二级培训介绍可在R/3系统中实现的基本业务流程

第三级培训侧重于详细介绍各应用模块中的具体功能及系统配置  客户化培训

根据具体客户的项目实施需要，SAP 培训部可以为特定客户组织客户化培训，培训内容基于与客户具体需求功能相关的标准课程，同时在培训时间上灵活安排。

flying.lei@163.com 冯雷

第三篇：SAP项目实施计划概要

SAP实施计划

实现业务方案的服务也就是实施 SAP 项目的服务，下面是一个 SAP R/3 项目实施工作的简要内容表。从表中可以看出，有计划有步骤地实现业务方案，要做很多细致复杂的工作。从咨询公司得到这种专业化服务是有好处的。这也是一种“软件”，而且是一种纯粹的“软件”。引进和实施这个软件的过程，就是企业业务流程重组的过程，也就是实现业务方案的过程。咨询顾问的主要工作就是按计划地和企业管理人员配合工作，实现 R/3 系统的配置以及业务蓝图的设计。第一阶段: 项目准备

1.1 启动项目计划

1.1.1 建立项目实施方案

1.1.1.1 定义项目目标

1.1.1.2 定义业务目标

1.1.1.3 定义业务指标

1.1.1.4 定义项目指标

1.1.1.5 定义改变方案

1.1.1.6 综合项目模块方案

1.1.1.7 批准项目方案

1.1.2 审查和改进实施策略

1.1.2.1 审查实施建议

1.1.2.2 确认实施方法

1.1.2.3 为全部策略在公司亮相进行检查

1.1.3 建立项目组工作环境

1.1.3.1 规划环境

1.1.3.2 建设环境

1.1.4 确定项目组织

1.1.4.1 改进组织和角色

1.1.4.2 通知每个人担当的角色

1.1.4.3 通知核心改变小组的角色

1.1.4.4 召开项目启动组会议

1.1.4.5 建立扩展的变更小组

1.1.5 准备项目计划

1.1.5.1 建立项目工作计划

1.1.5.2 建立项目预算计划

1.1.5.3 建立项目资源计划

1.1.6 建立项目组培训计划

1.1.6.1 讨论和通过实施建议

1.1.6.2 改进培训课程计划

1.1.6.3 确认项目培训计划

1.1.6.4 改变管理的培训和小组建立

1.2 项目程序 1.2.1 定义项目管理标准和程序

1.2.1.1 确定项目通讯计划

1.2.1.2 定义项目文档

1.2.1.3 建立问题管理计划

1.2.1.4 建立变更管理计划

1.2.1.5 建立范围管理计划

1.2.1.6 制定小组建设计划

1.2.1.7 定义项目计划和监督标准

1.2.1.8 定义使用 R/3 服务的策略

1.2.1.9 定义质量认证标准

1.2.2 定义实施标准和程序

1.2.2.1 定义系统配置标准

1.2.2.2 确认最终用户文档资料和培训

1.2.2.3 定义测试策略

1.2.2.4 定义实施后期服务和支持策略

1.2.2.5 为项目组定义系统授权标准

1.2.2.6 定义系统问题标准和错误处理程序

1.2.2.7 定义系统升级和修改确认程序

1.2.3 定义系统范围(System Landscape)策略

1.2.3.1 定义需求的系统

1.2.3.2 定义客户开发策略

1.2.3.3 定义发布策略

1.2.3.4 定义传输系统策略

1.3 项目启动

1.3.1 项目启动大会

1.3.1.1 准备项目准备大会

1.3.1.2 召开项目启动大会

1.3.1.3 在公司内介绍项目

1.3.2 项目组会议

1.3.2.1 准备项目组会议

1.3.2.2 召开标准会议

1.4 技术需求计划

1.4.1 确认技术需求计划

1.4.1.1 完成技术调查表

1.4.1.2 定义基本技术需求

1.4.2 购买硬件

1.4.2.1 确认基本硬件需求

1.4.2.2 审查系统规模制定结果

1.4.2.3 通过系统需求

1.4.2.4 基本硬件订货

1.4.2.5 远程网络连接订货

1.5 质量检查项目准备阶段

1.5.1 实现质量检查和获得批准

1.5.1.1 通告质量检查方法和标准 1.5.1.2 汇报结束项目准备阶段 第二阶段设计蓝图

2.1 项目管理业务蓝图阶段

2.1.1 召开项目组形势会议

2.1.1.1 准备形势会议

2.1.1.2 参加形势会议

2.1.1.3 跟踪各行动项

2.1.1.4 纠正项目偏差

2.1.1.5 精炼项目计划

2.1.2 召开筹划指导委员会会议

2.1.2.1 准备筹划指导委员会会议

2.1.2.2 参加筹划指导委员会会议

2.1.2.3 跟踪各行动项

2.1.3 全面项目管理

2.1.3.1 引导小组建设活动

2.1.3.2 定义培训小组技术和责任

2.2 改变管理

2.2.1 建立业务影响的预测

2.2.2 完成基线领导阶层风险评估

2.2.2.1 开发导入风险评估工具

2.2.2.2 管理领导风险评估工具

2.2.2.3 建立领导风险的说明

2.2.2.4 进行领导风险的工作

2.2.2.5 集成领导风险评估和责任人的建立过程

2.2.3 开发责任制策略

2.2.3.1 贯彻高层责任制程序

2.2.3.2 贯彻关键场所的责任制程序

2.2.4 完成基线项目组风险评估

2.2.4.1 开发项目组风险评估工具

2.2.4.2 管理项目组风险评估工具

2.2.4.3 建立项目组风险说明

2.2.4.4 进行项目组风险工作

2.2.4.5 从项目组风险工作中制定行动计划

2.2.5 完成基本的组织风险评估

2.2.5.1 为变更项目确定相应组织环境

2.2.5.2 建立组织风险评估计划

2.2.5.3 开发组织风险评估工具

2.2.5.4 召开一线管理人员参与会议

2.2.5.5 执行基线组织风险评估工具

2.2.5.6 建立基线组织风险文档

2.2.5.7 引导组织风险工作中心

2.2.5.8 总结并听取关键场所负责人汇报

2.2.5.9 为第一线管理者建立信息反馈包

2.2.5.10 执行由组织风险工作中心的出的行动计划 2.2.6 建立变更通信框架

2.2.6.1 确定管理项目通信的重要人员

2.2.6.2 为项目通信开发概念上和分析上的基础

2.2.6.3 将风险评估结果结合到进行中的通信中

2.2.6.4 发布项目详细信息

2.2.7 建立技术开发过程的管理结构

2.2.7.1 建立技术开发组

2.2.7.2 开发变更管理培训策略

2.2.7.3 选择内部或外部的培训合作伙伴

2.2.7.4 定义和执行评价和管理培训效果的过程

2.2.8 为知识传递过程定义管理结构

2.2.8.1 建立核心知识传递组

2.2.8.2 定义和执行核心知识传递过程

2.3 项目组培训业务蓝图阶段

2.3.1 执行项目组培训

2.3.1.1 精炼培训计划

2.3.1.2 准备培训

2.3.1.3 参加项目组培训

2.3.1.4 审查和获取后期培训技能

2.4 开发系统环境

2.4.1 建立技术计划

2.4.1.1 记录物理系统规划和分布

2.4.1.2 定义和记录打印布局

2.4.1.3 证明网络拓扑

2.4.1.4 证明接口拓扑

2.4.1.5 定义变更要求管理

2.4.1.6 定义发布管理策略

2.4.1.7 定义桌面管理策略

2.4.1.8 批准技术设计

2.4.2 建立开发环境

2.4.2.1 安装最初硬件

2.4.2.2 检验初始系统技术环境

2.4.2.3 安装和配置开发系统客户

2.4.2.4 为项目成员安装桌面组件

2.4.2.5 为项目组建立用户主数据记录

2.4.2.6 保护开发系统

2.4.2.7 为项目组 安装和设置打印服务

2.4.2.8 设置远程网络连接

2.4.2.9 建立与SAP 的远程网络连接

2.4.3 建立初始系统Landscape

2.4.3.1 安装和设置开发系统客户

2.4.3.2 设置和测试传输系统

2.4.4 维护系统管理程序

2.4.4.1 管理基础和系统管理工作中心 2.4.4.2 为开发系统定义系统管理

2.4.4.3 配置 CCMS 2.4.4.4 定义备份策略

2.4.4.5 检验系统管理功能

2.4.4.6 定义定期系统维护

2.4.5 初始化 IMG

2.4.5.1 建立企业IMG并维护项目标题数据

2.4.5.2 产生项目IMG

2.5 业务组织结构

2.5.1 定义业务组织结构

2.5.1.1 安排组织结构工作会议

2.5.1.2 发布组织结构指南

2.5.1.3 召开组织结构工作会议

2.5.1.4 建议和批准组织结构

2.6 业务流程定义

2.6.1 准备业务流程工作任务

2.6.1.1 计划业务过程工作任务

2.6.1.2 导入业务流程指南

2.6.2 导入全局需求工作任务

2.6.2.1 确定全局参数

2.6.2.2 确定企业标准

2.6.3 举行业务过程工作会议

2.6.3.1 确定业务过程需求

2.6.3.2 确定扩展功能需求

2.6.3.3 确定报告需求

2.6.3.4 确定需求界面

2.6.3.5 确定转换需求

2.6.3.6 确定需求增加

2.6.3.7 明确不足的地方

2.6.3.8 精炼业务过程描述和模型

2.6.3.9 确定额外详细的工作会议的需求

2.6.3.10 安排详细需求工作会议

2.6.4 举行详细需求工作会议

2.6.4.1 确定详细需求

2.6.4.2 精炼业务过程定义和模型

2.6.5 完成业务蓝图

2.6.5.1 进行组织优化分析

2.6.5.2 精炼项目组织和角色

2.6.5.3 收集业务蓝图

2.6.5.4 确定基线范围

2.6.5.5 检验业务蓝图完成情况

2.6.6 业务蓝图审查和停止

2.6.6.1 准备蓝图审查演示

2.6.6.2 进行审查和结束工作 2.6.7 起草最终用户培训和文档计划

2.6.7.1 定义最终用户培训和文档

2.6.7.2 开发原型

2.6.7.3 定案最终用户培训和文档计划

2.7 质量检查业务蓝图阶段

2.7.1 进行质量检查并获得批准

2.7.1.1 进行质量检查

2.7.1.2 业务蓝图阶段结束 第三阶段实施

3.1 项目管理实现阶段

3.2 持续的改变管理步骤

3.3 项目小组培训实现阶段

3.4 基本配置和确认

3.5 系统管理

3.6 最终配置和确认

3.7 开发转换程序

3.8 开发应用接口程序

3.9 改进

3.10 建立报告

3.11 设计表格

3.12 建立授权的概念

3.13 建立归档管理

3.14 最后的集成测试

3.15 最终用户手册和培训材料

3.16 质量检查阶段第四阶段准备

4.1 项目管理最后的准备阶段

4.2 最终用户培训

4.2.1 准备最终用户培训

4.2.1.1 为培训准备最后的条件

4.2.1.2 建立用户培训基本条件

4.2.1.3 为最终用户的培训准备数据

4.2.2 进行最终用户培训

4.2.2.1 进行最终用户培训

4.2.2.2 总结最终用户培训

4.3 系统管理

4.3.1 建立生产系统的管理

4.3.1.1 为生产环境配置 CCMS

4.3.1.2 配置生产系统的打印和spool管理

4.3.1.3 Train System Administration Staff 4.3.2 进行系统测试

4.3.2.1 进行大数据量测试

4.3.2.2 进行高使用强度测试

4.3.2.3 进行系统管理测试 4.3.2.4 进行灾难恢复测试

4.3.2.5 进行备份和恢复测试

4.3.2.6 进行打印和传真测试

4.3.2.7 进行投入运行测试

4.4 详细的项目计划

4.4.1 Refine Cutover 4.4.2 修订生产支持计划

4.5 Cutover

4.5.1 Perform Cutover to Production System 4.5.2 投入生产的最后批准工作

4.6 质量检查最后准备阶段

4.6.1 完成质量检查和获得批准第五阶段 切换

5.1 生产支持

5.1.1 提供生产支持

5.1.1.1 指出问题和缺陷

5.1.1.2 管理和解决问题

5.1.2 评价实际业务处理结果

5.1.2.1 逐日和逐周监控传输过程

5.1.2.2 解决问题

5.1.2.3 确认生产环境

5.2 项目结束

5.2.1 项目总结

5.2.1.1 审查和解决存在问题

5.2.1.2 审查业务的改进

5.2.1.3 总结改变程序的结果

5.2.1.4 完成改变管理的程序 项目结束和把问题归档

第四篇：SAP项目实施总结 - 完整版

北京航空航天大学研究生课程考核记录

202_－202_学年 第二学期

学号

GS0921G44

姓名

徐方华

成绩

课程名称：《 企业信息化管理

论文题目： 壳牌SAP项目实施总结 任课教师评语：

任课教师签字：

考核日期：

年

月

》

日壳牌SAP项目实施总结

本人所在的公司-英荷皇家壳牌（中国）有限公司已于202_年4月1日成功实施了SAP。本文是本人在成功上线后做的总结，发表在202_年5月的内部刊物上。本文部分内容有所增减。

荷兰皇家/壳牌集团公司是现今世界最大的石油产品，化学品，煤和金属的勘探者，生产者和经销商之一，在全世界一百多个国家的两千多家公司中拥有权益，雇员总数超过十万人。集团公司的五大核心业务:A.勘探和生产B.天然气和发电C油品D.化工E.可再生能源。

随着在中国大陆的实际投资达到10亿美元，壳牌已成为在中国投资最大的国际石油公司之一，五大核心业务都己在中国取得了长足发展。壳牌在中国已建立了十余个办事处。有20多家独资或合资企业在运营。员工人数约为超过5000人，90%以上为本地员工。

本人所在的部门为油品部，壳牌在中国的油品营销业务包括润滑油，加油站，沥青和液化石油气，属于石油的下游业务。从八十年代初至今，壳牌在这些领域投资了4亿美元建立合资企业和独资企业。在全国建立了三个大型的润滑油厂，它们是-一

A.位于天津年产10万吨的润滑油调配厂。

B.位于浙江乍浦年产10万吨的合资润滑油调配厂。

C.位于广东珠海特区的年产40万吨的润滑油调配厂（该厂为壳牌全球最大润滑油调配厂）。

从１９９５年开始，随着第一家润滑油调配厂在天津的投产，壳牌中国就开始了企业的信息化建设，同步上线的企业ＥＲＰ系统是由壳牌集团公司开发，并拥有自主知识产权的基于ＭＵＭＰＵＳ数据库的系统－ＭＬＩＩ系统。该系统基于Ｕｎｉｘ操作系统，客户／服务器架构，包含采购模块，企业生产模块，销售模块，库存管理模块等，并与财务系统接口。到２００２年，随着公司业务规模的扩大，该系统已经越来越难于胜任业务的需求。集团公司决定从２００２年７月开始实施ＳＡＰ项目。

项目的目的是为了实行企业内外资源优化配置，消除生产经营过程中无效的劳动和资源，实现企业信息流、物流、资金流、价值流和业务流的有机集成和提高企业竞争力，集客户、市场、销售、计划、采购、生产、财务、质量、服务、信息集成和业务流程重组（BPR）等功能为一体。

成功实施ＳＡＰ项目后，系统所要达到的功能主要有：

1、支持集多种生产类型、多种经营方式和多种产业为一体的，跨区域的SCM模式；２、支持市场分析、销售分析和客户关系管理；３、支持包括先进计划与排产技术在内的多种计划和优化排产方法；４、支持物流和配送体系管理；５、支持集团的资本运作管理；６、支持更大范围的信息集成和系统开放。

成功的ＳＡＰ项目实施，有许多经验可以总结，概括起来主要有以下四点：

一、最高管理层坚决支持，中低层员工积极参与

ERP的实施不是一个简单的技术软件培训，包括业务流程重组、管理模式和业务架构转变、岗位职能调整等许多方面。由于损害到部分人的长期或短期利益，ERP的实施常常会遇到或明或暗的阻力。只有得到一把手的坚决支持，才能排除干扰，克服困难，成功地实施ERP。

在壳牌ＳＡＰ项目正式启动之前，项目组组织了几次全体员工的沟通会，由公司最高管理层参加，对项目实施的必要性以及实施后对公司业务的帮助等做了充分的沟通。并且成立了项目管理委员会，有相关部门的最高管理人员组成，定期开会，对项目中遇到的问题进行及时沟通和解决，保证项目实施的进度及各个里程碑事件的顺利完成。

企业的中层管理者，扮演着局部目标和政策的制定以及企业管理政策执行者的双重角色；企业的基层员工是业务流程的日常参与者，软件的日常操作者；必须让他们理解如何利用ERP提高日常决策的及时性和正确性，提高工作的效率和效益。注重对中层领导和业务骨干的培训，使他们理解在ERP的实施过程中，自己应当如何配合项目小组、管理咨询公司、软件厂商的工作，调整工作方式、工作内容，才能使为ERP实施付出的时间、金钱得到切实的收益。

二、良好的管理基础

企业管理基础涉及许多个方面，总结起来较为关键的有以下几点： ①制度基础。壳牌是一家跨国大公司，有完善的企业管理制度。包括清晰的企业的产权制度、法人治理结构以及激励约束机制等企业基本制度。良好的制度基础是企业建立和使用信息系统的动力源泉，也是突破实施障碍的关键； ②业务流程基础。壳牌公司基本的业务流程是全球统一的，是对百年业务模式的一个总结提炼，并成功运用与香港，台湾等与中国运营环境类似的地区和国家，业务流程较为固定而且固化成为管理制度。

③数据基础。有许多ＥＲＰ项目因为数据问题而失败，以至于项目实施人员经常发出“一份技术，两分管理，七分数据”的感慨。壳牌公司虽然原有的ＥＲＰ系统比较陈旧，但由于管理到位，所有业务主数据都非常完善和清晰，冗余数据少，而且成立了专门的主数据小组，负责对各个业务模块的主数据进行清理和管理。

三、经验丰富的管理咨询公司

参考许多国内的ＳＡＰ项目实施经验，许多失败的项目实施主要是由于不能很好的将ＳＡＰ本地化，即不能根据企的需要和承受能力量体裁衣，不符合企业的业务流程，导致项目上线之后，用户不能很好地使用ＳＡＰ，系统是系统，流程是流程，甚至是在ＳＡＰ外用其他的工具来辅助完成。

为了避免出现这种情况，壳牌公司在以经验丰富的内部顾问团队的基础之上，又与ＩＢＭ中国签订了合作协议，由他们派驻各个模块的有经验的本地顾问，作为内部顾问和各个业务部门的沟通桥梁，并且引入本地化实施的经验，使得系统更好的本地化，与中国实际的业务进行整合。

四、注重实施工程中的项目监控

ＳＡＰ项目实施是一项风险很高的工程，需要进行严谨认真的项目监控。具体来说，壳牌公司实施了规范项目例会和阶段性评审制度：定期召开由企业的项目领导、各业务部门的领导以及实施咨询人员参加的项目实施例会,协调解决实施过程中出现的部门协调、人员沟通、技术支持、时间和成本控制等问题；分阶段对项目实施进行评估，如果出现偏差，研究是否需要更新计划及资源,同时落实所需的更新措施，如果达到要求，就部署下一阶段的工作。

规范项目实施过程中的文档管理也是一项关键工作。对实施过程进行全面的文档记录，详尽而规范的实施文档不仅有利于企业与管理咨询公司之间的交流，而且对ＳＡＰ项目的后期维护和持续改进都是重要的基础资料。

总之，ＳＡＰ项目实施是一个企业管理系统工程，而不是一般意义上的企业管理信息系统工程或者是企业信息化建设工程。ＳＡＰ实施的过程就是体制与观念变革的过程。实施ＳＡＰ，首先要学习和领悟先进的管理思想，只有企业内部对ＳＡＰ所代表的先进管理思想有充分认识，才能加强企业上下级之间、各部门之间、企业与管理咨询公司之间的沟通和协作，共同把ＳＡＰ实施工作做好。大量的研究与实践充分表明，ＳＡＰ在我国应用的成败并不取决于技术、资金、网络、应用软件和软件实施，而主要取决于企业自身主体意识。企业是应用ＳＡＰ的主体。企业应用ＳＡＰ首先要提高思想认识，转变思想观念，增强自身主体意识。只有增强了主体意识，才能提高主体能力，才能发挥主体作用，才能确保项目的成功。

第五篇：SAP实施Roll out项目经验谈（精选）

SAP实施Roll out项目经验谈

本系列文章主要讨论在SAP实施Roll out项目中需要注意的事项，包括思路与项目管理，技术细节与数据两个部分。

本文讨论项目实施实施的思路与项目管理方面。

Roll out项目，本身在很多方面不同于全新的实施项目。它在很多方面受制于Global的实施思路和系统配置的影响。这种影响主要体现在以下几个方面。第一，业务流程限制

与全新项目不同，Roll out项目的业务流程都是已经定好了的。实施的过程是一个把已有的业务流程复制到另一个子公司的过程。这就从根本上规定，业务流程实现方式必须以母公司为模板。尤其是跨公司交易的业务，公司间采购，跨公司销售等，更是必须遵从母公司的流程。

第二，数据分类限制

全新的项目可以根据公司的需要去定制统计分析模板，关键数据，特征字段等，都可以自行设计；但在Roll out项目中，不可避免地要受到母公司统计分析要求的制约。比如物料类型定义，涉及统计分析的字段内容定义如客户组，物料组等。CO模块更是有很多定义好的结构，是必须要严格遵从不能更改的。第三，实施过程限制

全新的项目可以按照ASAP的方法论进行项目实施。但在Roll out项目里则不一定。根据签订合同内容的不同，实施的过程有可能会不同于全新项目。比如某个项目的Roll out合同规定，该Roll out项目必须完全拷贝母公司的流程，不允许有子公司个性化设置。在这种前提下，业务流程调研这一步的工作就几乎被忽略了，实施重点只是业务实现和培训。实施团队的任务不是根据子公司的实际业务制定流程，而是主要负责把母公司的流程介绍给子公司，子公司严格按既定的业务流程操作。第四，法律法规限制

这一点在跨国公司roll out项目中尤其明显。各个国家法律法规不尽相同，从而导致公司业务流程不完全相同，这是显而易见的。比如税种不同，海关规定不同，甚至业务操作模式不同。这些都要在Roll out项目中予以充分的考虑。第五，实施时间限制 一般来说，Roll out项目的实施时间都会比全新项目的实施时间短。常规的Roll out实施一般是三到四个月，而全新项目一般至少要六个月以上。

由于诸多类似限制的存在，我们在做Roll out项目时，要从项目实施思路的层次确立指导思想，在项目管理的层次严格落实。指导思想的正确是项目成功的前提。不要认为这是空话套话，象天朝官员讲话一样。事实上，指导思想绝对是项目实施中至关重要的一个环节。平时注意不到它，是因为它不大会出错。一旦指导思想出了偏差，项目离失败就不远了。这一点适用于全新的项目和Roll out项目。第一，在母子公司之间确定主次。

各个企业结构不同，母公司对子公司的控制力度也不同。有些公司母公司控制力非常强，大权独揽，相对于子公司来说，是我叫你干啥你干啥，没叫你干的你就别干；另一些公司，相对松散，子公司相对拥有较大的自由度，除了关键问题，子公司具有“我说了算”的权力。在做Roll out项目的时候，确定公司间的这种主次关系是首要的任务。就本次实施任务来说，是子公司说了算，还是母公司说了算？这一点要在参与实施的各方之间达成共识。

在项目组织的架构上，如果以母公司为主，则项目经理应该是母公司的派出人员；在实施过程中，项目经理对子公司与项目相关的部分应该有相对较大的决定权。子公司项目参与人员更多的是被动的接受，而不是在某些需要做决定的有争议的部分，指手划脚。如果以子公司为主，则项目经理应该是子公司的人员，或者母公司派出人员。项目实施过程中更多地考虑子公司自身的业务，母公司已经设置好的流程等只是作为参照。曾经有一个项目，母子公司之间在这一点上没有达成共识。母公司认为子公司应该以复制母公司现有流程为主，基本不考虑额外的需求。如果有困难要从流程改变上去解决；但母公司又没有派出项目经理，甚至没有人全程参与，仅仅依靠实施顾问方进行知识转移，阻力之大可想而知。子公司参与人员没有理性的期望值，对项目要求过高。这种项目注定是不成功的。可能不是失败的，但最终效果一定是不理想的。第二，注重与母公司的沟通。

对于roll out项目来讲，不仅仅要在项目内部进行沟通管理，而且要在项目与母公司之间进行顺畅的沟通管理。项目组必须要建立项目与母公司顺畅的沟通渠道。实施过程中，不可避免地会需要与母公司进行各方面的沟通。特别是有CR提出来时，如果迟迟得不到解决，会大大地拖延项目进行，也会严重影响到项目人员的积极性。

值得一提的是，不论是母公司为主，还是子公司为主，母公司一定要有熟悉项目的人参与到子公司的实施过程中来。一个熟悉原始项目的参与者带来的效益，好过一堆文档。相信大家对这一点是认同的。囿于时间，资金等限制，几乎没有什么项目能够在文档上做到与项目实际进程齐头并进，保证文档是最新最准确的。除非是一个专门以交付文档为目的的项目。在这个前提下，原始项目参与者带来的知识就显得异常重要。而且，很多东西是无法写在文档中的，它只存在于人的大脑里。没有原始项目人员的参与，roll out项目实施过程中，就只能不断地通过电话邮件等方式与母公司联系。这对项目进行的效率影响是相当大的。尤其是跨国公司，加上时差原因，沟通效果就更大打折扣。第三，适当降低期望值。

无论是在全新实施项目中，还是在roll out项目中，这一点都是相当重要的。如果客户对项目的期望值过高，实施起来就会难度重重。优秀的咨询顾问，应该知道如何帮助客户建立适当的期望值。迫于签单的压力，销售人员往往会有意无意地夸大系统的功能，给后来的实施埋下隐患。顾问进场后，很重要的一个任务就是要管理客户的期望值。

尤其是在roll out项目中，要先给客户定下调子，这个项目不可能有很多的自由度，或许有很多实际的业务流程无法在系统中满足，只能通过更改现有的操作习惯的方式来解决实际问题。在数据分类，跨公司业务等涉及到全球模板的方面，要想更改是很不容易的，除非有特别的理由。

当客户对系统能够实现的功能有了较为合理的定位时，项目推进过程中就会避免很多抱怨。客户的主要精力才会由压迫顾问做事，转向自我改良去适应全球模板要求。

这并不是敷衍客户。全球模板之所以能被推广，一般来说不会有什么根本性的缺陷。某个子公司的特殊需求，经过认真分析，大部分可以在全球模板中找到解决的方案。第四，给予培训工作更多的重视。

对于全新的项目来讲，事前的流程讨论，业务蓝图的设置，需要用去很多的时间。这部分的工作做得越仔细，越认真，后续的系统实现和测试等就会越顺利。而在这整个过程中，关键用户都是全程参与的，无形之中他们已经学习了很多系统知识。同时，由于项目时间久，关键用户对系统的了解是由浅入深逐步进行的，会有时间去消化所学到的内容，后来的操作培训就会相对容易一些。

但对于roll out项目来讲，流程讨论部分其实是全球模板的介绍，仅对不符合实际业务的部分进行讨论和定义。由于时间短，关键用户没有太多的时间去理解系统的逻辑，对他们不可避免地要实行填鸭式培训，效果也相对差一些。常常是学了前面忘了后面。另一方面，由于系统功能已经经过原始项目的完整测试，一般来说在测试过程中出现的问题也少一些，关键用户通过测试发现问题，了解问题出现的原因的过程中，学到的知识也会相对较少。由此，培训工作在roll out项目中就要占据更大的比重。第五，整理数据时注意全局性。一般来说，roll out项目整理数据时，母公司的系统已经运行了一段时间。在数据的分类上，数据标准上，都已经有了现成的标准。更有许多物料供应商客户等数据，是母公司系统中已经存在的。因此在数据搜集和整理的过程中，要特别注意这一点。要过滤母公司已经存在的数据，新的数据定义，分类要与母公司保持一致。

从项目管理角度来说，要想避免冗余数据或者错误定义，应当由母公司对数据进行检查。但往往这是一个不可能的任务。因此，顾问应该对数据搜集投入一定的精力。这里又有一个矛盾。一般来说，数据搜集是客户的任务，顾问只提供模板，不参与实际的搜集整理过程。我认为，这是一个很不好的现象。数据是SAP系统运行的基础，如果数据做不好，系统的运行就不会令人满意。顾问作为系统专家，应该参与到数据搜集当中去。最好是在项目合同中就明确，顾问应该参与数据搜集整理，当然，咨询公司因此要得到一定的报酬。还要界定责任，顾问应当主动检查用户数据，并提出专业的意见。事实上，客户在搜集数据的过程中，也经常会向顾问请教。但是主动的参与和被动的指导，其效果肯定是大不一样的。这一点，不论是全新项目还是roll out项目都适用。第六，上线切换注意关联交易。上线时的切换工作方面，roll out项目和全新项目有一些不同。主要体现在跨公司业务方面。在子公司上线时，母公司往往已经运行了一段时间，且与子公司有业务往来。未清的跨公司交易业务如何处理？这是在roll out项目中要考虑的。在全新的项目中则不必考虑这一点，只需考虑到对客户，对供应商的未清业务即可。而公司间交易与外部客户和供应商显然有不同之处。

总之，roll out项目不同于全新项目，在项目管理的指导思想上，项目经理要区别对待，针对性地加强对相关环节的控制。

上一篇谈到roll out项目的实施主体思路及项目管理方面要注意的事项，本篇着重谈技术与数据方面的问题。

技术方面，由于上篇所讲到的诸多限制，与全新的项目也有所不同。本人只在后勤方面有所了解，因此只能简单谈一下后勤方面配置的注意事项。总的来说，就是要注意在做系统配置的时候，不要忽视了已经存在的东西。有些配置或许在原始项目中已经做了，而且不是使用的标准设置，在做roll out项目的时候就要特别引起注意，不要因为roll out把母公司的业务给搅乱了。

技术方面的问题不能分门别类地谈，比较零乱，只能说一点是一点了。1.语言问题。

尤其是在跨国roll out项目中，一定要注意语言的问题。比如，在国家设置中，如果选定了语言，则在发往别国的采购单上，国家代码是以本国语言显示的。如果实际业务中不能做成这样，国家代码里就不要去选这个语言，让系统根据登录的语言自动确定即可。

再如，采购单的form，是有多种语言的。如果要拷贝出来更改的话，一定要注意拷贝多种语言。只在一种语言下拷贝，有可能导致其他语言下的采购单出问题。2.数据分类

着重谈一下物料类型。在roll out项目中，很多都会涉及到公司间交易。不论是跨公司销售，还是公司间采购，如果这种公司间交易是采用系统标准的模式来做，都会涉及到同一个物料编码在多个工厂之间应用的问题。这时，一个物料是什么物料类型就成为一个很重要的问题。物料类型里有获取类型的限制。比如ROH的物料一般是只允许外部采购，不允许自制的。而在公司间交易时，往往在这个工厂是原材料的东西，在另一个工厂应该是成品。这时候，如果把它设置为原材料物料类型，在另一个工厂就无法做生产了。物料类型里也有视图控制。HAWA里是没有工作计划的视图的。如果某个工厂向另一工厂采购物料后直接销售，往往会把它设置为HAWA类型。但是在另一个工厂，它就是自制品，需要生产的。

诸如此类的问题往往会导致物料类型分类方面的麻烦，需要特别加以注意。3.采购批准策略

如果原始项目中没有使用批准策略，而在roll out的时候，子公司需要使用的话，要注意特性设置上用公司代码或者采购组织等区分开来，而不能简单地使用一个单据类型实现这个功能。

4.物料特殊获取类型

在MRP2视图里有一个字段叫作special procurement type。这里可以定义物料在另一工厂生产。象这种涉及到公司间交易的字段要着重加以确认。5.输出条件记录

要记得用MN*去维护各种输出的条件记录。尤其在跨国公司中，要注意维护出口税条件类型。

6.在基础数据的设置中注意国家的正确维护

比如shipping piont的国家设置，有时候直接从原始项目中的某个拷过来了，改的时候只注意地址细节之类，没有注意到国家是不同的。这个是很容易忽略的。因为国家这个概念太大了，一般不会去理会它。在跨国公司roll out时尤其要注意。7.EDI配置

在roll out项目中，有时会用到公司间交易。公司间交易的发票自动入账可以通过EDI实现，所以要注意EDI的相关配置。8.税码设置

SAP有个专门的notes来说这个事情。跨公司销售时，在F2类型的发票上，税码是如何确定的呢？可以由出货工厂和客户所在国家来确定，也可以由销售组织和客户所在国家来确定。默认是前一种。如果要用后一种，要手工把notes打上。9.ERS的使用

在原始项目中，一般只有外部供应商，不会启用ERS功能。但在roll out项目中，有可能会使用ERS，因为内部供应商一般来说是可信任的。10.GR-Based IV 原始项目中一般都要启用基于收货的发票校验。但在公司间交易中，有可能会使用基于PO的发票校验。尤其是在使用公司间采购流程同时使用EDI传送发票时，最好使用基于PO的发票校验。这样在发货方发货做Billing之后，对方可以立即入账。如果启用基于收货的发票校验，则因为还没有做收货，会出现无法过账的IDOC。11.MRP的运行范围

多个工厂联合运行MRP，在roll out项目中可能是经常遇到的。要注意修改相关的配置。12.Client层级的字段选择

比如物料主数据，供应商主数据，inforecord等，都有client层级的或者事务代码层级的字段选择设置。在改动这一类设置的时候，一定要小心。本人曾经改动过一个物料主数据的设置，为了针对某个工厂设置某个字段，把原始项目的相关字段组全部改为工厂级，还原为原来的设置，只把需要的工厂下的该字段属性做了改动。最后却发现考虑不周，影响了其他已经上线的公司，造成了很不好的影响。技术方面和数据方面，需要注意的地方很多。本文只是列出一些本人所了解到的一小部分而已，希望能够起到抛砖引玉的作用。