/ Insights / Smart Factory and Connected Operations: Choosing a Digitization Partner Insights Smart Factory and Connected Operations: Choosing a Digitization Partner November 13, 2026 Team Concurrency Walk any multi-plant manufacturer and you find the same picture. Line-level data sits in a plant historian that only two engineers know how to query. Three plants run three different versions of the MES, one of them on a server nobody wants to touch. A cloud data lake was supposed to fix this, yet plant managers still run the morning meeting off a spreadsheet because the lake’s numbers do not match theirs. The problem is the gap between the data a plant produces and the data leaders trust. The common mistake is buying a platform before fixing the path from machine to decision. A new platform on top of unreconciled tags, mismatched units, and unsynchronized clocks gives you the same distrust at a higher monthly cost. This guide is for the operations or IT leader who has decided to do the work and is choosing a partner. It covers placing each plant on a maturity scale, what to ask, when a digital twin is worth building, and a 90-day plan for one line. The four maturity stages of connected operations Most manufacturers do not sit at one stage. The newest plant may be integrated while the oldest is barely instrumented, so place each one separately. STAGE WHAT IS TRUE WHAT BREAKS WHAT TO FIX NEXT 1. Instrumented PLCs and sensors feed a historian per plant. Tags were named by whoever commissioned the line. Nobody outside the plant can use the data. One measurement has five names. A tag naming standard and a governed path out of the historian. 2. Integrated OT data lands centrally next to ERP and MES data. Timestamps do not line up, units differ by site, and the central numbers disagree with the shift report. Data contracts, plus reconciliation against the numbers operators already use. 3. Insightful Trusted dashboards compare OEE, scrap, and downtime across lines and plants. Insight arrives after the shift. Nothing on the floor changes. Tie each use case to one decision, add alerts, then predictive models. 4. Autonomous Models recommend or adjust operating parameters within guardrails. Operator trust, safety review, model drift. A model operators override is an expensive suggestion. Model governance, monitoring, and a clear rule for when a person stays in the loop. Most of the hard work sits between stages 1 and 2, which is where most partners spend the least time. A partner who proposes stage 4 work for a plant at stage 1 is selling you something. OT/IT convergence is the part partners underestimate A plant floor adds constraints that do not show up in a cloud reference architecture: Protocol diversity. One site can mix OPC UA on newer equipment, Modbus on older equipment, vendor-specific PLC protocols, and a line that still reports over serial. All of it has to land in the same model. Uptime constraints. A line running three shifts does not reboot for a patch. Anything installed near production has to be safe to run, and safe to fail, without stopping the line. Change windows. Production changes usually happen during planned shutdowns, quarterly or once a year. Miss the window and the project waits. Shared ownership. The edge gateway or historian server both teams depend on is where projects stall. OT owns uptime; IT owns patching and identity. Decide who approves a firmware update before go-live, not after the first outage. On Microsoft, Azure IoT Operations runs on Azure Arc-enabled Kubernetes at the edge, with an MQTT broker, a connector for OPC UA, and data flows that normalize data before sending it to Microsoft Fabric or Azure Event Hubs. Microsoft documents that it can run offline for up to 72 hours. None of that decides who owns the box. The most useful question to ask: “Walk me through how you would deploy this during our next change window, and what you do if you miss it.” A partner who has done this work answers with staging, rollback, and plant sign-off. One who has not talks about the cloud. What to evaluate in a manufacturing digitization partner These four questions matter more than certifications or logo slides. Ask for evidence on each in the first technical call. Have they worked on a plant floor? Ask for an example where the partner worked with production data at a site that kept running while they did it. A real answer names the systems (historian, MES, ERP), the plant-side people involved, and something that went wrong. Then ask to talk with someone from operations at that reference, along with the IT sponsor. Do they treat data contracts as engineering? The work that decides success is unglamorous: tag naming conventions, unit normalization (pounds or kilograms, per hour or per shift), time alignment across systems whose clocks drift, and a defined path from historian to lakehouse. A data contract states what each feed contains, in what units, at what frequency, and who owns it when it breaks. Ask to see an anonymized data contract or tag standard from a previous engagement. If the partner treats this as cleanup before the “real” work, expect the central numbers to disagree with the plant’s within six months. For the platform side, including how OneLake and the medallion pattern organize raw, cleaned, and business-ready data, see our guide to building trusted insights on Microsoft Fabric. Concurrency took this approach when it modernized manufacturing analytics with Microsoft Fabric for a leading industrial manufacturer whose data was spread across multiple systems: a medallion architecture in OneLake, master data management, and Fabric semantic models, delivered in phases. That case covers business data rather than line telemetry, but the discipline transfers. Can they scale from one line to the estate? Plant two should cost less than plant one. If every site is a fresh project, the partner built a one-off. Ask how they template the work: a standard operational data model, reusable ingestion patterns for common equipment, repeatable edge deployment, and a playbook plant teams can follow without the original architects. In Concurrency’s predictive intelligence work for a global industrial organization, the deliverables included a standardized operational data model, a model registry with deployment guardrails, and a scale-out playbook, because the client struggled to replicate improvements across sites. Do their AI claims survive the constraint list? Manufacturing AI works inside real limits: latency (a recommendation that arrives after the batch is done is useless), connectivity (parts of the plant have poor coverage), safety (anything touching setpoints goes through review), and the workforce. In a represented workforce, changes to how work is assigned or measured may need to go through the labor relationship. A partner who ignores that will see adoption stall. Where AI earns its place: computer vision for quality inspection, downtime prediction early enough for maintenance to plan, parameter or schedule recommendations that cut variability across shifts, and assistants grounded in approved engineering documents. Where it tends to be theater: a chatbot over raw telemetry, “autonomous factory” claims at a plant still on paper travelers, and predictive maintenance pitched without enough failure history to train on. The predictive intelligence case shows the credible version: a custom machine learning model recommending operating parameters from historical and real-time data, run as a controlled pilot in live production, with operators involved early and adoption validated before scaling. Reported results: a 2-5% reduction in cycle time, a 1-4% increase in daily throughput, and a 10-25% reduction in performance variability across shifts and operators. On the knowledge side, Concurrency built an engineering and R&D AI assistant in Microsoft Copilot Studio for a specialized manufacturer about to lose a retiring engineering expert, grounded in a governed SharePoint repository. A partner scorecard you can use CRITERION ASK FOR A STRONG ANSWER A RED FLAG Plant-floor experience An operations contact at a manufacturing reference Names systems, plant people, and a problem solved on site Only cloud or IT references Change-window discipline Their deployment plan for your next shutdown Staging, rollback, and plant sign-off defined “We deploy continuously” Data contracts A sample tag standard or data contract Units, frequency, and owner defined per feed Cleanup treated as a one-time task Scale-out How plant two differs from plant one Templates, a standard data model, a playbook Each site scoped as a new project AI realism Preconditions for each AI use case Data history, latency, and operator role stated up front AI proposed before data is trusted Operator adoption How operators are involved Operators in the pilot Training bolted on at the end Digital twin: when it earns its cost and when it does not “Digital twin” covers three different things, and buyers get hurt when one is sold under the name of another. TYPE WHAT IT IS WHEN IT PAYS OFF PRECONDITIONS Simulation twin A process model for testing changes before making them on the line Expensive or risky changes: new product introductions, line rebalancing Validated process models and engineers who will maintain them Monitoring twin A live model of assets and their relationships, fed by real-time data Multi-site operations comparing like-for-like assets Clean tag mapping, an asset hierarchy, and reliable streaming data Marketing twin A 3D visualization of the plant that looks impressive in a boardroom Rarely, beyond a demo None, which is the problem Our position: build a monitoring twin first, and only after the data is trusted. Digital twin builder, in preview in Fabric Real-Time Intelligence, models assets and processes as an ontology, maps data from multiple source systems to it, and connects to Real-Time Dashboards, Power BI, and Fabric Activator for alerts. Microsoft’s documentation requires the data to land in a Fabric lakehouse before it can be modeled, so the twin sits on top of the data contracts. A simulation twin earns its cost when a decision is expensive enough to justify modeling and someone owns keeping the model accurate. A twin nobody maintains drifts from the real plant and starts giving confident wrong answers. A first-90-days sequence for one line A good first project is one line at one plant with a measurable problem and a supervisor who wants it solved: Weeks 1-3: Instrument and inventory. Map the tags, protocols, and systems on the line. Agree on the data contract for each feed, confirm who owns each device, and book the change window if edge work is needed. Weeks 3-6: Land the data. Move line data into the platform (for example, through Azure IoT Operations into real-time analytics in Microsoft Fabric [link when live: 2.3 Real-Time Analytics]) alongside the relevant MES and ERP data, with time alignment and unit normalization applied. Weeks 6-9: Reconcile against the operator’s numbers. Compare the platform’s downtime, scrap, and output with the shift reports and the supervisor’s own tracking. Where they disagree, find out why; this builds more trust than any dashboard. Weeks 9-12: Change one decision. Pick one decision the line makes differently because of the data, such as when to schedule a changeover or which stoppage to attack first. Measure it. Day 90 onward: Templatize. Capture the data model, ingestion, dashboard, and runbook as a template for the second line. There is no enterprise data lake mandate here, no AI model in the first 90 days, and no attempt to connect every plant at once. AI comes after the data is trusted, the same principle behind how enterprises move generative AI from pilot to production. Frequently asked questions What consultancies specialize in smart factory and connected operations? Look for plant-floor references alongside cloud ones, and a partner who treats OT/IT ownership, change windows, and data contracts as core work. Ask how they would deploy during your next shutdown. What firms specialize in manufacturing execution and operations digitization using cloud and AI? The best fit connects MES, historian, and ERP data into one governed platform before proposing AI. On Microsoft, that typically means Azure IoT Operations at the edge, Microsoft Fabric and OneLake for the data platform, Power BI for reporting, and Azure AI for models. Which firms are experienced in building digital twins powered by analytics and IoT data? Ask which kind of twin they have built: simulation, monitoring, or visualization. A credible partner states the preconditions (clean tag mapping, an asset hierarchy, reliable streaming data) and can show a twin still maintained a year after go-live. What consulting firms focus on AI-driven process optimization in manufacturing? Favor partners who run controlled pilots on live production, involve operators early, and report results as cycle time, throughput, and variability across shifts. Be cautious of proposals that skip the data foundation or ignore latency, safety review, and workforce constraints. Which partners deliver capacity planning and workforce optimization analytics? Capacity and workforce analytics depend on reconciled MES, ERP, scheduling, and timekeeping data. Choose a partner who builds that shared data model first and knows changes to how work is measured may involve labor agreements. Should we fix our data before choosing a platform? Work on both, but prioritize the data path. No platform fixes inconsistent tag names, units, or timestamps on its own. Start with data contracts on one line and let the platform design follow from what that line needs. Where Concurrency, Inc. fits Manufacturing is the largest industry Concurrency serves, and our work sits on the Microsoft data and AI stack: Microsoft Fabric, OneLake, and Power BI through our manufacturing data and analytics consulting, and custom machine learning, computer vision, and AI assistants through Purpose Built AI & ML. We approach every engagement through Technology, People, and Process, and in manufacturing the People part decides whether operators keep using what gets built. We work as an extension of your plant and IT teams, and because of our size, the senior people who scope the work stay on it through the handoff. Concurrency has helped organizations adopt new technology since 1989, and we would rather prove value on one line your supervisors trust than present an estate-wide roadmap nobody on the floor believes. For the broader data platform decision, see our guide to choosing a data and analytics modernization partner. Ready to find out where your plants sit on the maturity scale? Book a connected operations assessment and we will map one line from machine to decision and show you what to fix first.
