AI production planning consulting, for a plant that already runs an ERP.
AI production planning consulting is the work of deciding which scheduling and capacity decisions in a plant should be handed to an algorithm, which should stay with the planner, and how to wire the first group of them into the ERP or MES that already holds the data. Most of the value is not in the model. It is in getting honest run times, changeover times and material availability into one place, then letting a solver sequence against the constraints your planner currently holds in his head. At a $15M to $150M plant this is a four to seven week build on top of your existing system, not a platform migration, and the first useful version usually runs in shadow mode next to the schedule you already publish.
Written for the owner, VP of Operations or plant manager who has been pitched AI scheduling three times this year and wants to know which parts are real, what has to be true in the plant before any of it works, and how to test it without betting the quarter.
The short answer.
Production planning at a mid-market plant is rarely broken because nobody knows how to schedule. It is broken because the schedule is built on numbers that are not true, and then re-broken four times a week by things nobody modelled: a hot order from the biggest customer, a late steel delivery, an operator out sick who was the only one certified on the press, a machine that ran at 70 percent of standard all shift and nobody logged why.
An optimizer does not fix any of that. What it does, once the inputs are honest, is search a far larger space of feasible sequences than a person can hold in mind, and do it again in ninety seconds every time the world changes. That is genuinely valuable and it is genuinely old technology. The newer part, the part where machine learning earns its place, is predicting the inputs: how long this job on this machine with this operator will actually take, how long this changeover will actually take given the previous part, how likely this supplier is to hit the promised date.
So the honest scope of an AI production planning engagement is usually three things in order. Measure what actually happens on the constrained resources. Learn the gap between your standards and reality. Then optimize against constraints that include the ones nobody wrote down. Skipping to step three is the failure mode, and it is the one most vendors will happily sell you.
If you want the wider frame before the detail, the manufacturing industry brief covers where AI investment tends to land first in a plant, and the maturity index gives you a baseline read on whether the data underneath your plan is ready.
The five things that actually break the schedule.
This is the problem an optimizer is genuinely good at, because a re-solve costs minutes instead of an afternoon. It is also the problem that exposes bad data fastest, because a machine will re-plan confidently on numbers a human would have quietly overridden.SequencingSolver work
Sequence-dependent setup is a well-understood optimization problem and it is often where the first real hours come back. The prerequisite is that somebody has measured actual changeover times by transition, not by part. Almost nobody has, which is why this is usually where a pilot starts.ChangeoverMeasure first
Supplier promise-date reliability is a prediction problem with a clean training set: your own purchase order history against your own receipts. Modelling it changes the plan from optimistic to probabilistic, and it is one of the few AI additions that shows up on the balance sheet as inventory rather than on the P and L as labour.MaterialsPrediction
Skills, certifications, shift patterns and cross-training model cleanly as constraints. The obstacle is organisational, not technical: the skills matrix lives in a spreadsheet that has not been accurate since the last hiring wave, and no one owns keeping it current.LabourConstraint
Any serious build has to end with the plan back inside the system everyone already uses, with the reasoning visible. A scheduling layer that produces a beautiful plan in its own interface has moved the spreadsheet, not removed it.AdoptionSystem of record
What can AI actually do for production planning in a plant this size?
Most of it is constraint optimization, and that is a compliment.
When a vendor says AI scheduling, the engine underneath is usually a constraint solver. You describe the world as variables and rules: these jobs, these routings, these work centres, these calendars, this operator cannot run two machines at once, this job cannot start before its material receipt, this customer date is hard and that one is soft. The solver searches for an assignment that satisfies every hard rule and scores well against the soft ones.
This is mature technology with open, credible implementations. Google publishes OR-Tools, whose CP-SAT solver ships job-shop scheduling examples. Timefold is the continuation of the OptaPlanner project and is open source. Gurobi, IBM CPLEX and Hexaly sell commercial solvers to the same problem class. None of this is new and none of it is a language model.
Calling it AI is not dishonest, it is just imprecise, and the imprecision matters when you are buying. A solver is deterministic and inspectable: you can ask why a job landed where it did and get a real answer in terms of the constraints. Ask that question of any tool you are evaluating. If the vendor cannot show you which constraint pushed a job, you are looking at a black box, and a black box does not survive contact with a floor supervisor who disagrees with it.
Where machine learning genuinely earns its keep.
The solver is only as good as the numbers you feed it. That is where learned models do real work, and it is the part most plants have never tried.
Run time prediction. Your routing says the operation takes 42 minutes. Your history says it takes 51 on the older machine, 38 on the newer one, and 64 when the material is from the second supplier. A model trained on your own completed job history predicts the actual, and the schedule stops being systematically optimistic.
Changeover time prediction. Sequence-dependent setup is the highest-leverage version of the same idea, because the ERP usually carries one flat number and the reality is a matrix.
Promise-date reliability. Supplier lead times in the system are contractual. Your receiving history is factual. Modelling the difference lets you plan against the probability of material arriving rather than the promise, which is the difference between a plan and a hope.
Scrap and yield. If a part family scraps at a predictable rate on a particular machine, the plan should size the run accordingly instead of discovering the shortfall at final inspection.
Lateness risk scoring. Not a schedule, a triage list. Which twelve of the four hundred open jobs are most likely to miss, ranked, every morning. This is the single easiest thing to ship and the easiest to evaluate, because the planner can tell you inside a week whether the list is any good.
Where large language models actually fit, and where they do not.
A language model should not be sequencing your plant. It has no concept of finite capacity and it will produce a fluent, plausible, infeasible schedule. Anyone demonstrating a chatbot that writes your production plan is demonstrating a category error.
Where language models do earn a place is at the edges of the planning process, on the unstructured material that never makes it into the ERP:
Reading what arrives as text. Customer schedule changes over email, supplier delay notices, EDI exceptions that need a human read, engineering change notes. Extracting the structured fact out of that and putting it in front of the planner is real work that currently eats mornings.
Explaining the plan. A solver output is a Gantt chart. A supervisor asks why job 44812 moved to Thursday. Generating a plain-language explanation grounded in the actual binding constraints is the difference between a schedule people follow and a schedule people work around.
Exception triage. Routing the twenty things that broke overnight to the right person with the right context, rather than into one queue that the planner drains by hand.
Notice that all three are about getting information to a human faster. That is where the technology is reliable today. Our own measured experience is in exactly that register: across clients we have handled at least 6,000 live calls with commissioned voice agents, including 3,787 calls and 5,514 minutes for one named client, and a regional third-party logistics and warehousing operator running 211 calls through the same pattern. That work is intake and triage, not sequencing, and we would rather say so plainly than imply the two are the same thing.
What is marketing.
The autonomous or self-healing factory. No mid-market plant is running an unsupervised scheduler, and the ones claiming to are running an optimizer with a planner who approves every publish. That is the correct architecture. It is just not autonomous, and the word is doing sales work.
Digital twin, on a plant with no instrumentation. A twin is a simulation fed by live data. If the live data is a clipboard, you do not have a twin, you have a drawing. Simulation is genuinely useful for capacity questions and line balancing, and tools like Simio are built for it, but the prerequisite is measurement.
Percentage improvements in the deck. Every vendor in this category will show you a double-digit improvement in on-time delivery or utilization. Ask which customer, at what revenue, with what product mix, and what the baseline measurement method was. The number is usually real for somebody and irrelevant to you. We do not publish a scheduling percentage on this page for the same reason.
AI that replaces the planner. It does not, and you should not want it to. The planner is the person who knows that this customer's dates are soft and that one's are not. What changes is that the planner stops rebuilding spreadsheets and starts adjudicating exceptions, which is the part of the job that needed a human.
The tools that actually exist, assessed fairly.
Verify current pricing, packaging and integration scope with each vendor directly. This category announces capability well ahead of general availability, and anything written down goes stale fast.
Your ERP vendor's own APS module. Check this first, always. Acumatica, Epicor, Infor and SAP all sell advanced planning and scheduling as part of or alongside the manufacturing suite. The integration is already done, the data model already matches, and the licence is usually the cheapest option on the table. If your shop fits the standard model reasonably well, buying here and stopping is a completely respectable outcome. We say so on calls regularly.
Dedicated mid-market APS. PlanetTogether and Simio both position at a scale a mid-market plant can actually reach and both integrate with common ERPs. Simio leans toward simulation as well as scheduling, which matters if your real question is capacity rather than sequence. Siemens sells Opcenter APS, the lineage of the former Preactor product, and Dassault sells DELMIA scheduling. Both are capable and both bring an enterprise implementation motion with them.
Enterprise supply chain planning. Kinaxis, Blue Yonder, o9 and RELEX are serious products solving a real problem, and they are built for companies that employ a supply chain planning department. Below roughly $150M in revenue the licence plus the implementation partner usually costs more than the problem is worth. C3 AI markets a production schedule optimization application aimed at large industrials. Ask any of them for a reference customer at your revenue and your product mix before the second meeting.
The measurement layer. MachineMetrics, Amper and Tulip solve the problem of knowing what your machines actually did. MPDV and Plex sit in the MES layer. None of these are planning tools, but for a plant with no reliable actuals, one of them is usually the correct first purchase, ahead of anything with AI in the name.
The small end. Katana and MRPeasy are built around inventory and light MRP for small manufacturers, and both market themselves that way. Neither is a finite-capacity scheduling engine. If you are a $40M plant with a real sequencing problem and one of these is on the shortlist, the shortlist is wrong.
Where a commission beats all of the above is narrow and worth stating precisely: when the constraints that decide your schedule are ones no product will encode, and when the plan has to land inside a system you already run rather than in a new interface. That is the same test we apply in off-the-shelf AI versus a custom commission.
How it wires into the ERP or MES you already run.
Where the data you need actually lives.
A scheduling layer needs six categories of input, and in a typical mid-market plant they are spread across three or four systems plus a spreadsheet.
From the ERP. Open orders and due dates, routings and operations, work centres and resource groups, bills of material, purchase orders and expected receipts, on-hand and allocated inventory, plant and shift calendars.
From the MES or machine layer. Actual start and stop by operation, downtime and reason codes, scrap counts, and machine signal data where it exists. MTConnect and OPC UA are the standards you will hear named; if the equipment predates them, a bolt-on sensor layer is the usual answer.
From nowhere in particular. The skills matrix, the sequence-dependent changeover knowledge, the customer-by-customer flexibility rules, the maintenance windows that are informally observed. This is the material that lives in people and spreadsheets. Extracting it is half the diagnosis work and it is the half that determines whether the build is worth doing.
The read-and-suggest pattern, and why we default to it.
The AI layer reads structured records out of the ERP, runs the workflow it was commissioned to run, and writes back a suggested plan that a planner approves inside the system he already uses. The ERP stays the system of record. Nothing is published to the floor without a human release.
This is not caution for its own sake. A schedule that publishes itself and gets one thing badly wrong burns the credibility of the whole project on the floor, and floor credibility is the asset the project actually runs on. Once the planner has watched the suggestions hold for sixty to ninety days, the review step relaxes to spot-checking the exceptions. That sequence is not negotiable in our engagements and it is the same discipline described in how to run an AI pilot that produces a decision.
Three integration levels, in plain language.
API layer. Read and write through the documented endpoints. Epicor Kinetic exposes a REST API and the BAQ layer, which is faster than reading table by table; we cover that specific stack in the Epicor Kinetic playbook. Infor CloudSuite Industrial, Microsoft Dynamics 365 Supply Chain Management, Acumatica, NetSuite and SAP all expose comparable layers. This is the cleanest and most maintainable option and it is where we start.
Event or webhook layer. Subscribe to changes so the schedule re-solves when something moves rather than on a nightly batch. This is what makes churn tractable, because the value of a fast re-solve only shows up if it fires when reality changes.
Database layer. A direct read against the underlying database where the API does not expose what the plan needs. Brittle, requires hosting access, used as a last resort and only with the operator's explicit approval in writing.
The data-quality gate, which is where most of these projects actually die.
Routings lie. Not maliciously; they were set during the ERP implementation years ago, by someone estimating, and the parts and the machines and the people have all changed since. If your standard times are systematically 20 percent off, an optimizer produces a schedule that is precisely, confidently wrong, and the floor learns to ignore it inside two weeks. After that you cannot get it back without a change of leadership on the project.
The gate we apply before scoping any scheduling build is simple. Take the constrained resource group. Pull the last ninety days of completed operations. Compare actual elapsed time against the routing standard. If the distribution is tight, the optimization is worth doing now. If it is wide and there is no pattern in it, the first engagement is measurement, not scheduling, and we will say that rather than take the build.
This is the same readiness question covered more generally in data readiness for mid-market AI. In a plant it has a specific and cheap test, which is the one above.
What we can prove, and what we cannot.
We would rather be narrow and checkable than broad and impressive, so here is the actual position.
The client we can name is Jim Glaser Law, where five channel-specific commissioned voice agents covering paid search, organic, television, Meta and local services ads have handled 3,787 calls and 5,514 minutes, giving the firm per-channel attribution on answered calls. Jimmy will take a reference call. Anonymized, the same pattern runs at a multi-location home services operator (1,486 calls, 2,203 minutes), a regional third-party logistics and warehousing operator (211 calls) and a realty firm (148 calls). A 47-attorney litigation firm runs its matter, invoice and trust accounting operation on a platform we commissioned, currently holding 13,296 matters, 4,396 clients and 5,684 invoices, with trust reconciled byte-identical. Two marketing agencies outsource their AI fulfilment to us.
None of those is a production schedule. What they demonstrate is the thing that actually decides whether a plant build succeeds: systems that run in production against real operational data, with an audit trail, owned by the operator at handoff. If you want a named manufacturing scheduling reference before you commission, we do not have one to give you today, and we will tell you that on the first call rather than at the third meeting. What we will offer instead is a prototype against your own data inside seven to ten days, before the main fee is committed, so the evidence you evaluate is your plant rather than someone else's.
ColabContent LLC has been operating since 2020 and has run the AI practice since 2024, out of Boston. More on how commissions are structured is on the process page and in build, buy or commission.
Scoping a pilot that produces a decision in weeks.
If you cannot name the constraint in one sentence, that is your first finding, and it is worth knowing before you spend anything.Week 0Scope
Utilization is a trap. You can raise utilization and ship less. If a vendor leads with it, ask what happened to on-time delivery in the same period.Week 0Measurement
That list of overrides is the most valuable output of the entire pilot. It is the constraint documentation your plant has never had, and it is what turns a generic optimizer into a model of your shop.Weeks 1-3Shadow
All three are useful outcomes. A pilot where no is not a permitted answer is a procurement exercise wearing a lab coat.Week 4Decision
Our own commissions follow the same shape. A prototype runs against your real data inside seven to ten days, the production build lands in four to seven weeks depending on integration depth, and the fee is fixed and stated before the build in the $45,000 to $180,000 band. You own the code, the prompts, the model selection and the data pipeline at handoff, with no retained licence and no dependency on us. The detail sits on what AI consulting costs for a manufacturer, and the evaluation criteria to hold any vendor to, including us, are in how to choose an AI consultant for specialty manufacturers.
Frequently Asked Questions
Can AI actually do production scheduling, or is it advanced planning and scheduling software with a new label?
Both things are real and they are not the same. Most of what gets sold as AI scheduling is constraint optimization, which is decades old and very good; the solver searches an enormous space of possible sequences against your rules and returns a feasible plan. Machine learning adds something different, which is better inputs to that solver, such as a predicted run time or changeover time based on what actually happened on your floor rather than the standard sitting in the routing. A serious build usually uses both, and a vendor who cannot tell you which part is which is selling you a label.
What is the difference between buying APS software and commissioning a custom production scheduling layer?
APS software gives you a mature scheduling engine and a planning board, and it expects your plant to fit its model of a plant. A commissioned layer starts from your constraints instead, including the ones no product will ever encode, such as which two operators can run the five-axis cell or which customer never accepts a partial shipment. Buy the product first if your shop is close to the standard model. Commission when the exceptions are the business.
Do we need an MES before AI can help with production planning?
No, but you need something that records what actually happened. If run times, downtime and scrap exist only as paper travellers and the memory of your lead hand, an optimizer has nothing honest to learn from and no way to tell you it is wrong. A lightweight machine-data layer, or even disciplined clock-in data on the constrained cells, is often enough to start, and it costs a fraction of a full MES rollout.
How much does AI production planning consulting cost for a mid-market plant?
Our commissions are fixed fee, stated before the build starts, in the $45,000 to $180,000 band depending on integration depth and how many workflows are in scope. A single scheduling workflow sits at the low end of that range. Buying an APS product instead is a recurring licence plus an implementation partner, and for a plant that fits the standard model that is often the cheaper correct answer, which we will say out loud on the call.
How long before a production scheduling pilot proves anything?
Two to four weeks, if you scope it to one bottleneck resource group and agree the measurement before anyone writes code. Run the model in shadow mode against the schedule your planner already published, compare the two on the one metric you chose, and let the planner overrule it freely the whole time. A pilot that cannot be judged inside a month is not a pilot, it is a project with a friendlier name.
Will an AI scheduler work if our routings and standard times are inaccurate?
Not on day one, and this is the most common reason these projects fail quietly. An optimizer takes your standards literally and hands back a confident, precise, wrong schedule that the floor stops trusting inside two weeks. The fix is to measure actual cycle and changeover times on the constrained resources first, then let the model learn the gap between standard and actual instead of pretending the standard is true.
Which AI production scheduling software is best for a plant doing $15M to $150M?
There is no single answer, but the shortlist is narrower than the marketing suggests. If your ERP vendor sells an APS module, price that first, because the integration is already done. PlanetTogether and Simio are reachable at mid-market scale and integrate with common ERPs. Kinaxis, Blue Yonder, o9, RELEX and the SAP planning products are built for companies that employ a planning department, and at this size the licence plus partner usually costs more than the problem. Ask any vendor for a reference customer with your revenue and your product mix before the second meeting.
Can AI handle labour and skills constraints, not just machines?
Yes, and at most mid-market plants labour is the binding constraint more often than equipment is. Skills matrices, shift patterns, certifications and cross-training all model cleanly as constraints inside the same solver that sequences the machines. The hard part is not the mathematics. It is that the skills matrix usually lives in a spreadsheet that has not been accurate since the last hiring wave, and nobody owns it.
What should we do first if we have never run an AI project in the plant?
Pick the one resource group that decides whether the week ships, and instrument it. Measure actual run time, changeover time and downtime on that group for a month. That single dataset tells you whether your planning problem is really a scheduling problem, a materials problem or a maintenance problem, and it is the input every subsequent build needs anyway. It is also the cheapest way to find out that you do not need AI at all.
Book the 45-minute diagnosis.
Bring one constrained resource group and ninety days of completed operations. We will tell you on the call whether your problem is scheduling, materials or measurement, including when the answer is that you should buy your ERP vendor's APS module and stop.
Where to look next.
If you are still deciding whether the problem is worth a build at all, start with AI consulting for manufacturers for the wider view of where AI investment lands first in a plant, and AI for specialty manufacturing if your work is make-to-order rather than repeat production. The manufacturer calculator puts a number against quoting and throughput leakage in a few minutes.
If you are shortlisting vendors, the AI consultants for specialty manufacturers guide and how to choose an AI consultant for manufacturers give you the questions to ask, and the manufacturing cost page sets expectations on the number before you take a meeting. The manufacturing AI benchmark covers where plants in this band actually are.
If the sticking point is build versus buy, read build, buy or commission and off-the-shelf AI versus a custom commission. If a previous attempt already stalled, why mid-market AI rollouts stall in month four describes the failure pattern in enough detail to recognise it early, and what to do after a failed AI pilot covers the recovery.
For the stack-specific version of this material, the Epicor Kinetic AI playbook is the closest thing on this site to a wiring diagram, and workflow automation covers the adjacent processes that usually get scoped in the same engagement.