← Back to Field Notes

March 12, 2026 · The Bloomfield Team

How to Connect Systems That Were Never Meant to Talk to Each Other

A typical mid-size manufacturer runs four to seven software systems. ERP for job tracking and invoicing. CAD/CAM for programming. A quality management system. A scheduling tool, possibly a spreadsheet. An accounting package. Maybe a CRM. And email, which ends up holding more operational data than any purpose-built tool.

None of these were designed to work together. Purchased at different times, from different vendors, to solve different problems. The ERP vendor did not anticipate your quality system's data would need to flow into quoting. The CAD/CAM vendor did not build an integration with your scheduling spreadsheet. The accounting software does not know your ERP exists.

Information moves between systems the same way it has for decades: a person looks at one screen, remembers or writes down what they see, walks to another screen, types it in again.

The Real Cost of Disconnected Systems

A production planner at a 60-person precision machining shop in Michigan described her Monday morning. She opens the ERP for this week's jobs. Opens a shared spreadsheet for machine availability. Walks to the floor to verify the whiteboard matches the ERP. Checks email for material delivery confirmations from three suppliers. Opens the quality system for open nonconformances affecting this week's schedule.

Two hours to get a complete picture. Five systems. Three trips to the floor. Accurate as of 9:00 AM Monday. By 11:00 AM, something will change and parts of it will be wrong.

Multiply this across every role needing information from more than one system. Total labor hours moving information between disconnected systems in a typical 50 to 100 person shop: 800 to 2,000 hours annually. At a blended rate of $35 per hour, $28,000 to $70,000 in data transfer labor alone.

The labor cost is measurable. The decision cost is larger. Every decision made with incomplete information because assembling the full picture takes too long carries an accuracy penalty. Quotes take longer and contain more errors. Schedules miss dependencies one system knows about but another does not. Quality issues recur because the connection between a nonconformance and the job parameters causing it lives in two databases with no link.

Why Traditional Integration Fails

A 2023 Gartner report found that 65% of ERP integration projects in mid-market manufacturing exceed original budget by at least 50%. Average timeline: 9 to 18 months. Many stall after the vendor discovers the ERP's database schema does not support assumed data mapping.

Traditional integration tries to make systems speak the same language natively. Mapping every field in System A to a corresponding field in System B, handling every edge case where formats differ, maintaining that mapping as both systems get updated. For systems designed in different decades by different teams with different data models, this is an enormous engineering effort.

A stamping shop in Indiana spent $180,000 on an ERP-to-quality-system integration in 2022. Fourteen months to complete. The integration handled about 70% of data flow. The remaining 30% still required manual entry because field mappings could not account for custom quality codes. Two years later, a major ERP update broke three data pipelines. Fix cost: $40,000.

The integration works until it does not. Maintenance burden grows. The promise of seamless data flow remains partially fulfilled.

A Different Approach

Stop trying to make systems talk directly. Build a layer that reads from all of them.

An operational data layer. Connects to the ERP database as a read source. Connects to the quality system the same way. Ingests the scheduling spreadsheet. Reads supplier emails. Pulls whatever structured or unstructured data the operation generates. Rather than forcing common language, the layer translates from each system into a common structure supporting the queries people actually need.

Three advantages over traditional integration.

No existing system changes. The ERP keeps running as-is. Quality system stays. No data migration, no field mapping, no vendor coordination. The data layer reads from these systems without writing to them, modifying them, or depending on stable APIs.

Handles unstructured data. Traditional integration only works with structured databases. An operational data layer also ingests PDFs (inspection reports, supplier certifications, job travelers), emails (supplier quotes, customer communications, internal notes), and images (setup photos, whiteboard schedules). Modern language models can read a PDF inspection report, extract measurements, and structure them alongside the corresponding ERP job record.

Incremental. Start with the two systems whose disconnection causes the most pain. For most shops, the ERP and quoting process. Or the ERP and scheduling. Connect those first, prove value, expand. Traditional integration is all-or-nothing. An operational data layer delivers value in month one and grows from there.

How It Works in Practice

Step one: map data sources. List every system, spreadsheet, shared drive, and email thread where operational data lives. This exercise alone is revealing. The owner thinks four systems. Mapping reveals seven, plus a dozen spreadsheets and two shared drives of PDFs referenced daily.

Step two: identify high-value connections. Where does a person serve as bridge between two systems? Where does someone look at Screen A, walk to Screen B, then decide based on both? Those bridges are the targets. Each represents labor hours, decision latency, and error risk.

Step three: build connectors. Standard ERP schemas get read connections pulling data on schedule or in real time. Unstructured sources get AI-powered extraction: reading PDFs, parsing emails, converting to structured data. Spreadsheets get either direct file reading or lightweight interfaces capturing the same data in queryable format.

Step four: build the query interface. The tool people actually use. Maybe a dashboard showing production status from ERP alongside quality data alongside material delivery status from supplier emails. Maybe a search tool where an estimator types a part number and gets full history from every system that part has touched. Form depends on workflow. Principle is consistent: bring data to the person, structured around the decision they need to make.

What Changes When Systems Are Connected

The production planner who spent two hours assembling Monday's picture opens one screen. Job status from ERP, machine availability, material delivery confirmations, open quality holds all visible in a single view. Monday morning takes fifteen minutes instead of two hours.

The estimator who searched the ERP, checked emails for material pricing, then walked to the floor gets all information surfaced automatically when opening an RFQ. Quote cycle drops from days to hours.

The quality manager who manually cross-referenced nonconformance reports with ERP job parameters sees correlations automatically. Three jobs with the same material and tolerance band showing the same dimensional issue get flagged. A pattern that took weeks to notice becomes visible in real time.

None of this replaces any existing system. The ERP stays. Quality system stays. Accounting stays. What changes is that data trapped inside each one now flows to people who need it across system boundaries.

The custom tools we build at Bloomfield sit on top of your existing systems, read from all of them, and deliver the connected picture your team has been assembling manually for years.