Case Study: How Data Migration Can Support or Undermine Strategic Outcomes

In this case study, a counter-intuitive approach to data migration was used to avoid a fatal strategic error.

When implementing a CRM system, or any system for that matter, the quality of the data is a key factor in whether the strategic outcomes are achieved or not. Data is the life-blood of the system, especially when we want to accelerate with automation and AI.

When we get to the stage in a program of defining the underlying projects, each of the information system projects needs to have a data conversion plan.

Many people will assume an automated data transfer approach is the way to go. After all, we are looking to improve efficiency and effectiveness. But it is important to assess whether the quality of the source data supports the program goals before automating a transfer. For lift-and-shift projects there is more chance that automated transfer will be useful, but that is not always the case when thinking about transformation programs.

If you would like a refresher on the differences between lift-and-shift, evolutionary and transformative programs then From Tweak to Transformation: Sizing Up Business Change will give a grounding on the terminology and differences.

In this article I will talk about a case when I used the counterintuitive approach of manual data recreation to support and enable the strategic goals of the client and how an automated approach would have undermined the very purpose of the endeavour.

Client Goals

The client was a global, digital enterprise in a market that was becoming more commoditized and competitive. Through legacy acquisitions and internal start-up business units the client had multiple teams and partners working with customers without an integrated Account Management approach. The major teams had siloed CRM or CRM-like systems to track customer projects for pre-sales, sales and support, resulting in no unified view of the customer for staff and leadership at any level.

Changing customer expectations and market disruption was the trigger for a major Digital Transformation investment with three strategic goals:

• One Account Team for the customer across all interactions to drive improved Customer Experience and Relationship. KPIs tracked via formal customer feedback process
• One Opportunity Pipeline across the organization to drive a complete view of customer and product performance and to accelerate project TPT and therefore Revenue. KPIs tracked availability of these views, executive use and project cycle time
• Data-led decision-making, with a particular emphasis on deal losses to inform future product features and customer team focus. There was no KPI in place (not best practice)

By the end of the program, two of these outcomes were realized and one was ongoing. You can guess which one was wobbly... the one without the KPI. As an aside - do set KPIs for strategic goals. The act of setting them helps to clarify up front and builds a cross-organizational coalition (or shows you do not have one) and then helps to focus activity in the execution and embedding stages.

Given those goals, a key project within the overall program was collapsing the legacy CRM-like trackers using Siebel, SAP and various Excel-adjacent schemes and replacing with the popular SaaS CRM, Salesforce.

For enterprise master data such as Customer, Product and Employee, and the associated hierarchies, I was able to identify enterprise data sources and, in partnership with the IT provider, automate their integration with Salesforce using Mulesoft. So far so good.

Garbage In, Gold Out?

But what about the transactional data? The most obvious approach was to automatically transfer from the legacy systems, but let's step back for a moment.

The data quality was bad. The client did not have a singular pipeline. There were sporadic updates. The data were completely different shapes in the source records as the legacy sales cycles are different.

Let's back up one more step. What are we trying to achieve here, strategically?

When we are thinking about the Target Operating Model for the client the following behavioural changes are happening:

Consider the elements of a Target Operating Model and what is changing here:

• Process - new processes around regular updates, reviews and sales stages
• Organization - virtual overlay of merged account team (later became physical organization) 
• Learning and Knowledge - New processes to understand and new tools to learn for both insights and capture
• Information and Data - better data available
• Technology - new tools
• Infrastructure - no change - same buildings
• Culture - key changes in collaboration, timely updates and management decision making

When we step back and look at the these changes through the lens of transformation we see that an automated transfer of the old, bad data would have actively undermined the strategic objectives of the program. We would have:

• Sabotaged the data quality from the beginning
• Missed the opportunity for individual and group hands-on training on real data and the new processes
• Critically, given the impression that this was an IT system change, not a new way of working
• Given the appearance of saving user time, but not, in fact, as manual corrections would have been necessary after the transfer. This is a key point when evaluating the cost/effort of automated vs manual approaches. Often the automated transfer has to be cleaned up manually anyway, which costs more and uses more time. This is counterintuitive unless the program is established as new way or working as distinct from a "new system".

You are doing WHAT?

So I made the recommendation to manually-recreate the opportunity pipeline data to the Steering Group. As you can imagine, this approach was not popular with the teams who would use the system. They were concerned about the "wasted time" involved in manual data-entry. I

• Performed analysis that showed the time spent re-entering Opportunities was manageable, especially when considering training time that would occur in any case
• Engaged decision-makers with the strategic goals and how this approach supported them
• Provided specific mitigations for key "hotspots"
• Ensured that the Change Management effort consistently referred back to the strategic goals so that users could focus more on the future and less on the time spent
• Enlisted Business Champions to support this position and also assist individuals in their migration

How did it go?

The transfer went amazingly well. The teams were able to clean the data as they went, applying their individual knowledge of the projects they were working on to each opportunity , assuring best quality and learning of the new processes, tools and expectations.

Over a period of weeks, tens-of-thousands of opportunities were created by thousands of customer-facing employees across four global regions, three major GTM motions and hundreds of product types.

The process was self-limiting and self-correcting, in that unnecessary transfers did not happen as a result of fine-grained expert curation, rather than a blunt automated approach.

The program team were able to monitor the build-out of the pipeline with reporting and ensure that DQ KPIs were being satisfied.

We were able to see this through all the different perspectives that the new approach enabled: by product, region, customer type, size. It was amazing to see the picture appear before our eyes!

The client subsequently used this data to define GTM approaches, measure business KPI performance in real-time, allocate resources and provide visibility to strategic projects at board level.

Conclusion

The choice to re-create the Opportunity Pipeline rather than automatically transfer the old pipeline data reinforced the strategic objectives and was material in creating a complete pipeline for the business.

The human intelligence was needed to create good-quality records. The prior culture and expectations meant that this intelligence simply was not present in the old records and so automatically transferring them would have been self-defeating.

Was it perfect? Of course not. Pipelines rarely are. But it was night-and-day better than before and paved the way for future decision making on product introduction plans and corporate resource allocation.

Would I do it again? Absolutely! And I would have more AI help this time, particularly in identifying issues, enriching data and in monitoring quality. Tantalisingly, I could perhaps have used AI to create new records by automated inspection of customer interactions. Please get in touch if you are interested in this.

For your next system migration or audience migration, think carefully about the data conversion approach across these dimensions

• Assess Source Data Quality Early: Automation may not be the best option for all datasets. Evaluate the state of your data before deciding on migration methods
• Align with Strategic Goals: Choose migration approaches that support and promote your organization’s transformation objectives. Migration may be an error
• Invest in Change Management: Manual recreation can be an opportunity for training and process adoption, but requires strong change management to support the client's staff
• Monitor and Measure: Establish KPIs for data quality and business outcomes to track success
• Consider Cost and Resource Implications: Balance the benefits of quality and training with the time and effort required for manual processes

Structuring your program for success at early stages maximizes the chance of achieving the intended strategic result. It reduces rework and saves money.

If you would like explore more about how to structure strategic business information systems programs to get the intended results then let's connect via LinkedIn or fieldenablement.com.

May your data fulfil your strategy,
Gareth