Manufacturing ERP selection: the 40 requirements checklists miss

The free manufacturing ERP checklists are too short to run a selection on. The most-visited one, from SelectHub, lists 17 features, each as a module name with a yes or no answer. A manufacturer needs about 40 specific behaviors, and 27 of them depend on whether the plant runs discrete, process, or job shop production. This article lists all 40, grouped into nine areas. For each one it explains why generic checklists skip it, how to prove it in a demo, and which production modes it matters for. It closes with a way to weight them so the scoring model rewards software that does the work natively rather than through a partner add-on.

Generic checklists stop at the module name

The three pages that rank for the primary keyword cover the following. SelectHub lists 17 features, from BOM and routing through MES, quality, and warehouse. It grades vendors on three support tiers (out of the box, workaround or add-on, partner or custom) and scores 0 to 100, which is sound. It does not say what to ask the vendor to show, and it does not separate discrete from process or job shop.

ERP Research goes further. Its page sorts by production mode and rates items Must, Should, or Could. It publishes scoring weights: functional depth 30%, total cost 20%, implementation risk 15%, and 5 to 10% each for partner network, roadmap, customer experience, and vertical fit. It also discloses a sponsorship from an ERP vendor, so treat its rankings with that in mind.

TechTarget's checklist, published June 10, 2026, lists production planning, BOM management, and shop floor control under one heading and gives no weighting method.

The gap is the same across all three. A line that reads "quality management: yes" tells you a module exists. It does not tell you whether an inspection plan fires automatically on receipt of a lot, or whether the nonconformance record links back to the supplier rating. Those are the behaviors that decide whether the plant uses the system or works around it in spreadsheets.

QAD's selection guide, written by its director of product marketing in February 2026, makes the same point from the vendor side (QAD blog). It says to run scripted demos with your own data and edge cases, and to shortlist two or three vendors before you do. That is vendor advice, but it is the right default: a shortlist of two or three keeps the scripted demos to a number the plant staff can attend.

Production mode decides which half of the list matters

Discrete, process, and job shop plants need different things from the same module. SYSPRO's explainer draws the first line: discrete products are assembled from parts and can be taken apart, while process products come from formulas and cannot. Sysgenpro's comparison extends that into six areas.

Job shops are a third case. ECI, which sells job-shop and batch-and-process software, describes job shop needs as job costing, quoting, and scheduling flexibility for make-to-order work (ECI). The table below is the split that holds up when tagging requirements.

In the requirement table that follows, the Modes column uses D for discrete, P for process, and J for job shop. Score only the rows tagged with your mode. If you run mixed-mode (a plastics molder that also assembles, for example), score both.

The 40 requirements, with the demo test for each

The table groups the requirements into nine areas. The demo test column describes what to put in the vendor's script. Give the vendor your own item numbers, routings, and lot data two weeks before the session, and tell them the script will be run as written.

Count the modes and the pattern shows. Thirteen rows carry all three letters. The remaining 27 rows apply to one or two modes. A job shop that scores all 40 is grading itself on 18 process-only or discrete-only items it will never run.

The ERP and MES boundary is the requirement most likely to be scored wrong

Requirements 6 through 10 are the group we expect to fail most often in demos, and the reason is a layer problem. ISA-95, published in 2000 by merging the MESA model with the Purdue reference model (Wikipedia), puts ERP at Level 4 and MES at Level 3. Level 4 plans in months, weeks, and days. Level 3 runs in days, shifts, hours, and minutes.

MESA International, the trade group that maintains B2MML, the XML standard for moving data between the two layers, defined 11 MES functions as far back as its 1997 white paper. When a vendor shows machine-level dispatching inside the ERP, the team often scores it as a strength. It is often a sign that the two layers have been merged, which makes every upgrade a plant-floor event.

The cleanest public test script is Microsoft's. Its MES integration for Dynamics 365 documents six processes and five message types: release the order, start it, report good and scrap quantity, report material consumed, report time per operation, and end the order. Each message gets three attempts before it is marked failed. You do not need to be buying Dynamics 365 to use that list.

Ask every vendor on the shortlist to walk those six flows and name which system owns each one. Sysgenpro's note on MES alignment adds the failure tests worth running: asynchronous transactions, a plant connectivity loss, a failed message, and an ERP upgrade against a validated MES interface.

Native, partner add-on, or custom: where the vendors sit

The same requirement can be met three ways, and the three carry different risk. SelectHub's three support tiers (out of the box, workaround or add-on, partner or custom) are the right frame. The table below records what each vendor's own page or a comparison site says about where a few of the 40 are handled.

It is not a ranking. Each vendor is the right answer for some plants, and the conditions are in the last column. Entries marked "verify" need checking against the vendor's current page before you rely on them.

Two cautions on this table. First, these are comparison-site ratings, not a research firm's independent testing, and the comparison sites disclose vendor sponsorships. Second, "native" changes with every release. Use the table to decide what to ask, then make the vendor prove it in the demo.

How to weight the 40 for a scoring model

A flat list of 40 items with equal weights produces a flat result, and the two finalists end up within a few points of each other. We recommend three adjustments. First, score only the rows tagged with your mode, which takes a discrete plant from 40 items to 36, a process plant to 29, and a job shop to 22. Second, tag each remaining row Must, Should, or Could, and weight them 3, 2, and 1.

Third, score the demo evidence 0 to 4 and then cap the score by how the requirement is met. Native gets the full score, a partner add-on is capped at 3 of 4, and custom code is capped at 2 of 4. The cap on custom code follows from the cost data. Keeping custom code under 10 to 15% of requirements saves 20 to 40% of implementation cost, so a requirement met with custom code is worth less even when the demo looks good.

Two rows where a loose script costs the most

The genealogy query, row 11, is where a vendor-written script hides the most. Suppose a process plant with a four-level BOM and a co-product asks for lot traceability, and the vendor demos it on a single-level BOM using its own sample data. The backward query from a finished lot returns in seconds, and the room scores it 4 of 4. Nothing in that demo touched the plant's real case: a raw material lot that enters at level four, passes through two intermediates, and splits into a main product and a by-product that ships to a different customer.

Run forward on that structure, the same query has to follow three consumption steps and one split. Some systems need a second screen or a separate report for each step. The script should have named three things: the direction (forward from a raw material lot), the data (the plant's own four-level item with the co-product, loaded two weeks ahead), and the clock (the time from query to customer list, written on the scorecard). Without those three, the vendor picks the item, the direction, and the pace, and the score measures the demo rather than the software.

Multi-plant templates, row 36, are the second place where a selection decision comes back later. Take a four-plant manufacturer in one legal entity, planning its rollout at ERP Research's 3 to 6 months per further site, so 9 to 18 months for plants two through four after plant one goes live. Plant one's template fixes costing at standard cost as a global setting, because that is how plant one has always run. Plant two runs actual cost on 4,000 items because its raw material prices move weekly.

When plant two starts, the team can reopen the design for costing, which means a plant-level costing setting, a new cost roll, and a retest of every variance report. Design work is 10 to 20% of implementation hours, so suppose the rework adds two months to plant two. Plant two now takes 5 to 8 months instead of 3 to 6. Plants three and four carry the new setting through their own test cycles, so the rollout runs 11 to 20 months rather than 9 to 18.

Or the team can force plant two onto standard cost and accept that the plant's margin reporting changes, which is a business decision nobody made on purpose. The demo question that would have caught it is row 21 as written: two plants in one company, one on standard and one on actual, posting to one general ledger. The right default is that each of the 40 rows is marked global or local before plant one goes live.