Customer Activity Warehouse
3.4 Overall strategy for development (one piece at a time, fitting into the overall architecture)
The job of figuring out the complete and perfect alignment between all of these different aspects of the business is clearly going to be a large, complicated, and
arduous task. The knee-jerk reaction of the theorist at this point will be that the company should commission a study group or hire a consulting firm to come in and figure all of this stuff out.
For many reasons, this is probably not a good idea. Mostly, it will not be possible to do this in any reasonable amount of time or at a reasonable cost. The issues that will be uncovered when trying to figure out all of the interdependen-cies and relationships will be overwhelming physically, logically, and theoreti-cally. The danger will be that we could very quickly become “lost in the weeds”
and spend an inordinate amount of time trying to polish the model instead of worrying about the business of servicing customer needs.
For that reason, we do not propose here to go about the process of devel-oping your warehouse in this way.
You may remember that we identified three primary ways to look at the warehousing process from the knowledge management perspective. We can look at the cross-silo integration capabilities, the optimization of silo activities view, or we can look to the point in time, special purpose warehouse initiatives designed to solve immediate, pressing business problems.
Clearly, for any number of reasons, the place where we want to start is in the area of deploying effective, short-term solutions quickly. In fact, it is in the execution of these types of projects that data warehousing and data mining have shown the best success. The telecommunications industry and indeed all industries are rife with case studies of organizations that deployed warehousing to solve a particular problem and found that not only were their immediate problems solved, but that several other unanticipated benefits were discovered along the way.
In fact, as a rule of thumb, we say that any warehousing effort you pursue should
• Be operational in less than six months;
• Solve immediate tactical business problems;
• Be cost justified and, in fact, deliver at least a five times return on investment within the first 12 months of its life.
Now, that may sound like a tall order when you first look at it, but the reality is that companies are delivering that kind of return on investment within those kinds of time frames on a regular basis. During subsequent chapters we will consider in much more detail exactly how this is done, and how you can do it too.
But the more pressing issue at this juncture is this. While it is possible to deploy small, tactical warehousing solutions in order to solve immediate busi-ness problems and achieve substantial returns on investment, how do we go about organizing that process so that five years from now we do not find ourselves having to deal with dozens or even hundreds of mini-data warehouses, all of them delivering value to the business but creating yet another generation of highly interdependent, severely intransigent, and incredibly cumbersome isolated pockets of information, which will make it even harder for the company to change in the future.
Our answer to this problem is to use our earlier discussions about value-chain-driven architecture as the key.
While it is highly recommended that you limit your warehousing efforts to those areas where the business needs them the most, we also suggest that when you begin deploying those systems, you have a much bigger, enterprise-wide vision in mind. This vision should be anchored in a logical and physical architecture that is derived from your own understanding of the organizational structure and the subsequent value chain that drives the businesses survival.
In other words, you should start by imagining an environment where every major silo of information (value chain element) represents a core warehousing area. Within each of these areas will reside all information pertinent to that group of knowledge workers (Sales, Marketing, Finance, etc.). At the same time, you should have constructed a neutral, globally defined cross-silo corporate ware-housing area that will house all information that is shared, merged, or otherwise transported between those silos, as shown in Figure 3.12.
When you then set out to deploy specific tactical solutions, you can begin to overlay them into your architectural model. An example should help illustrate how this process can work.
3.4.1 The growing warehouse example
Assume an insurance company, like the one we have been discussing, where we have already figured out what the organizational structure, value chain, major processes, and operational systems look like.
The first thing we want to do is identify those places where the warehouse can deliver immediate value. In this case, we’ll say that Marketing has proven that if you could provide them with a marketing database, holding customer buying behavior and demographic characteristics, it would be possible to prequalify new customers and save the company many millions of dollars a year in prospecting costs. Clearly, this should be the first project, and so you build a miniwarehouse to meet that need.
The second thing that happens is that the Claims Processing group discov-ers that they can reduce claims for traffic accidents by gathering a database full of past claimant information and use data mining tools to detect the patterns of current customers who get into accident situations and to help those people avoid those types of situations, thereby reducing claims. Our second miniware-house is born.
With the information about customers in the marketing miniwarehouse and the information about claims available in the claims miniwarehouse, suddenly someone realizes that by combining the information from both systems you could actually figure out how likely prospective customers are to be involved in accidents and use that to assist in the underwriting and actuarial areas.
In this case, we realize that since the information is cross-silo in scope, the new system should be built in the “global” area, thereby building up the inventory of the cross-silo warehouse as well.
As time goes on, we continue to use the same decision-making criteria:
1. Build only those parts of the system that provide immediate value.
2. At the same time, place those miniwarehouses within the architectural layout where they best fit.
Marketing
Figure 3.12 The global environment.
Eventually, you could very well end up with a complete global- and silo-rich warehousing environment without ever having to stop and figure out all of the detail up front.
Of course, there are many more issues for us to consider before you go running off to try to develop a solution along the lines that we have described, but the general model for how this works is valid (see Figure 3.13).
3.4.2 Ownership of knowledge issues
While we will be using the majority of the rest of this book to help flesh out the details of how this kind of warehousing template can be developed and deployed for a telecommunications company, there is one more generalized issue that we want to discuss, and that has to do with the organizational structure and its alignment with the warehouse architecture.
Up until now we actually have not developed a very strong case for allowing our value chain and our subsequent architectural template to be driven from the organizational chart. Why is that so important? Couldn’t we, in theory, simply construct the warehouse based on what logically flows from the value chain analysis? Isn’t that in itself enough guidance for us? The answer, unfortunately, is an unequivocal no. Marketing Actuarial Underwriting Claims Sales Marketing
Figure 3.13 Stepwise construction of the global warehouse.
In actuality, making sure that the organization and the warehouse line up is probably the most important key to making it successful, and the reason is pretty obvious when you stop and think about it.
We can theorize, conjecture, and wax philosophic all day and all night about the benefits of data warehousing and the different ways it can help. We can even build strong cases that rationalize building different parts of the system or even the overall warehouse structure.
But, unfortunately, nothing gets done in the business world unless there is a business manager—responsible for an operational area of the business, with a staff and a budget and bottom-line revenue and expense responsibilities—who is willing to commit the funding for the project. And only the most altruistic, intelligent, and farsighted business manager in the world is going to fund a multimillion dollar data processing project that doesn’t deliver immediate and substantial value to his or her particular area of the business. While this may seem selfish, shortsighted, and not fair, it is a fact of life.
So, what this means is that we will need to put our architecture together based not only on what the logical and functional realities of the business are, but on the budgetary and political realities as well. No manager wants to pay to help some other manager.
Therefore, we will inevitably be forced to build just as many different miniwarehouses as it is going to take in order to get the job done.
The good news is that over time, as our global warehouse becomes more
“filled in,” our dependence on these conditions will become less and less.
In the next chapter we will begin to apply this theory to practice by taking a look at telecommunications organizational structures, processes, and typical value chains, and with these propose some candidate warehouse templates that you can use as starting points for your own analysis.