← 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. They have run it for eleven years. Every job that has moved through the shop since 2015 is recorded in that system: part numbers, material costs, cycle times, setup hours, scrap rates, customer purchase orders, and 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.

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

The Access Problem

ERP systems were designed for transactions. They record what happened: a purchase order was created, a job was opened, material was received, a shipment went out. Each event gets logged with a timestamp, a reference number, and a set of associated fields.

What ERP systems were never designed to do is answer questions across those transactions. Questions like: what did we charge the last time we ran this part for this customer, what was the actual cycle time versus the estimated cycle time, which material supplier gave us the best price on 4140 bar stock over the past two years, and which jobs with tolerances under 0.001" required rework.

Those questions require pulling data from multiple tables, joining records that the system stores separately, and filtering by criteria that 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 who has been quoting jobs for fifteen years. The production manager who knows which parts always cause setup problems. The purchasing agent who recalls which vendor was late last quarter. These people are the de facto query engine for the entire operation.

When they retire, take vacation, or leave for another job, the query engine goes with them.

What the Data Actually Contains

Walk through a typical ERP database in a $10 million job shop and the depth of what is recorded becomes clear.

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

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

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

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

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

All of this is 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 (Business Activity Queries). JobBOSS has Crystal Reports integration. Global Shop Solutions has its own reporting module. These tools can pull data from the system, format it into tables and charts, and deliver it on a schedule.

The limitation is structural. Built-in reporting tools work within the data model the ERP was designed around, which means they answer the questions the software vendor anticipated when they built the product. If you want to know how many open jobs are in the shop right now, the report is already there. If you want to know which jobs from the past three years with a specific material, tolerance band, and customer had actual cycle times more than 20% above the estimate, you are writing a custom query that requires someone who understands the database schema.

Most shops do not have that person on staff. They have an ERP administrator who handles user permissions, runs backups, and troubleshoots login issues. The gap between what the system can theoretically produce and what anyone in the building 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 reports describe the present. They do not explain the past in ways that improve the future.

The Cost of Not Using What You Have

Consider quoting. An estimator at a 40-person shop builds 30 to 50 quotes per month. Each quote requires estimating material cost, setup time, cycle time per operation, and outside processing costs. The accuracy of those estimates determines whether the shop wins the job and whether the job makes money.

Without access to historical job data in a usable format, the estimator works from memory and rules of thumb. A study published in the Journal of Manufacturing Systems found that manual quoting methods in job shops produce estimates that deviate from actual costs by 15 to 30% on average. On a $25,000 job, that is $3,750 to $7,500 in potential margin variance per quote.

With structured access to past job data, those estimates tighten considerably. The system can surface the five most similar jobs from the past three years, show the actual costs, and flag where previous estimates were off. The estimator still makes the final call, but they make it with evidence instead of instinct.

The same logic applies to scheduling, purchasing, and quality management. Every decision made from memory or rough estimates carries an accuracy penalty. Every decision made with 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 not to replace the ERP. The ERP does its transaction-recording job well enough. The goal is to build a retrieval layer on top of it that makes the accumulated data useful for the decisions people actually make every day.

That retrieval layer connects to the ERP database and reads it. It also connects to the other places where operational data lives: spreadsheets, shared drives, emails with supplier quotes, quality inspection reports in PDF form, and notes from job travelers. It pulls all of that into a structure where it can be queried by a person who does not know SQL and does not understand the database schema.

An estimator opens a new RFQ. The retrieval layer identifies the customer, finds the five closest historical jobs by geometry and material, surfaces actual costs and cycle times, and shows the current material pricing from the most recent supplier quotes. What used to require an hour of searching takes seconds.

A production manager wants to know which work centers are running above estimated cycle times this month. The retrieval layer compares actual clock-ins against job estimates in real time and shows the variance by cell, by operator, and by part family. That information used to take a full day to compile from raw ERP reports. Now it updates continuously.

A sales manager wants to see which customers have increased order volume over the past six months and which have declined. The retrieval layer aggregates purchase order data, groups it by customer and time period, and shows the trends. No spreadsheet required. No report request to the IT department.

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

The Compounding Return

Every month that passes adds more data to the ERP. More jobs completed. More purchase orders fulfilled. More quality records logged. The value of structured access grows with every transaction because the historical base gets richer and the predictions get more accurate.

A shop that builds its retrieval layer in year one gets immediate benefit from the existing data. By year two, the system has a full cycle of data captured with consistent structure, which makes the analysis more precise. By year three, the operation is making decisions based on thousands of data points that no human could hold in memory, and the compounding effect on quoting accuracy, scheduling precision, and purchasing efficiency becomes measurable in the financials.

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