9.3. Determining Component Scope
We know from Chapter 3 that our CRM infrastructure is made up of the four key components: information, process, technology, and people. That means that the project charter must include deliverables, milestones, and resources of these four components. If we define only the technology deliverables for a project, we will not be able to deliver successful results.
9.3.1. The Components
Each of these four components is critically important to CRM success. Let's review the importance of each one.
Information
Information is the raw material of CRM. Without information, there is no way to use automation to build and manage customer relationships. A web site that looks personalized (Welcome, Judy) but contains no information that is relevant to me is worse than visiting an anonymous web site. The information may be collected and stored by the IT organization, but it is the business functions that know what information they need to address the business objective.
Process
Our processes are the means by which we actually deliver experiences to customers. People used to manage the process interactions with customers and protected them from some of the disconnects between processes. Now, we are asking our IT departments to automate many of these processes, but it is still the business team that knows what customers expect, where the breakdowns are, and what doesn't work very well. As we automate more processes, we need to be sure that we heavily involve those who work directly with customers and (heavens!) even the customers themselves. Automating an old, broken process just allows more bad choices to be made faster.
Technology
Technology is the machinery that produces CRM results. All of the best information, process improvements, and change-management programs will be useless if you don't have the right technology in place. This is the reason that it is so critical to keep your IT team and business team working together from the beginning. It's silly to ask Information Technology to make all the business decisions or to wait until all the decisions are made and then throw a project charter over the wall to the IT department and hope they understand it. Build the partnership early, and make it work. The business function is the primary provider of the content of the system and Information Technology is the primary manager of the processing of the system. As we move through the life cycle, IT takes more ownership, but the business function always has some responsibility. Marketing may not do construction, but they must be involved in testing modules as they are developed and in the initial implementation when released.
Somewhere between the project launch (where the project is defined) and the end of analysis (where business requirements are analyzed) is the transition point where business function involvement drops below 50 percent and the IT team's responsibility grows to a significant percentage of the work.
People
Even though people may not be directly delivering some customer experiences any more, it is still people who can really understand and address customer needs. People and organizations can smooth the implementation of the new CRM capabilities and ensure success, or they can, for lack of education, tools, or whatever, guarantee that the new “system” will fail.
Now let's take a look at a concept that will help us understand each of the four CRM components from both the business perspective and the Information Technology perspective: the concept of the enterprise architecture.
9.3.2. Enterprise Architecture
The purpose of the enterprise architecture is to capture all the different knowledge and perspectives held by various key players in the organization about what makes the business work. John Zachman popularized the concept of the enterprise-wide information architecture in an article he published in 1987 in the IBM Systems Journal. Zachman's major contribution was the development of his framework for enterprise architectures.
Why should we care about yet another framework? As we've discussed, tools and methodologies help us understand and organize the work that needs to be done. Any effort that requires the joint participation of business functions and Information Technology needs a formalized model of who is responsible for what and a way that helps improve communication between the two teams. Of course, this is not just a CRM tool; all large programs that include a technology component need a way to bridge the communication gap between the business team and the IT team, which are jointly responsible for delivering the program. It's all about increasing understanding between groups of people who don't exactly share the same view of the situation.
Framework
Zachman introduced his Enterprise Architecture Framework as a way to organize and classify knowledge about the whole business so that this knowledge could be used to design and build an organization's enterprise-wide business infrastructure, including its CRM program.
Building your CRM infrastructure has many parallels with the process of constructing a new house. Let's take a look at what happens when you do decide to build a house. It would be very unusual if you just picked up the phone one day, called a contractor you found in the Yellow Pages, and said, “Hey, can you build a house for me? I've already got the property and some ideas, so I just need you to build it.” As silly as it sounds, that is often what we ask the IT department to do when we need them to build our information systems.
|
It is unlikely that any contractor would accept such a job, and if he did, it's unlikely that you would be happy with the result! Instead, you would start by listing and sketching some rough ideas of what you think you want. You give your ideas to an architect who works with you to develop some alternative rough plans or models that might meet your needs. After you pick the alternative you like best, the architect develops an overall picture (blueprint) of what should be built (to the best of everyone's knowledge at that time). Then the architect creates very specific technical specs for every major component (concrete, wood, plastic, finishes, etc.) of the construction. These plans go to the contractor so he can start delivering detailed specs to the individual subcontractors who will work on the various components: concrete, framing, electrical, plumbing, etc.
What we have just described is exactly what Zachman's framework covers, and not surprisingly, the framework is actually based on well-known principles used in the traditional disciplines of architecture and construction. It is made up of columns representing the six different elements of the finished product (for construction, these would be electrical, plumbing, etc.) and rows representing the five different perspectives (levels of detail such as owner, designer, subcontractor). Zachman includes a sixth row representing the end goal: a functioning enterprise.
We already know the critical elements or components of our CRM program: information, process, people, and technology. It should be no surprise that these are also the first four columns of the Zachman framework. The added insight from Zachman, as we've already discussed, is that each of these components must be viewed and defined from the perspective of each of the various stakeholders. These perspectives must be captured in sequence, starting with least level of detail. Each more detailed perspective must be derived from the previous level. (How else will the plumbing actually end up where you want the sink to be?) Each stakeholder, from business owner defining requirements to IT programmer writing computer code, has more detailed knowledge of what it takes to build the infrastructure.
The components of the Zachman framework are data, function, network, people, time, and motivation. Do the first four sound familiar? Just in case they don't, Table 9-5 shows the relationship to our CRM components.
| Zachman's Components | Data | Function | Network | People |
| CRM Components | Information | Process | Technology | People |
Zachman's list of stakeholders and the corresponding homeowner/business owner perspectives are shown in Table 9-6. The highest perspective, the owner's wish list, is the equivalent of the strategic plan that we completed in Chapter 8. As you remember, we developed a high-level outline of our entire CRM program. For each of the subsequent levels, we will drive down to each more detailed perspective for just what is needed for a current project. This is how we achieve quick wins while keeping focused on the overall strategic objective.
| Zachman's Stakeholder Perspectives | Business Scope | Business Model | System Model | Technology Model | Detailed Representations | Functioning Enterprise |
| Home (or Business) owner's Perspectives | Owner's Wish List | Owner's Needs View | Designer's View | Builder's View | Subcontractor's View | New Home |
More information on the Zachman Framework can be found online at the Zachman Institute for Framework Advancement web site: www.zifa.com.
Ideally, companies would use this approach to understand needs and to design and build technology solutions for the entire enterprise. Practically speaking, if your company hasn't already applied this approach for your whole organization, the framework is still incredibly useful for understanding needs within just the front office organizations. Because CRM crosses multiple functions and needs broad business participation and perspective, a framework is a great way to understand what steps to take. If most of your house is okay, you don't need to pay an architect to redesign the whole thing. Just think of it as a remodel; Zachman's framework still works!
Although Zachman's framework is widely used within the IT community (including yours, I hope), we've already suggested the sad truth that Information Technology seldom gets much support or participation from the business owners who think technology is magic and somewhat beyond them. Building IT systems without demanding business owner participation is just like hiring a bunch of subcontractors to do the framing, install doors and windows, and lay electrical conduit without letting anyone know what you want the house to look like.
In Chapter 5, we saw that the relative responsibility for the internal CRM phases (1 and 2) is initially weighted heavily toward the business functions and transitions to heavy involvement of Information Technology. There is an Information Technology project life cycle that continues to be widely used today. The project life cycle steps correspond exactly to the business owner's perspectives as you see in Figure 9-5. As you can also see, the relative business function/IT department responsibilities map consistently to the stakeholder's perspectives and the traditional systems development project steps. The strong parallels between the business and the Information Technology description of the life cycle steps make it easier to understand each other's roles and responsibility. We're starting to develop a common language.
Figure 9-5. The relative responsibilities for CRM lifecycle internal phases
As we know, relative responsibility shifts step by step throughout each project life cycle step. The heaviest business involvement occurs in the early steps where the broadest perspective and least detail are required. Just about the time the project moves from the owner's needs view to the designer's view, much of the responsibility is transferred from primarily business to primarily IT. This transfer of responsibility takes place and can occur at different points for different projects or even different components of the same project. The business may have most of the responsibility for all levels of the people component, but may be involved only at the highest strategy-setting level for the technology. The transfer is the point at which communication and handoff problems most often occur. For the most part, the transfer takes place sometime during one of the first three levels; this is why we will concentrate most of our efforts there. The handoff is always the most critical point in any technical project.
You will find a very readable and informative introduction to the high-level business view of Zachman's framework in Building Enterprise Information Architectures by Melissa Cook (1996). Cook does an excellent job of explaining how to work through the highest information, process, and technology levels. Table 9-7, adapted from Cook's work, shows the framework we will use.
| Information | Process | Technology | People | |
|---|---|---|---|---|
| Owner's Wish List View | Data class (list of things important to the business) | Business function (list of types of work the business performs | Business location (list of places in which the business operates) | Organizations (list of the organizational units that are important to the business. |
| Owner's Needs View | Business subjects | Business process model | Business network | Organizational unit |
| Designer's View | Entity and relationship model | Activity | Distributed system architecture | Job role |
This CRM view includes the four CRM core components (information, process, people, and technology) and the highest perspectives (owner's wish list, owner's needs view, and designer's view).
Method: Engineering Each Component
Just as the owner and architect work together to turn the owner's wish list into a sketchy floor plan and then a detailed blueprint, we need to be able to develop ever more detailed requirements and specifications for each of the infrastructure components.
The highest level (the owner's wish list) is actually a deliverable from the strategic plan that we developed in Chapter 8. At that time, we were introduced to the topic of strategic planning for the CRM components. However, we postponed the discussion of how to use the methodology until now, because the whole process of going from owner's wish list to designer's view will be easier to follow if discussed in one place for each component. But do remember, the owner's wish list for each of the components was completed as part of your strategic plan. During each project, we'll use the owner's wish list view as the starting point for identifying just enough of the lower levels of detail that we need to complete that project. The strategic plan provides the vision and focus that allow us build a successful CRM program in small steps.
It is imperative that each perspective is based on the preceding level, just with more detail. What would you think of a subcontractor who ignored the specs and just did what he wanted? I can tell you exactly what you'd think, because my family and I had one (or maybe I can't tell you, not in print anyway). We have been living with the shoddy results of the electrical subcontractor (who ignored the plans and did things his own way) for 15 years. Not a single week goes by that we don't have the opportunity to enjoy his creative and independent decisions! Sometimes, you may run into a programmer who has the same brand of creativity. It is great if you get to work with an IT department whose people are creative about how to achieve the predefined goal, but it is not okay for them to be creative about the goal itself.
Let's get a quick refresher on the strategic planning process we followed. We used four assessment tools to collect and analyze information from inside our company, from customers, and from sources that gave us information about our position relative to competitors. Then we used other tools to prepare our strategic proposal, which includes the owner's wish list for the information, process, technology, and people components.