【IT168 专稿】作为思科公司的CIO，皮特·索尔维克对他的ERP实施预算中的最后一条产品线进行了考虑。思科有用现金奖励业绩的历史，但分配给ERP小组超过20，000美元的现金还是比较独特的。要知道，他们这次是在没有人认为可能的时间内完成了工作，而且工作本身也很不容易。
没有弹性的旧系统
随着Internet技术的出现，思科公司的产品越来越供不应求，公司迅速占领了网络产品市场。1998年7月17日，仅仅在公司成立14年之后，思科公司的市值就超过了1000亿美元，为1997年销售额的15倍。
皮特·索尔维克1993年1月加入思科公司时，公司的核心交易过程主要是由基于UNIX的软件包支持的。索尔维克的经验和思科公司的前景使他相信思科需要一次改变：现有的应用系统没有提供他们所需要的冗余性、可靠性和可维护性，它已经变成了意大利面条，完全没有弹性，软件供应商也不提供任何升级版。“当我们实现我们的目标时，我们的系统也应该更可靠、有更高的冗余度。而不是当我们已经是一家价值高达10亿美元的公司时，我们的软件包还只是与3亿美元相适应的软件包。”他说。
索尔维克最初的打算不是采用ERP的解决方案；相反，他打算让每个职能部门自己做出选择何种应用并确定时间的决策。
在接下来的一年里，进展很慢。而且各职能部门系统更换的困难使得思科现有的环境持续恶化。当公司持续以每年80％的速度增长时，公司需要做的修补工作也在增加，系统的内耗变得有规律了，产品的瑕疵更增加了从这种系统内耗中复原的难度。
在1994年1月，思科现有的环境终于支撑不住了，这使得现有系统的缺点再也不能被忽略。这一年，一种未经授权的访问核心数据库的方法——这种方法本身是由于系统失灵才产生的——发生了功能紊乱，破坏了公司的核心数据库。最后，思科公司被迫关门两天。
思科公司在修复系统的过程中，终于认识到公司的系统一直运行在危险的边缘，随时都可能失灵。索尔维克等很多其他的思科管理人员得出结论：他们采纳的系统自愿替换方法并不足够，需要一个替代的方法。
索尔维克这样讲述他们所做的工作：“我们不能再谨慎地等下去，直到我们的订单输入、财务与制造工作都不能进行下去时，再进行三个独立的决策。”
选择产品
思科的管理层认识到满足企业需求要求各商业部门的共同参与，而不仅仅是IT部门的事。除了需要一支强有力的思科小组，公司还需要强有力的合作伙伴。索尔维克解释了选择KPMG作为整合伙伴的理由：KPMG来了，而且真地将投入这些应用视为成就一项事业的机会。与一些想要培训“新手”的公司不同，KPMG有一支在该行业有着丰富经验的队伍。例如参与这个项目的程序经理马克·李，已经是得克萨斯州一家完全实施了ERP系统的IT公司的董事长。
小组的约20名成员与KPMG一道将目光投向了软件市场，并用多分叉的方法来选择最好的软件包，思科在两天内将选择范围缩小到了五个软件包上。在高层对软件包进行评估后的一个星期，小组定下了两个候选软件包：Oracle与ERP市场另外一家重要企业。
小组花费10天时间写了要求与建议书（RFP），并送达了各供应商。当供应商在准备他们的答案时，思科小组则一如既往地勤奋。在这期间，他们拜访了由每家供应商提供的参考客户。在思科公司对RFP的回复进行分析之后，每家供应商都被邀请参加一个为期三天的软件展示会，以说明他们的软件包如何能满足思科的信息加工需求。思科提供样本数据，供应商则展示他们的软件是怎样满足（或不满足）关键需求的。经过反复斟酌，思科公司最后选择了Oracle。
制造部门主管雷德菲尔德讲了三点最终选择Oracle的主要理由：第一，该项目主要是由制造驱动的，而Oracle比其他供应商有更好的制造能力；第二，他们就软件包功能的长远开发上做了很多承诺。再就是距离很近的Oracle公司的软件包很有弹性。
董事会批准
在去董事会寻求批准意见之前，思科ERP小组需要回答两个很重要的问题：它要耗费多少资金？花费多长时间？他们知道他们的领导很担心大的项目失去控制，并产生非标准化的结果。尽管有一些风险，小组还是用实用方法对项目需求进行了估计。
公司设定了目标日期，然后对项目预算进行了估计。思科公司这一次也很大胆，正如皮特·索尔维克所说：“在确定了日期之后，我们对预算进行了估计。当还没有真地开始程序时，我们就把整件事做了通盘考虑。我们关心的只是项目到底涉及些什么。”没有做任何正式的商业案例（如财务分析）来说明项目对公司的影响，思科小组只是将注意力投放在影响他们分析的问题上。在索尔维克看来，思科除了前进没有其他选择。最终，思科小组承诺在9个月内、花费1500万美元来完成这个项目。
1500万美元是公司批准的规模最大的单笔资本项目。小组成员当初是颤抖着把这个数字交给公司高层领导的。与CEO默格里吉的初次碰头并没有消除他们的这种担心。
另一位部门主管邦德对与默格里吉的会面记忆犹新：皮特·索尔维克、汤姆·赫尔伯特与我把建议交给了默格里吉，他的反应很有意思。他这样评论：“你们知道，公司员工对于比这少得多的钱都是很在乎的。”皮特与我的脸色就像一张白纸。我们知道，如果我们失败了，我们就应该被子弹打死。失败并不是企业喜欢的事，尤其是当涉及到钱的事情时。
但是，董事会最后还是批准了那个项目。之后的几周与几个月之内，默格里吉发挥了他的作用，他让思科的其他员工都明白了ERP项目是公司的头等大事，而且把项目列入公司当年最重要的七个目标之一。
Oracle的实施
小组在项目的实施过程中，采用了一种被称为“快速循环的原型设计”的开发技术。采用这种技术，小组成员把实施过程划分成了一系列被称为“CRP”（Conference Room Pilot）的过程。每个CRP的目的是在前面工作的基础上进一步对软件进行理解，弄清它是如何在企业内发挥作用的。
第一个CRP（即CRP0）阶段是从对实施员工进行培训和建立技术环境开始的。项目小组在这个阶段同时进行这两项工作。一方面，集中精力培训员工，让他们熟悉Oracle的应用程序。在两周之内，项目小组的大部分成员都参加了这种对整个应用程序的“浸泡”式的培训。与此同时，一个名为“老虎之组”（tiger team）的小组正进行着另一件工作：安装应用程序并让它运行起来。
CRP0阶段实施的一个重要结果是思科不再坚持早期的一个实施目标，即避免修改ERP软件。避免修改之所以很重要，是因为软件改动常常都是公司行为，改动之后要升级到将来的版本就非常困难，而且很费时间。项目小组在第一个实施阶段的经验告诉他们，如果不对软件进行很多改动，它就不能有效地支持公司的业务。当一个月过去的时候，要做一些变动已经是很清楚的了；而两个月之后，做一些改变明显成为必要之举。
有了在CRP0阶段的教训，实施小组很快开始了CRP1。和先前的工作一样，这次的重点也是让系统不用修改就能很好地适应思科的业务流程。在CRP1阶段，小组成员制作了详细的底稿来记录完成每一个流程的目的与程序。为了保证所有的协同工作都得到解释，小组还设计了商业流程原型追踪表。与CRP0不同，小组成员将他们在建模过程中遇见的所有问题都记录了下来，并在由程序管理办公室每周召开的为时三小时的会议上提出来，让参加会议的各个部门的负责人来共同解决它们，从而推动整个项目向前发展。这个阶段的建模过程明确了软件的一些问题，确实有大量的商业流程该软件并不支持。
对于系统的不足，实施小组采取的应对措施是设计一种方法对每种不足进行分类和评估：“所有的修改要求被分为红色、黄色和绿色三类。每一类都要经由部门领导人的批准。其中，红色类的修改还必须有执行委员会的批准。”最后，总共需要30名开发人员三个月的时间来修改Oracle系统，以满足公司的实际需要。
发现需要对Oracle做一些修改使得项目计划和预算发生了一些意料之外的变化。除了要找到需要进行修改的地方之外，项目实施小组还发现Oracle的软件包不能充分支持公司的售后服务。因此，小组同时也开始评估和选择服务支持软件包。软件包被选定后，它的实施时间表也与整个项目的实施进度保持一致。思科的打算是让企业同时运行这两个软件包。
当从CRP1进入CRP2，也就是从夏天进入秋天以后，实施小组发现他们进入了实施任务最重、也是最困难的阶段。项目的范围已经扩大到所有重大的修改以及新的售后服务软件包。此外，另一个重要的范围也在发生变化。由于对后期项目的影响远远超过了预期程度，项目小组决定先解决一些重要的技术问题。在把各个系统直接连通起来之前（如点与点之间的连接），项目小组开发了—种新的技术，使得所有的数据通讯都通过一个“数据仓库”（data warehouse）来进行。利用数据仓库，可以让思科的所有应用系统只需要访问一个数据源，就可以获取他们所需要的信息。
范围的变化意味着思科进一步加强了对资源的利用，特别是对公司100人的IT部门的利用。很多范围的变化，由于技术上的原因，也要求IT部门承担起多数项目的附加责任。索尔维克是这样描述范围变化的结果的：
基本上，IT小组的所有其他人员都开始从其他项目上退了出来。他们说：“我们必须花时间以弄明白公司的核心系统正在发生改变这个事实，我们需要把越来越多的精力和资源转移到这个项目上来。”那一年，IT部门没有做任何其他事。我们也决定不再将任何历史的东西转移到这个项目上来。相反，由负责数据仓库的小组在一个整合的数据转换程序中对历史数据和将来的数据进行报告。我们重新清点了我们的客户、产品，对材料账单的结构做了变更，彻底更换了公司的所有基础数据，让数据仓库成为了联结历史和未来的沟通系统。
到CRP2结束时，第一阶段的修改开始发挥作用了。在CRP2，实施小组继续加深他们对Oracle和服务软件的理解，以判断如何才能使它们更好地为思科工作。CRP2的最终目标是开始对系统的软件和硬件进行测试，以判断它们是否能在思科业务量不断增长的情况下，正常地处理各种交易。
CRP3的重点是测试整个系统，并评估公司是否为系统的全面实施做好了准备。最后的测试是完全由用户来进行的，测试的目的是判断系统是否能从头到尾、正常地处理一笔完整的交易。实施小组的测试是这样进行的：他们先提取某天公司所有有价值的商业数据，并在一月的某个星期六重新在系统上运行它。在这个过程中，小组成员会监视每个部门模拟完成工作的情况。这个测试的结果令项目小组非常满意，以致在2月份，每个人都认为应该是接入新系统的时候了。
转移到Oracle
思科接入到Oracle其实并没有达到预期目的。“（在接入新系统后）公司遇上了重大的日常挑战。例如，在我们承诺向客户发运的日期，我们按时发运的比率从95％降到了大约75％；这虽然还不可怕，但至少不令人满意。”索尔维克这样说。
当用户尽力用并不稳定的新系统工作时，整个公司的业绩呈直线下降的趋势。总的说来，系统差不多每天都要出点问题。情况的进一步发展证实了主要的问题是硬件的结构与规模的问题。一般说来，更正这些缺陷需要购买额外的硬件，并因此增加项目的开支。但是，思科已经从硬件供应商那里要求并取得了一份不一般的合同。在这份合同里，思科购置的是满足一定处理能力的设备，而不是某一个具体的配置。因此，完善硬件功能的责任就完全落在了硬件供应商的头上。
第二个问题是如何让软件拥有处理思科公司所有交易的能力。应用系统的设计不能有效地完成普通的任务加剧了硬件的问题。回想起来，很显然公司在最后测试系统时肯定犯了某种错误。
接下来的两个月主要是尝试运行整个系统的时期，这一点对于IT工作人员来说尤其如此。在这期间，他们主要都在解决由于新系统的接入带来的各种技术问题。对于每周的执行员工会议来说，ERP项目的状态成了会议日程安排中的头等大事。来自Oracle、硬件供应商和KPMG的承诺最终让软件实现了稳定运行，并改善了性能。
索尔维克这样形容当时的情况：大约有60天左右的时间，我们一直处在SWAT小组的模式中，来扭转整个局面。例如，硬件供应商的主席是我们实施这个系统的主要发起者。该公司可能在每个实施点都派出了30名员工，以致这些员工简直是随处可见。他们这次损失了不少钱，对他们来说，这是一次重要的经历，但也是一次痛苦的经历——记住：我们购买的是一种能力，因此他们做的任何一件来增强这种能力的事都是在自掏腰包。
事情的发展说明，与Oracle的实施有关的技术问题总是短期的。在接下来的三个月里，思科与它的供应商共同努力，实现了系统的稳定运行，也进一步增强了系统的能力。艰难的实施过程最后以一个为小组和公司管理人员专门召开的庆祝晚会而告终。思科董事会的几名成员也出席了此次晚会。大家感觉都很好，认为新系统完全能满足公司预期的快速增长的需要。
当索尔维克在奖金分配方案上签字时，他回顾了整个项目的实施过程：“整个系统更换只需1500万美元，而且只用了9个月的时间；有谁当初想到了我们能把它做成？”他也想起了在实施过程中他和项目小组所做出的决策：是什么因素决定了项目的成功与失败？他们聪明的地方在哪里？他们幸运的地方在哪里？如果再让他们做一次，他们能把它做好吗？
