Subject workflows · Updated 17 September 2026
How to Study Operations Management With AI (Safely)
This looks like a formula course, and a chatbot will happily produce the formulas. The subject underneath them is variability — and an answer built from averages alone is not a slightly rough answer. It is an answer to a different question.
Before any number gets computed, decide one thing yourself: is this problem deterministic or stochastic? That single choice picks the formula, and nothing in the figures you were given will announce it. The one published evaluation of ChatGPT on operations management coursework found it did fine overall and struggled specifically on the stochastic questions. So keep the modelling on your side of the desk, and push across the two jobs a machine does honestly — the arithmetic, and the sensitivity tables that show how much your answer depends on a number you guessed.
The evidence points at one half of the syllabus
Most subjects have no measurement of how AI performs on their specific coursework. This one does. Yaojie Li and Johnny Ho, writing in the International Journal of Services and Standards in 2024, took operations management problems and sorted them two ways at once: by Bloom's taxonomy, and into quantitative versus qualitative and deterministic versus stochastic groups. Their finding, verbatim: ChatGPT "generally performed well but struggled with Bloom's 'applying' and stochastic questions, suggesting its limitations in higher-order cognitive tasks."
Read that as a map. The weak cells are not scattered at random — they are the two axes your exam is built on. "Applying" means fitting a model you have seen to a situation you have not. "Stochastic" means everything downstream of the world being random: waiting lines, safety stock, the newsvendor problem, forecast error. The strong cells are definitions and plug-in deterministic sums, which are also the parts that feel like the course when you are revising.
One caveat, and it cuts the honest way: that study tested an earlier model generation, and raw arithmetic in particular has improved a great deal since. Read it as a description of where the difficulty lives — a property of the subject rather than of any model version.
Averages cannot answer a waiting-line question
Here is the structural reason, and it is the single most useful idea in the course. In 1961 John Kingman published an approximation for the average wait in a single-server queue, and it is essentially three things multiplied together: how busy the resource is, how variable the arrivals and the service times are, and how long a job takes to serve.
Look at what that means for a student holding a homework problem. If all you were given is an average arrival rate and an average service time, you have none of the middle term. Variability is not a refinement you add later for accuracy; it is one of the three factors, and it is missing. A chatbot handed those two averages will not stop to say so. It will reach for a formula that accepts two averages — usually the textbook M/M/1 case, which quietly assumes a very specific kind of randomness — and return a clean number.
The busyness term is the other half of the surprise. It is utilization divided by one minus utilization, so it climbs like this:
- 80% busy: a factor of 4
- 90% busy: a factor of 9
- 95% busy: a factor of 19
Five percentage points of extra utilization, and the expected wait roughly doubles. "Run the machine as close to full as possible" is the intuition this course exists to break, and an answer that treats utilization as something to maximise has usually missed the question.
One formula forgives you, the other does not
The judgement this course is really testing is knowing where precision pays, and it is not uniform. Two formulas from the same syllabus behave in opposite ways.
The economic order quantity is famously forgiving. In his ETH Zurich course material Integral Logistics Management, Paul Schönsleben puts it plainly: "The total costs curve … is very flat in the region of the minimum, so that deviations from the optimum batch size have only a very small effect on costs." Order 64% of the optimal quantity, or 156% of it, and either way total cost rises by only about 10% — "the surprising robustness of the calculation technique, which indeed rests on very simplified assumptions."
So a sloppy demand estimate barely dents an EOQ answer, while five points of utilization transforms a queuing answer. Same course, opposite sensitivity. A chatbot will carry every figure to two decimal places in both cases, because it has no view about which decimals matter. You need one, and forming it is most of what "applying" means.
Little's Law is the one check you get for free
Almost nothing in a stochastic problem can be verified by substitution — which is what makes this course harder to self-check than, say, differential equations, where you can plug a solution back in and settle it. Operations management gives you one exception, and it is worth building a habit around.
Little's Law says the average number of items in a system equals the average arrival rate multiplied by the average time an item spends there: L = λW. Writing on its fiftieth anniversary in Operations Research, John Little described what makes it unusual: "when you draw the picture you don't really seem to need any detailed assumptions about interarrival times, service times, number of servers, order of service, and all the other ingredients that go into the standard queueing models." It holds whether the queue is first-in-first-out, last-in-first-out, random or by priority.
That distribution-free quality is what turns it into an audit tool. Any solution reporting work in progress, a throughput rate and a flow time is making three claims that must reconcile — and if they do not, it is wrong, which you now know without knowing the right answer or trusting whoever produced it. Two cautions. Units are where the check fails in practice: a rate per hour against a time in days will never reconcile, and the mismatch reads like a maths error. And it is one-directional — failing it proves a solution wrong, passing it does not prove one right.
The gap is building the model, not solving it
Evidence from the adjacent field sharpens where to aim your effort. The ORQA benchmark, presented at AAAI in 2025 by Mahdi Mostajabdaveh and colleagues, was built by operations research experts from 1,513 questions across 20 application domains. Crucially, they chose "to focus on translating textual problem descriptions into mathematical optimization models rather than directly solving optimization problems" — that is, on formulation. The best model reached 77.2%, against 93% for human experts on a sample of the same questions.
Two scope caveats: they tested open-source models available in late 2024, not the frontier tools in your browser, and optimization modelling neighbours your course rather than being it. But it lines up with Li and Ho's "applying" result from a completely different direction, and the practical reading is the same. Turning a paragraph of description into the right mathematical object is the hard part, the graded part, and the part to keep.
Split the job
| Task | Who does it | Why |
|---|---|---|
| Decide whether the problem is deterministic or stochastic | You, first, always | It picks the formula, and the data will not tell you |
| State the system boundary and the assumptions | You | The "applying" step, measured as the weak one twice over |
| Capacity, bottleneck and cycle-time arithmetic | The chatbot, checked | Deterministic and mechanical — the strong cell |
| Catch rate-versus-time and unit errors | The chatbot, as auditor | Checkable against the units alone, not against judgement |
| Decide how precise an input needs to be | You | EOQ forgives a bad estimate; utilization does not |
| Produce a sensitivity table across a range of inputs | The chatbot, running code | Shows you the shape of the curve instead of asserting it |
The workflow, step by step
Four prompts for ChatGPT, Claude, Gemini or whatever you already use. Each keeps the modelling on your side and pushes only checkable work across.
1. Force the deterministic-or-stochastic decision to be yours. No formulas yet.
You are my operations management coach. Here is a problem:
[paste the problem]
Do NOT name a formula, do NOT classify the problem, and do NOT
calculate anything.
Ask me one question at a time, waiting for my answer each time:
1. List every quantity the problem gives me. For each one, is it
a certainty or an average of something that varies?
2. Does the problem give me ANY measure of variability - a
standard deviation, a range, a distribution? Which ones?
3. If something varies and I was given no measure of its
variability, what am I being forced to assume?
4. Where exactly is the boundary of the system being analysed -
what is inside it and what is outside?
If I answer wrongly, say only that it is wrong and ask again a
different way. Do not correct me and do not hint at the answer.
Question 3 does the work. Saying out loud "I am assuming exponential service times because nothing else was given" is a different mental act from having a model assume it silently for you.
2. Audit the units before anything else. This catches the most common mechanical error in the course.
Here is my working for an operations problem:
[paste your working]
Do NOT check whether my answer is right and do NOT solve anything.
Check units only:
- For every quantity, state its units (items, items per hour,
hours per item, etc).
- Flag every place I may have confused a RATE with a TIME, or
used a capacity where a cycle time belongs, or mixed time
bases (per hour against per shift or per day).
- Tell me which quantities would have to be converted for all my
equations to be dimensionally consistent.
List the problems. Do not fix them for me.
3. Run Little's Law against a solution's own numbers. Works on a worked example, a model's output, or your own draft.
Here is a worked solution to a process-flow problem:
[paste the full solution]
Using ONLY the numbers this solution states, and no outside
knowledge:
1. Identify its value for work in progress (L), throughput rate
(lambda) and flow time (W), converting to consistent units and
showing that conversion.
2. Compute lambda x W and compare it with L. Report both numbers
and the percentage difference.
3. If they disagree, say so plainly. Do not guess which of the
three figures is the wrong one.
4. List every step the solution asserts but never shows.
Do not tell me whether the overall answer is correct.
4. Make it show you the curve rather than tell you about it. This is the prompt that builds the intuition the exam is testing.
Actually execute code for this - do not estimate.
For my problem [paste the parameters], produce two tables:
A. Recompute total cost for order quantities at 50%, 64%, 80%,
100%, 125%, 156% and 200% of the EOQ, showing the percentage
cost penalty at each.
B. Recompute average queue length and average wait at utilization
of 0.5, 0.7, 0.8, 0.9, 0.95 and 0.98, holding everything else
fixed.
Show me the code you ran and its raw output. State which formula
you used for each table and what it assumes. If you cannot execute
code in this chat, say so and stop - do not produce the tables
from memory.
The last instruction matters: a table produced from recall looks identical to a computed one, and the point here is to see the real shape of both curves with your own parameters in them.
Where the line is
The split above sits comfortably inside most academic integrity policies, and the FAQ below covers the ordinary cases. The risk specific to this course is that the graded output is a justified model rather than a number, so an analysis you did not build is unusually hard to defend when someone asks where you put the system boundary. Read your syllabus, and if the wording is vague, our guide to homework help without cheating and the class AI policy checklist cover how to read it and how to ask in writing.
Related reading
- The rest of the business core. Managerial accounting, where the trap is a missing figure rather than a missing distribution, and business case study analysis.
- The maths underneath. Linear programming and the simplex method for the constrained-resource half, and probability and Bayes' theorem for the randomness half.
- Forecasting and data. College statistics and hypothesis testing, where the same "averages are not the whole story" lesson shows up again.
- Queues in another department. Operating systems process scheduling uses the same utilization and throughput ideas on CPUs.
- How the same tool fails elsewhere. Thermodynamics, where accuracy is the trap, and the hallucination checklist.
- A free second textbook. MIT Sloan publishes its whole introductory operations management course, 15.761, on OpenCourseWare under a Creative Commons licence. When your notes are thin, a full second treatment costs nothing and invents nothing.
FAQ
Can I just paste my operations management homework into a chatbot?
You can, and on a capacity or bottleneck question the answer will usually be right. The risk is on waiting-line, safety-stock and forecasting questions, where the model has to decide whether randomness matters before it picks a formula — and the one published evaluation of ChatGPT on operations management coursework found stochastic questions were exactly where it struggled. Make that decision yourself, write down which quantities are averages and which are certain, and only then hand over the arithmetic. Check your syllabus before pasting anything.
Is AI actually bad at operations management?
Not uniformly, and the pattern matters more than a score. Li and Ho sorted operations management questions by Bloom's taxonomy and by deterministic versus stochastic, and reported that ChatGPT "generally performed well but struggled with Bloom's 'applying' and stochastic questions." So it is strongest on definitions and on plug-in deterministic sums, and weakest on the two things your exam is built from: applying a model to a new situation, and reasoning about randomness. That study tested an earlier model generation, so treat it as a map of where to be careful rather than a current score.
What is the fastest way to check an AI answer to a process-flow question?
Run Little's Law on the answer's own numbers. If a solution reports inventory or work in progress (L), a throughput rate (λ) and a flow time (W), then L must equal λ times W. It is the rare check that needs no assumptions about arrival patterns, service times or number of servers, so it works on any answer from any source. Watch the units: a rate per hour multiplied by a time in days will not reconcile. A solution that fails the check is definitely wrong, though passing it does not make a solution right.
My course says high utilization is good, but the queuing formula punishes it. Which is right?
Both, and the tension is the lesson rather than a contradiction. High utilization is efficient use of an expensive resource; it also lengthens every queue feeding that resource, and it does so non-linearly. In Kingman's approximation the utilization term is ρ divided by one minus ρ, which is 4 at 80 percent busy, 9 at 90 percent and 19 at 95 percent. So the last few points of utilization are bought with a large increase in waiting. The exam answer is almost never "maximise utilization" — it is naming the trade-off and saying which side the case in front of you should fall on.
Is it cheating to use AI for operations management homework?
That depends on your course policy, and this subject carries one risk worth naming. The graded step here is choosing and justifying a model, and a model you did not choose is very hard to defend when an instructor asks why you assumed Poisson arrivals or where you drew the system boundary. Being quizzed on assumptions, having your formula choice challenged, or asking for a sensitivity table is ordinary studying. Read your syllabus, and ask your instructor in writing if the wording is unclear.
Bottom line
The formulas are the easy part of this course, and a chatbot will hand them over on request. What it cannot hand you is the decision that comes first — whether the thing in front of you is certain or random — because that decision is not in the data, and getting it wrong produces a confident answer to a question nobody asked. Make the call on paper. Run Little's Law on whatever comes back. Then spend your precision where it buys something, which is nowhere near the EOQ and everywhere near a resource running at 95%.