北京航空航天大学研究生课程考核记录
课程名称：《 企业信息化管理
论文题目： 壳牌SAP项目实施总结 任课教师评语：
日壳牌SAP项目实施总结
本人所在的公司-英荷皇家壳牌（中国）有限公司已于2004年4月1日成功实施了SAP。本文是本人在成功上线后做的总结，发表在2004年5月的内部刊物上。本文部分内容有所增减。
荷兰皇家/壳牌集团公司是现今世界最大的石油产品，化学品，煤和金属的勘探者，生产者和经销商之一，在全世界一百多个国家的两千多家公司中拥有权益，雇员总数超过十万人。集团公司的五大核心业务: 冯雷
实现业务方案的服务也就是实施 SAP 项目的服务，下面是一个 SAP R/3
项目实施工作的简要内容表。从表中可以看出，有计划有步骤地实现业务方案，要做很多细致复杂的工作。从咨询公司得到这种专业化服务是有好处的。这也是一种“软件”，而且是一种纯粹的“软件”。引进和实施这个软件的过程，就是企业业务流程重组的过程，也就是实现业务方案的过程。咨询顾问的主要工作就是按计划地和企业管理人员配合工作，实现 R/3 系统的配置以及业务蓝图的设计。第一阶段: 项目准备
1.1.1 建立项目实施方案
1.1.2 审查和改进实施策略
1.1.2.3 为全部策略在公司亮相进行检查
1.1.3 建立项目组工作环境
1.1.4.2 通知每个人担当的角色
1.1.4.3 通知核心改变小组的角色
1.1.4.4 召开项目启动组会议
1.1.4.5 建立扩展的变更小组
1.1.6 建立项目组培训计划
1.1.6.1 讨论和通过实施建议
1.1.6.4 改变管理的培训和小组建立
1.2 项目程序 1.2.1 定义项目管理标准和程序
1.2.1.7 定义项目计划和监督标准
1.2.2 定义实施标准和程序
1.2.2.2 确认最终用户文档资料和培训
1.2.2.4 定义实施后期服务和支持策略
1.2.2.5 为项目组定义系统授权标准
1.2.2.6 定义系统问题标准和错误处理程序
1.2.2.7 定义系统升级和修改确认程序
1.4.1 确认技术需求计划
1.4.2.2 审查系统规模制定结果
1.5 质量检查项目准备阶段
1.5.1 实现质量检查和获得批准
1.5.1.1 通告质量检查方法和标准 1.5.1.2 汇报结束项目准备阶段 第二阶段设计蓝图
2.1 项目管理业务蓝图阶段
2.1.1 召开项目组形势会议
2.1.2 召开筹划指导委员会会议
2.1.2.1 准备筹划指导委员会会议
2.1.2.2 参加筹划指导委员会会议
2.1.3.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.7 建立技术开发过程的管理结构
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.4 审查和获取后期培训技能
2.4.1.1 记录物理系统规划和分布
2.4.1.2 定义和记录打印布局
2.4.2.2 检验初始系统技术环境
2.4.2.3 安装和配置开发系统客户
2.4.2.4 为项目成员安装桌面组件
2.4.2.5 为项目组建立用户主数据记录
2.4.2.7 为项目组 安装和设置打印服务
2.4.3.1 安装和设置开发系统客户
2.4.3.2 设置和测试传输系统
2.4.4 维护系统管理程序
2.4.4.1 管理基础和系统管理工作中心 2.4.4.2 为开发系统定义系统管理
2.4.5.1 建立企业IMG并维护项目标题数据
2.5.1 定义业务组织结构
2.5.1.1 安排组织结构工作会议
2.5.1.3 召开组织结构工作会议
2.5.1.4 建议和批准组织结构
2.6.1 准备业务流程工作任务
2.6.1.1 计划业务过程工作任务
2.6.2 导入全局需求工作任务
2.6.3 举行业务过程工作会议
2.6.3.8 精炼业务过程描述和模型
2.6.3.9 确定额外详细的工作会议的需求
2.6.3.10 安排详细需求工作会议
2.6.4 举行详细需求工作会议
2.6.4.2 精炼业务过程定义和模型
2.6.5.2 精炼项目组织和角色
2.6.5.5 检验业务蓝图完成情况
2.6.6 业务蓝图审查和停止
2.6.6.2 进行审查和结束工作 2.6.7 起草最终用户培训和文档计划
2.6.7.1 定义最终用户培训和文档
2.6.7.3 定案最终用户培训和文档计划
2.7 质量检查业务蓝图阶段
2.7.1 进行质量检查并获得批准
2.7.1.2 业务蓝图阶段结束 第三阶段实施
3.1 项目管理实现阶段
3.2 持续的改变管理步骤
3.3 项目小组培训实现阶段
3.4 基本配置和确认
3.6 最终配置和确认
3.8 开发应用接口程序
3.12 建立授权的概念
3.13 建立归档管理
3.14 最后的集成测试
3.15 最终用户手册和培训材料
3.16 质量检查阶段第四阶段准备
4.1 项目管理最后的准备阶段
4.2.1 准备最终用户培训
4.2.1.1 为培训准备最后的条件
4.2.1.2 建立用户培训基本条件
4.2.1.3 为最终用户的培训准备数据
4.2.2 进行最终用户培训
4.3.1 建立生产系统的管理
4.3.2.2 进行高使用强度测试
4.3.2.5 进行备份和恢复测试
4.3.2.6 进行打印和传真测试
4.4 详细的项目计划
4.6 质量检查最后准备阶段
4.6.1 完成质量检查和获得批准第五阶段 切换
5.1.2 评价实际业务处理结果
5.1.2.1 逐日和逐周监控传输过程
5.2.1.1 审查和解决存在问题
5.2.1.3 总结改变程序的结果
5.2.1.4 完成改变管理的程序 项目结束和把问题归档
本系列文章主要讨论在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项目中，要先给客户定下调子，这个项目不可能有很多的自由度，或许有很多实际的业务流程无法在系统中满足，只能通过更改现有的操作习惯的方式来解决实际问题。在数据分类，跨公司业务等涉及到全球模板的方面，要想更改是很不容易的，除非有特别的理由。
当客户对系统能够实现的功能有了较为合理的定位时，项目推进过程中就会避免很多抱怨。客户的主要精力才会由压迫顾问做事，转向自我改良去适应全球模板要求。
这并不是敷衍客户。全球模板之所以能被推广，一般来说不会有什么根本性的缺陷。某个子公司的特殊需求，经过认真分析，大部分可以在全球模板中找到解决的方案。第四，给予培训工作更多的重视。
对于全新的项目来讲，事前的流程讨论，业务蓝图的设置，需要用去很多的时间。这部分的工作做得越仔细，越认真，后续的系统实现和测试等就会越顺利。而在这整个过程中，关键用户都是全程参与的，无形之中他们已经学习了很多系统知识。同时，由于项目时间久，关键用户对系统的了解是由浅入深逐步进行的，会有时间去消化所学到的内容，后来的操作培训就会相对容易一些。
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的时候，子公司需要使用的话，要注意特性设置上用公司代码或者采购组织等区分开来，而不能简单地使用一个单据类型实现这个功能。
在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层级的或者事务代码层级的字段选择设置。在改动这一类设置的时候，一定要小心。本人曾经改动过一个物料主数据的设置，为了针对某个工厂设置某个字段，把原始项目的相关字段组全部改为工厂级，还原为原来的设置，只把需要的工厂下的该字段属性做了改动。最后却发现考虑不周，影响了其他已经上线的公司，造成了很不好的影响。技术方面和数据方面，需要注意的地方很多。本文只是列出一些本人所了解到的一小部分而已，希望能够起到抛砖引玉的作用。
随着电力市场改革的深入竞争压力日益增大，电力企业原有的管理体制面临改革。迫使企业需要坚持以科技为先导，依靠科技进步、技术改造实现节能降耗和增效。因此，为了及时建立以经济效益为中心的经营管理新机制，浙江省电力公司于1998年和1999年先后在其下属主要电厂及电力局实施国外成熟的SAP R/3软件的FI/CO（财务成本）模块和PM（工厂维护）/MM（物料管理）模块。
绍兴电力局作为浙江省电力公司的一个下属电力局，作为试点率先在成功实施了SAP R/3软件的FI/CO（财务成本）模块之后，于2000年6月开始实施PM（工厂维护模块）和MM（物料管理模块），已于2001年初上线，并与之前已实施的FI/CO（财务成本）模块有机地集成。通过PM/MM的实施，绍兴电力局将实现设备维修、物资的集中管理。
1.高级管理层 随着电力改革的日益深入，电力企业面临提高内部管理水平的巨大压力。目前，财务、维修、物料等工作已通过ERP软件进行管理，基础建设、技术改造是资金占用相对较大、管理较困难的项目，亟需使用系统工具规范项目管理，借助现代的管理方式来跟踪、监控项目从项目计划、审批、建设、决算的全过程，实现新系统与原有SAP系统各模块的有效集成，真正丰富项目管理手段和改善项目管理方式。
2.项目建设部门（基建处）
亟需使用系统工具规范基建项目管理的工作程序；
相关部门与其工作程序中的对应关系的明确，保证各司其职，避免发生由于工作关系不明确导致项目进度受到影响；
由于项目管理是一个严谨有序，时效性强的过程，所以需要在项目管理过程中设置必要的监控点，对于某些关键步骤或关键环节应能够按照一定要求进行预警；
在项目竣工结算时需要从不同方面对项目的概算和实际发生的情况进行详细的比较；
在项目竣工结算时及时提供准确的报表，如项目相关设备清单等
4.ERP论坛欢迎您业务部门（计划处、物资供应处、生技处等）
提供模板功能，能够方便地在项目计划模板上修改生成新的项目计划，从而提高工作效率并保证新项目计划的准确性；
根据项目进度适时的物料采购，在保证项目的正常需求的同时，努力降低项目专项物资的库存，以提高资金的周转速度及利用率；
需要对项目相关的专项物资进行专项管理，保证项目进度不受影响；
生产部门需要及时平衡内部及外部的生产能力，及时调配有效资源，帮助客观地制定及调整项目计划；
新系统的安全性可以得到保障，用户可根据其权限设定在系统中进行维护，查询功能。
三、系统选型及功能描述
国外已广泛采用结合在ERP软件中的项目管理模块或单独的项目管理程序对项目进行管理。国内采用单独的项目管理软件较多。为解决项目管理中的业务难点，可以采用引进ERP系统中的项目管理模块（如SAP系统的PS模块）或引进大型的项目管理软件（如P3）等方案，两方案的优缺点如下：
实现充分的项目管理功能；
与已有的SAP FI/CO/PM/MM模块有机的集成，有助于企业形成一体化的ERP系统，提高企业整体管理水平；
实施时间较长，各有关部门之间的协调较多； l
对实施单位的各方面的要求较高。
2、P3项目管理软件：
实现充分的项目管理功能；
实施时间较短，涉及的部门和需要的协调较少；
与已有的SAP FI/CO/PM/MM模块不能集成，需要大量的接口开发或根本不能实现与现有系统的接口；
对提高企业整体管理水平没有太大的促进。
通过综合平衡和考虑，我们觉得引进SAP系统的PS模块这一方案更为可行。现将SAP系统项目管理（PS）模块的实施目标描述如下：
1.优先解决项目管理中的业务难点，实现对基建、技改、科技等项目的全过程、全方位管理。
2.在该模块的实施过程中，有机地与之前实施的SAP R/3系统ERP论坛欢迎您模块充分集成
3.通过完整实施先进的/高度集成的ERP管理系统，使得绍兴电力局确立国内同行业管理水平一流的地位，并为其争创国际一流打下扎实基础； 4.通过绍兴电力局项目管理模块的实施，为在浙江电力公司ERP论坛欢迎您下属单位的项目管理提供借鉴经验。
在绍兴电力局项目管理模块的实施，可实现的功能大致包括：
利用系统进行项目成本归集；
建立有效、适用的项目管理报表系统；
与SAP R/3系统前期实施的ERP论坛欢迎您模块实现集成
现将SAP R/3系统项目管理模块的功能结合绍兴电力局的现状具体分述如下：
项目是含有一些特殊特征的任务，它们通常相对复杂、有唯一性，并且有一定的风险；需要在一定的限定期间内0 完成，由项目参与各方共同制定的具体目标；同时受到成本和能力的影响；对于项目的质量也有具体要求。由于某些项目的执行通常对其公司具有战略重要性；项目通常作为公司内部流程的一部分。
为了能在项目进行期间控制所有的明细任务，需要有一个涵盖所有相关部门的组织结构与之相适应。对此，SAP R/3系统项目管理模块针对项目以上特点进行项目管理。
为了能够全面地执行项目，项目目标必须描述清晰，并且所要执行的项目活动必须结构化。一个清晰明了的结构化项目是进行计划，监控、管理并最终获得成功的基础。
在SAP R/3系统的项目管理模块中，用户可根据项目的类型及其监控的重点，使用工作细分结构和/或网络标准结构将其项目结构化。系统提供标准的工作细分结构和标准的网络可供用户参考，从而方便地建立标准化的，适合自身的项目结构及事件顺序。
复杂的项目更需要全面、易于理解的文档以及技术文件的规范，SAP
R/3系统的项目管理模块为用户提供有效的文档管理工具和项目管理文本。文档可包括如CAD图号，变更程序、合同信息等内容。系统中的文档管理使得这些信息可在系统中集中获取。项目文本则是直接为项目中的一个对象生成的，如功能规格说明、工作包(对项目中一具体活动定量、定性的说明)描述、注释。对于这类信息，用户可通过项目管理文本来维护。在文档管理中，可通过SAP内部文档信息的记录参照外部的文件。使其所链接的外部的文件可在线显示，如CAD图纸，微软Word
文件、图像图形文件或者合同等仅供打印的文件。基于项目分散计划、控制的目的，可以在系统中通过设置，使用户无须进入SAP R/3系统就能在企业内部互联网中取用这些资料。
生产资源/工具与机器和固定资产有所不同，他们是可以被用来执行具体行动并且可被重复使用的灵活资源。如：图纸文档、工程制图工具、工装夹具、计量器具等。
用户可将其分配给内部或外部的活动，通过分配决定：执行该项活动所需的工具数量，操作时间，日期。在SAP R/3系统中可通过将生产资源/工具分为物料、杂项、图纸文档、设备四类，并籍此对其进行管理。
通过计划、监控和管理项目成本，以达到全面的成本帐务处理。
SAPR/3系统的项目管理模块通过与系统中的CO(成本)、FI(财务)、PM(设备维修)、MM(物料管理)模块集成，实现以下功能：
不同明细程度地进行成本计划
利用预算分配和可用额度的管理进行资金管理
将项目中某项工作（需定义为网络活动）所需能力与其相关工作中心所能提供之能力进行比较；
为了优化能力利用率及选择合适的资源而进行能力测算；
基于管理经验的标准报表系统
即时生成项目的实际成本
根据需要使用预算报警功能，有效地监控项目预算的执行情况
通过报表系统提供项目决算所需信息
对于项目相关数据，在充分进行数据共享的同时，通过灵活设置，能实现以下四个层次的安全控制：
工作职责层面的安全性；-
具体执行人或责任人的安全性
总而言之，SAP R/3系统项目管理模块可以比较集中地全方位地监控项目的全过程，包括项目计划、预算、成本、项目状态、资金流等项目的方方面面。其与原有SAP R/3系统各模块的集成，不仅能实现不同层面的信息共享，同时将大大优化项目管理的方法，最终全面提高项目管理水平。
考虑到目前绍兴电力局对于项目管理的需求较为强烈，加之SAP R/3系统的FI/CO、PM、MM模块先后在绍兴电力局成功实施，SAP系统的实施及应用经验相对较为丰富，各有关部门的支持力量较强，绍兴电力局的SAP用户也有着相当的系统应用经验和集成意识，给项目管理模块成功实施提供了较好的基础和保证，因此，在绍兴电力局进行SAP R/3项目管理模块的实施是可行的。
