sap成功实施实地指南.pdf

掌握旋风：SAP 成功实施实地指南 CAPTURING THE WHIRLWING Your Field Guide to a Successful SAP Implementation 第一章 导言.错误！未定义书签。工作流是条河，SAP 是行驰在河上的船.错误！未定义书签。第二章 让星星成为你的向导.错误！未定义书签。制定看得见，能衡量的成功标准.错误！未定义书签。第三章 SAP 实施，立竿见影.错误！未定义书签。一套快速 SAP 获取、培训和实施方案.错误！未定义书签。第四章 渡过河流，穿越树林：空中俯视.错误！未定义书签。计划你的 SAP 实施.错误！未定义书签。第五章 从彷徨者到探路人.错误！未定义书签。各式各样的 SAP 教育浪潮.错误！未定义书签。第六章 用好童子军和雇佣兵.错误！未定义书签。充分利用你的咨询顾问.错误！未定义书签。第七章 分清南北.错误！未定义书签。如何避免走入通常的失败怪圈.错误！未定义书签。第八章 只有你才能预防森林火灾.错误！未定义书签。在 SAP 实施中范围之火是如何点燃的.错误！未定义书签。第九章 勇敢的新世界.错误！未定义书签。考验所有相关人员耐心的文化和业务变化.错误！未定义书签。第十章 指点迷津的详细地图.错误！未定义书签。在 SAP 实施中识别失败以及辨认成功.错误！未定义书签。第十一章 咨询联盟.错误！未定义书签。头脑、热情和勇气.错误！未定义书签。实地指导帮助页面和注解。.错误！未定义书签。SAP 应用程序名称：.错误！未定义书签。术语和缩略词：.错误！未定义书签。因特网介绍：.错误！未定义书签。后注：你是否有个大问题？19YY.错误！未定义书签。序 在北美地区的 SAP 现象已经成为媒体中无数篇文章的主题，SAP 自己就为其产品提供了近百万页的文字资料。然而，在我们第一本书迎接旋风：SAP 世界初学者指南出版以前，并没有简单、客观的材料能回答这些基本而又热门问题：SAP 有何不同？SAP 能否持久？为什么实施如此昂贵？等等。由于需要能回答这些问题的原始资料集，我应咨询联盟管理伙伴克利斯 symbol 160 f Wingdings s 14 卡尔森和沃夫根 symbol 160 f Wingdings s 14 贝兹之约写了这本书。最初，我们将此书提供给参加我们主办的主管讨论会的人员。我们原想把书写得简短、紧凑一些，这样人们就能在从芝加哥到纽约的班机上读完。书上没有标价格，因为我们并没打算把书当作“销售品”，而只是作为比咖啡杯或钥匙圈更实用、更有说服力的赠品送给我们的客户。令我们特别感到荣幸的是，我们开始接到询问，许多人要求多购买几本。随着越来越多已在实施或考虑将来实施 SAP 的公司和个人向我们订购此书，这样的询问成倍增加。然而，我们惊奇地发现有许多已进入 SAP 领域有一段时间的人们也在强烈要求获得此书。我们甚至还目睹了一位有三年 SAP 经验的人偷窃此书。这不由得使人深思一番。为什么有 SAP 经验的人竟会偷这本书？我们觉得书名中的“初学者”可能是关键所在。无论我们对 SAP 的了解有多深，无论我们有多少经验，SAP 是个广博和日益发展的主题，我们任何时候都会觉得自己仍处于初学者阶段。这第二本书就是为了帮助你越过初学者阶段，进入一个对 SAP 实施项目而言比较轻松自在的领域。如果你对 SAP 还很陌生，我们建议你在阅读本书之前先阅读另外的一本书，这样你才能充分受益于这些内容。如果你认为你已掌握了 SAP，那么.不，我们怀疑有人会这样认为。无论如何，我们想使某些变得越来越隐晦的内容清楚明白地呈现出来。事实上，范围管理、咨询要求、差异分析、方法与工具和其他一些在传统实施中看起来已掌握了的内容，在 SAP 实施中根本没有被掌握。相反，在如何实施这套声名显赫的业务功能和工作流系统方面，还存在着不少的迷惑之处。这样的后果就是产生高度的压力、时间和金钱的浪费、巨大的失望以及对 SAP 本身无端的指责，就好象供应商应对任何明显的产品误用负责似的。本书不是 SAP 实施的方法集，也不是循序渐进的步骤指导，因为我们认为 SAP 实施本没有菜谱式的成套方法。我们已不再处于软件安装或是单个应用程序的安装阶段。SAP 是涉及全企业的项目，如果仔细地设想，该项目将覆盖你公司所有的方方面面。因此，我们考虑到了大多数 SAP 实施中存在的主要因素，在这本实地指南中，我们向你提供了指引方向的指南针，提供了使你免受雨淋的帐蓬，提供了生存技巧方面不同寻常的建议，也始终如一地提供了对于我们所处的工作时代真实的观察意见。SAP 是一阵旋风，如果能妥善处理，也是能使我们获益的旋风。所以你要步步小心把握前进的方向，别让你的火柴淋湿。我们希望能在彩虹的另一端见到你。第一章 导言 工作流是条河，SAP 是行驰在河上的船 谁害怕 SAP？你是谁？为什么要阅读本书？本书一部分是告诫性的故事，另一部分是指南。在告诫性故事方面，我们将详细列举存在的威协和风险，指出各式各样等着让你踏上摔一跤的香蕉皮，指出隐藏在阴影中的怪物和其他咨询顾问，指出吱嘎作响的桥梁上这里那里松动的结缝。这样做并不是让你丧失信心，而是为了帮助你，强调 SAP 实施与其他所有你迄今为止经历过的项目之间的巨大差异。到本书付印时，SAP R/3 可能将已售出超过 6,000份许可证。其中，大多数许可证已带来了成功的实施，而另一半正处于不同程度的实施过程之中。本书不是为了吹嘘 SAP 在世界范围内的成功。如果你需要事例，可以登录上网，在因特网上键入 SAP.COM，你就能找到许多成功的故事。随着我们即将跨入新的一千年，信息系统技术正令人高兴地与通信技术以及新的商业前景结合在一起，这样的结合是重要的，新的商业前景同二次大战结束以后一直存在的标准、原则截然不同。SAP 具有极大的市场占有率和雄心勃勃的业务范围，在世界商业应用软件市场没有势均力敌的对手。只有用 SAP，公司才能设想拥有在客户机/服务器环境中运行在多种硬件平台上的集成应用程序套件，才能同时拥有全球性规模上（多种货币、多种语言）的因特网通信，电子数据界面和应用链接实现（ALE）。SAP 是只诱人的苹果，许许多多的公司都蜂拥而至急于咬上一口。但是不幸的是，吞下这只苹果所要求的远远超过这些公司所能准备的条件。在 1993 年和 1994 年，整个新闻界对于 SAP 的发展、它的承诺以及它的成功信心十足、兴奋不已。但到 1995 年和 1996 年，新闻界由于幸福杂志前 500 名公司在实施上的挫折以及 SAP 竞争对手的抱怨声，而变得有些敌对。持否定态度的新闻中不断重复的主题是，相对于其它系统实施而言，SAP 实施所需的周期较长，费用较高。于是就存在着谬误。“其它”安装是单个应用程序或者有限的几个应用程序相联的安装。只有 SAP 的实施是涉及全企业的，包括公司的各个方面。这样SAP 实施和“其它”安装之间就无法再比较了，大多数危言耸听有关 SAP 失败的文章，也失去了其存在的前提条件。我们在本书从头至尾说明，必须弄清 SAP 项目同其它程度较低项目之间有哪些差别，最好在你项目开始时就这样做。自从七十年代初期第一批在线（或实时）应用程序的诞生，信息系统专业人员就开始不得不为协调在线系统，应用程序之间连接（或接口）和随着业务和公司发展而不断产生的系统维护需求之间的关系苦苦挣扎。在本世纪后二十五年里，业务人员很少会对信息系统的支持感到满意，这种支持一直被看成落后于真正的业务需求。近年来，尽管磁盘、内存、通讯和联网的成本都已下降到原来的几分之一，但是这样的落后现象依然存在于软件，尤其是应用软件的领域里。SAP 有两个特点能填补长期存在于业务发展的鸿沟。1.SAP 提供了完整的集成商业应用程序套件。2.SAP 是由业务人员，而不是由信息系统人员来建立和维护的。商业应用程序已不再局限于一对一的模式，将财务、销售、分销、物料管理、生产计划、工厂维护和其它所有应用程序完全、有效地集成于一体已成为可能。数据流和流程规则已不再由数据技术人员来决定和维护，业务人员不再坐在那辆出租车的后座，他们控制着方向盘。这是一场文化上的革命，而不只是业务上的革命。要充分享受 SAP 所带来的利益，你就得在你公司内部进行同样的革命。本书不是进行这场革命的蓝图，而只是为这场革命提供帮助的宣言。第二章 让星星成为你的向导 制定看得见，能衡量的成功标准 我在这里干什么？在 1992 年大选中，许多人瞧不起罗斯 symbol 160 f Wingdings s 14 佩罗的副总统竞选伙伴斯托克代尔将军，因为他曾在一次愚蠢的辩论中，向前跨出一步，伸出双手，问美国人，“我在这里干什么？”对于这位将军这个时候的举动，人们普遍认为这个可怜的家伙思路不清。但是我们却不这么认为，考虑到他曾经是哲学教授，而且作为战俘在河内希尔顿饭店待了许多年，他不可能思路不清。他头脑非常清晰，因为那时，他意识到这次辩论没有真正的方向或价值。他肯定已经意识到他正在同一位智力上的侏儒和一位好心的巨人持剑拼杀，这仅仅是为了讨得电视观众的欢心，而他本来打算是参加一个政治家们的对话，以教育持有投票权的公众。他的这个提问不应被理解为是他思路不清的证据，而应被理解为是智慧，一种时下非常短缺的智慧。“我在这里干什么？”是应该经常提出的“盘存性”问题中的一个。在 SAP 实施领域中，任何时候，对此都必须作出回答，而且应该是明确的回答。SAP 的实施应该有个理由，一个清楚可见、能够衡量、可以在全企业内交流的理由。因为公司将经历由业务流程重组、一定的人员削减和高层的争斗（都得付出高额代价）所带来的痛苦，那么在黄砖铺地的道路尽头必须要有一定的奖赏，一座充满利益的蓝宝石城，或者可能是对一艘正在下沉船只的成功挽救。没有人赞同的前景无法实现，充满迷雾的前景只能带来充满迷雾的结果。传统上，系统方面的项目总是为了业务目的而进行的：手工操作和流程由于工作量的增长而需要自动化；遗留下的系统已经过时；公司需要有管理方面的信息才能正确转向。传统上，业务部门必须毕恭毕敬地走向系统部门去要求、交涉，甚至乞求以获得信息系统支持。传统上，信息系统部门也取得了这样或那样的结果。但是令人惊讶和常常困窘的是，往往在“那套系统”到位后，促使实施那套系统的理由就发生了变化，或者完全丧失了。要使 SAP 实施真正地成功，就必须要有一个明确、清楚、明白易懂、能进行交流和衡量的理由。单 一、简单的理由不见得就是明确的。理由可以多种多样，就象丹尼斯 symbol 160 f Wingdings s 14 罗德曼头发的颜色一样，但它们不应当随着时间而变化。如果企业中的每个人都对 SAP 实施的理由有个清晰的概念，那么，1.对于项目的抵触就会大为减少。2.业务流程就会根据一种观点而不是几种观点进行。3.就不大可能对 SAP 作修改（ABAP式的）。4.雇员们就会希望实施成功 在我们组织的专题研讨会上，我们按惯例询问参加者为什么他们要考虑使用 SAP。得到的回答中很少有让人茅塞顿开的：因为母公司让我们这么做的。因为我们有 2000 年问题（Y2k），而我们的遗留系统反正总得要更换。因为母公司说我们一定得这样做。一个经常给出的回答是：我们不知道。我们通常提的另外一个问题是：你公司是否有一套战略计划？回答总是一样：“是的。”但我们总对此有些怀疑。战略计划的肥料（或者马粪）当 SAP 被选来帮助公司实现其战略计划，最好真有那么一套可依照的战略计划。下面是一些经常被引用的购买和实施新系统的理由：赶上二十世纪的潮流（更新的说法是，架设通往二十一世纪的桥梁）。使业务运作增效（synergize），（增效能量资源，使得 112）。降低库存。提高盈利度。改善客户服务（送货时间，产品质量，价格）。提高业务运作效益。降低信息系统的管理费。合并分散的业务单位（公司，部门等等）。大多数声称具有一套战略计划的公司往往列出类似上述内容的一张清单。这并不是战略计划，而是列有良好愿望的清单。取清单上任何一条，加上“怎样”和“为什么”，再假定实施周期为“何时”，这样你就进入了战略性领域。事实是，这通常与钱有关。当然这也可能与其它许多方面有关，但是别搞错了，主题是现金和它的流动。这是个关系到公司里每一个人的概念。但是，很少有战略计划可以具体实现预定的存款量或者现金创收量。我曾经观察到下列的交谈，这里几乎一字不漏地照原样记录下来。咨询顾问：我看到你把降低库存作为明年战略计划的第一条列了出 来。客户总裁：不错。我们打算降低 15的库存。咨询顾问：你们现有库存的价值多大？客户总裁：我不知道。咨询顾问：你们计划如何降低库存？客户总裁：我不知道。咨询顾问：要派谁去负责这项工作？客户总裁：我不知道。咨询顾问：为什么你们要降低库存水平？客户总裁：因为这看上去是个不错的做法。客户总裁并没有错，降低库存确实是“不错的做法”。他“战略计划”的其余部分也是大同小异，只是些改善业务运作的具体措施。类似这样对于“战略计划”的错误应用在商界比比皆是，而真正的战略思维非常缺乏。象这样模糊的思维应用到任何系统实施都将导致同样模糊的结果。如果我们还只是在谈论一套新的库存系统，还不会有太多麻烦。但如果应用到涉及整个企业的解决方案，这肯定会给企业带来灾难性后果。战争的迷惑 我们有过一个客户，它的主管们勇敢地选择了 SAP 作为引掣：1.向几家最近归属至同一旗帜下的公司提供增效的共用系统。2.不仅在总收入而且在多种经营方面，为公司进入新的业务范围提供跳板。其他系统解决方案明显地要便宜一些，但都需要进行大量的接口工作。客户管理层清楚地看到一旦咬了接口这个苹果以后，接口方面的麻烦也接踵而来，而且所有公司的遗留系统都将成为一个大问题。我们的系统比你们的好，是又不是，让我们碰头商量一下吧。噢，不，还是让我们开个专题研讨会吧。该公司随后决定选择 SAP，同意请来自六大会计事务所的实施伙伴，并起草了一个二年计划，分三个阶段进行实施，还确定了预算。第一年：1.指定一位没有 SAP 经验的内部项目经理。2.内部咨询顾问接受了少量的 SAP 培训。3.发现缺乏外来咨询顾问。4.计划滞后了半年。5.追加一倍预算。6.我们公司应邀检验新的预算和计划。我们发现预算实际上没有翻倍。预算总是应该比原先决定的多一倍。半年滞后于原计划不仅仅是因为糟糕的 AS-IS 阶段（参看本书其它地方有关 AS-IS 阶段性理论的启示），而且所谓新计划只是多给三年时间用于实施。这就是战争的迷惑。这家公司选择了 SAP，因为他们有各种各样很好的理由，并在会议室里详尽讨论过，但是他们一遇到 SAP 道路的老问题时，就将实施期限延长至下个世纪。（好！将预算翻倍不是个简单的老一套做法。下个世纪已即将来临，但是你明白了道理）。ROI，意思是“投资回报”，不是法语中的“国王”，这个概念由于下列的混乱突然被遗漏了：明白如何充分利用咨询顾问 不完整的 SAP 培训 不信任咨询顾问 独自承担培训任务 因此，实施周期长了许多。因此，在 2000 年以前没有真正的投资回报。在 2000 年以前就得相对多地依赖于他们的遗留系统（和可怕的接口化）而且代价昂贵。我们的建议是重新回到 ROI 的轨道上。这家公司与大多数其他公司不同之处在于它的主管们能清楚地向我们描述 SAP 能为他们做些什么。但可悲的是，他们没有向公司的其他员工交流这些看法，更糟的是，在与困难激烈的抗争过程中，丢失了他们原来的目标。这个小事例告诉我们这样一点：即使是在 SAP 实施开始之初公司具有所有正确、清晰、能够衡量的理由，也可能由于战争的迷惑，看不到可以衡量、可以得到的利益，进而沦落到尽管成本逐年递减，但实施周期越来越长的地步。他们做了些什么？他们只做了一半我们让他们做的：a)放弃独自承担培训任务的做法，寻找合适的SAP 咨询顾问以提供尤其在集成方面的推动力；b)寻求适当的培训，尽管这很少见。他们没有 c)加速实施以掌握和获取因此带来的利益，或者 d)与公司里的其他员工交流和传达项目前景方面的思想。看得见能衡量的 SAP 成功标准 我曾经做过一家法国轮胎制造公司的项目经理。（是的，就是那家具有“该是喝一杯的时候了”广告语的公司，他们的市场推销形象是一位笑嘻嘻、胖乎乎、有双突出大眼的家伙）。如果说，曾经有过一个项目具有看得见能衡量的 SAP 成功标准，那就是这个项目。轮胎是作为 OEM产品向日本汽车制造商提供的，每一家这样的制造商都当然遵循 JIT标准。客户的困难是基于以下这单一、简单的原因：所有轮胎，不管是在欧洲还是在美国生产的，都处于十一个星期为一个周期的供应链上，其中包括船运所需的时间，而供应商的数据（销售预测、供应链监控、订购等）则十分混乱。在轮胎业中，每售出一只用于安装的轮胎都会带来以后 2.2只供替换轮胎的销售。所以如果客户错过了一只轮胎的发货，他们不仅会在汽车制造商面前丢脸，而且会将其总共 3.2只轮胎的生意，拱手让给他们的竞争对手。后一点相对而言最不重要，因为汽车制造商的耐心长期以来已变得很差，整个汽车业都不太景气。针对这个问题，该公司将其 12的年收入交给法国航空公司，用于托运所需的货物。据说曾有一次，一架从巴黎飞往东京的波音 747 飞机只装运了十二只轮胎。本项目的任务是：大幅度降低法航的费用，同时继续在JIT的环境中向客户提供服务。这是一个看得见、能衡量的 SAP 成功标准最好的例子。这个项目不管怎样想象都不是轻而易举能完成的，但是我们项目组的优势是我们清楚地知道彩虹的那端是什么。所有设计方面的决策都因此紧紧围绕在如何向客户公司 提供降低法航费用并完成客户对货物要求的办法。在处理优先安排、方向或是战略方面问题时没有召开冗长的会议。在管理项目范围方面也以同样的方法作了简化。任何对项目附加工作的建议，如果不能直接达到设想中的目标，根本不会被采用。并不是所有的项目都提供如此简单的目标。但是不管怎样，在你项目开始之初找到你的目标，就能产生深远的影响和利益。要寻找的内容：通过减少人员或是将处理重组入工作流，减少工作强度 增加产量 更佳的效果可见性信息 最后一点，相比其他两点，经常是很难量化的。但无论如何，如果你想实施成功，你就应该为你的项目组和公司提供一个明确的目标，而不是什么模棱两可的说法。开展项目的理由还应该基于事实。越南战争的爆发是因为有了多米诺骨牌理论（也就是说，如果西贡沦陷了，共党们就会进攻夏威夷，然后进攻圣迭哥，最后，天啊，会进攻奥马哈。这样的理由经不起仔细推敲，因此就有人强烈反对这个战争项目，而最终，项目的经理们没有一个人能成功圆满地完成该项目。出于同样的原因，成功标准最好能具有一些诱惑力。如果在盟军大规模进攻开始日之前，艾森豪威尔将军告诉他的部队，进攻诺曼底海滩是为了在德维尔地方设立个电影节，那么进攻能否成功很值得怀疑。如果你找到内在明显的和可以量化的内容，你就可以赢得你的关键战役。最后的提示：SAP 不会直接给你带来利益。只有 SAP，而不是世上其它的应用程序套件，才能帮助你取得收获。但是，收获必须由你和你的公司来设计、规划。如果你期望仅仅靠实施 SAP 就能使你取得收益，那就大错特错了。附言：SAP，缓解老式信息服务预算战争刨伤的良药 为什么那么多的公司把信息服务成本当作总收入的一部分来衡量？这是什么意思？我们一直看到一些公司的统计数字，他们做了某些工作后，信息服务成本从占总收入的 2.5 下降到 2.2 或接近于这个数字，这也是一部分收益。没有什么特别的魔法可以告诉我们信息服务成本的降低会直接创造收益。但是信息服务本身作为一种开支能降低其他成本。公司内部再没有其他服务能具有同样的功能。营销带来收入，销售带来收入，信息服务在经营和人力两方面降低成本。暂时让我们设想一下，如果没有信息服务，没有计算机，没有公司内部的各种技术，公司还需要多少人手才能做现在做的事情。把这些全加起来看看。如果你是信息服务圈中之人，而且正与那些认为你是个财政负担而要削减你预算的人们闹得不可开交，看到这里你会有同感的。信息服务并不个财政负担，你可以告诉他们，而是一个机遇。他们根本看不到这点。因此，请用你的电子表格和 电子图示演示软件来向他们作解释，以证明信息服务项目的必要性。既然大多数公司的最高行政主管仍然习惯于将 SAP 看作是一项信息服务的成本，他们如何才能将信息服务成本的降低当作整个收益的一部分来衡量呢？很简单！SAP 是通过将重心从信息支持费用移到业务上的方法来合理地降低信息服务成本的。房租是管理费用，文具、旅差费、管道修理上的花费也是。而 SAP 能在推动工作流的同时降低企业成本。因此，在这上面花钱你会赢得胜利。第三章 SAP 实施，立竿见影 一套快速 SAP 获取、培训和实施方案 在流程设计前获得软件 如果你已决定使用 SAP，你可能希望跳过这一节，直接阅读实施指导部分。但如果你仍然在寻找合适的软件解决方案，SAP 就是你唯一的选择，请继续阅读下去。传统上，需要新的软件系统的公司遵循以下的简单步骤：1）设计新的业务流程，然后 2）找到最符合这些流程的软件包。习惯上，人们认为没有任何软件包能符合80%以上公司的要求，于是剩下的 20%你公司特有的难以捉摸的要求，必须要重新设计和独立开发。许多公司因为过于注重那20%部分，往往不能顺利地进行新软件的购买工作，他们没有注意到 80强有力的新解决方案将如何提高公司经营这更宽广的前景，而只是等待，或者试图找到一种全能的软件包。除了以上的犹豫不决外，设计过程（或者起草具体规格）也是传统上减慢系统购买和实施进程的因素。你熟悉这样的情景：你同系统人员挤在一起商量，并作记录，确定系统应该如何为你工作；然后你走出去，拜访销售商，看看市面上有没有软件包符合要求。发现找不到以后，你重新考虑你们的规格要求，确定一位销售商；与此同时购买新的软件，开发 20的欠缺部分，然后为遗留的旧系统以及你自己开发的20部分编写接口程序，以满足规格要求。理论上说，你现在将获得 100满意的系统，符合早先确定的需求。但事实是，你将得到的可能是90符合要求的系统，因为 1）业务要求经常发生变化，2）你的数据库是通过接口相连的，而不是集成的。归纳而言，对于销售商提供的更为复杂的设计，许多用户的规格编写和设计是多余的，而且很大程度上是在浪费时间。以往，这样的情景很难有办法避免，但有了集成的软件套件和客户机/服务器技术，获取和提供数据已不再是一个问题。有了 SAP，应用程序本身就是灵活和综合的。关键的一点是，你现在应当重新考虑传统的软件包购买方式。不要再去寻求一种软件包能支持你的设计，而应该去寻找一种能提供平台的软件套件，在此平台上你能重新调整你的公司。在这个练习中，这个软件套件就是 SAP。实施的步骤是什么？如果你接触 SAP 环境已有足够长的时间，你无疑会听到一些不断被重复的言语。“集成是 SAP 的关键。”“业务重组是 SAP 的关键。”“SAP 比它看上去要简单，只有设置是复杂的。”另一句象圣言般在 SAP实施过程中不断被重复的话是：SAP R/3 实施不是一个计算机项目，而是一个业务项目。把这句话剪下来，贴在你的便携机屏幕上。不断有人重复说这句话是因为众所周知的普通软件项目的步骤并不适用于 SAP 实施。新系统设计、开发的整套方式，或者最优秀软件的安装将包括对于 SAP 项目毫无重要性可言的阶段和任务。这句话正确的主要原因是 SAP 实施的重点是业务流程的重组，而不是对支持这些流程的系统设计。再进一步的说法是：SAP R/3 实施不是一个部门计算机项目，而是涉及全企业的业务项目。如果项目人员坚持以他们过去的方式行事，以往的信息系统项目经验不但没有帮助，而且更加有害。下面简要概括了你将遇到的不同之处。传统软件项目 SAP 项目 满足单个部门、组室的需求 针对整个公司 促使循序渐进的变革 强制进行根本性的变革 软件开发是主要活动（以信息系统为主）业务重组是主要活动（以业务为主）一步一步、线性的项目方式 反复和交互式的项目方式 信息系统人员与用户商议设计方案 用户确定用途 在仔细阅读咨询公司的手册时，你一定会看到各种各样描述实施步骤的图表，有些墙报式的方框和箭头列出了跨越三年的详细任务。有些方式比业务重组更强调SAP 的众多功能（或相反），而有些则着重于优化完善公司的流程。在 SAP 咨询领域里，有众多“方式”使用了表示实施速度的形容词：快速、快捷、迅速、即刻。好象安装一套具有革命性、突破性的完整应用程序套件可以同烘烤奶酪汉堡包并将其装袋一样快速。本章节的标题本来就是为了挖苦人的。没有所谓的 SAP 实施立竿见影，不管使用何种方式，实施需要时间。除了实施任务外，你的员工适应新的业务环境也需要时间。这样的适应不可能在几周内完成，因此，对于那些只能加快工作而不能完成工作的实施方式要冷眼看待。最重要的是：没有一种在 SAP 实施中必须采纳的唯一的方式。如果有人对你这样说，那他就是这样一种人：告诉你世界上只有一种汽车值得拥有，只有一种啤酒值得饮用，只有一个女人值得去爱。不管怎样，几乎所有 SAP 实施都包括以下的组成因素或措施。措施 决定 关键事件 SAP 进场；是深渊还是高潮 1.设想未来 什么会改变？2.制定实施计划 循序渐进式实施或是一次性完全实施？3.组成实施小组 谁来做？做什么？4.实施 SAP 要预先设置些什么？5.定义 SAP 结构 信息架构？6.重新设计业务流程 你如何来做？7.设置 SAP SAP 如何为你工作？8.培训用户 谁是用户？9.系统迁移 如何进行转换？10.使用系统 关注利益实现 大多数步骤以一种线性的方式进行，但其中有一些互相重叠；第六、第七步内有很重要的循环。培训将自始至终贯穿于项目进行的全部阶段。关键事件 公司总裁或其他真正掌握大权的人物，具有这样的远见，即 SAP 将是一种降低成本提高效益，具有升级、启示和发展作用的软件平台，能带你的公司走向下一世纪。一语既出，众人欢呼。设想未来 这是 SAP 项目中的第一步，也是最奇特的一步。在商业环境中不允许有“梦想”，但仅仅回答“我们在这方面就是这样干的”已远远不够了。现在请你想象一个以最佳方式工作着的公司。这是个为进行业务流程重组定基调的阶段，你应该认真进行，就好象你要将公司推倒重建一样。这不是个小修小补的阶段，也不是进行作简单微调的时候。你应该从一种崭新的角度来审视公司，着重注意以下问题：为什么你的公司在做它正在做的事？你的战略目标是什么？为什么考虑实施 SAP？什么样的变化将可能产生最具戏剧性的利益？阻碍这些变化的关键在那里？如何才能消除这些障碍？这样的问题应该在金字塔般结构的企业内，由上至下在各个层次，各个部门，各个处室提出，也应对现有的公司结构提出疑问，这样业务流程重组就能在破墙式的斜向面上进行。即将支持你新的业务流程的 SAP 软件是一种斜向的应用程序，这意味着它将支持整个跨越部门界限和公司结构的业务流程。让我们重新回到“破墙式的斜向面”这个词语。它听上去很顺耳，在项目计划书上看上去也很顺眼，但是事实上，一个破墙式的斜向面正是大多数人将抵制的内容，因为它不仅会影响他们以后工作的方式，而且也可能会使他们丢掉饭碗或者进入完全不同的工作岗位。SAP 在任何情况下都不要求进行这样的结构重新调整，但认真地进行业务流程重组以使公司和 SAP 有机会在一起创造奇迹，就有可能带来这样明显的结果。在认真努力下，决策权力将会被重新分配，正是在这个地方，你会发现遇到最强有力的抵抗。有些员工会因为失去权力而心存不满，而有些则会对新赋予的职责惟避不及。文化上的变动将是令人惊奇的，至少在一开始，会让人措手不及。没有必要为一套完美的业务流程找一个完美的计划。在项目的这个阶段，你应该大刀阔斧地工作，而将涉及具体流程重新设计的细枝末节留到以后。如果你在这个关口就精耕细作的话，那末项目就会陷入困境而停顿下来。制定实施计划 在确定项目的范围时你将是在为大量的实施问题提供答案打基础，而这些问题必须在计划中予以解决。范围的要素包括：考虑到了多少个地点、公司实体和用户？哪些遗留系统将被保留？是暂时的，还是永久的？要求有什么样的接口？那捉摸不定的 20部分有多重要？是否必须在实施的第一阶段就予以处理？（对于这个问题的回答通常是个坚定的“不”字，但针对这些问题会有许多会议召开，多得大部分项目经理难以承受。）使用 SAP能得到的最大利益是什么？只要能实现这些利益，不管是什么，都应该被置于项目范围的中心。实施计划草案将涉及一个重要的决定，其结果的重要性再怎么强调也不过分：你将如何实施？是一 步一步地干（经常有人称之为循序渐进式的实施）还是所有的内容一起上，也就是一次性完全实施。要是对此的答案能象这些词语说起来那么简单就好了。循序渐进式实施 一次性完全实施 有些功能都很快地实施好 只有当所有业务单位都准备好后才能实施 在系统启用之初能使用的功能范围较窄 在系统启用之初，能使用的功能范围很宽 有些集成工作被延误 集成工作随即完成 需要编写临时接口程序 不需要接口 中等风险 中等至高等风险 在循序渐进式实施中，每次只实施一到两项单个的功能或流程，直到所有的功能都完全实施好。有些循序渐进式实施是基于地理位置进行的（一个地点接一个地点），有些是基于领域的（先进行财务，然后是销售和分销，再是物料管理，等等），而有些是根据需要程度进行的。譬如有时候某些业务部门实施准备工作比其它部门做得早。在“一次性完全实施”式的实施中，所有的功能和处理同时启动实施。不管你选择了哪一种情形，实施计划中必须包括能达到的里程碑（或者限期，如果我们必须用这个词的话）和能每天衡量的项目流程。为了精简，我们不准备详细列出这些具体任务，因为不管怎么说它们是显而易见的。公司的规模，用户的人数，实施的种类，要实施的应用程序的数量和种类，这些都会使具体的时间段和项目周期发生变化。组队 设想成熟以后，你就要组成一支实施队伍来实现你的设想。对于传统的系统项目，这样的队伍将包括一位项目经理，一些系统分析员，用户代表和一些既懂分析又会编程的技术人员。简单地说，信息系统人员太多。对于一个 SAP 项目，组成人员完全不同：将你公司的业务人员同外来的更倾向于业务而不是信息系统的咨询顾问组织起来。在传统系统中，实施小组象棒球队，先由业务人员挥棒击球，然后是分析员，再是编程人员，再是测试分析员，再又是业务人员进行接受性测试。SAP 的实施小组则更象是支足球队，每个人必须与其他人协同工作。外来咨询顾问和内部实施人员的关系有点儿象网球双打，每个成员尽力发挥自己的强处，而由队友来弥补弱点。请考虑以下的员工构成表：在这个安排下，你的员工将由业务流程经理组成，每个业务流程经理将负责一个具体的应用程序（或者一套应用程序）。他们将掌握功能性方面的内容，了解那个模块的集成点。在较小的公司里，可能可以让一个人负责一整套应用程序，比如从销售分销（SD）到物料管理（MM）。在项目开始之初，每个业务流程经理将有一位专职或兼职的“影子”咨询顾问，取决于范围要求。这些咨询顾问应该具有丰富的 SAP 经验和知识，而业务流程经理们则应该在一开始就鼓励知识转移。注意这些流程经理不应该是信息系统人员，而应是来自与这些应用相关部门的业务人员。他们应该善于交流，头脑清醒，能轻易取得别人的一致看法，喜欢变革，热情高涨；他们还应该拥有高级便携式电脑及所有配件，漂亮的衣服，飞快的汽车和极好的耐心。除此之外，他们必须要有权力。他们必须要有权进行新的业务流程，采用新的做法，有权作出决定，让公司使用 SAP 来实现他们的业务流程。如果他们只 被看作是“协调人员”，几乎得不到高级管理层的支持，这个练习就等同于_（在此填上你公司的名称）大学，在这所大学里，你公司成了许多学期论文的主题，但得不到实质性的改善。对于这些人员，另有一点必须搞清：他们必须要有时间投身于该项目。业务流程经理应是专职，而相关的员工也应该至少花上一半时间在项目上，否则该项目肯定要偏离目标。信息系统方面的功能必须有专职负责 SAP项目的信息系统负责人协调。这位负责人不应当同时在SAP 项目和现有系统上花时间。项目中信息系统的活动可能包括用 ABAP/4 语言作一些定制式编程，以填补功能性方面的缺陷。有了影子咨询，你的信息系统人员应该在 BASIS 和 ABAP/4 编程方面得到充分培训。在项目进行过程中的某一时刻，你应该能够降低咨询时间和在场时间的比率。记住你们的目标是利用咨询顾问，使他们在开始时提供知识和经验，并让那种知识和经验向你公司转移。这个时候，应该为项目的余下阶段制定一个基本实施计划。在下个阶段（实施 SAP）以后，实施计划就能有血有肉，具体到任务一级。在购买和实施 SAP 以前，尝试制定极其详细的主计划并不可取，除非你的实施小组对即将实施的预先设置好的软件也很熟悉。在这个时候，也应该开始培训工作。这个计划不完全呈线性，所以你可能会为获得某些指导，而短暂地向前跳到培训部分。尽快实施 SAP 这话听上去比看上去要容易些，因为 SAP 的实施过程可能是无休无止的。SAP 只提供很少的实施支持，而依赖于它的第三方伙伴（也就是平台和/或咨询公司）提供需要的帮助。这就是为什么你自己的实施小组应该已经到位的原因。为了使不可避免的设置过程更为简短、更加合理，你应该作好准备实施一个预先设置好的“香草”系统。所谓“香草”，我们是指系统已按普通的标准设置完毕，这样大多数一般常用的标准流程已经到位。所谓“预先设置好的”，我们是指要实施的基本设置将适合于你们工作的产业领域。要寻找一个预先设置好的系统，可以联系 SAP或者你地区的工业技术中心（ICOE）（对此后有详细介绍）。如果不行，找一、二家与你公司相似，而已使用 SAP 的公司，看看你是否可以安排些什么。如果可能的话，尽量不要实施一套基本的、原厂包装的 SAP，许多以后的设置工作会因此非常复杂和费时，这毫无必要。还是把时间花在寻找一套别人为此冥思苦想过的设置方案，由此继续下去为好。在搜寻已完成的设置方案上的花时间是会有回报的，在以后的实施过程中，你会省下大量的时间。定义 SAP 的结构 这可能是整个 SAP 实施过程中最为痛苦的一部分，因为这触及到你公司如何运作的中心。在具有高度垂直结构（即统管生产和销售全部过程）的公司里，各个部门拥有极大的工作自主权，这种公司会发现SAP 正在“逼迫”他们更加趋向于水平式的结构。一直以独立王国运作的部门很难融入 SAP 集成式计划。悬而未决的问题是即将建立的报告、成本核算和控制的结构。有些公司通过在不同的业务实体中运行多个 SAP 系统以回避这个问题。这些公司为集成式的系统投入了巨大的资金，然后又决定跳过系统集成。因此我们可以认定这不是值得推荐的做法。比较开窍的公司则努力调整组织结构，在报告和数据共享的概念上充分利用现在的垂直运作方式。从底层上说，SAP 追求在整个范围内建立财务控制系统，将范围内的每个业务单位（处，科，室）看成一个成本核算和盈利中心。引人注目的一点是，不管有多少已建立的独立王国，或者有多少实施好的展示服务器，数据库只有一个。注：这样的单个数据库现象可能会在 3.1版本中得到解决，SAP 将分割成物、财、人三个组成部分。这些组成部分将以独立的应用程序套件运作或者通过传统的单个数据库互相连接。只有当组织结构牢固地建立起来并得到大家的同意以后，实施项目才会成功地继续。因此，管理层是个关键。如果上层人物不参与组织结构的建立，阻力将永远存在。许多 SAP 实施项目就在这些顽石前停滞不前。有些公司喜欢在项目范围完全确定以及新的业务流程定位以后，建立一个运作模型或原型。一个合适模型的存在能带来巨大的好处，包括：会产生结果或平行差距分析，你就能发现 SAP 所不能满足的功能或特性。通过提供一个所使用系统的等比例模型（以及定义了的业务流程），向那些反对实施项目的人们“证明”实施的必要性。会产生第一个你公司将来工作量的详细面貌，项目计划可以因此得到调整。“玩沙箱”是个有时被使用的词语，而且形象很贴切。你正在做的就是在建造一座沙丘城堡。如果你不喜欢，只要推倒它再来就行了。在整个反复进行的重组阶段，原型可以随时更改，直到共同认可一种“完美无缺”的模型为止。在继续下去到业务流程重组部分以前，我们觉得有必要就差距分析坚定地说几句话。如果咨询顾问或者用户对于 R/3