← Back to Field Notes

March 10, 2026 · The Bloomfield Team

Your ERP Data Is More Valuable Than You Think. You Just Cannot Access It.

A contract manufacturer in Ohio runs Epicor. Eleven years. Every job since 2015 recorded: part numbers, material costs, cycle times, setup hours, scrap rates, customer purchase orders, shipping records. Roughly 43,000 completed jobs. Tens of millions of data points.

The owner uses Epicor to generate invoices and track open orders. That is about 5% of what the system contains.

A 2024 survey by the MPI Group found that 72% of small and mid-size manufacturers use their ERP at less than 40% of functional capacity. The data goes in. It rarely comes back out in a form that helps anyone make a better decision.

The Access Problem

ERPs record transactions. Purchase order created. Job opened. Material received. Shipment out. Each event logged with a timestamp, reference number, and associated fields.

What ERPs were never designed to do is answer questions across those transactions. What did we charge the last time we ran this part for this customer? What was actual cycle time versus estimated? Which supplier gave the best price on 4140 bar stock over the past two years? Which jobs with tolerances under 0.001" required rework?

Those questions require pulling data from multiple tables, joining separately stored records, filtering by criteria the built-in reporting tools do not support. The information exists. The retrieval path does not.

Most manufacturers work around this by asking the person who remembers. The estimator quoting jobs for fifteen years. The production manager who knows which parts cause setup problems. The purchasing agent who recalls the late vendor. These people are the de facto query engine for the entire operation. When they retire, take vacation, or leave, the query engine goes with them.

What the Data Actually Contains

Job records contain estimated versus actual hours for every operation on every job. Five years of this data is enough to build highly accurate cycle time predictions for new quotes. The gap between estimated and actual reveals which operations the shop underestimates and where margin erosion starts.

Purchase order history shows every material buy with vendor, price, lead time, and quantity. Aggregated over time, this answers questions about price trends, vendor reliability, and volume discount thresholds that nobody currently tracks in a structured way.

Customer records contain order frequency, average job value, quote-to-order conversion, payment history. This identifies which customers are growing, which declining, which cost more to serve than they generate in margin.

Quality records track nonconformances, rework hours, scrap. Linked to job parameters, this reveals which geometries, materials, or tolerance bands produce the most issues. That information should flow into the quoting process. In most shops, it does not.

Shipping records show on-time delivery by customer, part family, and production cell. Cross-referenced with scheduling data, they reveal where delays originate, how far upstream root causes sit, and which work types are most likely to ship late.

All sitting in the database. Searchable in theory. Inaccessible in practice.

Why Built-In Reporting Falls Short

Every ERP vendor sells reporting as a feature. Epicor has BAQs. JobBOSS has Crystal Reports. Global Shop Solutions has its own module. These tools work within the ERP's data model, answering questions the vendor anticipated. Open jobs in the shop right now? Report is there. Jobs from the past three years with a specific material, tolerance band, and customer where actual cycle times exceeded estimates by more than 20%? That requires a custom query from someone who understands the database schema.

Most shops do not have that person on staff. They have an ERP administrator handling permissions, backups, and login issues. The gap between what the system can theoretically produce and what anyone knows how to ask for is enormous.

So the reports that run are the same ones that have always run. Open orders by customer. Jobs by work center. Revenue by month. These describe the present. They do not explain the past in ways that improve the future.

The Cost of Not Using What You Have

An estimator at a 40-person shop builds 30 to 50 quotes per month. Without historical data in usable format, they work from memory and rules of thumb. A study in the Journal of Manufacturing Systems found manual quoting methods deviate from actual costs by 15 to 30% on average. On a $25,000 job, $3,750 to $7,500 in potential margin variance per quote.

With structured access to past job data, estimates tighten. The system surfaces the five most similar jobs from three years, shows actual costs, flags where previous estimates were off. The estimator still makes the final call, but with evidence instead of instinct.

The same logic applies to scheduling, purchasing, and quality management. Every decision from memory carries an accuracy penalty. Every decision from historical data carries less risk. The data to reduce that risk is already in the building. The gap between what the ERP stores and what your team can access is where the value sits.

What Structured Access Looks Like

The goal is building a retrieval layer on top of the ERP that makes accumulated data useful for daily decisions.

That layer connects to the ERP database and reads it. Also connects to spreadsheets, shared drives, emails with supplier quotes, PDF inspection reports, job traveler notes. Pulls everything into a structure queryable by someone who does not know SQL and does not understand the database schema.

Estimator opens an RFQ. The retrieval layer identifies the customer, finds five closest historical jobs by geometry and material, surfaces actual costs and cycle times, shows current material pricing from the most recent supplier quotes. An hour of searching becomes seconds.

Production manager wants to know which work centers run above estimated cycle times this month. The layer compares actual clock-ins against estimates in real time, showing variance by cell, operator, and part family. A full day to compile from raw reports becomes a continuous update.

Sales manager wants customer order volume trends over six months. The layer aggregates purchase order data, groups by customer and period, shows trends. No spreadsheet. No IT request.

This is what custom AI tools for manufacturers do. Turn transaction data into decision support. Make the knowledge the operation has generated available to people who need it, in the moment they need it.

The Compounding Return

Every month adds more data. More completed jobs. More purchase orders. More quality records. Structured access value grows with every transaction because the historical base gets richer and predictions get more accurate.

A shop building its retrieval layer in year one gets immediate benefit. By year two, a full cycle of consistently structured data makes analysis more precise. By year three, decisions are based on thousands of data points no human could hold in memory, and compounding effects on quoting accuracy, scheduling precision, and purchasing efficiency become measurable in financials.

The manufacturers pulling ahead over the next five years will not necessarily have the newest machines or largest headcount. They will be the ones that figured out how to use data they had been sitting on for a decade. The tools exist today. The question is who builds the retrieval layer first.