Customer Data Migration with Late-Discovered Quality Issues
You are the BA on a customer data migration from three legacy systems into SAP S/4HANA. Go-live is in six weeks. During the final data rehearsal, you discover 22% of customer records have missing or inconsistent address data, and 8% have duplicate records across systems. The business case assumed 99% data accuracy. The data owner (head of customer service) says the data is 'good enough' and wants to proceed; the CIO is risk-averse and wants to delay. You have a fixed budget and the vendor's contract has penalties for delay of £20k per week. Customer service handles 5,000 calls a day, and the marketing team has a campaign planned for week one post go-live. The steering committee asks for your recommendation within five working days.
1. What analysis would you perform to assess the impact of the data quality issues, and what options would you present?
Read the worked answer
I would perform a data profiling exercise to quantify the issues by customer segment, product, and region. I would then map the impacted business processes: billing (wrong address means invoices go astray), delivery (misrouted goods), customer service (longer call handling), and marketing (campaign waste). I would estimate the cost of each impact. I would also do root cause analysis: is the address data missing because of legacy system design, or because of process gaps? For duplicates, I would assess merge complexity. Then I would present options: (A) delay go-live by four weeks to remediate, costing £80k in vendor penalties plus internal effort; (B) proceed with a manual data cleanup team for the first eight weeks, costing £60k but with residual risk; (C) phase migration by customer segment, starting with clean data; (D) proceed as-is and accept the risk, with a contingency plan. I would quantify the risk of each in terms of customer impact and cost.
2. How would you frame your recommendation to the steering committee, given the conflicting positions of the data owner and CIO?
Read the worked answer
I would frame the recommendation around business risk, not data perfection. The steering committee needs a decision, so I would present a clear recommendation with evidence. My recommendation would likely be option B with conditions: proceed with go-live but only after a targeted cleanup of the highest-risk records (e.g., customers with active orders or recent complaints), and with a 90-day remediation plan and a dedicated data steward. This balances the CIO's risk aversion with the data owner's desire to proceed. I would show the cost of delay (£20k/week) versus the cost of remediation and the potential cost of a data incident. I would also highlight that the business case assumption of 99% accuracy is no longer valid and propose a revised business case. I would ask the steering committee to accept the residual risk explicitly. I would document the decision and the mitigation plan. The key is to be transparent about trade-offs, not to pretend there is a perfect answer.
3. If the decision is to proceed, what data quality remediation approach would you recommend?
Read the worked answer
If proceeding, I would implement a three-tier remediation: (1) automated cleansing rules for standard address formats and duplicate matching, run in batch; (2) manual review by a temporary data quality team for high-value or high-risk records, prioritized by customer lifetime value or open orders; (3) a process fix at source: new validation rules at the point of capture, and a data governance forum to assign ownership. I would also set up a data quality dashboard tracking completeness and accuracy weekly. For duplicates, I would use a match-merge tool with survivorship rules agreed by the business. I would communicate to customer service and marketing about the known issues and provide workarounds. I would also schedule a post-go-live audit at 30 days to measure improvement. The goal is not 100% clean data but a controlled, improving position.