OBLYTECH Logo
OBLYTECH Logo
ServiceNow Software Asset Management Professional for Manufacturing
Home / Guides, Services and Solutions / by Industry / for Manufacturing / ServiceNow Software Asset Management Professional for Manufacturing

ServiceNow Software Asset Management Professional for Manufacturing

This page explains how a manufacturer can use Software Asset Management Professional to track plant software licenses, reconcile them with what is installed and prepare for vendor audits, including validated engineering tools that discovery cannot reach.

How Manufacturing Organisations Use Software Asset Management Professional

Manufacturing organisations deploy specialized software: production control systems, supply chain planning, quality management and equipment monitoring. These systems are business-critical and often licensed per seat, per core or per deployment. Tracking licenses and ensuring compliance is complex. Software Asset Management Professional provides visibility into deployed software, license usage and compliance. When software licenses are renewed, costs should match actual deployment. When software is audited, you should have evidence of what is deployed and whether licenses cover the deployment.

Manufacturing also tracks software dependencies. Production control systems depend on database software and networking. When planning upgrades, understanding these dependencies is critical. Unplanned downtime of manufacturing equipment has high cost, so changes must be well-coordinated. Software Asset Management Professional helps map these dependencies and plan changes safely.

Software Inventory and Deployment Tracking

Software Asset Management Professional maintains inventory of deployed software. Production control systems are tracked, along with their versions and license terms. Engineering workstations have CAD software and simulation tools; all are tracked. Office software is tracked on administrative systems. The inventory answers key questions: how many copies of each software are deployed, what versions are running, are we licensed for all deployments.

Inventory is updated when software is installed, upgraded or removed. Automation can discover software on systems and update inventory automatically. Manual additions track software that discovery cannot find. Regular reconciliation between inventory and actual deployments catches discrepancies.

License Compliance and Cost Optimization

Manufacturing software is often expensive with complex licensing. A database server might be licensed per core, so every time you add processing cores you need new licenses. Modelling software might be licensed per named user or per seat. Compliance audits verify that deployment matches license terms. Software Asset Management Professional tracks license terms and enforces them. If a license allows installation on 50 workstations and you have 52, that is a compliance gap that must be addressed.

Software Asset Management Professional also optimises costs. If you have licenses for software that is rarely used, you might save money by uninstalling it and reallocating licenses. If usage is growing and you need more licenses, bulk purchasing might be cheaper than adding licenses individually. License data drives procurement decisions.

Compliance and Vendor Audits

Software vendors audit customer deployments to verify compliance. When audited, you should be able to produce proof that software is deployed only as licensed. Software Asset Management Professional provides audit reports showing deployed software and license coverage. If the vendor finds unlicensed instances, the report shows the scope and cost to remediate. Without good tracking, audit findings can be costly and difficult to defend.

Compliance is ongoing, not just during audits. Track license expirations so renewals are not missed. Track license restrictions like geography or industry: some software is licensed for use in certain regions or industries; violating these restrictions is a compliance violation.

Support and Maintenance Tracking

Software support and maintenance contracts are tracked separately from licenses. A production system might have an active maintenance contract while other software has expired support. Expired support means no updates or security patches; this creates risk. Software Asset Management Professional tracks support expirations and alerts when renewal is needed. Without tracking, support might lapse and you do not realise until a critical issue occurs and support is no longer available.

Dependency Mapping and Change Planning

Manufacturing systems are interdependent. Production control depends on database software. Planning systems depend on networking. Quality systems depend on data repositories. Software Asset Management Professional maps these dependencies. When planning a system upgrade, you see which other systems depend on it and can coordinate changes safely. This visibility prevents cascading failures where one upgrade breaks dependent systems.

Dependency data also supports capacity planning. Adding load to a system might exceed its database performance. Knowing the dependencies helps you identify whether database upgrade is needed to support the application upgrade.

Continuous Monitoring and Updates

Software changes frequently. New versions are released, security patches are issued, support expires. Software Asset Management Professional tracks these changes. When a version reaches end-of-support, alerts remind teams to plan upgrade. When security patches are released, tracking shows which systems need patching. This proactive management prevents security gaps and extends system life.

Matching each license metric to how plant software is actually deployed

License compliance on a plant starts with the metric, not the count. The same engineering package can be licensed per named user, per concurrent session, per installed instance or per processor, and each metric counts a different thing. A simulation tool sold per concurrent session is compliant on a laptop that sits in a drawer, but a per-instance license counts that laptop whether it is used or not. Before reconciling anything, the software asset owner should record the metric in plain terms for every product that touches production, because the metric decides what the discovery data has to show.

License metric What the record must show Where plant deployments often miscount
Named user Who holds the seat and whether they still need it Shared engineering logins and departed staff
Concurrent session Peak simultaneous use over the agreement period Session pools that were never measured
Installed instance Every installation, including offline and archived machines Laptops and test rigs outside the network
Processor or core Core count at each host, with virtualization rules applied Clusters that moved to larger hosts without a license review

Reconciling discovery data with what the vendor will count

Discovery is good at finding installed software on connected machines. It is weaker at the things vendors audit: unused seats, offline instances and the difference between a standby failover node and a live one. A reconciliation routine therefore has two parts. The automated comparison flags anything discovered but not licensed, and a manual review covers the machines discovery cannot reach. The manual part is where plants find the gaps that cost the most, often a test environment that was cloned from production and never removed from the count.

  1. Export discovered installations for each product and group them by plant area and by the license metric.
  2. Remove installations that are retired, then mark standby or failover instances according to the agreement.
  3. List every machine that discovery could not scan and assign an owner to confirm its software by hand.
  4. Compare the adjusted count with entitlements, and record any surplus or shortfall with the date it was found.
  5. Raise a reclaim or purchase request through the normal approval route, rather than adjusting the record to match the license.

When a manual register is the better tool

Not every plant asset should be managed by discovery. Specialist software on dedicated controller workstations, validated tools that cannot be changed without a re-validation step, and software supplied under a site license negotiated by a corporate function often need a manual entitlement register kept by the owning engineering team. The platform can hold that register and link it to the asset record, but forcing automatic discovery onto those machines tends to produce a constant stream of false exceptions that the team learns to ignore. An ignored exception list is worse than no list, because it hides the real shortfall.

Indicators that license management is slipping

Look for reconciliation tasks that are repeatedly marked complete without a count change, for renewal requests raised only after a vendor letter arrives, and for license records whose named owner has left the business. Each of these signals a process that is being performed rather than used. A simple test is to pick three products at random and ask a plant engineer to show the machines that run them. If the answer takes more than a short walk to find, the record is not fit for an audit.

Questions raised when the first vendor review arrives

Should a validated engineering tool be removed from a machine that is rarely used?

Not without checking the validation record. Removing software from a validated system may itself require a change control step, so the decision belongs to the quality team as well as to the software owner.

How should software on a cloud-hosted simulation environment be counted?

Count it against the metric in the agreement, not against the discovery view. Cloud instances often do not appear in a machine scan, so the record should be built from the provider’s usage reports and reconciled against entitlements each cycle.

What if the plant has inherited licenses from an acquisition?

Treat inherited entitlements as unverified until each one is matched to an agreement and an owner. Many acquired estates carry licenses under the previous company’s terms, and those terms can limit transfer or use by the new site.

For the broader lifecycle, see the manufacturing IT asset management guide and the software asset compliance service. The article on software asset lifecycle controls covers the approval routes in more depth.

Software Asset Management Professional: tables, product models and values in the compliance chain

ServiceNow Software Asset Management Professional works by comparing what is installed with what was bought. Discovery or another feed writes installation records, normalisation maps them to software product models, and licence records hold the entitlements. The compliance position is the gap between the two sides, so a missing feed on either side makes the answer unreliable.

These are common out-of-box table names behind that chain. Check them on your own instance and release, because names, menus and defaults change between releases.

Table What it holds
cmdb_sam_sw_install Typically one record for each detected installation of software on a device
alm_license The licence record, which is the entitlement side of the comparison
cmdb_software_product_model The normalised product that installs and licences should both point to
cmdb_ci_computer The device class that most installations attach to

Licence metrics are usually chosen per product, with per device, per user and per processor core among the common choices. The list you see depends on your release and on what the vendor contract defines.

Example (hypothetical): a plant finds a few more installations of a simulation tool than it holds seats. Before buying more seats, the team checks whether two of those installations sit on retired machines still listed as active, and whether one belongs to a contractor group covered by a separate agreement.

Why do installs and licences disagree when nothing has changed?

The usual cause is normalisation. The same product can be discovered under slightly different publisher or product names, so installs land on one product model and licences on another. Fix the mapping before disputing the count.

Can discovery see software on isolated plant networks?

Usually only where a MID Server or another collector can reach the device. Where it cannot, installation data has to arrive by import or manual entry, and the register should say which source each record came from.

What does reconciliation need from purchasing?

Licence records that name the product model, the quantity and the metric the contract uses. Records missing any of these tend to show as unmatched, which inflates apparent exposure.

Related reading: Software Asset Management Professional, ServiceNow Discovery and software licence optimization.

Frequently asked questions

How do we handle free or open-source software in Software Asset Management?

Track it even though it has no license cost. Open-source software often has support and maintenance costs. Some organisations support the software through subscriptions or service agreements. More importantly, open-source software often has security updates that must be tracked. Knowing you have a dependency on open-source software helps you plan updates and identify security risks.

Should manufacturing track every software title or focus on high-value strategic software?

Focus on software that is business-critical or has significant cost: production systems, modelling tools, databases and enterprise platforms. Utilities and small tools can be tracked at a higher level. However, if a utility has a security vulnerability, even small tools matter. Strike a balance: detailed tracking of critical and expensive software, summary tracking of everything else, focused attention on security issues regardless of software type.

How do we handle software running on production control systems that cannot be easily audited?

Industrial control systems often have limited visibility. Work with the equipment vendor to understand what software is running and support options. Document software manually if automatic discovery is not possible. For critical systems, ensure support and maintenance contracts are in place and current. The risk of unsupported industrial software failing is high, so it is worth effort to track and maintain.

Talk to Oblytech

Planning, running or fixing a ServiceNow programme? Tell us where you are and we will suggest a sensible next step.

Contact us