I am very flattered that you have asked me to present the Citicorp/Citibank success story with respect to using information technology (IT) to improve business operations, including what Citicorp did to overcome its problems with legacy systems. I must first, however, set the record straight. Although Citicorp/Citibank has indeed had many successes and has made some progress towards overcoming its problems with stove pipe legacy systems, I would be less than honest to say that we have solved the problem, or that we are happy with our current state. Let's say that I will be presenting a status report of efforts in progress, and not a success story of a job completed and well-done. First to give you a feel for the magnitude of the problem. Citicorp is a global financial services organization with a staff of 85,300 (including 48,000 outside the U.S.), serving individuals, businesses, governments, and representative offices, subsidiary and affiliate offices) in nearly 100 countries and territories throughout the world. We process trillions of dollars a day and have over 40 million customers.
We still are not satisfied with the state of our IT. There is no final state, only continuous change. This is one of the major challenges for all of us. We still have legacy systems we have not replaced. We still are working on the Year 2000 problem, and we still feel that our applications development processes take too long, cost too much and are not responsive enough in meeting the business needs. An ongoing challenge is getting the businesses to work in a more organized way with technology, not just specs, but working with prototypes, being more involved, etc. My goal as you know is technology/business fusion. That said, I will be pleased to tell what we have done to date, and the steps we are taking to continue to improve our systems, people and processes to better solve our business problems.
Stove pipe legacy systems: We have taken several important steps in streamlining and consolidating our stove pipe legacy systems. The main approaches we have adopted include: Consolidation, Front-end integrators, Functional migration, and Replacement. I will discuss each in turn.
Consolidation: Like the IRS, we have many systems that don't interoperate well, and which overlap and duplicate each other, with respect to their functionality. It has not been easy, but at much cost and difficulty we have managed to eliminate many of these redundant systems, by ruthlessly phasing out systems, and cutting over many of our business processes onto a single application/system.
To achieve this we had to make many compromises, including sacrificing some regional functionality, as well as implementing selected enhancements on the surviving systems. An example of this consolidation was a 2 year project to move all our U.S. branches onto a common back office processing and operations system, from what had been a collection of duplicative overlapping systems.
Front-end integrators: Our customer delivery systems and back-end reporting systems get driven by "Integrators" that we built which interface to and access our various stovepipe product processing systems. In this way we present our users with a single integrated interface point, and hide from them the need to access multiple systems to get something done, each one differently, and the need for translation of information between systems.
Functional migration: Over time we have stripped functionality out of these stovepipe product processing systems onto the newer, better architected Integrators and new product processing systems applications. Replacement: In some instances, such as in our branch platform systems, we are replacing all our old stovepipe legacy systems with a common system package from Systematics, that we have purchased, and are customizing. We did try one other approach, an Evolutionary one, where we were to migrate functionality in phases from our stove pipe legacy systems to a new architected system. This approach didn't work for us however. It was taking too long, and too many new requirements kept getting added to the project - increasing its cost and time to complete. We have initiated a special Year 2000 project office that is dedicated to fixing all our systems with respect to the Year 2000 problem - the count-down continues.
We have installed several technology processes aimed at ensuring that our future developments are developed in a consistent, compatible fashion, in accordance with our architecture and standards frameworks, and implemented using good software engineering guidelines and principles. These processes include: building an evolving a common architecture; selecting strategic vendor partners; introducing and adopting the Software Maturity Model principles into our technology units - I am proud to say that we now have several software units performing at level 4. We also have implemented a Building Permit process that all new developments must pass before the project is approved and funded. The project must be cost-justified and conform to our architecture, standards framework and selected vendors, etc.
These processes seem to be working. The only caveat is that we must keep vigilant and adaptive because the technology and the marketplace is very dynamic, requiring us to be alert to shifts that might cause us to adjust our architecture, standards, vendors, etc.
We have benchmarked ourselves against the competition, and our business needs, identifying gaps in capability that we are now addressing filling. We see this evaluation process as a continuous process.
On the positive side, we are becoming a learning organization, continuously rethinking and streamlining our systems and processes, and re-engineering our workflow process. We have consolidated our networking and data centers, reducing redundancy, and improving bandwidth, reliability and responsiveness. We have introduced imaging and expert systems in areas such as our credit and application processing systems, to reduce paper-handling, manual processing and delays, and to improve our service quality and responsiveness. We have built Data Warehouses which we continue to expand, and applied complexity theory to improve our forecasting and scheduling of such things as: our service representatives schedules, and customer delinquencies.