This is the 4th in a series of 6 articles looking at how to successfully deliver your CRM project. The full series contains:

The development of Business Requirements will, if done right, clearly dictate the functional definition of the solution. This however must be accompanied by an equally clear and complementary data definition. Separate teams should be created for Customer data and Product data as well as Functionally aligned User Teams.

The Product data, to be designed/developed for import, will need to reflect current definitions, additional fields for enhanced usage and the structures and capability of the CRM or operational systems being deployed.

The Customer data will reflect the core business processes of Sales and Transaction processing and the necessary requirements for Marketing to understand the customer sufficiently to generate lead campaigns based on current and potential value as well as fields that reflect the nuances of the customer.

Importantly the Data Dictionary will also include, and match the Business Requirements, the rules pertaining to when and by whom fields will be updated and the mandatory requirements. This is where the devil in the data can be exposed or tamed.

All this happens, and is signed off by all parties, in design prior to work being started or at least completed in the new platform

The model below is the Solution Architecture. Each system will receive, hold and generate data. It is important to define:

• Data will be held within each system. Duplication of data is not optimum but is acceptable as long as data maintenance is automated
• Data will be transferred. Data should be transferred, or better still presented, on an “As Required’ basis. Ie Customer data will be delivered to the Marketing Automation system for activities. The CRM will be the master for all Customer data; Product data will be represented in the Ecommerce solution, The PIM will be the master for all Product data
• Data will be generated. Data will be created as each Customer engagement occurs. Ie A customer will be included in a Marketing Segment for either analysis or activity. That the customer is part of that segment will be flagged and that they were contacted as part of a campaign will also be flagged against the record

The rules to manage this data proliferation are what will allow the complexity to provide the business value while supporting each process and team.

3 x Critical Success Factors

These are CSFs for the Selection Process, not the Project:

1. Data design supports all Business Processes

A CRM solution will support multiple Business Units who will have diverse and potentially conflicting needs. Simple field structure like location may be different for Sales Territory Management and Marketing Segmentation. It is better to have a single view of customer, but not compromised, than multiple fields for the same purpose.

2. Import Clean Data – Time consuming but essential process
   1. If importing from multiple sources, consolidate externally adding a source code to each file. Select a master file and build rules for when data conflicts
   2. Identify breadth and depth of data to import.
      1. Many fields, included when source systems were deployed, will no longer be relevant and/or data has not been maintained so as to not have any value
      2. Historical data will be more valuable for analytics than operational/sales staff, the value therefore needs to be assessed especially if the system has a contact record fee structure
   3. Clean duplicates. Be certain on tight vs loose matching criteria. It is better to use loose criteria and run a report for records that would have been picked up in a tight match and have sales staff manually clean
   4. Import Unsubscribe flags
   5. Assign / reassign appropriate Sales Team members
3. Maintenance

The day the data is loaded it will start to be out of date. There will be fields that need no maintenance (Date of Birth) Fields that are automatically maintained via business processes (Transaction Data; Marketing Activity) and fields that require additional processes to maintain (Customer Contacts; Opt Outs). Automation of data maintenance creates major efficiencies.

2 x Reasons how this is Unique to Manufacturing

Sometimes it is subtle variances that make the difference in approach and each industry has its own idiosyncrasies:

1. Complexity of SKUs

The complexity of product options driving the proliferation of SKU’s needs to be allowed for in the selection of Products for customers and then the analysis of Sales compared to Market Segments and Sales Channels. The SKU needs to be to built up and then broken down again.

2. Data Transfers, Including ERP

The interface to the ERP, as well as potentially a PIM and CPQ, requires the data to be transferred and stored for multiple purposes. All data must be clearly identified as to its Master and transfer protocols, unless contained a single system.

In Summary

Clarity – The Clarity comes from Design. There are so many potential pitfalls in manipulating and structuring the data that a precise, agreed design is absolutely imperative. It is easier to amend functions than it is to change the data model post go live.

Simplicity – Simplicity again comes from design but slightly different in that working through all the pitfalls can produce a simpler data model, with less fields, less rules but still supporting the business requirements.

Certainty – Deploying the data to enable each team the flexibility to deliver on their accountabilities, after rigorous design, will give the solution and business benefits Certainty of being achieved. Flexibility can also require complexity, but by this stage the design will have tamed the Devil exposed by the Detail.