Challenging the “CRM”

Dears,

For many of us CRM or/and Customer Management Systems are simple or synonymous to a IT Application and processes but the truth is “ CRM is a centurion effort” of last 20 years of work in this Customer Management discipline than have been renamed as CRM. These years have been years of success and years of frustration. The lasting gain from these twenty years has been a wealth of experience in all aspects of CRM, from defining it to implementing it. A discipline of technology grows the more it is questioned and put through the furnace, It may come out as Gold or may turned to ashes but this exercise is must for it see the future far beyond from next few years.

In the market today for CRM and related ideas, supply exceeds demand. Small Products have collapsed. The Big CRM companies are much less bullish. Many large consultancies and marketing service agencies were at the time of writing 'letting go' many of their staff. Analysts were busy publishing reports showing by how much systems suppliers and consultancies over-estimated returns and underestimated implementation difficulties in their attempts to push up the price and desirability of their services - as if the analysts themselves were not heavily tarred with the same brush. As the salesmen of these new ideas retire to lick their wounds, what are marketers left with? Can marketers continue to practice and teach marketing and selling as they always did? Have the central ideas of marketing, such as branding, been completely unaffected by the temporary intoxication of senior marketing management with CRM and e-business ideas?

It's not unusual to hear senior managers claiming that their company is aiming to recreate the 'customer intimacy' that was characteristic of the corner shop in earlier generations. Of course, most corner shops sold to poor consumers at very high margins, and in some cases used credit as an insidious loyalty device to ensure that the customer's business did not go elsewhere. In the distant past, for some workers the only shops that would trade with them were company shops, working on terms that were severe enough to trigger the foundation of the co-operative movement. Such analogies can be misleading because they do not ask whether a giant telecommunications company, bank or a retailer should even be aspiring to such 'intimacy'. Today's self-service era has cut out 'unnecessary' human intervention, allowing big companies to supply vast numbers of individuals with products and services that are far cheaper in real terms than those bought by our supposedly 'lucky' forebears, while for those of us who like privacy, the absence of human intervention is a blessing.

This raises some interesting questions. Are large companies going too far in trying to match their offer to individuals? Are CRM initiatives that aim to recreate customer intimacy for very large companies doomed to failure because they aim too high or because they aim to do it too fast? Do those large companies that succeed in creating customer intimacy do so only by adopting an unprofitable business model? Do most customers prefer to avoid intimacy, now that they have discovered that they can get much of what they want from large companies without getting too involved?

The answer to all of these questions is 'possibly, yes, in most cases'. Most analysts agree about the relatively high rate of CRM programme failure and how it is induced by trying to do too much too soon. However, the story is not all doom and gloom. In fact, many of the larger companies that are succeeding (by their business measures and by measures of customer satisfaction) in customer management are doing so almost by stealth, over a period of years. In these companies, we see a steady rise in value per customer, declining recruitment of low or negative value customers, better customer retention, and increasing cost-effectiveness of customer management (largely driven by propositions which make it easy for customers to get what they want by using lower cost channels and by their taking on themselves some of the costs of being managed). In these large companies, we find programme management disciplines being observed, by teams which combine marketing, customer service and systems people, working to common objectives and with a clear mandate from senior management to take time to improve customer management, on the condition that returns to customer management are achieved not too long after the investment, and that the benefits of improved customer management are visible in cost savings (eg use of lower cost channels of communication and distribution) as well as in revenue gains (which usually take longer).

Most noticeable of all in these companies is the relatively high proportion of internal input (relative to consultancy input) at the beginning of the journey, with most of the external spend being later, on implementation rather than on reconsidering directions. Putting it another way, big companies cannot do CRM through consultants - they must have critical mass of people in areas such as marketing, IT, customer service and operations who are committed to improving customer management, who have the knowledge and skills required to do so, who are committed to staying with their company to see it through, and perhaps most importantly of all, are wise enough to see through the nice CRM phrases into a more realistic world where it is understood that managing customers is mostly about managing people who manage customers (and only rarely about doing it entirely through computers, as on the Web).

So, size matters in a strange way in CRM. It does make succeeding in CRM more difficult, and makes it take longer. But it probably also means that when you have 'got CRM going', and when you are measuring your progress carefully, with metrics that include not just what customers are doing (hopefully buying more, more often, additional products etc) or thinking (hopefully more satisfied) but also your internal process metrics (fewer leads lost, faster reactions to customers, better targeting), it becomes self-sustaining, partly because success breeds success. Customers like it when companies get the basics right, and so do staff.

Seize the day, Gentlemen and Make your CRM little more better every day

Loving P&C

DC*

MDM Made Easy

MDM Made Easy

Dears,
This is must read Article for all MDM Aspirants , Be it a IT Professional or Corporate Folks who are taking their first step towards MDM initiative. This article is based on  Roger Wolter and Kirk Haselden research work on "MDM".
The pain that organizations are experiencing around consistent reporting, regulatory compliance, strong interest in Service-Oriented Architecture (SOA), and Software as a Service (SaaS) has prompted a great deal of interest in Master Data Management (MDM). This paper explains what MDM is, why it is important, and how to manage it, while identifying some of the key MDM management patterns and best practices that are emerging. This paper is a high-level treatment of the problem space. In subsequent papers, we will drill down into the technical and procedural issues involved in Master Data Management.

What Is Master Data?

Most software systems have lists of data that are shared and used by several of the applications that make up the system. For example, a typical ERP system as a minimum will have a Customer Master, an Item Master, and an Account Master. This master data is often one of the key assets of a company. It's not unusual for a company to be acquired primarily for access to its Customer Master data.

Rudimentary Definitions

There are some very well-understood and easily identified master-data items, such as "customer" and "product." In fact, many define master data by simply reciting a commonly agreed upon master-data item list, such as: customer, product, location, employee, and asset. But how you identify elements of data that should be managed by a master-data management system is much more complex and defies such rudimentary definitions. In fact, there is a lot of confusion around what master data is and how it is qualified, necessitating a more comprehensive treatment.

There are essentially five types of data in corporations:

• Unstructured—This is data found in e-mail, white papers like this, magazine articles, corporate intranet portals, product specifications, marketing collateral, and PDF files.

• Transactional—This is data related to sales, deliveries, invoices, trouble tickets, claims, and other monetary and non-monetary interactions.

• Metadata—This is data about other data and may reside in a formal repository or in various other forms such as XML documents, report definitions, column descriptions in a database, log files, connections, and configuration files.

• Hierarchical—Hierarchical data stores the relationships between other data. It may be stored as part of an accounting system or separately as descriptions of real-world relationships, such as company organizational structures or product lines. Hierarchical data is sometimes considered a super MDM domain, because it is critical to understanding and sometimes discovering the relationships between master data.

• Master—Master data are the critical nouns of a business and fall generally into four groupings: people, things, places, and concepts. Further categorizations within those groupings are called subject areas, domain areas, or entity types. For example, within people, there are customer, employee, and salesperson. Within things, there are product, part, store, and asset. Within concepts, there are things like contract, warrantee, and licenses. Finally, within places, there are office locations and geographic divisions. Some of these domain areas may be further divided. Customer may be further segmented, based on incentives and history. A company may have normal customers, as well as premiere and executive customers. Product may be further segmented by sector and industry. The requirements, life cycle, and CRUD cycle for a product in the Consumer Packaged Goods (CPG) sector is likely very different from those of the clothing industry. The granularity of domains is essentially determined by the magnitude of differences between the attributes of the entities within them.

Deciding What to Manage

While identifying master data entities is pretty straightforward, not all data that fits the definition for master data should necessarily be managed as such. This paper narrows the definition of master data to the following criteria, all of which should be considered together when deciding if a given entity should be treated as master data.

Behavior

Master data can be described by the way that it interacts with other data. For example, in transaction systems, master data is almost always involved with transactional data. A customer buys a product. A vendor sells a part, and a partner delivers a crate of materials to a location. An employee is hierarchically related to their manager, who reports up through a manager (another employee). A product may be a part of multiple hierarchies describing their placement within a store. This relationship between master data and transactional data may be fundamentally viewed as a noun/verb relationship. Transactional data capture the verbs, such as sale, delivery, purchase, email, and revocation; master data are the nouns. This is the same relationship data-warehouse facts and dimensions share.

Life Cycle

Master data can be described by the way that it is created, read, updated, deleted, and searched. This life cycle is called the CRUD cycle and is different for different master-data element types and companies. For example, how a customer is created depends largely upon a company's business rules, industry segment, and data systems. One company may have multiple customer-creation vectors, such as through the Internet, directly through account representatives, or through outlet stores. Another company may only allow customers to be created through direct contact over the phone with its call center. Further, how a customer element is created is certainly different from how a vendor element is created. The following table illustrates the differing CRUD cycles for four common master-data subject areas.

Cardinality

As cardinality (the number of elements in a set) decreases, the likelihood of an element being treated as a master-data element—even a commonly accepted subject area, such as customer—decreases. For example, if a company has only three customers, most likely they would not consider those customers master data—at least, not in the context of supporting them with a master-data management solution, simply because there is no benefit to managing those customers with a master-data infrastructure. Yet, a company with thousands of customers would consider Customer an important subject area, because of the concomitant issues and benefits around managing such a large set of entities. The customer value to each of these companies is the same. Both rely upon their customers for business. One needs a customer master-data solution; the other does not. Cardinality does not change the classification of a given entity type; however, the importance of having a solution for managing an entity type increases as the cardinality of the entity type increases.

Lifetime

Master data tends to be less volatile than transactional data. As it becomes more volatile, it typically is considered more transactional. For example, some might consider "contract" a master-data element. Others might consider it a transaction. Depending on the lifespan of a contract, it can go either way. An agency promoting professional athletes might consider their contracts as master data. Each is different from the other and typically has a lifetime of greater than a year. It may be tempting to simply have one master-data item called "athlete." However, athletes tend to have more than one contract at any given time: one with their teams and others with companies for endorsing products. The agency would need to manage all those contracts over time, as elements of the contract are renegotiated or athletes traded. Other contracts—for example, contracts for detailing cars or painting a house—are more like a transaction. They are one-time, short-lived agreements to provide services for payment and are typically fulfilled and destroyed within hours.

Complexity

Simple entities, even valuable entities, are rarely a challenge to manage and are rarely considered master-data elements. The less complex an element, the less likely the need to manage change for that element. Typically, such assets are simply collected and tallied. For example, Fort Knox likely would not track information on each individual gold bar stored there, but rather only keep a count of them. The value of each gold bar is substantial, the cardinality high, and the lifespan long; yet, the complexity is low.

Value

The more valuable the data element is to the company, the more likely it will be considered a master data element. Value and complexity work together.

Volatility

While master data is typically less volatile than transactional data, entities with attributes that do not change at all typically do not require a master-data solution. For example, rare coins would seem to meet many of the criteria for a master-data treatment. A rare-coin collector would likely have many rare coins. So, cardinality is high. They are valuable. They are also complex. For example, rare coins have a history and description. There are attributes, such as condition of obverse, reverse, legend, inscription, rim, and field. There are other attributes, such as designer initials, edge design, layers, and portrait.

Yet, rare coins do not need to be managed as a master-data item, because they don't change over time—or, at least, they don't change enough. There may need to be more information added, as the history of a particular coin is revealed or if certain attributes must be corrected. But, generally speaking, rare coins would not be managed through a master-data management system, because they are not volatile enough to warrant a solution.

Reuse

One of the primary drivers of master-data management is reuse. For example, in a simple world, the CRM system would manage everything about a customer and never need to share any information about the customer with other systems. However, in today's complex environments, customer information needs to be shared across multiple applications. That's where the trouble begins. Because—for a number of reasons—access to a master datum is not always available, people start storing master data in various locations, such as spreadsheets and application private stores. There are still reasons, such as data-quality degradation and decay, to manage master data that is not reused across the enterprise. However, if a master-data entity is reused in multiple systems, it's a sure bet that it should be managed with a master-data management system.

To summarize, while it is simple to enumerate the various master-data entity types, it is sometimes more challenging to decide which data items in a company should be treated as master data. Often, data that does not normally comply with the definition for master data may need to be managed as such, and data that does comply with the definition may not. Ultimately, when deciding on what entity types should be treated as master data, it is better to categorize them in terms of their behavior and attributes within the context of the business needs than to rely on simple lists of entity types.

Why Should I Manage Master Data?

Because it is used by multiple applications, an error in master data can cause errors in all the applications that use it. For example, an incorrect address in the customer master might mean orders, bills, and marketing literature are all sent to the wrong address. Similarly, an incorrect price on an item master can be a marketing disaster, and an incorrect account number in an Account Master can lead to huge fines or even jail time for the CEO—a career-limiting move for the person who made the mistake!

Here is a typical master-data horror story: A credit-card customer moves from 2847 North 9th St. to 1001 11th St. North. The customer changed his billing address immediately, but did not receive a bill for several months. One day, the customer received a threatening phone call from the credit-card billing department, asking why the bill has not been paid. The customer verifies that they have the new address, and the billing department verifies that the address on file is 1001 11th St. N. The customer asks for a copy of the bill, to settle the account. After two more weeks without a bill, the customer calls back and finds the account has been turned over to a collection agency. This time, they find out that even though the address in the file was 1001 11th St. N, the billing address is 101 11th St. N. After a bunch of phone calls and letters between lawyers, the bill finally gets resolved and the credit-card company has lost a customer for life. In this case, the master copy of the data was accurate, but another copy of it was flawed. Master data must be both correct and consistent.

Even if the master data has no errors, few organizations have just one set of master data. Many companies grow through mergers and acquisitions. Each company you acquire comes with its own customer master, item master, and so forth. This would not be bad if you could just Union the new master data with your current master data, but unless the company you acquire is in a completely different business in a faraway country, there's a very good chance that some customers and products will appear in both sets of master data—usually, with different formats and different database keys. If both companies use the Dun & Bradstreet number or Social Security number as the customer identifier, discovering which customer records are for the same customer is a straightforward issue; but that seldom happens. In most cases, customer numbers and part numbers are assigned by the software that creates the master records, so the chances of the same customer or the same product having the same identifier in both databases is pretty remote. Item masters can be even harder to reconcile, if equivalent parts are purchased from different vendors with different vendor numbers.

Merging master lists together can be very difficult. The same customer may have different names, customer numbers, addresses, and phone numbers in different databases. For example, William Smith might appear as Bill Smith, Wm. Smith, and William Smithe. Normal database joins and searches will not be able to resolve these differences. A very sophisticated tool that understands nicknames, alternate spellings, and typing errors will be required. The tool will probably also have to recognize that different name variations can be resolved, if they all live at the same address or have the same phone number. While creating a clean master list can be a daunting challenge, there are many positive benefits to your bottom line from a common master list:

• A single, consolidated bill saves money and improves customer satisfaction.

• Sending the same marketing literature to a customer from multiple customer lists wastes money and irritates the customer.

• Before you turn a customer account over to a collection agency, it would be good to know if they owe other parts of your company money or, more importantly, that they are another division's biggest customer.

• Stocking the same item under different part numbers is not only a waste of money and shelf space, but can potentially lead to artificial shortages.

The recent movements toward SOA and SaaS make Master Data Management a critical issue. For example, if you create a single customer service that communicates through well-defined XML messages, you may think you have defined a single view of your customers. But if the same customer is stored in five databases with three different addresses and four different phone numbers, what will your customer service return? Similarly, if you decide to subscribe to a CRM service provided through SaaS, the service provider will need a list of customers for their database. Which one will you send them?

For all these reasons, maintaining a high-quality, consistent set of master data for your organization is rapidly becoming a necessity. The systems and processes required to maintain this data are known as Master Data Management.

What Is Master Data Management?

For purposes of this article, we define Master Data Management (MDM) as the technology, tools, and processes required to create and maintain consistent and accurate lists of master data. There are a couple things worth noting in this definition. One is that MDM is not just a technological problem. In many cases, fundamental changes to business process will be required to maintain clean master data, and some of the most difficult MDM issues are more political than technical. The second thing to note is that MDM includes both creating and maintaining master data. Investing a lot of time, money, and effort in creating a clean, consistent set of master data is a wasted effort unless the solution includes tools and processes to keep the master data clean and consistent as it is updated and expanded.

While MDM is most effective when applied to all the master data in an organization, in many cases the risk and expense of an enterprise-wide effort are difficult to justify. It may be easier to start with a few key sources of Master Data and expand the effort, once success has been demonstrated and lessons have been learned. If you do start small, you should include an analysis of all the master data that you might eventually want to include, so you do not make design decisions or tool choices that will force you to start over when you try to incorporate a new data source. For example, if your initial Customer master implementation only includes the 10,000 customers your direct-sales force deals with, you don't want to make design decisions that will preclude adding your 10,000,000 Web customers later.

An MDM project plan will be influenced by requirements, priorities, resource availability, time frame, and the size of the problem. Most MDM projects include at least these phases:

1. Identify sources of master data. This step is usually a very revealing exercise. Some companies find they have dozens of databases containing customer data that the IT department did not know existed.

2. Identify the producers and consumers of the master data. Which applications produce the master data identified in the first step, and—generally more difficult to determine—which applications use the master data. Depending on the approach you use for maintaining the master data, this step might not be necessary. For example, if all changes are detected and handled at the database level, it probably does not matter where the changes come from.

3. Collect and analyze metadata about for your master data. For all the sources identified in step one, what are the entities and attributes of the data, and what do they mean? This should include attribute name, datatype, allowed values, constraints, default values, dependencies, and who owns the definition and maintenance of the data. The owner is the most important and often the hardest to determine. If you have a repository loaded with all your metadata, this step is an easy one. If you have to start from database tables and source code, this could be a significant effort.

4. Appoint data stewards. These should be the people with the knowledge of the current source data and the ability to determine how to transform the source into the master-data format. In general, stewards should be appointed from the owners of each master-data source, the architects responsible for the MDM systems, and representatives from the business users of the master data.

5. Implement a data-governance program and data-governance council. This group must have the knowledge and authority to make decisions on how the master data is maintained, what it contains, how long it is kept, and how changes are authorized and audited. Hundreds of decisions must be made in the course of a master-data project, and if there is not a well-defined decision-making body and process, the project can fail, because the politics prevent effective decision making.

6. Develop the master-data model. Decide what the master records look like: what attributes are included, what size and datatype they are, what values are allowed, and so forth. This step should also include the mapping between the master-data model and the current data sources. This is normally both the most important and most difficult step in the process. If you try to make everybody happy by including all the source attributes in the master entity, you often end up with master data that is too complex and cumbersome to be useful. For example, if you cannot decide whether weight should be in pounds or kilograms, one approach would be to include both (WeightLb and WeightKg). While this might make people happy, you are wasting megabytes of storage for numbers that can be calculated in microseconds, as well as running the risk of creating inconsistent data (WeightLb = 5 and WeightKg = 5). While this is a pretty trivial example, a bigger issue would be maintaining multiple part numbers for the same part. As in any committee effort, there will be fights and deals resulting in sub-optimal decisions. It's important to work out the decision process, priorities, and final decision maker in advance, to make sure things run smoothly.

7. Choose a toolset. You will need to buy or build tools to create the master lists by cleaning, transforming, and merging the source data. You will also need an infrastructure to use and maintain the master list. These functions are covered in detail later in the paper.

You can use a single toolset from a single vendor for all of these functions, or you might want to take a best-of-breed approach. In general, the techniques to clean and merge data are different for different types of data, so there are not a lot of tools that span the whole range of master data.

The two main categories of tools are Customer Data Integration (CDI) tools for creating the customer master and Product Information Management (PIM) tools for creating the product master. Some tools will do both, but generally they are better at one or the other.

The toolset should also have support for finding and fixing data-quality issues and maintaining versions and hierarchies. Versioning is a critical feature, because understanding the history of a master-data record is vital to maintaining its quality and accuracy over time. For example, if a merge tool combines two records for John Smith in Boston, and you decide there really are two different John Smiths in Boston, you need to know what the records looked like before they were merged, in order to "unmerge" them.

8. Design the infrastructure. Once you have clean, consistent master data, you will need to expose it to your applications and provide processes to manage and maintain it. This step is a big-enough issue, I devote a section to it later in the document. When this infrastructure is implemented, you will have a number of applications that will depend on it being available, so reliability and scalability are important considerations to include in your design. In most cases, you will have to implement significant parts of the infrastructure yourself, because it will be designed to fit into your current infrastructure, platforms, and applications.

9. Generate and test the master data. This step is where you use the tools you have developed or purchased to merge your source data into your master-data list. This is often an iterative process requiring tinkering with rules and settings to get the matching right. This process also requires a lot of manual inspection to ensure that the results are correct and meet the requirements established for the project. No tool will get the matching done correctly 100 percent of the time, so you will have to weigh the consequences of false matches versus missed matches to determine how to configure the matching tools. False matches can lead to customer dissatisfaction, if bills are inaccurate or the wrong person is arrested. Too many missed matches make the master data less useful, because you are not getting the benefits you invested in MDM to get.

10. Modify the producing and consuming systems. Depending on how your MDM implementation is designed, you might have to change the systems that produce, maintain, or consume master data to work with the new source of master data. If the master data is used in a system separate from the source systems—a data warehouse, for example—the source systems might not have to change. If the source systems are going to use the master data, however, there will likely be changes required. Either the source systems will have to access the new master data or the master data will have to be synchronized with the source systems, so that the source systems have a copy of the cleaned-up master data to use. If it's not possible to change one or more of the source systems, either that source system might not be able to use the master data or the master data will have to be integrated with the source system's database through external processes, such as triggers and SQL commands.

The source systems generating new records should be changed to look up existing master record sets before creating new records or updating existing master records. This ensures that the quality of data being generated upstream is good, so that the MDM can function more efficiently and the application itself manages data quality. MDM should be leveraged not only as a system of record, but also as an application that promotes cleaner and more efficient handling of data across all applications in the enterprise. As part of MDM strategy, all three pillars of data management need to be looked into: data origination, data management, and data consumption. It is not possible to have a robust enterprise-level MDM strategy if any one of these aspects is ignored.

11. Implement the maintenance processes. As we stated earlier, any MDM implementation must incorporate tools, processes, and people to maintain the quality of the data. All data must have a data steward who is responsible for ensuring the quality of the master data. The data steward is normally a business person who has knowledge of the data, can recognize incorrect data, and has the knowledge and authority to correct the issues. The MDM infrastructure should include tools that help the data steward recognize issues and simplify corrections. A good data-stewardship tool should point out questionable matches that were made—customers with different names and customer numbers that live at the same address, for example. The steward might also want to review items that were added as new, because the match criteria were close but below the threshold. It is important for the data steward to see the history of changes made to the data by the MDM systems, to isolate the source of errors and undo incorrect changes. Maintenance also includes the processes to pull changes and additions into the MDM system, and to distribute the cleansed data to the required places.

As you can see, MDM is a complex process that can go on for a long time. Like most things in software, the key to success is to implement MDM incrementally, so that the business realizes a series of short-term benefits while the complete project is a long-term process. No MDM project can be successful without the support and participation of the business users. IT professionals do not have the domain knowledge to create and maintain high-quality master data. Any MDM project that does not include changes to the processes that create, maintain, and validate master data is likely to fail. The rest of this paper will cover the details of the technology and processes for creating and maintaining master data.

How Do I Create a Master List?

Whether you buy a tool or decide to roll your own, there are two basic steps to creating master data: clean and standardize the data, and match data from all the sources to consolidate duplicates. Before you can start cleaning and normalizing your data, you must understand the data model for the master data. As part of the modeling process, the contents of each attribute were defined, and a mapping was defined from each source system to the master-data model. This information is used to define the transformations necessary to clean your source data.

Cleaning the data and transforming it into the master data model is very similar to the Extract, Transform, and Load (ETL) processes used to populate a data warehouse. If you already have ETL tools and transformation defined, it might be easier just to modify these as required for the master data, instead of learning a new tool. Here are some typical data-cleansing functions:

• Normalize data formats. Make all the phone numbers look the same, transform addresses (and so on) to a common format.

• Replace missing values. Insert defaults, look up ZIP codes from the address, look up the Dun & Bradstreet number.

• Standardize values. Convert all measurements to metric, convert prices to a common currency, change part numbers to an industry standard.

• Map attributes. Parse the first name and last name out of a contact-name field, move Part# and partno to the PartNumber field.

Most tools will cleanse the data that they can, and put the rest into an error table for hand processing. Depending on how the matching tool works, the cleansed data will be put into a master table or a series of staging tables. As each source is cleansed, the output should be examined to ensure the cleansing process is working correctly.

Matching master-data records to eliminate duplicates is both the hardest and most important step in creating master data. False matches can actually lose data (two Acme Corporations become one, for example) and missed matches reduce the value of maintaining a common list. The matching accuracy of MDM tools is one of the most important purchase criteria. Some matches are pretty trivial to do. If you have Social Security numbers for all your customers, or if all your products use a common numbering scheme, a database JOIN will find most of the matches. This hardly ever happens in the real world, however, so matching algorithms are normally very complex and sophisticated. Customers can be matched on name, maiden name, nickname, address, phone number, credit-card number, and so on, while products are matched on name, description, part number, specifications, and price. The more attribute matches and the closer the match, the higher degree of confidence the MDM system has in the match. This confidence factor is computed for each match, and if it surpasses a threshold, the records match. The threshold is normally adjusted depending on the consequences of a false match. For example, you might specify that if the confidence level is over 95 percent, the records are merged automatically, and if the confidence is between 80 percent and 95 percent, a data steward should approve the match before they are merged.

Most merge tools merge one set of input into the master list, so the best procedure is to start the list with the data in which you have the most confidence, and then merge the other sources in one at a time. If you have a lot of data and a lot of problems with it, this process can take a long time. You might want to start with the data from which you expect to get the most benefit having consolidated; run a pilot project with that data, to ensure your processes work and you are seeing the business benefits you expect; and then start adding other sources, as time and resources permit. This approach means your project will take longer and possibly cost more, but the risk is lower. This approach also lets you start with a few organizations and add more as the project demonstrates success, instead of trying to get everybody on board from the start.

Another factor to consider when merging your source data into the master list is privacy. When customers become part of the customer master, their information might be visible to any of the applications that have access to the customer master. If the customer data was obtained under a privacy policy that limited its use to a particular application, you might not be able to merge it into the customer master. You might want to add a lawyer to your MDM planning team.

At this point, if your goal was to produce a list of master data, you are done. Print it out or burn it to a CD, and move on. If you want your master data to stay current as data is added and changed, you will have to develop infrastructure and processes to manage the master data over time. The next section provides some options on how to do just that.

How Do I Maintain a Master List?

There are many different tools and techniques for managing and using master data. We will cover three of the more common scenarios here:

• Single-copy approach—In this approach, there is only one master copy of the master data. All additions and changes are made directly to the master data. All applications that use master data are rewritten to use the new data instead of their current data. This approach guarantees consistency of the master data, but in most cases it's not practical. Modifying all your applications to use a new data source with a different schema and different data is, at least, very expensive; if some of your applications are purchased, it might even be impossible.

• Multiple copies, single maintenance—In this approach, master data is added or changed in the single master copy of the data, but changes are sent out to the source systems in which copies are stored locally. Each application can update the parts of the data that are not part of the master data, but they cannot change or add master data. For example, the inventory system might be able to change quantities and locations of parts, but new parts cannot be added, and the attributes that are included in the product master cannot be changed. This reduces the number of application changes that will be required, but the applications will minimally have to disable functions that add or update master data. Users will have to learn new applications to add or modify master data, and some of the things they normally do will not work anymore.

• Continuous merge—In this approach, applications are allowed to change their copy of the master data. Changes made to the source data are sent to the master, where they are merged into the master list. The changes to the master are then sent to the source systems and applied to the local copies. This approach requires few changes to the source systems; if necessary, the change propagation can be handled in the database, so no application code is changed. On the surface, this seems like the ideal solution. Application changes are minimized, and no retraining is required. Everybody keeps doing what they are doing, but with higher-quality, more complete data. This approach does have several issues:

o Update conflicts are possible and difficult to reconcile. What happens if two of the source systems change a customer's address to different values? There's no way for the MDM system to decide which one to keep, so intervention by the data steward is required; in the meantime, the customer has two different addresses. This must be addressed by creating data-governance rules and standard operating procedures, to ensure that update conflicts are reduced or eliminated.

o Additions must be remerged. When a customer is added, there is a chance that another system has already added the customer. To deal with this situation, all data additions must go through the matching process again to prevent new duplicates in the master.

o Maintaining consistent values is more difficult. If the weight of a product is converted from pounds to kilograms and then back to pounds, rounding can change the original weight. This can be disconcerting to a user who enters a value and then sees it change a few seconds later.

In general, all these things can be planned for and dealt with, making the user's life a little easier, at the expense of a more complicated infrastructure to maintain and more work for the data stewards. This might be an acceptable trade-off, but it's one that should be made consciously.

Versioning and Auditing

No matter how you manage your master data, it's important to be able to understand how the data got to the current state. For example, if a customer record was consolidated from two different merged records, you might need to know what the original records looked like, in case a data steward determines that the records were merged by mistake and really should be two different customers. The version management should include a simple interface for displaying versions and reverting all or part of a change to a previous version. The normal branching of versions and grouping of changes that source-control systems use can also be very useful for maintaining different derivation changes and reverting groups of changes to a previous branch.

Data stewardship and compliance requirements will often include a way to determine who made each change and when it was made. To support these requirements, an MDM system should include a facility for auditing changes to the master data. In addition to keeping an audit log, the MDM system should include a simple way to find the particular change you are looking for. An MDM system can audit thousands of changes a day, so search and reporting facilities for the audit log are important.

Hierarchy Management

In addition to the master data itself, the MDM system must maintain data hierarchies—for example, bill of materials for products, sales territory structure, organization structure for customers, and so forth. It's important for the MDM system to capture these hierarchies, but it's also useful for an MDM system to be able to modify the hierarchies independently of the underlying systems. For example, when an employee moves to a different cost center, there might be impacts to the Travel and Expense system, payroll, time reporting, reporting structures, and performance management. If the MDM system manages hierarchies, a change to the hierarchy in a single place can propagate the change to all the underlying systems. There might also be reasons to maintain hierarchies in the MDM system that do not exist in the source systems. For example, revenue and expenses might need to be rolled up into territory or organizational structures that do not exist in any single source system. Planning and forecasting might also require temporary hierarchies to calculate "what if" numbers for proposed organizational changes. Historical hierarchies are also required in many cases to roll up financial information into structures that existed in the past, but not in the current structure. For these reasons, a powerful, flexible hierarchy-management feature is an important part of an MDM system.

Conclusion

The recent emphasis on regulatory compliance, SOA, and mergers and acquisitions has made the creating and maintaining of accurate and complete master data a business imperative. Both large and small businesses must develop data-maintenance and governance processes and procedures, to obtain and maintain accurate master data. While it's easy to think of master-data management as a technological issue, a purely technological solution without corresponding changes to business processes and controls will likely fail to produce satisfactory results. This paper has covered the reasons for adopting master-data management, the process of developing a solution, and several options for the technological implementation of the solution. Future papers in this series will explain the technological and procedural issues that must be resolved to implement an MDM system.

Loving P&C
DC*

Loyalty is Bilateral

Dears,

Loyalty is Bilateral. So much is written about customer loyalty that one sometimes wonders what it all means. Similarly, one wonders where loyal employees fit, if anywhere. Do our loyal employees deliver the service that ensures customer loyalty? 'Experts' say that loyal employees are critical to successful organizations and that their contribution is recognized.

Some organizations rarely or never think about their customers, some organizations would find it difficult to define who their customers are, let alone estimate their value, and some believe they do not have time to think about such things. Senior executives sometimes discuss employees as assets that can be removed quickly to protect the bottom line. What price employee loyalty in such organizations? How does such an organization present itself to its customers and how does it ensure customer loyalty?

I believe that employee morale is a very important determinant of customer satisfaction. Satisfied employees have such positive energy and willingness to give good service that customers at least perceive they are getting a better product or service, and in turn become much more satisfied and loyal to the company. 'There is considerable evidence demonstrating that customer loyalty is a leading predictor of financial results, and employee satisfaction is predictive of customer loyalty.

People are an integral part of CRM. However, unless the employee is trained and empowered to manage customers within an organizational structure that is customer focused and flexible, CRM implementation will suffer. Employees need to work at the levels of their abilities and have responsibilities commensurate with these if they are not to feel under-utilized, which can lead to dissatisfaction. 'Staff members who manage customers are usually capable of much more than they are asked to do. That is why policies that empower your staff to manage customers better work so well.'

Satisfied employees tend to stay with the company longer and so give a higher return on the investment the company makes in them (for example via training and benefits). Employees with morale problems tend to be inwardly focused and more concerned with internal company processes and procedures (and issues) than the customer. This can lead to a vicious circle of reduced customer satisfaction and profits, further reducing morale amongst employees, as this leads to increased probability of redundancy. Fear of redundancy can by itself lead to higher employee attrition. Keeping good people longer can have a substantial economic impact on the firm, and 'a layoff rarely exhilarates employees. What it does do is stifle creativity, discourage risk-taking, and destroy loyalty. The fear that goes with a layoff soaks up energy and draws people's attention to their own safety and careers, away from the success of the enterprise.

Defining business vision (what the organization should look like in three to five years' time), and creating goals and critical success factors (the things the organization must do this year) that will help achieve the vision, are fundamental to developing loyalty. Capturing the voice of the customer is also critical. Unless these actions are done and communicated to employees, the organization will have an uphill struggle to retain loyal customers and employees. Many organizations have vision statements, but employees do not have a clue what they mean. No one has taken the trouble to explain the vision statement to them.

A solid approach to managing loyalty of staff and customers requires an understanding of:

• the need for a business vision with the voice of the customer aligned;

• who customers are;

• which are high and low-value customers;

• the target markets the organization wishes to serve;

• customers' basic requirements from the organization as a supplier;

• the things customers value;

• how that value can be made a reality (ideal value) that will keep them loyal;

• the things that the organization does well and the things it could do better;

• who does it better than the organization;

• How it could attract new customers.

If an organization does not know who its customers are or has done little in the way of segmentation, then it has little chance of finding out the basic requirements of its customers. If this work is done and customers are prioritized, then the organization can create the capabilities, processes and enabling infrastructure to ensure it delivers basic requirements for customers. Why is segmentation so important? Without segmentation, differences in customer needs might never be recognized. One runs the risk of guessing and getting it wrong.

Moments of Truth

Customer loyalty often results from how the customer is treated in a given situation, that is, 'moments of truth'. A simple rule is always to treat others as you would want to be treated yourself, or 'good manners'. It is through this principle that people who are empowered to act can generate customer loyalty and reinforce their own sense of being valued, as well as reinforcing their loyalty to their own organization. Each 'moment of truth' is an opportunity for a supplier to add value to the interaction between customer and supplier or to create a 'point of pain'. If that 'point of pain' relates to a basic need of the customer, then the chances are that he or she will leave and go elsewhere, which is why it is important to understand the 'moments of truth' between customer and supplier and then test these with the target customers to understand their wants and needs at that moment.

Listening skills, telephone techniques, negotiation skills, problem solving and so on, are all important in keeping customers satisfied. Over the past decade or so, many companies have cut their workforces (using technology where they can to bridge the gaps) and have expected the remaining employees to make up the shortfall. People are working longer hours, often with little or no recompense or appreciation, motivated perhaps by fear of being a casualty of the next recession.

Many of those who work longer hours just to get through their workload are experiencing the breakdown of family life. Many of the workers are white collar/management, and also a growing percentage of women are among them. This trend is visible in many public sector organizations and call centres, which is ironic as CRM uses such call centres to get closer to the customer. According to one call centre worker, 'you take call, after call, after call for seven hours or more. You can get very tired at the end of a shift, uncomfortably tired.... It can be very stressful - dealing with customers who aren't very happy ... companies should spend as much as they can to make sure they have happy, productive call centre staff.' Problems such as these are likely to have an adverse effect on the customers the staff are dealing with.

Employees, Integral Part of Customer Satisfaction

Employees need to be shown that their organization values them and their contribution to customer loyalty. If customer loyalty is important to an organization then it must be made important for employees. Some organizations are product-driven, measuring customer satisfaction once a year, offering no specific customer training to their employees, and then telling shareholders that they are 'customer driven'! Good customer-focused organizations motivate employees to offer good service, perhaps having a reward programme to recognize good service. They ensure that customer service and satisfaction are part of their appraisal system. Complaints will be seen as an opportunity to improve customer satisfaction and add value. Customer comments will be communicated to staff regularly. There will be a process to survey customers often and also to understand the wants and needs of customers. Education and training will focus on customer service.

Many organizations today employ third parties to handle their call centres, reception and security: the three most critical areas of entry into an organization by a customer or prospective customer. How many of these people are trained by the company they are contracted to about the organization's customer service needs? A service-level agreement is simply not good enough to ensure quality. When customers call or turn up at reception looking for someone, they expect professional assistance. They do not differentiate between the company they are calling and the third-party supplier of the telephonist or receptionist. As far as customers are concerned, they have basic needs. If these are not fulfilled, they will go elsewhere.

Who Determines ?

Once the organization understands its customers' wants and needs, it can decide whether or not the vision needs to be realigned. Having understood the 'ideal value' customers require, the organization can then develop a set of capabilities: the things it must do to achieve the ideal state. Then it must determine the enabling infrastructure that will achieve the capabilities. This is where employees come into their own. The customers will determine the ideal state, but employees determine the capabilities and enablers. Projects in areas such as process, organization, technology and communication are likely to feature highly. These enablers will address the basic requirements and the ideal-value requirements. Having completed this, the organization can then complete a gap analysis to determine which areas most urgently need change.

Organizations that take no account of their customers' needs and wants and that think they know best, will fail. The organization that takes the 'outside-in view' - the customer view - and bases its business decisions on it, will succeed, if it harnesses the collective energies of its employees. Organizational change and cultural change take time, and employee buy-in is critical.

Here are some examples of success.

• Retail major in US implemented a set of total performance indicators using the 'soft' measures of employee satisfaction and customer loyalty to create a linkage that makes it possible to estimate their impact on the company's financial performance and set targets for employee and customer satisfaction. 'Every five point increase in [employee] satisfaction is related to a 1.7 per cent increase in customer loyalty which in turn is associated with a 3.4 per cent increase in earnings.

• Airlines in the United States has carved a successful niche as a low-cost, no-frills airline, taking pride in giving customers what they want. Similarly it has a commitment to its employees as it 'believe[s] that relaxed and secure employees will act on their own to take good care of customers'. This resulted in the lowest employee turnover in the industry and a consistent return on investment of 15 per cent over 27 years.



Loving P&C

DC*

CRM Custodianship

Dears,

What is this CRM Custodianship? What does it mean to Companies of different sizes to have the CRM or Customer Data Custodian? Let’s see -Take a data warehouse, add smart analysis tools, a structured approach to managing inbound and outbound customer contacts, including self-managed Web contacts, and give the golden data an almighty stir - we develop magical insights into customer characteristics and behavior which give us a strong advantage over our competitors. While increasing numbers of large companies claim to have reached magical levels of insights, we must never forget that when we say 'a company knows', we may be committing the ultimate sin of 'personification' - treating a 'thing' (the company) as an individual.

In fact, when we say 'a company understands or knows its customers', what we mean is that this knowledge of customers resides in a combination of databases (often several), analyses, reports documenting the analyses, and even the minds of certain staff. As customers themselves are constantly changing (the individuals may be different, the behavior of given individuals changing), this knowledge needs to be refreshed, and whether this happens depends upon the frequency and accuracy of update of the information sources, the re-application of whatever techniques were used to distil knowledge from the information, and the re-communication of results to whoever is deemed to hold the knowledge. This applies whether the source is at the batch end (eg who responds to a direct mail campaign, nature of response) or online (eg site exploration behaviour of particular types of customer).

So, the ingredients of the golden data are ever changing. What we put in, how we stir it, and how long we let it cook all influence the quality of what we take out. Who determines these? The answer - the custodian of the golden data. Who is the custodian? Is it the company itself, the data exploitation agency, the direct marketing agency, or the outsourced database bureau? In practice, the answer is usually some combination of these. In very few cases do larger companies do everything themselves. Interestingly, when they do, the result seems to be that customer knowledge is less sophisticated (fewer segments defined, data perhaps less up to date, less accurate), but the knowledge is better used (more consistently, across different channels, as part of well-defined general marketing processes rather than tactically). This is usually for one of two very different reasons. Either the marketing users are themselves more closely involved in the process of specifying and then interpreting analyses, or the internal department charged with developing a customer view becomes an advocate for its good use, and works very closely with marketing users to make sure it is used. In the more advanced examples, they will also provide metrics to show when it is used and what the results have been, to encourage use and to expose misuse.

However, there are also some examples of excellent practice in outsourcing to analysis or database hosting agencies. This works really well when there is a long-term strategic agreement between supplier and client and when the focus of the agreement is not solely or primarily on the input (who holds and analyses the data, or communicates the findings) but on the outputs, ie what business results are expected from the gathering and holding of data, analysis to obtain knowledge, and exploitation of the resulting knowledge. These required outputs may be expressed in tactical terms, eg uplifts to campaign response or conversion rates, or strategic terms, eg increased value of the customer base. Increasingly e-sourcing, e-business on demand (EBOD) and other modern variants of outsourcing are reflecting and including these requirements.

Unfortunately, in most cases, whether customer understanding is in-sourced or outsourced, the custodianship is poorly allocated - sometimes dropping between the planks, sometimes simply non-existent. This failure is evidenced in many ways. There may be many overlapping segmentation projects with no interface with each other. Segmentation and analysis may be conducted using variables that are not available on the database, so analysis can rarely be acted upon. There may be great lack of awareness amongst users about what is available, what the results of data use have been, or even how to use the knowledge practically. Where these basic problems do not exist, there may be more advanced problems, eg the customer understanding only being used in one channel (perhaps the channel in which the understanding was generated) and not in others. In many cases, failures are due to not understanding that managing customer knowledge is a skilled operation, and whether the skills are in-house or out-house, they must be maintained and improved - to keep up to date with what it is possible to do, and also with the customer knowledge itself.

In most cases, these failures can be traced to a single cause - that no one has asked (let alone answered) the question: 'Who is fully accountable for managing customer knowledge?' In cases where it is badly in-sourced, marketing managers have often taken the view that 'customer knowledge is a strategic asset, and therefore our company will not out-source its management!' Every time I hear such a brave phrase, I know I'm likely to find that the company manages it very badly, because it has not asked the accountability question.

Today Companies go after MDM solutions to get their Golden Record which is a progressive step but not A matured step without taking effective steps towards Customer Data Custodianship. The fragmented customer data is a very risky proposition to grow in this competitive economy. Enterprises should focus on improving the customer data quality and enrichment. This is the first step toward customer experience optimization as well as setting a stage for some competitive intelligence project. The custodian should be empowered to make all that is necessary to enrich the customer data and fully autonomy to be given in directing the Sales and Marketing department to effectively maintain and update the customer data.


Loving P&C


DC*

KYBC – Know your Bad Customers

Dears,

Today, many companies are prone to serious forms of attack from customers, not just hacking, though there is a relationship between this and the move to more remote forms of doing business, whether Internet or call centre. These attacks are attempts to commit fraud - money laundering, illegal trading - or to exploit loopholes in credit or insurance products. These attempts are helped by technological advances because companies have fewer face-to-face opportunities of validating identities, credit-worthiness and the like, and also because the perpetrators often work in teams, using Internet and mobile telephony to communicate quickly with each other in ways authorities find hard to track.

Need for Protection

The response of government authorities has been to impose upon companies - particularly those in the financial services sector - a series of requirements in terms of 'know your customers' and 'track and if necessary unwind your transactions'. These requirements incidentally sometimes conflict with data protection and industry-specific requirements designed to protect honest customers. For example, money-laundering monitoring requirements include the need to retain and be able to retrieve information, track and report to the national authorities. For this, record keeping and reporting products are designed to track and report information to regulators or other national authorities, where the detailed requirement, such as a threshold value, is specified. So, financial services companies are now investing in a number of areas designed to support their war against the bad customer. These include very advanced software, designed to pick up new patterns of bad behavior, the data storage required to ensure that everything can be tracked and where necessary is reversible, and the systems integration work (often including specialist middleware) to ensure that data from various sources can be brought together for 'detection' work.

What is interesting about these developments is that they are some way in advance of recent developments in database marketing in companies with very large customer bases and/or very high volumes of transactions. Rules-based products are used to monitor transactions to identify and filter out potentially suspicious transactions that are outside the norms for an account and customer (or other group). These 'outside limit' or 'out-of-character' transactions are flagged and routed for manual review by bank compliance, audit, or risk management staff. Transactions that appear, after review, to be inconsistent with a customer's business are reported to the appropriate government entity. To achieve this, expert and/or intelligent systems identify non-linear trends and relationships within transaction activity, including associative patterns among accounts, customers, relative to peer or other groupings. These systems examine all possible combinations among transactions, rather than looking at the individual transaction record itself, and apply risk scorings to suspect transactions. There can be significant differences between systems and results depending on the architectural approach and the intelligence technologies used. The most advanced types of software can be programmed to warn about virtually any kind of risk - including imminent system failure due to lack of capacity.

Value Vs Risk

In the financial services industry, value and risk are not far apart. In call centres and Web sites, where the customer is invisible to the supplier, systems have assumed the role of detecting bad customers. The pay-off to good risk management has always been much larger than that to value management, at least in the short run, simply because the costs of failure are so large. However, with increasing volumes of business being done remotely, the need for smarter systems to help companies extract much higher value from customers is increasing. For this reason, banks are starting to investigate how the software and processes they use for detecting bad customers more quickly and accurately can be used for detecting value more quickly. One reason for this is that these products are not cheap, so banks want to extend their use. The products are very advanced, and the very latest products have shown dramatic levels of success, in terms of reducing the incidence of false positives and successful detection of negatives. They do this by creating 'sentinels' which take on much of the role of the data analyst, freeing analysts to work on strategies. For the data analysis industry, these products represent both a threat and an opportunity - an opportunity if used to liberate analysts to focus not on implementing models but on understanding why they work, but a threat if analysts try to compete with them.

Building a Fraud Intelligence in CRM Apps


One of the definite value add beyond having Financial CRM Vertical application is to have Behavioral & Transaction Detection Intelligence which eventually would lead to detect Fraud and ability to differentiate a good customer from Bad Ones. The CRM industry is up for a revolution and customer prefer more of Virtual Services than to be served in person in lieu of enablement of Web2.0 Self Services, Mobile Computing and Kiosk terminals etc. Real Time Decisioning and Intelligence is of great value to render fraud free services to customers ranging from High Net worth to Moderate Value customer.


Loving P&C

DC*

Deception Point @ CRM

Dears,


This article is more of an introspection of the CRM program execution that prevails over a decade and an attempt to identify some vital deception points in CRM initiatives.
When companies started to realize that they might have been just a little misled about the costs and benefits of CRM, one of the witty professional renamed it as 'Clever Repackaging Mechanism - CRM'. This was because he believed that CRM was just a combination of some very simple classic business disciplines, such as customer database marketing, key account management, people management, quality, supply chain management, change management, risk management, customer service and latterly e-business, combined to create a rather complex but often not very well articulated, planned or managed business change programme.

When the first CRM disasters began to occur, the same witty professional referred to 'Client Rip-off Menu' – CRM, because in retrospect many more System Integrators and Product Vendors than clients seemed to have made money out of CRM! One way System Integrators and Product Vendors achieved this was through a sustained campaign of hype, consisting of a combination of almost 'self-evident' requirements, such as 'a single customer view', justified by different 'burning platforms' such as, for example, severe customer attrition, escalating costs of customer recruitment, the need to reduce the costs of customer management radically and quickly, and of course that all-purpose justifier, competitive advantage and so forth.

Over a decade, most CRM programmes are barely worth the name, particularly when a vision of CRM has been foisted on the client by a high-powered consultancy or firm of analysts. Before we explore the perniciousness of this, let us explain why so many companies were (and still are) vulnerable. It is because the quality of what we call 'business discourse' has plumbed depths usually only plumbed by poor CRM evangelist and Business Consultants. One reason for this is PowerPoint culture, which makes managers decreasingly able to produce connected arguments.

This low quality discourse occurs in a less detectable and possibly more pernicious form within CRM. This version of the disease is called 'personification'. For grammarians, personification means treating something (anything from a car or a company to a country) as if it were a single person. This is harmless in daily life, but potentially catastrophic in management. Why? Well, consider the phrase, 'Company X does Y, or believes Y'. While a small company might be so in control of its actions or thoughts to achieve this degree of consistency, the large companies who constitute the suppliers and clients in the world of CRM are rarely in this situation. Take the suppliers of CRM systems. They can be divided into suppliers of CRM software and services (including implementation and outsourcing), with many companies straddling the two.

While suppliers of single software packages might be capable of maintaining a relatively simple vision of what CRM is and how information technology supports it (indeed, this vision may be their prime differentiator), the implementers - particularly those who serve very large clients - are in a very different situation. The largest implementers are giant companies, usually global in scale. They are typically involved in helping giant clients, themselves often global in scale, change the way they manage their customers. Neither supplier nor client can in these situations ever be personified as described above. Our experience is that successful suppliers succeed because they work closely with their clients, whose view of where they want to go in CRM is often fragmented. For example, a big insurance company may in each country in which it operates have different visions of where it wants to go in CRM in its direct division, its life and pensions division, its broker division, and so on. Many such companies have tried to bring their different visions together, and failed. Some have turned to consultancies that have produced simple templates representing visions and implementation plans, and tried to use these templates to impose change upon the organization - and failed. This is because of big differences in the skills and capabilities possessed by the different divisions, and of course differences on the buy side - different competitive pressures, channels of distribution, and of course customer needs.

The lesson - the bigger the company, the less relevant and the more foolish the idea that a single vision is needed. In many cases a portfolio approach could be more relevant. The idea that a very large supplier should or even could have a single vision is similarly stupid - many large suppliers succeed by having the skills and flexibility to work with different business partners (eg software suppliers) to develop and deliver very different visions of CRM to their clients. This is, by the way, true in nearly all areas of systems. Of course, there are massive economies of scale to be gained by standardizing on systems, but as our research has shown again and again, brilliant systems are neither a necessary nor a sufficient condition for success in CRM. That is why the more discerning clients do not want a vision, but pragmatic advice and results, taking into account the variety and possible inconsistency that exists in their own situation

The moral of the story is simple every organization has its own vision formulated and diversified in terms of what they want to achieve in a different portfolio of their business , CRM should become the enabler of this vision accommodating the diversified needs of business group rather than to superimpose the CRM Product vision on the Client ‘s Vision. This exercise of resisting to CRM deception points is not simple as it may sound and requires intelligent introspection from top executives of the company to lay down their CRM plan before it gets baptized by third party arguments and still hold on to the true CRM vision of the company.



Loving P&C


DC*

CRM Signs of Trouble: Act or Be Acted Upon

CRM Signs of Trouble: Act or Be Acted Upon

Dears,
The Life has its own signs to show you well in advance what you will be going through in near future, some pick these instincts..Act Fast and rest fall prey to be acted upon. The CRM world is not to different and fix it small before becoming a bigger problem.

Some IT systems are designed and built without a lot of regard for the organizational structure of users. Of course you pay attention to users’ needs and preferences, but an accounting system is deployed pretty much the same no matter who's in charge of the accounting department. But CRM systems present a unique challenge because they need to be very tightly aligned with the user organizations. If you have a big reorg or bring on a whole bunch of new channel partners, you're likely going to go through major changes in the CRM system.

Problems come in 3

This is what makes CRM systems so much harder to get right, but also effective when they are done right. The CRM system is tightly bound to the way the organization works, and the twin goals of the system are to (1) improve leverage and collaboration, and (2) more closely understand and influence the customers' buying patterns.So when you've discovered a problem with the way your CRM system is working, you need to look for corresponding (or compensating) problems in the organization that's using it. The problem symptoms to look for in CRM systems is:

• A technical issue, such as data quality or fragile integration.


• A business process issue, such as pipeline formation and nurturing.


• A policy issue, such as "we ignore disqualified leads."

As an IT leader, you'll probably notice the technical problem first. But users won't see that one: they'll be paying attention to the measurable business issue in the second category. Unfortunately, they'll likely be blind to the third problem, which was probably somebody's brilliant idea from a couple of reorg ago.

Why do I bring this up? Because solving only one of the issues won't make the problem and its symptoms go away. You have to troubleshoot and resolve them as a set. If you don't, the system imbalance will continue. New variants of the original problems will soon grow to replace the "solved ones." Even if you think there's a pure IT problem, in the CRM world there will be corresponding elements outside your domain. Count on it.

These intertwined problems tend to cluster in the heart of the following business processes:

• Lead generation, processing, and nurturing

• Lead conversion and opportunity creation

• Trials and demos

• Pipeline development and forecasting

• Deal closing and order entry

• Order management and expediting

• Commissions and referral fees

• Fulfillment, distribution, and shipping

• Support entitlement and case creation

• RMA and reverse logistics

In some cases, the problem trio is almost entirely within the span of a single organization. These lucky situations don't involve a ton of politics. In contrast, the juiciest situations are those that span organizations. As these problems can be the embodiment of long-standing political feuds, unraveling them may involve more time in meetings than anything else

Where to start when trying to resolve these issues? There's nothing wrong starting out by doing the spade-work that is internal to IT. Your team can be productive for a while without involvement of the user organizations. However, it's not uncommon to find lots of IT cruft — software and database tables and integrations surrounding the CRM system — that really aren't necessary any more. These elements were often constructed to compensate for an ill-conceived policy or a misaligned business process. So leaving these extra system elements in place — or worse, "repairing" them, will only reinforce the other two parts of the problem triad.
Consequently, the real work won't begin until you have a closed-door conversation with the VPs of the organizations involved, helping them realize that the only path to the solution will mean changes to things they measure and policies that they may have championed. The VPs themselves won't be the solution, but they can certainly stand in the way of one.

If the VPs are digging in their heels, ask them questions like:

• Does this policy or business process actually help you reach your goals faster and more predictably? Or was this just a "quick fix?"


• Do your team members genuinely prefer it this way, or is it causing them pain?


• Do our competitors do it this way?

• Is it creating an advantage for our company?


• Do our customers prefer it this way? Is this making us easier to do business with?

Once the VPs have given their blessing to solving all parts of the problem, make sure they've assigned a knowledgeable underling to help redesign the business process and refine the policies that need to be changed. With the right will and direction, troubleshooting and resolving the non-IT parts of the CRM problem can be resolved in just a few meetings.

Loving P&C

DC*

Everyday Customer Champions

Dears,


“Service to Humanity is Service to God “, you may feel that I sound too philosophical today. The truth is different; the Soul of our service is very deep roots to this saying. Everyday Customer Champions are the people who inspire you to go back to an establishment again and again—whether B2B or B2C. Often they are the unsung customer heroes at the front lines or big renowned corporate houses who ensure that provides a great experience or that your problem is solved—even if it means going out of their way.

Providing customers with a flawless and memorable experience that gives them what they want – and brings them back – is the goal of any company. Those that get “customer experience” right say that the key is to focus on relationships with buyers at so-called “touch points” along the way, from long before until long after a sale takes place. At the end of the day customer want relationship more than anything else.

Wal-Mart Makes a Difference

Wal-Mart made a major shift in its marketing focus in 2009/10 — and the buzzword became "value." Television ads touted the company's Great Value line of foods, telling the story of how parents could feed their families for $2 per meal. Part of the "Save Money, Live Better" campaign also included a branded web site with videos, free classified ads and a message board where shoppers swap tips on stretching paychecks. In the bottom-left corner of that site is a constantly updated ticker — currently just over a quarter of a trillion dollars — that shows "the amount of money Wal-Mart has saved American families since January 1, 2009."

CRM Professionals Commitment
CRM is such a powerful thought that makes a great difference to everyone’s life. Take an extreme example of helping the citizen of War Torn country like Iraq helping the citizens to share their thoughts about the rebuilding their country and work in cognizant with US forces to make them help better. The entire CRM concept could be deployed in such scenario and what is required is some humane effort to take such step. We the IT Professionals see our job more as a way to exhibit our talent and intelligence beyond this there is great value add by making someone’s life better be it a employee of your customer or customer of your customer. The great organization are great for a reason that they have the everyday customer champions who knowingly or unknowingly putting a great effort in building great relationship with customer.

So, who is your Everyday Customer Champion? Is it a barista at Coffee Shop’s or a salesperson at your Super Market or perhaps your local dry cleaner or gas station attendant, or maybe it’s a B2B sales or service rep at a supplier’s firm? Take a moment to recognize him or her below. You’ll be glad you did.

Loving P&C


DC*

Open Source CRM

Dears,

Though I am an evangelist of popular CRM packages, I want to explore the options of Open Source CRM. Before we get into what open source CRM is, the only reason that CRM is interesting to me is that it’s the only science of business that attempts to reproduce an art of life. That would be the art that's involved in crafting good human relationships. CRM itself attempts to figure out an approach, a methodology and a program that will recreate how humans interact in good ways - but in what is a constrained business environment... It could be about whatever it is feeling like talking about - as long as the human psyche, human emotions, personal interactions and business consequences are somewhat involved. That gives me something of a wide range of imagination about CRM as Art and Science.

I have to remind you of one thing. It's CRM -- regardless of how it's constructed. The applications are classically CRM, with sales, customer service and sometimes marketing -- the so-called "customer-facing" applications. Open source CRM can be delivered exactly the same way any other CRM is delivered -- as on-premise or on-demand, or even as a hybrid. It takes developers to develop it and implementation teams to install, configure and customize it. It takes skilled professionals to administer it, and it is used the same way that any CRM application or service is used -- by users. When doing a deep technical dive, it has a similar architecture and needs source code to develop the applications related to it. And, to bust a recurring myth, the open source model doesn't guarantee free software.

But where it differs is in the way the source code is distributed and in the culture that surrounds it. Those differences affect how it's priced and how it's used -- but not always. This is by no means a blanket condition. @REG

What is the open source model?

When you hear that something is "open source," you are actually hearing about a culture and a license. The source code for an open source application is freely provided under any one of a number of licenses approved by the Open Source Initiative (OSI). For example, the license that SugarCRM uses is an unmodified version of the GPL version license, but it is just one of 70 possible licenses. What these licenses provide is a somewhat constrained allowance for use of the software code under certain conditions. The conditions vary from license to license.

As much as open source represents a license, it is also the manifestation of a culture. It stands for "openness," meaning that proprietary, non-standards-based source code is not aimed for. It represents a culture that doesn't treat source as a trade secret but often retains it as owned intellectual property. It means that others are permitted to alter the code for their own purposes, though, again, within reason. The culture is also collaborative. Many of the open source vendors in any area have dedicated individual developers who spend time developing applications and add-ins, improving load times and making myriad other changes or additions to the source code. These developers do not work for the software companies. All of this is done with encouragement from the vendor providing the code. Often, vendors throw in other resources such as software tools or marketplaces to make the developers' lives easier or to enable those developers to sell the fruits of their labor.

Why choose an open source CRM application?

When it comes to evaluating open source CRM, it should be considered for the same reasons you'd consider any CRM software. Open source CRM doesn't provide more or fewer features or functions than any other CRM application. It doesn't have a different delivery mechanism. It can be implemented on-premise or on-demand. The one area where you might find a bit of an advantage is in the pricing of open source CRM. It is slightly less expensive than other CRM packages, often because the developer community working on it is working pro bono, for the love of developing that particular source code. If the open source CRM Company is smart, it will pass on some of the cost savings to its customers.

What are the benefits and risks associated with the open source model?

The benefits of a good open source CRM application are the ones mentioned above -- pricing can be favorable for the customer, and there can be a wide array of applications, add-ins, or even fully customized versions of the open source provider's applications. This may not be available in more standard forms of CRM because the developer community is not as large or as open. Instead, many of the more traditional CRM companies have their own developers working on their tightly held proprietary source code. Innovation and creativity are stifled by this type of approach, so instead of a wide variety of additional capabilities or specific versions, they give you -- to their credit -- an improved version from a tightly controlled roadmap with specific features being developed.

There are risks, however -- the biggest being quality control over a community of unpaid developers, and the second being uncertain feature release dates and availability because the developers control their own destiny and are on their own time. The developers can't be held to any standard if they are involved in the core feature release. Some open source CRM companies have employed developers or paid contractors to work on features for core releases and have then had the developer community work on the ancillary capabilities. That's one way of avoiding the release date problems.

The other risk is that open source CRM is often built on open source platforms with open source tools. Typically, you'll need the right infrastructure (e.g., MySQL databases and Linux operating systems). If you are to use an open source CRM application, you can't ignore this. At a minimum, you'll need Linux to run the applications. This problem is, of course, mitigated by a hosted solution.

Also, because there are such robust external developer communities, there are always some concerns about the security of open source CRM. Because of the easy availability of the source code, writing malware to breach security is a bit easier to do, and there is no way to monitor the quality and/or qualifications of the individual developer without a strong quality-assurance program in place.

How much has the open source market grown in recent years?

There has been modest growth in open source CRM licenses over the past year, but nothing explosive. The open source market isn't really a market per se. It is part of the broader CRM market, and if you had to distinguish it in any way, you'd simply include it with the same distinctions raised between the on-demand market and the on-premise/traditional license market. There is no real reason to separate it out. Again, we're looking at a culture and a license, not a fundamentally new way of delivering or architecting CRM.

What is the up-front investment in open source CRM?

The classic consultant answer is: "It depends." For example, if you have a strong need for customization -- if you choose an open source CRM application with a robust developer community -- there is a chance that either what you need has already been developed or you can find a developer through the community to help you at less expense than through traditional means. Implementation costs are dependent on whether or not you're using a hosted or an on-premise version -- not unlike their proprietary cousins. It will always depend on what you need.

Open source CRM means that the code is licensed in a way that makes it more freely available, and the culture of the companies involved is more open. There are free versions, but even they will cost something to maintain and install. Providing support for those free versions is often how the companies that produce them make their money.

In conclusion, open source CRM is certainly a small but stand-out niche in the world of CRM, but it shouldn't be treated differently from a proprietary CRM package. Check out the features, functions, code, pricing, corollary applications, total cost of ownership and the professional services offered when you are making your decision. If open source CRM meets your requirements, Check it..

Loving P&C
DC*