Do You Need an MRP Consultant? What Independent Advice Actually Looks Like
If you are weighing up whether to bring in an MRP consultant, you have probably already had at least one conversation with a software vendor. Vendors are good at their job. Their job is to sell their platform. A consultant’s job is different: work out what your operation actually needs, then say so, even when the answer is a platform they do not sell.
That difference is the entire point of this article. Not every manufacturer needs a consultant, and not every consultant gives independent advice. Here is how to tell the two apart before you commit any budget.
What an MRP consultant actually does
An MRP consultant’s job starts before any software conversation. The work maps your production process, your bill of materials, and your current systems, then locates where the pain actually sits. That becomes a set of requirements the platform has to meet.
This is different from a vendor demonstration, which starts from the software and works backward to find reasons it fits you. A consultant starts from your operation and works forward to find what fits it. Get that sequence backward and you’ll end up buying capability you never use, or missing capability you needed from day one.
A good consultant also brings pattern recognition from other manufacturers. They’ve seen where rollouts stall, which requirements get missed at scoping stage, and which platform categories suit which kind of production. That experience is worth more than any single feature list. It tells you what question to ask before a problem shows up, not after.
What independent MRP advice looks like in practice
Most consultants worth hiring have implementation experience with more than one platform, and that’s exactly why their advice is useful. Having a relationship with software vendors doesn’t disqualify that advice on its own. What matters is who the consultant is accountable to, and what drives the recommendation.
Paid by you, not by the software vendor
The clearest test is who signs the invoice. An independnet consultant paid by you has no reason to steer the recommendation toward a platform that pays them a referral fee or commission. A consultant paid by a vendor, even indirectly, has a built-in incentive that sits behind every piece of advice they give you, whether they say so or not.
A consultant with platform partnerships can still be independent. The fee structure and the accountability simply need to be clear from the outset. Ask directly how the consultant is paid and whether that changes depending on which platform you choose. A straight answer is a good sign. A dodge is not.
Requirements come before any product name
The second test is sequencing. Independent advice starts with a requirements conversation: your bill of materials, your production stages, your integration needs, your team’s capacity to manage a new system. A product name shouldn’t enter the conversation until that picture is clear.
If a consultant names a platform in the first meeting, before they have asked how your production actually runs, that is worth noticing. The right order is requirements first, shortlist second, recommendation third. Reverse that order and you are closer to a sales process than an advisory one.
Considering MRPeasy, Katana or Cin7? We implement them.
Do you need one if the software is meant to be easy?
Modern MRP platforms are genuinely easier to set up than the on-premise systems they replaced. That has led some manufacturers to assume a consultant is unnecessary overhead, since the software itself doesn’t need a specialist to configure it.
The gap an MRP consultant actually closes
That gap is rarely the software interface. It sits earlier, in the decision about which category of system fits your production complexity, and whether your data is ready to migrate before the new system goes anywhere near it.
We see this most often with manufacturers who buy a platform because it looked easy in a demo. Mid-implementation, they discover their bill of materials was never structured cleanly enough to migrate. Skip that step and the cost isn’t just a delayed go-live. It’s weeks of manual rework, a frustrated production team, and a system nobody trusts by the time it finally launches.
When you can reasonably skip an MRP consultant
If your production is straightforward and your bill of materials is already clean, you may not need outside help. That’s especially true if someone internally understands both the operation and the software category. If any of those is missing, a short scoping engagement with a consultant is usually cheaper than a failed rollout.
When to bring a consultant in: before or after choosing
The earlier a consultant is involved, the more value they add.
Before a platform is chosen
The stronger sequence is to bring a consultant in at the point where you have identified a problem but have not yet named a solution. That is when requirements can genuinely shape the shortlist, rather than being reverse-engineered to justify a decision already made.
After a platform is chosen
Bringing a consultant in once you’ve already selected a platform limits their role to implementation oversight. That still has value, but it forecloses the harder question of whether the platform was the right choice in the first place.
If you’ve already chosen a platform and simply need help getting it implemented properly, that is a different engagement with a different scope, and one we cover separately.
What independent MRP advice should cost
Cost varies with the scope of the engagement and the complexity of your requirements, so we won’t quote a figure without understanding both.
What drives the cost up or down
A focused scoping engagement is a smaller piece of work than a full implementation oversight engagement running alongside a rollout. The complexity of your bill of materials, how many systems need to integrate, and how much data needs cleaning before migration all drive the cost.
What to weigh it against
The number worth focusing on isn’t the consultant’s fee in isolation. Set that fee against the cost of a rollout that has to be redone because the requirements were wrong the first time. In our experience, that avoided cost is the larger number, by a wide margin.
Ask about fee structure. Ask what requirements were gathered before any platform got mentioned. Treat the answer as the real test of independence.
When we scope a system at Cohesis, the first conversation is about your bill of materials and your sales channels, not a product name. The recommendation follows from what we find, which sometimes means telling a manufacturer the system they already run is the right one. If you’re weighing this up for your own operation, an independent view starts with your requirements, not a vendor’s pitch.
Frequently asked questions
Yes, provided the fee comes from you and the recommendation follows your requirements rather than the partnership. Ask how the consultant is paid and whether platform relationships change the fee.
An MRP consultant helps you decide whether you need a system at all and which category fits. An implementation consultant takes over once a platform is chosen, managing the rollout itself.
A scoping and requirements engagement is typically measured in weeks, not months. Timeframes depend on how much data mapping and stakeholder input is required before a shortlist can be built confidently.
Before, if possible. Requirements set before you see vendor pricing keep the comparison honest, rather than working backward from whichever quote looked most attractive.
Simon Cohen
Written by Simon Cohen, Founder, Cohesis. Simon has over two decades of experience working with Australian SMEs and local government organisations on technology strategy, governance, and implementation.
