The Capacity Equation: Why Your JDE Team Is Busier Than Ever But Delivering Less
Your team is talented. Nobody is coasting. The hours are real — the nights and weekends to get through a deployment, the early mornings chasing a broken integration, the sprint to finish testing before a go-live. And yet the roadmap keeps slipping. The backlog grows quarter after quarter. Strategic projects get scheduled, rescheduled, and quietly downgraded in priority while the urgent work takes over.
The instinct, eventually, is to ask for headcount. Maybe another CNC resource. Another functional consultant. And sometimes that helps — for a quarter. Then the same pattern reasserts itself.
What’s actually happening isn’t a people problem. It’s a math problem. There’s a structural tax on your team’s available capacity that most JDE shops never measure — and because they never measure it, they keep planning against capacity that doesn’t exist.
The 35% Capacity Tax
The IT Process Institute studied more than 850 IT organizations and found something consistent across all of them: 35–45% of total IT capacity disappears into unplanned work before a single planned project gets touched. Reactive incidents. Emergency fixes. Undocumented one-offs. Interrupt-driven support. Work that arrived because something broke or someone asked, not because anyone planned it.
Call this the Capacity Tax.
JDE environments are particularly susceptible to it. EnterpriseOne is a deep, customizable platform — that’s its strength. But that same depth and customization flexibility creates surface area for things to break, for integrations to fail, for packages to misbehave, for users to generate support volume. JDE shops that have been on the platform for 10+ years often carry years of accumulated customizations, orphaned UBEs, and undocumented integrations. Each one is a potential interrupt.
Here’s what the math looks like in concrete terms.
Your team logs 160 hours of capacity per week on paper. But if you’re at the industry median — a 35–45% Capacity Tax — 56 to 72 of those hours are consumed by reactive, unplanned work before anyone opens a project plan. You’re not executing your roadmap against 160 hours. You’re executing it against 88–104 hours at best.
That’s why the roadmap slips. Not because the team is slow. Not because the requirements were wrong. But because the starting capacity was never what you thought it was. You’ve been planning a full load into a truck that’s already half full.
The Five JDE-Specific Capacity Drains
Not all unplanned work is equal. In JDE environments specifically, there are five recurring categories that consume the most capacity — and they’re worth naming precisely, because you’ve probably encountered all of them.
1. CNC Firefighting
Deployment engine failures. Package build errors. Server restarts. Environment refreshes that go sideways. CNC work in JDE is inherently reactive — when something breaks in the deployment layer, development stops. Users can’t be patched. Projects can’t move forward. Everything queues up behind the CNC issue.
Most JDE shops have one or two CNC people. When they’re in firefighting mode, their entire queue freezes. The capacity cost isn’t just the hours it takes to resolve the issue — it’s every hour of blocked work multiplied across everyone waiting on them. A four-hour CNC incident during a deployment window can easily represent 20+ hours of total organizational impact.
2. Orchestrator and Integration Failures
As JDE environments modernize with Orchestrator, the integration surface area grows. Every new orchestration connecting EnterpriseOne to a warehouse system, a third-party portal, or an EDI partner is another potential failure point. That’s not an argument against modernization — it’s just the math.
When an integration breaks at 6 AM before a shift starts, someone stops what they were doing to find and fix it. Multiply that across 10–20 active integrations, each with its own failure modes and dependencies, and the interrupt cost becomes significant. From what we’ve measured across JDE environments, orchestration and integration incidents are now one of the top three reactive work categories — a shift that has happened in the last three to four years as Orchestrator adoption has accelerated.
3. ESU and Tools Release Cycles
Electronic Software Updates and Tools Releases are not optional. Oracle releases them on a cadence, security and stability depend on staying reasonably current, and falling too far behind creates compounding risk. But here’s the pattern most teams fall into: ESUs and Tools Releases get treated as “extra” work layered on top of the normal workload.
They’re not extra. They’re predictable, recurring capacity consumers — weeks of testing, validation, deployment planning, and rollback preparation — that happen on a known schedule. When teams don’t plan for that capacity structurally, it lands as unplanned work, displacing whatever project was supposed to happen that quarter. Every time.
4. Functional Ticket Sprawl
This one is slower and harder to see. A user submits a request: “Can you add a field to this purchase order form?” Sounds like a two-hour task. But it turns into a requirements discussion, which surfaces a process gap that the field change would expose, which requires a design conversation, which needs sign-off from the business owner who’s on vacation. The original two-hour task becomes a 40-hour project.
This is ticket sprawl — the scope expansion that happens when work arrives without enough definition and grows through discovery. It’s common in JDE functional work because the platform’s configurability means the right answer is rarely obvious from the initial request. The underlying issue is usually intake quality, but the symptom is capacity consumed on work that takes five to twenty times longer than it should have.
5. Fuzzy Intake and Rework
Related to ticket sprawl but distinct: work that arrives so underspecified that the developer builds the wrong thing. The requester asks via email. Or in a hallway conversation. Or in a ServiceNow ticket that says “fix the report” without specifying which report, what’s wrong with it, or what the correct output should be.
The developer makes reasonable assumptions. They build something. It doesn’t match what the requester had in mind. Rework begins. From what we’ve measured across JDE environments, fuzzy intake drives 15–20% of all rework — work that gets done twice because it wasn’t specified correctly the first time. That’s pure waste. It’s not failure, it’s not incompetence — it’s structural, and it’s fixable.
How to Measure Your Own Capacity Tax
You don’t need a time-tracking overhaul or a consulting engagement to get a directional read on where you stand. You need your ticket data from the last 90 days and a few hours to analyze it.
Step 1: Categorize last quarter’s work.
Pull every ticket, service request, or work item closed in the last 90 days. Classify each one as either PLANNED or UNPLANNED.
- PLANNED: It was on a roadmap, a project plan, a scheduled maintenance window, or a release calendar before it started.
- UNPLANNED: It arrived as an incident, an urgent request, a reactive fix, or a surprise of any kind.
Don’t over-engineer the classification. If it surprised someone, it’s unplanned. The directional truth matters more than forensic precision.
Step 2: Calculate the ratio.
Unplanned hours ÷ total hours = your Capacity Tax.
If your tickets don’t have hours logged against them, use ticket count as a proxy. The ratio won’t be exact, but it will be directionally accurate enough to be useful.
Step 3: Benchmark yourself.
- Below 20% unplanned: You’re in the top 10% of IT organizations. Your team has structural capacity for strategic work, and the roadmap is probably moving.
- 20–35% unplanned: Healthy but constrained. You can execute the roadmap if you actively protect focus time from reactive interrupts.
- 35–45% unplanned: Industry median. Your roadmap is at risk. Strategic projects will consistently slip unless something changes structurally.
- Above 45% unplanned: Your team is in reactive survival mode. The roadmap isn’t slipping — it’s not being executed at all. Every quarter, planned work gets displaced.
Step 4: Find your top five repeat offenders.
Sort your unplanned work by frequency. Look for the issues that appear month after month — the same CNC failure mode, the same integration that breaks, the same report that crashes during month-end close.
These recurring incidents are your highest-leverage targets. An issue that consumes 8 hours each time it occurs and happens monthly costs 96 hours per year. Eliminating it at root cause — not just resolving it faster — permanently recovers those 96 hours for planned work. That’s more than two full weeks of one person’s capacity, year after year.
What Teams That Fix This Do Differently
This isn’t about best practices or framework adoption. It’s about a small number of structural choices that separate teams that consistently deliver their roadmap from teams that consistently don’t.
They measure the ratio. Capacity Tax gets tracked quarterly alongside other operational metrics — not because it’s a KPI someone mandated, but because it’s the leading indicator of roadmap delivery. When the ratio climbs, leadership knows before the roadmap slips.
They separate reactive and planned work structurally. Different queues. Different accountability. Someone is responsible for keeping the reactive queue contained while someone else is protected to work the roadmap. This doesn’t require more headcount — it requires explicit separation that most teams never formalize.
They fix repeat incidents at root cause. The instinct when something breaks repeatedly is to get faster at fixing it. The better instinct is to eliminate the failure mode. Resolving faster is a throughput improvement. Eliminating at root cause is a permanent capacity recovery.
They normalize intake. One channel for requests. A structured form or template that captures the minimum required information before work begins. Requirements defined before a developer opens an IDE. This alone materially reduces rework.
They protect focus time. Strategic work requires sustained attention — the kind that gets destroyed by constant interruption. Teams that deliver their roadmap treat focus time for project work with the same seriousness they treat production uptime. Not everyone is on-call. Not everyone is available for every interrupt.
None of these are complicated ideas. They’re hard to maintain because reactive pressure is constant and visible, while the long-term cost of not protecting capacity is invisible — until you run the numbers.
The capacity problem isn’t going to solve itself by working harder or adding headcount. It’s structural, it’s measurable, and the teams that diagnose it first are the ones that actually deliver the roadmap. Start with Step 1. Pull last quarter’s tickets, split them into planned and unplanned, and do the math. The data will tell you everything you need to know.
About the Author
John Mathieu is Managing Partner at Allari (allari.com), where he leads enterprise application capacity engineering for Fortune 500 and mid-market organizations. With 27+ years in enterprise IT operations, he works with CIOs and IT leaders to structurally eliminate the capacity constraints that slow ERP environments. He serves on the board of the Quest Oracle Community Southeast User Group (SERUG).
LinkedIn: linkedin.com/in/johnrichardmathieu