Your plant lost four hours of production last Tuesday. The equipment was fine. No operator made an error. No material was missing. The MES (Manufacturing Execution System, the software layer that tracks production orders and machine status) stopped talking to the ERP (Enterprise Resource Planning system, the back-office software that handles inventory and orders). Until the IT team figured out that a routine Windows patch had broken the connector service, your line was running blind and supervisors had to shut it down.
This kind of downtime does not show up in a “mechanical failure” report. It gets logged under some vague “systems issue” code, filed, and forgotten. And because it is not tracked with the same rigor as equipment downtime, most plants do not know how much of it they are actually absorbing.
Research from Siemens’ 2023 True Cost of Downtime report (a commonly cited industry benchmark) estimates that unplanned downtime costs Fortune Global 500 manufacturers $1.5 trillion per year, with the median cost exceeding 10% of productive capacity for heavy industry. A meaningful share of those losses trace back to IT and network issues that were treated as low-priority until they hit production.
The Problem: IT Failures Don’t Look Like IT Failures
The traditional picture of a “downtime event” is mechanical. A spindle breaks. A robot throws a fault. A bearing seizes. Maintenance replaces the part, and the line comes back.
IT-driven downtime looks different. A few examples we see repeatedly:
- A Windows update reboots a critical PC during first shift. A machine that used that PC as its operator interface is down for 45 minutes.
- An industrial switch fails in the aggregation rack. Five production cells lose communication with the MES. Production continues but quality data stops flowing, and the shift supervisor calls for a stop because the downstream audit trail is broken.
- Active Directory has a replication issue overnight. In the morning, half the shop floor cannot log in. The line starts 90 minutes late.
- A ransomware detection on a back-office server triggers a conservative response. IT segments the network as a precaution. OT systems lose access to file shares they depend on. Production stops for three hours until scope is confirmed.
- A vendor’s remote access session leaves a process in an inconsistent state. The operator comes on shift, the system does not behave normally, and an hour of troubleshooting follows.
None of these are “equipment failures.” None of them are tracked the same way. None of them trigger the root-cause analysis that a mechanical failure would. And all of them are expensive.
Why It Matters to You Specifically
For a plant manager or operations director, this category of downtime hits three areas:
Unmeasured Losses Accumulate
If your downtime reporting does not break out IT and network causes with specificity, you are systematically understating the problem. The budget for IT improvements competes against capital requests for new equipment, and the equipment requests have hard numbers behind them. The IT requests often have vague “stability” justifications that do not win the argument. Better measurement is the first step to better investment.
Cybersecurity Incidents Are Now a Top-5 Downtime Cause
IBM’s 2024 Cost of a Data Breach Report found that the industrial sector carries the highest per-incident breach cost of any industry, largely because of operational downtime associated with response and recovery. Manufacturing has been the most-attacked industry for ransomware for several consecutive years, according to IBM X-Force. The question is not whether IT-driven downtime will grow as a share of your losses. It will. The question is how prepared you are when it does.
Your Continuous Improvement Program Is Missing Half the Picture
Lean manufacturing methods are rigorous about mechanical causes. They are often silent about IT causes because IT is someone else’s department. A Kaizen event on a pressing line will tear apart a hydraulic fault. The same plant might accept a 6-hour MES outage as “just what happens.” The improvement opportunity in the second case is often larger than in the first.
What Good Looks Like
A plant that has gotten ahead of IT-driven downtime looks different from a plant that has not.
Downtime Codes That Distinguish IT and Network Causes
At minimum, your MES or production logging should have distinct codes for:
- Network outage (LAN, industrial network, wireless)
- Server or system outage (ERP, MES, historian, domain services)
- Endpoint failure (HMI, operator station, scanner)
- Planned IT change causing unplanned impact (patching, updates, migrations)
- Security response (detection, isolation, investigation)
With these codes in place, the data starts telling you where to invest.
Change Management That Respects Production Schedules
IT changes on production-critical systems should not happen during production hours without explicit coordination. This sounds basic. It is violated constantly when corporate IT applies a patch policy globally without understanding the operational impact. The fix is a documented change management process that includes operations as a stakeholder, with production downtime windows coordinated explicitly.
Segmentation Between IT and OT
The CISA guidance on OT/IT network segmentation is the practical starting point. A plant where an AD replication problem can bring down a packaging line has a segmentation problem. A plant where ransomware on the corporate side can reach PLCs has a segmentation problem. Proper segmentation means IT issues stay in IT, and OT issues stay in OT, as much as technically possible.
Monitoring That Catches Issues Before Operators Do
Operations staff should not be the first to notice that a network link is down or a server is struggling. Proper monitoring (of servers, network equipment, and the application health of production-critical systems) catches issues minutes to hours before they cascade into production. The investment in monitoring tools is small relative to the downtime they prevent.
An Incident Response Plan That Includes Operations
The IT incident response plan usually prioritizes data protection. The operations incident response plan usually prioritizes physical safety. These two plans need to be reconciled so that a cybersecurity event does not trigger a response that is more damaging to production than the incident itself. This is especially important in environments where corporate IT has the authority to “pull the cord” on network segments during an incident.
Practical Takeaways
- Audit your current downtime data for IT codes. If you cannot tell the difference between “mechanical failure” and “network outage” in your current reporting, that is the first fix.
- Review the last three months of unplanned downtime events. How many had an IT root cause or contributing factor? Nearly every plant is surprised by the answer.
- Check your change management process. If Windows updates, patching, or system changes can happen during production hours without operations approval, you have a known upcoming problem.
- Look at your IT/OT segmentation with fresh eyes. A failure on one side should not stop production on the other side. If it can, that is a priority remediation.
Plants that get a handle on IT-driven downtime typically see total unplanned stoppage fall by double-digit percentages without touching a single piece of equipment. The opportunity is sitting in your logs right now.
If you want a conversation about assessing IT and OT downtime drivers at your plant, the HVR Cloud team does this for manufacturers on a regular basis. Get in touch and we can talk through what a review would look like.