The effects of data chaos are debilitating. As a cure, I recommend establishment of a detailed, integrated, and fully reconciled data base.
In practical terms, creating an integrated financial reality in a banking institution takes the form of creating an enterprise-wide profitability data base that all decision-support systems will use as their definitive source for institutional data.
This article suggests guidelines that banks can follow in creating this data base.
Some Fundamental Principles
The exact form of a decision support data base will vary by institution. But it will always incorporate a few basic principles.
First, it will be functionally independent of the bank's operational systems,
depending on them only for data extracts at regular intervals.
Bank operations systems are designed to perform the bank's nuts-and-bolts business transactions. They are not designed to maintain decision-support data in useful form.
Second, the data base must integrate all information needed to serve the whole range of an institution's decision-support applications. The principle of integrated financial reality requires that every decision-support application in the institution make use of a single source of reconcilable data.
Particular applications may require other sources of information, such as demographic data for marketing plans. But all profitability data must flow from the decision-support data base. Existing analytical applications must be modified to interface with the data base, which must in turn be structured to accommodate their requirements.
Many institutions initiate decision-support data bases to improve decision making in very specific contexts, such as profitability reviews of major business lines or potential acquisitions.
Many soon find that they may leverage their data base investments in other, very beneficial ways.
Several banks, for example, have tapped their new data bases to support customer relationship information systems that help lending officers make tactical decisions on relationship management. Others draw on them for marketing plan analyses, delivery channel evaluations, or compliance reports.
And a few are beginning to use data bases to distribute overhead budget goals to the operating units for budget development. The usefulness of such comprehensive and accurate financial data is limited only by the ingenuity of the user.
Defect of Aggregated Data
Third, the data base extracts and maintains data at account and transaction levels. A data base built on highly aggregated data may be able to identify problems on very broad levels, but it cannot support detailed analysis of causes or precise modeling of proposed remedies.
Nor can a highly aggregated data base allow analysts to measure profitability at the level of individual customers or geographic areas, an increasingly important aspect of marketing.
Highly aggregated data bases also breed systems fragmentation. Every decision-support application uses data in different ways for different purposes. Each application will therefore require different methods of consolidation.
If the data in a data base are already highly aggregated, these decision-support applications must "adjust" to the underlying data. And the adjustments will simply recreate the data chaos the data base is intended to eliminate.
In addition to these drawbacks, highly aggregated data bases limit distributive applications, such as budgeting and planning on operating levels.
A Crucial Step
Fourth, and finally, the reconciliation process is crucial. Raw extract data must be reconciled and balanced so that aggregations and consolidations can be tied to general ledger data. This process must be done swiftly and accurately before any data are passed to any user application.
To some bankers, this concept of a single, integrated financial reality embodied in an enterprise-wide, decision-support data base will undoubtedly seem too good to be true - one of those idealized concepts we read about in business school and never encountered in the real world. Yet the concept is now being realized at a number of banks in a very pragmatic and workable fashion.
These banks have found three principal barriers to establishing the integrated decision-support data bases I am advocating.
The first is common to all information systems: mistaking data for information.
Information via Analysis
Data are only the raw material of decision support. Information is produced from data through careful, intelligent, and appropriate analysis. Users cannot expect a data base to provide information automatically and should not encourage others to think that it can. It will only yield data.
Application systems transform these data into information, assuming they are used properly for particular purposes.
An organization must be careful to recognize this important distinction and educate the users of its decision-support systems accordingly.
Information is the product of constant feedback. What goes into an analysis (in the form of assumptions, business logic, processing controls, and definitions) will play as great a role, or greater, in determining the output as the raw data.
All users must recognize that the information process is basically cyclical. With each reporting cycle, data are extracted, reconciled, analyzed, and then fed back into the system in the form of plans, goals, and comparisons with actual results.
Alienating End Users
A second barrier is the communications gap, found in most institutions, between end user communities and information systems organizations.
Information systems professionals want end users to establish careful and accurate specifications for systems so that the professionals responsible for creating and documenting systems can do so properly. End users want to get what they want when they want it, without getting locked into a fixed set of requirements.
A very real benefit of the new client-server architecture is that it lends itself to bridging this gap by assigning complementary spheres of responsibility. Welldesigned client-server systems allow an information systems department to retain control of the data extract process, systems infrastructure, and network administration.
End users, on the other hand, can take control of determining their own data needs, their application functionalities, analytic programs, and reporting.
Information systems departments often find themselves liberated from responsibility for maintaining patchwork inventories of special applications systems. They can spend proportionally less time gathering data to meet special requests and more time on their real mission, improving systems performance and reliability.
End users, in turn, gain effective and unconstrained use of both the data and systems applications they use to interpret the data.
Incremental Development
A third and more formidable barrier is the "life cycle" development process so deeply ingrained in our thinking.
In this model, a data base or application is designed according to specifications to do certain set tasks. The design process is closed, and the resulting application is installed and run unchanged until it becomes outmoded.
This model works very well for operational systems-such as item processing, where system needs are well-characterized and constant over relatively long periods - and the need for control is very great.
At this stage of development, the functions of decision-support systems are very different. The needs of decision makers and users change rapidly as the bank and its environment evolve. Every indication is that the rate of this evolution is accelerating and will continue to do so.
Therefore, banks must adopt an alternative model of systems implementation, which recognizes an iterative process of development that yields results successively closer to what's desired. Both user needs and system functionalities are regularly refined and adjusted.
Fortunately, the technology now available to us, such as open systems, client-server architectures, and flexible relational data bases, permits us to design and carry out decisionsupport systems in repetitive stages.
