Can we take this order for next November?

The client is a vertically integrated manufacturer that produces complex, high-value engineered systems for program-driven customers. They build nearly every component in-house, from machined metal parts and electronics to cable assemblies, sub-assemblies, and final products, through testing. The operation spans four distinct production cells, each with specialized equipment, unique routing logic, and timing dependencies that interact across the floor.

Their order book extends multiple years into the future, but their enterprise planning system only generated requirements three months out. When a customer asked, “Can you take this order for next November?” the planning team had no tool to answer the question. They had no way to check whether a new commitment fit against what was already scheduled, where capacity conflicts would emerge, or which departments would absorb the pressure.

The planning process lacked a middle layer. Plans were built manually and pushed directly into the live production system for testing. If the result showed overloads, the team would revert. But by the time they caught it, procurement, staffing, and supply chain teams had already seen the data and started making decisions based on a plan that might be pulled back within hours. Every planning cycle carried the risk that downstream decisions would be built on assumptions that remained untested.

The client had invested in enterprise systems, business intelligence, and experienced planners. None of that solved the fundamental problem: they could describe what the plan said, but they could not show what the plan would do.

That distinction matters. Enterprise planning tools are good at generating schedules, calculating requirements, and allocating resources against a set of inputs. Business intelligence is good at reporting what happened. But neither can run a production plan forward through time. Neither can show where queues build, which departments overload, when a timing cascade in one cell causes a downstream failure in another, or whether a schedule is robust enough to withstand the daily variability of every production floor. The client had spent heavily on tools that answered “what does the plan say?” and had nothing that answered “what will the plan do?” Those are fundamentally different questions, and the gap between them is where the real risk lives. Every time the team pushed a plan into the live system and then pulled it back, that gap showed up as wasted procurement cycles, reversed staffing decisions, and a loss of confidence in the planning process itself.

The gap had always existed, and for years it had been manageable. But the operation was reaching limits it had not hit before. Workload mix was shifting, and machines that had never been bottlenecks were becoming constraints. New capital equipment was replacing machines that had been in service for decades, and achieving a return on that investment required understanding how the new capacity would interact with existing workflows. The closer the plant ran to capacity, the less room there was to shuffle, and the more consequential every scheduling decision became.

Planners knew the limits intuitively. They could feel when a plan was fragile, but they had no way to demonstrate it. When leadership asked whether the plan would hold, the honest answer was “we think so,” backed by experience and judgment rather than evidence.

Outsourcing decisions, labor commitments, and delivery promises worth several million dollars were being made on that basis.

The client had even tried to solve this internally. An in-house expert built a simulation proof of concept that captured the basic logic of one production cell. The logic was sound, and the team could see the potential. But as the model grew, it hit scalability limits and run times climbed. The architecture could not support adding the remaining production cells without becoming unusable. They had seen enough to know simulation was the right approach, but they could not get there on their own.

SimWell framed the engagement around a planning decision, rather than a modeling exercise. The client's own proof of concept had already shown that simulation could represent the production floor. The question was whether a simulation-based planning environment could be built that was fast enough, scalable enough, and usable enough to change how planning decisions actually get made.

The work started with the least complex production cell, deliberately chosen because it allowed SimWell to establish the model architecture, data integration approach, and user interface on a scalable foundation. The early design decisions had to support the addition of more complex cells over time, including sub-assemblies, space constraints, and integrated testing, without rebuilding the core. That architectural thinking, knowing where to set the level of granularity so the model stays fast and scalable as complexity grows, was the gap the client's internal team had been unable to close.

The modeling process itself surfaced operational knowledge that had been invisible. SimWell's standard approach requires mapping every constraint, dependency, and handoff across the production system. In doing so, the team consistently uncovered interactions that even experienced internal staff had never fully recognized. Validation runs that produced unexpected results led to conversations that exposed hidden constraints, undocumented dependencies between departments, and assumptions embedded so deeply in the planning process that no one had thought to question them. The simulation had yet to reach its final form, and it was already changing how the client understood their own operation.

SimWell worked with the client's data team to create an abstraction layer that preserved the operational reality of the production floor without drowning the model in component-level detail. Raw data was too granular: individual projects could involve thousands of machined parts. The client built scripts to generate representative workloads from historical patterns, producing inputs at a level of detail that was meaningful to planners and sustainable for the model to process quickly. That collaboration required strong data literacy on both sides, and the client's understanding of their own data was unusually strong.

The planning environment was designed for planners, for use in real meetings on real timelines. The interface ran through a familiar spreadsheet layer where planners could load schedules, define scenarios, adjust parameters, and run simulations without touching the underlying model. SimWell built the output dashboards collaboratively with the planning team, replicating the data relationships planners were already accustomed to seeing rather than imposing a new reporting structure. The goal was a tool that fit into the team's existing workflow, one that required no change to how they already operated.

Speed was a hard constraint. The client needed results fast enough to use in a 30-minute planning meeting. When someone asked whether a schedule change was feasible, the simulation had to answer before the meeting ended. That requirement shaped every design decision: level of detail, run architecture, scenario setup, and output format.

SimWell delivered a simulation-based planning environment that was fast enough, scalable enough, and usable enough to change how the team makes production decisions.

What the engagement delivered:

• Full-horizon planning capability replacing a system that could only generate requirements three months out, giving the planning team evidence-based answers when customers asked whether a new commitment fit against existing schedules
• Protected planning environment with a simulation layer between planning and the live production system, eliminating the cycle of untested plans triggering premature procurement, staffing, and supply chain decisions
• Continuous delivery model that replaced the client's original plan for months-long testing pauses between stages, with SimWell delivering new capabilities while simultaneously supporting adoption and refinement of what was already in production
• Scalable model architecture designed to support adding remaining production cells without rebuilding the core, with additional stages already underway and further expansion in active discussion
• Daily use by the planning team, with scenarios tested in real time during scheduling meetings, and feasibility questions answered fast enough to support decisions within a 30-minute window