Long before “IIoT” became a standard term, manufacturing plants already had a real problem to solve. Data was everywhere on the shop floor, but nowhere at the same time. Control systems knew what was happening second by second. Labs held critical quality data. ERP systems expected clean, structured inputs. And people in between were stuck stitching everything together manually.
This post is about one of those projects: a large US-based titanium dioxide (TiO₂) pigment plant, delivered between 2016 and 2017, and an SAP MII-based manufacturing intelligence implementation. The work focused on integrating process control data, quality management, and batch tracking to enable real-time visibility and decision-making in the plant. It was not an IoT project by today’s definition, but it faced many of the same challenges we still deal with in IIoT initiatives today: connecting heterogeneous shop floor systems, contextualizing data, integrating production with ERP, and making information usable across roles.
Why Titanium Dioxide Manufacturing Exposes Data Problems Fast
Titanium dioxide production is continuous, complex, and sensitive to variation. Small drifts in process conditions can turn into quality losses, scrap, or even shutdowns. The process spans digestion, hydrolysis, filtration, calcination, and finishing. Each step generates data, but historically, that data lived in separate systems.
At this plant, the landscape was familiar. DCS and SCADA systems controlled the process. PLCs from different eras handled auxiliary equipment. A historian stored years of data, but only a few specialists could really navigate it. Labs generated quality results that were typed manually into SAP. Operators relied on paper logs and experience. Engineers lived in spreadsheets. Management asked for KPIs, but trust in the numbers was low.
Quality control was a major pain point. Lab results were manually entered. SAP outages meant data gaps or delayed entries. There was no real statistical process control. No automated off-spec detection. No reliable way to connect lab results to a specific batch, shift, or process event. By the time problems were visible, material was already off-spec.
The Objective. Connect the Shop Floor to ERP in a Meaningful Way
The goal was not to replace systems. It was to connect them.
The project focused on three core objectives:
- Collect reliable, real-time and historical data from shop floor systems.
- Contextualize that data so it could be tied to batches, materials, and production events.
- Integrate production and quality data with SAP ERP in a way that supported daily operations.
SAP MII was chosen as the central integration and intelligence layer. It acted as the bridge between control systems, historians, lab systems, MES functions, and SAP ERP.
What Was Actually Built
Shop Floor Integration
Process data was collected from PLCs, SCADA, and DCS systems using OPC DA and HDA connections. This allowed access to both live values and historical trends. Existing historians such as AVEVA PI (formerly OSISoft PI) and Aspen InfoPlus.21 were integrated to avoid duplicating storage and to leverage existing investments.
Critical parameters were pulled from key production steps. Temperature, pressure, flow, levels, and pH were all part of the dataset. Data collection itself was not the hardest part. Contextualizing it was.
Lab Data Integration
Lab systems were one of the most complex areas. Some instruments exported files. Some communicated over serial connections. Some only printed results. Custom adapters and parsers were built to extract results digitally whenever possible.
Each lab result had to be tied back to the correct batch, material, and production window. Without that link, quality data had little operational value. This step required close collaboration with quality teams and a lot of iteration.
SAP Integration and Manufacturing Intelligence
SAP MII was integrated with SAP ERP to pull master data such as materials, batches, and inspection lots. It also pushed validated production and quality data back into SAP.
On top of that, manufacturing intelligence applications were built. Operator dashboards showed live trends and SPC charts. Engineers had access to historical analysis and batch genealogy. Managers saw production KPIs that were finally aligned with what was happening on the floor.
Implementation. Why It Took Time
This was not a plug-and-play rollout.
Processes had to be redesigned to match the new digital backbone. Offline scenarios had to be handled. Operators were trained gradually. Old and new workflows ran in parallel until confidence was built.
Web-based dashboards were introduced so data could be accessed beyond the control room. Internal teams were trained to support and extend the solution. That ownership was critical. Without it, the system would not survive beyond the initial rollout.
The Challenges That Really Mattered
- SAP downtime and data loss: When SAP was unavailable, manual entries caused gaps and sequencing issues. Offline buffering and controlled synchronization logic had to be built to preserve data integrity.
- Manual lab processes: Not all lab equipment could be modernized. The project focused on automating what was feasible and designing controlled manual steps where needed.
- Lack of SPC and early warning: Before the project, quality deviations were often detected too late. SPC dashboards and real-time off-spec alerts were implemented so deviations were visible while corrective action was still possible.
- Data quality and trust: Sensor issues, unused tags, and calibration problems surfaced quickly once data became visible. Side-by-side validation with manual readings was essential to build trust with operators and engineers.
- Legacy systems and vendor constraints: Some integrations required extensive coordination with vendors and workarounds for proprietary interfaces. Progress was incremental, not instant.
- Change management: People were used to their tools and routines. Adoption required training, feedback, and screen redesigns. Technology was rarely the blocker. Habits were.
What the Plant Gained
The results were tangible.
- Scrap was reduced by roughly 700 tons per year at the first plant, representing around $500,000 in savings.
- Asset utilization improved due to earlier detection of process deviations.
- Quality investigations became faster and more reliable because process and lab data were finally connected.
- The architecture was reusable. Templates and integration patterns enabled rollout to additional plants with lower effort.
What This Has to Do with IIoT
This was not an IoT project in the modern sense. There were no cloud platforms or MQTT brokers involved at the time. But the core problems were the same ones IIoT initiatives still face today.
- Multiple heterogeneous shop floor systems.
- The need for reliable, contextualized data.
- Integration between operations and ERP.
- Making data usable across roles, not just available.
Many IIoT projects struggle not because of technology, but because these fundamentals are ignored. This SAP MII project reinforced how critical those basics are.
A Practical Takeaway
Manufacturing intelligence does not start with advanced analytics or AI. It starts with connectivity, context, and trust in the data. Whether the platform is SAP MII, a modern IIoT stack, or something in between, the principles remain the same.
If those foundations are solid, everything else becomes possible. If they are not, no architecture diagram will save the project.
Final Thoughts
This project remains a useful reference point for me. It showed that meaningful shop floor connectivity and ERP integration can deliver real value, even in complex, continuous process environments like titanium dioxide manufacturing.
The tools have changed since then. The problems, for the most part, have not.
Leave a Comment