Guides / Where to start
Every manufacturer I talk to has the same two problems: they can't fill the roles they have open, and the work keeps coming anyway. This is about the second-best option, which is making the people you already have go further, and what to look for in whoever helps you do it.
You've got a position open. Maybe more than one. It's been open a while, the people you interviewed weren't right, and in the meantime the work is getting done by somebody covering two jobs. That's the actual situation in most operations your size, and it isn't going to resolve itself by posting the job again.
So the question stops being "who do I hire" and turns into "what can I stop asking a person to do." That's a different question with much better answers.
Before anybody builds anything, it's worth being honest about where the hours go. In most operations the answer is uncomfortable: a large share of a skilled person's week goes to work that produces nothing on its own. Re-typing a PO that arrived as a PDF. Chasing a vendor who never confirmed. Rebuilding the same report. Hunting for the file with the right revision on it. Answering where an order is, which means looking in two or three places and then writing an email.
The people doing it describe themselves as the glue holding the documents together, making the same update in three different files because nothing talks to anything else.
That's the thing to go after. It's dull work, and it's the part of the job that doesn't need the person you can't find. The judgment, the customer relationships, the call on a tricky feature, all of that needs your people. The double handling doesn't.
The work is dull and repetitive, which is exactly why it's hard to keep somebody in the seat. So you're competing for people to do the part of the job a machine should be doing, and losing them because of it.
Not the person. The typing.
Take the customer PO. The order lands in a shared mailbox. Something reads it, pulls out the part numbers, quantities, prices and dates, checks them against what was quoted, drafts the order in your system and flags anything that doesn't match. A person still looks at it before it commits, but they're checking a draft instead of building one from scratch.
Or the vendor acknowledgments. Every one gets read and compared to the PO line by line. A mismatch gets flagged as soon as it's found, and a morning email sums up where everything stands.
That's the shape of all of it. The machine does the reading, the comparing and the typing. The person does the deciding, and gets flagged only when there's something to decide about.
The honest answer is not "the biggest problem." It's the thing that happens the most times per week, because that's where a small fix compounds fastest and where you'll know quickly whether it worked.
Rather talk it through than read the rest? Email me. First call's on us. No cost, about 30 minutes, a straight conversation, not a demo.
The word consultant covers several different jobs in manufacturing, and they're worth telling apart before you go looking:
The reason that gap exists is worth understanding, because it explains why nobody has fixed it for you already. No software vendor owns the space between their product and somebody else's. Your ERP vendor's job stops at the edge of the ERP. Your accounting package's job stops at the edge of the books. The work that falls between them is where your people are spending their week, and it's nobody's product.
Worth keeping regardless of who you end up working with:
Sometimes the honest answer is that the fix is free and nobody makes money telling you so. A module you already own and never switched on. A report nobody wrote. A process that could just stop being done. I'd rather rule those out on the first call than sell you past them, and that restraint is the only reason it means anything when I do say something's worth building.
And sometimes you really do need to hire, and I'll say that too. If the gap is genuinely a person's judgment rather than their typing, no software fixes it.
Software also won't fix a process nobody agrees on. If three people do the same job three different ways, that has to be settled first. Automating a disagreement just makes it faster. And it needs your systems to let data out. Most do, some grudgingly. That's a real question, and I answer it honestly up front.
A paid half-day first, $2,500, at your place or over video. AI reads, drafts, and remembers what your people know. It is not exact, and it does not run your systems. So we go through the jobs eating your week and sort them: the reading, writing and know-how AI can genuinely help with, and the parts that need a tool built because the answer has to be right every time. Your people leave able to write skills themselves. A skill is your way of doing a job, written down so the AI follows it instead of guessing. Whether AI, a small build, or nothing at all is the honest answer, I'll say so. Written document within two working days. Then a Build quoted up front, so you know the number before it starts, with no hourly billing.
I build it, host it, and keep it running on managed infrastructure that works on top of the systems you already have, so nothing moves to a new platform. An ongoing care plan covers hosting, monitoring, fixes and small adjustments as your operation changes, with term and price by agreement. That's a real cost and I'd rather name it here than surprise you with it later.
A career in manufacturing, including a decade running a machine shop. Quoting, scheduling, purchasing, quality, month-end, the works. Most people offering this understand software or they understand your operation, rarely both, and the gap between the two is where these projects fail. The tools I've deployed sit exactly where the hours go: vendor PO confirmations, order intake, quoting support, and a morning brief that answers where things stand without anybody running a report.
See what I’ve shipped →No, and the AI setup level has no real floor at all. For anything built, the question isn't headcount, it's whether there's a specific recurring cost you can point at. One person spending a day a week on something is a real number, and you're already paying it, just not on an invoice.
Almost never, and I'd push back on anyone suggesting it as a first move. Your ERP stays the system of record. What I build reads from it, and writes back only where you specifically want that.
Both, in specific places. AI does the reading of anything messy and written by a human. Ordinary code does the comparing, the arithmetic and the writing into your system, because that part has to be right every time. The split matters enough that it has its own page: AI is a good reader, it's a bad accountant.
Usually you already know, and it's whichever one somebody complained about this week. If you'd rather have a structured read on it before talking to anyone, the AI readiness assessment walks you through your own operation and gives you a report at the end. It's free and nobody has to call you.
Not really. A developer builds what you specify. Most of the value here is in working out what's worth building in the first place, which is the part that needs somebody who has run an operation. Then it gets built, hosted and kept running, rather than handed over as a project that's finished.
The AI setup is quick, days rather than months, because nothing is being built. A build depends entirely on scope, and that gets pinned down honestly before a number is quoted rather than guessed at.
Where to go next. The specific gaps each have their own write-up: customer orders arriving as PDFs and getting keyed in by hand, vendor POs going out with nobody reading the acknowledgments, reports that the ERP won't produce, quotes that take too long to get out the door, and the know-how that is walking out the door with somebody, which is the retiring machinist problem. If you already know roughly what you want built, the useful read is how much of it actually needs building, because it's usually less than people expect.
Before you build any of it yourself, it's worth reading where drag-and-drop automation tools stop working, because some of this genuinely belongs in one and some of it very much doesn't. I'm based in Michigan and a fair amount of this work is with operations around West Michigan, though none of it needs me to be local.
First call's free. About 30 minutes, a straight conversation about how your operation really runs, not a demo. If there's something worth building, I'll say so; if there isn't, I'll say that too.