Challenge: Your CRM platform and business processes are flat, failing, dysfunctional, erratic, scattered, and lack adoption and utilization. The user community abandons the tool because the data is not useful. But the data is not useful because the users have abandoned the application. Sound familiar?
Cost of Poor a CRM Implementation: As a CIO, your first job is to decide how bad this problem really is. What business costs are incurred from a failed demand-side enterprise solution. For most organizations, there are wasted software and support costs, as well as the inability to use the data that is intended to be accumulated from natural use of a CRM, and the lack of coordination caused by a system that is not used. For most businesses, they still do what a CRM would enable, but they use a bunch of other unsophisticated and disconnected tools to do the same thing. They create data and process silos. This causes errors, lost visibility, lost control and inefficiencies to the intended user community.
The Data Focused Solution: Examine your CRM’s database design and the data. Then invite the sales, marketing and customer service teams to a summit to obtain their opinions and advice. Offer no alternative except a successful deployment (even if this is 2.0). Evangelize the benefits of good data. Create a plan that includes repairing data, remodeling the database, improving UX, and making the solution useful by achieving on their priorities and delivering good data to the users as individuals and as a team. You can help these communities help each other by asking what if’s that entertain better integration, data availability, data quality, and BI.
The Wrong Data Solution: Hire a bunch of expensive IT resources to build a data warehouse and make that system a “crutch” by repairing the bad data in the data warehouse and making DW the “system of record” for good data and integration hub, thereby enabling the contributing systems to continue to languish. Worse, plumbing the DW back to the line of business applications like CRM. This approach gives the appearance of heroics, where magicians “fix” a problem that should be avoided. An ounce of prevention is worth a pound of cure. DW as data integrity management is a road to perdition, yet it is the choice many IT organizations took over the last 20 years.
Step 1, Data Forensic Analysis: Hire a specialist to conduct data diagnostics, looking for data quality defects and determining the extent of the problem. This analysis will include database design/integrity analysis, since CRM systems are notorious for being surgically botched, and the resulting database improperly normalized. Let the data tell you what changes need to occur in the applications landscape.
Step 2, Integration Analysis: Where is similar data replicated or shared between systems. What are the integration points or overlaps? What data wrangling occurs to get good reports and data flow?
Step 3, SOR/MDM Analysis: Review all key applications that replicate or share data. Ask why any given application cannot be trusted or efficiently used to contain certain kinds of data? Create a way for data to be owned by one system or another. Create a MDM/integration plan to give rights to specific systems to “own” certain data at certain points in a business process, and share that data across the borders. Create a blueprint for proper integration between systems.
Step 4, Continuous Data Quality & Enrichment: CDP or not, you need to have data cleansing and enrichment processes that perpetually maintain data reliability, accuracy and trust. This is the most important aspect of data “governance”. It is really data maintenance.
Step 5, Combine BI and CRM: Build profiles and deliver these rich data sets to the individuals and work teams that need them. Find a CDP platform that meets your needs.
Ascendant Group’s CRM Data Assessment Dimensions
I. Identify the data objects needing forensic analysis. Common entities are:
Campaign = marketing project:
Offer = a benefit offered in exchange for trade or commitment with pre-negotiated terms and conditions
Lead = initial conversion to an inquiry, referral or response process for a prospect or customer
Opportunity = sales project for qualified leads
Interaction = activities, communications, correspondence, sessions
Product = value prop item or service
Quote = offer to sell for qualified prospects or customers; subject to versioning from negotiation; may stipulate a deposit or prepayment
Sales Order = accepted offer to trade with terms and conditions; may stipulate a deposit or prepayment
Fulfillment Order = any supply chain order to deliver value to a customer
Invoice = request for payment before or after fulfillment (prepayment vs. post-payment). Often structured record is accompanied by a PDF
Installed Base = purchased assets in place
Workplace/Facility/Location: a building/structure with an environment in which assets are placed
Contract = subscribed agreement for repeat trade; has terms and conditions, in particular - price. Includes support and warranty agreements. Often a structured record is accompanied by a PDF
Case = small project to rehabilitate a relationship
Work Order = task to fulfill on a case or contract
Territory = geolocation exclusive to an authority for a business purpose
Human Resource = employee or contractor selling or supporting a customer, including executing on work billed to a customer or charged to a contract
Business Role = level of authority and responsibility with relationship to an entity or process
User = record of business resources who use the application or are assigned to business roles
II. Apply Analysis Dimensions to the Data Objects
Missing records: Are you missing records that should be represented? What belongs in the DB but is not there?
Duplicates: Does the DB contain more than one record to represent that same real-world object or process instance?
UI Validation Enforcement Deficiencies: What data elements are not required that should be, and what elements are required in a burdensome or inelegant manner?
Parameterization Flaws: Are List-of-Value (LOV) fields (drop-downs, pick-lists and database relationship lookups) mutually exclusive and collectively exhaustive? No overlaps and nothing missing from being represented? Sometimes these fields are better represented by two or more dependent LOV’s
Missing Key Data: are some records missing important data, either fields or parent or child record relationships?
Invalid Values: Do parameterized fields contain the values that are represented in the LOV’s? Do lookups reference active records?
Overlapping Field Values within record: often flawed systems will scatter data in fields that contain similar data or conflicting data.
Overlapping Values Across Tables: is the same kind of data managed in similar fields in different tables?
Obsolete Data: is data old and likely to be inaccurate or proven to be no longer representative of real-world conditions?
Non-Normalized Data: is the same data type replicated in companion fields on the same record in ways that restrict the number of records that can be tracked (missing child entity)? Also, are data relationships missing that cause real world data to be replicated (missing many to many table)? Or is the same data applied to more than one record (missing parent record).
Unclosed Records for Completed Processes: process records should be closed with the process instance is complete. Often they are left open. Likewise end-of-life entity records may need to be archived as "inactive" or in some cases removed.
Non-standardized Data: data in non-parameterized fields contain values that are not consistent and optimal.
Master Data Conflicts: data that should be managed in one application is managed in another application or both, which causes conflict and inefficiencies.
Subjective Scoring: rating type data is not dynamic or objective, derived from scoring parameters that can be calculated periodically or on demand.
Do You Need Advice? Contact us for a discounted assessment, at 920-428-5669; info@ascendant-group.com.
Comments