Most MES programs we walk into have a detailed plan for the implementation and almost nothing written down about the day after. The project team demobilizes, the integrator's hours taper off, and the site discovers that a dozen responsibilities nobody ever named are now everybody's problem. Nothing fails dramatically. Things just get slower, tickets sit longer, and the workarounds start piling up.

The fix isn't complicated, but it has to happen early. Before you write a single job posting, figure out what your organization actually has to own. Headcount comes after that, not before.

Four capabilities, not four job postings

Running an MES after go-live takes four distinct capabilities. Whether that turns into four people, two people, or six depends on your site count, your process complexity, and what you've promised your operations team for support coverage.

Tier 1 support handles first response and triage: can't log in, can't open the client, needs a permission change, scanner won't read. Tier 1 doesn't need to know MES deeply, but it does need to scope the impact, capture evidence, and escalate with enough detail that the next person isn't starting from zero. At most companies this is an assignment to an existing help desk rather than a new hire.

The site functional owner is the bridge between the plant floor and the MES organization. They own governed master data, they diagnose the transaction that works technically but doesn't match how the process actually runs, they coach users, and they turn "we need another button" into a real requirement. In our experience this is the single most under-resourced role after go-live, and it's the one that quietly determines whether people trust the system.

The technical engineer covers Tier 3: application defects, extensions, integrations, performance, environments, and deployments. You can staff this internally, contract it, or split it, and all three are legitimate answers depending on how much change your program generates.

The enterprise product owner carries roadmap, governance, backlog, funding, and vendor management. This one becomes essential the moment a second site enters scope, because that's when competing site priorities start showing up and somebody has to decide between them.

One thing worth saying plainly, since the numbering invites the wrong reading: tier describes the nature of the issue and the escalation path, not organizational seniority. A Tier 2 functional owner is very often the most valuable person in the room.

The unicorn requisition

We see this posting a lot. Deep manufacturing and process expertise, platform expertise in your specific MES, professional software development, IT infrastructure troubleshooting, product ownership and prioritization, and executive-level communication. One person, available locally, starting next month.

That person exists in roughly the quantity you'd expect. The requisition sits open for eight months, the salary creeps up, and you end up compromising anyway, usually on the capability you needed most.

The alternative is to split the roles before you write any descriptions, decide which capabilities genuinely have to live inside your organization, and then hire for manufacturing aptitude and learning agility. Specific platform experience belongs under "highly desirable," not "required."

A useful test for any job description: everything under Required should be something you'd reject an otherwise strong candidate over. If it isn't, move it down the page. And if a responsibility shows up in three different role descriptions, it doesn't belong to three people. Pick one.

Don't screen on the platform name

Prior experience with your exact MES platform is genuinely valuable, and requiring it shrinks your candidate pool dramatically for very little return.

Experience on other configurable, extensible MOM platforms tends to transfer well, because the habits are the same: production modeling, workflow, extension, integration, and supporting live users under pressure. What matters is what the candidate actually did with it. Did they administer security, or configure the production model? Write business rules, or build integrations? Troubleshoot a live production issue at 2am, or read about one afterward?

One caution here. Experience limited to heavily recipe-driven electronic batch record environments is valuable for regulated process knowledge, but it doesn't automatically demonstrate the development and extensibility skills a highly configurable platform needs. Evaluate the demonstrated capability instead of assuming equivalence because someone knows MES.

Hire ownership, contract capacity

Functional ownership and product ownership are hard to outsource without quietly losing control of your own system. Those decisions compound. Get them wrong for two years and you'll be living with the results for five.

Technical capacity is a different question. It's genuinely contractable, and during implementation an integrator is usually the faster and more flexible source of it. That isn't a permanent arrangement or an admission of failure. As the work changes shape, the sourcing should change with it. Implementation work is large, spiky, and platform-specialized, which suits an outside team well. Steady-state work is smaller, continuous, and tied closely to your process, which is exactly the point where internal sourcing starts to pay off.

So if you can only fund one or two positions before go-live, fund the site functional owner, and add the enterprise product owner once a second site is in scope. Hire them late and someone else will have made the decisions you're going to live with.

Interview for judgment, not trivia

Product trivia tells you very little. Scenarios tell you almost everything.

For a functional owner, try this: "Production asks you to add a new button to an MES screen. What do you ask before that becomes a requirement?" You're listening for whether they investigate the underlying problem or simply pass the request downstream. Most of the time the right answer isn't a software change at all. It's training, master data, a configuration setting, existing functionality nobody found, or a process that should change instead.

For a technical engineer: "A requirement can be met with configuration, low-code, custom code, or an integration. How do you decide?" Listen for supportability, upgrade impact, and who owns the result afterward.

For a product owner: "Tell me about a time you said no to an important stakeholder." Listen for whether the relationship survived it.

Then give your finalists something real to do. Handing a functional owner candidate a short manufacturing scenario and asking for a one-page requirement will teach you more about how they think, how they write, and what they ask when information is missing than a third conversation ever will.

The point isn't zero external support

We're an integrator, so read this with that in mind, but we mean it. The objective shouldn't be to eliminate outside help. It's to have enough internal knowledge and ownership that you can operate confidently, make informed decisions, and bring in outside expertise deliberately instead of reactively.

Establish functional and product ownership first. Decide how technically self-sufficient you actually want to be second. Then assign whatever's left to an integrator or a shared IT group on purpose, and write it down where people can find it.

Any responsibility that doesn't have a name next to it becomes a support gap eventually. That's usually the whole problem.