Manufacturing Software Selection: 20 Things Australian Manufacturers Need to Consider
At some point, most manufacturers reach the same moment. The systems that got them here are not going to get them where they need to go. We have guided Australian manufacturers through this process more times than we can count, and the same mistakes come up again and again. This article covers the 20 things we think matter most: before you choose, during your evaluation, and when you are ready to implement.
Australian manufacturers are navigating a significant shift right now. Many businesses that spent decades on legacy on-premise systems are moving to cloud-based platforms, and supply chain pressures have made the cost of poor systems visibility much harder to absorb. The decisions you make during software selection will shape your operational capability for years.
Before You Choose Any Software
Define What Success Looks Like
Before you open a single product brochure, get clear on what success looks like for your business. Be specific. What does better stock accuracy mean in practice? How much time does your team currently spend on manual data entry, and what would it mean to cut that in half? Which reports do you wish you had but cannot currently produce?
The clearest software briefs we see come from businesses that have spent time answering these questions before they start evaluating options. The murkiest implementations almost always start with “we need something better than what we have.”
Prioritise Your Requirements Using MoSCoW
Not every requirement carries the same weight, and treating them as if they do is one of the most common ways businesses end up choosing the wrong platform. The MoSCoW method is a practical tool for sorting this out. It splits your requirements into four categories: Must have (the system cannot go live without this), Should have (important but not a blocker if absent at launch), Could have (nice to have if it comes at no cost or complexity), and Won’t have (explicitly out of scope for now).
Applying this framework prevents you from letting a polished demo of a non-critical feature override a gap in something business-critical. For manufacturers, Must haves typically sit around production scheduling, inventory accuracy, and finance integration. If a platform cannot do those things well, everything else is irrelevant. Our software selection and implementation process uses this approach from the first session.
Involve Your End Users Early
The people who will use the system every day know things that do not show up in a requirements document. They know which workarounds the business quietly depends on. They know which processes are messier than management realises. Involving end users early does two things. It surfaces requirements you would otherwise miss. And it builds the kind of ownership that makes adoption far more likely when the system goes live.
Do not mistake a tick-box consultation for genuine involvement. They need to see early prototypes, give feedback on workflows, and feel that their input shaped the outcome. Businesses that skip this step tend to spend the months after go-live managing resistance that was entirely predictable.
Evaluating the Right Platform
Scalability: Will It Grow With You?
A system that fits your business today but cannot scale with you is not a solution. It is a delay. When evaluating scalability, look beyond the current user count and product volume. Ask what happens when you add a new production site, expand into a new market, or acquire another business.
Consider whether the platform’s pricing model penalises growth in ways that will hurt you later. Manufacturers who have been through a cloud ERP migration before know that the cost of migrating again in four years almost always exceeds the cost of choosing a more scalable platform from the start.
Integration With Your Existing Systems
Most businesses do not replace every system at once. Your new manufacturing platform will need to work alongside your finance system, your CRM, and possibly your e-commerce or routing tools. The first thing to check is whether native integrations exist between the platforms you are connecting. Native integrations are preferable where they exist. They are typically lower maintenance and better supported over time.
Where native integrations are limited or absent, custom API development can fill the gap. When evaluating any integration, ask to see the vendor’s API documentation and assess whether it is actively maintained. Undocumented or poorly maintained APIs create technical debt quickly. We have built Katana implementation, MRPeasy implementation and Cin7 Implementation projects where the integration layer was as significant as the platform configuration itself. Sometimes more so.
Data Sovereignty and Storage Location
Where your data lives matters, particularly if you operate in a regulated industry or hold sensitive supplier and customer information. Ask vendors directly: where are the servers located, what happens to your data if you cancel your subscription, and how is access controlled across your organisation.
For Australian businesses, data stored offshore can create compliance obligations that are easy to overlook at the point of purchase. At worst, it becomes a compliance issue. At best, a contractual argument with a vendor you are already dependent on.
Analytics and Reporting Capability
The reporting question is not just about what a platform can produce out of the box. It is about whether you can get to the numbers that matter for your business without a developer’s help. Look for platforms where report creation is accessible to operational staff, not locked behind a technical function.
Ask to see real reports, not polished demo screenshots. Better yet, ask the vendor to run a report using your own data during the evaluation. How they respond to that request tells you something useful.
Automation Potential
Mobile Compatibility
Security and Compliance Standards
Customisation Options
Vendor Reputation and Track Record
A vendor’s product roadmap and financial stability are worth scrutinising. A well-designed platform built by a company that is acquired, pivots, or exits the market in three years creates real operational risk. Ask about the vendor’s history, their customer retention, and their development roadmap. Speak to reference customers in similar industries.
A vendor who cannot answer those questions is either not investing in the product or hiding something. Neither is a good sign.
Commercial and Financial Considerations
Maintenance and Update Commitments
Understand exactly what is included in the ongoing licence fee. Ask who is responsible for updates, how frequently they occur, and whether they require downtime. Find out whether platform updates can introduce breaking changes to your configuration or integrations, and what the process is when they do. Vendors vary significantly on this, and the difference only becomes apparent after you are live.
Return on Investment Beyond Licence Fees
The licence fee is rarely the largest cost in a software project. Implementation, data migration, training, integration development, and internal staff time all add up. When building a business case, the more useful question is not “what does this cost?” but “what does poor systems visibility currently cost us?”
Think about the measurable outcomes that matter in manufacturing: stock accuracy, production scheduling accuracy, days to invoice, time spent on compliance reporting. Quantifying the current gap on even two or three of these gives you a more defensible ROI case than any vendor-provided estimate.
Vendor Roadmap and Long-Term Direction
Getting Implementation Right
Training That Reflects Your Actual Workflows
Generic product training teaches people how the software works. It does not teach them how to do their job in it. That gap is where adoption fails.
Training should be designed around the actual tasks your team performs, in the order they perform them, using your own data and your own configuration. Role-based training, where each person learns the workflows relevant to their function rather than a broad overview of the whole system, consistently produces better outcomes. For more on how we approach this, see our change management service.
Setting a Realistic Implementation Timeline
Software vendors have an incentive to give you an optimistic timeline. Implementation partners who have done this before do not. A realistic timeline accounts for the complexity of your data, the number of integrations required, the availability of your internal team, and the change readiness of your organisation.
Rushed implementations tend to produce a system that is technically live but operationally broken. The cost of fixing that after go-live almost always exceeds what it would have cost to take more time upfront.
Data Migration: The Risk Most Teams Underestimate
Data migration is where many implementations quietly unravel. Poor migration shows up in specific, operational ways: incorrect stock levels that your team does not trust, broken bill-of-materials records, missing supplier history that forces manual re-entry, production orders that reference items that no longer exist in the system.
Good migration practice involves three things. First, a phased approach where data is moved in stages rather than all at once, so problems are contained and recoverable. Second, validation at each stage before proceeding, so errors are caught before they compound. Third, a documented rollback plan so the business can revert if something goes wrong at go-live.
Data that looked clean in your old system often reveals problems the moment it is moved. Build that expectation into your project plan.
User Acceptance Testing and Change Adoption
User acceptance testing is not a formality. It is the last opportunity to catch problems before they become operational incidents. Build structured testing into your project plan with real users performing real tasks in the new system, using production-representative data. Test the edge cases, not just the happy path.
Pair this with deliberate change adoption activities. Communication about what is changing and why, access to support during the transition period, and a named internal contact for questions all reduce the friction of go-live. See our change management approach for how we structure this.
Choosing the Right Implementation Partner
This is the decision that will most determine whether your implementation succeeds. The difference between a good implementation partner and a poor one rarely shows up in technical capability. It shows up in how well they understand your business before they configure anything.
A good implementation partner asks questions about your processes before they open the platform. They want to understand how your production scheduling actually works, where the manual steps are, and what your team struggles with today. In our experience, the ones who skip that step build you a technically correct system that nobody actually uses.
Role-based training built around your actual workflows is another signal. If your partner’s training plan looks like a product walkthrough, ask for something more specific. Your team needs to know how to do their job in the new system, not how the system works in the abstract.
Post go-live support matters more than most businesses anticipate. The first weeks after go-live always surface edge cases and adjustments that could not have been anticipated. A partner who disappears after cutover leaves you exposed at exactly the moment you most need support.
The downstream cost of poor implementation is real and specific. Incorrect stock levels erode trust in the system and force manual workarounds that negate the value of the investment. Poor production scheduling alignment creates downstream delays and customer service problems. Misaligned financial integrations create reconciliation work that can persist for months. Choosing a partner with manufacturing-specific experience, and checking their references in businesses similar to yours, is the most important due diligence you can do.
frequently asked questions
The ecosystem varies by business size and complexity. For production and inventory management, platforms like MRPeasy and Katana are commonly used by small to medium manufacturers. For inventory and multi-channel operations, Cin7 is widely adopted. Xero is the dominant finance platform in the Australian SME market. The right combination depends on your production model, integration requirements, and how tightly you need your manufacturing and finance data to connect. No single platform suits every manufacturer.
A straightforward implementation with limited integrations and relatively clean data can be completed in weeks. A more complex project involving multiple system integrations, significant data migration, and a team spread across multiple sites typically runs three to four months. The variables that most affect timeline are the complexity of your data migration, the number and type of integrations required, and the change readiness of your team.
Rushed implementations carry real downstream risk. Incorrect stock levels, delayed invoicing, and integrations that were never properly tested are the typical symptoms. The businesses that invest time upfront in good process mapping and structured testing consistently have smoother go-lives.
MoSCoW is a prioritisation framework that sorts requirements into four categories: Must have, Should have, Could have, and Won't have. The failure mode it prevents is a common one: a manufacturer chooses a platform because it demos well on a feature that turns out to be non-critical, while a core requirement goes unmet.
In a manufacturing context, Must haves typically sit around production scheduling, inventory management, and finance integration. Getting clear on those before you start evaluating platforms makes the selection process significantly more objective and harder to distort through a well-presented demo.
The technology is rarely the root cause. Implementations fail most often because the people using the system were not adequately prepared for the change. That shows up in specific ways: low system adoption, teams reverting to spreadsheets, incorrect stock levels because staff are not confident in the new processes, and workarounds that quietly grow back after go-live.
Adequate preparation means role-based training built around actual workflows, structured testing before go-live, clear internal communication about what is changing and why, and post-launch support that is available when the first edge cases surface.
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.
