The CRM Landscape: Why Now

This chapter is from the book

Special Edition Using Microsoft CRM

Learn More Buy

This chapter is from the book

This chapter is from the book 

Special Edition Using Microsoft CRM

Learn More Buy

CRM and Transaction Processing

A day in the life of a piece of corporate data will see that data move through many different perspectives of use and handling. First, it is captured and checked for errors in entry, format, and other attributes according to its validation rules. Next, it travels to the systems that utilize the data for primary business contact, processing transactions and supporting primary business functions such as sales, order-fulfillment, and services. After being cleaned up for corporate standards, the data moves on to be shared with other systems that need it to complete their picture of the company's business, and is manipulated and stored in decision support holding areas. Finally, the data is distributed for selective viewing of both company insiders and external users such as customers and suppliers.

Opposite Needs for Opposite Goals

In the lifecycle of data management, marketing information systems such as CRM occur at the polar opposite of transaction processing systems. CRM needs data across application systems, such as all customer accounts, not just those belonging to one product line or line of business, whereas transaction processing systems often house data for only one product line or line of business. The goals of CRM systems are global, whereas the goals of transaction processing systems tend to be local.

Indeed, at each step of the lifecycle different priorities will surface. They will require different technical design and development approaches employing defined terms and agreed upon structures. Figure 3.1 shows the steps of the cycle and some of the supporting technical structures. It adopts a starting point where customer and supplier interactions initiate business transactions that must be processed. Keep in mind that although it's a common starting point it is a little arbitrary because activities in any step of this model can act as a starting point.

Figure 3.1 The Cycle of Data Management depicts how data is utilized at each step of the process.

The steps of the Cycle of Data Management are listed here:

1. Process business transactions

2. Transform data for sharing

3. Support business decisions

4. Create external portals

5. Create internal portals

6. Interact with customers and suppliers

Process Business Transactions

Business events, such as a customer contact resulting in a sales order being placed, or a customer request that is fulfilled by customer service personnel, produce data that must be managed. They involve relatively small amounts of data that must be maintained with a high level of accuracy at the time of the transaction and access of the data. Business transactions are typically simple transactions involving very detailed data. For example, a customer order includes specific mailing address, product information, and pricing details.

The systems that support such business transactions must handle many simultaneous updates, reads, and insertions of data. They must often be available for processing on a continual basis, 24 hours a day, and 7 days a week. They have low requirements for storage of historical information, usually needing only that information required for supporting the flow of work.

The data model for supporting business transactions is usually highly normalized, which means that data components are structured so that they are stored only once for convenient control of updates. It also attempts to achieve a balance between design for state modification (insert, update, delete) and speed of retrieval or data access. Because the data usage is predictable, the data model can be optimized for these performance concerns.

Data management in business transactions usually prioritizes data persistency and state management. It will be utilized by down-stream systems (subscribers to the information), which are usually unrelated to the systems producing the data.

Transform Data for Sharing

The data produced in business transactions must often be transformed before sharing with other applications. Sometimes sensitive or irrelevant information must be removed before sharing. At other times information must be made generic so that it matches the definitions of other application views. Some data will be summarized and used to support analytical processing or decision support. Other information will be used internally by other departments such as operations or financial reporting, whereas some data is selected for sharing with customers and suppliers, depending on the requirements of their interactions with the company.

Data extract, transformation, and middleware tools are all means of transforming data to make it suitable for sharing. Extract and transformation tools usually help to convert, cleanse, and standardize data. Middleware and messaging technologies facilitate the physical aspects of sharing data, through the use of data delivery mechanisms and subscription maintenance machinery.

The priorities at this stage are for credible data, verified, cleansed, and transformed in a streamlined process. Speed of data availability for sharing with mission-critical applications is also an important factor.

Support Business Decisions

The data that is delivered to decision-support applications, such as CRM systems, is used to help companies measure performance, manipulate revenue and yield ratios, make market decisions, and monitor operational statistics. It is earmarked for business management and strategic functions, and used in determining competitive advantage. It can be used to identify opportunities for improvement and growth of the company.

Decision support data is often derived through summarization and calculations applied to detailed data taken from transaction-processing systems. It often involves large volumes of data, with significant amounts of historical data used for trending and reporting of regulatory and markets information. Analytical processing usually involves complex transactions or queries against the data, utilized in unpredictable ways by processes characterized by discovery. A fairly small user community (managers, executives, and analysts) needs actual access to the data.

Data models for analytical processing are optimized for rapid access through non-repetitive queries, producing unpredictable workloads. The priority is on efficient data retrieval, which requires that data be heavily indexed and de-normalized (more than one copy of a data component stored) for convenient access rather than normalized for convenient update. Integrity constraints such as those utilized for transaction processing (primary keys, foreign keys, and column constraints) are generally relaxed in decision-support systems because the source systems can be expected to enforce the referential integrity that is required.

Create External Portals

External portals provide access to customers and suppliers for carefully selected portions of a company's information. Portals can deliver a personalized view of real-time order and inventory information to customers and supply-chain partners. "Drill down" capability provides self-service access to orders, disposition of service queries or cases, increasing customer satisfaction, while simultaneously reducing support costs.

Portions of the business process in which customers or suppliers participate may be detailed on public Web sites. Financial performance may be provided in annual reports online or investor information packets. Product and service specifications and pricing may also be made available through an external portal on company information.

Wirelessly enabled CRM systems deliver real-time order visibility to any wireless device, empowering salespeople and customer service reps to provide customers immediate answers to delivery inquiries regardless of where they are.

Characterized by selective viewing, external portals usually reside outside a company's firewall, providing a highly secured environment for customer and supplier interactions.

Create Internal Portals

Internal portals allow parties within a company to access data according to the needs of their particular business or application viewpoint. Data warehouses spawn data marts, which house application-specific views of data replicated from the central repository. Intranet portals provide windows on data that might be needed by operational personnel or marketing analysts.

A typical executive view includes up-to-the-moment Key Performance Indicators (KPIs) such as Order Status, Costs versus Goals, and so forth. Portals also enable executives to set custom Business Alert levels to provide immediate notification to business rule exceptions. Timely notification of deviations from plan enables executives to take action to correct problems before they impact production goals, reducing production, and cost variability.

Internal portals represent multiple views against the company's information and are generally accessed with low security requirements, within the confines of a company firewall.

Interact with Customers and Suppliers

Interactions with customers and suppliers can occur through the window of an external portal, or they can be facilitated by business transaction processing systems. Sometimes they occur with replicated versions of company data, carried by a sales or marketing representative in a remote device such as a laptop computer configured to provide price quotes and service specifications.

Interactions are increasingly likely to occur through various means of electronic exchange, whether via XML Web services, extended component technology, or B2B mechanisms.

Distribution of data becomes important in the interaction step, with an emphasis on convenient access and accuracy to certain limits established within a window of time. Metadata definition, partitioning, and data replication are schemes that facilitate the desired distributed deployment of components of data.

The Horizontal View

The systems that process business transactions usually reside in a vertical slice of the overall business process. Order entry occupies one vertical slice, whereas order fulfillment occupies another. But CRM systems typically look across these verticals to represent the horizontal view.

Because the customer relationship occurs across all applications, as everything a company does ultimately serves customers, the systems for managing that relationship have to span across vertical applications.

The Holistic View

Whereas business transaction processing systems drill down to the details of a particular customer interaction, CRM wants to know about all customer transactions. The CRM portal might support customer access to the details of a transaction, but overall, CRM encompasses all transactions.

For example, in a financial services institution, a customer opens a checking account and a savings account. Later the same customer applies for a loan and a credit card, and then buys a house, borrowing the money from the same institution through a mortgage loan. All these accounts are processed as separate transactions, stored in separate systems, reported on, and serviced separately. However CRM, in looking at the whole customer relationship, wants to know about all the accounts. They represent share-of-wallet—how much of a customer's potential business have we acquired? What further business might we propose, and in what order is the customer most likely to desire to purchase? These are questions that CRM systems are set up to answer, and they require data extracted from all the individual systems that a customer's relationship with the company might involve.

Thus, CRM represents a holistic view. It requires information about the whole customer interface, including all customer touch points and all service and delivery channels. It requires a uniquely comprehensive view of the customer relationship and all the factors that enter into determining the value of that relationship, and its health and potential longevity.

CRM Requirements

Because of the differences between CRM and transaction processing systems, CRM requirements present a whole new ballgame for application developers. Differing requirements dictate different technical solutions.

CRM projects differ significantly from OLTP (online transaction processing) software development projects. The business requirements for OLTP development projects are usually well understood and finite in nature. They are specific to the needs of a departmental tactical solution, and are managed with a clearly structured approach. Requirements for CRM projects, on the other hand, typically evolve as the project unfolds, and are accomplished with a pragmatic approach, which expects mid-course corrections throughout the duration of the project. OLTP development delivers tactical solutions to defined problems, specified to solve departmental concerns. CRM delivers the holistic view of enterprise applications, with a focus on the strategically transparent support of a new kind of customer relationship.

OLTP development projects usually occur in a controlled environment where the technical manager has the freedom to select among predefined and standardized platform options. The development of OLTP solutions is generally treated as a black box, with input and outputs defined, where everything inside the box falls under the project manager's control. He will develop local applications, which are built on either a single platform or a distributed platform using local and internal networks. CRM projects generally take place in an uncontrolled environment. The CRM integrator must deal with a variety of technologies, old and new, which are already embedded in existing systems. The CRM integrator works within the confines of the existing architecture.

On OLTP development projects, team members are specialists who apply the discipline of systems engineering to well-defined specifications. The goals of CRM involve the alignment of legacy systems (usually with little or no documentation available) and their merging with newer technologies in the global CRM/Internet arena. Therefore, the CRM integrator is usually more of a generalist, with expertise in multiple systems arenas. The CRM integrator must also be skilled at utilizing specialized resources at the right time.

CRM projects extend across the enterprise and its relationships with customers and the supply chain, whereas OLTP development projects usually concentrate on local objectives. The data in these local projects tends to be discrete and contained, easily understood and modeled. CRM systems on the other hand, must reconcile data from disparate sources in disparate formats. It is not unusual for a CRM effort to require the merging of data from five to ten, or even fifty different application systems (built on different platforms at different times by different vendors). It can also require that the integrated platform account for less structured data from sources such as various Internet sites, or telecommunications software packages where data is scraped from online screens in a blob, which must be parsed and managed.

The implementation model for OLTP development is usually either top-down in structured projects that proceed from conceptual design to logical analysis and detailed design and development, or bottom-up, in typical object-oriented approaches. The model for CRM projects, on the other hand, is middle-out. First, it focuses on the system's use, in the context of CRM business goals. Then, it builds simultaneously upward to business modeling and downward to detailed technical design to deliver the system. The CRM project can drive process improvements upward to the business model, as well as incorporate technical efficiencies at the system level.

Table 3.1 summarizes how OLTP development projects differ from CRM projects.

Table 3.1 Differences Between OLTP Development Projects and CRM Projects

Because of the many differences between OLTP and CRM, CRM systems have evolved separately from many other business applications.