This article originally appeared on the BeyeNETWORK.
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 team was rather small; one project manager, one application designer (the term “architect” is frequently used to describe this role), one database designer (this role included information requirements gathering, data modeling, database design, database implementation and data conversion design and oversight), one business subject matter expert as the business requirements coordinator, two developers, one tester, and a large number of “temporary” business representatives from across the enterprise. All business areas that created, maintained or used customer information were represented. These people were highly recognized experts in their business areas. Their participation in this effort was “temporary” but their direct management was committed to their participation; they had clear guidance that this was their most important assignment.
The two designers were the only senior people in the team; they worked with the program designers. The program designers had the responsibility to oversee all the applications and databases across the program to ensure that all the pieces worked well together.
Once the project to design the customer database got started, their first challenge was to achieve a clear definition of the information to be centrally managed. Because each line of business had specific information needs regarding “their customers,” the information requirements gathering process included the development of agreements between the business areas and the central customer information management team on what will be managed centrally and what will be managed by each line of business. To achieve these agreements, the team required operational definitions of the customer information requirements. Once these definitions were achieved, then the delineation of responsibilities became easier to define and the team was ready for the design phase.
Another difficult challenge was to keep the team together. The project manager indicated “we did not let executives distract the project team by taking our key resources away, especially at the end. Keeping the right people throughout the project was a major factor in the success of this effort. Highly skilled and experienced people add significant value to the project but are in high demand; everyone in the company had a good reason for taking away the designers, but we had the right leadership to keep them in place.”
Once the infrastructure was developed, a final challenge that faced the team was the conversion and rollout. The conversion approach from the old, disparate databases, including the “consolidated name and address” database, would have to be executed in a one-time, over-the-weekend effort. The source databases were very large, containing millions of records that needed to be reconciled and unified. A staggered conversion, preferred by most efforts of this class, was not possible due to the preexisting interfaces between applications, the inter-relations between customers and the huge number of pre-existing and new transactions that need to be processed every night. At the same time, over the weekend, some of the existing applications had to be redirected to use the new database instead of their own while others had to “disable” their customer management capabilities and replace them with new interfaces from the new customer database.
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:
- Information, especially strategic information on customers and products, is a critical and valuable resource that requires the deployment of enterprise-strength databases.
- The technology of today can support enterprise strength databases for most organizations. Size and complexity of most enterprises are within the reach of today’s computers, networks and database management systems.
- Management leadership and commitment are required. All those involved in this effort indicated that critical to its success was a compelling business case, a clear business vision, and strong business leadership. The top executive must understand the value proposition, must articulate the vision for the organization and must lead the way. Deploying true enterprise-strength databases is a management concern, not a technology concern. Executive “buy-in” and “approval,” common management tools in the deployment of information technology, are insufficient. The common practice to “charter and fund” (in some extreme cases “delegate and forget”), and “manage by committee” causes a serious disconnect between executive management and the outcomes from these efforts.
- Enterprise-strength databases and applications must address all the information needs of all the information producers and consumers across the value chain, not just a few business areas. Their deployment may necessitate careful design for rollout across the enterprise; but the design must be based on all the information needs if it is to serve the enterprise. The common practice (not to be confused with a “best practice”) to achieve “customer data integration” or “master data management” is to focus on the needs of one business area, or a small set of business areas, to the exclusion of all other business areas. When questioned, the typical response of project leaders is “we’ll address their needs later.” The fact is that if the design does not include the information needs of all business areas, it is extremely difficult to retrofit after initial deployment. For this reason, “later” rarely arrives.
- Enterprise efforts, such as customer information management, must be funded and managed as critical enterprise investments, not departmental expenses. Most efforts of this nature are initiated, championed and funded by the IT departments, not the CEO. They are usually funded as part of one department budget and, therefore, they cannot address the needs of information producers and consumers outside the “budget boundary.” This practice perpetuates the suboptimization of the information resource: creating more departmental, fragmented information, increasing operating costs, reducing information quality and negatively impacting customer satisfaction.
- Although this organization did not use any customer data integration or master data management tools, these tools are available and can provide value in attacking technology infrastructure issues. However, it is important to maintain their value-add in the right perspective – they are part of the effort, not the solution.
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.
What do you think? Please let me know your thoughts at firstname.lastname@example.org.
- The term "enterprise-strength database" was first used by Larry P. English to differentiate true reusable databases that serve the needs of the enterprise from application specific databases. Visit www.infoimpact.com for more details.