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.
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. Not because it's glamorous, but because 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 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.
A paid Diagnostic first, where I look at how the work actually runs today and decide what's worth doing, including whether anything is. You get a written scope with pricing for whatever earns its place. 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 selected work →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.
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 the Diagnostic is where that gets pinned down honestly rather than guessed at.
Where to go next. 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. If the immediate pain is that the knowledge is walking out the door with somebody, that's the retiring machinist problem.
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.