ERP selection for mid market manufacturer teams is not a software beauty contest. The best way to evaluate options is to start with the work the system must support, document the requirements that matter most, test realistic scenarios with credible data, and compare implementation risk and full lifecycle cost alongside functionality. A disciplined process helps leaders choose a system the company can adopt and govern, not just one that looks good in a demonstration.
Discuss your ERP decision with an advisor
What should a mid-market manufacturer decide before comparing ERP systems?
First, agree on the business problem and the decision boundary. A company may be replacing an aging finance platform, joining several acquired sites, improving production planning, or moving from spreadsheets into a shared operating system. Those are different projects. If the executive team cannot state what must change and why, vendors will fill the gap with their own assumptions.
Write a short decision charter before issuing a request for information or scheduling demonstrations. It should identify:
Business outcomes: What needs to improve, such as visibility into inventory, reliable production schedules, faster month-end close, or consistent processes across facilities?
Scope: Which entities, sites, functions, product lines, and processes are included? What is explicitly out of scope for this phase?
Constraints: What deadlines, regulatory obligations, staffing limits, legacy systems, or planned business changes could shape the choice?
Decision owners: Who recommends, who approves, and who will own process and system decisions after launch?
Measures: How will leaders know the new system is working, and what baseline can they compare with?
Keep the scope realistic for the organization’s capacity. A 150-person manufacturer may have complex scheduling, traceability, and costing needs without having a large internal program office. A staged rollout may be more manageable than replacing every application and process at once. For an overview of how executive IT leadership can support technology planning and governance, see Fractional CIO services.
How do you translate plant and business work into requirements?
Do not begin with a long feature checklist copied from a vendor website. Map the work that crosses departments and facilities, then identify where delays, duplicate entry, poor visibility, or control gaps occur. Include people who do the work, not only department heads. A system that fits the executive’s preferred dashboard but adds friction to receiving or production reporting will struggle to gain adoption.
Walk through representative processes from beginning to end. For example, follow a customer order from quote and order entry through material planning, production, quality release, shipment, invoicing, and payment. Then examine a purchase-to-receipt process and a production-to-costing process. Note decisions, exceptions, handoffs, records created, and the systems involved at each step.
Turn findings into requirements with clear priority levels. A useful classification is:
Required: Needed to operate safely, meet a defined obligation, or achieve the stated business outcome.
Important: Provides meaningful value, but a workable alternative exists during a transition.
Optional: Useful only if it does not add disproportionate cost, complexity, or delay.
For a food and beverage producer, lot traceability, formula or recipe management, expiration dates, and multi-site inventory may be central. A medical device manufacturer may place more weight on controlled records, validation evidence, quality workflows, and change history. The applicable requirements depend on the company’s products and obligations; do not assume one industry label determines the whole design. See Turning Point Advisory’s context on IT strategy for food and beverage companies or technology leadership for medical device manufacturers for examples of industry-specific concerns.
For each requirement, record the process owner, priority, current pain point, acceptance test, and any dependency. This turns broad requests such as “better inventory” into testable expectations: for example, a planner can identify the available, reserved, and in-transit quantities for a selected item and location using a defined source of truth.
Which manufacturing workflows should an ERP evaluation test?
Evaluation teams should use scenarios that reflect the company’s actual operating model. A polished demonstration of standard sales and accounting screens says little about whether the system handles a production exception or a late supplier shipment. Choose scenarios that are frequent, financially material, operationally risky, or difficult to manage today.
Consider testing a set that includes these process areas:
Demand and order planning: How does a forecast or customer order become a production plan? Can planners see constraints, changes, and the effect of priorities?
Materials and purchasing: Can users review requirements, supplier lead times, substitutions, partial receipts, and shortages without relying on disconnected spreadsheets?
Production execution: How are work orders released, labor and materials recorded, scrap captured, and schedule changes reflected?
Inventory and traceability: Can staff find the location, status, lot or serial details, and movement history they need for a realistic inquiry?
Quality and nonconformance: What happens when an inspection fails, a hold is applied, or a corrective action requires follow-up?
Costing and finance: How do actual material, labor, overhead, and variances flow into financial reporting and period close?
Shipping and service: Can the organization confirm what is ready, what is shipped, and how a return or customer issue is recorded?
Ask vendors to demonstrate both the normal path and a meaningful exception. For instance, change a production quantity after a partial material receipt, then ask the team to show how planning, inventory, costing, and reporting respond. The point is not to force every product into an identical workflow. It is to expose assumptions and understand whether a gap can be addressed through configuration, process change, integration, customization, or a separate application.
How should leaders assess data, integrations, and reporting?
ERP outcomes depend on information quality as much as software capability. Before selection, inventory the important data domains: products and bills of material, routings, customers, suppliers, locations, units of measure, open orders, inventory balances, and financial structures. Identify where each set lives, who maintains it, how complete it is, and which records are duplicated or inconsistent.
Data cleanup is not simply a technical task to postpone until implementation. If product identifiers differ across locations, units are inconsistent, or ownership is unclear, migration and reporting decisions become harder. Estimate the effort to define standards, resolve duplicates, validate records, and assign ongoing stewardship. Ask each vendor or implementation partner how it would approach profiling, mapping, migration rehearsals, reconciliation, and sign-off.
Draw the system context around the proposed ERP. Manufacturers may need connections to accounting or tax tools, warehouse systems, manufacturing execution or shop-floor tools, product lifecycle management, e-commerce, customer relationship management, quality systems, shipping providers, and reporting platforms. Not every company needs every connection. For each actual integration, document what information moves, in which direction, how often, who monitors failures, and what happens if either system is unavailable.
Test reporting needs with examples rather than generic promises. Can the right users see site-level and consolidated views? Can they trace a number back to its source and understand the timing of updates? Does the organization need standard reports, configurable dashboards, a data warehouse, or some combination? Confirm which capabilities are included and which require additional products, services, or licenses.
Also discuss access and security early. Identify roles that need to create, approve, change, or view sensitive transactions. Consider how access is granted and removed, how administrative actions are recorded, how backups and recovery are handled, and how the ERP connects to the company’s broader security program. NIST is a starting point for government guidance on information security and risk at NIST; leaders should assess the controls appropriate to their own systems and obligations rather than treat a software feature list as proof of security.
How can the team evaluate compliance and internal controls?
Begin with the obligations that actually apply to the business, its products, customers, and locations. Ask quality, finance, operations, legal, and IT stakeholders to identify relevant requirements and the records or controls they depend on. The ERP may support parts of a control environment, but choosing a product does not by itself establish compliance.
For each important control, describe the intended behavior and gather evidence in a demonstration or written response. Examples include role separation for sensitive transactions, approval thresholds, change history, retention needs, traceability of materials or product records, and the ability to document exceptions. Ask what the system records by default, what configuration is required, what an administrator can change, and how the organization can review that activity.
Distinguish between product capability and the operating process around it. A system might offer an approval workflow, but the company still needs to define who approves, how substitutes are handled, and how approvals are reviewed. A traceability function is useful only if source data is accurate and staff record movements consistently. Map ownership for each control so that no critical responsibility is assumed to belong to “the ERP.”
Where requirements are specialized, involve qualified internal or external subject-matter expertise before locking the design. For companies in regulated sectors, the industry-focused IT consulting overview provides context on the range of operational and regulatory environments Turning Point Advisory serves. Keep the evaluation focused on your organization’s obligations and evidence needs.
How should a manufacturer compare implementation risk?
Implementation risk is not a side issue to resolve after choosing the product. The same software can produce very different outcomes depending on project scope, data readiness, decision speed, partner experience, internal capacity, and the amount of process change required. Evaluate the delivery approach for the specific business, not only the vendor’s product roadmap.
Ask each proposed delivery team to explain its plan for discovery, design decisions, configuration, integrations, data migration, testing, training, cutover, and early support. Who will do each task? How much time will the company’s employees need to contribute? What decisions must be made by executives, process owners, and technical staff? Which assumptions could change the timeline or cost?
Look closely at the proposed partner’s experience with your operating complexity, not just the ERP brand. Ask for relevant examples, references you can contact, and a clear explanation of how the team handles scope changes, unresolved requirements, and escalation. Confirm whether the named people will remain involved and how specialized support is arranged. Avoid treating a generic fixed timeline as a commitment before scope and dependencies are understood.
Check the change impact by role and location. A new process may alter how planners schedule, how operators record production, how quality staff release product, or how finance closes the books. Identify training ownership, shift coverage, language or accessibility needs, and the time required for users to practice. A technically successful launch can still disrupt operations if the workforce is not prepared.
For independent oversight, define who can challenge the implementation plan, review assumptions, and escalate risks to leadership. An organization considering senior technology leadership can explore executive IT advisory as a distinct source of peer-level counsel, or review the firm’s IT vendor selection checklist for a broader set of vendor evaluation prompts. Keep this ERP decision grounded in your own process maps, data, and delivery constraints.
What belongs in the total cost comparison?
Compare the cost of operating each option over a period that reflects the expected system life, not just the first subscription or license quote. The cost model should make assumptions visible and separate one-time implementation from recurring expenses. Include the elements that apply to the proposed design:
Software subscriptions or licenses, including user, module, site, storage, and environment charges.
Implementation services, project management, data work, integrations, testing, and any customization.
Additional tools for reporting, planning, warehouse operations, quality, or shop-floor execution.
Internal staff time for discovery, data cleanup, decisions, testing, training, and support.
Infrastructure, security, backup, support, and ongoing administration costs.
Training, process redesign, change management, and post-launch stabilization.
Potential costs to retire legacy systems, archive records, or maintain temporary interfaces.
Do not assume the lowest initial quote is the lowest-cost choice. A product with a lower subscription may require significant customization or extra applications to cover essential workflows. A broader product may carry capabilities the company does not need. Compare scenarios on a consistent basis and clearly label estimates, exclusions, and dependencies.
Connect cost to measurable business outcomes without promising savings that have not been validated. For each expected benefit, name the process, the baseline, the owner, and how the effect will be measured. If the case depends on reducing manual reconciliation, for example, agree on what work is counted and whether labor time will be redeployed or removed. This allows leadership to review the investment honestly after implementation.
How can the team reach a defensible ERP decision?
Use a documented evaluation rather than a single weighted score that hides important trade-offs. A simple scorecard can help compare options, but it should sit beside written evidence, cost assumptions, and unresolved risks. Give criteria explicit definitions and score options against the same scenarios.
A practical sequence is:
Confirm the charter and decision group. Get agreement on scope, outcomes, constraints, and who makes the final decision.
Map priority workflows. Involve process owners across plant, quality, supply chain, finance, and IT. Capture normal paths and exceptions.
Set requirements and evidence. Mark each item required, important, or optional, and define how the team will verify it.
Shortlist plausible options. Remove options that clearly fail a non-negotiable requirement or exceed the organization’s delivery capacity.
Run scenario-based demonstrations. Use realistic examples and ask vendors to identify configuration, customization, and third-party dependencies.
Validate delivery and cost. Review partner staffing, migration assumptions, internal effort, recurring expenses, and risks.
Record the decision and conditions. Document why the selected option fits, what remains uncertain, and what must be resolved before contract or launch.
Weighting can clarify priorities, but do not let arithmetic overrule a critical weakness. A high overall score cannot compensate for a system that fails a mandatory process or an implementation plan that the company cannot staff. Provide leadership with a concise recommendation, the meaningful alternatives, trade-offs, financial assumptions, top risks, and the next decisions required.
Once selected, preserve the evaluation record as a foundation for implementation. The requirements and scenario results can become design and acceptance criteria. This continuity reduces the chance that assumptions made during selection disappear when the project moves to a delivery team. For ongoing oversight, consider how the company will govern technology investments and decision rights through an IT governance framework for mid-market companies.
What should happen after the ERP is selected?
Selection is the start of a controlled change, not the finish line. Before signing or beginning implementation, confirm the scope, success measures, responsibilities, commercial assumptions, and escalation paths. Resolve ambiguities about data ownership, integration responsibility, support coverage, and acceptance criteria. If major uncertainties remain, make them visible and assign an owner and decision date.
Establish a decision cadence that fits the project. Process owners need a way to resolve design questions; the project team needs a route to escalate schedule, cost, and scope risks; executives need concise updates that distinguish decisions required from general status. Keep a decision log and a risk register, and revisit whether the expected outcomes remain achievable as new information emerges.
Plan how the system will be supported after go-live. Name business owners for key processes, technical owners for integrations and access, and administrators for configuration and user management. Agree how users will report issues, how enhancements will be prioritized, and how performance will be reviewed. The internal team should understand which responsibilities sit with the software provider, implementation partner, and company.
Then compare actual performance with the baseline. Review operational measures selected before the project: for example, the accuracy of inventory records, schedule adherence, time required to close the books, or the frequency of manual re-entry. Investigate causes when results differ from expectations. The purpose is to learn and improve the operating model, not merely to declare the launch complete.
Explore fractional CIO support for technology planning
Frequently Asked Questions
How many ERP vendors should a manufacturer evaluate?
There is no useful fixed number. Start with a manageable shortlist of options that appear to meet the essential requirements and fit the organization’s capacity. A few well-tested candidates usually provide more decision value than a long list of superficial demonstrations.
Should a manufacturer customize its ERP to match current processes?
Not automatically. First determine whether the current process is valuable, required, or simply familiar. Standard configuration may support the need with less complexity; a process change may also be sensible. Reserve customization for a clear business case, and understand its effects on cost, testing, upgrades, support, and future flexibility.
Can spreadsheets remain in use after an ERP rollout?
Some spreadsheets may remain useful for analysis or limited planning, but define where official records live and who owns them. If a spreadsheet controls a critical transaction or duplicates data without review, it can undermine visibility and control. Evaluate each one based on its purpose, users, data source, and risk.
When should data cleanup begin?
Begin during evaluation, as soon as the team understands the data domains and likely migration scope. Early profiling exposes ownership and quality issues that can affect product fit, effort, timeline, and cost. Detailed cleansing can be planned with the implementation, but the work should not be treated as an unknown future task.
A strong ERP decision comes from matching real manufacturing work to a realistic delivery plan and a sustainable operating model. When leaders test the assumptions before committing, they can choose with greater clarity and prepare the organization for the work that follows.
