通过从不同的方式来设计和开发企业IT系统,日本新生银行将IT系统从对企业的约束变成了推动企业发展的动力。
企业的IT工程，不管是特殊定制的还是适合大多数企业的打包系统，长期以来，一直是令商业领袖们的头痛的事情。其中最根本的问题是他们雇用什么样的程序员来构建系统还是使用Eric Raymond的开放源代码的系统接口，而且这个问题是相当重要的。就像中世纪时欧洲建造的一座座举行建筑一样，企业的IT项目不仅耗资巨大，需要耗费相当长的时间，而且仅仅在刚刚建成的时候才会发挥效用。最后，他们会放弃那些僵化的系统，并且会使企业的工作效率回归到几年前项目刚刚开始时候的样子。尽管最近出现了一些强化打包系统灵活性的进展，但是企业还是会发现，为了开拓新的商机来重新调整这些系统是相当困难而且需要花费昂贵的成本的。
与其构建那些建立初期就会马上过时的IT系统，经理们可以并且应该开发一种可以被便捷而且持续拓展的系统。在过去的十年中，我们研究了企业IT系统的设计和完善，并且协助很多企业进行了他们的IT系统建设。通过我们的工作，我们探索出了一条不仅可以降低企业成本而且可以支持企业已经存在的业务的成长和开发新业务的办法。我们称之为“路径基准”方法，因为企业应该更多的注重于为该系统提供一个可以开发的路径，而不是尝试去规定这个系统应该有的所有的特征。这种方法适用的前提是：在项目开始之前，人们通常不能指出他们需要的所有的特性，而且指出所有需要的特性需要花费高昂的成本。与此同思，一旦系统开始运行，经常还会有新的需求产生。并且在系统已经建立并且开始运行之后再去劝说人们去使用并且调整这个系统是很困难的。
通过我们的研究，我们发现了一个应用“路径基准”方法非常成功的案例：日本新生银行。日本新生银行在一年的时间里，用五百五十万美元成功的开发并且配置了一个全新的企业IT系统。他们所消耗的时间是通常需要时间的四分之一，而且成本只占使用打包系统的10％。这个系统只是作为一个低成本高效率的平台来使用，通过它不仅可以支持企业现有的业务，而且它的可扩展性使它可以来支持企业向包括零售银行，客户金融与在日本以合资的方式销售印度基金的新的领域发展。
日本新生银行在系统的设计，构造，调整IT系统（不是简单的将业务和IT系统排列在一起，而是有机地将其结合），使用最便捷的技术，将系统彻底的模块化，使系统自发的推销给用户和允许用户提出改进建议中所应用的“路径基准”方法原理可以成为其他公司的榜样。这些原理中的很多都是在旧的主题的基础之上演变而来的。
按需制定
日本新生银行成立于日本政府在二战后为了恢复本国工业而成立的长期信贷银行带着四十亿美元的债务破产后的1998年。长期信贷银行被国有化之后，于2000年被卖给了一个名为Ripplewood控股公司的美国私人基金会，并且改名为日本新生银行，取这个名字是意味这这个银行的重生。Ripplewood控股公司的董事们劝说日本前花旗银行主席，已经退休的Masamoto Yashiro来领导新生银行。为了修复已有的商业银行的运营，Masamoto Yashiro制定了一个计划，在日本全面革新零售银行业务,这项新的银行价值战略，那个时间的日根本是独一无二的。这个战略的基础是：高品质的产品和提供方便的服务，易于便于使用，并且只消耗很低的成本。该战略要求新生提供的服务在当时的日本非常罕见，包括免费的24/7自动柜员机，网上银行，网上外汇交易，网上双语银行业务，以及快速响应服务支持实时的数据库更新（指每个交易后，客户账户被立即更新）。
Masamoto Yashiro认为，在零售银行业务中，银行不经需要快速响应，而且要能够抓住机遇。不过，该公司已有的IT系统已经过时甚至已经无法充分支持新生银行的现有公司业务。为了解决这些问题，Masamoto Yashiro聘请了他的前同事dhananjaya "JAY" dvivedi ，运作花旗银行IT系统的前首席信息官。接受这份工作后， dvivedi迅速成立了自己的一个才华横溢的核心团队，其中大部分是以前曾为他工作的同事。由于央行回收了有限的投资资金，虽然Yashiro给Dvivedi的命令是将IT系统进行革命化的变革，但是他仍然要求他的团队必须做快速与低成本。由于他们不可能完全知道零售银行的运营将需要那些因素，二个人达成了一项共识，他们的目标应该是建立可以自动成长和适应新的机会并处理动态事务的系统。
建立的一个常规的企业IT系统通常有两种选择：用全新的IT系统与业务处理流程将现有的企业IT系统一下子替换掉的“大爆炸法”，和将现有系统一点一点地用新系统替换或者升级的“递增法”。 Dvivedi和他的队对“大爆炸法”的可行性表示怀疑，他们相信“大爆炸法”对于银行的现金约束的危险是相当巨大的，而且在将这样的将目本地化的时候会遇到很多的困难。如果使用“递增法”，那么，整个计划的实施可能需要3到5年的时间，这对于他们的要求来说相差的太多了。因此他们决定探索第三条道路。他们将探索一个新的领域，他们将建立一个模块化系统，这个系统起初和企业现有的IT系统将会平行运行，但是最终代替当前基础设施。根据传统的IT系统理念，这样做无疑是相当疯狂的。用于连接新老系统是他们能够实现平行运行的桥接系统将的开发将会需要极大的努力。
但是Dvivedi从之前的经验和与他的交谈的其他CIO们中得知，技术问题从未成为阻碍IT系统构建中的原因，人的问题才是。人们通常会习惯性的抵制新的IT系统，通常情况下，这是因为他们认为这样做的成本要大于这个系统给他们带来的收益。为了向其他人说明这点，Dvivedi使用了很简单，但是令人感到不快的方法给了大家活生生的体验。例如，通过模仿现有的企业信息管理系统的低下的效率，使Dvivedi和他的队能加速新的系统的建设。
当零售银行业务坚实的走出萧条的黑暗后，新的企业IT系统帮助新生银行很快的成为了日本零售银行市场中的有力竞争者。截止至2007年6月30日，新生银行已经拥有了二百万以上的零售银行用户，但是在2001年，新生银行的零售银行用户总数还不足五万。《亚洲银行家》杂志将日本新生银行称为2004年度和2005年度日本最佳零售银行，与此同时，《Nihon Keizai Shimbun》，日本最有影响力的商业报纸之一，将新生银行评为2004，2005和2006年度日本客户满意度第一的银行。
下面，让我们仔细探究一下日本新生银行所采用的“路径基准”的方法。
别只是列出你的商务和企业IT战略——把他们结合起来
商业战略和企业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系统。那意味着业务管理者为了避免使IT系统崩溃必须理解技术而且理解其折衷方案。
Dvivedi在新生银行果断地采取了标准化的构建方式。他征求了相关人员的意见但是并没有等到取得一致意见就开始了行动。一个最基本的决定是削减新生银行原来的大型机系统——传统的银行系统的主干，取而代之的是采用基于Intel的服务器。这是一个非常大的变化，区别于日本银行乃至全世界的大多数金融服务机构，通常这些机构都倾向大型机的高吞吐速度还有可靠性。问题是，大型机系统非常的昂贵且难于维护（通常每年维护费用是当初购买价格的15%～20%）。大型机的软件系统的软件多为一些难于理解的专有语言书写，即使是找到对代码很熟悉的程序员也不容易维护。这种向Intel服务器的变化立即为银行节约了每年4千万美元。随着选择了单一服务器平台，Dvivedi和他的团队选择了一系列其他标准，诸如Dell计算机，微软操作系统，互联网，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件的容量。
这得益于自动系统的模块化结构，新生银行能够轻而易举的更换任一部分（比如，贷款或者信用检查），而无需影响其他。另外，模块化也让新生银行在方便必要的时刻变化它的IT系统而不会让客户觉察到。比如它能让用户界面（web页面或者ATM屏幕）不变而同时更新后台系统。
・适当授权给工作人员
许多大型IT项目失败始于组织内部的抵制——用户不情愿去用，而并非是技术不好用。有的时候是公司试图强迫把系统强加给人们，而他们抵制；更常见的是人员根本没有一个必须的理由去努力学习如何操做一个新的系统。
通常大公司不必让用户用新系统，他们更愿意让用户主动来欢迎系统。这并不是说要让组织内的每一个人都疯狂的爱上每项要采取的技术，但是如果一个系统要让大多数人经过一个讨厌的“认识”的阶段，似乎就意味着这个系统需要做重大的改进或者直接废弃了。
当新生银行引入一个新的系统时，它是通过提供用户一个接口、界面或者屏幕格式的方式来进行地，而这些都是尽可能模仿旧系统的。一个新生银行的雇员在开始用新系统输入贷款信息的时候，可以找到一个几乎完全是旧系统复制品的界面来输入，但是如果新系统需要的信息（比如客户的手机号码）在旧系统里没有的话，员工必须到新的界面上录入。通过这种向上兼容的方式，用户变得习惯于新系统。只有当绝大多数用户转变到新系统上来的时候，Dvivedi的团队才会关闭旧系统的输入界面。这种方式在短期内会增加一些成本，但是Dvivedi相信对于换取员工更乐于和快速的迁移到新系统来说，这只是很小的代价。
・持续改进。Dvivedi相信用户的力量会超出系统的引入阶段，进而适用与持续改进地阶段。一个基本原则是任何持续改进的努力如果没有用户的同意必将失败。新生银行积极的向用户征求改进企业系统的主意，把用户地观点包含在日常的改进测试中，努力让他们感到自己在出谋划策。必须意识到地是，如果人们感觉到他们的意见没有被听取和迅速采取行动，那么他们就会停止发表。
最后，Dvivedi和他的团队建立了一个系统来收集来自最终客户，业务用户还有技术用户的反馈和需求。最近的几个月，这样的意见和需求平均每天达到了100条，建议和系统的失败信息形成了电子工作流程，如果这些建议和系统的失败信息很长时间没有被处理的话它们将被分发到相关的责任人或者转送到更高层。当一个问题被处理以后，那个提问题的人会被通知。
举个例子，反馈系统帮助业务领导发现抵押业务上有一些问题。申请房贷的客户抱怨他们已经向新生银行提交了所需文档之后，系统却显示有问题，这个问题被自动通知给相关地管理者们，然后，一个由业务和IT人员组成的小组被委派去查出原因。经过研究，他们发现真正的原因是银行已经发给客户一个有关提交文档的列表，但是客户不确定哪些是银行所需要的（例如他们不知道自己是哪一种），自然客户提交了错误的文档。这个小组的解决方式是：让IT系统来自动识别客户需要提交的文档类型，然后发给客户恰好对应的范本。在第一时间确定客户发送了正确的文档以后，银行和客户双方都节约了时间也提高了客户满意度。这听上去不像是一个重大的突破——但是确实说到点子上了。当不断的持续改进被集合到每天日常工作中，简单的口号激发了生产力，而减少了个人英雄式的解决问题。
现在企业在IT上大约花费5%的收入，投入上的巨大差异导致了，企业由此而获得的利益上的巨大差异。因为无论如何，选择那些支持业务战略的正确的IT系统提供更有竞争力的优势，并且可以供发展的平台。随着更加廉价的推动力，网络，还有发展中国家成熟的IT供应商的到来，我们的选择将会变得更多，更快，也更加复杂。
在这样一个商业世界里，我必须要建立一个能不断改进的IT系统。对于那些传统的管理者来说，构建一个IT系统就像建造一个大仓库：“建立它，然后完工”，这样想法已经不再适用于IT系统的建设，因为如果你打算用这种理念建立企业IT系统，你将会建成一个不变的，代价昂贵的并且从上线第一天就过时的系统。反之，如果采取一种“路径基准”开发的方式，你就可以取得更多的灵活性，并且可以随时根据业务需要而改变，这使得IT不再是现有操作的简单平台，而是新的商业功能和品牌的发动机制。