The Flexibility Revolution in Customer Information Architecture
Architects pride themselves on redesigning structures to help us better meet our goals. When stairs slow movement of inventory out of the warehouse, architects replace them with a ramp. When plans show that weight-bearing masonry walls would create a warren of offices separating workgroups, architects recommend alternative structures that permit fast internal reconfiguration.
Computer architects approach information systems in a similar way. They understand that the large, monolithic systems that have historically handled customer information inhibit companies from improving customer services, responding to new regulations and rate changes in a timely manner, and entering new lines of business. The systems are too inflexible and difficult to alter. Computer architects also understand that the root cause is overintegration of system parts, so that minor changes can cause adverse results in seemingly unrelated applications.
The question is: What can be done about it in 2003? Some industries solved the problems inherent in monolithic customer information systems by distributing databases and applications over a network of servers and PCs. Unfortunately this model is simply unworkable for monumental tasks like processing millions of monthly bills and payments, typical of energy and service companies.
Today there is an alternative gaining credibility and popularity: heterogeneous customer management systems in which discrete, componentized applications ride on a common, flexible architectural backbone.
The Monolithic Customer Information System
Figure 1 below illustrates a typical legacy system, in which a centralized, monolithic core integrates myriad applications and rests them on a "customer" file that in this case contains a combination of customer, meter, service address, and financial information.
FIGURE 1: Monolithic Customer Information SystemIn the majority of cases, monolithic systems represent an accretion of data and applications developed over the years. They are jumbles of overlapping and intricately integrated data and functions. All too often, they complicate operation of core functions by using basic customer billing information as support for peripheral applications like trouble management, asset management, and usage acquisition.
There are reasons, of course, that companies retain these monolithic customer information systems and use them for new applications. The advantages of a monolithic customer information system include:
Pride of work. Legacy systems represent 20 or 30 years of accumulated effort by hundreds of individuals, many of whom remain in the employee pool. These systems are a virtual library of historical knowledge about how the business worked in the past and how it works today.
Investment justification. U.S. utilities, for example, have a huge investment in legacy customer information software systems. SPL research indicates that it would cost the top 50 U.S. utilities about $1.4 billion in software purchases and other external costs to replace those systems. In addition, utilities trading out legacy systems would face even larger internal costs for implementation and training--costs that some estimate at 2 to 2.5 times the external investment. Given these figures, it's no wonder that stockholders, regulators, and rate payers all want to believe that they can continue to rely on current systems.
Familiarity. Legacy systems have highly customized, task-oriented user interfaces with which employees are comfortable. New-employee training is easy, because proven educational materials already exist. And virtually anyone a new employee turns to can answer questions.
Regulatory reluctance. No matter how inflexible and difficult it is to use, it is virtually always cheaper in the short term to make one more modification to an existing system than it is to replace it. In organizations in which each modification is seen as a separate decision point, the cost benefits of remaining with the legacy system are clear. While nonregulated companies might have no difficulty in grasping the savings involved in replacing systems in order to decimate the costs of ongoing multiple modifications, regulated companies may have difficulty justifying costly alterations.
However, monolithic systems also have their share of disadvantages:
Inflexibility. The primary disadvantage of a monolithic system is that it so intertwines core and peripheral applications that changing one results in unanticipated and undesirable changes in others. In the monolithic customer information system, even the simplest alteration can lead to unreliable results that can be difficult to rectify.
Cost. Monolithic systems are expensive to maintain and modify. Many companies with these systems keep an army of programmers on staff to test and verify system results after even the most routine of changes. In regulated industries, responding to even the simplest of requests or requirements from state or local regulators can take months. Changes in national accounting standards can produce a cost hemorrhage. New business structures like retail competition may be all but impossible to achieve.
The Componentized Customer Management System
In contrast to the monolith, the componentized model links separate, heterogeneous applications through a backbone that permits each application to access customer data separately. Backbone architecture also allows functions to exchange information in a many-to-many relationship when appropriate. For example, customer contact information collected during customer interactions can be used by many disparate applications, from SFA to outage management.
FIGURE 2: Componentized Customer Management Core SystemThe customer management core shown above in figure 2 contains all the functions companies need to handle the core of their business--be it regulated or deregulated. For most energy and service companies, this can include such functions as calculate usage by accepting metering data and classifying it according to the appropriate rate, price, tax status, etc.; calculate and present bills; post remittances; extend credit and collect past-due bills; settle individual accounts; aggregate individual account activity into a centralized accounting system; issue field activities; work with multiple third-party suppliers.
The component system has some distinct advantages. With a componentized system, companies can:
Choose only the applications they need, adding to the system or subtracting from it as the business model changes.
Make changes rapidly, using built-in change routines. Additionally, modern software products offer flexible configuration options unheard of a few years ago.
Change one function without affecting others. These features dramatically reduce the number of personnel needed to maintain and perform routine upgrades to the system.
Take advantage of technology and service-concept improvements--automated meter reading, for example, or internet-based customer bill-paying--that would be far more costly if added to existing core systems.
Component systems do, however, have disadvantages as well.
Replacing the technology that lies at the heart of a business is not a trivial task.
Projects for large utilities can run well into the millions of dollars, even though the new software is normally considerably less than half the cost of the investment in the old software.
These projects need a significant time investment as well, because they often take more than a year to plan and implement.
Although it is possible to run user interfaces similar or identical to the old ones, most companies find it far more efficient to change some user interfaces in the new systems, especially in applications that offer added functionality. These changes take time to learn and can meet with initial resistance from service personnel, especially if they have not been involved in the early stages of system change.
Adding to a Customer Management Core
As the figures 1 and 2 illustrate, the typical monolithic customer information system contains more functionality than does the typical componentized customer management core. This is because the core has been deliberately honed down to the functions shared by most energy and service companies--those related most closely to customer care and billing--while the customer information system has typically been permitted to grow without a long-term plan, integrating peripheral functions into the core.
That doesn't mean, however, that choosing a backbone customer management core system limits strategic opportunities. To the contrary, the customer management backbone permits additional noncore applications to be added easily, initially or later, as business models change. Each new application has its own discrete interface with the customer management core and with related peripheral applications.
The complete customer management system can be as simple or as complex as corporate strategy demands. Companies can, for instance, surround the core with a layer of customer interaction applications that expand today's typical call center through services like interactive voice response, telephone conferencing, email, individual customer sites accessible on the Internet, real-time credit checks; transaction management.
Business processes can be directed using scripting tools and other desktop assistants, navigating the end-user through the various components. For example, companies engaging in retail competition might add a sales automation level that manages campaign development and execution, tracks leads and contacts, and quotes prices. Yet another layer can provide such analytical customer management tools as market research, competitive analysis, branding, delivery optimization, and assessment of product or segment profitability.
Thus, a fully developed customer management system might look something like:
FIGURE 3: A Fully Realized Customer Management SystemBusiness Case
The advantages of a componentized, backbone-based customer management system are immediately apparent when viewed through business case scenarios. For example, reducing costs through the use of off-the shelf components frees capital and personnel to pursue added services and new lines of business in changing business environments--regulated or deregulated. Off-the-shelf components also permit companies to evolve and change direction rapidly. Applications can be added for test marketing, removed or altered, and then reintegrated into the system--all without disruption to other applications and lines of business. That's crucial when regulations force the development of relationships with a variety of new entities.
The flexibility of easily changed components also permits companies to keep pace with industry best practices and take advantage of computer hardware improvements that may increase reliability and decrease costs. Similarly, components reduce product time-to-market, since new applications with existing training documentation take far less time to implement and assure companies that they are up-to-date on business rules and regulations.
Components can be chosen for easy scalability, reducing the cost and easing the consequences of vigorous acquisition and merger strategies. Components also can keep pace with new technology developments. Emerging Web Services technology, for instance, while not fully developed today, promises to become widely adopted across many industries. Companies with customer information systems that cannot adapt to this development could find themselves stranded and isolated from suppliers and business partners.
Components: Pre-Integrated Versus Best-of-Breed
There are two basic approaches to obtaining the components needed for a backbone system. One approach uses pre-integrated components from a single software applications vendor. This approach can reduce implementation time--at least in theory--but may force a company to accept a "jack of all trades, master of none" system. Pre-integrated components can also mask symptoms of the monolithic application, providing deep integration where it is not expected, requiring adoption of unwanted and unneeded components.
The other approach mixes and matches components from different vendors. This permits companies to select the best-of-breed in each application category. In the past this approach frequently required longer implementation periods and additional expenses for integration services. Increasingly, however, best-of-breed vendors are striking technology agreements under which they commit to evolving their architectures in tandem to reduce integration and implementation time and costs. Emerging standards, like Web Services, also ease technology integration. In some cases companies find that it easier to integrate these coordinated best-of-breed components than it is to implement common-vendor components that are, in fact, at different stages of development and functionality.
Embrace Components
For energy and service companies, monolithic customer information systems are an artifact of a monopolistic, noncompetitive past in which companies offered only a single line of relatively unchanging services to customers with few or no alternatives. Such systems bear only peripheral resemblance to customer management systems based on an architectural backbone and discrete application components.
The speed and flexibility offered by today's componentized customer management systems is essential for companies seeking to keep up with the rapid changes in today's regulatory and business structure and to enter emerging markets. Companies that attempt to compete while carrying forward the burden of a legacy customer information system are likely to find themselves greatly disadvantaged in ways that management drive, determination, and strategic insight simply cannot overcome.
About the author:
Brian Owenson, vice president of solution management for SPL WorldGroup, is dedicated to prioritizing and coordinating the solutions for SPL. The solution management group is responsible for both product release cycles and related technical alliances, for managing organizational readiness for product releases, and to assure product release logistics are in accordance with strategy and development intent.