|
|
掌握旋风：SAP成功实施实地指南_水上漂的专栏-CSDN博客
掌握旋风SAP成功实施实地指南
序
在北美地区的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增效能量资源使得11>2。
· 降低库存。
· 提高盈利度。
· 改善客户服务送货时间产品质量价格。
· 提高业务运作效益。
· 降低信息系统的管理费。
· 合并分散的业务单位公司部门等等。
大多数声称具有一套战略计划的公司往往列出类似上述内容的一张清单。这并不是战略计划而是列有良好愿望的清单。取清单上任何一条加上“怎样”和“为什么”再假定实施周期为“何时”这样你就进入了战略性领域。
事实是这通常与钱有关。当然这也可能与其它许多方面有关但是别搞错了主题是现金和它的流动。这是个关系到公司里每一个人的概念。但是很少有战略计划可以具体实现预定的存款量或者现金创收量。我曾经观察到下列的交谈这里几乎一字不漏地照原样记录下来。
咨询顾问
我看到你把降低库存作为明年战略计划的第一条列了出 来。
客户总裁不错。我们打算降低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能为他们做什么或不能做什么匆忙作出定论就会造成巨大的资金和时间上的浪费。简单的习惯性行为方式是计划进行附加功能编程或者更糟的是购买其他软件以用于修补完成 R/3表面看来不能满足的功能。
错误之处在于在项目的这个阶段你的员工显然还不太了解 R/3以致于提出这样的要求而且你的咨询顾问可能也是如此糟糕。因此差距分析还得慢慢来。如果你急于处理每一个找到的差距尤其是使用“加入的”新软件你将会首先损失你花钱买来的主要功能也就是集成性。在项目进行的后期随着你 R/3知识的不断加深和拓宽你会发现许多原来找到的差距问题干脆消失了。当然也会有 R/3不能提供的功能和特性。但你也必须问问自己这些功能的价值是否比在时间、金钱上的花费以及 R/3集成性的丧失更为重要。下面还将进一步谈到这个问题。
重组业务流程
你需要知道的有关业务流程重组内容无法用几句话说清这是个好几册书才能恰当说明的主题。我们明确地建议任何考虑购买和实施SAP的人都应该熟知业务流程重组的准则和做法。为达到这一目的我们提供了一些基本要点。
1. 业务流程重组不是对现有的业务流程进行修饰和优化而是在最底层上重新建立业务流程其目的为了在客户服务和/或经济状况方面根本性改善公司现状。
2. 一个业务流程不是一个狐立的行为如一次任务一次输入或一次输出而是以为用户带来附加值的输出或结果告终的一系列活动。一个流程的例子是以收到来自用户的定单开始然后用户收到所定货物最后以收到货款结束。
3. 要保证给予业务流程经理们充分的职责完成每个单独的业务流程。是他们必须向阻碍实施的人灌输新的想法并确保重组工作顺利完成。这些人在公司里应顺理成章地具有足够的影响力和可信度。如果没有这些能力即使最优秀的新流程方案可能也不会顺利地得到贯彻。
你一开始假设通常是正确的SAP能提供支持你所设想的新组织结构必要的集成功能和系统表现因此这个时候你就要详细描绘你公司将转变成的绝佳的业务新世界。
描绘可以有许多形式但SAP实施中最有用的描绘是可视性描绘譬如使用过程图和数据流图。SAP R/3包含了一套称作为“分析者”Analyzer的工具。尽管用户在使用这套工具可行性方面意见不一但是对于有人在使用上犹豫不决人们还是疑惑不解的。人们对这套工具多少有些误解在下一节中将讨论 R/3“参考模型”。在项目的这个阶段可以使用“分析者”将现存的业务流程绘成图表以便于设计出新的、更理想的业务流程。
“分析者”和“参考模型”合在一起同其它一些次小组成部分现在被称作为“业务设计工作台”。我们不想就你将选择的工具发表这样那样的评论。ARIS, Visio等供应商也提供具有类似功能的软件。我们听到了有关这些软件中每一个优点的激烈辩论对此我们只能耸耸肩不予理睬。一个男人的锤子是另一个女人的垒球棒──各人用途不一。我们还是让你自己选择。
对于一家心情迫切的公司来说将现有的业务流程绘成图表可能只是在浪费大量时间。实际上你可能要花上几周甚至几个月来整理你打算推翻的业务结构。所以最好还是继续下去开始为将来建立模型。
然而一家竭力想创建崭新的业务流程的公司可能会发现用“分析者”将现有业务流程绘成图表很有指导意义。一些多余的活动和无意义的处理将在图表上变得一目了然而且图表本身也将迅速记录下讨论内容。
不管你选择哪条道路现在的关键是你的业务流程将得到改善而不是仅仅有变化。要避免使用一些抽象、嘈杂的词语诸如“强化”、“增效”、“团队”等等集中精力于起因和结果。每个新的业务流程应该有一个确定了的触发因素客户要求定购和一个确定了的结果或者一系列结果定单输入系统开出定购确认书根据要求发货。一个特定的结果会转而成为另一个流程的触发因素。
你正在寻找的是工作流是通过消除不必要的人为干预或者系统缺陷对于业务流程的加速。你也正在寻找用户和供应商之间的自动挂接想想电子数据交换想想因特网。
失败会出现但不能因此放弃一切。每一次重大变化都伴有风险应该根据期望中的利益来衡量这些风险。
BPR业务流程重组和 R/3设置正好处于 R/3实施至关重要的道路上这两项活动紧密相连不断重复。重复、再重复、再重复.…..噢真报歉
R/3
生产控制
在这个阶段许多在范围中呈线性的方法处于困境。R/3实施中充满着一系列必须爆裂的泡泡和花边似的曲线而不是直线。逻辑上设置紧随BPR在许多情况下设置上的失败导致新的BPR或者导致可能必须要用ABAP/4附加程序来解决的差距分析中的新内容。有些公司将设置工作留给咨询顾问而加快进行BPR以加速实施过程这是不妥当的。你的员工应该在设置过程中一马当先这样一旦咨询顾问离开后你就会发现你自已稳稳坐在方向盘前了。
我们的朋友和同事吉姆symbol 160 /f Wingdings /s 14 }欧基夫将 R/3比作一套安装器他的理论是你拥有你想建造任何东西的所有零部件只要你不弄坏这些零部件即修改原代码你就可以用同样的零部件以后重新建造。设置过程就因此等同于选择你的零部件然后决定如何将它们拼搭在一起。R/3实施正是这样将零部件合理地拼装起来。BPR只提供了一部分你所需要的。熟悉 SAP R/3则是另一关键。
设置SAP
R/3发布以来的这些年人们普遍认为有时这是痛苦的事实SAP实施耗时颇长人们在采访时尤其抱怨两方面重组这是他们的地盘和设置这是SAP的地盘。设置是根据你的要求调整功能的过程屏幕的式样和遮掩、数据流、流程规则等等。
事实上有成千上万种设置选择根据你的业务流程正确选择系统设置非常令人头疼而且费时。这正是SAP这把利剑的另一刃口。系统内置了众多的功能极具灵活性非凡人可以掌握。
到这一步你有了“预先设置好的香草”版本和一张根据你新的业务流程设计制定的新的详细设置图。你并不一定要等到详细设置完才开始实施。在这里有太多的实施开始走下坡路在这里设计──设置──设计──设置的旋风将SAP项目转变成由实施者用户和系统本身三方参加的泥塘摔角比赛。
BPR和设置的产品用八十年代的新词来说是“可供的货”是原型。一个SAP原型就是一个概念的证明这个概念是任何有时间看看的人都能看得见的。有了这样一个原型你就可以“走过”所有的流程去测试它们你可以在它们的基础上继续开发直到全公司的人们都学会用同一基调歌唱。
我们真诚地建议你们寻找一个断点在这个断点单个和详细的要求将搁置一边系统迁转将允许开始。一旦SAP处于运行之中设置过程可以继续下去。
针对这一令人气馁的问题SAP提供了许多不同的解决方法和工具
R/3参考模型
使用这件工具你可以创造和修改系统内的组成部分和各种业务流程也称作为“事件驱动处理链”或EPCs。这极大地消除了混乱因为EPCs是用简单明了的事件顾客电话订购和功能输入订购单流程图描绘出来的而且设置过程不仅仅由一系列代码和开关构成。
一旦参考模型令人满意你就可以使用 R/3程序模型这个模型描述了所有实施中涉及的任务包括项目阶段和工作步骤间的依赖性、标准设置和推荐设置。参考模型将与程序模型相伴工作在两者之间集成了文档、在线帮助、培训材料、数据模型和处理模型。
总体而言以参考模型在五个层次上对系统进行了描绘除了过程概述外还有
· 信息流描绘了信息发送者和接收者之间的关系和属性。
· 数据模型展示了对于公司活动在处理流程中有描述至关重要的数据实体。尽管可以看到不同的数据层但业务定义只要求第一层的详细情况。
· 功能概述将展示公司已确定的组织结构的概况或图表。这种概述是静态的只有当组织结构的定义发生变化才会改变。
· 组织勾画出某些组织的关系。
R/3预先确定的设置
由于存在着大量的 R/3实施项目正在进行中的R/3设置数量成倍增长。SAP这些年来已收集了许多不同设置套路欢迎用户从中选择并根据需要直接运用。
如果你使用SAP定制工具或者预先确定的设置方案你可以极大地减少实施时间使你公司尽快运行SAP。尽管不断有人抱怨实施费时但仍有几十家公司只用几个月时间就完整或部分地实施了SAP成功的原因因人而异但其中始终不变的一个原因是管理层具有坚强决心在设置过程中以符合确定的业务流程为目标不在办公政策、权力之争等方面纠缠不清。那些花了大量时间也完不成SAP实施的公司在许多情况下应该停止在设置处于僵局时争论不休而应该集中精力于之前的业务流程问题。
教育你的员工
在整个SAP实施过程中教育一直是一个令人关注的问题。它是SAP项目中比较棘手的问题之一。指导人员能力不一进行适当的培训在合适的时间为合适的人员选择合适的课程不是项简单的任务。
需要进行三个层次上的教育
1.管理层教育
2.实施小组教育
3.用户培训
在本书后面我们将以一整章的篇幅介绍SAP教育这里不再提供有关细节。只要说任何时候任何公司层次都要求开展教育就够了。教育不只限于教会用户按哪些键就能达到预期效果。
对于实施小组可通过全国的SAP办事处来安排SAP产品培训。这种培训可以集中在某些具体的功能上销售和分销生产计划等等。不幸的是通常提供这种培训的人员是职业的培训员并不具备实际的SAP使用经验。
工业技术中心成立于1995年在SAP与各个行业的用户之间联络工作。它们被简称为ICOEs用首字母作简称是SAP的特点。这些中心为寻找设置套路提供帮助也提供适合公司具体要求的工作模型。它们分为以下部分
汽车制造业
消费包装类商品
保健
金融服务业
石油和天然气
公用事业/交通
操作速成课开始于1994年5月。该课程包括一次面向所有实施人员的概况课然后是一系列针对特别兴趣领域SDFI 等等的特别课程。SAP从1997年春季开始提供有关ASAP方法的新课程。这些课程定期开设于亚特兰大、芝加哥、福斯特城、费城和多伦多新加入的地点包括波士顿、达拉斯、加尔加利、蒙特利尔、克利夫兰、辛辛那提、圣路易斯、明尼阿波利斯和加州的欧文市肯定还会加入更多的地点。你可以向你的SAP代表询问最靠近你处的地点除此之外还需要进一步开展在不同层次上面向不同人员的教育工作。
项目经理们应掌握系统架构尤其是当其附属于公司的组织结构、工具ARIS导航者等用于定制和重组的工具和设置方面的种种复杂详情。
流程经理们应在SAP中心寻求在针对他们即将负责领域的培训。
公司管理层尽管没有计划全职参与项目实施也应接受大量的SAP概况知识和有关培训。应将高级管理人员看成是业务流程的“拥有者”。有关重组的最终决定是由他们作出的因此他们有必要在组织层次上熟悉SAP。
在项目的后期将出现用户培训。用户培训指的是对那些将每天接触系统的人员进行培训。为了消除对SAP和/或昂贵的咨询顾问的依赖你应该考虑为初步培训建立一个三代计划咨询顾问教会你的经理一个功能该经理教授用户其中一位用户将被指定充当长期的内部培训咨询顾问。这个计划可以有其他变异体包括是否考虑在设置组中包含超级用户。任何一种方法都可行抛个硬币决定吧。
在整个系统的使用周期中总能找到在线帮助和在线文档。但是这些特性并不总是如你所愿的那样有用没有什么可以替代一对一指导。
重要的是你自己的员工应该尽量快速和全面地掌握这些功能这样在以后的系统使用中你就不会依赖于咨询顾问。再次重复
知识转移是这里的关键这就是为什么总用黑体字的缘故。
总而言之培训选择包括
· 专门SAP培训公司参看本书最后几页的内容
· 工业技术中心
· 通过SAP美国公司的SAP培训常年开设单科培训
· 利用咨询顾问的培训如果能找到真正合格的咨询顾问
· 将员工送往已使用SAP的公司进行培训
· 集中使用在线文档和在线帮助
系统迁移
不管你选择哪些实施道路“循序渐进式实施”还是“一次性完全实施”每个业务模块现在要从遗留系统向SAP迁移了。迁移的顺序取决于公司的需要和战略但如果集成是追求的结果系统的逻辑部分应该同时迁移。例如所有与完成定购相关的应用程序SD可能还有 MM甚至可能 PP可能需要同时迁移。人力资源HR部分可能最好是最先实施以利于以后的工作流。
我们是否已说清楚我们把编制接口看成是祸害应该尽可能避免如果是“循序渐进式实施”接口无法避免因为确实需要SAP和遗留系统间的连接。随着最后实施的临近公司中有些部门的准备工作比其他部门做的更好停留在接口当然是暂时的的诱惑是强烈的。应该避免这种诱惑。为SAP编接口程序复杂而又费时你就此做得越多你最后实施的时间将延误得越长。
可能在一段时间内手工进行业务处理要比刻意地进行编制接口子项目要好。但是不想把遗留系统扔到垃圾堆就还得为它编制接口。生活中没有完美的事继续下去吧
知道实施完成并宣布大功告成
如果你按照正确制定的实施计划行事知道何时项目完成是相对容易的。SAP R/3将在你大多数的部门中运行产品源源不断地输出公司可能已开始获取预期的收益。在达到关键的总量后你应该准备启用百分之八十的规则。你的业务正在运作另外的百分之二十将成为每天经常需要调整的目标。因此如果知识转移是成功的你就可以解雇外来咨询顾问走上正常的业务道路。
我们不想在这个时候或项目中的任何时候强行支配你的行为但在这个时候请让所有人知道你已大功告成。这不是个普通日子应该好好地庆祝一番。很显然还有许多有待解决的问题有些流程需要重新考虑有些软件需要加以修改但这是常有的事。实施好并运行SAP不等于让所有人都提前退休除了那些咨询顾问以外。如果你还没有感谢他们那么为他们干杯然后有礼貌地请他们离开。
那些被指派专职参与SAP项目的内部人员现在可以驶向黄昏回到他们原来的生活中去。但有些人会喜欢在某个职位上继续用SAP工作而另外一些人如果他们的努力和新近获得的SAP技能没有得到赏识的话则会离开公司被吸引去干咨询工作。
实施以后的策略根据实施成功的程度会不尽相同。现在是回到原来的打算和设想衡量你有多成功的时候了。现在也是产生新的设想回到系统生命周期开始处的时候但这次是SAP系统不同于其他系统。
系统生命周期的新设想
信息系统的生命周期传统上被看成是循环的
· 感觉到需求
· 计划
· 购买/开发
· 实施和使用
· 降级不断感觉到需求
一旦SAP实施好后系统就不再遵循这个模式。可能一直需要附加模块和升级以及对付那难于捉摸的百分之二十。但是为了你业务的核心在那里有个大核心你不应该觉得有必要重新设计或更换软件。随着需求的产生和系统表现不尽如人意你公司会发现重组业务流程并在SAP设置中反映出变化是有所帮助的。
第四章渡过河流穿越树林空中俯视
计划你的SAP实施
为什么为SAP制定计划如此不同
如果你把制定计划看作是把从承诺到实现的过程画出路线图那么你认为已经看见过即将要攀登的山峰和要徒涉的溪流而且这些已由形容枯槁、目光锐利、具有扎实制作流程图能力的人们画成图表。在购买、开发和实施传统系统时情况大多数就是这样。有几十套开发方法可以供人忠实地参照这些方法有一些把握可以将你从暗礁险滩带向胜利彼岸。如果你谈论的是一个单一应用程序你可以根据你能得到的光彩夺目的咨询手册从方法 1到高峰D再到手册中吹嘘的任何方法一直向前沿着虚线标注的线路走。你就来到熟识的领地在这里甚至连小路上的蚯蚓都标注得清清楚楚。
但是SAP到来了你不妨将那些地图/方法都带上用它们作引火物点燃温暖的篝火。SAP之风寒冷刺骨那些蚯蚓现在变成了毒蛇原先的小溪变成了奔腾的河流因此原先那些方法根本帮不了你的忙。你现在正以全企业的规模工作着你需要的是崭新的作图法。
成套方法大多显线性状能使你一步一步地从A走到Z。但是SAP实施上上充满着重复、循环的狭口这些需要一开始从空中而不是从地面上观察清楚。
请注意以下SAP实施中重要的因素
1. 学习曲线效应
大多数公司在开始SAP实施时缺乏足够的相关知识。实际上许多公司失败一次后回过头来获取进一步的教育然后重新开始。在全部有助于成功实施的因素中SAP教育排名第二第一则是反复提及的管理层投入程度。
2. 引入业务人员
在传统的非SAP成套方法中业务人员扮演着客户的角色他们提出需要的内容然后批准或者拒绝信息系统所能带来的任何东西。
在SAP项目中信息系统人员主要是靠边站而业务人员则掌握方向盘。估计一组程序员为新财会系统编写代码所需的时间是一回事估计一群业务人员通常他们还忙于本身业务设置顾客定购处理工作流所需的时间则是另外一回事。对于绝大多数的企业来说这完全是一块崭新的领地我们必须找到一套能解决这个问题的方法。
3. 实施的持续时间
实施一套崭新的财会系统即使在最困难的环境中可能只需要六个月其中两个月用于使公司里的统计专家们相信他们能得到所有的报告和单据将与他们钟爱的大型机以往一直能提供的完全一样。
在某些加工企业中实施一套崭新的生产系统可能要花上一年或更多的时间这取决于该项目具体的抱负目标。
实施SAP...... 不请等一下。我们不是
实施SAP而是订购SAP。我们接纳它就象教士们穿长袍那样费时。在一些企业里这样的接纳可能要花一年以上或更长的时间。写这本书时通用汽车公司正在仔细考虑他们的决定。如果答案是“前进”我们可以想象一个正在酝酿中长达十年的项目。
SAP实施确实费时但这有很好的理由。在实施过程中对于企业整个生命周期进行了详细审视、讨论、测试、尝试或者消化了或者吐了出来。新闻界有无数有关如何缩短SAP实施周期的文章这章讨论的也是这个主题但事实是你不只是打破几个鸡蛋做张蛋饼而是正在打破一箱或几箱鸡蛋去堆一座蛋饼做的小山。总会有些旁观的母鸡们对你打鸡蛋的方法咯咯地说三道四。
为建立一个新的零配件储存系统计划一个为期三个月的项目是一回事而为将至少改变你公司五年进程计划一个为期一年半的项目则截然不同。
4. 不断重复的从BPR到设置从设置到BPR直到原型站得住脚的过程
许多业务流程不管有多复杂都能在R/3设置中得到适当的处理。这是SAP魅力之一也是优势之一。但是另外一些你可能需要的流程其设置会变得象破解中国式迷语那样困难你不止一次地被领回到BPR画板面前。你将无法简单地设计你的流程只能设置SAP以满足它们的要求然后继续向前。这样会产生一个循环从设置回到BPR再回设置直至原型系统令人满意。你如何定义“令人满意”以及你要多久才能达到目的将对你的主计划及你的神经系统带来重大的影响。
5. 利害关系
前面已经说过风险是全企业的即涉及整个公司。每个人都受到影响很难找到问题的关键。
如果你成功了利润将滚滚而来。如果你的成功来自大规模拼斗之后那些利益的到来将大为延缓而且许多职业生涯将受到伤害。
6. 团队合作要求
你可能会计划项目组要从事的工作但是你将如何计划每一个人要做的事你可能有结构紧凑的 FI-COSDMM和 PP工作组但是所有这些小组都必须象SAP一样地集成起来。不能允许一个小组太多地领先于其它小组不管他们技术有多好进取心有多强。你的整体进步将根据你最慢的小组以及使其他人同步工作的能力来衡量。
最后期限是为新闻记者准备的
每一个项目都有一个最后期限即在某个日期前一切都必须完成。系统将“到位”或者“启动运行”不再需要更多的时间或资金。
管理层可以把最后期限看成是期望的日期把期间的酝酿阶段看成是“工作进行之中”。但是真到了最后期限尤其是对于软件安装的期限会普遍产生许多的失望。
但事实是
· 大多数系统实施既超时又超预算。
· 所有的SAP实施既超时又超预算。
这怎么可能是真的是否全世界的系统人员都是懒散而又无能的是否每个项目经理都是缺乏条理而且盲目的使实施准时在预算范围内完成真的是那么艰难吗
不但设定一个最后限期与其说是科学不如说是猜测其中存在着那些“超时”和“超预算”等词语的关键。
态度在其中起着重要的作用。计划主要是预测未来的艺术但计划经常由于个人或集体的超现实态度而走了样。
我曾经担任过一家大型连续印刷公司的信息系统主管我主要的内部客户中有一位是商务主任他是这样一种人当听到一位销售人员以百分之十的利润做下一笔交易后他总是说如果是百分之十五就更好了。所以他的销售人员学会了说他们得到百分之七的利润只是为了听他说百分之十是理想的目标。
这位主任在请求信息系统服务时也抱怨有同样的态度。我提出一个完成日期他总是觉得我在估计中有所保留。他总是试图把三星期削减到两星期半年削减到四个月。就他而言任何为公司商务部门所做的工作都是“超时”和“超预算”而我的记录显示我们百分之八十以上的工作是达到预定目标的。
应该由项目经理根据实际情况制定一个计划而不是根据高级管理层的期望值。如果两者不能达成一致即如果高级管理层给项目经理施加压力要求加速进行不应加速的实施工作那么项目从开始的那天起就超时和超预算了。
这发生于单个应用程序已够糟的了发生于全企业规模的SAP项目更是等同于精神折磨接近于悲剧。管理层必须支持项目进行即使项目“超时”和“超预算”否则实际的效果是给实施小组增加心理压力这种压力产生于错误的时间概念而不是产生于业务的具体抱负目标。
在大多数SAP项目计划中
1. 没有考虑到教育学习曲线。
2. 使用以往的实施项目作为基准例如“上一次财务软件包的安装只花了五个月”。
3. 高级管理层不相信在咨询方面所需要的成本在预算中砍去了那部分。
4. 过于”乐观地“认为公司内有足够员工完成项目。
计划的结尾是最后限期。九月一日一月一日四月三十日这些都是人们最喜欢用的日期但是在SAP实施中这些毫无意义。
在一家正在进行大量SAP工作的公司走廊里有一幅招贴画上面的口号是”成功是有期限的梦想“真是这样吗
最后期限背后的假设是它能督促人们好好地工作仿佛没有期限他们就会犹豫不决到处闲逛或者翻翻报纸而不是脚踏实地地解决工作中的问题。事实是人们只有在有指导、有尊严时才会努力工作。最后期限侵蚀人的尊严并不能提供足够的指导。
有些最后期限是自然的如付款条件而且必须遵循。而其它最后期限则是管理层痴呆的表现。年底是一个期限但财会系统以外很少有系统要求这样的期限。
如果有充分的业务理由要求一个具体的最后期限你就必须计划调动各种资源以满足这一要求但你也应该现实一些。在许多情况下你已经超时因此试图赶时间只会在整个项目过程中让人们增添焦虑的心情。
我曾在东京当过一个重要项目的经理。项目开始前一位信息系统经理通过翻译问我我们是打算订下一个最后期限到了那天我们就大功告成了还是按照日本的方式进行只要建立起个好系统花再多的时间也可以。他是想借此侮辱我但最后倒是给了我一些启发。我原打算确定一个最后期限最后证明这个期限是过于乐观了但在这次交谈后我放弃了它。这是在1988年7月我告诉客户他们的系统将能在1990年的春季三月四月或五月正式运行。在项目进行过程中出现了许许多多的艰难困苦但是时间并不是个问题。我们一直干到1990年5月30日。我们能否干得更快一些当然可以但这样做我们就要以质量为代价我们的客户可能会因此得不到同样的最终利益。
这个故事的教益在于如果一定要设定最后期限也应反映出项目持续过程而且除非有使人非相信不可的业务上理由外为SAP实施设定刻板的最后期限是不明智的。
这是只为你准备的方便指南
持续时间
完成时间
18个月或更长
春季、夏季、冬季或秋季
12至18个月
任何两个月例四月/五月
6个月
任何一个月
星期
星期五或星期六
天
午餐后的任何时候
继续计划
SAP实施计划不应该在项目开始时就定稿而且以后不再更改。实施计划应不断进行修正直至实施完成前的最后几周。即使项目范围在开始时已经固定其它大量的因素在三个月之内就会使最初的计划变得毫无用处。这些因素有
1. 项目开始之初并不充分了解所拥有的各种资源。你不知道咨询顾问是否称职他们有多少真正的SAP经验你也不知道你的员工将如何支持该项目的进行。
2. 公司外的教育课程计划可能不符合你的计划。
3. 项目范围从来就不能真正固定得住尤其在全企业范围内进行实施。
4. 你不可能预知所有会发生的事情尤其在项目的后期发生的事情。
考虑一下不同的项目计划层次
时期
阶段
阶段
活动
活动
活动
活动
任务任务任务
任务任务任务
任务任务任务
任务任务任务
传统上三个时期是计划开发和实施在SAP项目中开发时期被看作是业务流程设计/设置/原型化
阶段构成了项目框架例如产生设想组成实施队伍实施硬件最终用户培训等等。
活动是由一组一组的任务构成而任务则是要做的具体事情。
在“计划时期”以“活动”以上的具体内容来规划“开发时期”是不适宜的在为期更长的项目中“实施时期”只应该在“阶段”层次上规划。
最重要的是整个项目的“时期”和“阶段”计划应在一开始就作出。“计划”和“开发”时期的“活动”计划只能在此时作出。对于“开发”时期不可能考虑到所有的活动。只有当开发的主要部分完成后才能进行实施阶段的“活动”计划。“任务”计划只能在每个阶段开始前才能进行。
我们强烈建议你不要在项目开始时就将一个完整的计划分发给实施队伍中的所有人员。大量的细节和多页的任务将使你的员工迷惑不解并不知所措而且一旦你修改了计划他们会非常不快。
你应当在项目开始时分发一份阶段层次上的计划其中只包括针对每一具体小组的第一阶段“活动”计划以及最初“活动”的“任务”计划随着项目的进行你将根据需要制定和分发具体的计划使用分阶段的初步计划作为实施小组的总体准则。
这样做的结果是实施小组成员们将对项目的前进方向具有一个清晰概念而不会因任务和活动层次上细节变化变得无所适从。
同样从一开始就必须勾勒出初步计划。你必须要制定一个可行的预算和时间计划这样项目就会具有一个方向和价格标签。但是统计大量具体任务所需要的时间和成本工作量很大却不会因此产生合理的预算。所以你应该一开始采取空中俯视的方式然后随着项目的进行逐渐降低高度这样目标和利益将清晰地映入视野。
咨询方面计划的“及时”方法
你应该指望你的员工越来越多地参与到实施项目中因为你的目的就是要让他们领导项目直至完成。但是你还是需要一定程度上协助你工作的咨询服务。
在项目过程中你不必从头至尾将咨询顾问的参与保持在同样的程度上。但是不管怎样在你需要的时候找到你需要的咨询顾问并让他们为你工作一段你需要的时间可能是困难的。
好的咨询顾问就象是摩西。他们有机会来领导但很少有机会看到“希望之乡”看到终点看到目的地。他们如空降般来到你公司用他们的能力寻求指导随着你公司的音乐节奏跳跃。好的咨询顾问迫使这种节奏变成业务般的语言一旦客户获利后他们就会悄悄消失。
这是一张近乎完美的SAP实施中内部员工和外来咨询顾问参与量的曲线图。
咨询顾问
内部员工
专家阶段
职责完成
在计划阶段你很可能需要一批咨询顾问为战略规划、队伍建立和进行设想提供推动力和专业技术。随着这个阶段趋于结束你可能会引进一小队必要的咨询顾问帮助你完成的大量的设置和集成工作。最好是让他们在急需一周的星期一出现而不是提前几周出现。在开发阶段前三分之二左右的时间内咨询顾问将向你的员工提供SAP知识转移。他们将为BPR和设置活动提供推动力和专业技术而你的员工正处于学习之中。
你的员工会逐渐地开始从咨询顾问手中接过控制权。设置问题不再看上去象魔方般难以对付你的业务流程也会开始为所有相关人员所理解。这个时候你将减少咨询顾问在公司的出现频率。你将达到“专家阶段”继续读下去SAP实施的好处也会初显端倪。
意外事件的计划
我曾在明尼苏达州的圣保罗市工作数年我发现每年十二月底以前用于除雪的预算早已用尽对此我并不感到有趣。这是个每年发生的问题因为用于除雪的资金是“意外事件专款”的一部分不管在冬季还是夏季都可使用。这个预算的问题在于所谓的“意外事件”是个什么都包括的概念而不是具体指一个不可预料的变化因素比如下雪其结果是每年的一月份或二月份还得由圣保罗市政厅投票决定拨给应急资金。
“意外事件”计划是制定恰当计划和预算时不必具体到任务层次的关键。你采取的应急措施取决于你对每个阶段的预知措施。因此不应该只有一笔资金或一定量的“日子”应用于“意外事件”。相反每个阶段都应该有一部分内容考虑到“意外事件”以备
· 计划中的假设不成功
· 项目之初你较缺乏经验
如果你为早期阶段准备了50的应急备用金你可能要为稍后阶段准备10甚至15的应急备用金。如果某一特定阶段的备用金没有用到这部分资金不应该挪至以后的阶段除非你同管理层共处于可怕的预算困境这种情况下任何事情都可行。
设立应急备用金并不等于你可以故意放宽预算尺度而是为可能的错误留出些解决的余地。如何确定这个余地将在制定一个实际、可信的项目主计划中起到很重要的作用。
SAP项目的一个计划金字塔
这章主要涉及各种项目。但是SAP项目有它们的特殊之处应在计划时予以考虑。
· 学习曲线。
· 对变化的自然抵抗。SAP带来的变化是巨大的相应产生的阻力也是巨大的。
· 全企业范围实施意味着计划将围绕整个企业进行。
我们公司的一些咨询顾问在南部一座城市里怎么也完不成项目。在那里对SAP的抵触情绪从上至下充满整个企业。在解决阻力问题时管理层中也产生了阻力。公司里的老资格员工声称“SAP项目开始前我们就在这里SAP项目在厕所里被冲走后我们还会在这里。”他们现在仍然在那里项目已在厕所里被冲走这主要是这些人的“功劳”。
这家公司没有就阻力问题作过规划。虽然这只是他们所犯的巨大错误之一但这是个很昂贵的错误。
你必须为阻力作好准备计划好消除阻力所需的时间你还必须为陡峭的学习曲线作准备不仅为了你的项目成员也为了所有受到项目影响的员工。
顶峰或低谷
时间
舒服阶段
专家阶段
进程
舒服阶段
一个项目的最初阶段是使人十分兴奋和看上去大踏步前进的日子。你确定了设想组成了实施队伍制定了预算和主计划派遣若干主要人员去SAP培训中心墙上贴满了各种图表。咨询顾问开始知道休息室在何处吹嘘着他们的定期汇报技能。你只听到大约三十次“SAP成功的关键是请填入空档”这样的话项目经理仍然晚上七点钟前回家。
啊这就是“舒服阶段”。卓有成效的会议令人愉快的午餐墙上漂亮的图表构成了良好的生活。
海啸从涟漪开始任何一股加勒比海的微风可能导致飓风的生成落在山脊上的每一片雪花都可能成为雪崩的一部分。你的项目将变成什么什么样无关痛痒、微不足道的麻烦事情会给你带来认真实施中的艰难险阻你将如何应付这些麻烦事
在“舒服阶段”只有直接参与的项目组成员和部分管理层人员受到直接的影响公司的其他人员还处于圈外还只是涟漪、微风和雪花。
学习曲线
一旦设置工作开始学习曲线就变得陡峭而又令人害怕。在计划阶段看来象一排排小山现在呈现在人们面前的却是真正的连绵高山。你也正处于BPR光滑的斜坡上同那些听说过项目但至今为止还未受到其影响的人们开第一次会。力量曲线还未到来但首先要看到的是学习曲线的顶点。
现在你开始明白SAP的复杂之处和力量所在。你正在学习设置流程突然SAP特性开始显露集成与工作流。你首次意识到包含8000多个表格的系统是如此深邃你在SAP培训中心所学的课程还未能使你充分准备好。
如果在你公司已充满咨询顾问时你才开始认真对待学习曲线你将面临两大障碍
1. 在咨询顾问和你应该取得进展时你还正在学习这将是昂贵的。
2. 那些不管出于何种原因反对项目的人们会将项目看作是吞噬成本和时间的巨大窟窿并把你明显的慌乱认作SAP不是解决方案的证据。
你如何才能缩短学习曲线你应预先对此进行规划确保在达到项目这个阶段以前已完成了绝大部分艰难的学习任务。你向你的重要员工提供有关设置和集成的实践和理论方面的培训。你就SAP本身教育你的管理层人员它是干什么用的它能做些什么以及它与传统系统实施项目有什么不同。简而言之你不能只带着完美的指南针而背了只空背包到达此处。
力量曲线
当学习曲线还在上升时力量曲线就闯了进来。这些曲线在何处相交可能决定着你项目的命运。在力量曲线产生过程中公司将就实施SAP的可行性进行争议。那些驾驭学习曲线的人可能会赞成实施而那些落后于学习曲线的人很可能会反对。在此期间项目会停顿下来。具有SAP知识的人们会发现很难使不具有SAP知识的人们明白他们的主张。公司里一些原本将被项目推倒的传统做法会被那些对正在发生的事情迷惑不解的人们当作大炮来使用。
正是在项目的这个时期你觉得你永远也成功不了。预算和神经都快被撑到了极限超时似乎已不可避免。
如果一开始管理层就有足够的投入这条曲线就能缩短。但是如果管理层只是在这个时候才踏入圈子项目就好象要从头开始有关成本和利益的问题象纸飞机般被到处乱掷。你要忍受这条曲线多久取决于你公司的团结、管理和交流能力也取决于你在“舒服阶段”的准备程度。
在大家一致认为仍然将继续实施 SAP那些驾驭学习曲线的人将领导实施的时候或如果这样力量曲线将达到终点。
专家阶段
到这个时候你已经准备好飞跃了。你已经历了培训、数月的尝试和失误大部分政策上的丛林之火已经扑灭。这时耐心比以前更是个问题因为你已接受了数月SAP知识的灌输而最终用户和其他人员则刚开始接受洗礼他们是现在积极参与的人们。
这个时候你身挂实施战斗留下的伤痕对争论已开始感到厌倦。一鼓作气冲向终点是对你的诱惑。但是你要抵御住这种诱惑就象咨询顾问曾经向你传授知识一样现在你要向你周围的人们传授知识。
在庞贝的某晚曾有过晚餐计划
在制定和修订计划时你必须知道项目是不会不折不扣、按步就班地依照计划进行的。人性和业务事件是不能用微软的Project文件来严格管理的。制定计划实际上就是预先警告和错误地假设你能精确地预言未来。如果你看到项目没有依照计划进行就应大声地说出来和写下来。你的同事和管理层人员会欣赏这样的小心谨慎他们不会欣赏突然而至的最后失望。
最后衡量SAP实施的成功不是看实施是否紧跟计划行事而是看你公司能否充分实现预期的实施利益。如果为了给公司带来利益而更改计划就更好了。
要为利益而不是为最后期限而殚精竭虑。这样海啸还停留在涟漪状态最糟也只能使人淋湿而已。
第五章从彷徨者到探路人
各式各样的SAP教育浪潮
教育不只是培训
在你的职业生涯里寻找难忘、持久的学习时刻。其中有多少发生在教室里或讲堂里有多少发生在老板的办公室有多少发生在午餐时带着一支笔一本笔记和一瓶啤酒有多少发生在业务战场上
在你商务生活中什么时刻使你面对着卧室电影银幕般的天花板沉思至深夜你职业生涯中的有什么使你夜不能寐
信息是具有相关性和目的性的数据。将数据转化成信息需要有知识
彼得symbol 160 /f Wingdings /s 14 }特拉克
《哈佛商业周刊》
1988年一月/二月
是失败。或者最好的情况是搏击。
很明显我们从失败学到的要比从成功中学到的更多。当我们作出了导致灾难性后果的决定后我们通常数年忘却不了这些后果带来的创伤。我们分析和在脑海中重放出错的地方通过分析得到教训。当我们成功了就不会作那么多的分析。失败被当作非正常现象而反复审视而胜利则被当作常有的现象抛在一边。
但是胜利在SAP领域或其它地方并不是每天都能产生的。估量一下你自己公司最近的十个提案你会发现大约只有三分之一会达到预期的结果。最近几年SAP一直由于其费时、昂贵和复杂的实施遭到抨击。在SAP实施领域里确实存在着使人疲乏的教育问题以及一大堆的后悔、假设和疑问。SAP实施覆盖整个企业与它们的近期和中期命运紧密相关。风险是高的高过大多数参与者能够相信的高度。
当我们仔细观察实施困难背后的原因时我们通常发现用于教育的预算少得可怜。我们还发现高级管理层对于SAP除了手册上的目录和标签行外知之甚少。高级管理层通常对SAP能为其公司所做的要求甚高这一点也不奇怪。
克利斯symbol 160 /f Wingdings /s 14 }卡尔森经常提醒我们大家SAP要求有一个教育计划──不只是培训──因为人们获取知识必须通过对SAP概念有系统而且全面的了解。培训是通过学徙制和操练让人学习技能的。技能培训是解决增强我们SAP教育概念这个疑难问题的一部分但是对你公司成功实施SAP只有技能培训是远远不够的。我可能有时要回到“培训”这个词的标准用法上但是请专注于通过SAP教育获取知识这个概念。
我们基于无数次经验和观察的结论是大多数SAP实施失败主要是因为在签暑许可证前缺乏SAP倒底是什么样的重要知识。而且这种缺乏重要知识的问题在项目初始阶段又很少得到解决。只是在几个月的努力之后大多数公司才看到这点才暂停项目回到合适的地方进行教育工作然后再重头开始。查一查SAP成功的故事你就能发现它们大多数在历史上都有这种“开始、停止、学习、再开始”的循环过程。
你现在可以通过在教育上投资来避免这种费用高昂、令人伤心的循环过程。要么学习要么灭亡你得尽快作出决定。
预备开火瞄准
战场上有足够的遗体可供尸体解剖。SAP实施失败同蒲公英一样常见它们的种子通常在《计算机世界》和《信息周刊》的文章中着陆。你可以听见来自各地的抱怨声如果你理解很快你一定已经觉察“受害者”认为是SAP出了问题。
比较直接的问题原因是一种想获得立竿见影效果的态度有些抱有该种态度的公司想通过往他们雇员喉咙里塞下SAP的方式来实施SAP。最快、最便宜也是最急功近利的方法就是从实施直接跳到设置。设置任务是“开火”类的任务是释放决策之箭射向战略目标。在设置射失了一千个这样的目标之前很少有公司决定先瞄准。我们大多数人在较小的规模上有过相似的经历。我们为手提式或台式电脑定购了软件快速运行a:/setup安装好软件然后连一眼都不扫用户手册就尝试使用软件。安装是快速的但要掌握软件则慢得多。我们下一百个步骤要求你在索引和任何我们能尽快吸收的段落之间快速翻页以加快我们的前进速度。实际上我们总是先胡乱地玩上一段时间然后成为入门者。只有在长时期的操作以后我们才能掌握这个游戏。
把这个属于我们一部分的北美口头语乘上你公司委以SAP实施重任人员的数量扔进一个平方或立方乘数再加上社会和职业上的压力让它慢慢熬上三至六个月你就闻到成熟的香味了。
回到未来
在你SAP选择以前你的大多数员工很可能已经历过不至一次信息系统实施工作。但是SAP实施与众不同你对此还未准备好恰恰是因为你已实施过其它系统。
你的员工需要作好准备但在大多数公司中除了主要人员有过SAP培训和偶而举行研讨会外其他人几乎没有重要的SAP知识却冒然开始实施项目。你不会聘请中学毕业生担任你公司的经理但是硬让你的经理人员进行SAP实施工作你实际上正在将这些人员送回到未来因为以往所学所练的管理和业务技能很容易同这种业务流程和信息技术的混合解决方案混淆起来。采用信息技术方式是一个致命的错误。在实施传统信息系统时管理层所从事的任务和活动不再完全适用。
倒底是什么与众不同直到目前为止你的员工是把信息系统作为你公司中信息服务或信息技术人员所提供的服务来对待的。业务人员要求得到服务也被要求以具体的功能规格来定义他们的需要。信息服务人员通过购买软件和编程来理解和实现这些具体要求但编程并不是由业务人员完成。
在SAP编程不是个问题设置却是。编程是创建一系列代码使之能够指引信息来往的顺序、路径、处理和终点。设置则是设定业务图表使之能够指引信息来往的顺序、路径、处理和终点。编程是机械性功能而设置是业务性功能。
给一位业务经理看下面一个句子看看他或者她能对此有何反应。
SET VAR TO 4 GO CHAIN TO RT 742
RETURN IF 3 PAUSE
WRITE TO CALL
编程使业务和业务满意之间产生了差距。这种差距从数据处理开始以来一直存在。业务部门可能已确定了曲调但信息服务部门操纵着所有的乐器。SAP通过将语言还给业务部门以一种革命性的方式解决了差距问题。
当我们孩提时代玩美式橄榄球时我们这样称玩法“帕迪朝底线跑。克利斯你最好堵住那个胖家伙”。在你上中学后同样的玩法被称作“位置向右跨4中路堵截“。在中学时要为十一位球员简明、快速地作出详细指导因此普通的指令变成了语言程序。“X位置向右”描述了边线接球员要跑动的线路“跨 4”告诉跑动中的后卫佯装跑向右边锋“中路堵截”意思是所有卫线队员最好堵住那个胖家伙。
同样的老式的编程将你的功能性要求转化成代码然后送还给你的是与你所要求相仿的功能。
在SAP实施中代码处于幕后给你的是经过恢复的普通业务用语。你不必向信息系统人员说明你的要求你可以通过设置用业务语言自己确定。在你根据一个业务流程设计设置SAP时你事实上正在标题为“定单证实限制”或“最大允许数量”等你理解的数据区域里填入数值。你可以决定在某个特定屏幕上哪些区域出现或者不出现。你可以决定多种货币财务活动如何进行每天由EDI提供汇率更新还是每周手工输入等等。你这样做时程序员几乎不作干预他们只是当SAP功能不能满足你最深刻的业务追求时才出来作些调整。
如果你的管理层让你在没有预先SAP教育的情况下这样干你就象不穿衣服奔跑在荆棘遍地的原野你的实施项目就会变成一次充满迷惑和焦虑的经历。
对大部分员工来说同信息服务经理们坐在满是文件的会议室开上几小时会并不新鲜。他们可能已经非常精通如何定义他们的要求并且通过安装了一个应用程序他们甚至对于如何紧跟发展也变得非常精明。
但是作为一支队伍他们不知道如何将SAP设置成一个以工作流为目标的无缝应用程序套件。在没有预先足够的SAP知识情况下要求他们接受这项任务就好象把他们送回到中学阶段从毕业舞会上直接聘用他们然后将他们置于正进行大海战的战舰甲板上。
他们可能会随着你的战舰一起沉没。
但是如果你提供了足够的培训你就能
· 大量减少对外来咨询顾问的需求。
· 因为你在他们技能上的投资和因此产生的对他们的信赖激励你的员工。
· 建立已经十分丰富了的公司内部SAP技术知识共享库这样就能大为减少用于令人担心的AS IS 阶段的时间。后面要详细介绍这个内容
·获得能引向可信的项目计划和预算的理解基础。
· 为适当应付各种期望即SAP能或不能为你公司做什么提供一 个基础。
· 确认哪些人可以取得飞跃哪些人不能。
SAP培训比SAP咨询更能使人收益。
一个有关把握方向的案例研究
我并不是日本式业务方式的虔诚信徒。相反我对八十年代风靡一时的许多业务方法持怀疑态度当时普遍认为日本的方法是他们成功目前落后了的关键。不管怎么样我在那个国家里的一个项目中得到了许多教训这里我希望把其中一个告诉大家。
在一个为期两年的项目里我负责一个实施小组由来自库柏斯和立布兰德公司的英国人组成他们早已因在欧洲的一些项目而声名显赫。由于我们以往的成功我们被挑选去日本为同一家公司解决一个严重的问题。在那项目的后期SAP前我计划用三个月时间将我们的设计移交给一家第三方日本编程单位。我计划给他们五个月的时间用于编程在这个阶段结束后开始正式实施。
当然设计移交工作由于语言问题变得复杂起来。我比常规情况多加了一个月时间对此我还自觉聪明颇为得意。但是设计移交的前二个月过去后我的队友告诉我项目可能要超预算。那家编程公司增加了越来越多的会议其中许多根据我们的想法是多余的。开完一次三名程序员参加的会议后又会开一个由同样三位程序员另加二位参加的会议。紧接着的会议由前两次会议中的部分人员和一、二名新人参加。
我找了本英日词典查找“压力”这个词的意思。
设计移交阶段持续了五个月超过我项目计划两个月。但是编程只花了三个月比我的项目计划少了两个月。实施如期进行。我又一次翻开英日词典寻找“这到底是怎么了”这个词语。
词典的答案是第三方日本编程公司不希望设计从设计者直接移交给编程组负责人而要一遍又一遍地移交给所有程序员直到编程组所有成员从头至尾彻底掌握这个设计。一旦这部分工作完成后编程本身就是径直奔向终点的冲刺没有必要再说这样经常能听到的话了“杰里米我还是不太明白这该死的库存程序。真见鬼什么我们能否开个会”
编程组在充满信心进行冲刺前把握了方向。在经历了独自闯荡日本的汗水和压力后我经常在想“别再发生了”。但是我承认对SAP实施以这样的方式管理感到难以理解。
编程组在充满信心进行冲刺前把握了方向
他们既准时又符合预算这里有个概念。
所需教育的清单。
你已经阅读了大量文章这些文章都描述了在培训预算、公司内部再教育、适应性培训或者在业务场所进行学习或其它什么名称方面的巨大增长。在七十年代据认为职业技能应该每六个月左右就得重新学习一次。叮咚现在是1997年新的职业技能必须每周学习一次。在日常工作中这不一定是个不好的阶段。最起码这是个现实最好的情况时这是进展。你正在阅读本书而不是最新的“律师拯救世界”之类的廉价畅销小说证明我们都处于同样的困境。因此让我们充分地利用我们现在所拥有的一切。
既然SAP已控制着你公司的精神状态加速学习必须成为活动的节奏。一方面你每天要应付各种日常业务另一方面你根据员工的要求改变你公司的面貌以便你能照照SAP镜子。我可以保证只要你在正式开始涉及巨大范围的SAP实施工作前坚持进行和获得恰当的培训和教育你和你的同伴们就一定会成功。
仅仅假设你和你的员工需要SAP教育太过于简单了。不管怎样据认为大多数公司在这样的项目开始时就给预算很大的压力。真正需要的是在水平层次上观察所需的培训谁需要培训和什么时候需要。
你公司中要涉及的教育层次有
· 管理层
·实施小组
·信息系统支持人员
·最终用户
·新职业培训来源于BPR
·周边技能Windows个人电脑技能
·使公司准备好应付变化
管理层SAP教育
我们经常发现这样的情形即高级管理层由于SAP实施的“超时”和“超支”而技穷力竭我们对抱怨SAP项目费用高昂但进展缓慢的副总裁们的沮丧不再感到奇怪。但我们深入探索高昂费用和缓慢进展的原因时我们总是发现管理层对于SAP实施项目究竟能实现什么只有非常模糊的概念。使我们确实感到惊奇的是许多已开始实施的公司陷入麻烦即将完蛋的时候公司的管理层还似乎仍然稳如泰山迷惑不解是引人注意的现象。
管理层倾向于认为SAP实施与公司自七十年代以来已经从事过的其它软件的实施相似。这是任何这样工作中最糟糕、最有害的谬误因为这种谬误在时间、预算和预期利益上误导人们的期望。在软件许可证中划上一笔对于引进新的财务系统不是大不了的事。技术人员和财务人员自己就能以最小的麻烦和最少的超支实施这样的系统。
SAP提供一个概况性课程也提供大量录像指导下的幻灯片演示。SAP所没有提供的是在你签署许可证前让你有机会仔细看看你是谁。做超出他们应该做的事不符合他们的利益。你是买主而他们是卖主。因此好好考虑一下不管你是最高行政主管最高业务主管还是最高信息主管。你在考虑投资数百万美元这个投资将使你公司的命运依赖于你公司在该项目中成功的能力。你想将公司带入下一千年而你被有史以来能使业务快速飞跃的最佳软件深深吸引。你会从SAP还是从六大伙伴公司寻求指导好干得不错小脚只能迈小步。或者你会让自己多学一些
去找一个专家讨论会。然后第二个、第三个。在更多地花钱以前就这么干。派几位可信任的官员去另外一些讨论会。比较一下不同的笔记。花23.95美元买一本书让你学习如何入门再花23.95美元买另一本书。你的时间本身的价值就十倍于这些书籍的价格你所学到的可能将节省你公司成千上万美元。
仅仅为这种教育你可能花费你公司总共十万美元用于讨论会另外十万美元用于可以依赖的咨询顾问。如果你是在谈论一个二千万或五千万美元的公司投资这些费用就显得黯然失色如果你当真在寻找可达到的投资回报这些费用会有人承担的。
管理层SAP培训的好处是巨大的
· 可以制定实际的项目计划和预算因而大幅度减少实施小组人员的心理压力
· 投资回报几乎当然成为项目的中心任务这本该如此
· 在一开始就能确定期望的目标大量减少以后的相互指责
· 管理层就能到位就能正确评估外来咨询顾问评估他们的工作态度和工作业绩
这方面最后要考虑的一点如果SAP培训只是提供给中层及以下的管理人员一旦SAP实施完毕高级管理层就无法继续处于领导公司的地位。
对你实施队伍进行SAP教育
你会把你最优秀最聪明的人员组织起来力图把他们捏合成一支队伍。刚开始时你可能要依赖于外来咨询顾问推动项目的进行但你不希望这种情况永远继续下去。
实施小组成员有许多人很可能是中层管理人员他们的职位会因为项目的缘故而将被撤消。你可能不仅在实施时期而且在实施以后都要把他们看作是内部支持人员因为你公司将继续调整和设置SAP以便改善其状况并给企业带来更多的利益。
你所尝试的就是建立内部SAP咨询顾问团他们能从外来咨询顾问手中接过昂贵的火炬帮助你高举那仍然点燃的火炬奔向实施胜利的终点
1. 空中俯视图
2. 集成的水平视图
3. 专家视图
SAP 第二第三级培训
FI, CO, MM, PP, HR, PM...
4.实施小组视图
5. 项目经理视图
项目管理及更多
第一阶段空中俯视图
SAP提供产品培训这可以被看作是传统的垂直培训。任何需要销售和分销深度培训的人都可参加SAP的概况课程然后是第一级至第三级课程以获得完整的销售与分销SD教育。但仅有这些还不足以使人有资格有效率地参加据证实是垂直式、以工作流为目标的实施工作。
相反任何可能成为实施小组成员的人应该首先学习SAP的业务基础知识。SAP概况课会有所帮助但它只局限于SAP本身不会涉及实施中所有的周边问题例如
· SAP为何如此与众不同
· 有哪些实施问题
· 需要多少业务流程重组才能使其工作
· 谈到这里什么是业务流程重组
· 咨询顾问在项目中能起到什么作用
· 由谁来做做什么怎么做
这些问题中有许多及其它问题在我们的第一本书里《迎接旋风SAP 世界初学者指南》有所涉及。许多其它问题在本书里有介绍。但是需要提供更多的背景资料包括案例分析和实施情景因为没有两次SAP实施项目会完全相同没有什么固定做法也不存在厚厚的成套方法集和一步步教你如何做的指导书。
因此第一阶段的适应性培训和定位是必需的你不应该在这方面有所欠缺。如果你直接跳到SAP产品培训你的问题就会比答案多。问题要花时间和金钱。答案减少时间和金钱的花费。这是具有明显回报的投资。
第二阶段集成的水平视图
我们忍不住还得重复已经说过的话。SAP生活的事实总会以这种非常多余的方式循环往复。SAP是一套集成的应用程序套件它使你学会和应用工作流区别于通过接口和昂贵的线索互相串联起来的垂直应用程序。因此你的实施小组必须尽快完全地学会集成的基本原则可以也应该先后学会集成知识和具体设置方法。
被派去设置SAP 财务模块FI的人仅仅学会 FI 是不够的因为设置 FI 的决策将对设置 SDMMPP 和其他模块产生因果影响。因此第二阶段的教育应该把重点放在集成上对于设置原则进行扎实的基础训练。
最有效的培训经历之一是成立一个用于试验的公司进行包括 FICOSDMM 等关键模块的设置和集成。这个时候必须进行动手实践性的教育上课和阅读的价值极其有限。
第三阶段专家视图
在SAP领域里没有复兴的人们。SAP的全部内容没有也不可能被一个人所掌握。SAP在业务方面的广阔和深邃的内涵使我们都可能成为这样或那样的专家。例如本书的作者就是一位项目管理方面的专家他不会设置MM模块但可能对 FI 略知一二。
你的员工最终都会具有专家身份FISDMMPP。将人们塞进这个或那个区域是SAP领域中的特点。有经验的咨询顾问经常会倾向于使用连字号例如SD-MMFI-CO或者MM-PP有时候内部人员也会这样这是SAP水平和集成的性质所引起的。
但是这个时候你必须允许你的人员学习他们具体的专业。现在你要送他们去参加SAP第二级和第三级培训在那里他们可以集中精力于将由他们直接负责的模块学习其关键和直接方面的知识。
SAP美国公司在五、六个城市里常年提供这些课程。
第四阶段项目实施小组教育
绝大多数的SAP实施项目都在某个地方设有一个经常被称作是“战争室叹气的房间。在那里实施小组成员紧挨在一起连续数周协同工作设置、流程设计、重新设置直到SAP模型在原型中使人基本满意。
最常见的是这些实施小组成员一开始分散着以传统的垂直方式独自工作毫无结果但是随后出于需要他们越来越彼此靠近以便更好地工作。从项目开始到他们都出现在“战争室”又叹气可能要几周或者几个月取决于他们的集体观和你项目管理的质量。
我们这里推荐的是一个中级教育阶段让这些人在一起参加一个为期两周的实施小组培训练习活动。在此期间可以同时测试和提高他们的SAP技能。
有一些成员可能会在培训中摔倒在路边。或者你可能发现原先某些成员设计的角色最好还是作些调整。这种教训的成本同一旦项目开始所可能花费的成本相比是微不足道的。这个阶段的培训将证实你的实施小组就是那样一支好队伍。
最后的提示只是为了丰富多彩一些把你们都去的那个房间的名称改了吧不要叫“战争室”试着叫它“和平和安宁室”或者“联合国”或者“招财进宝屋”。总之选一个乐观向上的名称一个没有血腥的名称。
你在寻找什么样的实施小组
一支足球队由一批专家组成在教练的严格控制下协同工作对于SAP实施这可能是一种可取的组队方式。另外一种方式是建立一支类似于网球双打的队伍。每个选手的优势得到充分发挥每位选手的弱点则由另一位选手的优点弥补或掩盖。这样的队伍将不需要太多的指导管理能为创造性和推动力提供足够的余地。
第五阶段项目管理视图
这个教育不是针对所有参与实施的人员。但应提供给项目经理、主任和实施小组负责人。你正在阅读本书这样你就进入了项目管理视图。不可否认你倒底需要什么样额外的教育才能使你准备好领导SAP实施是不明确的。即使你曾经成功地管理过其他大型实施工作你仍然将需要更多的教育以理解SAP集成和管理一支实施小组的要求而这支实施小组比你其它项目要求更紧密的合作。其关键在于要避免过分依赖过去的信息系统开发和实施经验在SAP实施方面保持一种开放的观点。
如果你是项目经理你需要知道你的主要作用不是协调各种资源而是领导。在你身后混乱的职业道路当然你对所有跟着你走的人来说是项目活生生的象征将会是要解决的主要问题。你应该随时准备在超出你能力范围的领域里寻求帮助和指导。有时会突然想到改变管理方式也会想到网络客户机/服务器等问题。
老一套可用于传统软件安装的“个人崇拜”方式尽管以往可以被信赖但用于SAP实施肯定会彻底失败因为该项目涉及的范围不可否认是极其巨大的。项目经理必须时刻准备好学习最重要的内容之一就是学会如何委托和分配关键的周边工作。另一个要学会的内容是尊重这样的事实即你周围的每个人至少在某一时候是所有正在发生中事情的生手。另外项目经理是所有专业的生手他只能钻研第二级或第三级能达到更大的深度的专业知识。
业务看上去简单而且SAP项目能帮助有关人员将简明性带上表层。但是事实是没有人能够掌握业务的每一方面内容引伸一下说没有人能够掌握SAP的所有方面内容。
SAP实施小组教育──不管你怎样看待这是个可以讨价还价的问题
实施小组的SAP教育其成本大约是每人一万至二万美元。如果这对你来说过于昂贵请看一下
· 你可能要支付的咨询帐单每小时150美元以上
· 你所追求的投资回报ROI
· 你所从事项目所承担的风险。
如果你在一位实施小组成员身上花费一万五千美元这相当于外来咨询100个小时或者有经验的SAP咨询顾问二周半的费用。你可以设想在项目开始后的三到四个月中获得可靠的投资回报并在整个项目进行期间降低咨询成本。此外你因为建立了内部技术知识库而不再继续依赖外来帮助减少了你的风险。
整个教育成本可能达到你全部实施成本的15到20当你精心培养的人员离开公司在SAP咨询领域中寻找更高收入的职位时你将肯定会损失很大一部分这样的投资。请考看有关咨询的章节中如何留住你内部咨询顾问的技巧。
对信息系统支持人员的SAP教育
在开始SAP项目时你可能要面对一些乖戾的内部信息系统人员。如果项目成功了他们长期以来赖以生存的遗留系统将不复存在所以他们没有理由在这个项目中支持你。
许多信息系统人员会看墙上的手写通知在你还没希望他们走前早已消失了。另外一些人则以比较积极的态度阅读同样的通知然后报名参加再培训以进入SAP领域。这些人是你的宝贝你必须尽早考虑他们的培训需要否则他们会跟别人一块离开到时你会发现自己处于会产生大量问题的技术真空中。
需要涉及的教育领域很多没有一个单一的培训方法可以在这里简单介绍给大家。尽管SAP提供开放式系统架构事实是BASIS操作主要是以硬件为特点。如果你的硬件设备主要是惠普的培训应倾向于UNIX系统。如果你使用的是Oracle公司的数据库在那方面也需要有相应的培训。
你几乎肯定需要具有扎实系统管理背景的人员。SAP升级的速度和影响本身就要求这一点。如果你在每次完成升级时都要依赖于SAP提供的帮助那么你在技术和财政上都处于一个脆弱的位置。
与些同时随着你的信息系统人员向SAP转化需注意以下一些严重的、与成本有关的问题
1. 在传统系统中编程向业务需求提供了解决方案传统的信息系统人员很可能是倾向于程序的。如果你将一些C语言编程人员集中在一起教他们ABAP语言他们会推测他们生活中新的刺激就是编写ABAP程序以满足用户组的要求。你并不想让ABAP编程渗透到你已建成的SAP体系。如果你真的这么干升级即使能实施也将是昂贵的系统维护就会回到你在传统系统时经历过的同样恶梦。
2. 信息系统在此之前一直处于“技术手段解决业务问题”的前沿阵地由此变为“业务手段解决业务问题”这样的文化变革需要时间。把信息系统人员从驾驶员的位置移到乘客的位置即充其量是导航者位置实际上是机修员位置仅仅靠SAP技术培训是不够的。
遗留下的信息系统人员将要求具有完全崭新的技术能力。电子数据交换和因特网是你首先需要了解的内容。等待SAP 3.1吧。一千年以前一个业务关键问题是货币你的用户是付黄金还是泥巴一百年前第一批真正的工作流主题开始出现。SAP可以解决多货币问题不管是黄金还是泥巴。工作流是SAP的核心。“相连性”是下一千年开始时的大问题。如果你没有在信息系统或信息技术方面强调这点你将不仅在1997-98年度而且在以后丧失SAP本应带来的巨大利益。
业务流程重组
在质量研讨小组的软弱表现和随之而来的全面质量管理的暂时冲击以后出现了称之为BPR或者业务流程重组的业务潮流和态度。
SAP和BPR从1992年末R/3发布开始就被看成是一对同义词。在此后的日子里SAP的产品和BPR理论很大程度上被运用于实践产生了各种不同的结果。据分析如果你能理性地重组你的业务你就需要基本系统能支持重组了的业务而目前最适宜的支持系统就是SAP R/3。我们花钱说明我们完全接受了这种分析。
商业系统和方式产生于五十年代在以后的几十年中得到了不断改善这些方式倾向于继续将技能分成各自独立的几部分。到了八十年代理论学家引进了新的、经过改良了的商业方式并在全世界尤其在北美运用于不太成熟的实践之中而北美当时正急于“赶上”日本。在编写本书时“赶上”仍是个争论未决的观点。全球经济正处于一个平缓发展的艰苦之路对于日本式管理和分销技巧的热情已不再是董事会议上对决策起关键作用的因素。新的关键因素是重组这个主题由于篇幅限制我们不能也不会作过多的说明。用一句经常可以看到钉在房间墙上的简单口号就行了“不要更努力地工作而要更巧妙地工作”。这值得一试。
工作位于BPR的核心工作的措施、流程和方向。要设计和制成图表的工作必须是能带来利益和客户满意的工作因此必须建立在有愿望达到追求目标的基础上。你即将需要的人员应该愿意谈论这一基本原则不受公司传统、政治、调动和个人地盘的干扰。如果这些人想创造出明白、合适的高水平流程图作为SAP设置的基础他们也将需要指路的明星。
给那些委以重组公司重任的人员能提供什么样的教育呢在这里SAP不是个问题。在你组队的时候每一位成员必须知道SAP是一系列桥梁、立柱、管道和关节能支持你采用的任何设计方案。SAP不是业务而是业务支持。BPR是你的业务计划因此不管是谁制定这个计划他或者他们应该成为你们中间的明星如果是一组明星就更好了。
我们还没有回答这些人员应得到什么样培训的问题。首先他们应在你们业务基本知识方面具有经验和坚实的背景他们也愿意在以后的几年中工作下去。你们生产什么谁买你们的产品为什么他们继续购买你们的产品
让你的实施小组阅读有关重组的基础书籍让他们参加一些SAP专题讨论会。如果他们最初尝试的结果是几大本厚厚的、充满方框箭头方框的图表那么他们是误解了这个练习的目的和手段。如果他们的成果直接涉及利益例如更快的定购处理达到原来的200那么你的实施小组已有资格正式开展工作了。
如果高级管理层将BPR当作任务交给某个遥远的实施小组或者更糟的是交给外来咨询顾问结果就会有问题。在迈克尔symbol 160 /f Wingdings /s 14 }汉默和詹姆斯symbol 160 /f Wingdings /s 14 }钱匹合写的名作《重组公司》中我最喜欢的一句话是“你不是在铁坦尼克号上重新安排甲板上的椅子”。把这话剪下来别在你接待员的衣襟上。尽管他脸上的自豪值得怀疑但是每当你经过他身旁去休息室时你就会再被提醒一次。
到这里我们要告一段落。业务流程重组是你所从事工作中的主要内容SAP会支持你的BPR而不是相反。对于BPR单靠这本书还不够你还得继续阅读才能成功。
新的流程然后是什么
这章是否会结束是否还需要更多的教育
既然你已经在铁坦尼克号上重新安排了甲板上的椅子那么每个人都必须挪地方了是不是现在有了新的业务流程大量新的见识什么都是新的。
至少现在我们又回到SAP实施工作。随着BPR进入到设置阶段脚本出现了。一个脚本就正如你所想象的一样是一个清单它告诉每个参与者在事件处理链SAP喜欢称之为EPC中怎样做才能把一件事干好。我接到一个定单一个事件然后把定单输入系统一次处理一旦定单进入系统所有能导致其它处理的事情事件相继发生直至供应定货和收到货款。
我们现在已距离BPR和设置若干光年远了。我们已到达被称为“最终用户”的阶段。最终用户是这样的人们他们在键盘上按键或者在牵引车的保险杠边使用条形码阅读器然后填入即将通过键盘输入系统的表格。
从本质上说最终用户培训最后落实到按键扫描条形码和偶尔填写备注栏。从更广的意义说这与新的授权和责任有关。
在SAP之前那些在表格的方框中填写或键入数据的人们这样做是为了完成各自相对独立的任务。琼赛在装货台上咔嗒一声用那支BIC牌圆珠笔在六箱货物的收据上作了个查对无误的记号接着在一份垫有复写纸的表格中飞快地写上自己的姓名首字母然后咬了一口他的三明治一份复写拷贝到财务部门另一份到了仓库。三明治是不错但为什么他们又忘了放色拉酱
在琼赛新的工作环境中那“咔嗒”一声不再是圆珠笔而是由键盘、光笔或者是条形码代替了。那手轻轻一挥那个签名就将数据送入了财务部门物料管理部门也可能到销售和分销部门。所以最终用户培训已变成如何让全公司意识到一次击键的重要性了。现在是教会琼赛比如何使用笔更多东西的时候了。
通过简单的基本培训琼赛就等同于过去的一个经理。
那么怎么样就给琼赛和你自己一些严肃对话和一些培训带来的好处吧
最终用户培训
这通常是唯一被列入预算的培训简单地培训那些将使用键盘将数据从一个文件搬到另一个文件的人员。整个项目的成败通常表现在这个培训中但事实上这个培训最多只不过是对在此之前所有的活动的点缀。
用简单的话来说给通向设置的新流程做脚本应该考虑制作最终用户培训材料。给每个人一份工作用的脚本最终的结果是理解。
许多公司将这个阶段的工作交给第三方专业公司即最终用户培训官这是为什么
第三方最终用户培训官是这些方面的专家
1. 将你们的所有努力合在一起
2. 将脚本汇集成基本功能
3. 将所有功能汇编成用户指南
4. 教会用户基本功能
我们使用这种方法时的问题是那些设计和设置了工作流的人们被排除在这种平衡之外。在一些培训课程中间爱丽丝会失声提出一些尖刻但是有特点的问题这些问题第三方最终用户培训官根本无法回答。因此我们要么打死爱丽丝要么回复理智让建造了庙宇的原班人马详细说明如何从台阶走向圣坛。但是我们首先应让那些有出息的人们学会正确的舞步。
新职业培训
这样的事发生了。你将面对所有的领域所有在你公司你所需要的人们他们的工作已经变化或者调整过了。你对他们有何计划
除了对他们现在所从事工作的培训以外还应该考虑一些周边技能。例如他们能使用Windows吗他们知道Window 95或者Window 97吗他们能操作下拉式菜单吗他们知道怎样将一个非SAP的功能联接到你们正在建设中的主流系统吗
当然他们不知道。培训他们
让公司作好准备迎接变化
如果我把这一节叫作“改变管理方式”很可能你会撇撇嘴对此不屑一顾。你可能会暗自好笑或者已经考虑跳到下一节去。仅仅提到改变管理方式就可能让管理层的朋友彻底晕倒。他们眼睛转动紧抓钱包马上就要大笑起来。
他们觉得那样的改变不可行改变管理方式的课程和咨询工作一向被认为是过于软弱过于一般不是以盈利为目标的。
几个月前我应邀去会唔一家大公司的副总裁这家公司正尝试实施SAP但正处于巨大失败的痛苦之中。那位副总裁已读过我们的第一本书而且似乎比较喜欢那本书他给予我非常隆重的欢迎。在上咖啡的时候我简要、迅速地介绍了我自己、我们的公司也介绍了我们提拱的SAP咨询及教育服务。在我结束的时候那位副总裁向后靠了靠微笑地说“那么你是不打算卖给我那种改变管理方式的万能秘方了。”
我的回答既是否定又有辩解但是语句混乱缺乏完整。我说不管怎么样改变管理方式对于这家公司都是必不可少的。我花了很长时间边搔头边想弄清楚是什么使我处于这样的境地最后我得出了一些结论
1. 改变管理方式是八十年代兴起的许多咨询小玩意产品的后代在当时的热潮中主要的领先产品被看成是过于敏感而需小心对待的东西这经常倒是正确的看法。
2. 全面质量管理、质量研讨小组等类似管理方式被看成是失败的方式。它们有可能包含在对它们能向公司提供什么的管理层期望之中。
3. 不管怎样经历过这样项目痛苦的公司尽管失败了至少也会让它们的雇员熟悉变革方式以便使他们准备好进行例如SAP实施这样革命性的活动。
如今改变管理方式已经成熟已不应成为嘲笑的对象。商业概念将随着市场及市场对于这些想法的认识和欣赏程度这是基本点变得成熟起来。已经有很久没有看到销售队伍一起登山一起在惊涛骇浪中乘筏子航行以准备证明他们的团队合作能力。在八十年代这样做的人们结果又冷又湿九十年代为我们提供了毛巾和某个焦点。
我们想强调“让公司作好准备迎接变化”这个概念。你的公司需要集中精力让人们意识到公司里各个层次的人们所经历过的困难和拼搏。实质上
让公司作好准备迎接变化注重的是
SAP
实施努力中人性的一面
· 消除针对变化的阻力
· 为职业变化提供方便
· 在人员削减的环境里解决“生存内疚感”问题
· 其它在这章中讨论过的教育工作如果你正在培训你的员工你已经发出了积极的信号。
我们在本书中不断强调SAP实施并不可爱或者人道。它们的特点是产生极度的忧虑、长时间的工作、偶而的恼怒和迷惑不解的痛苦。进行这种项目的公司根本不是考虑到个人的需要也甚至不是集体的需要。金钱、生存和发展是进行SAP实施和随之而来的BPR和/或人员削减的原因。象这样的热潮导致混乱、愤怒和抵抗。最重要的一点是你可以培训员工听从指导但如果你不能处理好他们自然的困惑和对变革的抵触情绪你是在把他们贬为公司的工具。
如果你公司有1,000员工你打算在这项目上花费一千万、二千万或者三千万美元那么建议你多花一百万左右“让你公司作好准备迎接变化”。你仍然必须在众多在方面提供帮助的公司中进行挑选你仍然应该从中挑选出一家或者另一家公司。
最后的注释我们仍然同那位副总裁保持着紧密的联系。在尝试实施SAP时由于没有考虑到改变管理方式他受到了很大的伤害现在他是同样这些原则的坚定信徒。
这SAP就象是沙子我们可以用手掌捧起一大把但是许多沙粒将从我们手指间流掉。那些留在手心里的就是获得的知识和经验。所以我们又把手伸回沙子一遍又一遍。这样沙子总会越来越多。我们唯一的愿望是拥有更多的知识否则我们只能祈求有更大的手掌。
咨询联盟SAP系列的下一本书《旋风中的人们SAP实施中的人性一面》将集中介绍让你公司作好准备迎接变化。
第六章用好童子军和雇佣兵
充分利用你的咨询顾问
为什么你总要有咨询顾问
如果你有过自己试着修车然后又放弃再把车送到汽车修理厂的经历你一定会注意到罗伊和艾尔正在摇头相视而笑。他们中有一人肯定会说你应该首先找他们帮忙。
几天以后你会驾着修缮一新的汽车驶出修理厂回到你原来的生活中。罗伊和艾尔会已将车修好你也会付给他们修理费但是你不会学到罗伊和艾尔的技术。如果车子再次出故障你还得去找他们。他们还会作同样的修理工作你还得付同样的修理费。
同SAP咨询顾问们就不应该是这样了。是的你会需要他们但是你不应该永远需要他们。如果罗伊和艾尔是SAP咨询顾问他们将不仅为你建立起系统而且还会教会你如何自己建立系统。一旦你掌握了其中的窍门罗伊和艾尔就会悄然而退而不会再向你收费了。
关键的一点是你需要得到局限于a) 提高和 b) 知识转移的技术指导。
即使你动用你公司所有最优秀的人员将他们百分之百地用于实施项目在没有外来帮助情况下你仍然不会成功。你可能在其他地方看到有资料说有些公司在极少的咨询帮助情况下顺利走上SAP之路。你仔细阅读一下你就会发现这些公司做过以下的一件或者两件事
· 只实施了非常有限数量的模块例如 FI 和 SD
· 在SAP培训方面大量投资
打断你现有的正常业务比聘请咨询顾问在SAP实施的初期阶段助你一臂之力要冒更大的风险花费也更多。你追求的是在发展和干扰之间找到一种平衡。一个简单的提示短期中断业务不如你想象的那么破费那么重要。
稀少、昂贵而又捉摸不定的人们
1993年R/3发布后SAP在北美的舞台上迅猛发展。同年汉默和钱匹的《重组公司》引起了风暴性大火般的轰动。没有合理的系统支持重组无法成功而SAP明显地被看成是最合适的支持。《幸福》五百家公司中有许多匆忙地签订了SAP许可证但当他们四处寻找时却发现整个大陆上几乎没有具备SAP经验的咨询顾问。
四年过去了有经验的SAP帮助仍然求大于供。一些只有不到一年SAP经验的人要求每小时150或更多美元的报酬这使得用户的不满程度逐年上升。
据估计在1997年对SAP咨询顾问的需求量将超过20,000人。这是根据在过去两年中SAP每月售出大约一百张许可证和每个实施项目持续一至三年的事实基础上估算出来的。根据这个计算目前在北美大约有二千五百家公司正处于不同形式的SAP实施过程中其中绝大多数公司是大型公司。
估计有经验SAP咨询顾问的数量不是件容易的事。将所有咨询人员混为一谈也会产生误导作用。能提供咨询的人员中有项目经理、集成专家、Basis权威以及专长于 FICOSDMMPPHRPM 等领域的咨询顾问们。在1996年以前有大约一千个实施项目因此有经验咨询顾问的人数增加了六至八千左右加上在此之前的五至六千有经验咨询顾问总人数大约在11,000至14,000之间。我们猜较低的那个数字可能更真实一些。
要找到具有两年以上丰富SAP经验即具有设置技术又有业务水平的北美咨询顾问不是件容易的事而找到具有以往产业背景和真正咨询经验的SAP咨询顾问则更难。
SAP咨询顾问来自何方
在这所有之中最重要的一个词是“经验”。这些咨询顾问能把什么样的经验摆在桌面上每个星期我们公司都会收到许多充满着诸如 FISD 或者 MM 等SAP缩略语的简历我们不得不用放大镜来仔细分析这些简历的内容。我们的行政助理埃丽很耐心地回答那些想在SAP与Rap音乐恰好同韵领域找份高薪工作的应征者打来的电话但第一个隐约的感觉是他们所吹嘘的经验不怎么真实。也有些应征者声称他们具有一年或者更长时间的SAP经验但是面试的结果显示他们只是来自于一家正在实施SAP的公司而他们本人并没有直接参与。
为什么如此众多的人们以SAP咨询顾问的身份介绍自己这里有一个简单的原因。环顾一下正进行SAP实施的工作区你就会发现有关SAP咨询花费巨大的剪报被粘贴在墙上。这里SAP和金钱是同义词。
有一次在曼哈顿的街上有人向我推销一只值五十美元的钻石戒指。我问那推销员我是否能用钻戒在旁边的大理石柱上磨擦一下。他问为什么我回答说我想看看钻石是否是真的。他很恼怒地问谁在谈论“真的”还是假的问题。
SAP是一股经济旋风因此吸引了所有想趁机往上爬和迅速发财的人。正因为如此SAP咨询顾问的来源远远多于可以想象的数量。事实上北美的SAP市场上充斥着假冒内行造谣撞骗和拐卖人口之类的不良之徒。知道咨询顾问真正来自何方十分有用这样你就能更好区分出玻璃和钻石。
1. 转行的信息系统咨询顾问。
要不了多长时间咨询公司就能看出SAP能变成运钞车所以许多公司将现有的信息系统人员转向SAP来获得SAP实践能力。
很快就能想到的是信息系统专业人员是从事SAP咨询的当然候选人但这并不完全正确。正如我们已经强调的SAP实施成功要求的是业务知识而不是技术知识。来自信息系统领域的人员如果他们的强项是技术而不是业务他们可能不会在SAP中成功。文件设计、编程规格和编程本身是技术问题在SAP领域中几乎不存在。
相对而言那些在战略计划、功能设计、用户协调等方面有专长的信息系统专业人员经常能在SAP项目中找到对他们有用的位置。
2. SAP实施小组成员
现在有许多SAP咨询顾问来自曾经实施过SAP的公司。其中一些人是因为实施项目被替换下他们的老位置后投入到咨询业。另外一些人注意到了在他们项目中工作的SAP咨询顾问收入很高一旦他们能够在简历上填入“一年SAP经验”后就跳离了原公司。
这些咨询顾问的情况比较复杂。他们只是在一个环境中即在他们的老公司里有过SAP经验。一般来说由于他们对自己公司的情况较熟所以在自己公司开展项目不成问题。但是当他们突然降临到你的公司由于对业务环境不了解可能就不会那么灵巧和有效率了因此他们的进行速度就会很慢。
SAP咨询工作中有三点要素
· 产业背景
· SAP知识
· 咨询技巧
咨询工作可以被做成一种让人高兴的事在此过程中咨询顾问会觉得有义务让所有人都满意即使这是以项目成功为代价的。直接来自企业的咨询顾问是咨询方面的新手他们经常会认为“满足用户”就是目标而实际上“为客户服务”才是真正的目标。有能力仲裁、描述、教育、说明、谈判、妥协、提供文件和进行决断是SAP咨询的要求只有经验才能提供这些能力。
这并不是说要避免使用这样的咨询顾问。相反他们经常比老资格咨询顾问更能站得住脚。你要谨慎的只是仅有SAP经历的人并不一定就能当咨询顾问。
3. 工程师
在最成功的SAP咨询顾问里找到大量来自工程领域的人们已不再令人惊奇。SAP成功的核心是“怎样干才可行”而工程师由于以往的经验和受过的培训在“怎样干才可行”方面富有天份。他们不会像依赖工作流程那样依赖信息技术这对他们是有利的。
如果你发现一位SAP咨询顾问具有产业背景、一些咨询经验、扎实的SAP知识以及工程师的出身你应该即刻与他或她签约尽快把他或她留下来。
4. 学校培养的咨询顾问
这是一类应该避开的咨询顾问这不是因为他们在专业上都干得不好而是因为在聘用他们前很难估计他们多有效率。Big 6公司有许多这样的人员任何相信使用“新手”的大型咨询公司也是如此。在你的项目中以大幅度降低的价格接受这些人员是个不错的主意。许多人会证明是物有所值但也有些人是在用你的钱获取经验。如果在你实施小组里每五位老资格咨询顾问中有一名以上这样的人员你就应该象通常对待那些你不想给小费的糟糕侍者那样狠狠地瞪一眼你的项目经理。
5. 来自欧洲的咨询顾问
R/3的发布没有在欧洲引起核爆炸似的风暴性大火因为SAP的R/2已得到广泛的实施。例如1993年德国前500家公司中约有70%签订了SAP许可证。你可以想象整个欧洲会有多少。
因此在欧洲的咨询人才要比在北美大陆的多得多而且更富经验。他们中许多人一直从事着这个版本SAP的实施工作他们的知识和经验是极其有益的尤其是他们较具深度的经验。
但是另外一方面欧洲人的咨询技能并不总能适合北美的需要。由于文化背景不同实施方法在不同的国家里也会不尽相同而且实施工作是由集体而不是由个人完成的。一位欧洲咨询顾问曾经对我抱怨说美国人充满幻想不愿正视现实。他所指的是我们偏好于获得全公司的一致赞同而不是全公司的一致服从。我劝告那位咨询顾问要学会有耐心不要使用“充满幻想”这个词而要用“随心所欲”。
许多欧洲人指出SAP的基础是最佳业务实践的集成但是北美公司经常忽略这一点他们实施SAP是为了使其适用于他们独有的业务实践。固执地追求个性化是美国人的特点延伸到了公司和公司的经营方式我们坚持自己的“独特性”确实与SAP的原则背道而驰。欧洲人追求的是如何循规蹈矩而我们追求的则是改变现状。欧洲咨询顾问如能明白这些可能会极大地成功不明白这些则会焦躁不安很可能会失败。
总结
在继续讨论“经验”问题时我们觉得有必要再告诉大家有一种被引入歧途的SAP经验的势利态度正在广为流传。一些只有一年SAP经验的人经常会看不起所有比他们经验少的人仿佛单凭SAP经验就能使一个咨询顾问提升到拥有骑士头衔的贵族。这种态度的部分起因是SAP“顾问学院”现已废除带来的后果。在这样的“学院”里学员经过六个星期的SAP培训将被“证明”是SAP咨询顾问。这些学院从一开始构想就有问题而且管理上很糟糕许多已被“证明”的学员根本是不合格的。
引入歧途的这种势利态度其另外一个产生原因应归罪于SAP本身。从1995年中期开始当时SAP已成为商界和信息系统媒体中最巨大、最显眼的角色对于术语的重新定义突然变得规范起来这与谁能或者不能代表
真理有关。什么是SAP这个概念陷入充满迷雾和疑惑的境地。我们当时有这样的印象即只有SAP的员工才具有随意处置的真理。请原谅我们摘用蒙迪派森喜剧团的一段台词一位苏格兰父亲向他儿子解释他的帝国是如何兴起的
父亲听着年青人。我在一无所有的基础上建起了这座王国。当我在此开始时这里只是一大片沼泽。其他国王们说我在沼泽上建城堡是愚蠢的。但我还是造了就为了让他们看看。我们同六大会计事务所签约使其成为实施伙伴城堡陷入了沼泽所以我又造了第二座。我们又增添另一家大型咨询公司的资源那座城堡又陷进了沼泽。于是我又造了第三座。由于受到SAP新的压力第三座城堡烧毁了倒塌了然后陷入了沼泽。但是第四座……使用富有SAP经验的公司矗立起来了。那就是你将得到的城堡年青人那是建筑在这些岛屿上最坚固的城堡。
──选自《蒙迪大蟒和圣杯》
在具有SAP经验之前拥有在产业和咨询方面的专业经验将为SAP经验增添分量。你应该对那些在SAP经验之前只有不到四年产业经验的简历不屑一顾。当然凡事总会有例外天份不是由上帝平均分配的专业素质也是如此。明星总是那些剧团的主要演员而跑龙套的总是得不到足够的尊重。
从总的意义上讲咨询顾问现在已与以前不同过去的咨询顾问能够为你带来即刻启示和快速投资回报是具有一长串成功故事的重量级、老资格人员。而现在咨询顾问最差情况下只是比你领先几个月最多也只是些头脑清晰、富于责任心、能与你共享技术的人员。
我们最诚恳的建议是避免两个极端一是主要依赖于学校培养的咨询顾问的大型咨询公司二是靠炒作SAP合同从每个咨询顾问头上每小时收取10到20美元佣金冒充内行的中介机构。两者都不是以伙伴的关系与你合作都在诈取你的钱财所以要小心。
选择你的咨询伙伴
你公司的规模和所在地在你选择咨询顾问中起到一定的作用。如果你在一家拥有数十亿美元的大企业你的项目主要将在大城市里进行那么你就可以找到从大到小各个专长于SAP的咨询公司。但不管怎样你不要期望能在任何一家公司中在你需要的时候找到你所需要的所有咨询顾问。合格咨询顾问的供应目前还不能满足需求。另外SAP咨询顾问不是全才。如果你打算实施 FISDMMPP 和 HR你可能需要寻找具有这些领域技术的顾问。
所以选择咨询伙伴的第一条原则就是仔细考察被推荐的咨询顾问而不是仅仅看推荐他们的公司。你应该面试每一个咨询顾问以确定他们是否是合适人选。如果主持面试的人员有一些SAP知识会有很大的帮助。我们建议你聘用另外一个咨询团体协助你进行挑选。这个咨询团体应排除在实施伙伴的考虑之外以保证他们的推荐是客观公正的。
面试候选咨询顾问也会帮助你避免一种“虚晃一枪”式的推荐方法。有些主要的咨询顾问在提议阶段极力炫耀他们的公司卖弄他们的SAP舞步但是在项目开始时他们本人将不会出现在你公司门前与你共舞。
另外你也必须现实一些。1996年春季我们收到了许多在人事方面要求帮助的请求。几乎所有这些请求中都包括了这样的附带条件即咨询顾问必须在3.0版上有至少一年的经验。这样的人员根本无法找到原因很简单3.0版才刚刚发行了大约五至六个月尽管如此许多客户还是坚持要有一年的3.0版经验。
大多数咨询公司会吹嘘他们具有项目管理、咨询顾问和成套的实施方法。请仔细看一下最后一项因为根据它的内容你项目的成本可能会大幅度上升。后面对此有更多的介绍。
你的审计伙伴和SAP蛋糕
所有有一定规模的北美公司都会有一家审计公司为其服务这些公司中许多开展咨询业务。由于SAP与金钱的紧密关联它们中许多会向你推荐咨询顾问。这些公司具有竞争的有利条件因为它们预先知道你的业务和你的人员。他们还具有挥舞在头上的审计大棒。
让这样的公司成为你SAP实施的伙伴是诱人的因为你可以避免在你的办公室里有来自不同咨询公司的人员走来走去。如果不是因为没有一家咨询公司拥有所有你需要的咨询顾问这一事实的话这样做还有些道理。此外来自你审计公司的咨询顾问要比来自其它地方的咨询顾问更容易接近你的高级管理人员他们能影响你在项目和使用咨询顾问方面的决策尽管他们并不是聘来做这些事的。
根据优势来评估咨询公司是更有道理的做法。他们能否提供合格、有经验的实施者他们提供的实施小组是否根据你的需求或者标准做法进行了调整他们能否提供适合你业务环境的项目开展方法
不管你有什么打算你肯定会在项目进行的全过程中感觉到你审计伙伴的热情尤其当你的实施项目是委托给一家同样开展审计业务的咨询公司。
无论在哪种情况下你都应该注意观察咨询
伙伴的费用。这些费用通常介于每天3,000美元至5,000美元之间。你能得到回报的价值经常是值得怀疑的比如他们花时间在你的工地上竭力使他们的咨询顾问发挥咨询的潜力他们花时间同你空谈所谓的“项目进展”。如果在建议中包括每五十个其他咨询顾问日中需要多于一个“伙伴”日你就应该仔细审视建议中其他涉及到费用的部分了。
你的项目经理第一号决策
在SAP实施项目中你要作出的单一最重要的决策就是谁将成为你的项目经理
项目经理
· 是项目计划的主要设计者
· 要为完成项目计划、分配和安排资源
· 要掌握和协调项目过程的节奏和方式以及实施小组的凝聚力
· 要管理努力的范围
· 要妥善处理用户和管理层的期望和要求
· 要决定资源的来源和使用无论是内部还是外来的。
项目经理必须是每天项目的监管者以保证你希望的目标能最终实现。正因为如此你需要相当肯定这位经理会陪伴你直到项目结束。此外在经理和高级管理层之间应该存在一定的信任当项目经理来自于外部即一家SAP咨询公司时就更应该这样。没有这样的信任高级管理层会经常怀疑项目经理的做法是出于客户的利益还是出于咨询公司的利益。
在你经历选择项目经理的过程时要注意项目管理是咨询公司竞争的战场。提供项目管理的公司将会在以后因为“成功的实施”而赢得声誉。更确切地讲这家公司将会在咨询顾问的来源和安排方面具有举足轻重的影响。
即使在你已经选定项目经理以后他或者她也将成为来自内外批评的目标。有些批评是正常的因为那是对项目所包含变革的自然抵触情绪。更多的批评将来自于另外一些想安置他们自己项目经理的公司。如果你在高级管理层有权决定由谁来管理项目你就应该分析攻击你项目经理的那些人们的动机并相应地采取措施。
给你的项目经理配备一位内部助手也是个明智的做法。这位助手应是你自己的人员他将最终掌握应有的知识接替经理之职而原先的项目经理则退到一个顾问的地位或者干脆彻底消失。
大部分实施项目的命运兴衰取决于项目管理的质量以及高级管理层和项目经理之间的信任程度。
由多个伙伴组成的咨询队伍
前面已经提到几乎没有SAP实施项目在只有一个咨询公司的帮助之下开展的。咨询顾问求大于供的现状决定了客户将需要从两家或者更多公司中聘请咨询顾问然后寻找一种将他们集中在一个咨询队伍中方法。
来自不同公司的咨询顾问在一起工作可能会有许多困难。他们之间的不同有技术上的也有门户之别。你必须进行处理尽快消除这些差别否则你的项目会走向歧途。有些客户将不同的子项目分配给不同的咨询公司使他们各管各工作以避免各小组之间的磨擦。但是由于集成的缘故这不能做到百分之百完美无缺。如果一个咨询小组在设置FI另一个小组在设置SD再有一个小组在设置MM, 这些应用程序的最终集成将会是困难的。
比较可取的方法是将咨询顾问们混合在单个有效率的队伍中设定所有相关人员必须遵循的唯一的项目方式并反复强调让所有人员明白项目属于客户不属于他们各自所代表的公司。
如果咨询顾问中谁不尊重你的指导方针谁过分坚持他们自己公司的方法和习惯做法他们就应该被清除出项目。那些具有较强合作技能但SAP技能相对较弱的咨询顾问要比那些具有较强SAP技能但合作技能相对较弱的咨询顾问更可取。
七个告诫
应该由你决定而不是咨询顾问的决定你从他们那里接受帮助的程度。你可以把来自不同公司的合格咨询顾问一个一个地放在他们各自合适的位置上来调整你的项目队伍。也可以把一大批咨询顾问都放在一个出问题的地方期盼产生最佳的效果。那些把实施失败归罪于咨询顾问的公司应该从内部找找原因。以下是一些你在安排队伍时应该注意的问题。
告诫一
咨询顾问可能不象宣传时说得那么富有经验他们正在花客户的钱来接受实习培训。
这个现象在北美的SAP项目中是经常出现的。原因之一是因为SAP在这里是相对较新的系统有经验的SAP咨询顾问很难找到原因之二是对于具有真正SAP经验咨询顾问的巨大需求将费用抬得更高。贪心已在太多的地方出现许多根本没有经验的咨询顾问被推进了项目推上了他们无法成功的位置。
该怎么办
在允许参加你的项目前面试所有应聘的咨询顾问。如果你对SAP知之甚少聘用咨询顾问协助你进行面试工作但是不要只“让专家们去干吧。”
告诫二
从事管理的咨询顾问可能会提议进行开始看来很诱人但对定义后的项目没有实质性价值的附加开发活动或子项目。
同样不幸的是项目超期对于某些咨询公司最有利。项目持续的越长咨询费用就越高。不管是有意还是无意咨询顾问可能会拓宽或者改变项目的范围尤其是在长期项目的进行过程中在这个过程中用户的处境不断地在变化。
该怎么办
在项目的范围内评估新的提议而不应孤立地只看这些提议的优点。用SAP开发工具你几乎可以做任何事情在项目过程中的附加开发提议通常是为了针对扩展功能。你应该接受那些在财政上有意义的提议而拒绝接受那些具有“要是那样该多好”式的提议。
如果新的提议涉及解决诸如用户或管理层阻力、教育或者交流之类的问题你应该予以高度重视。尽管这些问题可能要求你专门为此安排时间和资源甚至对项目计划和预算都有损害但是对于项目的整体成功却是有利的。
告诫三
大型咨询公司通常有它们自己内部的成套方法尤其对于系统项目。
有时客户要为使用这些成套方法而付费。如果该套方法适用于已定义了的项目这还是合理的。据我们所知对于SAP实施目前唯一存在的成套方法是《SAP实施指南》而其本身也是不完整的正如其名所示是“指南”而不是“成套方法”。其它的成套方法是针对传统设计、开发和实施项目的并不能有效地运用于SAP实施。
该怎么办
如果成套方法是由厚厚的、多卷装订本中的表格和脚本组成你应该费时认真通读一下评估咨询公司对于项目的做法需要有多少SAP知识转移在什么时候以什么样的深度进行差距分析AS-IS阶段是否被看成是漫长的
如果成套方法仅仅涉及到一些文本类的内容这很可能是传统成套方法的一个修订版本应该予以抛弃。
从另外一家咨询公司征求意见也会有帮助。就如同面试阶段一样这必须是一家会提供客观意见以及诋毁被推荐的成套方法对它们自己也没有任何好处的公司。
你应该避免的是这样的项目它能完成成套方法中描述的步骤但不能实现你的项目目标。即使有些可接受的成套方法也会要求进行一些对于确定项目来说不必要的活动和工作。应该在整个项目进行过程中而不只是在开始时根据你的项目范围对成套方法作相应调整。
告诫四
在聘用一个以上咨询单位时会产生在选用项目方法和工具方面的冲突
旨在证明一种方法比另一种方法更可取的项目任务对于已经确定了的项目不会增加多少价值。
该怎么办
如有多个伙伴公司参与实施工作必须指定其中一个为主要伙伴必须确立唯一的项目开展方式。如果其他次要伙伴不遵循已确立的项目方式就解雇他们。多个伙伴不应当把你带向多个方向。
告诫五
客户在项目范围之外可能会依赖于外来咨询顾问如果SAP知识没有从咨询人员那里转移到客户人员。
非常有能力的咨询顾问可能经常会为了节省时间和提高效率独自完成工作。如果没有足够的SAP知识转移外来咨询顾问在公司出现的时间可能会大大延长至确定的项目完成以后
该怎么办
本书中反复提到你应该从一开始就对知识转移作好规划。如果你的员工早已接受了足够的SAP培训已经能够掌握咨询顾问的那部分项目工作你就可以放心了。但是如果没有进行过认真的SAP培训那么你对于咨询顾问的依赖将会是危险的而且很难估计很难以结束。
应该保证你的人员正在咨询顾问的指导下进行着真正的设置工作对此唯一的例外情况是中型公司经常做的不在场设置。但是即使如此你的人员也需要知道在最后实施前已经做过些什么。
告诫六
项目可能会超时客户经常想知道超时是由咨询顾问还是由它们自己人员造成的。在有些事例中超时是因为在主计划中对客户员工过于乐观的安排在另外一些事例中是因为咨询顾问的错误或者疏忽。咨询顾问一般认为原因是前者。
该怎么办
作最坏的打算把超时考虑在内。超时现象发生后应该检查客户员工是否按批示完成了工作如果没有让咨询顾问休息一会重新组队然后再开始。
告诫七
在一个长期项目开始的时候项目计划是根据期望和以往的经验制定的。在长期的过程中许多原先计划的任务变得毫无意义但还是被执行了因为它们包括在计划之中。咨询顾问可能会把完成这些任务看成是完成合同上的义务。
该怎么办
取消这些任务通知咨询顾问你这样做了以及这样做的原因然后重新安排资源。
咨询顾问应该为你做什么
咨询顾问提供SAP经验以缩短用户和信息系统的学习曲线加速项目完成。他们对于这样广度和深度项目的经验会降低项目的风险。咨询顾问提供项目进行方法、项目跟踪和执行项目的技术他们了解SAP所固有的方法和工具。
咨询顾问应该被充分利用不仅仅帮助实施系统而且通过完成
知识转移帮助公司向SAP环境的转变。要成功地实现这样的转移应该考虑到每一至三名内部人员配备一名咨询顾问要牢记一旦知识转移完成后咨询顾问将从公司消失。
如果在第一天正式使用SAP之前的某一时候你公司的员工已经能在SAP设置和业务模型化方面的使用和技巧上做到信赖自己那么你就可以总结说聘用咨询顾问是明智的举动。然而,如果你的公司还是继续依赖于咨询顾问这要么是咨询顾问失败了或者在项目上墨守他们的主张要么是你还没有取得足够的知识转移。问题也可能只是因为公司内部员工没有接过驾驭的缰绳还是让专家们掌握着。
你要知道咨询价格
最基本的、能干的SAP实施咨询顾问将花费你大约
· 按每小时计算的价格
· 每周两次搭机旅行的费用
· 两个晚上旅馆住宿费
· 八到十餐的伙食费这取决于他们的早餐习惯
· 可能一辆租借的汽车及其它一些费用
你得应付这些。
更高层次上的咨询顾问除了上述费用外还得让你为一流咨询顾问多付25美元/小时为管理层级别的咨询顾问多付50美元/小时可能更多。你也得应付这些。直接面试这些人员参看有关面试的章节但当你找到你需要的人才以后爽快地付钱吧。最终的费用不在于这些咨询顾问而是取决于你的项目方向以及你如何使用这些咨询顾问使他们物有所值。我们定期同与我们结成伙伴的咨询顾问交谈经常发现他们的才能由于糟糕的项目管理而浪费了因此我们尽力重新派遣他们去一些合适的项目即方向明确的项目。
请你仿效一位SAP实施咨询顾问的生活规律
周一上午 很早、很早地起床比如在早上4点到5点去赶一趟前往工作地点的班机。
周一中午到达你的工作地点赶上你一天中最早的三小时。
周一晚上 仍然在赶时间很可能为此而揪头发试图弄明白在飞机上的时候他们错过了什么。
周一深夜在旅馆的房间里。奇怪的伙食桔黄色的长绒地毯。
周二凌晨 淋浴准备睡觉。倒在地上躺在那里睡得又香又沉......
.......周五早上自从周二上午到达你公司以来每天工作十到十二小时。旅馆房间里依然是那糟糕的桔黄色长绒地毯有时更糟比如早餐没有准备好或者旅馆没有打电话叫他们起床。打好领带梳好头发或者抹上些胭脂穿上平底便鞋或者高跟鞋或者是双网球鞋直奔你公司。与此同时你的项目因为内部差劲的管理和几乎肯定是因缺乏SAP知识和背景正乱作一团。于是你的咨询顾问就得尽力将支离破碎的烂摊子收拾好因为他们不是到这里来浪费时间的。你的项目最好能符合要求因为他们有比在差劲管理着的项目上浪费时间更好的事情要做。如果是这样他们就会......
......在每周五中午时分飞回去一边在想你见鬼去吧这样想不无道理。
注意在这段时期咨询顾问是远离家庭为你的公司整整服务了一周。你盯着的是价格而咨询顾问从星期一晚上开始后的这个星期里努力看着的则是你。
重复一遍不要把咨询顾问当作雇佣兵来看待。和他们拥抱同他们结合指给他们看咖啡室在何处花些时间让他们熟悉他们即将投身的项目阶段。给他们一个星期左右的时间去感觉一下他们应该完成的任务花一整天向他们解释整个项目的目标这样做你就给予了他们为之工作的前景。你并不因为掌握着支票簿就占有优势。你只是客户而不是主人。
这看起来象是个简单而又愚蠢的建议事实上它不是。我们经常看到这样的情景咨询顾问经过面试、挑选和确定后被贴上标签送往客户的公司。在那些客户的工地上咨询顾问在付给了以小时计算的高额报酬同时只分配到很差劲的工作而且几乎没有任何可以衡量的成功标准。这种情形对于客户和咨询顾问都是不利的。
如果你没有将咨询顾问引导至正确的工作道路上如果你没有在你员工的教育方面作投资以便能在一定的时间限制内向咨询顾问说再见你向咨询顾问支付的报酬都将更多持续时间都将更长。
费用问题就谈到这里。接着你将如何运用你买来的资源呢咨询顾问的职责比如怎么雇佣他们怎么使用他们应由你决定而不是由他们自己决定。
第七章分清南北
如何避免走入通常的失败怪圈
差距(GAP)分析的陷井
在我们前一本书《迎接旋风SAP世界初学者指南》里我们对过于着迷于“要求的”软件和现有的软件之间百分之二十差距的现象郑重地提出了几点看法
“.... 人们认为没有任何软件包能符合80%以上公司的要求于是剩下的20%你公司特有的难以捉摸的要求必须要重新设计和独立开发。
许多公司因为过于注重那20%部分往往不能顺利地进行新软件的购买工作他们没有注意到80强有力的新解决方案将如何提高公司经营这更宽广的前景而只是等待或者试图找到一种全能的软件包。”
关键在于许多公司先规划出他们的要求然后再去搜寻能满足他们要求的软件。他们从来就找不到100的解决方案通常他们只能找到80的解决方案。
在这个时候差距分析开始登场亮相了。它是那欠缺的20功能的对象。按照传统系统的做法你会抵御不了诱惑自己设计出一套规范并开发软件以填补所选软件与欠缺功能之间的空缺然后将它塞入你最终的系统解决方案之中就仿佛 8020100。
困难是当你已
· 确定了差距
· 设计了填补差距的补丁软件
· 编写完填补差距的补丁软件
· 实施完另外的80以及
· 实施了加上补丁的20
......以后与此同时你的公司和业务环境也已发生了变化。那20%部分将会转变成新的内容完全变成了另一套差距。
对于这难于捉摸的20部分的追求永远存在。这对那些从事信息系统工作的人来说是每天出现的挑战。
进行适当的差距分析很难要拿出能填补差距的能保持一段时间的设计更难。即使最终的系统百分百地满足你的要求你也很清楚你的满意不能持续很长时间。如果想获得百分之百令人满意的系统即使是一分钟也得让时间暂停一会儿才能实现。
这样的情形如果出现在SAP实施中将要糟糕上n 次方。SAP是巨大的它的巨大规模本身就使得进行和维持真正的差距分析不能如愿以偿。尽管这样还是有许多项目经理在不真正了解SAP的情况下在项目中某一时刻进行这样的分析。
在一段很长但不太舒服的日子里我们有五、六名较好的咨询顾问参与一项大型实施项目。另有五、六家较大的公司更加牢固地盘踞在客户的工地上。其中有两家公司经常派他们的咨询顾问来与我们的人员见面询问SAP是否能实现这个或那个业务要求。我们的咨询顾问尽其所能回答那些问题然后他们的面试者就飞快地跑去告诉客户SAP不能实现他们的要求于是新的条目被加入了“差距分析”。
实际上客户和在前线的咨询顾问都没有足够的SAP经验来提出这样的要求。但是实施伙伴的成套方法坚持在项目的这个时候进行一次差距分析。分析在一个为期三年项目的第四个月开始了当时客户还茫茫然什么世面还没有见过。尽管如此大量的差距分析工作和其它一些不明确的工作开始作为子项目进行起来目的是填补那些差距就好象木胶能填补白蚁留下的空洞一样。
随着项目的进行前线的咨询公司被其他具有真正SAP经验的咨询顾问包括我们的人员所替代。据发现大部分以前被确认的“差距”是由错觉产生的为填补它们所进行的子项目纯粹是浪费时间和金钱。
问题出在客户和最初的前线咨询顾问存在着知识的缺陷。
SAP本身不可能弥补所有的缺陷。作为一个可以设置的软件目前仍只有一种版本它不能全面地为每一个客户服务。例如看一下你的物料主控文档你的担忧可能会变得极度的恐慌。当你开始设置系统时你会发现实施套件中的关键部件根本不在那儿。你是选择用附加件用ABAP编写的补丁软件还是购买额外软件这当然要求编写接口来替换这些部件将取决于这个差距有多大。
这里需要告诫你在实施项目开始之初的几个月里你很难确定许多这样的差距。在获得该软件之前你肯定无法确定这些差距除非你在SAP教育方面已作大量投资这样你的知识差距已经被缩小了。
强有力的咨询帮助将在这方面节省你的时间和金钱。有经验的咨询顾问能确定在你所要求的和SAP能提供的之间的真正差距。缺乏经验的咨询顾问可能只会搔着头向你建议使用ABAP编程这将导致以后维护上的麻烦。
另外一个告诫如果你询问负责促销的SAP代表即将到来的SAP升级会不会弥补现已发现的缺陷时他们的回答很可能是肯定的。这也许是真的因为SAP的功能正以很快的速度被不断扩展和提高。在你期盼一次能弥补你功能缺陷的升级之前以书面的形式向SAP作一次询问并要求得到回答。
三百个艾丽丝或者协商差距
你是个销售与分销SD模块的负责人你的任务是将SAP呈现给销售定单处理负责人艾丽丝。艾丽丝在公司工作已有多年曾在三个不同的信息系统上工作过。她了解自己的业务了解她的系统她对所听到的有关SAP实施项目的消息并不怎么喜欢。
除此之外有人告诉你艾丽丝不怎么喜欢你。
她来到你办公室你请她喝咖啡但她说更喜欢茶你俯身看笔记而她却看着她的手表。你不禁注意到她的胸前衣领上别着一只印有公司标志的徽章。这种徽章是公司最高行政主管颁发的用于奖励长期服务于公司并且劳苦功高的员工。当你打开桌面上的电脑时艾丽丝问这是否需花一上午的时间。你紧张地笑了笑开始演示用于定单输入和确认的现有原型系统。在另一个屏幕上艾丽丝打开了现在的系统。随着你描述新的定单输入处理艾丽丝将现有系统同你的原型作了比较。她列举论点的速度要比一台数字式弹子球游戏机在奖分灯闪亮时还要快。你的SAP系统要求她经过两次屏幕显示和一次询问而她现有的系统处理同样工作只需经过一次屏幕显示。在她现有的系统中定单的目期是在屏幕的左上角而在你的原型中日期呆呆地处于中央。她现有的系统包含了一个四十个字符的“笔记”区域她认为这是她成功的关键。而你的原型没有供笔记的区域而且你由于慌张忘了指给她看内置的有关该软件所有方面内容的文档子系统。
在以后的几个小时你结结巴巴地向她介绍了各种功能。但最后她提出与你比赛结果她在你输入三份定单的时间里输入了五份订单。
你该怎样对付艾丽丝你是否应该回到项目会议室用ABAP编写的补丁软件来更改草图中的内容艾丽丝是否真的指出了一系列必须解决的缺陷了吗
根本不是这样。艾丽丝所做的无非是在展示她对现在时态的掌握现在时态是垂直的、各自独立的、注定是要消亡的。她在维护她的销售定单输入而你代表的是工作流。
我们在我们主办的专题研讨会上讲了这个故事。最近有一位学员突然回答道“我们公司有三百个艾丽丝”。不管你公司有一个还是一千个艾丽丝我们对你的建议是教会他们享受工作流的乐趣。你应该充满自信坚持你的主张。你追求的是一种前景而艾丽丝是在重复过去的经历。
不要停留在对一些次要处理的比较上。同艾丽丝谈她在通讯和汇报方面的要求你会发现她
· 每周写报告给财务人员要求获得有价证券财产目录
· 每天接到十几只来自信用部门询问各种客户信息的电话
· 用她自己编写和维护的电子表格每月准备一份根据地区、产品组别和销售代表分类的销售定购活动报告
· 要对一半以上的销售定单作修改因为她的系统不提供足够的产品数据用于即刻处理确认了的定单
· 要定时给客户打电话以保证他们收到了定单收到通知书以及计划中的交货日期是可行的
你的原型应该能解决这些问题这些问题应该成为你和艾丽丝之间的话题而不只是简单的如何将定单输入系统之类的处理。不管怎样你很可能会发现电子数据交换EDI将极大地减少输入的工作量。
你千万不能把艾丽丝所有的反对意见都记下来然后逐条编入修改计划中。在许多情况下艾丽丝需要的是编程而不是SAP。她需要知道一旦SAP实施完毕她只要集中精力对付例外情况而不必关心简单、明显的基本流程SAP以它的集成方式会向那些目前打电话来窃取她脑力劳动成果的人提供数据。艾丽丝必须明白她在你公司工作流循环中所处的位置她必须接受一些新的东西才能在付出时获益。
SAP真的能以一种不能令人满意的方式满足成千上万种日常工作的要求。对于一些次要的流程人体工程学经常是不被认真考虑的。这是紧密集成着的软件的一个弱点也是咨询顾问和其他实施者每天感到困惑的地方。我们听到过这句话的许多种不同的说法“SAP有时真讨厌但它确实行得通。”
困难的是艾丽丝变成了路障而不是个过程。让我们来解决这个困难艾丽丝们以各种形式出现。有些只是需要教育一下了解工作流的不凡之处他们就能成为你这方的同盟。而另外一些人对工作环境的变化感到困惑和恼怒他们会用那些次要工序上的比较结果攻击你使你的项目无法正常进行。如果你屈服了开始对SAP过于不经意了你很可能会让艾丽丝平静下来但与此同时你在项目上却增加了不必要的开支而且系统的维护也将会更长。
从垂直的角度转变为从水平的角度看问题对任何人来说都需要时间。对于象这样的实施顾客现在可能是正确的但在将来肯定是错误的。如果可行可以作些外交式的让步如果有可能要考虑到人体工程学但是在工作流这点上你要坚持原则。
AS IS──或者“我们过去的做法”
相当多的SAP实施包括了这两个阶段AS IS意即照原有的样子指不作修改或改进和 TO BE意即即将变成的样子指经过修改或改进以后的情况。在我们公司里对于SAP实施中AS IS阶段是否有用一直有争议。
对于不具备专门知识的人来说AS IS阶段以前用过较长的词语“目前状态分析”是一个客户的所有或部分业务流程被分析、绘成图表和写成脚本的过程。实质上它是个对公司现有运行方式的完整列表。
如果能够聪明地运用AS IS阶段也有以下存在的理由
· 主要流程应该绘成图表以及
量化这样就能衡量由SAP带来的新流程的潜在利益。
· 除非你的咨询顾问对你公司的业务非常内行AS IS阶段允许咨询顾问和你内部项目队伍──通常是第一次──真正地了解你公司主要的业务流程。
· 详细的脚本并不是必需的以墙上的流程图表示出的对公司业务流程的总体了解是应达到的目标。
· AS IS 经常为 TO BE 阶段设定范围和期望目标。
· 如果你的员工参与以后的业务流程重组把业务流程绘制成图表和编写成脚本将会有所帮助把你现有的业务流程当作来源使用将为他们第一次进行业务流程重组提供一些经验。
避免因为 AS IS 而被人敲了竹杠
传统上TO BE 阶段紧随 AS IS 阶段之后TO BE 要求你和你的咨询顾问充分地设想公司的远景并将SAP设置完后能够达到的效果绘成图表和制成脚本。根据这个原理你将把 AS IS 文档当作 TO BE 的基础来使用。
大多数项目计划包含了以下的步骤
从一个设想到一个根据此设想开发的原型应用程序你以一种相当直接的方式从抽象阶段走到具体阶段。你不仅注意前面的道路而且更注意着未来的远景。除了在象块后视镜的 AS IS 阶段外其它时期都是如此。在取得了你公司将转变成什么样的设想以后你就应该以坚定的步伐朝实现目标的方向大步迈进。但如果下一步是 AS IS阶段你可能会一下子放慢进程。
如果 AS IS 阶段持续得太久而且你不仅仅是为了总体了解而将现在的业务流程绘成图表那么你的 AS IS 阶段就有些过头了。AS IS 就变成了我们称之为“咨询伙伴退休基金的筹集阶段”因为这个阶段在时间、金钱和精力方面耗费太多而且收效甚微。
在一个有些过头的 AS IS 阶段中会发生些什么呢首先你详尽列出公司中的一切你如何工作你做些什么每一步骤和工序要花多少时间和金钱等等。然后你把列表摊开指着找到的弱点在一个步骤到另一步骤之间抹去一些箭头想出你如何改善的方法。在这个阶段你从 AS IS 到 TO BE从这时到那时从熟知的现实到闪耀的未来不断在图表上涂涂抹抹。
过头的 AS IS 阶段的最后结果是你花钱请咨询顾问向你的员工询问你们是如何工作的请他们把同样的内容绘成图表制成脚本但随后不久你就要把这些图表和脚本扔进废纸篓。因为有了SAP你不再需要那样工作了。这种做法对你毫无帮助却花了你不少的钱。一旦你开始进行项目实施你的 AS IS 就变成了过去式即“我们过去的做法”了。
就如歌词中所唱的“回忆我们过去的做法是痛苦不堪的。”
因此要注意过头的 AS IS 阶段的负面影响
· 为一个过头的 AS IS 绘图表很可能比为一个合理的 TO BE 绘图表更困难所以为什么要在你打算抛弃的内容上浪费时间和金钱呢正确地使用SAP经常会显示这样的传统做法即将被淘汰。
· 你可能认为自己的公司是复杂和独特的许多人对他们的公司有这种感觉。过头的 AS IS 可能使公司看上去更加复杂而且给保守的员工提供数据使他们有理由尽量将一切保持原样。正确地使用SAP经常会使一些传统做法逐渐消失。
· 过头的 AS IS 阶段会倾向于充满着逐渐的改善而不是彻底的改进。在 AS IS 阶段没有富于创造性的内容。如果用作 TO BE 的基础你就不能以崭新的观点来看待你的业务活动。传统做法会依然存在你会发现自己只是在做些小修小补而不是创造性的工作。
正如我们前面已经讨论过的那样适当的差距分析要求预先具有SAP知识。有用的 AS IS 阶段要求有节制。如果你正处于从许多咨询公司中挑选实施伙伴的过程中你应该仔细看看他们在提案中是如何定位这些阶段的。如果差距分析很早出现在项目中或者咨询顾问提议进行详细的 AS IS 工作你要记住这点
在选择你的咨询伙伴时你是个钓鱼人。但如果忽视这条建议以后你可能会沧落为无用的差距分析和昂贵的 AS IS 阶段的鱼饵。
第八章只有你才能预防森林火灾
在SAP实施中范围之火是如何点燃的
如果你看到了冰淇淋你就想要冰淇淋
最近有一份调查显示相当多的美国人吃晚餐只是因为他们可以吃到甜食。在甜食前所做的一切都是为了打基础是必须要做的。晚餐是手段而甜食是结果。
我不属于统计中那些人的一部分。我通常关注的是开胃品、主菜以及也许葡萄洒。我从来想不到甜食除非我是在英国的饭店里用餐。在那里服务员会在你主菜吃到一半的时候把装着甜食的手推车推到你的桌旁。我坐在那里拨弄着最后的一些煮肉和土豆目光落到了呈夸张螺旋形的巧克力奶油冻上。然后转向水果鲜奶油又反复扫视苹果馅饼。我原先满足地嚼着的肉突然在我嘴里变得索然无味。我想看别的地方但双眼最后还是落回到甜食上。喂小姐这是巧克力蛋糕吗啊是巧克力薄荷味的我把刀叉放下叹了口气。请来份香草冰淇淋。
先前我可能已看到过菜单上每种甜食的名称但是这些词语本身没有激起我想吃的欲望。只有当它们放置在我面前而且时间长到足以引诱我时我才会感觉需要它们。
在SAP实施中有些你从来就没有特别想要的功能和特性同样也会不知不觉地变成了你的需要。如果你不够小心不够专注你所为之努力的方向会被各种诱人的甜食笼上阴影而难以辩别。
“范围漂移”是个常用的词语许多人用它来指不知不觉的、无法在日常工作中观察到的项目范围的不断扩大通常这是没有预计到的或为了项目成功无法避免的用户需要所引起的。
当你看到某些功能你就想要那些功能不管你是否真正需要。SAP功能的巨大广度和深度令人叹为观止充满无限的诱惑。范围上的变化不会在SAP实施过程中悄悄出现它们会当着你的面爆发开来。
SAP实施中范围之火点燃的方式
1. 你需要有一堆营火收集一些火柴。
SAP引起业务流程的彻底改进但大多数公司开始时追求的是逐渐改善。因此最初的项目范围非常有限缺乏雄心壮志需要进行扩大。
2. 你意识到如果你投入更多的柴禾火就会越烧越旺。
随着项目的展开SAP学习曲线开始出现客户发现了他们拥有的所有潜力他们需要的更多。
3. 雇用的童子军们指出了玩火的巧妙方法。
旨在改变、扩大或者改进原先设想的咨询顾问影响了公司使之偏离了最初的设想。这种情况可能是有用的也可能是有害的。
4. 部落的首领想保证他们拥有足够的火所以他们点燃自己的营火。
随着新的业务这被高级管理层所了解SAP功能等同于权力这个概念导致了新的子项目开始。
5. 一组人员满怀热情地点燃了一堆篝火后被另一组人员注意到于是另一组人员点燃了他们自己的篝火。
你的项目人员掌握了学习曲线开始在SAP功能的森林里抢夺。
6. 一堆篝火的火焰失控了所有人员离开自己的火堆去参加灭火。
项目某一部分的失控暂停了整个项目的进展。
7. 由于部落首领放逐了部落的一部分人员管理篝火的人手就不够了。
不够成熟的人员削减计划导致了人力资源的缺乏而不能应付项目范围的扩大。
8. 整个村落被烧毁了。
范围管理
项目范围的扩大是必然的如果你对此有所准备就能为了公司的利益管理好这种扩大。
首先必须要指定专人负责范围管理。可以指派一个人但是最好指派一组在项目中有足够参与的人员他们能明白业务和SAP方面的问题并在公司里有足够高的职位能理解这种高层次的设想。
随着项目的展开以及SAP学习曲线的上升所提议的范围改变应该交给有关委员会由他们在成本和利润方面对此进行评估并根据轻重缓急对照现有的设想进行衡量。范围方面的更改如果被接受必须明确定义而且广为宣传。对于以后的项目计划和预算的修订也必须同样处理。
再重复一次如果项目在你的员工和管理层还没有接受足够的SAP培训前就开始实施将很难管理项目范围因为每天人们都得看到通过使用SAP人们可能做到大量各种各样的事情。这个事实带来了诱惑而诱惑则引起了对于项目范围的更改。
管理范围的一个难点是并不是所有的范围扩展都会向上汇报。在设置阶段业务流程设计可能不是不折不扣地得到贯彻的。这可能是因为SAP并不总能以你希望的方式样样能干或者是因为你的员工发现了某个业务流程重组时没有预料到的功能他们采纳了新的功能仅仅是因为得到那个功能易如翻掌。
要记住这种功能会永远在那里不必要马上就用上它这是很重要的。这只是一个实施项目一旦项目完成你可以使用SAP时使用的范围能够而且也会扩大。
你要决定什么是你现在需要用于支持新业务流程的功能。你的需求会在实施的长期过程中发生变化但是在某些地方你必须要善于管理小规模的欲望之火不必完全踩灭沿着确定的道路走向终点。
到达终点后你可以使用SAP了很可能你还会继续根据机遇和条件增加或更改某些功能。
实际上SAP的实施永不停止。随着你业务的变化相关的SAP应用程序也会发生变化。
SAP实施中的范围因素
范围不局限于即将实施的应用程序数量以及即将需要培训的最终用户的数量。以下简要地列出了在SAP实施全过程中将影响你项目范围的一些因素。
1. 地点多地点实施很明显将比单地点实施持续更长的时间尤其是当新的业务流程跨越多个地点时所需时间就更长。即使有两个项目除了一个是单地点另一个是多地点这方面不同以外其它方面完全相似多地点的那个项目要成功也会多花费25的成本而且时间更长。
2. 用户数量这个范围因素有两个层次。第一为10位用户重组业务流程要远比为1000位用户重组简单得多。第二更加紧迫的任务是最终用户培训。但是纯粹的用户人数在范围中的作用没有象想象得那么重要因为在大多数情况下用户问题要到项目的后期才会出现。所以一家拥有1000名用户的公司除了在最终用户培训方面以外并不比拥有10名用户的公司在范围上大出十倍。
3. 业务流程一家只买卖产品而不生产和储存产品的贸易公司要比一家生产、销售门类齐全的企业需要建立数量少得多的业务流程。同样道理生产的复杂性程度也因人而异。从事石油和天然气之类的加工企业会比主要从事装配工作的企业产生更多的麻烦。
4. 应用程序FICOMM 和 SD 通常被看成是核心应用程序在所在的项目中都会被实施。第二级应用程序包括 PPPM 和 1996年成熟的3.0版引入的 HR第三级应用程序数不胜数。有些公司以线性的方式实施先是
FI然后是 SD再是 MM......。另外一些公司则一组组地实施先是 FI-SD-MM然后是 PP 和 PM或者其它什么程序。你实施的次序和组合方式将明显地对你的项目范围产生重大的影响。
5. 扩展和购买这是范围中最难的因素。因为为两者作规划时没有预先知识和经验的基础。许多公司选择SAP时看法一致把它当作“通过购买求发展”战略的解决方案。应该考虑到购买公司的起点文化以及该公司发展的曲线。
6. SAP项目期间的结构重新调整你可能会希望你公司会冻结这样的活动直到业务流程重组得以完成但这不会发生。没有办法可以为此作规划也没有办法在其发生前调整项目范围。屏住呼吸它
会发生的。
7. 实施方式“一次性完全实施”还是“循序渐进式实施”“一次性完全实施”的方式很吓人但通常比“循序渐进式实施”更容易成功。“循序渐进式实施”缓慢、拖延但同“一次性完全实施”一样具有高风险。范围问题主要在于用户和他们是否愿意转向SAP。如果他们紧紧依附于遗留系统你的范围将由于包括了对阻力的预防措施而扩大。
服务员我的牛奶太凉了
在饭店当过端盘子服务员的人都知道顾客的期望既有正当的又有不合情理的经常还会发展到荒谬可笑的地步。我在念大学时曾在圣迭哥市的一家高档乡村俱乐部当过服务员。在那儿工作的第二周有位顾客要了一份法式饮料然后大声抱怨说我没有给他一把喝“汤”的汤匙。几天后另一位顾客抗议说他的牛奶太凉了。
商业中的情景可能也会如此的荒谬。我通过给顾客他们想到的东西一把汤匙和较热的牛奶解决了饭店里的问题。这样做除了稍许占用我一些时间外没有给我的生意和饭店带来任何损失。但是如果在SAP实施过程中我们迁就提出无理或者不正当要求的高级官员就会让公司损失很多很多。
如何应付来自企业中各个层次的要求是项目经理所面临的最重要的任务之一。应付来自高级官员的要求最为困难高级官员们倾向于认为这是“一个信息系统”或者“软件”或者是“能给我们更好报告的技术玩意儿”。
高级官员对于SAP的无知在北美十分普遍许多SAP的买家在决定把公司载上SAP之车以前不会比踢踢轮胎做得更多。从签署SAP许可证和把项目交给实施小组那时起产生失望的可能性已经存在从那时起到召开第一次危机会议之间通常只有三到四个月。
处理高级官员的要求存在着以下一些障碍
· 高级官员不知道他们对SAP不知道些什么
· 他们不会花时间学习更多的SAP知识因为他们不明白SAP项目具有如此众多的细节他们把SAP项目看成是信息系统而不是业务
· 他们以为巨大的咨询费用会保证实施成功
· 他们以为超时超支是实施小组的责任
· 他们不想明白技术和信息是在业务的核心而不是外围。
我们公司为高级官员和经理们提供SAP专题研讨会。经常有人问我们是否能提供一个一天的研讨会──而不是我们标准的两天会议──因为这些高级官员没有时间参加
全部两天的研讨会。我们注意到这些高级官员们将为SAP实施支付二千万至二亿美元但他们只能抽出一天时间来参加SAP集体知识培训。这样的态度通常会延伸到项目圈子内它是歇斯底里的新闻界称之为“SAP实施失败”的头号原因。
如果高级官员们没有被坚定地导入实施的主流中你的范围将根据他们失望趋势的上升而扩展。在你重组公司工作流时他们会对管理报告的设计吹毛求疵在你使供货响应时间减少三十天时他们会怀疑你为什么在最终用户培训上花费如此之多。
唯一能减少他们失望度的办法是教育他们使他们了解这个项目的真实情况。如果他们拒绝你就只能在项目的整个过程中忍受他们的无知并接受这么一个事实一旦你成功了。这些高级官员只会着眼于所花费的成本和时间会把你的努力看成是失败。
那位抱怨牛奶是凉的人在上菜的工作流中只给其他人带来小小的麻烦。而更严重的问题是有人点了菜单上没有的东西而且还不依不饶不许别人回答个“不”字。
结束范围
如果你一开始就接受这样的事实即范围在项目进行过程中会有所变化你就处于能够应付这种变化的位置了。功能方面的扩展是最自然的扩展其它在范围方面的变化是项目进程中业务环境变化的直接结果。
项目组应当以轻快的脚步迅速完成设置阶段的工作。因此我们建议在可能的情况下冻结范围确定“结束范围”并通报全企业。这种结束范围的做法会使那些直接要求得不到处理的人们感到失望。在解决失望问题时你要为不把某些被认为是遗漏的因素包括在范围内找到确凿的理由。一旦关键的实施主体工程完成后这些暂时遗漏的因素可能会在晚些时候得到考虑。
你所应该避免的是一个期望─业务流程重组─设置─新的期望的不断循环。让原型上的油漆变干向任何一位肯听愿学的人在原型上作番演示简单解释一下后结束。然后继续下去。
第九章勇敢的新世界
考验所有相关人员耐心的文化和业务变化
信息不是报告
八十年代初我在一家大型英国电子和防卫公司的欧洲贸易分部担任信息系统经理负责从斯德哥尔摩到马德里七个不同地点的信息系统。那个时代信息系统被看作是从属于财务部门因此我在这些不同地点主要接触的是财务主管。
我们当时已为所有的地点开发了单独一套基本系统。我发现实施中最大的困难之一就是让财务主管们在系统的输出即报告上达成一致。在接此职位之前我学会一句格言“报告因公司而异”。我从那七位财务主管那里学到的是报告格式、内容既不是因公司而异因地点而异也不是因部门而异而是因人而异天底下每个上帝的子民都有其独特的报告方式。到了财务主管这里这就更能说明问题了。
在所有这些地方实施软件的一年半里我花费了大量时间处理现金流样本分析、长期拖款的债务人名单和发票对账表同时听那些会计部门的负责人向我解释他们绝对独特工作方式的种种优点。我那时还很年轻于是非常相信财务主管们跟我说的也非常当真这样一来我的编程─分析员们为了应付关于额外报告格式选项的“系统提高要求”几乎忙得要命。通过最后的分析我们为七位财务主管兄弟们得到了七份长期拖欠的债务人名单新娘们但是其中没有一份除了语言不同外与其它还有什么显著差别。工程结束了欧洲的财务主管提出了他们的意见而我则直言不讳地提出了对他们的责备。
时光匆匆已经临近了千年的结尾许多事情已发生了变化。信息系统部门已不再从属于财务部门。哈利路亚在SAP领域中信息系统扮演的是支持角色而不是直接服务角色更让人欣喜但是旧时代令人讨厌的一种做法依然存在即报告的格式和内容仍然是因人而异根据客户归类整理根据地区及客户种类小计包括总计的百分数和小计的百分数然后重复所有根据地区进行的小计再将总数登记在最终的单独一页上。
在以后的日子里我的对策是在我设计和实施的所有系统里包含报告生成机制向用户不管他们的级别提供定义所要数据的选项提供展示报告的格式提供一系列数据操作键这样大多数所需要的报告就能由那些为特别目地要求特别信息的人们自己生成。
但是这样做也不能绝对地满足所有的需要。人们所要求的不是所坚持的是摁一下按纽式的解决方案或者更理想的是定期将所要的报告送到手边。
对不起请你将我掉在这页上的灰白头发扫去。现在让我们回到讨论......
建议你在SAP实施中避免就报告问题进行长时间讨论。“输出”是大多数用户着迷、却是SAP中最不难满足的内容。你能得到SAP脚本、成百上千份标准报告、询问功能等等只要你说得出你就能得到。有时需要编写ABAP/4程序但大部分情况下输出不应成为主题。重复一遍主题是工作流。
你如何才能将主题带回到工作流取决于a)你的咨询才能b)你对手头项目的理解以及c)你的听众。要准备好演示表面上令人生畏的SAP报告功能。在系统演示过程中准备好又唱又跳以夸张的方法介绍该功能希望能满足用户所关注的“输出”的期望。不要对定制的报告格式作出任何承诺。做一名传教士别做奴隶。如果用户定制报告成为业务流程重组期间一次会议的主题那么你离开正确道路已偏离太远了连一大群圣伯纳德救护犬都无法找到你。
无纸化公司是巴西丛林的梦想。不管如何你应尽力使你的员工转向使用屏幕查询搜索等SAP功能。如果你对新的业务流程有深刻的了解而且你能象个样板似地为他们作示范这样做的效果最好。你把人们轻松带过一个流程的能力对你极有帮助。高地上的树苗会为你祝福的你的实施预算和你的精神状况也会为你祝福的。
针对那些计厌的财务主管的另一个音调变化
开具发票自从很早有会计以来一直属于财务/会计部门的管辖范围销售发票由财会部门出具。购货发票由财会集中在付款之前同发货收据放在一起。销售发票同发货通知结合在一起引出收货流程。这些都牵涉到财会都同这块分数板有关。
更好的业务流程SAP说是“最好的”但在北美对此的区分仍有争议要求给客户开发票工作属于销售和分销SD购货票据由物料管理MM出具。有了SAP财务/会计部门最终成了计分员。而选手们即买主和卖主控制着买卖的游戏。
在你把开具发票销售和采购的权力从计分员那里夺来交给那些懂得如何处理的人们时你必须要稳重具有外交手段而且一定要坚决。
更少的教练更多的选手
将垂直的组织结构压扁成更加水平状的结构是伴随着项目进行的业务流程重组工作中首先考虑的基本点。明显的结果是在最临近的地方减少了中层经理人员的数量将有更多的选手自己决定做什么和何时做。
在北美五十年代起就有人认为一家企业就象支美式足球队每个人在特定的位置上工作。由一名四分卫一名主教练一名边线教练一名接球教练一名防守后场教练和到了八十年代一名心理医生所领导。这种美式足球队概念的地位受到八十年代日本方式的冲击而日趋下降在日式热潮中人们认为原先的管理牵制和平衡做法过于呆板、迟钝有些空洞乏味。
有了SAP你走进了一个新的天地在这里甚至连团队的概念也与你以前所知的不再相同。那些边线教练和接球教练将消失。队伍会变成象爵士乐团或者交响乐队根据需要和机会组合或者改组然后一旦满足需要或者抓住机遇后就解散。“需要”将是业务事件“机遇”则是功能潜力和SAP的灵活性。在原先那些教练的位置上将有一名基本指挥或者少数几个人组成的小组他将挥舞指挥棒和谐完美地奏出你每一工作日中有特点的活动之曲。
除了实施项目以外这个因素将是对你集体的最大挑战。你和你的部落把自己改组成一个爵士乐团会多快从被替换下岗的管理人员那里你会遭到多大的抵抗你的高级管理层处理这个改革有多认真最后既然每一次革命都会引起一次反革命那么你将如何对付该项目必将激起的强烈而又不利的反应呢
几点提示
1. 准备好展示未来在原型开发期间使用原型组织几次新业务流程的模拟操作关键是要尽可能证明理论的有效性。
2. 避免进行煽动民心的宣传。你不是在领导民众起义而只是在帮助你的公司或客户进入下一千年的业务实践和支持。
3. 在不同的角度坚持强调成本和利益的关系。成本很容易遭到攻击而对可以展示的利益进行的攻击会象亚利桑那州的雪那样很快消失得无影无踪。
4. 在就文化方面的变化进行争论时尽可坦率承认主题就是文化。公司传统也是文化战场将会为手中的事情而平整好。伪装成谨慎的胆怯永远存在如果你笨手笨脚你会打胜许多战役但最后打输整个战争。你应该作示范作讲解最重要的是预测你会遇到的阻力。你要准备好打输一场、二场甚至三场战役。抵抗不总是拒绝有时却是启发是以它特有方法显示出来的齐心协力。
所有的烈士有一件事是相同的
他们都死得很难看不管是圣人还是傻瓜他们死了。
圣人的思想永垂不朽傻瓜的思想同他们一起死了。在公司这个环境里所有的烈士都是傻瓜。你没必要以辞职作威胁让人接受你SAP业务流程重组的事业。如果你这样做了你的想法不会在告别晚会以后还有人记着。
你的最高行政主管对SAP知之甚少这没关系。
你公司里的头号人物有许多事情要干尽管许多事情与公司今年的盈亏底线毫无关系。最高行政主管有比你和你的部落要干的业务重要得多的事情要干。呃不也不是更重要的事情而是大多数最高行政主管自己认为是更重要的事情。市场份额、企业合并、合资、与媒体打交道、产品多样化、董事会上的小冲突诸如此类的事情比业务流程重组更多地占据最高行政主管的时间。
你的最高行政主管可能是“投身”于SAP实施工程的甚至还记录备忘录发布声明偶儿参加自带食物的工作午餐表示对项目的支持。但整个公司的运作往往会更加重要超出内部改革的推动力。
如果做得到你可以给你的最高行政主管一些教育。如果不能至少不要让他搅乱整个项目。这不是说首度执行官们是讨厌、无知或者玩忽职守的而是说最高行政主管们通常有自己的计划表SAP实施仍然只被看成是结构性的调整而不是文化性的变革。真是可惜但是情况通常就是这样爸爸、妈妈去看电影了而疯狂的孩子们却把房子重组成一个更好的居住之处。
我们不想在这里显得太任性了。按照目前的定义最高行政主管的工作与业务流程或者业务流程重组几乎没有什么关系。在食物链上端你能得到的帮助可能只限于来自最高财务主管、最高业务主管和最高信息主管以及处于同样第二个同心圈里的其他人。如果你做得到让公司的工作人员和设计者们及其他特殊阶层的人们充分工作起来。
注意尽管这方面看起来令人难于理解。最高信息主管不总是SAP实施项目的一部分实际上他们经常是充满兴趣的观望者一方面忙于关注遗留系统一方面为平行的SAP项目喝采同时在两边下赌注。如果SAP失败了遗留系统将保留最高信息主管会受到伤害但仍会活着。如果SAP项目成功了最高信息主管会得到《计算机世界》杂志的采访他会就成功的关键简要地说上几句。
那么把最高信息主管带入SAP的营地吧否则你得要为更长的实施时间、更高的失败率作好准备。如果你没能将最高信息主管带入SAP你也可能成功在没有控制的情况下但是这样的成功可能会被推翻被忽视或者不明不白地受到损害。
如果你是最高信息主管太好了你处于保证项目成功的最佳位置。关键一点是你要把注意力越来越多地放在SAP上越来越少地放在遗留系统上那些遗留系统可能是你以前劳动的结果放弃它们可能是痛苦的。但项目组将注视着你看你是否愿意放弃它们。向他们显示你的坚定决心通往SAP成功的道路就能变得宽广笔直。
用户就是用户你是带来光亮的人
变化会使用户受到教育、指导也会被愚弄、操纵和遭受打击。他们无法控制SAP实施也无权决定业务流程重组。
在北美有种观点认为“用户永远是正确的”。用户本身并不正确用户只是队里的选手。你应该把用户看成普通的人他们早在你带着有关SAP、业务流程重组以及随后的“授权”等花里胡哨的想法出现以前已经拥有一份良好、稳定和受到指导的工作。
那些要击打键盘的人们会以使你流程计划落空的方式操纵系统。他们会依赖他们在这个项目之前已工作多年的方式。他们对编程—分析员的未来往往已习以为常。他们早已看到过卓有成效或者失败的管理备忘录他们会不为什么明显的理由而填写表格他们曾聚集在会议室聆听有关全面质量管理的管理倡议而那些倡议就象是永远不会变成酒的葡萄。简而言之你要面对的是一群不好对付的人而且SAP项目中内在的变化将使他们更加难于对付。
对于不能平稳经历变化的人来说SAP可能是对他们事业上的打击。但是对于能够随机应变的人来说SAP又可能是使他们生存、发达的极好机遇。学会操作因特网对许多人来说是件大事而学会掌握工作流是更加伟大的成就。
责任和贡献是最终用户应该展示的核心。不要给这些人贴上空洞的标签例如“授权”权力不是你能提供的你提供的是机会和责任。你的管理层是否能认识到这点将是你中期和长期成功的关键。如果你把责任交给那些从来不曾有过责任的人们你就要准备好为失败而代人受过准备好承认最后获得的成功。
文化方面的工作是你的主要工作。掌握关键的词语掌握利益所驱的论点并予以充分展示你的生活将华丽无比普通的荆棘将变成鲜花至少接近于商业能提供的仿真鲜花。
第十章指点迷津的详细地图
在SAP实施中识别失败以及辨认成功
失败是暂时的成功却是长久的
“真理在起步前谎言已周游了半个世界”
──温斯顿symbol 160 /f Wingdings /s 14 }邱吉尔
现实中你最终的胜利或者失败总会被旁观者看到。但是几乎没有几个涉及全企业应用程序套件实施的宏伟项目会被人全面认识。南达科他州黑山地区有北美最大的金矿这个金矿已存在了120 年。这里曾经是充满绿色的美丽山岗但现在只剩下尘灰飞扬的平地。1977年在这里爆破并淘出了价值几十亿美元的黄金在我们商业圈子里这个金矿可算是极为成功了。但是那美丽的山岗却已不复存在空空如也永远地消失了。
我们在各种媒体中读到过无数有关SAP失败的文章但是当我们再次阅读这些文章时我们发现实施游戏依然在进行中。客户们已变得非常暴燥预算和人们的神经都撑到了极限然而实施项目仍在继续实施队伍仍在调整之中。不能在半年或者一年之内实施完SAP几乎总是被看成是完全失败这种态度来源于历史上和传统上对单一应用程序的实施。现在看来这种态度对公司和有关人员是不公平的针对SAP实施也是目光短浅的。
我反复、彻底地搜索我的记忆想记起是哪位愚蠢的六十年代美式足球教练说了这么一句话给我找个输得起的人我就会让你看一个真正输了的人。赢或输成功或失败这种概念愚蠢地简化了我们在复杂但具有人情的商务领域中所做的一切。
考虑一下在SAP实施中各种可能出现的失败或者成功的原因
· 签订了SAP许可证但没有实施即根本没有使用SAP。
· SAP实施完毕但项目既超支又超时。
· SAP部分实施完毕这意味某些遗留系统仍在使用之中。
· SAP实施完毕但结果并不是具有错误设想的人所期望的那样。
· SAP正在实施之中但没人知道为什么要实施或者如何实施。
在所有这些情况中唯一彻底失败的只有第一种。但是即使如此无法使用SAP可能仍有指导意义对于SAP来说仍然是一种成功。在我们第一本书《迎接旋风SAP世界初学者指南》最新修订和扩容过的版本中我们提供一系列针对“你是否准备好实施SAP”的详尽问与答材料。许多公司通过使用这些材料证明他们还未准备好。明显具有垂直组织结构并且死抱着不放的公司肯定会在SAP实施上失败就象三月份苏格兰会下雨一样的肯定。没有管理远见的公司会因为预算修正使SAP实施小组处于极其不利的地位。
然而一旦我们把成功看成是通向工作流具有实质性地进步时成功就会意想不到地到来。
我们长期以来一直观察着一家在SAP实施中不断抱怨、呻吟的超大公司这家公司在咨询顾问、旅行、会议等等方面花费了数百上千万美元但还是看不到有明显地进步。实施SAP的失败是过道里的迷雾但某些成功的香味已开始吹送到那迷雾之中。这家公司名符其实是许多垂直结构王国的总和我们怀疑这个SAP实施项目是最高行政主管用来压扁和敲击那些垂直王国的大棒以使它们能高度警觉。
作为SAP项目的结果这家公司现在正激烈辨论它将如何走向未来的二十五年而不是如何照常开展业务。这家公司是否能根据挂在许多办公室墙上的巨大图表成功实施SAP并不是关键所在。现在是工作流和以往做法之间发生冲突的问题。小卒子的前进早已为摇摇欲坠的马和象让路了。我们隐约觉得在一年左右时间内这家公司的文化就会沾上进步的墨迹SAP或者其某一版本就会实施完毕。在此期间失败是个定论而成功只是谣言是还没有起步的真理。
第十一章 咨询联盟
头脑、热情和勇气
图图我觉得我们已不在堪萨斯州了
当弗兰克symbol 160 /f Wingdings /s 14 }鲍姆住在南达科他州的阿伯丁时他写了并发布了他第一版《欧兹的巫士》他的朋友和邻居对他把南达科他州描绘成一个单调、荒凉的地方很反感。为了增加读者和改善邻里关系他重写了此书用了堪萨斯州一个地名。后来他的书和电影极其成功人们错误地认为堪萨斯州是通往欧兹黄砖铺地道路的起点。应该是南达科他州。在我们最近的技术时代南达科他州出了一家电脑公司Gateway 2000具有乡下的图案奶牛和外表黑白相间的箱子。欧兹这个地方是一个技术上的Gateway即入口是你通向SAP成功旅途最肯定、最可靠的起点。
尽管拉什英尔山上不可搬动的石刻人像在南达科他州
咨询联盟是一个全球性组织在四大洲──欧洲、北美洲、南美洲和亚太地区──拥有办事处或项目。我们的咨询顾问和指导人员遍布诸如汉堡、亚特兰大、费城、拉皮德城、克里夫兰、法戈、墨尼黑、加拿大的温尼伯、香港、上海以及地球上数不清的其它地方。我们无数次成功地实施了SAP或是作为主要咨询顾问或是作为多伙伴项目中的伙伴公司。我们依靠经验、方法、工具和风度。我们不是一家人而是一个部落我们具有成功的习惯。
总而言之
咨询联盟是一家单一来源的公司向寻求实施和使用SAP产品的公司提供一种集成方式。集成方式强调SAP教育的必要性──即从我们的员工向客户的员工从项目开始到实施结束进行SAP知识转移。
它的咨询集团称作为THE OR PARTNER GROUP意思是“组织和重组伙伴”。我们的咨询顾问平均 35岁具有四年半SAP经验和之前的十一年工业经验我们提供SAP实施和战略咨询服务。这就是我们所干的全部。我们遵循SAP的实施原则依据由SAP批准的ASAP项目方法。THE OR PARTNER GROUP在德国、美国和中国建有办事机构。
我们相信一个更加完全的SAP教育是SAP实施成功必不可少的关键通过使用THE DOLPHIN GROUP的教育服务设施我们补充了SAP应用程序课程以达到客户自给自足最终独立的目的。THE DOLPHIN GROUP的教育中心在特拉华州的威尔明顿为你公司各个层次人员提供专题研讨会和课程主管人员项目经理。协调员和直接用户。我们的指导人员是圈内的知名咨询顾问都具有真正的SAP实施经验和背景知识。
· 《迎接旋风高级行政人员SAP课程》
· 《把握旋风SAP成功实施实地指南》
· Dolphin 2000
Tm: 培训课程持续10天涉及从FI-CO到SD-MM以及集成测试学生有机会亲自动手用 SAP 建立和设置一个功能性模拟公司。
· Dolphin 4000
Tm: 学员分组进行设置和设置练习在10天内通过动手学会设置一套R/3系统FICOSDMMPP和 HR基于案例研究建立一个功能性模型。一次真正的微型SAP实施。
· Dolphin 5000
Tm: 面向实施小组的设置和集成研讨会五天动手实践学员根据实例分析建立一个功能性模型学会设置R/3系统FICOSDMM。一次真正的微型SAP实施。
· 使用标准课程作为基础根据客户要求灵活安排课程。
咨询联盟也出版发行了《迎接旋风SAP世界初学者指南》目前已是第四次印刷。Amoco, Georgia Pacific,杜邦IBMDeloitte/ICS, Texaco, Andersen, Consulting, SAP和其它公司都不至一次定购了此书。他们在谈些什么呢
用平白经常也是生硬的语言说这本书超越了道听途说和错误信息给这些和其他问题提供了答案
· 为什么SAP如此热门
· SAP是一股暂时的热潮还是个持续的现象
· 是否SAP只适用于《幸福》杂志前500名公司
· 为什么SAP如此难以实施
· 实施SAP需要进行多少业务流程重组
· SAP项目的隐含成本是什么
· 在SAP项目中什么是最佳使用咨询顾问的方法
· 为什么有经验的SAP咨询顾问难于找到
· SAP是否是帮你削减人员的伙伴
THE DOLPHIN GROUP 的口号是
帮助人们适应
SAP
。在SAP实施中人们有许多需要适应──要学许多要忍受许多。为了向Dolphins表示敬意我们将在1997年夏初出版一本新书叫《旋风中的人们SAP实施中人性的一面》。即将上市敬请留意
《收获于旋风从SAP实施中获得最大的利益》可能在今年或1998年推出。
如果你喜欢这本书或者如果你对此书有意见请跟我们联系。如果你想多得到一些或者如果你要更多的书也请跟我们联系。我们有电话号码我们有各种传真机我们随时准备着。
不图图。我们已不在堪萨斯州我们在南达科他州。我们在地图上。如果你希望找到SAP的欧兹即乐土这是开始你旅图的好地方。我们乐于陪伴你上路。
实地指导帮助页面和注解。
SAP应用程序名称
CO
控制
F1
财政会计
EC
企业控制
IM
资本投资管理
AM
资产管理
TR
库存
HR
人事管理
PA
人事应用程序
PD
人事计划及发展
LO
后勤
MM
物料管理
PM
工厂维护
PP
生产计划
PS
项目管理
QM
质量管理
SD
销售及分销
Basic
在跨各种可能的操作系统时稳定操作的中间件。
ABAP/4
使用的编程语言
术语和缩略词
ABAP
高级商务应用编程语言
AM
SAP中固定资产管理应用程序
ASAP
一套快速实施SAP的方法
Business Process
为将输入转化成有利于顾客的输出而进行的一组或一系列活动
C/S
客户机/服务器
CO
SAP R/3中的控制应用程序
Config
设置SAP就是为你公司在各个图表中设定选项
Customize
根据你的流程设计对系统作改动
FI
SAP R/3中的财务应用程序
Gap analysis
对你想做的但你认为SAP不会提供的内容进行分析
GUI
图形用户界面
HR
SAP R/3中的人力资源应用程序
ICOE
工业技术中心
Interfaces
在分开的数据库之间由程序驱动的连接
IS
信息系统
IS
SAP中的工业解决方案应用程序
IT
信息技术
Middleware (Basis)
在客户机和服务器之间的“/”例如客户机/服务器
MM
R/3中的物料管理应用程序
OC
SAP R/3中的办公室和通迅应用程序
OR
组织和重组伙伴即OR伙伴
PM
SAP R/3中的生产维护应用程序
Portability
软件能运行在不同操作系统的能力
PP
SAP R/3中的生产计划应用程序
PS
SAP R/3中的项目系统应用程序
PTA
父母教师协会
QA
SAP R/3中的质量保证
QM
SAP R/3中的质量管理应用程序
RMD
作者姓名的首字母缩略
SAP
读成Ess Ay Pee
SD
SAP R/3中的销售和分销应用程序
Software suite
源自同一设计的多种软件应用程序
因特网介绍
有人曾经将因特网的发展类比于西部世界的发展说每一年相当于西部历史上的十年。如果是这样的话我们现在正处于1890年。还要再忍受十年的荒野、无序、高山、沙漠、匪徒和响尾蛇。
SAP自己在因特网上有一站点SAP.Com)可以比作1890年的旧金山。表面上有些华丽有些自傲但在公司、产品、咨询伙伴以及实施过的客户方面具有丰富、有助的信息。最近又增加了成功故事库以全彩资料简要介绍实施SAP的公司以及它们从中得到的收益。尽管这些简介散发了市场的气味但是从中看到全世界所取得的成就是有用的。
除此之外还有许多与SAP的相关的站点提供技术资料、业务设计工作台细节、针对实施者的帮助信息、ABAP简介和其他信息。我们不在此列出这些站点因为在你读到本书时许多站点可能已经消失、换址或者合并。重要的是你要知道有几百个这样的站点你只要使用一些基本搜索引掣如 Lycos 和Yahoo就能找到它们。
在你实施期间最好能定时查看SAP.Com站点。正如已经提到过的那样每天都有新的公告几乎每月都有新的版本发行。但是不要对新的公告过于敏感因为许多公告还不太成熟许多只是对号称是事实的杂志文章的反应。然而既然有数千名专家每天在编写新的SAP代码你最好还是能随时了解他们的发展方向。
后注你是否有个大问题——19yy
1976年我在明尼苏达州圣保罗城工作时曾被要求去为该市设计和编制一套程序用于捕获和追踪所有用债券保证的债务情况。在同一位面无生气但很和善的该市会计确定完功能方面的规范后我开始用COBOL语言编程以完成要求。我第一个测试程序是针对为期二十五年债券我用COBOL编的用于偿还和利息表的程序工作得很顺利直到最后一年。那年是2000年。
在这年以前我使用二位数表示年份已足以对付偿还计算工作但是突然用00减去99不能产生预想中的答案“1”。我那时碰巧撞到了一个现在二十几年以后让许多公司关心的问题。现在看来毫无意义而在当时在任何记录的日期栏内少填入两个讨厌的数字“19”似乎很重要。如果67就行何必要填入1967呢如果我是从1974起开始我的债券项目而不是从1976年起我就可能得不到这个教训──19yy。
在1976年就能找到一个将来能用的解决方案我算是幸运的。你可能也是幸运的。 19yy的痛苦导致了在SAP领域另一个成本考虑。
SAP提前想到了这点已作好准备下一世纪到来的准备。如果你还在考虑是否实施SAP你可能已考虑到不用修改你现有的程序将为你节省下多少资金。最近美国政府的一项声明显示为改正这个错误已安排了超过二十亿美元的预算。我们不知道你公司用于19yy方面的预算有多少但是不管有多少可能你早就应该实施SAP了。仅仅是可能
掌握旋风SAP成功实施实地指南
本书对于项目经理、模块负责人、超级用户和任何积极参与SAP实施的人员来说都是极具价值的。在传统系统实施中似乎已掌握的范围管理、咨询要求、差距分析、方法与工具及其它许许多多内容在SAP实施中根本就没有得到掌握。其结果是产生了高度的压力、巨大的失望、时间和金钱的浪费以及对于SAP的无端指责。
SAP是一股旋风如果处置得当能为人们带来利益。本书将帮助你认清前进的方向避免潜在的危险把握这股旋风使之为你公司所用。
本书所涉及的一些内容
l 用好童子军和雇佣兵充分利用你的咨询顾问。
l 分清南北识别差距分析、AS IS和其它咨询阶段中的陷阱。
l 从彷徨者到探路人各式各样的R/3教育浪潮。
l 只有你能预防森林火灾在SAP实施中范围之火如何点燃的。
有关作者
迈克尔·多恩Michael Doane是咨询联盟的一位伙伴他在世界各地的项目管理方面具有十五年以上的经验。本书写作过程中得到沃夫根symbol 160 /f Wingdings /s 14 }贝兹Wolfgang Beitz、克利斯symbol 160 /f Wingdings /s 14 }卡尔森Chris Carlsen、周汉策James Chow、罗伯特symbol 160 /f Wingdings /s 14 }佩勒格里尼Robert Peilegrini和其他咨询联盟SAP专家组成员的通力合作。
|
|
发表于 2021-1-21 03:02:43
