The mid-market cost and the recovery path
A CFO and COO guide to quantifying the operational impact, choosing between stabilization, remediation, and reimplementation, and rebuilding the program around measurable business outcomes.
An SAP program rarely moves off track because of one dramatic event. More often, unresolved design decisions accumulate, data ownership remains unclear, testing is compressed, and operational teams create workarounds to protect daily business. By the time the project plan shows a serious delay, the business may already be absorbing the cost.
For a mid-market company, that cost can reach far beyond the implementation budget. Billing delays affect cash. Inventory uncertainty increases working capital. Production and fulfillment issues put customer commitments at risk. Finance and operations spend more time reconciling exceptions while leadership loses confidence in the program.
The executive question is no longer whether the original plan was right. It is which action will restore control with the least additional risk: stabilize the current design, remediate specific weaknesses, or reset the program around a different implementation approach.
Stabilize
Hold the operation steady
Remediate
Repair contained weaknesses
Reimplement
Reset the approach
Schedule variance is visible in the project plan. The more important effects appear in operational and financial measures. A delayed or unstable go-live can interrupt order processing, invoicing, purchasing, production planning, inventory control, and the financial close. Each issue creates a different cash, margin, or service consequence.
Order to cash
Early failure signal
Pricing, credit, delivery, or billing exceptions increase
Executive impact
Slower invoicing, higher DSO, delayed revenue, and more customer escalations
Procure to pay
Early failure signal
Vendor records and approval workflows do not operate consistently
Executive impact
Late payments, lost terms, duplicate effort, and supplier disruption
Plan to produce
Early failure signal
Demand, material, or production data cannot be trusted
Executive impact
Stockouts, excess inventory, schedule changes, scrap, and expedite costs
Record to report
Early failure signal
Reconciliations and manual journals increase after go-live
Executive impact
Longer close cycles, weaker margin visibility, and additional control risk
Integrations and controls
Early failure signal
Transactions fail between ERP and operational systems
Executive impact
Interrupted workflows, incomplete audit trails, and higher support cost
The financial case should use company data rather than broad industry averages. Two simple calculations can show why an operational problem deserves executive attention.
Measure
Cash tied up by slower collections
Annual revenue divided by 365, multiplied by the increase in days sales outstanding.
Measure
Additional inventory carried
Annual cost of goods sold divided by 365, multiplied by the increase in inventory days.
Illustrative example — not a benchmark, forecast, or promise
Annual revenue
$200M
Increase in DSO
5 days
Additional cash tied up in receivables
≈ $2.7M
Illustrative example. For a company with $200 million in annual revenue, a five-day increase in days sales outstanding represents approximately $2.7 million of additional cash tied up in receivables. This calculation is not a recovery forecast. It shows how a process issue can quickly become a financing issue.
The cost can compound when the company runs the legacy ERP and SAP in parallel, extends external consulting support, repeats testing cycles, or delays other investments that depend on the new operating model. A recovery business case should capture these costs separately instead of hiding them inside the original implementation budget.
The software may contribute to a problem, but program failure usually involves the interaction of business scope, process design, data, integrations, governance, and organizational capacity. Recovery begins by identifying which part of that system is failing.
Executives may approve the program to improve working capital, accelerate the close, support acquisitions, or standardize multiple plants. Those priorities often disappear once design workshops begin. Teams make local configuration decisions without a clear rule for resolving conflicts, and the program measures completed activities instead of business outcomes.
A usable business case names the operational measures that must improve, the process owners accountable for them, and the design principles that take priority when requirements compete.
A program can have a technically reasonable scope and still be too large for the organization to absorb. Mid-market subject matter experts often support the implementation while continuing to run finance, production, procurement, warehousing, or customer operations. When the plan ignores this constraint, decisions wait, testing loses depth, and training is pushed toward go-live.
Item masters, bills of material, customer and vendor records, pricing logic, and opening balances need named owners and acceptance criteria. The same applies to connections with manufacturing execution, warehouse, transportation, customer relationship, and other operational systems. If these dependencies are not proven early, the program discovers business-critical gaps when the cost of change is highest.
A steering committee cannot manage the program from a percent-complete indicator alone. It needs visibility into unresolved decisions, critical process defects, data readiness, testing coverage, change capacity, and the financial effect of delay. Reporting can remain green while operational readiness deteriorates.
A full restart should not be the automatic response to a troubled program. Continuing the current plan without testing its assumptions is equally risky. The right path depends on whether the core design remains viable, whether the data and integrations can be repaired, and whether the organization can support the required change.
Recovery path 01
Best fit
The core design is viable, but operational incidents or adoption problems are disrupting critical processes
Primary risk
Temporary fixes become permanent and the root cause remains
Executive decision
Which business flows must be protected first and what changes should pause
Recovery path 02
Best fit
Weaknesses are material but contained within specific processes, data domains, integrations, or governance practices
Primary risk
The program corrects symptoms without reopening the decisions that created them
Executive decision
Which scope must be redesigned, retested, or deferred
Recovery path 03
Best fit
The target design, architecture, data model, or operating assumptions cannot support the business at reasonable risk and cost
Primary risk
A reset increases near-term effort and organizational fatigue
Executive decision
What should be retained, what must change, and how continuity will be protected
7
Countries of operation
2
Already live: Argentina, United States
ISTC operates across seven countries and previously ran its business on SAP Business ByDesign. With Dintec Consulting, the company is moving to SAP Cloud ERP through a phased, country-by-country rollout, with Argentina and the United States already live. Each market can adopt a proven template while the wider group continues operating, and finance gains a consistent model for multi-entity and multi-currency reporting from the first wave onward.
ISTC’s rollout is an example of risk reduction through sequencing. It does not represent a troubled-project recovery. It shows how a company can limit operational exposure, validate the model, and apply lessons from each go-live before moving to the next country.
These questions turn the recovery decision into an investment choice. They also prevent sunk cost from becoming the primary reason to continue a plan that no longer serves the business.
A CFO-ready roadmap connects technical work to operational protection, cash exposure, decision authority, and measurable exit criteria. It should give leadership enough information to release funding in stages rather than making another all-or-nothing commitment.
Stage one
Create one fact base for project health and business impact. Confirm the current design, open defects, data readiness, integration status, testing coverage, support demand, remaining cost, and operational constraints. Assign one owner to each critical end-to-end process and document who can make time-sensitive decisions.
Stage two
Prioritize the processes that protect revenue, cash, supply, production, customer commitments, and financial control. Use a temporary change freeze where it helps reduce instability. Separate urgent continuity work from longer-term optimization so the team can restore predictable operations without expanding scope.
Stage three
Reconfirm what must be delivered, what can be deferred, and which design decisions need to be reopened. Recalculate the cost to complete, contingency, internal capacity, dual-running expense, and expected timing of benefits. The revised plan should show what evidence leadership will receive before each additional funding decision.
Stage four
Define acceptance criteria for process performance, data quality, integration stability, controls, user readiness, and support. Track value after stabilization using the same KPIs that supported the business case. Knowledge transfer should be part of the recovery plan so internal owners can manage the system after the immediate crisis passes.
Business continuity
Measures to track
Order backlog, billing exceptions, production interruptions, supplier and customer escalations
Decision supported
Where stabilization resources should go first
Cash and margin
Measures to track
DSO, inventory days, expedite cost, write-offs, manual effort, and dual-running cost
Decision supported
Whether the financial exposure is improving
Delivery health
Measures to track
Critical defects, decision aging, testing coverage, data acceptance, and integration stability
Decision supported
Whether the revised plan is credible
People and adoption
Measures to track
Training completion, role readiness, support demand, and process-owner sign-off
Decision supported
Whether the organization can absorb the change
Value realization
Measures to track
The original business-case KPIs with owners and review dates
Decision supported
Whether the program is producing the intended outcome
A recovery partner should connect system findings to business consequences. Leadership should expect a focused assessment, a prioritized recovery plan, clear assumptions, named accountability, realistic sequencing, and knowledge transfer to internal teams. The objective is to restore management control and create a program the organization can operate after the recovery engagement ends.
Dintec Consulting brings more than 30 years of SAP experience, more than 500 SAP projects, and a customer satisfaction rate above 95 percent. Its work spans manufacturing, wholesale distribution, professional services, transportation and logistics, and food and beverage. That operating context helps Dintec evaluate SAP design decisions against the processes and constraints that mid-market companies manage every day.
30+
Years of SAP experience
500+
SAP projects
95%+
Customer satisfaction
A troubled SAP program does not need another optimistic schedule. It needs a fact-based decision about what can be stabilized, what must be repaired, and what should be reset. When financial exposure, operational priorities, and system decisions are managed together, leadership can protect continuity while rebuilding a credible path to value.
Dintec can assess the current design, data, integrations, governance, and operational readiness, then help leadership define practical next steps. Start with a focused SAP project assessment to understand the risks, recovery options, and decisions that require executive attention.
A focused assessment of risks, recovery options, and executive decisions.