Radically Simple IT - HBR

Radically Simple IT - HBR

By designing and deploying enterprise systems in a different way, Japan’s Shinsei Bank turned IT from a constraint into a launchpad for growth.

by David M. Upton and Bradley R. Staats

Enterprise IT projects—both custom and packaged “one size fits most” systems—continue to be a major headache for business leaders. The fundamental problem with these systems is that for the most part, they’re constructed using what programmer and open source champion Eric Raymond dubbed a cathedral approach. Like the great edifices that Europeans erected in the Middle Ages, enterprise IT projects are costly, take a great deal of time, and deliver value only when the project is completed. In the end, they yield systems that are inflexible and cement companies into functioning the way their businesses worked several years ago, when the project started. Despite recent improvements in the flexibility of packaged software, companies often find it exorbitantly expensive and difficult to modify their enterprise systems in order to exploit new business opportunities.

Instead of building systems that are legacy from the day they are turned on, managers can and should develop systems that can be improved—rapidly and continuously—well after they’ve gone live. Over the past decade, we’ve studied the design and implementation of enterprise IT systems and assisted numerous firms with the process. Through our work, we have identified an approach that not only reduces a company’s costs but supports the growth of existing businesses and the launch of new ones. We call it a “path based” approach, because rather than attempting to define all of the specifications for a system before the project is launched, companies focus on providing a path for the system to be developed over time. The approach’s premises are that it is difficult and costly to map out all requirements before a project starts because people often cannot specify everything they’ll need beforehand. Also, unanticipated needs almost always arise once a system is in operation. And persuading people to use and “own” the system after it is up and running is much easier said than done.

In our research, we discovered a standout among the companies applying the path-based method: Japan’s Shinsei Bank. It succeeded in developing and deploying an entirely new enterprise system in one year at a cost of $55 million: That’s one-quarter of the time and about 10% of the cost of installing a traditional packaged system. The new system not only served as a low-cost, efficient platform for running the existing business but also was flexible enough to support the company’s growth into new areas, including retail banking, consumer finance, and a joint venture to sell Indian mutual funds in Japan.

The path-based principles that Shinsei applied in designing, building, and rolling out the system—forging together, not just aligning, business and IT strategies; employing the simplest possible technology; making the system truly modular; letting the system sell itself to users; and enabling users to influence future improvements—are a model for other companies. Some of these principles are variations on old themes while others turn the conventional wisdom on its head.
Born of Necessity

Shinsei came into being when Long-Term Credit Bank, founded by the Japanese government to assist in the rebuilding of the country’s industries after World War II, went bust in 1998 with nearly $40 billion in nonperforming loans. The firm was nationalized, then sold in 2000 to Ripplewood Holdings, a U.S. private equity fund, and renamed Shinsei, which means “new birth.” Ripplewood executives coaxed Masamoto Yashiro, the former chairman of Citibank Japan, out of retirement to lead Shinsei. In addition to deciding to revamp existing commercial-banking operations, Yashiro formulated a plan for revolutionizing retail banking in Japan by offering a value proposition that was unique in the country at that time: high-quality products and services provided on a convenient, easy-to-use, low-cost basis. The strategy called for Shinsei to offer services that were then uncommon in Japan, including ATMs available 24/7 free of charge, internet banking, online foreign-exchange trading, online bilingual banking, and quick service supported by real-time database reconciliation (meaning customers’ accounts were updated immediately after each transaction).

Yashiro felt that the bank needed to move quickly to seize the opportunity in retail banking. However, the firm’s existing IT systems were antiquated and could not even support the bank’s existing corporate business adequately. To address these issues, Yashiro hired his former colleague Dhananjaya “Jay” Dvivedi, who had led IT operations at Citibank Japan, to be chief information officer. Upon taking the job, Dvivedi quickly surrounded himself with a talented core team, most of whom had worked for him previously. Since the recovering bank had limited investment funds, Yashiro gave Dvivedi the mandate to revolutionize IT but with the understanding that his team needed to do it “fast” and “cheap.” Recognizing that they could not fully know what the retail operation would need, the two men agreed that the goal should be to build a system that could scale with growth and adapt to new opportunities that the dynamic business would create.

The conventional choices for building a major enterprise system were two: the “big bang” approach of replacing the current system with an entirely new system and processes all at once or the incremental method of improving or replacing the existing system one small piece at a time. Dvivedi and his team were leery of taking the big bang route, believing it was too risky given the bank’s cash constraints and knowing all too well the problems endemic to such projects. The incremental course, however, which would probably take three to five years, would be far too slow. So they decided to blaze a third path. They would put into place a new, modular infrastructure that at first would function in parallel with but eventually would supersede the current infrastructure. According to traditional IT thinking, this was madness. Much bridging software would have to be developed to span the old and the new, which would require an enormous effort.

But Dvivedi knew from his prior work and his conversations with other CIOs that technical problems were almost never the reason that new IT systems flopped. Human problems were. People typically resist adopting new systems, often because the cost (the effort) outweighs the benefits. To address this, Dvivedi used simple but innovative technology solutions to avoid the wrenching go-live experience. For example, by mimicking the old system’s look and feel at least for a while, Dvivedi and his team were able to speed adoption of the new system.