You are on page 1of 24

哈佛商学院案例

9-699-022
修订于:2002 年 5 月 6 日

作者:
Robert D. Austin
Richard L. Nolan
Mark J. Cotteleer

思科系统公司:实施 ERP

思科系统公司首席信息官(CIO)皮特·斯洛维科(Pete Solvik)思考着 ERP(企业资源规划)实
施预算的最后一行项目。思科公司有着以现金红利奖励绩效的传统,但奖励 ERP 团队的金额超过
200,000 美元,前所未有。无可否认,他们在人皆以为不可能的时间框架内实现了诸多成果。而且
这并不容易。团队成员包括斯洛维科在内,参与这个项目本身就承担着风险。奖励应该而且将会异
常丰厚。尽管如此,奖金池的规模依然令斯洛维科陷入思索中:他们的表现十分出色,但出色到什
么程度呢?哪些方面运转顺利?哪些方面出现问题?如果面临同样规模和风险的另一个项目,他们
是否能够再次实现成功?

思科公司历史
思科系统公司由两位斯坦福计算机科学家创建于 1984 年,并于 1990 年上市。公司的主要产品
是“路由器”,结合硬件和软件,在构成互联网(以及企业“内联网”)的复杂 TCP/IP1网络中担任流量“警
察”。随着互联网技术的崛起,对思科产品的需求也异常繁荣,公司很快开始在市场中占据主导地位。
1997 年,公司首次列入财富 500 强之林,营收收益率和资产收益率均名列五大企业之一。(思科公
司的财务业绩见附录 1。
)只有另外两家企业(英特尔和微软)可与之相提并论。更为令人惊讶的是,
在 1998 年 7 月 17 日,在创建短短 14 年后,思科公司的市值超过了 1000 亿美元的标准(相当于 1997
1

传输控制协议和互联网协议,合称“TCP/IP”,为 LAN 之间的信息路由提供了稳健的标准,并提供了在不断扩大的广

域网(WAN)中连通所有计算机的可能性。
1

年销售额的 15 倍)
。一些行业评论员预测,思科公司将与微软和英特尔一起,成为构建数字革命的
第三大主导企业。
红杉资本公司(Sequoia Capital)合伙人兼思科公司董事会副主席唐·瓦伦丁(Don Valentine)2最
早投资于思科;当其他风险投资者较为谨慎时,他却在这家新锐企业中小试运气。为了保护 250 万
美元的初始投资,瓦伦丁的办法之一是保留了在他认为适当时雇佣职业经理人的权利。
1988 年,瓦伦丁聘请约翰·莫格里奇(John Morgridge)担任首席执行官(CEO)
。莫格里奇是计
算机行业中的资深企业高管,他立刻着手建立专业管理团队。这个团队很快与创始人发生了冲突,
在思科公司于 1990 年首次公开募股(IPO)之后,两位创始人均出售了手头的全部股票,并离开了
公司。他们的离职让莫格里奇得以自由地继续实施他的计划,建立起极其严谨的管理结构。
莫格里奇坚信,许多硅谷公司过于快速地开展分散化,并没有重视职能部门组织在增长的同时
而不失控制权的切实能力。因此,莫格里奇保留了中央化的职能部门组织。尽管产品营销和研发部
门分散化为三条“业务线”(企业、中小企业和服务提供商),但制造、客户支持、财务、人力资源、
IT 和销售组织依然集中化。

思科公司的 IT 历史
皮特·斯洛维科于 1993 年 1 月加入思科公司,担任公司 CIO。当时,思科是一家价值 5 亿美元
的企业,采用基于 UNIX 的软件包来支持其核心交易处理。该软件包所支持的职能领域包括财务、
制造和订单录入系统。对支持这项应用程序的软件供应商而言,思科公司远非最大的客户。3 斯洛
维科的经验和公司的巨大发展前景让他坚信,思科集团需要变革。
我们希望增长到超过 50 亿美元。这项应用程序无法提供我们所需的冗余度、可靠度和可维
护性。我们再也无法为了满足业务需求而修改这项应用程序。它已经变得太过复杂,过于定制
化。软件供应商的确提供[升级版本],但看到这个版本,我们认为:
‘系统完成后,将会更加可靠,
具备更高的冗余度,但这个软件包仍然只适合价值 3 亿美元的企业,而我们则是价值 10 亿美
元的企业。
’”
斯洛维科的初始倾向是避免 ERP 解决方案。相反,他计划让每个职能领域就应用程序和行动时
机自行作出决策。然而,遵循思科强有力的标准化传统,所有职能领域都必须使用通用的架构和数

2

唐·瓦伦丁之前是思科集团董事会的外部执行董事长。思科公司保留了董事会主席,作为外部董事。目前,约翰·莫

格里奇担任董事会的外部董事兼董事长。
3

这家软件供应商的大部分客户营业收入在 5000 万美元至 2.5 亿美元之间。
2

据库。这种方法与斯洛维科在就任时所建立的组织和预算结构保持一致。斯洛维科强烈地感到,应 由职能领域作出有关 IT 开支的预算决策,尽管 IT 组织直接向他报告。斯洛维科之所以反对 ERP 解 决方案,也是因为担心 ERP 实施往往会成为“巨型项目”。 决定性时刻 在第二年中,进展极小。制造总监4兰迪·庞德最终成为这个项目的联合主管,他描述了 1993 年 年末职能领域所面临的困境: 我们明白,如果按兵不动,就会遇到麻烦。我们的一切行动都将在现有的遗留系统上运行。 最终成为不断修补现有系统的努力。我们都不会亲自出去采购个软件包……。对我来说,去找 董事会,说: ‘好吧,制造部门想要花五六十亿美元采购一个软件包,顺便提一下,真正投入运 行需要一年以上的时间’,因此造成的业务中断过于严重,难以证明其合理性。我们都不愿抛弃 遗留系统,实施大规模行动。 职能领域的系统更换难题造成了思科公司遗留环境的持续恶化。递增式改良不断实施,同时公 司保持着 80%的年增长率。系统中断成为家常便饭。产品缺陷则导致从中断中恢复变得日益困难。 最终,在 1994 年 1 月,思科公司的遗留环境遭遇了严重故障,令企业无法再对现有系统的缺 陷视而不见。访问核心应用数据库的未经授权方法(这一权宜之计源于系统无法实现适当性能)出 现故障,损坏了思科公司的中央数据库。因此,公司在两天中陷入大面积停机。 思科公司从这次大规模停机中恢复的努力揭示了这样一个事实:公司的系统正濒临全面崩溃的 边缘。斯洛维科、庞德和思科公司的一些其他管理人员得出结论,他们所采用的自发系统更换模式 并不足够。需要另一种模式。斯洛维科描述了他们当时的行动: 我们说: “我们不能悠闲地等待着,而订单录入、财务和制造部门作出三个不同的决策。”这些 应用程序到位需要的时间太长。我们必须采取更为快速的行动。当时,我们得到了制造高级副 总裁卡尔·雷德菲尔德(Carl Redfield)的支持。在加入思科之前,他曾在数字集团(Digital)负 责个人电脑制造。他一马当先,表态说:“好吧,我们就继续干吧……。我们从制造角度开始, 看看能不能让公司内的订单录入和财务团队也有兴趣对所有应用程序实施一次性的整合更换, 而不是花费更多的时间实施不同的项目。 ”于是,在[公司停机]后大约一个月,在 2 月,我们开始 组建团队,为更换应用程序实施调查。 4 实施后,兰迪·庞德被提升为思科公司制造部门的副总裁级别。 3 .

根据以往在数字集团的大型实施经验,雷德菲尔德明白,“庞大的”IT 项目可能会自行发展。他认 可斯洛维科有关项目规模的顾虑,对于思科集团如何着手大型实施项目也抱着强有力的观点。 我明白,我们希望快速行动。我们不会分期实施,我们将会一次性完成。我们也不会允许大 量定制化。MRP 系统5中存在这样的倾向,人们希望系统映像其运营方式,而不是重新培训员 工按照系统的意图来行动。这所需的时间要长得多。此外,我们还希望所制定的日程可行,成 为企业中的首要任务,而不是二级努力。 选择一种 ERP 产品 思科公司的管理团队意识到,为了满足业务需求而开展实施需要业务团队的深入参与。这并非 是仅限于 IT 的项目。尽可能吸引最优秀的人才,这一点至关重要。斯洛维科阐述说:“我们将员工从 现有职位上调离[加入这个项目],其判定条件在于如果很容易做到这一点,那么我们就挑选了错误 的人。我们所挑选的人员都是业务部门极其不愿放弃的人。” 除了需要强有力的思科团队之外,公司也需要强有力的合作伙伴。斯洛维科和雷德菲尔德认为, 与整合合作伙伴携手合作,由后者协助选择并实施公司所选择的解决方案,这一点尤为重要。优秀 的技术技能和商业知识是先决条件。斯洛维科解释了为什么选择毕马威(KPMG)担任整合合作伙 伴: 毕马威参与进来,看到了围绕实施这些应用程序而真正建立起业务的机会。他们还把它视为 决定性机遇,能够在这个项目上与我们合作。一些其他企业希望派出大量“新手”参与,和他们 不同,毕马威所建立的团队包含具备丰富行业经验的人员。例如,他们所任命的项目经理马克·李 (Mark Lee)曾在德克萨斯州一家企业中担任 IT 总监,该公司曾实施过 ERP 系统的各个部分。 在毕马威参与后,由大约 20 人组成的团队转向软件市场,采用多管齐下的方式确定最佳软件 包。这个团队的策略是充分发挥他人的经验,建立起尽可能多的知识。他们向大型企业和六大会计 事务所询问后者所了解到的信息。他们还利用高德纳集团(Gartner Group)等研究来源。6 通过将 选择流程导向人们真正使用的软件,同时继续强调决策速度,思科公司在两天内将范围缩小到了 5 个软件包。在对这些软件包进行了为期一周的高层次评估后,这个团队确定了两个主要候选人,即 甲骨文公司和 ERP 市场中的另一家重要参与者。庞德回忆说,在选择时,规模是一大因素。“我们决 5 MRP 代表一种系统类别,通常被视为 ERP 的前身,聚焦于为生产规划原料要求。预测或实际需求通过人工或从其 他类型的系统中馈送入 MRP。所有主要 ERP 供应商的产品中均内建 MRP 功能。 6 高德纳集团是有关 ERP 和其他信息系统信息以及制造相关研究的主要行业资源。 4 .

定不应将思科公司的未来交给规模比我们小得多的企业手中。” 这个团队花了 10 天时间撰写将发送供应商的招标书(RFP) 。供应商有两周的时间用来作出答 复。在供应商准备回复的同时,思科团队继续其“尽职调查”,拜访各家供应商提供的一系列参考客户。 在思科公司对招标书回复进行分析后,邀请各家供应商进行为期三天的软件演示,并且展示其软件 包将如何满足思科的信息处理要求。思科公司提供样本数据,而供应商则举例说明其软件如何满足 (或无法满足)关键要求。 选择甲骨文公司是基于一系列因素。雷德菲尔德描述了其中三个重要的决策点: 首先,这个项目在很大程度上以制造业务为出发点,而甲骨文公司在制造领域的能力优 于另一家供应商。其次,他们就软件包功能的长期开发作出了一系列承诺。7 还有一部分则取 决于甲骨文公司所擅长的灵活性。8 思科公司也有理由相信甲骨文公司特别热衷于实现这个项目的成功。庞德阐述了他对甲骨文公 司状况的印象:“甲骨文非常希望能够竞标成功。我们最终达成了出色的交易。但是,其中还涉及许 多方面。我们进行资信调查,实施实地调查,与参与决策的许多企业进行全面讨论。”思科项目将成 为甲骨文新 ERP 产品发布的首次重大实施。甲骨文公司宣传这个新版本在制造支持方面实现了重要 改进。在思科公司成功实施,将令这个新版本呈现出十分有利的趋势。 从启动到最终选择,思科集团共花费了 75 天。最终选择由团队作出。斯洛维科描述了他们如 何作出这个决策并向供应商传达: 团队内部作出了选择,并通知了供应商。我们无需通过重要流程,无需获得管理层的“批 准”。我们只是说: “甲骨文公司,你们赢了,[其他供应商]你们输了。 ”然后我们继续与甲骨文进行 合约谈判,准备向董事会提交的建议书。焦点立即转向这个项目需要多久、需要多少投资等问 题。团队确定: “好吧,我们将采取这项行动,而且应该继续推动项目的进展。 ”因此,现在,在 4 月末,我们制定了整个方案。 向董事会报告 在取得董事会批准前,团队需要回答两个非常重要的问题:需要多少投资?需要花费多久?他 们知道,公司高管担心大型项目可能会超出控制范围,最终却带来低于标准的成果。但尽管存在风 7 雷德菲尔德之后提到,并非所有这些承诺都在合约谈判期间达成协议的时间框架内实现。 8 甲骨文公司和思科公司的全球总部均位于美国加利福尼亚州圣何塞市,相距约 20 英里。 5 .

险,团队依然采用实证方式来估算项目要求。斯洛维科描述了这个流程: 思科公司的季度划分是从 8 月到 10 月、11 月到 1 月、2 月到 4 月、5 月到 7 月。9 因此, 5 月 1 日是第四季度的期初,我们问自己:“实施项目,更换所有核心系统,应该花费多久?”我 们是这样操作的。我们说:“众所周知,不可能在第四季度实施。审计师希望一年有头有尾。”如 果需要一年时间,那么我们将在第四季度实施,而这行不通。我们认为事实上应该为 15 个月, 到下一年的 7 月或 8 月。项目经理汤姆·赫伯特(Tom Herbert)表示,完成这个项目不可能要花 费 15 个月之久。这太荒唐了。因此,我们转向另一个方向,思考我们在 5 个月内能够达到怎 样的程度?看上去就不对。懂了吧,我们还没有范围。最终,我们基本上决定将在第三季度初 上线,以便在第四季度保持完全稳定。 (ERP 实施的节点日期概要见附录 2。 ) 于是,这样设定了目标日期。下一步的任务是估计项目预算。思科公司对此同样雄心勃勃:“在 设定日期后,我们估计了预算。我们制定了整个方案,而并未真正着手项目的实施。我们只是想看 看其中涉及的范围”(皮特·斯洛维科)。团队并没有开发正式的商业案例(即财务分析)来证明这个 项目将对企业造成的影响,而是选择聚焦于首先激发分析的问题。在斯洛维科看来,思科公司别无 选择,只能采取行动。他这样解释对这种情形所采取的方式: 我们提到 1 月份的大规模停机事件;我们是当前软件供应商最大的客户,并且该供应商被 另一家公司收购。尚不明确谁将会支持我们的现有系统,而我们需要对此采取行动。当前应用 程序的可靠性、可缩放性和可改良性将无法支持我们的预期未来增长。我们要么升级到当前应 用程序的新版本,要么加以更换。如果选择更换,要么分成多个部分进行,要么一次性整体实 施。我们评估了这三种备选方案,讨论了每种备选方案的优劣点,建议采用 ERP 解决方案大规 模更换系统。 我们致力于在 9 个月内使用 1500 万美元完成整个项目。 (项目成本细分见附录 3。 ) 尽管思科公司在一定程度上是被迫实施 ERP,但在缺乏正式经济的合理解释时继续执行,这也 是管理理念问题。正如雷德菲尔德所说的: 不能从合理解释的角度来解决这类事务。成本避免并不是讨论这个问题的适当方式。我们 对待这个项目的看法应真正达到“嗨,我们将会通过这种方式开展业务”。我们是在为所在组织实 现商业模式的制度化。 如果投资为 1500 万美元,这个项目将成为思科公司有史以来批准过的规模最大的资本项目。 团队成员准备好将这个数字呈报管理高层,但也略带紧张。与首席执行官莫格里奇的首次会议并没 有缓解他们的担忧。庞德这样描述与莫格里奇的这次会议: 9 思科公司的财务年度截止于 7 月 31 日。 6 .

500 人。 7 .我和皮特·斯洛维科、汤姆·赫伯特将建议书提交给莫格里奇,他的反应颇为耐人寻味。他 的评论是:“你们知道,比这个数字少得多的金额也会让人断送职业生涯。”我和皮特面无血色。 我们明白,如果失败,我们就会被开除。失败可不是公司愿意容忍的事件,尤其是涉及如此高 的金额时。 但莫格里奇同意将这份项目建议书提交给董事会。对庞德和斯洛维科而言,遗憾的是董事会的 反应也并不热情。庞德这样描述当时的情形: 我们还没来得及播放第一张幻灯片,就听到董事长在会议室的后面说话。他说:“多少钱?” 我说我很快就会谈到这个问题,他则回答说:“我不喜欢惊喜。现在就播放那张幻灯片。”放完之 后,他说: “我的天啊,你最好能给我们看到很多逻辑合理的幻灯片……。” 事实上,的确如此,最终董事会批准了这个项目。10 在这次会议后的几周和几个月内,莫格里 奇履行了他的职责,他向思科公司中的其余人明确表示,这个 ERP 项目是首要任务。这个项目成为 公司当年的七大目标之一。“公司里的每个人都明白这个项目势在必行,也是企业的首要任务。”庞德 解释说。 建立实施团队 获得董事会的批准之后,核心 ERP 团队立刻开始为实施制定结构。其中的首要行动之一是将思 科公司与毕马威之间的关系延长到实施结束时。这项决定取决于毕马威在软件选择流程中的表现, 同时,该公司也为这个项目派出最资深的人员,表现出持续承诺。 继续实施也意味着团队必须从核心的 20 名成员扩大到约 100 人,涵盖思科公司业务群体的各 个领域。11 同样的,团队只希望由最优秀的人才参与这个项目。实施人员的参与原则之一是这是短 期项目,并不代表参与者的职业变化。这项工作针对将其视为挑战的人员,“挑战严酷考验”。此时, 让人员参与团队不再是问题。实施团队的新成员伊丽莎白·费描述了对这项任务的看法。“他们为这个 团队精心挑选最优秀、最聪明的人才。对每个人而言,其中都蕴藏着职业进步的可能性。人们愿意 参与,因为它与众不同,是最佳良机。 ” 来自思科公司内部各个领域的团队成员被分别纳入五条“路线”(流程领域小组)。每个路线都包 含一名思科信息系统主管、一名思科业务主管、来自毕马威或甲骨文的商业和 IT 顾问以及来自企业、 10 庞德补充说,遗留系统在董事会会议当天出现了崩溃,这一情形有助于获得批准。“会议当天,[遗留系统]停机了。 我们得以走进董事会会议,说:‘它又崩溃了。’这一点极具说服力。” 11 当时思科公司的员工总数为 2.

担任团队成员的其他人员(思科公司 ERP 团队结构图表见附录 4) 。这些路线由“项目管理办公室”加 以管理,其中包括思科公司的商业项目经理汤姆·赫伯特和毕马威项目经理马克·李。 执行指导委员会是整个项目管理结构的最高层,包括制造副总裁、客户支持副总裁、企业财务 总监、斯洛维科、甲骨文应用程序高级总监以及毕马威西海岸咨询公司的负责合伙人。来自甲骨文 和毕马威的管理高层列席于指导委员会,表明了这些机构对这个项目成功的重视程度。 ERP 团队设立指导委员会的目的是让他们无需直接干涉项目的管理。委员会的角色是为该项目 提供高层面的支持,确保可见度,并激励团队。团队的目标是让指导委员会会议变为庆祝成功的事 件。为了确保这一点,他们聚焦于在会议之前解决指导委员会成员的问题。 实施甲骨文软件包 团队的实施策略采用被称为“快速迭代原型制作”的开发方法。运用这一方式,团队成员将实施 细分为一系列阶段,称之为“会议室试点项目”(CRP) 。每个 CRP 的目的是以之前的工作为基础,对 软件及其在商业环境内的运转建立起更加深入的理解。 CRP0 首个 CRP(CRP0)从培训实施团队、建立技术环境开始。此时,团队平行开展两项工作。第一 项工作聚焦于对团队进行有关甲骨文应用程序的培训。思科公司指导甲骨文将正常的五天培训课程 压缩成两天,每天 16 小时。在两周中,大部分团队成员参加了这项针对整个应用程序套装的“沉浸 式”培训。与此同时,一支“猛虎小队”则着手开展第二项工作,让这些应用程序投入运行。 在培训和系统建立之后,核心团队举行了会议,希望快速配置甲骨文的软件包。来自公司各个 领域的团队成员在公司外的会议中朝夕相处,为软件内嵌入的数百个参数确定适当的设置。除了团 队成员之外,还有来自甲骨文和毕马威的专家。斯洛维科这样描述这一体验及其强度和成果: 如何运行系统,存在着众多可配置的选项。你要在这些应用程序中设定数百个参数。因此, 我们在公司外呆了两天,共有 40 个人参加,当时在这个阶段,项目可能进行了 3 至 4 周,每 个人的回家作业是在这次公司外会议中就如何配置系统提出 80-20 建议。我们一整天都在开会, 一直延续到晚上,一共花了两天时间,为了让系统有效运行,深入到极其细微的层面。甲骨文 的专家,有毕马威的专家,以及思科业务人员、思科 IT 人员,我们讨论分类账,我们讨论账户 一览表,讨论这个,讨论那个。我认为这是 1%的努力,却为我们将如何运行这个应用程序带 来了 80%的准确性,而不是典型的 ERP 模式,后者往往研究六个月,却导致过度分析。我们将 8 .

这个项目进行了三至四周,最终就如何实施获得了大约 80%的准确度。 这次会议的一周后,团队完成了 CRP0,并演示了这款软件可在公司的整个业务流程中接受思科 订单(从报价到订购) 。 CRP0 带来的一项重要实现是思科公司将无法遵守其实施的一项早期目标——避免 ERP 软件的 改良。避免改良十分重要,因为变更往往针对具体企业,造成难以迁移到未来的应用程序版本,而 且耗时颇久。团队在项目第一阶段获得的经验表明,不经过大量改变,这个软件将无法有效支持公 司。一个月过去后,已经十分明确,将需要实施一些改变。两个月内,大家都明白,其中一些改变 将会幅度很大。 CRP1 根据在 CRP0 中学到的经验教训,实施团队立即着手开展 CRP1。现在,团队已经具备充分人手, 项目这个阶段的目标是让每条路线在各自的领域中实现这个系统的正常运转。和之前的工作一样, 重点在于让系统符合思科公司的流程,而无需改良。在 CRP1 期间,团队成员生成了详细脚本,记 录了完成流程的目的和所采用的程序(业务流程脚本样本见附录 5) 。为了确保所有或有情况均已考 虑在内,团队开发了业务流程原型追踪表(原型追踪表样本见附录 6) 。与 CRP0 不同,团队成员认 真记录了他们在建模期间遭遇的问题。项目管理办公室每周召开为时三个小时的会议,解决这些问 题。在这些会议期间,来自每个领域的路线主管携手合作,解决问题,推动项目的进展。这个阶段 的建模确认了有关软件的担忧。这个软件无法对大量业务流程提供支持。 对系统中出现的这一差距,实施团队的反应是开发出单独分类和评估的方式。“所有改良请求都 分类为红色、黄色或绿色。每一个问题都提交路线主管,如果是红色,则提交给监督委员会审批。” 红色并为数不多(“红色”改良列表见附录 7) 。最终,需要 30 名开发人员花费三个月的时间来讲甲骨 文的系统改良为可正常支持企业。12 伊丽莎白·费这样描述这个过程: 当我们意识到无法“平常”上线时,就开始制定改良策略。7 月和 8 月聚焦于我们将进行哪些 改良?哪些真正需要改良,哪些不是。在某些情况下,用户会说:“你知道,以往首先要录入日 期,而在甲骨文系统中,则排名第四位。”在另一些情况下,是意识到如果我们无法找到自动化 12 在设计这个系统所需的改良时,思科公司共同努力,“避免核心应用程序代码”。“核心”代码是作为应用程序处理 基础的中央编程逻辑。软件供应商通常不支持核心代码改良,改良也会让企业难以通过新版本发布对现有软件进行 升级。在思科公司的案例中,大部分改良避免接触核心代码,而是依赖于添加数据库字段和技术上简单的窗口变更。 在改变核心代码的情况下(通常是为了绕过特定处理) ,思科人员与甲骨文公司的顾问和软件工程师协作,确定适当 的变更。在部分情况下,思科公司的改良在之后融入甲骨文公司的核心产品中。 9 .

的模式,就必须雇佣 100 个人,在车间内打开和关闭工作单。 发现了对甲骨文系统进行改良的必要性,为项目方案和预算带来一些计划外的变更。除了确定 所需的改良之外,实施团队还决定,甲骨文软件包将不会充分支持公司的售后支持需求。因此,团 队同时开展工作,评估和选择服务支持软件包。这个软件包的选择和实施日程与总体实施日程相匹 配。思科公司计划将两个软件包在同一天上线。 CRP2 与 CRP3 随着 CRP1 阶段转入 CRP2,夏去秋来,实施团队发现自己面临着实施中最具厚度、最为艰难的 部分。项目范围已经有所扩大,包含了重大改良和新的售后支持软件包。另一项重要的范围变更也 即将出现。由于这个项目对下游的影响超过预期,团队决定解决部分较大的技术问题。尽管之前系 统设计为可直接彼此通信(即“点对点”) ,但现在将部署新的方式,其中所有数据通信都将通过“数据 仓库”执行。采用数据仓库可让思科公司的所有应用程序都可访问单一来源,满足信息需求。 范围变更意味着进一步改变思科资源的利用情况, 尤其针对公司内部拥有 100 名员工的 IT 部门。 范围改变具有技术性质,意味着这个团队将承担项目新增内容的大部分责任。斯洛维科这样描述这 一结果: 基本上,IT 团队的所有其余人员都开始脱离其他项目。他们表示:“我们必须花时间接受这 一事实,即公司内的核心系统正在发生变化。我们需要为这个项目投入越来越多的精力和越来 越多的资源。 ”那一年,IT 部门完全没有执行其他任务。我们还决定不在这个项目中转换历史记 录。相反,数据仓库团队建立起了在一体化的数据转换中报告历史和未来数据的能力。我们对 客户进行了重新编号;我们对产品进行了重新编号;我们还改变了材料单结构。我们基本上改 变了公司内的所有潜在数据,数据仓库成为了将历史和未来记录融为一体的桥接系统。 到 CRP2 结束时,第一轮改良已经到位,正在运行。在此期间,实施团队继续深化自身对甲骨 文和服务软件包的理解,确定如何更好地使它们为思科服务。CRP2 的最终目标是开始系统软硬件的 测试,根据思科公司日益增长的业务需求,了解其应对处理载荷和交易量的情况。 CRP3 的焦点在于测试完整的系统,并评估公司对“上线”的准备度。公司的全体用户执行了最终 测试,了解这个系统在完全交易载荷的情况下从前台到后台的表现。实施团队捕捉了相当于一整天 的实际业务数据,并在 1 月的一个星期六“重新运行”,执行了这些测试。团队成员观察每条路线轮流 执行相当于一整天的模拟工作。这项测试的完成令整个团队颇感满意,因此,每个人都觉得已经为 2 月的全面切换做好了充分准备。庞德这样描述结束 CRP3 阶段的仪式: 10 .

当 CRP3 结束时,每位职能部门主管都展示了各自的流程部分,确定否准备继续进展。我们 让他们每个人分别进行,然后让所有人汇集在同一个房间,让他们点头,说“我们应该继续。”…… 然后,我们就开启了这个系统…… 切换至甲骨文系统 ……[切换后,]我不能说一败涂地,但是我们每天都遭遇重大挑战,需要快速解决,才能避免 对公司造成严重影响。例如,我们的准时发货率(在我们向客户承诺的日期发货)从 95%下跌到约 75%,这还谈不上痛苦,但也不是好事。 ——皮特·斯洛维科 至少可以这样说,思科公司切换至甲骨文系统的初始成功不如预期。用户们试图应对新的系统, 而事实证明这个系统并不稳定,令人恼火,因此,总体业绩直线下跌。平均而言,这个系统几乎每 天要崩溃一次。人们发现,主要问题在于硬件架构和规模。要正常纠正缺陷,需要采购额外的硬件, 因此会提高项目的总开支。但思科公司要求硬件供应商签订一份不同寻常的合约,而且如愿以偿。 在合约中,思科公司根据承诺性能来采购设备,而不是根据具体配置。因此,解决硬件性能问题的 责任完全落在硬件供应商身上。 第二个问题和软件本身处理思科环境中所需交易量的能力有关。这项应用程序的设计对常见任 务的处理效率低下,因而令硬件问题更加恶化。回顾以往,就会明确发现公司在系统的最终测试中 哪些地方出错了。正如庞德所说的:“在遭遇大量数据时,就会出现一些严重问题,……而我们的数 据库十分庞大。我们的错误在于并没有连接足够大的数据库,同时对系统进行测试。”在测试系统时, 思科公司依次运行单个流程,而不是同时运行。此外,也只使用了部分载荷的数据库。切换后,当 所有流程同时在完全转换后的数据库上运行时,系统缺乏处理所需载荷的容量。 接下来的两个月是整个实施中最具考验的时刻。对 IT 人员尤其如此,这个部门试图改善新系统, 解决因此产生的技术难题。费描述了当时的情况: 非常棘手,压力很大。这是一个大项目,公司的首要项目之一。众人瞩目,期待它的完成。 我们一直在加班,做出将会在未来影响企业的决定……。我们都明白,我们能够成功。问题总 是“何时成功”,而不是“是否会成功”。我们对[这个软件]存在[许多]不满意的地方。 ERP 项目的状态成为每周高管例会的首要议题。甲骨文公司、硬件供应商和毕马威的有力承诺 11 .

令软件最终稳定下来,性能也有所改善。斯洛维科这样描述当时的环境: 在大约 60 天中,我们完全处于“霹雳小组”模式,致力于令情况好转。例如,硬件供应商的 总裁是我们的高管支持者。这家供应商一度在现场部署了约 30 名人员。他们全力以赴。在这 个重要阶段,他们遭遇着亏损。能够获得这个大项目,对他们很有利,但也是一次艰难的经历。 还记得吗,我们采购的是性能,因此他们为了增加容量而采取的一切行动都必须自掏腰包。 稳定化之后 事实证明,与甲骨文系统实施有关的技术问题只是暂时的。在接下来的三个月中,思科公司及 其供应商携手合作,致力于稳定,并为系统增加容量。艰难的实施工作结束时,团队和公司管理层 举行了庆祝派对。思科公司董事会的多名成员也出席了活动。人们兴高采烈,认为新的信息系统将 会履行承诺,支持公司预期的快速增长。 在签字确认奖金分配的建议时,斯洛维科思考了他们对实施所采取的方式。 “在 9 个月中,花费 1500 万美元,更换整个系统,谁会想到我们居然做成了?”他试图思考自己和团队在实施过程中做 出的决定。哪些因素决定成功还是失败?他们在哪些方面十分明智?在哪些方面只是运气很好?如 果有必要,他们能够再次实现成功? 12 .

470 $466.086 $563.490.999 $111.977.000 1.000 $3.833 $12.附录 1 财务数据和思科公司的其他统计数据 年度截止于 销售净额 1998 年 7 月 25 日 1997 年 7 月 26 日 1996 年 7 月 28 日 1995 年 7 月 30 日 所得税拨备前收入 $8.409 $546.000 $1.417 $22.464.000 8.000 $456.893.000 $737.000 $6.988.489.000 11.048.782 4.61 $0.415 $90.984.000 $65.078.173.000 $1.440.825.039.000 $913.32 1.888.171.000 1.232.91 美元。 13 .08 亿美元以及出售少数股权投资的已实现收益 1.000 $1.072.53 亿美元。预估净收入和每股摊薄收益(不含扣除 税项的非经常性项目)分别为 1.777.007.413.334 $103.84 $0.458.705.000 美元和 1.425.466.000 $5.167 $35.949.324.005 $95.872.679.916.878.17 美元。 b 1997 年,净收入和每股净收益包括采购研发费用 5.000 $1.630.000 $2.000 $2.458 15.918 $585.000 $8.000 $4.652.000 净收入 a,b,c $1.608.551.302.451.247.232.000 1.350.720 普通股每股净收益(摊薄)d 每股数据计算中所用股票数(摊薄) 资产合计 财务年度结束前最后一个周五股价 e 雇员人数 f 雇员人均销售净额 雇员人均净收入 数据来源:1998 年年报和 1998 年 10-K 表。 a 1998 年的净收入和每股净收益包括采购研发费用 9400 万美元以及出售少数股权投资的已实现收益 500 万美元。预估净收入和每股摊薄净收益(不含扣 除税项的非经常性项目)分别为 1.096.000 $0.000 美元和 0.68 $0.991.

36 美元。 d 反映 1998 年 9 月生效的每两股配三股配股方案。 e 股价反映 1996 年 2 月生效的每股配两股配股方案、1997 年 11 月生效的每两股配三股配股方案以及 1998 年 9 月生效的每两股配三股配股方案。 f 员工人数来自相应的 10-K 表。 14 .000 美元 和 0.c 1995 年,净收入和每股净收益包括采购研发费用 9600 万美元。预估净收入和每股摊薄收益(不含扣除税项的非经常性项目)分别为 515.723.

附录 2 ERP 实施重要节点日期概要 项目启动 1994 年 6 月 2 日 原型建设完成 1994 年 7 月 22 日 实施团队培训 1994 年 7 月 31 日 流程、关键数据、改良设计完成 1994 年 8 月 31 日 职能部门流程批准 1994 年 9 月 30 日 硬件标杆和容量方案得到验证 1994 年 10 月 15 日 关键界面、改良和报告完成 1994 年 12 月 1 日 程序和最终用户文档完成 1994 年 12 月 16 日 会议室试点完成——有关是否继续实施的决定 1994 年 12 月 22 日 最终用户培训开始 1995 年 1 月 3 日 数据转换完成 1995 年 1 月 27 日 上线! 1995 年 1 月 30 日 资料来源:思科公司 ERP 指导委员会报告,1994 年 10 月 20 日。 15 .

附录 3 思科公司 ERP 实施成本细分 a 思科公司 ERP 实施成本细分 软件 硬件 系统集成 人员 资料来源:思科公司 ERP 指导委员会报告,1994 年 10 月 20 日。 a 项目预算估计值不包含核心团队部分成员之外的思科人员工时成本估算。 16 .

附录 4 思科公司 ERP 实施团队结构 思科 ERP 实施团队结构 执行指导委员会 项目管理办公室 订单录入路线 制造路线 财务路线 销售/报告路线 技术路线 业务主管 业务主管 业务主管 IT 主管 IT 主管 IT 主管 IT 主管 IT 主管 商业顾问 IT 顾问 商业顾问 商业顾问 商业顾问 IT 顾问 IT 顾问 IT 顾问 IT 顾问 用户 用户 用户 17 .

根据订单录入流程录入订单 2. 选择 View Schedule Results f. 运行 Process Exception/Report/Navigate Other Report Run a. 如果订单为政府费率或快速费率,根据订单录入流程填写订单行项目 订单录入流程 a.附录 5 业务流程脚本样本 ATP 流程: 范围:本流程将定义“承诺可用”(ATP)流程将如何运作。本流程将包含如何将信息录入 ATP,如何 维护 ATP,如何访问 ATP 信息,以及此类信息应如何使用。 政策: 所有销售订单将根据 ATP 日期分配预先安排的发货日期 Master Scheduling 安排将维护 ATP 信息 如果客户并未注明请求日期,请求日期将留空 日程日期将为今日起一周后 订单日程安排流程: CS 代表 1. 如果 ATP 日期匹配安排日期,并且下方未列出失败原因,转到步骤 g。如果存在错误,订单 必须安排为集团可用日期,或按顺序更改参数 g. 如果日期可用,订单将出现在界面上 c. 选择订单拒收的日期范围 e. 完成后,再按 Page Down e. 为 Program Number 选择 Demand Interface d. 在订单 Booking 后,按 Page Down b. 根据订单录入流程输入客户请求日期 3. 选择 Order…(Order Action Quick Pick) c. 如果订单不符合上述情况,根据订单录入流程 Book 订单 a. 如果日期不可用,订单将在需求界面运行后保持合格状态 订单日程安排程序 5. 选择 ATP Inquiry Order d. 在 Type 下选择 Report b. 选择 Process Exception Report c. 订单将自动提交 Demand Interface b. 选择需求 。系统将表明日程安排完成 4. 再次选择 Page Down,并选择 Choose order… h. 提交报告(F5) 18 .

运行在线 ATP 流程,确认订单发货的首个可用日期 a. 再次选择 Page Down,并选择 Choose order… 选择需求:系统将表明日程安排完成 19 . 选择 ATP Inquiry Order f. 如果 ATP 日期匹配安排日期,并且下方未列出失败原因,转到步骤 g。如果存在错误,订单 必须安排为集团可用日期,或按顺序更改参数 h. 查询之前日程安排失败的订单 c. 按 Page Down d. 选择 View Schedule Results g. 转到 Order/Navigate Orders Enter b.6. 选择 Order…(Order Action Quick Pick) e.

承诺日期、安排日期和申请日期具体 定义?如何填写? 7. Demand Interface 发生一次后,从安排日期修改为默认承诺日期。对安排日期的未来变更不应影 响申请日期 ATP 流程问题 1.附录 5(续上页) ATP 系统问题 1. 我们如何保证 Master Scheduling 增加 ATP 时,要求该日期的订单将按时收到?(分发问题) 4. Process Exception Report 需要根据 Order Request Date 排列 4. DOA 订单将如何运作,以便尽快发货? 5. Demand Interface 读取的表格从不清除或清理。因此,失败记录不会在成功后清除。需要在每次 运行前对 Demand Interface 表格进行一定程度的清理 3. 如何控制 Master Scheduling 的使用?请勿使用/Buffer Demand Class? 评论:流程问题 1 对于服务客户领域的需求类别,此项责任完全在于客户服务组织内部。未经 Master Scheduling(为 避免影响营收计划)或 Buffer Demand Class 的批准,客户服务部门不允许将可用数量从 Non-Revenue 需求类别移动。 评论:流程问题 2 开放问题:客户服务部门应负责解决 评论:流程问题 3 如果产品可用,Master Scheduling 将改变订单和在线界面上的需求类别,以避免造成沟通混淆问题 (将在会议室试点项目中测试) 评论:流程问题 5 伊丽莎白和凯文将通过 Master Scheduling 处理这个问题,以确定最佳解决办法。 评论:流程问题 6 无 评论:流程问题 7 申请日期是客户申请从思科发货的日期。承诺日期是思科承诺将订单向客户发货的日期。安排日期 是制造部门所用的日期,用于分配 ATP,如果某个订单错过,则用于将生产日期的变更通知客户服 务部门。 20 . 谁将负责决定使用来自另一个需求类别的产品?根据何种方针? 2. Process Exception 报告目前需要 Demand Interface Concurrent Manager ID 方可使用(由于漏洞) 2. 是否应允许客户服务部门为任何保留使用 Buffer(请勿使用)需求类别? 6. 谁将决定清除哪些订单,以便将订单添加到 ATP 日期?根据何种方针? 3.

资料来源:思科公司。 21 .

日历 已完成 12 日历时期 会计 全部 13 货币 会计 全部 美元 已完成 14 账簿集 会计 全部 14 个账簿集 已完成 15 职能部门设置 16 账户等级和汇总类别 会计 全部 17 交叉验证规则 会计 全部 18 安全规则 会计 全部 19 速记别名 会计 全部 20 暂停账户和公司间账户 会计 全部 已完成 21 指标统计单位 会计 全部 已完成 已完成 进行中 22 .附录 6 原型追踪表样本 A 1 2 3 4 应用 B 类型 C D 相关模块 必要 E 备注 F 状态 财务与分类帐 系统设置 5 会计 Flexfield 结构 Flexfield 全部 是 5段 已完成 6 数值集和数值——公司 Flexfield 全部 是 3位 已完成 7 数值集和数值——部门 Flexfield 全部 是 6位 已完成 8 数值集和数值——账户 Flexfield 全部 是 5位 已完成 9 数值集和数值——项目 Flexfield 全部 是 4位 已完成 10 数值集和数值——产品 Flexfield 全部 是 3位 已完成 11 日历时期类型 会计 全部 4-4-5.

22 会计 flexfield 组合 会计 全部 23 每日汇率类型 翻译 全部 24 汇率 翻译 全部 25 概要账户和模板 概要 GL 26 JE 来源和类别 JE GL 27 职能部门测试案例 28 人工日记账录入 JE GL 29 经常性日记账录入 JE GL 30 大批量分配公式——租金分配 JE GL 31 逆向日记账分配 JE GL 32 日记账导入 JE GL 33 在线查询 查询 GL 34 翻译 翻译 GL 35 定义预算和预算组织 预算 GL 已完成 是 已完成 资料来源:思科公司。 23 .

附录 7 思科公司 ERP 实施“红色”改良列表 包装:  为制造目的创建“旅行者”(即需要配置的项目列表),根据生产单元对旅行者排列队列,让每个 单元可根据需要印刷自身文档(而不是其他单元文档)。  纸箱装满时,可扫描条形码,以记录每个箱子的内容。分配一个纸箱追踪编号,并提示产品序 列号录入。存储序列号,以供未来使用,并避免充分签发。  纸箱关闭时,从系统中回洗库存。  确定箱子可供发货还是等待与其他箱子合并,并将其分发至适当的发货地点。如果可发货,将 直接发货,如果箱子准备合并,则通过其在合并中心的收货进行追踪。  当一个发货集中的最后一个箱子在合并中心收到时,对其进行表示,并指示人员准备发货。 加拿大:  为分类帐和应收账款创建独立装置,有单独的账簿集和单独的货币。  允许思科分类帐合并的数据转移。 产品配置器:  已允许思科采用逻辑方式输入有关可订购性(订购的实际和技术限制)的“规则”,而不是通过代 码。  已绑定订单录入——预订订单时,根据配置器验证。 OE 表:  已变更从主订单线到附属订单线的折扣翻译流程。还改变了价格信息载入甲骨文系统的方式。  已建立了允许将起岸成本数据录入订单的功能。  已建立了允许跨国订单的功能——出账地点为美国,但发货在美国境外  已添加了新字段,以捕捉额外的销售订单数据  已在预订时添加了触发变量,以呼叫配置器。 净变更预订:  每日创建预订的信息“摘要”。  创建所有订单活动(加减)日志,然后由多个其他系统用于报告。 24 .