Why Your JDE Orchestrator Project Stalled
And how to unstall it.
Orchestrator is genuinely the most interesting thing to happen to JDE in years. It is the closest thing the platform has to a modern automation platform. Release 26 added conditional launch from form extensions, debugging enhancements, and the Enterprise Automation Dashboard.
38.4%
Reactive Load
10-15 hrs
Weekly Dev Time Needed
25-37%
Of Remaining Capacity
30+
R26 Features
And in most of the environments we work with, the Orchestrator project is stalled, deprioritized, or running at roughly 20% of what it could be. The feature is not the problem. The team's bandwidth is.
The feature isn't the problem. The team's bandwidth is.
Why Orchestrator Projects Stall
Building Orchestrator automations requires your most experienced people — the same people handling P1 production incidents, managing overnight batch jobs, running ESU regression testing, and fielding requests from the business.
Orchestrator work is strategic. When a 2 AM batch failure competes with Orchestrator development for a senior analyst's attention, the batch failure wins. Every time. The result is a series of small, individually reasonable decisions that collectively stall the project.
The Pattern We See Repeatedly
Phase 1 gets scoped with real enthusiasm. Two or three high-value automations are identified. Work starts. Then a production incident pulls the lead developer away. ESU testing absorbs the team. Quarter-end close needs all hands. By the time someone circles back, momentum is gone.
This is not a planning failure. It is a structural one. The team does not have protected time for strategic work.
What the Numbers Look Like
Reactive work consumes a median of 38.4% of available team time. Meaningful Orchestrator development requires 10 to 15 hours per week of focused time from a senior functional analyst. In a 40-hour week where 38.4% is already consumed, that is 25 to 37% of what remains.
The math is not the problem — the structure is. A team that cannot predict what next week will look like cannot commit to sustained development work.
Orchestrator is deflationary by nature: each automation eliminates future manual work. But you have to reach escape velocity first.
Two Structural Moves That Actually Work
First: reduce the reactive load before asking the team to carry the Orchestrator investment. If another team handles production incident response, your analysts recover 10 to 15 hours per week.
Second: sequence Orchestrator work so the earliest automations reduce the reactive load itself. Automate the batch job monitoring. Automate environment health verification. Each automation buys back time — which compounds as the next automations are built with recovered capacity.
This is the escape velocity problem. Orchestrator is deflationary by nature. But reaching that state requires sustained investment that most teams cannot make while carrying a full production support load. The teams that succeed almost always do it by offloading reactive work first.
Find out where your team stands.
See where your capacity is going.
Take the Executive Diagnostic →