项目总结会议经验谈

第一篇：项目总结会议经验谈

项目总结会议经验谈（转）

项目总结会议经验谈

序：笔者主持过大小四十多个项目，参加过无数次的项目会议，对此可说是游刃有余，而且笔者主持过的项目总结会议中，有几个就是在同事们意料之外的表情中，和客户签署了项目验收文档的。然而，年前的一次项目总结会议却是铩羽而归，虽然原因很多，并非笔者的失误，但结果是全面失败。这次的老马失蹄使得笔者静下心来，对所参加过的项目总结会议进行总结，在此提出两个观点，三个准备和四个步骤，以希望更多的人获益。

两个观点

一、项目验收的标准的不同将决定项目验收的进度和难度，尽快地让项目验收是项目经理首要的职责

越是大项目，验收的标准和细节就越多，同样也因为金额大，所以涉及验收的人员也多，在谁签字谁负责的压力下，大家都不愿意先签字，就使得项目验收的标准变得比较不可捉摸。

在大项目中查找不适合验收标准的问题，就相当于打靶的目标是我们所站的地球，随便怎么打，都能中。因为客户内部都会有一套连卖硬件都难过关的验收标准文档和流程，更何况是软件验收。如果真的按客户的要求和标准执行，团

队再进行两年的开发，还不能保证能通过验收。

所以，大项目的验收，往往都包含着三分人情。项目经理平时就要搞好和客户的关系，双方在验收的标准上能有个双方都可以接受的方案，共同把事情做好，如果做不好，虽然客户他也有责任，但你的公司却要为此多付出很多的人力

物力时间和资源。

二、项目总结会议是决定项目能否顺利通过验收关键与跳板，要把握好这机会，不要打无准备之仗

项目总结会议，顾名思义，就是对项目的工作进行总结，哪些做到了，哪些还没有完全满足客户的需求，哪些是还没有完成的工作。因为软件的运行有个周期，其需求会随着用户使用的程度，而提出更多更完善的需求，同样，也会使

得项目的周期会比商务谈判时所想像的要更长一些。

因为有商务合同和项目组工作的汇报，如果能获得客户的认可，同时，软件功能，在客户目前所提的范围内，有了一定的实现，则项目总结会议很有可能会变成项目验收的跳板，至少对项目验收会有非常好的心理预期，让双方的中下层人员在接下来的工作中，都以项目验收为中心的工作，会让项目工作顺利地转入验收期做最好的铺垫。

三个准备

一、全面了解项目情况

很难想像一个对项目进程和工作不了解的项目经理，能主持好一个项目工作总结会议。项目验收的流程就象是链环，一个套一个，其中的任何一个环出了问题，整个链就断掉了。因为其中涉及的细节太多，客户所问的任何一个问题，你没有做出让客户满意的回答，就很难保证客户会让会议结果朝着你所想像的目标进行。

所以，项目经理在会议开始之前，心里就应当要非常清楚，这个项目中哪些是客户关注的，项目组完成的情况，以及客户的满意度，特别是客户领导所提的需求的满足度。以及项目进行到什么程度，在项目进行过程中，客户的想法和

态度等等。

在此基础上设想，客户对我们的满意度，如果满意度达到一定的程度，就要明白在正式会议开始的时候，哪些会是客户重点关注的业务，客户在这些关注点上的态度和底限，预先知道客户会出什么的牌，会让你在会议上有着出人意表的收获。

二、知晓参会人员特点

在项目实施过程中，要注意收集客户基本的为人处世的信息，比如某人对要他签字非常感冒，非常怕担责任，某人比较好说话，某人实事求是，某人对细节问题非常关注，某人有整体的项目观念，等等，平常注意这些信息的收集，总

会在某些特定的场合让你的项目更加顺利地进行。

在知晓客户的这些信息后，要尽可能地了解客户在参加会议那几天的工作安排，尽可能地让对项目有利的人员参加你的项目总结会议。千万不要碰到能帮你说话而且权重比较大的人物，在你预约的时间出差，把你的计划全部打乱。

同时，更要多考虑对项目满意度不高的人，特别是对项目抱有敌意的关键人物，越早了解这样的人可能出的牌，对你的项目就会越有利。因为即使客户中有人帮你说话，但只要有人执反对的声音，作为同公司的同事，客户还是帮他的同事，而不是你。

三、确定切实可行的目标

不参加没有议题的项目会议，每次项目会议都一定要有一个明确的会议主题，即使是项目例会。没有目标的会议大家过过场，其实那是浪费双方的时间，也是项目经理的失责。

同时在了解项目过程与现状的基础上，针对参会人员的特点，制定切实可行的目标与你所要实现的最低目标，并抱着最低目标进会议室，在此基础上和客户商谈。过高的目标与期望只能在客户都非常认可你们的工作，对你们所在的公

司也非常认可的情况才会实现。

同样，以较低的可实现的目标向你的领导汇报时，在实际会议结束后，如果争取到了好的成绩，领导当然更高兴了。相反，如果预期目标过高，而实际却没有实现，很难想像你要如何向领导交差。

四个步骤

项目总结正式会议

一、实事求是地对项目过程进行总结

这是一个开场白，根据习惯和现场情况，也可以将第二点放在首先开始的位置。

在对项目过程总结的时候，还是要注意尽可能谈大的方面，对项目有利的要多谈一些，项目过程中发生的不愉快则不要谈及，同时避免将会议的主题往细节方面偏。对客户在项目过程中的帮助不要忘记提一提，特别是他们领导在场时。

实事求是但不忘方法。

在项目总结过程，要强调的是关键的里程碑，双方的付出，客户方人员的变更，过程的辛苦，这是感情牌，有可能对会议过程会有不小的收益。软件的运行状况一定要报告的，谈的要是总体的情况，因为细节问题和让他们不满意的可

以谈三天的。

二、明确项目已完成和未完成的工作

任何一个项目，总是做不完，就算全部做完了，也不可能做到尽善尽美，而且更不可能做到客户的百分百认可。所以，已完成的工作一定要重点强调，未完成的工作还是要提，因为总结会议上提到了未完成的工作，大家的心里也会开始逐渐不设防，容易流露出他们真实的想法，同样，也不会让他们有着验收的压力，虽然我们的目的是为了验收。

同样，已完成的工作中获得哪些客户的认可，最好能表示一下，避免大家为了担责任又相互踢足球，同样，其他人都认可了，会让会议更顺利一点，为我们的预期目标实现铺好路。

三、探听对方的虚实和态度

项目总结会议的最高目标就是为项目验收做铺垫和引信，所以在项目总结会议上看客户对项目过程的总结和未完成工作的报告时，就能明白客户的态度了。

此时客户不可避免会根据项目过程中的某些问题谈自己的看法，此时，要避免和客户发生争执，要用较委婉的方式提出让客户觉得我们努力了，而且结果总体上也还是不错的，能说得过去的，记住在客户的同事们面前要保留住客户的面子。

如果客户此时没有异议，表示可以接受，就说明客户对项目整体上还是可以接受的。如果客户对此还是有一定的不能接受，这时一定要再对客户的此问题进行解释，以达到他所提的是有道理但却超出项目的范围。如果客户对此异议较大，则需在不伤客户面子的基础上，据理力争，最好是由下层人员发表意见，以便为项目经理或更高层的副总和总经理

留有更广的回旋空间。

如果某些客户提出近乎耍无赖或苛刻的要求，此时，现场最高职位的人一定要站出来，发表对其的批评和意见，因为此时不制止，就算客户的同事明白这情况，但也不会发表相左的声音帮你说话的，相反，要是高职位的人员出面说话，客户的同事特别是职位比他高的人反而会帮忙制止他的要求，如果提这样无理要求的客户是项目经理或更高职位，那现场上，中下层人员包括项目经理都要做好和客户吵翻天的准备了，此时，闹得越大，只要有理，虽然人员会更换，但项目的验收一定会比所有的预期中更快的时间完成，甚至本周就会完成。

四、结合现有情况逐步实现目标

项目总结会议并不是项目验收会议，所以特别忌讳项目验收签字付款这类的词汇，更不能在会议刚开始时，就表露出这样的心态，除非双方公司有非常铁的关系，对方也非常愿意近期将这项目验收才成，不然项目总结会议会使得双方变得有敌意，而且客户会因为你所说的这些话开始对你设防，处处抵制你所说的项目情况，会议就会陷入细节辩论，使

得会议劳而无功，所有的预期目标都难实现了。

所以，一开始你要隐藏目标，在了解了客户对项目的态度和底线后，再根据现场你所主导的气氛和客户对项目的认可度，再决定你所能达到的目标，如果觉得目标客户不可能答应，就不要提。所以在现场，只能根据实际情况顺势利导，提出对方可以接受的要求，以保证会议会有收获。

结合现场情况，在实现初步目标的基础上，逐步提出更高的目标，会让客户在不知不觉中逐渐认同你的观点，项目过程中的某些不足客户也会觉得情有可原，大家心里都了解都明白，只要不陷入细节的商谈，会议的预期目标会在非常自然的情况下被客户认同的，因为只要我们项目做到位，客户是不会去非常刻意地为难我们的，他们也希望项目能验收，特别是元旦和春节之前。

第二篇：IT项目收尾管理经验谈

IT项目收尾管理经验谈

2013年12月20日 09:24 来源：中国项目管理资源网 作者： 字号

打印 纠错 分享 推荐 浏览量 267

所谓验收就是对整个软件开发、建设项目的结果的综合评价，是软件系统交付使用前对项目进行评估、认定和总结的过程，包括费用、质量、服务等多个方面，包括对整个系统的运行情况、业务流程重组的有效性、生产运作的效率等方面的一个评估，也是对IT项目范围的再确认。IT项目的实施，一般包括6个阶段，即项目的选型、培训、业务流程重组、基础数据整理、会议室试点、切换等，在系统切换后，紧接着的还有一项关键性的工作，就是项目的验收。

IT项目验收主要是通过对项目全面测试性检验，找出项目中可能存在的问题和不足，并进行最后的修正、完善，以使项目保质保量最终交付到用户单位每个使用人员手中。可以说，验收是IT项目最后关键的环节，它是对项目的实施质量和软件的可交付性起到“一锤定音”的作用，也关系到IT项目能否平滑顺利步入运营期、为企业创造效益，软件开发服务商能否实现收益标志之一。因此CIO必须高度重视，万莫轻视。

比如ERP项目，由于其软件的复杂性、规模性，CIO们可能更多地关注它多变的需求定义、选型、个性化解决方案，却轻视了项目的验收工作，而验收需要大量数据测试、自定义扩展、长时间运行等后才能明辨优劣、成效，但是由于供需双方受种种原因的影响急需“结账”，从而使项目验收从时间、内容、范围、数量、人员等投入均显不足，而且由于多数信息化项目的验收评估标准难以具体量化，常使验收常流于形式，最终使实施结果不佳。

为何不少IT项目成了“鸡肋工程”甚至变成“烂尾工程”?一个重要原因就是最后一个关--“验收”疏忽大意，没有把关好，前功尽弃，败走麦城。对此，作为企业信息官的CIO，负有重要责任。还有，一些用户单位CIO以为项目实施工作做好了，系统跑起来了，文档移交了，开发商确认了，还有什么必要大动干戈做验收？这些想法、做法，源于对验收的目的、流程、方法和意义缺乏认识，造成一个个延期工程、半生不熟项目或烂尾工程。

一、把握项目验收的重点内容

可以说，验收事关项目能否善始善终，悠关全局的成败，那么CIO如何做好项目验收？从哪里重点把握？结合理论与实际操作，一般而言，IT项目验收主要应包括验收准备、数据移植、系统测试、系统评估4个主要过程。

1、着手验收阶段的准备工作

当单位始要进入验收时，CIO应着手进行相应验收的准备工作--向软件开发商收取软件开发过程中各阶段性文档，包括需求分析说明书、概要设计说明书、详细设计说明书、数据库设计说明书、源程序代码、可供安装使用的系统安装程序、系统管理员手册、用户使用手册、测试计划、测试报告、用户报告、数据移植计划及报告、系统上线计划及报告、用户意见书、验收申请等；然后对这些各类约定的技术文档和合同中的相关内容进行自查，要彻底了解系统目前完成的情况如何，是否已完成了与开发商达成的各项书面约定以及口头约定，没有完成的，如果是书面约定，准备采取什么策略去进一步完成等。

当然，此时CIO做一个详细的验收计划是非常必要的，可以用来作为验收阶段的工作指导，并组织管理层领导、业务管理人员和信息技术专家成立项目验收委员会，负责对IT项目进行正式验收。

2、数据移植

如今不少企业都上了OA、CRM等系统，或淘汰老系统，在进行新系统(如ERP或PLM)建设并最终上线时，一般需要将旧系统的原始数据移植到新系统或调用企业原有的OA、CRM等系统内的数据时，则常需数据移植，此时CIO正好可籍此机会检验新系统的优劣、匹配性如何。这些应完成以下主要工作内容：

1)制订数据移植：除了要定义数据收集的格式、范围、进度外，还要考虑系统接口的影响，并建立数据移植完整性和准确性测试方法以及意外事件处理程序;

2)数据收集：项目实施常涉及到数据收集，应由数据收集小组根据数据收集格式，准确对数据进行收集，以确保数据提供人员了解和掌握对数据收集的各项规定和要求;

3)数据导入并核查结果：项目组成员将数据导入系统，并在导入后按照事先制定的数据移植完整性和准确性的测试方法，对系统中的数据做进一步的核查，确保导入数据的质量;

4)数据移植后要进行适当时间的试运行，检测、确认数据移植的真实性、准确性和完整性。

3、系统测试

系统测试是项目验收的关键环节，也是CIO最需花心思把关之处。以ERP软件为例，系统测试具体包括以下5大测试内容：安装测试、功能测试、界面测试、性能测试、文档测试等。而其中，功能测试是重点，必须高度重视。

下面结合ERP，重点阐述如何有效进行功能测试，其功能测试的用例设计，主要应注意以下几点：

1)测试项目的输入域要全面。要有合法数据的输入，也要有非法数据的输入，CIO可以此检验系统的抗干扰性如何;

2)要适时利用边界值进行测试。如“订单预排”中一般要求预排的数量大于0，那么测试数据可以分别为0，-1，1，100000(一个非常大的正数)，查看单据流转和控制情况，系统在执行MRP分解、工单下达、车间任务调度等操作是否正确;

3)CIO可不按照常规的顺序执行功能操作，查看系统计算的准确性，如仓库历史库存、当前库存、货位库存是否准确;

4)验证实体关系，实体间的关系有三种：一对一，一对多，多对多。如一个MPS对应多个MRP，一个MRP对应多个车间任务，CIO对此检验，看能否对应;

5)执行正常操作，观察输出结果的异常性。如CIO删除某条记录对排序的影响，或执行审批后，单据的状态是否改变，报表的打印输出效果如何;

6)划分等价类，提高测试效率。要划分等价类，选择有代表意义的少数用例进行测试，提高测试效率等等。

4、其它系统测试

除上述的系统测试外，CIO还有必要对系统的其他特性和需求加以测试，这些系统测试也很重要，主要有以下几种：

1)负载压力测试，主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试，一般采用自动化技术分别在客户端、服务器端和网络上进行测试;

2)恢复测试，通过模拟硬件故障或故意造成软件出错，检测系统对数据的破坏程度和可恢复的程度;

3)安全性测试。通过非法登陆、漏洞扫描、模拟攻击等方式检测系统的认证机制、加密机制、防病毒功能等安全防护策略的健壮性;

4)兼容性测试。通过硬件兼容性测试、软件兼容性测试和数据兼容性

测试来考察软件的跨平台、可移植的特性;

5)性能测试，性能测试主要是测试软件的运行速度和对资源的消耗。

5、评估整个系统运行效益

作为信息部门的一把手，聪明的CIO应在项目合同上写明系统试运行2-3月后再来验收、付款的规定，以争取主动。CIO的做法主要是录入1-3月的企业相关经营数据进行核查，目的是利用此段时间来判断系统上线运行后能给企业带来哪些积极变化和成效--看它有无促使企业在管理思想、管理模式、管理方法、管理机制、管理基础、业务流程、组织结构、规章制度、全员素质、企业竞争力、企业形象、科学决策和信息的集成与处理等方面发生一些明显的改进、提高和创新;企业是否运用ERP系统对整个供应链管理中的各相关环节和企业资源实行有效的规划和控制;通过财务模块分析，企业在客户关系管理、市场预测分析、加强财务管理、合理组织生产、资源优化配置、压缩生产周期、降低物料库存、减少资金占用、降低产品成本、提高产品质量、扩大市场销售和实行电子商务等方面有无产生相应的经济效益等。如果在这些方面，用户感觉良好，表明系统运行成功，那CIO就可放心正式验收、签单付款了。

二、项目验收的几大注意事项

CIO把握、核检了项目验收4个主要过程了，并不表示万事大吉，尚需对以下几大事项高度重视，加以解决，以保证项目和验收全面顺利完成。

1、依据行业标准制定验收规则。验收是目前或许是一个比较模糊的概念，业内一直都没有一个统一的标准，随意性大。而这种“验收的随意性”对于用户单位来说将是一个致命性的错误，产生此类问题的根源就在于CIO常不知道或根本就没有制定合理的验收标准，从而导致IT项目在验收过程中，主次颠倒，忽视了对关键业务流程的验收。因此，只有明确了相关系统项目的验收标准，才会做到有备而来，从而达到验收的目的。CIO一定要重新明确、制定每个阶段验收标准和项目总体验收标准，时刻维护验收的严谨性、权威性和准确性，必要时可请第三方咨询顾问机构来帮忙把脉把关。

2、把握验收的时间火候。一般而言，要根据软件模块的多少、系统涉及部门人员、投入费用的多少，CIO要在验收时间上进行更多考量、把控，别急于收尾验收。大型的ERP项目通常是边实施边验收，一步一步地向前推进，以便一边发现问题一边解决问题，但中小型的ERP项目最好是成功切换后，录入了一个月以上的数据，运行一个月时间，再来验收。毕竟一个月才是一个小的系统周期，如果小的周期都没有跑顺，就更别说一年这样的大周期了。如ERP系统能做到平稳运行两个月以上，能够准确导出各类月度报表的时候，系统应用和各项业务操作基本正常、顺畅，通常而言，可认为系统已达到的效果或者是达到了先前预定的目标，系统项目上线成功了，验收可算通过了。

3、建立有效的解决冲突机制。用户、开发商在实施、验收IT项目过程中难免会发生冲突，造成IT建设偏离轨道。关键是事先是否有明确的项目目标和项目要求，是否建立起有效的冲突解决机制。CIO主要是要明确今后双方责权利关系，可对将来可能发生重大事件或不可抗拒事件所引发可能的实施超期、费用超支、产品价格调整以及服务收费超标等事项、行为及其权责做出预测，并有效约定，从而使信息化项目从一开始就按预定的规道行驶，避免再发意外。因此CIO要快速查找以前问题所在，既然上次合约没有明确细节，也就意味着可以增加验收内容，明确细节和进度，从合同中挑出对方的问题，与对方补签合约，保证项目有效进行。建立解决冲突机制，是为了使验收更好地执行。

第三篇：房地产项目周总结会议

唐霸华府2014年12月21日周日总结会议

唐霸华府的家人们下晚上好，大家辛苦了我代表公司、个人感谢大家。经过大家风雨无阻，不怕苦不怕累的战斗精神，团结一心奋战的精神，我们取得了初期的成绩，好的宣传效果，让我们售房部来访不断。说明一份付出一份收获。离我们认筹排号时间不多了。大战在即让我们拿出我们唐霸华府超人一般工作方法和能力去冲刺我们的任务和目标，俗话说得好，是好钢你用在刀刃上，到了我们展现的时候了，我相信我们唐霸华府的每一个人都是好钢，大家说是吗？下面我们开会，一：先汇报一下本周任务完成情况，个人汇报，案场第一名奖励红包一个（50元）少完成一个任务乐捐20元。刘媛媛：任务

实际完成董

敏：任务

实际完成 杨

娜：任务

实际完成赵苗苗：任务

实际完成薛舒静：任务

实际完成0

高

赛：任务

实际完成拓展部：任务

实际完成

二：定下一周任务，注：置业顾问或拓展部经理不许比上周任务少只许多。

刘媛媛：任务6

实际完成 董

敏：任务5

实际完成 杨

娜：任务3

实际完成 赵苗苗：任务3

实际完成 薛舒静：任务1

实际完成 高

赛：任务1

实际完成 拓展部：任务17

实际完成三：置业顾问；拓展部经理发言总结本周工作。四：工作纪律确定，摆位接待纪律，执行刘媛媛。

五：暴风雨般的掌声有请李经理和刘主管进行施行乐捐和发奖仪式，五：本周总结会结束，祝唐霸华府全体家人周末愉快，明天节气冬至大家都记得吃饺子不然耳朵会冻呀。掌声

2014年12月21日

第四篇：经验谈

2012，很特别的一年，世界末日并没有打破所有考研学子的梦想，我也一样，坚持到了最后一刻。我是2013年考华中师范英语学科教学的，考研这一年当中我最喜欢浏览的网页就是考研论坛了，从这里了解到历年华中师范的题型，还经常关注其他研友的备考心态。浏览考研论坛确实挺另人兴奋的，每次都会有不一样的收获。很感谢考研论坛为所有的学子提供这样一个平台。以前在论坛了解了挺多东西的，经历了一次考研，也了解到了一些华中师范英语学科教学的一些新动态，仅供给2014的学弟学妹参考。

英语学科教学是专业硕士，主要要考四门，政治，英语二，333教育综合，833专业英语。政治大家都要考，所以比我有经验的很多，所以不说了，英语二今年考得挺简单的，也是国家统考，所以这些信息都比较好掌握。发这个帖主要是要说一下华中师范今年的333教育综合及833专业英语。

333教育综合，因为我刚开始什么都不懂，所以报了一个凯程酷考的全程班，花了1600多，可能确实有点多，但那时以为特别难，又不知道怎么动手复习，所以就急急忙忙地报了一个班，有没有这个必要能，我觉得还是看个人吧，现在觉得教育综合确实不难，如果自己能踏踏实实看书，真的问题不大。凯程酷考对我最大的帮助是它每个时间寄资料过来，分批寄过很多次，这不仅让我复习有指导性，还让我坚持到最后，当我每次收到资料时我都会特别有感觉，我知道我下一步该怎么做了，就是这种感觉让我稳步前进。还有就是他们的资料确实很全，以前有学姐有前几年的，但酷考今年跟凯程联办，所以2013年的资料增加了不少，拥有他们这些资料，自己踏踏实实看书基本上问题不大，虽然有大纲，有参考书目，但是我觉得凯程酷考的资料确实是最好的，今年333教育综合感觉自己答得比较顺利，其实这一年自己确实花了很多时间在这么功课上，但到考前我最怕考教育综合，我总怕自己到了考场上什么都忘了，答不出来。如果真踏踏实实复习过来，真不用担心，到了考场上以前背的全记起来了。教育学从大三下学期我就开始准备了，那时都在看那六本厚厚的书，还有大纲，还一边听凯程的基础课程，看了挺久的，这是第一轮复习教育综合。接下来就是暑期凯程强化班了，资料有大纲详细解析和题库了，十月份有个真题和专题，十一月份就是冲刺班，有冲刺资料考前必会题，掌中宝，还有模拟题7套。所以我说333教育综合我资料最多，花的时间和钱也是最多的一门，不过还是挺有收获的，不管结果如何，这一年都过得特别充实，考场上也还比较顺利，也没有追求太多，经历也是一次不错的选择，选择考研一点都不后悔。接下来说下今年333的题型吧，今年题型有点变，15题选择题，挺简单，4个名词解释，4个简答，3个论述题。名词解释：体育，白版说，形成性评价，还有一个忘了。简答：教育的文化功能，人格发展规律，朱子读书法，教师教育素养。论述题：举例说明启发诱导原则的基本要求，陈鹤琴的活教育论，加德纳多元智力理论。就是这些题型了。

今年感觉最难的就是833专业英语了，题型有点变动，而且感觉比前两年的更难点，以前的单选蛮简单的，今年有点难。今年备考当中确实用在专业英语上的时间比较少，因为没有指定的书目，不好准备，也不知道怎么准备，所以感觉有点难。先说下题型吧，单选20个，以前的是老六级单选，今年基本上不存在了；然后是改错，两篇阅读理解；接下来是完型填空，自己填单词，没选项，有点难；下一个题型是true or false,基本上语言学的，这个题型经常变，以前考缩约词，歧义句，名词解释，之前我都是准备这些的，所以真不好准备，真不知道明年老师又出什么题目。接下来就是有关教学法的翻译了，不怎么难。最后一题是作文，没怎么变，关于杜威的教学理论，总结评述一下，就是这些了，说怎么准备吧，每个人都有不一样的方法，知道题型就自己找适合自己的方法，英语确实不好复习，不像教育综合，怎么都不会超出这个界限。

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