In 30 seconds
- Setting: the night shift at an electronics plant. Production line 3 freezes at around 2am every night, and nobody knows why.
- What Motadata did: Motadata ServiceOps turned scattered shop-floor complaints into one tracked problem; Motadata ObserveOps showed a network switch overloading at the same minute each night, caused by a device nobody had recorded.
- Business point: Astiostech, a Malaysian technology company, implements Motadata ObserveOps, a unified observability platform, and Motadata ServiceOps, an ITSM, ITAM and patching platform. Together they help manufacturers stop small, repeating IT problems from becoming lost production.
Plant networks that grow faster than their records
Modern factories run on IT as much as on machines. Production lines depend on manufacturing execution systems, terminals, scanners, printers and the network that connects them. More and more, those devices share a network with office systems, cameras and building equipment.
Plant IT teams are usually small, and the problems they face are familiar:
• Devices appear on the plant network without IT knowing, installed by contractors, facilities teams or equipment vendors.
• Problems repeat at odd hours, on night shifts, when the people who notice them are not the people who can fix them.
• Shop-floor issues are reported by phone or chat messages, so nobody can see the pattern across several nights.
• Asset records fall behind reality, so IT cannot tell what is connected where.
• Every fix competes with production, because a line that stops costs output, and some systems, such as security, cannot simply be switched off.
The illustration
At 2:03am on Thursday, Pak Hamid, the night shift supervisor on line 3, watched every terminal on his line freeze for the third night in a row.
Scanners stopped. Label printers stopped. The screens showed the little spinning circle that means "please wait" in every language. Twenty minutes later, as mysteriously as it had started, everything came back. By then the line had lost part of a batch, two operators had restarted their scanners out of hope rather than reason, and someone had suggested, only half joking, that line 3 was haunted.
Until last month, Pak Hamid would have sent a voice note to the IT WhatsApp group, where it would have sat between a birthday greeting and a photo of somebody's new car. Now he opened the self-service portal on his phone and logged it in Motadata ServiceOps. So had the line leader, and the quality technician, each in their own words.
At 8am, Syafiqah, the plant's IT manager, opened ServiceOps with her first coffee. Incident clustering had grouped the reports from all three nights into one problem: line 3 terminals freezing around 2am. Three nights. Same line. Same time. That was not bad luck. That was a schedule.
Mr Lee, the plant manager, stopped by her desk at 8:30am. "Is it the new AI thing?" he asked. He had asked this about every problem since the plant bought a chatbot for the canteen menu. "Not this time," said Syafiqah. "Give me until lunch."
She opened Motadata ObserveOps and went back to 2am. The production servers were fine. The manufacturing execution system was fine. But the network switch serving line 3 told a different story: at 2:00am each night, its uplink filled to the brim and stayed full for about twenty minutes. Every terminal on the line was trying to talk through a pipe that something else had already filled. ObserveOps had raised an alert each night, and each alert had opened an incident in ServiceOps, which was how Pak Hamid's reports had found company so quickly.
Log monitoring showed the switch had learned a new device on one of its ports eleven days ago. Syafiqah checked the CMDB in ServiceOps. Nothing was recorded on that port. According to the plant's records, it was empty.
Records are only as good as the last person who updated them. So at 1:50am on Friday, Ah Keong, the night IT technician, walked line 3 with a torch, following cables like a man tracing the roots of a very old tree. He found two forgotten network cables, an empty mouse nest and a calendar from 2019 before he found what he was looking for.
It was behind a panel near the loading bay: a new grey box, blinking cheerfully, with a handwritten label on top. "JANGAN USIK. FACILITIES."
It was the new CCTV recorder. Facilities had installed it the week before, to meet the insurer's new security requirements. Every night at 2am, it uploaded the day's footage to head office, through the same switch line 3 used.
Ah Keong sent a photo to Syafiqah with a single word: "Found." Then, because it was 2am and he was proud, a second word: "Torch."
The obvious fix was to unplug the box. Syafiqah did not even consider it. The cameras were a security requirement, and switching them off would solve her problem by creating one for the plant manager, the insurer and possibly the police. Production could not stop either. Both systems had a right to be there. They just could not share a switch at 2am.
So the decision was not about which system won. It was about who needed to talk to whom.
At 9am, Syafiqah called Encik Zul from facilities. He was horrified, then helpful. Nobody had told him the plant network was used by the production line. Nobody had told her that facilities had a box on it. Both statements were true. The installer had simply asked for "a network point", and the nearest one happened to be on the production network. Nobody had asked a second question, because nobody had known there was a second question to ask.
They agreed on two steps. That night, facilities moved the recorder's upload from 2am to the twenty minutes of the evening shift change, when line 3 was between batches and the switch was quiet. At the next planned maintenance window, IT would move the recorder to its own separate network. Syafiqah raised the change in ServiceOps with the ObserveOps evidence attached, and the plant manager approved it.
Before she closed the problem, Syafiqah added the recorder to the CMDB: its location, its owner (facilities), the switch port and the service it supported. Then she added a new step to the facilities workflow in ServiceOps: any new device on the plant network starts with a change request to IT.
At 2am that night, Pak Hamid stood beside line 3 with his arms folded, daring it to freeze. Ah Keong stood beside him with the torch, just in case.
It didn't. The scanners scanned. The printers printed. On ObserveOps, the switch's uplink stayed comfortably in the middle of its range. Pak Hamid logged one last entry in ServiceOps, which the system dutifully categorised as feedback: "Line 3 OK. Please thank the torch man."
On Monday, Encik Zul came to the IT office with a box of kuih and a new label for the recorder. It read: "JANGAN USIK. FACILITIES. ALSO IT. WE ARE FRIENDS NOW."
Key points: the problem and how Motadata solved it
| Common manufacturing problem | What happened in the story | How Motadata helps |
| Shop-floor issues reported by phone or chat | The supervisor logged the freeze through the self-service portal | Motadata ServiceOps self-service and virtual agents give shop-floor staff one place to report issues |
| Repeating night-shift problems go unseen | Reports from three nights clustered into one problem | ServiceOps incident clustering reveals patterns across separate reports |
| The cause hides in the network | The line 3 switch's uplink filled at 2am every night | Motadata ObserveOps network monitoring and log monitoring show when and where capacity runs out |
| Devices appear without IT knowing | The switch learned a new device on a port the CMDB showed as empty | ObserveOps log monitoring spots the new device; ServiceOps IT asset management and CMDB show what should be there |
| Some systems cannot simply be switched off | The CCTV recorder was a security requirement, so its upload was moved instead | Tools find the conflict; people agree on a fix that works for both production and security |
| Changes by other teams bypass IT | Facilities now raise a change request for any new network device | ServiceOps change management and workflow orchestration bring every team's changes into one process |
FAQ
What is Motadata ObserveOps? Astiostech, a Malaysian technology company, implements Motadata ObserveOps, a unified observability platform. It covers hybrid infrastructure, application and network monitoring, traces, log monitoring, real user monitoring, SLO monitoring and network configuration compliance, with AI anomaly detection, cross-domain correlation, forecasting and alert-noise reduction.
What is Motadata ServiceOps? Astiostech implements Motadata ServiceOps, an ITSM, ITAM and patching platform. It provides a service desk with change management, IT asset management and CMDB, patch and endpoint management, workflow orchestration, self-service and virtual agents, and AI ticket categorisation, routing and incident clustering.
Can Motadata monitor networks in a manufacturing plant? Motadata ObserveOps provides hybrid infrastructure and network monitoring, including network devices such as switches. Coverage of specific production equipment should be confirmed during an assessment.
How does Motadata help plant IT teams with small staff numbers? Motadata ServiceOps groups related reports, routes tickets automatically and gives shop-floor staff self-service, while Motadata ObserveOps alerts can open incidents in ServiceOps automatically. That reduces manual triage for small teams.
What does Astiostech do for Motadata customers in Malaysia? Astiostech implements Motadata products: discovery, architecture, deployment, integration, training and ongoing support. Read more on the Motadata page.
Lets Talk
Book a 20-minute IT asset and service desk walkthrough
Disclaimer
This story is fiction. The electronics plant and every person in it are imaginary. The product capabilities shown are taken from Astiostech's published product information and capabilities confirmed by Astiostech.
More in the series
Read the other industry stories: banking, telco, government and hospital, each showing how Motadata helps solve a common problem in that sector.