This is a composite scenario drawn from real field experience across cost-model implementations; the details, sector and figures are illustrative and represent no single client. For a generation, getting a defensible enterprise cost model meant a multi-year build on a heavyweight platform, a seven-figure budget, and a dependence on scarce specialists that often left the model dead within a year of go-live. The modern stack does the same job in days, keeps it alive in the client's own hands, and makes every number traceable, and once you have seen both, the old way is hard to defend.
Ten minutes, fourteen questions, the full result on screen, no email required. If you already trust your margin by customer, you do not need it.
Enterprise Costing, Then vs Now
Quick answer. This is a composite scenario drawn from real field experience across cost-model implementations; the details, sector and figures are illustrative and represent no single client.
The heavyweight-platform era of enterprise costing was not a mistake for its time; it was the only way to allocate cost at scale before the tools caught up. But its economics were punishing: a large enterprise costing suite, a global advisory firm to configure it, eighteen to thirty-six months of build, and a model so intricate that only a handful of people ever understood it. When those people rotated off, the model calcified, accurate on the day it was signed off, and quietly wrong every month after. The modern approach inverts every one of those constraints. A small specialist team, a purpose-built costing engine (CostCtrl), and AI to accelerate the mapping and the narrative deliver a first working model in days, not quarters, at a fraction of the old cost, with a structure the client's own finance team can maintain and a full audit trail behind every allocated euro. Software did get cheaper, and that helped. The change that mattered more is that costing stopped being a construction project and became a living capability. This page sets the two eras side by side, fairly, and shows why the second one wins.
Picture a large, capital-intensive infrastructure operator around 2019 (a composite, not a single organisation). The board wants to know what each service line, asset and customer segment actually costs to run. The received answer, then, was a programme: license a heavyweight enterprise cost-management platform, engage a Big Four firm to configure it, and stand up a project office to run the build. The platform was genuinely powerful, it could model tens of thousands of cost objects and drivers, and that power was exactly the problem. Every strength came with a matching weight.
The build unfolded over quarters, not weeks. Requirements workshops, a driver dictionary, allocation rules encoded by consultants, reconciliation against the general ledger, then a validation cycle that alone could run for months. Representative figures for a programme of this size (illustrative): eighteen to thirty-six months of elapsed time and a budget well into seven figures once licences, system integration and internal effort were counted. When the model finally went live it was, on that day, a serious piece of work, a defensible answer to a hard question. The difficulty was everything that came after day one.
The failure was rarely dramatic. A heavyweight cost model does not crash; it drifts. The business reorganises, a cost centre is renamed, a new service launches, an asset is retired, and each change needs a specialist to re-encode the allocation logic. Because the model was built for the client rather than by them, that specialist was usually external, expensive, and no longer on site. So the small changes queued, the workarounds multiplied, and within a year the model that cost a fortune to build was being politely ignored in favour of a spreadsheet someone trusted. This is the pattern a defensible cost split is supposed to end, not repeat (see CostCtrl versus spreadsheets).
None of this is anecdotal. The Standish Group's long-running CHAOS research has for years shown that large IT-enabled programmes are the ones most likely to be challenged or fail outright, with success rates falling as project size rises. The Project Management Institute's Pulse of the Profession has repeatedly put the share of budget lost to poor project performance in the double digits. A cost model is exactly this kind of asset: its value is not in the go-live, it is in the fiftieth month of trustworthy use. The old delivery model optimised the launch and neglected the life.
The method is on this page. What it would find in your numbers is not. The Profit Check scores seven dimensions of your costing in ten minutes and names the gap worth closing first. If you already have your margin by customer and by product in a number you trust, you do not need it.
Take the Profit CheckThe modern answer is not a bigger platform. It is a different shape of delivery, made of three parts. First, a small specialist team that lives in cost and profitability work and brings the method rather than reinventing it, time-driven activity-based costing done properly, so the driver logic is transparent instead of buried (the foundations sit in activity-based management). Second, a purpose-built costing engine, CostCtrl, designed for exactly this job: it is opinionated about cost pools, drivers and capacity, so the structure that took a heavyweight suite months to configure is largely there on arrival. Third, AI to do the slow, mechanical parts, mapping a chart of accounts to cost pools, drafting time equations from process descriptions, reconciling to the ledger, and writing the first-pass narrative a finance team can review rather than compose.
The compound effect is a first working model in days. Not a toy: a model that ties to the general ledger, respects the cost of unused capacity (see cost of unused capacity), and produces a profitability view leadership can act on in the first workshop rather than the fourth quarter. Because CostCtrl is purpose-built and the logic is explicit, the same team that saw the model built can maintain it. The specialist configures the first version and teaches the pattern; the client's own analysts carry it forward. Costing stops being something that is delivered to the business and becomes something the business owns.
The table sets the heavyweight-platform era against the modern stack across the dimensions that actually decide whether a cost model earns its keep. The figures are illustrative and representative of programmes of this type, not verified results from any single client.
| Dimension | Then: heavyweight platform era | Now: specialist team + CostCtrl + AI |
|---|---|---|
| Time to first model | 18-36 months of build and validation before leadership sees a usable view (illustrative) | A first working model in days; a refined, ledger-tied version in weeks (illustrative) |
| Total cost | Seven figures once licences, integration and internal effort are counted (illustrative) | A fraction of the old cost, a small fixed-scope engagement plus a subscription engine (illustrative) |
| Maintainability | Changes need a scarce, usually external specialist; small edits queue for weeks | The client's own finance team maintains the model; changes are made in the workshop, not in a change request |
| Traceability | Powerful but opaque; allocation logic understood by a handful of people | Every allocated euro traces back through driver and cost pool to the source ledger line |
| Key-person risk | High; the model lives and dies with named specialists who rotate off after go-live | Low; the method is explicit and taught, so no single person is the model |
| Likelihood of surviving past go-live | Low; often quietly abandoned within a year as it drifts out of date | High; designed to be updated monthly by the people who use it |
Read down the last column and a pattern emerges: every advantage of the modern stack is really the same advantage wearing different clothes, ownership. Speed, cost, maintainability, traceability and survival all follow from a model the client can actually hold. The old world outsourced understanding; the new world builds it in.
It would be a straw man to pretend the old approach was foolish. It was the rational response to a real constraint. Before purpose-built engines and capable AI, allocating cost across tens of thousands of objects genuinely required an industrial platform and specialist hands, and the heavyweight suites did things smaller tools of the day could not. The discipline those programmes imposed, a driver dictionary, formal reconciliation, a validated audit trail, is exactly the discipline the modern stack keeps. Time-driven activity-based costing itself, the method underneath all of this, was formalised by Kaplan and Anderson precisely to tame the complexity that early activity-based costing collapsed under. The modern approach does not reject that lineage; it inherits it and sheds the weight.
What changed is not the ambition but the cost of achieving it. The old model paid for its rigour with time, money and fragility. The modern model keeps the rigour and stops paying those three prices, which is only possible because the engine is purpose-built and the mechanical work is automated. When a large enterprise costing suite is genuinely the right tool, a handful of the very largest, most idiosyncratic environments, it still is. For the overwhelming majority of organisations that once assumed they needed one, they no longer do. The honest comparison is not "old bad, new good"; it is "the constraint that justified the old way has lifted."
Speed is a temptation as well as a virtue. A first model in days is only valuable if the inputs beneath it are real, and the failure mode of the new stack is the mirror image of the old one: instead of over-building, teams under-validate. A few pitfalls recur. Confusing fast with finished: the day-one model is a starting hypothesis, not a signed-off answer, and it still needs reconciliation to the ledger and a sanity check against how the business actually behaves. Letting AI encode a plausible-but-wrong driver: a language model will happily draft a time equation that reads well and allocates badly, so the specialist has to own the logic, not rubber-stamp it. Skipping the capacity question: a model that ignores unused capacity flatters busy periods and punishes quiet ones, which is why the cost of unused capacity has to be explicit from the start.
There is also an adoption trap the old world knew well and the new world can still fall into. A model the client cannot maintain will die whatever built it, so the handover is not a phase at the end, it is the design principle from the beginning. If the specialist team leaves and the finance function cannot make next month's change unaided, the engagement has failed regardless of how fast the first model appeared. Judged the right way, the modern stack is measured not by time-to-first-model but by whether the model is still trusted and current a year later. That is the same test the heavyweight era so often failed, and it is the one worth holding the new approach to. It is also why profitability work should be tied to the metrics leadership already watches (see profitability KPIs) and, for investors, to the diagnostics that reveal where portfolio value actually sits (see private-equity portfolio profitability diagnostics).
The Standish Group, CHAOS Report (success, challenge and failure rates of IT-enabled projects, and how they worsen with project size). · Project Management Institute, Pulse of the Profession (share of investment lost to poor project performance). · Kaplan, R. S. & Anderson, S. R. Time-Driven Activity-Based Costing (Harvard Business Review, 2004; book, Harvard Business Press, 2007, the method underpinning transparent, maintainable cost models). · Kaplan, R. S. & Cooper, R. Cost & Effect (design and lifecycle of activity-based cost systems). For related reading see economic value added (EVA).
Proof
A distributor in New Zealand. €1.335M of cost-to-serve made visible, then halved, and 830 loss-making customers brought down to 295.
Read the case study →Who you would be talking to
Miguel Guimarães, Founding Partner
Cost and profitability practitioner for 25+ years. Presented the Damco cost-to-serve case at Managing for Profit (Amsterdam RAI, December 2009), on the same programme as Robert S. Kaplan.
Call +351 910 313 731
Workshops
One working profitability model, built from real data, that you take home at the end.
Reserve a seat
Reviewed by
Miguel Guimarães
Founding Partner, Cost and Profitability Consulting
More than 150 Time-Driven ABC engagements across 11 sectors since 2010, working within the Kaplan and Anderson framework.
About the author →Published
Done. There is nothing here to refuse. This site retired advertising on 27 August 2026, and no advertising or tracking tag runs on it for anyone. Your remaining choices, session recording and audience measurement, are under “Cookie settings” at the foot of any page.
We are asking again. Your last answer is more than 12 months old, so it has been cleared. Nothing is switched on until you answer.
This notice has changed. Your previous answer was given to different wording, so it has been cleared and we are asking again. Nothing is switched on until you answer.
Say yes and we learn which pages help. Say no and nothing on this site changes.
Session recording. Microsoft Clarity records how this page is used - mouse movement, clicks and scrolling - so we can improve it. Form fields are always hidden from the recording.
Audience measurement. Google Analytics 4 counts your visit and the path you take through the site, so we can see which pages are useful. It stores two cookies of our own domain, _ga and _ga_L5HNZN655T, holding a randomly generated identifier for your browser - so these statistics are not anonymous. Nothing is loaded until you say yes.