The bottom line
The largest line in most IT operating budgets — the human effort that keeps ERP and the application estate running — is still procured by fixed headcount or fixed-fee contracts, even though the work is consumed unevenly. Even demand paid for evenly leaks money.
A practitioner's case for treating IT support delivery the way the cloud already treats infrastructure — as a service you consume, not a headcount you carry.
The views below are my own, drawn from years of standing up ERP support for mid-market and enterprise estates. Reasonable operators will weigh the trade-offs differently, and I welcome that.
The cloud already taught buyers the lesson — IT support never learned it
Every CIO and CFO now understands the as-a-service bargain intuitively. You do not buy a data center to run a web app; you rent compute from AWS and pay for what you consume. You do not buy a CRM license server and a database administrator to run it; Salesforce delivers the software as a service. The pattern is so familiar — IaaS, SaaS, PaaS — that it barely registers as a decision anymore.
Yet the largest line in most IT operating budgets, the human effort that keeps ERP and the surrounding application estate running, is still procured the old way: full-time hires, fixed-fee managed services contracts, or staff augmentation by the hour. The work is consumed unevenly, but it is paid for evenly. That mismatch is where money leaks.
ITaaS — information technology delivered as a service, applied to human expertise rather than only to machines — closes the gap. System administration, database work, development, business analysis, and day-to-day production support can be delivered and consumed the same way you already consume cloud infrastructure. The benefit is not novelty. It is that demand for support is lumpy, and a consumption model is the only one that tracks lumpy demand without waste.
Where the traditional models leak
The argument for ITaaS is easiest to see by looking at what the legacy models cost you when nothing dramatic is happening.
Paying for capacity you do not use. Hire a full-time specialist and you are committed to roughly forty hours a week whether or not the work is there. Sign a fixed-fee managed services contract and you pay the same monthly figure in a quiet month as in a busy one. The scope is set once, priced with a vendor risk premium baked in, and then it sits — a fixed cost wrapped around variable demand.
Riding the business cycle the hard way. Every company moves through expansion, plateau, and contraction, and the last several years added pandemics, supply shocks, and demand swings to that list. Under the traditional models, a downturn forces a bad choice: lay off skilled people you will need again in two quarters, or open a slow scope-and-cost renegotiation with an incumbent provider — and when neither works, the orphaned work simply lands back on internal staff.
Burning senior time on routine work. Internal IT teams rarely get to specialize. The same people field 24/7 support tickets, run projects, and carry deep expertise, which means constant context-switching. Critical project work stalls to chase an urgent ticket. Senior engineers spend their hours on low-level tasks they are overqualified for. Too much of the team's day goes to keeping the lights on when the business wants revenue, margin, and customers.
What a consumption model actually changes
Reframing support as a service is not a billing trick. It changes five things that show up directly in the operating model.
Pay for consumption, not for a bundle
Fixed monthly fees charge the same amount regardless of what was actually used, and the price is almost always set to protect the provider's margin against its worst month — which means you overpay in your average month. A consumption model inverts that: cost tracks the work performed and is submitted on that basis. Quiet months cost less; busy months cost more; neither produces waste in the first case or a renegotiation in the second.
Scale up and down without an HR cycle
Demand for support is driven by the economy, customer behavior, technology change, and even weather. The ability to flex support up or down quickly, with little administrative friction, is the practical payoff. The patterns recur across industries: a company acquiring a business needs support to ramp immediately; an agribusiness needs to ramp spend down fast after extreme weather; a manufacturer needs heavy ERP implementation support that tapers to steady-state after go-live; a seasonal consumer-health business needs identity and access support that rises and falls with hiring seasons; a dairy operation mid-migration needs phased support for the legacy ERP for years. None of those profiles fits a fixed headcount or a fixed-fee scope cleanly.
Out-task the distractions and reclaim productivity
The daily reality of an IT team is shifting demand, tickets arriving at any hour, and projects starting and stopping. That churn can make a skilled team materially less productive than its raw capacity suggests. Adding staff, contractors, or a managed services layer often costs more than the productivity it returns. The consumption alternative lets the customer decide which task sets are distractions — the work that forces context-switching or does not draw on core expertise — and hand only those off. In practice that has let a retailer's IT manager spend more time managing and less time on hands-on support, and freed senior engineers at a chemical distributor to redirect dozens of hours a month into project work instead of tickets.
Get many skills without paying for many people
A single ERP application typically needs system administration, database expertise, development, business analysis, and more. The demand for each is usually less than one full-time person, but no single hire holds all those skills. A consumption model lets a customer call on any of those skills on demand and pay only for what is used — because the cost attaches to the task, not to a salaried resource. A mid-market manufacturer using on-demand access across system administration, database, development, business analysis, and BI reported large savings against the cost of hiring each skill set separately. Treat any specific savings figure as illustrative until your own estate proves it; the structural point is what holds — you stop paying standby cost for skills you use intermittently.
See exactly what you are paying for
Fixed-fee invoices often arrive as a single line item, leaving the customer unable to say what was done last month. A consumption model reports work by category and resolves cost down to fine-grained increments. The value of that transparency is not the comfort of a predictable number — comfort can shade into complacency. It is the opposite: when monthly cost is allowed to move with actual work, the peaks and valleys carry information. A cost spike is a signal worth investigating; the investigation often surfaces a non-value-added activity that can be removed, or a repetitive task that can be automated away. A flat fixed fee hides that signal and removes the incentive to act on it.
Why this matters more now, and where it leads
That last point is the whole thesis. A flat fee gives you no reason to find and kill repeat work, because the cost does not move when the work does. A consumption model does the opposite: every recurring cost spike is an invitation to automate the underlying task, and when you automate it, the cost falls and stays down. Repeat work becomes visible, so it can be automated or removed. That is the difference between a model designed to stay the same and one designed to get cheaper as you learn.
Digitalization, and the steady drumbeat of pandemics, conflict, supply shocks, and climate disruption, are forcing businesses to be more agile, more resilient, and less dependent on forecasts that no longer hold. An operating model that charges for work done, makes that work visible, and then automates the repeatable part is simply better suited to that world than one that locks in a fixed cost and hopes demand cooperates.
Analysis by Ravi Madhavan. Originally published on LinkedIn. Allari runs the ERP production-support layer for JDE, SAP, Oracle Fusion, and NetSuite estates — making routine work visible and finding where the repeatable part can be automated.
