Deploying the Integrated Customer Database: A Case Study Real Life Examples in Quality by Design
by Andres Perez
Originally published February 13, 2008
Many organizations have recognized that having an integrated database for customers can boost marketing efforts, reduce operational costs, increase customer satisfaction and more. The value of knowing the whole customer and understanding how best to meet the whole customer’s needs has become a critical issue for many organizations. However, most organizations have exactly the opposite; a myriad of fragmented files and databases, designed as “solutions” for each of the business areas or divisions across the enterprise where customer information is frequently complete for the department but incomplete for the enterprise, timely for the business area but untimely for the entire organization and, worst of all, somewhat sufficient for one group and grossly inconsistent across groups.
The lack of well designed and properly performing enterprise-strength databases has resulted in excessive redundancies, high complexity, and constant process breakdowns caused by information systems failures, regular maintenance and upgrades.1 Some examples of excessive redundancy include a client who has 17 “customer” databases but does not know if the customer information on these databases is consistent; another client has 268 customer databases and they are fully aware the information in these databases is not consistent. As an example of high complexity, an insurance company wanted to know the number of internal interfaces moving claims information from one file or database to another; they stopped looking after exceeding 4,000 – they had more interface files with claims information than adjusters handling the claims!
Some people attribute the current state of disparate, inconsistent and highly redundant information to the advent of distributed computing and the commercialization of personal computers. However, companies that embraced computing at an early age and have many applications running on a single mainframe platform suffer the same maladies in their applications.
Although many organizations have attempted to deploy integrated solutions in the past, most have achieved only marginal results. Why? Let’s look at some of the factors.
Information technology is not the barrier. Current technology enables the creation of very large databases with very high transactional throughput that can support the most demanding organizational information needs, with very few exceptions. There are affordable technology platforms in the marketplace to meet every budget; so technological costs are not a significant constraint.
The demand for integrated information has created a vendor response that has spawned a market for what many call customer data integration (CDI) or master data management (MDM). These approaches are characterized in many ways; however, they are typically presented as a “federation” or “consolidation” of disparate databases and applications to present an “integrated” or “unified” view of the customer, product, supplier, etc. The vendors offering customer relationship management (CRM) tools, CDI or MDM capabilities usually focus on facilitating and accelerating data movement from one or more databases or files to another using extract, transform and load (ETL), messaging (message queues), and other capabilities. How are these “solutions” meeting the customers’ expectations? In a previous article, I mentioned that data movement increases costs (adds more complexity to the information management environment), information float or delays (whether batch or messaging), reduces semantic value (much semantic value is casted in the context of the existing applications), and significantly increases the opportunity for introducing information defects. Customers are realizing that these “solutions” are more focused on attacking the symptoms (e.g., moving data around faster) instead of attacking the root cause (e.g., keeping the information integrated in one place in the first place).
Again, why is it that, despite the available technology and the significant efforts by many organizations, most are still lacking integrated databases for critical information such as customer, product, supplier, etc.? Is it really not possible to deploy enterprise-strength, integrated databases that meet the needs of all business areas, departments, divisions, etc., across the enterprise?
There are some organizations that have created a truly integrated, enterprise-wide database that supports the information and processing requirements of all its operational areas. They are realizing the promises, without the headaches, of MDM and CDI and they are doing it without moving data around. Some did it before the technology platforms had reached the level of capability we have today. This is proof that technology, again, is not the barrier.
If technology is capable and it is affordable to deploy truly integrated, enterprise-strength databases that meet the needs of all the business areas, departments and divisions, and if some organizations have achieved this level of information management across the enterprise, what then is preventing the general use of these valuable capabilities?
A general misconception I have encountered is that “it is not possible” to deploy such databases. It seems that the failures from the past as well as massive marketing by CDI and MDM vendors have created this common misconception that deploying truly integrated enterprise-wide or enterprise-strength databases is not desirable or even possible. One of my clients said to me, “that is too far out in the future; we need to focus on what we can do today.”
To help dispel this misconception, I offer a real-life example of an organization that was able to deploy a truly integrated customer database that met the needs of all the information stakeholders across the enterprise at the time it was first deployed and continues to do so today.
Early Approach to Customer Information Management
This case study is for an insurance company that, from its inception, has focused on its customers by providing excellent service at a competitive price. This business model has enabled them to maintain the highest retention rates in their industry. Their existing customers are eager to buy new products and services from them and the existing customers’ dependents are a very strong source of new business.
As with most organizations, this organization deployed their information technology to support each line of business, using the “solutions” paradigm that is so prevalent. Therefore, each line of business had its own policy administration system, and in some cases, multiple systems deployed to support different products within the line of business. It is important to mention that early on, the company established the practice to issue a customer number to each customer or prospect as a means to uniquely identify its customers. This customer number has been well managed since its inception through effective methods and procedures to ensure that “each customer has one customer number and that each customer number is for one customer.” Customer numbers are issued with consistency and control and processes are in place to monitor and reduce the incidence of multiple or duplicate customer numbers.
Despite this singularity of customer identifier, each line of business issued and maintained policies and billed them to the customer. As it is in many of today’s solutions, each system contained the personal details of each customer. If a customer had multiple policies, the customer information was replicated on each policy. When a customer moved or changed any personal information, the customer was required to notify each line of business of such changes. This redundancy, besides the significant customer burden, frequently led to inconsistencies resulting from updates to one business area or application not made to another, updates lagging behind from one application to the next, inconsistent capture methods for the same information, or different standards and practices for the recording of the information (e.g., abbreviations, formatting). Customers with multiple policies received many mailings and bills.
As the organization grew, it became clear that the old methods for managing customer information and servicing their customers were creating unwanted friction in their relationship. Customers complained that they were frequently confused by the large number of documents and bills they received from the company. They also complained about solicitations for products they already had or asked to purchase products for dependents that were long gone.
In response to the complaints on the multiple bills, the organization decided to consolidate the bills by creating a central billing department. An automated method for consolidating the bills was deployed; however, in those cases where the customer name and address were different for different policies, significant manual effort was required to ensure proper consolidation. Once the bill was consolidated, the system would print the final bill. To address the complaints on solicitations, top management created a corporate marketing department to handle all marketing efforts to reduce or eliminate the incidence of solicitations for products the customer already had or for dependents no longer in the household.
This new function quickly realized that some actions needed to take place immediately. The first step was to create a central file for consolidating “name and addresses,” by extracting it from all the operational applications and merging the information on customers from all lines of business; this included basic information such as name and address and the products the customer had. This file was intended to help both the marketing and the billing efforts.
The new marketing department strengthened the customer number issuance process and established stronger controls to reduce or eliminate issuing multiple numbers to the same customer. It also recognized the burden imposed on customers to notify each line of business on changes to their personal information, especially the change of address. They created a new process for change of address; instead of having the customer notify each line of business, the new process allowed a customer to call in once or send one change of address request and then all lines of business were coordinated by the central marketing function to affect the change. These actions are very much like those frequently taken by today’s CDI and MDM efforts.
The initial response from the customer was extremely positive.
The company experienced a reduction in the number of duplicate numbers issued, the number of duplicate or unwelcome solicitations dropped significantly, customer satisfaction with the address change process was very positive, and miscommunications with the customers due to incorrect addresses were reduced.
However, the initial gain quickly dissolved as the “new” process became routine. Because each line of business continued to maintain information on “its customers” in each of their policy files, it continued to be difficult for the organization to manage customer information across the lines of business to really know and understand the customer. Issues with marketing, billing and change of address continued to besiege the organization. The change of address process was slow and inefficient and sometimes failed to correct all the instances of the information. These inconsistencies in the information persisted and continued to create customer dissatisfaction and missed opportunities. The organization learned that merging customer data was not yielding the results they expected!
Business Vision – Not “ROI”
Top management, specifically the CEO, was aware that to strengthen the company’s relationship with its customers, they needed to manage the customer information even better. The corporate marketing experience indicated that tighter management of the customer information was required to achieve this objective. He knew that issuing a customer number that uniquely identifies a customer for the organization is a necessary but insufficient part of managing customer information. The use of this “federated” approach to managing customer information where each line of business had one or more replicated customer records needed to change.
The CEO understood that to maintain their position in the market, the company needed to manage customer information more effectively; a centrally managed customer information file was required. He liked to state it as “one customer, one record.” The CEO believed that the company needed to have “one view of the customer” and the customer needed to have “one view of the company.” This was a significant change and people were going to resist if they did not have a clear understanding of the value proposition. He needed to clearly articulate the vision and direction for customer information management.
He articulated this vision saying “we need our customer to see us as one company and we need our company to see our customer as one. This will enable the entire organization to be market ready, to know and meet the needs of our customers effectively and efficiently. We can do this by knowing the entire customer, including their demographics, dependents, product portfolio, and preferences. We must manage the relationship with our customer end-to-end by focusing on life events to offer them tailored services and products that better meet their needs.” He was convinced that this business model was going to place the organization in a better competitive position and was going to launch it far ahead of the competition – a true quantum leap.
Management Commitment – Staying the Course
It became clear that to accomplish this vision, the company needed to keep one record of each customer that employees could use when interacting with the customer. He reached out to his CIO and asked “how can we do this?” The CIO told the CEO that the technology was now in place to make this happen; the technical platforms offered the capability to create a true enterprise customer database that can be directly shared by all lines of business. This new environment provided better support for data recovery in case of breakdown. He indicated that the need for replicated customer records was no longer the result of technological constraints.
Both of them recognized that many challenges lay ahead.
Some challenges were operational: how do you enable each line of business to continue to operate independently while maintaining control of central resources such as finance, personnel, marketing and now customer information?
Some challenges were technological: can this information be readily available and maintainable to present the “one company image” to the customer at all touch points? They knew the organization had many technological capabilities but had not used database management systems and transaction monitors to the extent that this vision would require.
Some challenges were financial: in order to achieve this vision, given the technological condition of the organization, it was going to be necessary to slow down investment in new information technology for the lines of business to enable the IT department to focus their energy on creating the proper infrastructure to manage customer information across the enterprise. It was not just deploying the customer database but redirecting all the existing applications to use the new database instead of the “application owned data.” This implied that existing needs for automation by the lines of business would have to be placed on hold while the organization continues to grow in lines of businesses, products, and customer base. The pressure by the lines of business to operate independently was going to continue to grow while the new customer database, and the necessary infrastructure to enable its use across the organization, was developed.
Some challenges were organizational: the new application was going to displace a number of people and this created fear and concern for those impacted. There was a need for a redeployment plan; the company did not believe in displacing loyal and well trained human resources.
Some challenges were functional: the vision called for a marketing strategy based on the customer’s life events. These life events include such things as graduation, employment, marriage, child birth, retirement, and so on. Supporting “life events” across the enterprise will require efficient and effective communication between the diverse business areas and their applications to “notify” each other of such events and orchestrate a consistent response to the customer’s needs.
Facing these challenges required a clear vision to focus on the customer, strong leadership and strong diplomacy to balance these difficult issues.
Under the direction of the CEO, the CIO led the development of a far reaching systems plan that included a number of projects to create the necessary infrastructure, including the development of a central customer database and application, designed to be weaved into the line of business applications and therefore enable each line of business to see the “customer information” as if it was part of the application. The purpose of this new capability was to create “one single image of the customer” that could be used across the enterprise.
The plan was considered by many as “too ambitious” and “high risk;” however, the CEO and CIO were committed to provide the necessary leadership. This commitment was essential to get the process started and was instrumental in maintaining the course.
The Journey – Developing an Enterprise-Strength Customer Database
The new database and application were to replace the customer information contained in each line of business application and in the existing “consolidated” customer file. The plan was to replace the latter with the new database. For existing applications, the principle was that these applications in the lines of business will no longer be allowed to create or update customer information on their own. Where possible, existing applications were directed to remove all customer information and use the new database as their customer file. Existing applications that needed to retain customer information could do so by replicating the data from the new central database – again without changing it outside the central database. A mechanism for notification and movement of customer information changes (additions, updates and deletions) was created to enable the replication process to work. New applications were not to contain customer information; they will be designed to use the central customer database as their customer file.
The new customer information application was to assign new customer numbers and was going to enable more people across the enterprise to register new customers. The central customer database was to
be designed to provide the base functionality for customer registration and maintenance as well as added functions and features such as cross references using names or part of the name, social
security number, phonetics, and more, to ease the burden of locating an existing customer record. This was fundamental in preventing the issuance of duplicate numbers to a customer in this new
environment. The new application and process was going to replace a labor intensive process that had functioned well for years.
The roll out was very tight. Once the decision was made to begin conversion, the team had only a few hours to fall back (that is, to “abort and try again later”). Each action had to be monitored closely and each step assessed carefully to ensure that moving forward was not placing the conversion at risk. The situation was so sensitive during the rollout, that the CIO called the project manager and asked her to provide hourly project status reports. “I recall telling him to come down to the ‘control room’ where I was answering phone calls, checking status on each of the activities, talking to all the touch points in the business areas and application support teams to ensure that we were on the right track” she remarked. Once the CIO arrived, the project manager said, “Please read the boards and charts, if you have any questions, let me know.” She indicated that people in the executive ranks were not used to their staff telling them to come in for updates. At first, the CIO was visibly unhappy with this response. Once he arrived to the control room, he quickly realized the importance of the control room and of keeping the project manager in this place. After that, he just walked down every time he wanted to know what was going on.
After one long weekend, the database went live. It took nearly a month to stabilize the entire system. The Director of Application Development indicated, “This thing almost got me fired.” He added, “The old name and address system had nearly instant response, and the new central customer database took much longer to respond at first. After some fine-tuning, ‘it rocked along!’”
The conversion, rollout and fine-tuning were all successful efforts by all measures. Once the central customer database and application were deployed and the new customer information management team was solidly in place, the project manager was asked to stay in place as the manager for the maintenance team for the following two years.
This was a deliberate move by the CIO to ensure effective continuity in the rollout and use of the newly developed customer database and application. The institutionalization of proper customer management principles, practices and processes required leadership and the project manager was considered the best person for the job. She indicated, “During those days, I used the CEO’s ‘one-customer, one-company’ words every time I was called to a discussion with a line of business asking why they should have to use the customer database for their new product or application. I would use his words and then explain the design guidelines and principles that must be used with the new application.”
After the first couple of years, the customer database and application were mature, matter-of-fact, business tools. However, as the organization grew in new products and services, they grew organizationally with new departments, divisions and, in some cases, entire new companies. The executives of these new large organizations, following the common practices to acquire solutions and to develop local tools, kept pushing for ways to collect and maintain “their” customers’ information. In addition, as new applications replaced existing ones with purchased software, the trend to revert back to carrying localized information continued to bring challenges to the organization. However, the CIO had the resolve and discipline to establish controls to sustain the centralized customer database. On occasion, local solutions were deployed and the organization found itself experiencing some of the old problems. Then, the CIO would step in and reassert the company’s position to focus on the customer. Eventually, the concept of central customer information became part of the company’s culture and these challenges ended.
The Result – Reaping the Benefits
The organization exceeded all of their expectations. They realized a significant increase in customer satisfaction while reducing their costs of operation. They also had a significant increase in customer information quality and in the use and reuse of this information across the enterprise. They used the same data to service their policies, issue bills, deploy marketing campaigns, develop new products, and more.
The return on this investment has been immeasurable; years after deployment, the organization continues to benefit from this investment. And while they are getting significant value, their competitors continue to struggle with fragmented and highly questionable customer information and its associated high costs.
Although the deployment of the new database, application and processes for customer information management indeed displaced a number of people, all the people were re-deployed, no jobs were lost.
This case offers a number of insights. The following are some observations:
We can conclude that organizations can derive significant, strategic value from enterprise-strength databases and that information technology is no longer a barrier to achieve them. The barriers
organizations encounter in achieving the deployment of true enterprise-strength databases are managerial not technological.
Recent articles by Andres Perez
Copyright 2004 — 2017. Powell Media, LLC. All rights reserved.
BeyeNETWORK™ is a trademark of Powell Media, LLC