How to Reduce Enterprise System Fragmentation in 120 Days
Written by Aravind Sakthivel, Author & Technology Leader
Aravind Sakthivel is a global IT technology leader with extensive experience in the industry. He is also the author of the book The Leadership Trap: Why Smart Leaders Fail and How to Break Free.
Disconnected systems slow decisions, create rework and weaken customer service. A focused 120-day programme can begin restoring control by improving the processes and data behind them. The starting point is to understand where value gets stuck. During my Master of Business Administration (MBA), I had the opportunity to learn from a former IKEA Chief Information Officer (CIO), and one lesson stayed with me, global scale does not require technological uniformity everywhere. Disciplined process design and clarity about where standardisation creates value matter more. Enterprise Architecture should simplify the business, not merely standardise the technology.
Begin with the value stream. Identify the process and data problems, remove unnecessary steps, standardise where it adds value, connect the information, then automate what remains. There is little value in automating waste. The phases below provide a working sequence rather than fixed deadlines. Their pace depends on scope, system access and the business’s capacity to deliver change.
Follow the customer journey
Across technology transformations, I have seen businesses invest in integration and reporting while leaving the causes of fragmentation untouched. Sales knows the customer, Enterprise Resource Planning (ERP) holds the order, operations manages production, and finance tracks margin. Each team can be busy and competent while the overall customer journey remains slow.
My Enterprise Architecture training at Carnegie Mellon reinforced a lesson from practical delivery, begin with business capabilities and the flow of value. Follow an order from quotation through pricing, credit, production, delivery and payment. Look at the whole journey before deciding which platform needs replacing.
Lean calls activity that consumes resources without creating customer value muda. In transactional work, it often appears as duplicate entry, spreadsheet reconciliation, avoidable approvals and queues between teams. A task might require ten minutes of work but spend two days waiting. Automating those ten minutes leaves the main constraint in place.
Find the biggest constraint
During days 1 to 30, choose one priority value stream, such as order to cash, and walk it with the people doing the work. Follow real transactions rather than relying only on process diagrams. Identify where information is entered twice, approvals stall or teams correct data received from elsewhere.
Assess the master data supporting that journey. Who owns customer and product records? Which system is authoritative? Where do duplicates originate? Do business units use the same definitions? An apparent ERP problem may be a customer data problem, unreliable reporting may begin with inconsistent product hierarchies.
Agree a baseline for a few useful measures, such as order lead time, rework, on time delivery and cash collection. By day 30, aim to have a current state map, named process and data owners, and a ranked list of constraints. Keep the scope manageable, understanding one important value stream properly is more useful than documenting every process superficially.
Include the cost of waiting in the assessment. An order delayed by missing customer information may affect delivery commitments and cash collection, even if correcting the record takes only minutes. Separate processing time from elapsed time, and examine where errors first enter the journey. Ask frontline colleagues which workarounds they rely on and why. Those answers often reveal dependencies that system inventories miss. Agree who can resolve issues crossing departmental boundaries, because a process owner without decision authority will struggle to change them.
Simplify before adding technology
During days 31 to 60, bring business owners and technology teams together to remove the largest source of waste. A focused Kaizen, or continuous improvement exercise, can test whether each approval, handoff and correction still serves a purpose. Some steps exist because an old system once required them.
In order to cash, repeated credit checks and pricing exceptions passing through several managers may delay an otherwise straightforward order. Clear approval thresholds, cleaner customer records and agreed standard work can improve flow before any new software is introduced. Retain controls that manage real financial or regulatory risk, and remove duplication with the responsible owner’s agreement.
Commercial excellence needs the same attention. Customer, pricing, order and service information should help sales make informed decisions. Identify the information needed for pricing discipline or customer prioritisation, then clarify its ownership and quality. By day 60, the priority process should have fewer avoidable handoffs and a clearer route for exceptions.
Test the revised process with a small group before extending it. Make the new approval thresholds and responsibilities easy to follow, and check whether staff understand when an exception requires escalation. Standard work should capture the best agreed method while leaving room for legitimate local requirements. A regulatory obligation, customer contract or manufacturing constraint may justify variation. The important distinction is whether that variation serves a current business need or simply survives from an earlier arrangement. Record the reason so the next improvement team does not have to rediscover it.
Build a trusted view
During days 61 to 90, use Enterprise Architecture to connect the improved process across existing systems. A business does not have to replace every enterprise resource planning (ERP), customer relationship management (CRM) and warehouse platform before it can gain useful visibility. Governed interfaces and a shared information model can support a focused operational view while those systems continue running.
Common definitions matter more than an attractive dashboard. If business units calculate backlog differently, placing their figures together simply makes the disagreement visible. Agree on what customer, order, margin and on time delivery mean, how they are calculated, and who maintains each definition.
Start with information that supports a specific decision. Operations may need demand, stock and delivery constraints, commercial leaders may need pricing and customer profitability. Show when data was refreshed and where gaps remain. By day 90, aim for a tested view of the selected value stream, with fewer manual reconciliations and clearer accountability for data quality.
Data quality needs an operating routine behind the dashboard. Define checks for missing fields, duplicates and failed interfaces, with named owners and a route for correction. Trace important measures back to their source so teams can investigate discrepancies. Access should reflect the sensitivity of the information and the decisions people need to make. Avoid creating another uncontrolled reporting layer that depends on one specialist. Document the essential mappings and calculations, and ensure business owners can explain what each measure represents before leadership begins relying on it.
Automate what still matters
During days 91 to 120, automate repetitive work that remains after the process has been simplified. Use rules for predictable cases and workflows to route exceptions to a named owner. AI can assist where interpretation adds value, such as summarising an operational issue across several sources, subject to appropriate access controls and human review.
If delivery performance deteriorates at a plant, bring production status, inventory, supplier constraints and affected orders into one view. The manager can investigate with context rather than begin by requesting separate reports. For a margin exception, assemble price, discount and cost information so the responsible team can assess the cause.
Keep the technology proportionate. A simple rule may be enough, an unnecessary process step can be removed entirely. Test automation on a limited scope, monitor incorrect exceptions and assign someone to maintain it. By day 120, aim for a small number of working improvements with measurable outcomes rather than a large collection of unfinished experiments.
For AI, agree on what a useful answer looks like before testing the tool. A summary should distinguish confirmed facts from possible explanations and allow the reader to inspect the underlying information. Missing or outdated records should be visible. Where recommendations could affect customers, pricing or production, retain accountable human judgement. Track whether the tool reduces investigation time without increasing errors or rework. This gives the business evidence about where AI helps and where a simpler approach remains more dependable.
Choose the next investment
A single global enterprise resource planning (ERP) system may eventually be the right choice, but it should follow evidence about business value, cost and risk. One platform can still contain inconsistent processes. Assess whether each application should be retained, integrated, migrated, replaced or retired after understanding the value stream.
The first 120 days will not erase years of fragmentation. They can establish a baseline, simplify a priority process, create trusted visibility and test useful automation. Review results against the original measures and use what you learn to choose the next constraint.
Continue reviewing the selected value stream after the initial programme. Compare results with the baseline, investigate deterioration and update standard work. Discuss persistent exceptions with the people performing the work and agree on who will resolve each cause. Before expanding, confirm that the first improvement has an owner, reliable measures and enough support to continue. Start by tracing one customer order this week, where does it wait, who owns that delay, and what would remove it?
Read more from Aravind Sakthivel
Aravind Sakthivel, Author & Technology Leader
Aravind Sakthivel is a global IT technology leader and the author of the book The Leadership Trap: Why Smart Leaders Fail and How to Break Free. He is a former Chief Information Officer (CIO) across Danaher Operating Companies, where he spent 18 years leading multi-million-dollar technology portfolios. He previously worked at market-leading organizations including Oracle, KPMG. Also provided services to General Electric and Toyota in consulting. Aravind holds an MBA from Nyenrode Business Universiteit, completed leadership programmes at Harvard Business School, and is a Certified Enterprise Architect from Carnegie Mellon University. Alongside his book, he has published research on autonomous AI for enterprises in the Well Testing Journal. He is currently based in Cambridge, United Kingdom.
