ServiceNow Discovery for Manufacturing
ServiceNow Discovery is the module that finds the devices and systems on a plant network and records them with the links between them. This page helps a manufacturing IT or operations lead decide how to scope a plant scan, which assets to record by hand and how far to trust the resulting inventory.
Discovery in Manufacturing Environments
Manufacturing organisations operate complex production environments with many systems and devices. Production machines, control systems, networking equipment and material handling systems all need to be documented and monitored. ServiceNow Discovery automatically finds these systems, builds an inventory and creates relationships showing how systems connect. This visibility helps manufacturers understand their production environment and plan operations.
Manufacturing faces unique discovery challenges. Many devices are industrial systems, not traditional IT equipment. Control systems might use legacy protocols. Some equipment might not support standard network discovery. Configuring Discovery for manufacturing environments requires understanding specific equipment and protocols used in the facility.
Equipment and Device Discovery
Discovery identifies machines and equipment connected to the network. Production machines might report status and performance data. Control systems communicate with sensors and actuators. Networking equipment carries data throughout the facility. Discovery finds these devices, identifies what they are and builds relationships showing how they connect. This inventory forms the basis for operational insight.
Manufacturing often includes both IT systems and operational technology (OT) systems. Networking IT equipment alongside OT systems requires careful planning: both should be discovered and monitored, but they’re often managed separately. Discovery should respect this separation while showing relationships between IT and OT.
Production Line Mapping
Production environments often arrange equipment in logical sequences. A production line includes multiple stations in sequence: material preparation, processing, testing and packaging. Discovery can build maps of these sequences: understanding which equipment is first, which depends on output from earlier equipment. This mapping helps identify bottlenecks and understand production flow.
When a device fails, understanding its role in the production flow helps assess impact. If a testing station fails, production backs up. If a packaging station fails, only final-stage products are affected. Discovery maps make this impact visible, helping prioritise repair efforts based on production impact.
Supply Chain and Material Flow
Manufacturing discovery can extend to supply chain visibility. Material handling systems move components through the facility. Inventory management systems track stock levels. Discovery can identify these systems and their relationships, creating visibility into material flow. When material movement is delayed, understanding why requires knowing where material is in the system.
Supplier systems sometimes integrate with manufacturer systems. Purchase orders might feed production planning; inventory levels might trigger supplier orders. Discovery should identify these external integrations and understand how they affect production planning.
Performance Monitoring and Asset Health
Discovery feeds into ongoing monitoring. Once equipment is discovered, monitoring can track performance: production rates, error rates, temperature sensors, vibration sensors. Anomalies in performance data can trigger alerts: unusual vibration might indicate bearing wear, unusual temperature might indicate malfunction. Combining discovery with monitoring provides early warning of equipment problems.
Maintenance planning benefits from discovered equipment. When equipment is properly documented, maintenance schedules can be established and tracked. Preventive maintenance is triggered based on equipment condition rather than time alone. This condition-based maintenance reduces unexpected failures while optimising maintenance cost.
Manufacturing-Specific Discovery Challenges
Manufacturing environments often include legacy systems that don’t support modern network discovery. Some control systems might require direct serial connections rather than network access. Some equipment might be air-gapped for security reasons. Discovery must be configured to handle these limitations: some equipment might be manually added to CMDB rather than auto-discovered.
Safety is a concern in manufacturing. Discovery tools shouldn’t interfere with production or create safety risks. Some manufacturing environments restrict network scanning during production. Discovery should be scheduled during maintenance windows or configured to avoid production systems.
Integration with Production Planning
Production planning systems benefit from accurate equipment discovery. When planners schedule production, they need to know equipment capacity and availability. Discovery provides this data automatically: equipment is mapped, relationships show dependencies, historical performance data shows reliability. This integration helps production planners make realistic schedules.
When equipment is discovered and relationships are understood, troubleshooting becomes faster. When a production line stops, operators can understand which equipment might be the cause based on the production flow map. Maintenance teams can see which equipment failed and which equipment depends on it, helping prioritise repair efforts.
Setting the scan scope with the people who run the network
Discovery on a plant begins with a scope agreement, not a scan. The plant has networks that were built by different suppliers at different times, some of which carry control traffic that no one should interrupt. The OT owner needs to agree which address ranges, which protocols and which times of day are permitted before anything is probed. A scope that looks complete on a whiteboard can still miss a segment that was added during a retrofit and never documented.
The table below sets out the three ways a plant asset can enter the CMDB and the situations that call for each. Many sites use all three, and the trouble comes from treating one method as the answer for every device.
| Method | Suits | Does not suit | Main risk |
|---|---|---|---|
| Active discovery through a probe | IT servers, managed network gear, supported workstations | Fragile controllers and devices that react badly to probing | Disruption if scope and timing are not agreed |
| Passive or log-based recognition | Devices that already send traffic to a monitored point | Silent equipment that never transmits | Partial picture that looks complete |
| Manual entry with a named owner | Air-gapped machines, legacy controllers, embedded systems | High-volume assets that change often | Records that go stale without anyone noticing |
Placing probes and credentials on a segmented plant network
A probe has to reach the devices it scans, which on a plant often means a probe on each segment rather than one at the data center edge. Placing probes is a security decision as much as a technical one, because each probe becomes a path into a control network. Credentials need the same care: a single administrator account used across every controller is a finding waiting to happen, and the discovery design should use the narrowest account each device class allows.
- Map the network segments with the OT owner and mark those that carry control traffic.
- Agree which device classes may be probed actively, and which must be recognized passively or entered by hand.
- Place one probe per segment that needs active discovery, with its own service account.
- Test the scan on a single non-critical device class during an agreed window and watch the device response.
- Widen the scope only after the test shows no effect on the equipment, and record the result with the scope.
The credential approach is covered in more depth in the discovery credential governance article, which is worth reading before the first probe is placed.
Reading the relationships Discovery builds
Discovery records devices, but on a plant the useful output is the relationships between them. A sensor reports to a controller, a controller feeds a line, and a line depends on an execution system that schedules its work. When those links are present, a stoppage can be traced quickly. When they are absent, the device list looks complete and the impact analysis is still guesswork.
Relationships also reveal the integrations nobody drew. An interface file that moves material counts between the planning system and a warehouse controller may never appear on an architecture diagram, but it will show up as a dependency once the network is mapped. Those are the links most likely to break quietly during an upgrade.
Scheduling scans so production is not the test case
Discovery should run in a window that the operations lead has accepted, usually during a planned stop or a low-demand period. A scan that runs during a changeover can make a controller briefly unresponsive, and the operators may remember the stoppage longer than the scan report. Where a device class is sensitive, the record should say so and the scan should exclude it by default.
Signs the discovered picture can be trusted
Trust in a plant inventory comes from checks that the floor can verify. Pick a line and confirm that every controller the operators name is in the record. Pick a recent change to a controller and see whether the record reflects it. Compare the discovered count for a segment with the count in the maintenance register. Mismatches are not failures; they are the list of records that need an owner.
What should we do with a controller that discovery cannot identify?
Create a manual record with the make, model and location, mark it as manually maintained, and assign an owner in operations. Leave the discovery gap visible rather than deleting the record, because the gap is the evidence that the device needs a human to keep it current.
Can discovery run on a plant network during production?
Only after the scope test has shown no effect on the equipment and the operations lead has agreed the window. Until then, passive recognition and manual entry should carry the load, and active scanning should wait.
Who owns the probe and its credentials?
The IT team often runs the probe, but the OT owner should approve the scope and the device classes it touches. Credential rotation should follow the same change route as any other access change on the network.
How do we know a relationship is real rather than inferred?
Ask the operator on the line. Discovered links are a starting point, and a relationship that the operator cannot recognize should be marked for review before it is used in an impact analysis.
Next step
If the plant is deciding what to scan first and what to record by hand, the scope conversation is the right starting point. The Discovery module, the MID server that carries probes to remote segments, and the first scope planning article cover the groundwork.
Frequently asked questions
How should manufacturing organisations approach network discovery?
Discover both IT systems and operational technology (OT) systems, but understand they're often managed separately. Configure discovery for the specific equipment and protocols in your facility. Schedule discovery during maintenance windows to avoid production disruption. Some legacy equipment might need manual discovery.
What's the value of mapping production lines?
Production line maps show which equipment is first, which depends on earlier equipment and how material flows. When equipment fails, impact assessment is faster because dependencies are visible. Bottlenecks are easier to identify. Production scheduling becomes more realistic when equipment relationships are understood.
How can discovery support maintenance planning?
Once equipment is discovered, maintenance can be scheduled based on equipment condition and historical performance. Preventive maintenance is triggered by condition data rather than time alone. Discovery provides the equipment knowledge base that condition-based maintenance depends on.
Related guides
Related Oblytech services
Where this topic turns into delivery work, these are the Oblytech services that cover it.
Planning, running or fixing a ServiceNow programme? Tell us where you are and we will suggest a sensible next step.
Contact us