The situation
Growth exposed the work between the ERP and the decision.
Revenue was growing, but every increase in volume created more quoting, scheduling, and review work. The ERP held the transactions. The operating view still had to be assembled across spreadsheets, local knowledge, and follow-up conversations.
Important decisions depended on a few people who knew which release was actually shippable, why margin had moved, or which tooling signal deserved attention. The goal was not to replace that judgment. It was to give it a repeatable operating surface.
What the team did
They started with the work, not a generic app.
The team did not ask planners and operators to adapt to another fixed workflow. myai supplied the governed context and a place to build. The customer supplied the operating judgment. Each version was tested in the work and changed before it spread.
01
Make the source understandable
An ERP expert translated tables, definitions, and exceptions so the operating team could work from a shared view of the data.
02
Build inside the real workflow
Operational builders worked with planners and operators, tested each app against the job, and kept the judgment the team said mattered.
03
Carry the pattern forward
The first site brought working examples and experienced builders to the next site. The local team changed them around its own people, ERP, and process.
What changed in the work
Separate workarounds became one operating loop.
Scheduling shaped the daily call. Daily work fed the monthly review. Actual cost improved the next margin decision. Each tool started with context the others had already created.
Planning
ERP releases became a schedule the team could stand behind.
An ERP release entered with its customer date, quantity, value, job, and inventory coverage. The planner marked it Good, Maybe, or No based on what was actually buildable. The allocation logic recalculated the projected ship month immediately, leaving the team with a shared commit instead of another private spreadsheet.
Illustrative synthetic data
Daily management
The morning huddle carried trends, owners, and open actions forward.
The daily board joined safety, quality, delivery, and cost in one operating view. The team could see whether today was an isolated miss or part of a longer pattern.
Illustrative synthetic data
Monthly operating review
The operating view and the financial view finally reconciled.
The monthly review joined product-line performance, GL-based EBITDA, and cash conversion in one prepared surface. Leaders could see where an operating miss reached the P&L, then move from assembling numbers to deciding what to do.
Illustrative synthetic data
Margin analysis
Actual work improved the next operating decision.
Routed hours, actual hours, and job-level margin lived in the same view. Teams could see where the floor diverged from the standard and carry that evidence into the next quote and operating review.
Illustrative synthetic data
The handoff
The second site did not start from a blank screen.
Builders from the first site joined a focused Kaizen week at a sister operation. They brought working patterns and a shared way to read the systems, then walked the local work with the people responsible for it.
The second team changed the apps around its own ERP, people, and process. By the end of the week, the site team presented the tools they had shaped, what had changed, and what they wanted to improve next.
Results
Time was the first return. Capacity was the larger one.
Faster reviews, shorter release cycles, and narrower exception queues gave the same teams more room to operate and improve. At the first site, roughly 20 hours of weekly reporting work also moved into real-time apps and agents.
8 hours
15 minutes
Monthly operating review preparation
Measured at the first site
2 days
2 hours
Shop-order release cycle
Reported by the second site
358 signals
4 to review
Tooling demand triage
Validated system output
The roughly 20 hours of weekly reporting is the first site's own estimate, not a measured result. Growth and EBITDA impact remain outcomes being enabled, not measured results presented in this story.
What scaled
The next team inherited a stronger starting point.
What traveled was not a finished template. The second site inherited working applications, connected data patterns, and people who knew how to shape them. Its team could adapt the tools without discarding what the first site had learned.
That is the compounding effect: each use case leaves behind integrations, rules, and operational knowledge. The next app starts with more context, and the next site has more capability than the one before it.