Radically Simple IT

彻底简化IT

彻底简化IT

通过一种不同的方式设计和部署企业级IT系统，日本新生银行1（Shinsei Bank）把IT从“不得不做”变成了一种发展的原动力。

—— David M. Upton & Bradley R. Staats2

企业IT项目——无论定制还是集成“一个能适用于大多数”的系统——一直是企业领导者的一个很大的烦恼。这些系统的根本问题在于它们大部分都被构建在，一个被程序员或者开源斗士Eric Raymond 3“大教堂”的方式之上的。像中世纪的欧洲的代表性巨大建筑一样，企业IT项目通常代价巨大、耗时，而且直至最终交付才会生效。最终，产生了一个并不灵活，但把公司的业务固化成在这个系统里，虽然这已经是几年前项目刚开始时的业务状况了。不论后来在软件包灵活性上的如何改进，公司总是发现非常困难而且代价巨大，来改进系统以适应新的商业变化。称之为

不同于这种构建一个从上线第一天就过时了的方式，管理者们能够而且应该开发一种——能够被快速而且持续改进的系统，即使在发布了以后。在过去的十年，笔者研究了企业IT系统的设计应用，而且帮助为数众多的公司改善流程。通过我们的研究，发现了一种方式，不仅可以减少企业的投入成本而且能够支持持续的商业变化和新领域的开发。我们称之为"基于途中(path based)"开发方式，不同于在系统发布以前，试图定义整个的所有方方面面的做法，而是致力提供一种能够延期开发的方式。

(…… waiting for inputting of oskiwi)

建立的一个常规的企业信息系统通常有两种选择：用全新的信息系统与业务处理流程将现有的企业信息系统一下子替换掉的“大爆炸法”，和将现有系统一点一点地用新系统替换或者升级的“递增法”。 Dvivedi和他的队对“大爆炸法”的可行性表示怀疑，他们相信“大爆炸法”对于银行的现金约束的危险是相当巨大的，而且在将这样的将目本地化的时候会遇到很多的困难。如果使用“递增法”，那么，整个计划的实施可能需要3到5年的时间，这对于他们的要求来说相差的太多了。因此他们决定探索第三条道路。他们将探索一个新的领域，他们将建立一个模块化系统，这个系统起初和企业现有的管理信息系统将会平行运行，但是最终代替当前基础设施。根据传统的IT系统理念，这样做无疑是相当疯狂的。用于连接新老系统是他们能够实现平行运行的桥接系统将的开发将会需要极大的努力。

但是Dvivedi从之前的经验和与他的交谈的其他CIOs中知道，技术问题从未成为阻碍信息系统构建中的原因，人的问题才是。人们通常会习惯性的抵制新的管理信息系统，通常情况下，这是因为他们认为这样做的成本要大于这个系统给他们带来的收益。为了向其他人说明这点，Dvivedi使用了很简单，但是令人感到不快的方法给了大家活生生的体验。例如，通过模仿现有的企业信息管理系统的低下的效率，使Dvivedi和他的队能加速新的系统的建设。(…… waiting for inputting of oskiwi)

别只是列出你的商务和企业IT战略——把他们结合起来

商业战略和IT策略因该要紧密联系起来，因此业务用户要被引入到企业系统设计这一观点被广泛接受。但由于种种原因，这也被（实践）证明非常难于实施。首先，IT的领导们尽全力去了解业务背景；另方面，业务部门的领导却不肯投入足够的时间关注来自技术方面的挑战，仅仅把IT部门的人员当成二级服务单位。即使两个部门同时讨论一个项目的时候，也容易互相割裂开来考虑问题，而不是作为一个整体。但是不管你承认与否，在今天的各行各业中，信息系统已经成为了完整的商业策略的一部分。如果业务高层把IT看成一个辅助，而不是合作伙伴，那么在这两个团队之间知识共享就遭殃了，结果就是错失良机还有效果差强人意。

复杂一点的情况是，当一个企业采用了标准的软件套件，通常就宣告业务部门信息化的过程完成了。事实上，有时这会让业务部门放弃了低效率的流程而且学会了那些包含在软件中的最佳实践。但是更多情况并不是，（业务）管理者们牺牲了一些原本业务的特质的，最有竞争力的部分。本来这些功能是可以在系统中实现的，但由于开发这些功能会让本来就已昂贵而且紧迫的项目更加不堪（而不得不放弃）。

那么一个企业如何做才能结合好IT和企业战略的关系呢?在计划开始以前,综合管理者需要确信IT员工充分理解业务而且在组织中担当核心角色。一个有效的方式是让CIO直接报告给CEO或者COO（像Dvivedi在新生银行做的那样），而不是像很多公司那样报告给CFO——通常态度决定效果。

业务管理者也需要充分了解IT能干什么。在新生银行，八城（Yashiro）和他的继任，Thierry Porte投资了大量的时间来了解IT。Porte经常和Dvivedi一同交谈，每周至少有一次正式的例会，同时访问公司的IT和操做中心至少每个月一次。Porte相信作为CEO，“我必须能够向客户和员工解释IT如何让我们满足客户需求甚至提前交付”。

在项目开发上，第一步是要集中精力在公司的前瞻性业务上，而不是现有的环境。很多公司花费了所有的精力来考虑如何让既存的系统在现有的流程之上完成工作，这导致一直在老路上徘徊。任何人想要在波士顿或者伦敦的谜一样的路上驾驶都要明白方向的重要。

确定了目标，老板们还必须建立IT策略来达到它们。这必须是与时俱进的：得在IT和业务之间有持续的交互，在商业目标和IT的决策和约束措施上。双方渐渐能用同样的观点来沟通，当业务用户教会系统人员他们的需要同时，IT把新的原型放到业务人员面前，潜在的更好的方案就产生了。

在IT和业务团队之间紧密的联系帮助新生银行利用技术驱动来提高客户体验。比如，新生银行的出纳台安装2个屏幕——一个面向出纳人员，另一个对着客户，客户的屏幕界面和网上银行是一样的，同时出纳的屏幕上显示同样内容并附加客户信息。当一个客户打算开始一笔业务，出纳可以书面的向客户展示如何自己执行这个操做（将来他/她可能自己在家里的PC或者ATM上做同样的事，实际上用户同时在被培训为将来做准备）。出纳本身是不经手现金的，如果用户打算存或取钱，那么人员会和客户一同去ATM完成这个业务，在客户自己的参与中。客户不会被要求自助服务，但是通过IT 系统和其他设备（分支，ATMs，出纳），新生银行提供了高水平的服务，同时培训并鼓励客户自己来完成某种特定的业务。

同时出纳前台人员也可以直接看到什么样的业务对于客户来说是很麻烦的，大量的改进系统的点子也就应蕴而生了。举个例子，当客户在做类似开户之类的业务或者转移基金时，需要填写各种表单交给前台，并由出纳人员录入系统。出纳发现客户经常会选错表格而且填写也不正确。为了解决这个问题，新生银行改变了工作流程。现在出纳们从客户那里得到信息然后录入系统，然后生产一个即时确认让客户来承认。

向超级简化而努力

William of Ockham，中世纪的哲人说过，理论应该尽可能的简单。同样的原则适用于企业IT系统：他们会被设计成为尽可能少的标准（例如网络协议，操作系统或者平台）——理想状况是每种只有单一方案。通常组织会从少部分的标准开始，然后慢慢运行它们膨胀，随着并购或者个别的业务创新。另外，技术方案选择或者开发来满足特殊需要时应该尽可能简单，要估计到有可能失败而且有办法去掉他们，而且尽可能的可以被复用。

・最小标准化。标准化的小模块对“基于途中”开发来说至关重要。西南航空公司只购买一种飞机波音737，来获益，简化IT构建允许公司减小复杂的，高度专业的技术，而且增加了潜在的可以重用的系统组件——这也加速开发和低成本维护。另外，标准化组件减少组织在维护时间的投入，转而构建更多的新功能。

事实上，来自外部的“大爆炸法”开发软件供应商的经常带来一个最大的资源消耗是他们经常限制组织原有的标准而倾向用他们自己的那套。大多数的IT管理者没有力量或者长期的训练能够自己维护。那意味着业务管理者必须理解技术而且理解折衷方案，为的是避免使IT系统割裂开。

Dvivedi在新生银行果断的采取了标准化。他征求了相关人员的意见但是并没有等到取得一致意见就开始了行动。一个最根本的决定是削减新生银行原来的大型机系统——传统的银行系统的主干，取而代之的是采用基于Intel的服务器。这是一个非常大的变化，区别于日本银行乃至全世界的大多数金融服务机构，通常这些机构都倾向大型机的高吞吐速度还有可靠性。问题是，大型机系统非常的昂贵且难于维护（通常年维护费用是当初购买价格的15%～20%）。大型机的软件系统的软件多为一些难于理解的专有语言书写，即使是找到对代码很熟悉的程序员也不容易维护。这种向Intel服务器的变化立即为银行节约了每年4千万美元。随着选择了单一服务器平台，Dvivedi和他的团队选择了一系列其他标准，诸如Dell计算机，微软OS，互联网，IP电话还有和其他商业系统之间的标准消息（邮件或者即时通讯：译者）。

・简单，而且可重用的解决方案。没有等新银行（像商用和投资银行一样进入零售领域的业务）被现有技术制约，Dvivedi和他的团队建立了一种构架，可以让新生银行一旦发现业务问题马上就找到所在。这包括一个坚持执行的应急解决预案。在第一次发现业务问题时，他们会中断系统把问题分成不同的部分然后对每一部分决定技术解决方案。如何能做到呢，首先他们仔细分析了现有标准组件，以确定是否已经有了解决方案；如果没有，然后转向外部的现成方案；如果还没有，把这个问题转拿到5或6个印度软件合作伙伴之一去来开发这个功能。

新生银行的全新ATM网络从定义到开发的全过程是个很好的例证。在2000年，其他的日本银行会收取费用，在用他们的ATM的时候，而竞争者只在正常业务时段提供ATM服务。新生银行意识到如果要提供24小时的免费服务，不可能用一个像其他银行一样的网络。因此，业务和IT共同按功能定义了他们要提供的，然后尽可能分解了可能出现的问题。这使得他们能以一种更新、而且经济的方式解决问题。例如，传统的ATM通过昂贵的租用专线连接到银行后台系统。在这里意识到因特网可以起同样的效果，虽然上线时间、可靠性要差一些。一个简单的解决方法就是：安装2条因特网接入不同的供应商。这就达到了租用专线的效果，但费用仅仅是十分之一。总而言之，新的办法使得新生银行能提供给客户ATM服务，比竞争对手更多的功能，而只是很少的代价。

另外一个很好的例子是如何解决IT团队的内存泄漏问题。任何操作系统都可能有这个现象——当应用程序结束运行而没有释放内存。最终操作系统可能会变得不稳定，甚至宕机。通常的解决方法是设计精密的内存管理管理还有调试工具来尽可能避免任何内存泄漏发生。但是，即便这样的工具也不能百分百的防止问题发生，新生银行决定简单的假设内存泄漏是不可避免的，每隔一段时间交错的重新启动所有服务器——一个看似粗暴但是很有效而且经济的方式。

无论Dvivedi的团队内部开发一个组件或是从供应商那里取得，它一定是可以最大程度重用在其他新生银行的系统的。为了确保这点，这个团队清晰的描绘出每个组件的需求功能和标准接口，使得它能其他现存或者将来的模块交互。比方说，业务部门和IT人员很早意识到信用检查是很多银行提供的为数众多的服务中一个关键流程。因此，他们开发了一种可复用的信用检查模块，部署到不同产品中。今天，超过90%的组件被用在一个以上的地方。

・模块性，但不仅是模块。当主流的观点——大的IT程序和系统应该集成模块还是很新的的时候，模块性经常被误解。只是因为一个软件开发者说道：应用程序的不同部分已经分成模块不意味着他们就真的是模块了。模块性包含清晰的接口定义，这样才能让代发工作在不影响其他的基础上完成。公司经常在开发企业系统时会忽视这点。比如，我们知道一个汽车厂在企业系统上有很多不同分工的团队，以及模块设计。其中一个负责接口的小组不断的改变设计，每次这个小组的变化都会要求其他所有的人花费大量时间重复做他们已经做过的事情。实际上，这家公司是在制造麻烦，而不是把模块化的影响降低到最低限度。

一个真正的模块化构架允许设计者集中精力解决自身的问题而不会影响全局。而用小的模块化的设计，组织可以购买一些现成的解决方案或者定制一些特定的部分，来加速开发过程。模块框架也能加速模块的技术升级。

分解问题并一一解决不仅带来速度上的优势。它还允许IT团队专注于为每一部分找到最低代价的解决方案，来减少一个部分失败带来的风险性。清晰定义的模块功能和接口使得它易于在其他应用中再次使用。

模块化方式是取得银行策略的关键部分，Dvivedi这样形容，“按比例的提高和膨胀，能够服务于组织的成长，就像从一个婴儿长成一个大人…但也要避免不需要的过度的容量”。以处理贷款来说，项目组长给出了小范围容量，基于3个理由：为了证明计算机系统管理可以做到像承诺的一样，不用突然给管理和用户一下带来过多的自动化，能够发现技术问题在它们发生的时候。因此，一开始系统表现出可以正确的批准少部分（20到30件/每天）贷款信用；然后开发增加到200到300件每天。随着业务的增长，新生银行逐渐减少手工作业，达到一天可以处理6000件的容量。

得益于自动系统的模块结构，新生银行能够轻而易举的更换任一部分（比如，贷款或者信用检查），而无需影响其他。另外，模块化也让新生银行变化它的信息系统，在方便必要的时刻，无需让客户觉察到。比如它能让用户界面（web页面或者ATM屏幕）不变而同时更新后台系统。

（适当）授权给人员

许多大型IT项目失败始于组织内部的抵制——用户不情愿去用，而并非是技术不好用。有的时候是公司试图强迫把系统强加给人们，而他们抵制；更常见的是人员根本没有一个必须的理由去努力学习如何操做一个新的系统。

通常大公司不必让用户用新系统，他们更愿意让用户主动来欢迎系统。这并不是说要让组织内的每一个人都疯狂的爱上每项要采取的技术。但是如果一个系统要让大多数人经过一个讨厌的“来认识你”的阶段，似乎就是说这个系统需要做重大的改进或者直接废弃了。

当新生银行引入一个新的系统时，它以提供（用户）一个接口、界面或者屏幕格式的方式，而这些都是尽可能模仿旧系统的。一个新生银行的雇员在开始用新系统输入贷款信息的时候，可以找到一个几乎完全是旧系统复制品的界面来输入，但是如果新系统需要的信息（比如客户的手机号码）在旧系统里没有的话，员工必须到新的界面上录入。通过这种向上兼容的方式，用户变得习惯于新系统。只有当绝大多数用户转变到新系统上来的时候，Dvivedi的团队才会关闭旧系统的输入界面。这种方式在短期内会增加一些成本，但是Dvivedi相信换取员工更乐于和快速的迁移到新系统来说这只是很小的代价。

・持续改进。Dvivedi的信念是用户的力量会超出系统的引入阶段。这也适用持续的改进。一个基本原则是任何持续改进的努力如果没有用户的同意必将失败。新生银行积极的向用户征求改进企业系统的主意，把用户包括在日常的改进测试中，努力让他们感到自己在出谋划策。得意识到如果人们没有感觉到他们的意见被听取和迅速采取行动，那么他们就会停止发表。

最后，Dvivedi和他的团队建立了一个系统来收集来自最终客户、业务用户还有技术用户的反馈和需求。最近的几个月，这样的意见和需求平均每天达到了100条，建议和系统的失败信息形成了电子工作流程，被分发到相关的责任人或者转送到更高层，如果很长时间没有被处理的话。当一个问题被处理以后，那个提问题的人会被通知。

举个例子，反馈系统帮助业务领导发现抵押业务上有点毛病。当申请房贷的客户抱怨他们已经向新生银行提交了所需文档，而系统显示有问题，这个问题被自动通知给管理者们，一个业务和IT人员的小组被委派去查出根本原因。经过研究，发现真正的原因是银行已经发给客户一个有关提交文档的列表，但是客户不确定那些是（例如他们不知道自己是哪一种），自然客户提交了错误的文档。这个小组的解决方式是：让IT系统来自动识别客户需要提交的文档类型，然后发给客户恰好对应的范本，不多也不少。在第一时间确定客户发送了正确的文档以后，银行和客户双方都节约了时间也提高了客户满意度。这听上去不像是一个重大的突破——但是确实说到点子上了。当不断的持续改进被集合到每天日常工作中，简单的口号激发了生产力，而减少了个人英雄式的解决问题。

……

现在企业大约花费5%的收入在IT上。当巨大的差异出现在投入上，同时也有甚至更巨大差异在企业因此而获益上。如果有什么事，那些选择了正确的IT系统的艰巨任务——那些支持了业务战略，提供有竞争力的优势，有个可以供发展的平台——都在变得更具挑战。那是因为越是好的选择，变化也越快，随着更加低廉的推动力，网络，还有发展中国家成熟的IT供应商的到来，也变得更加复杂。

在这样一个商业世界里，必须要建立一个能不断改进的IT系统。对于那些传统的管理者来说，认为构建一个IT系统就像建造一个大仓库：“建立它，然后完工”这样想法的话，前景是很不乐观的。这不再适用于IT，如果你打算建立企业系统，一个不变的、代价昂贵的从上线第一天就过时的系统。反之，如果采取一种“基于途中”开发的方式，你可以取得更多的灵活性，随时根据业务需要而改变，使得IT不再是现有操作的简单平台，而是新的商业功能和品牌的发射场。

1日本新生银行，托生于日本旧长期信用银行，1998年后由海外私募基金入主并改名。同时八城政基出任CEO，开始了传奇式的“新生”http://www.caneb.com/Case/GeneralFunction/Finance/200501/3589.html  http://www.rieti.go.jp/cn/papers/journal/0505/bs01.html

2本文原载哈佛商业评论（Harvard Business Review | hbr.org）2008年三月期 P118～124

作者David M.Upton(dupton@hbs.edu )任职Albert J.Weatherhead III of Business Administration 与Bradley R. Staats(bstaats@hbs.edu ) 在波士顿哈佛商务学院技术与管理操作管理方向攻读博士

3Eric Raymond ，著名开源程序的倡导和实践者，最著名的著作是《大教堂和集市》，http://www.catb.org/~esr/