Sid Tiwari
Tera Explorer

There is a familiar moment in many organisations where finance believes an asset has been purchased, operations believe it has been deployed, and technology believes it hasn’t yet been onboarded. 3 truths, all partially correct, none stitched together. The consequences are predictable –

  • Missing warranty data
  • Vague maintenance plans
  • Poor visibility of inventory and spares
  • Nervous audit conversations

 

I have come to see this not as a tooling problem but as an operating model “join issue” specifically between Source‑to‑Pay (S2P) and Enterprise Asset Management (EAM). With recent advancements, ServiceNow is well‑placed to close that “join-issue” because it can act as the front door for demand, the orchestration layer for fulfilment, and the system of engagement for the entire Asset lifecycle. The design challenge is agreeing where each record of truth lives and how data flows through the lifecycle without creating duplicate variants of the same facts.

 

I start with a simple statement – every Enterprise Asset should articulate a story – from the moment someone requests it, through vendor selection and purchase, into receiving and deployment, through service and maintenance, and finally to retirement and secure disposal. That story should be readable by humans through Employee Center and by systems through a well‑governed CMDB and Asset tables. When you align those perspectives, you can remove large pockets of waste and confusion.

 

SidTiwari_0-1759377474075.png

 

The first decision is about the front door. If employees and departments don’t know where to go for asset‑related needs, they will invent their own doors. I use Employee Center as the single entry point for requests—new assets, moves, swaps, break/fix, calibration, recalls, disposals, and everything in between. The key is resisting the temptation to create hundreds of near‑duplicate catalog items, and instead, standardise around outcomes and drive the variability through request variables, product models and assignment logic.

 

The second decision is the taxonomy. If you can’t agree on the product model hierarchy and CI classes early, everything becomes harder – stock levels are inaccurate, maintenance plans are generic, discovery and monitoring classifications are messy, and analytics becomes a guessing game. I design a common taxonomy where Product Models map cleanly to CI Classes and where those classes have a clear relationship to maintenance regimes, warranty entitlements and security policies. The naming matters. The hierarchy matters. And the discipline of placing new introductions into the taxonomy matters most of all. When the taxonomy is stable, it becomes far easier to build catalog content that is both simple for requesters and precise enough for fulfilment.

 

The third decision is the flow of authority. Procurement systems remain the system of record for purchase orders and invoices, and the finance remains the system of record for depreciation. The engineering teams and EAM remain the system of engagement for maintenance execution. ServiceNow’s job is to orchestrate outcomes, not to hoard master data. Practically, that means integrating with your ERP for purchase order creation and goods receipting, while creating Asset records (hardware, software, facilities assets and beyond) as soon as there is enough context to be useful. As items are received, Asset records are enriched with serials, warranty start dates and contract references. When assets are deployed, CI relationships are established, and support group ownership is assigned by policy rather than by memory. When maintenance is due, the Work Orders are generated with the correct spare parts list because the model and class are known, not guessed.

 

The fourth decision is controls by design. If you retrofit risk later, you will spend twice as long proving basic hygiene. I embed guardrails across the flow where vendor onboarding checks the feed supplier risk posture, automated validation of disposal certificates, attestation of high‑risk Asset locations, and segregation of duties for approvals where finance, operations and technology intersect. This continuous assurance that lets you move faster with fewer audit surprises.

 

I have seen organizations attempt to solve this by custom‑building “asset dashboards” that look beautiful but hide brittle integrations and ad‑hoc data rules. Six months later, the dashboard is stale and teams are back in spreadsheets. The alternative is less glamorous but far more resilient –

  • Make the catalog lean
  • Make the taxonomy robust
  • Let the platform do the heavy lifting with flow orchestration, assignment rules and Work order management
  • Performance Analytics can then tell a reliable story because it’s built on events that actually happened in the platform, not on stitched CSVs

 

The most satisfying moment is when operations, finance and technology stop arguing about whose numbers are “more correct” and start arguing about how to improve the numbers together –

  • Mean time to deploy drops because receiving and staging are visible
  • First‑time fix improves because maintenance plans are tied to real models
  • Budget leakage reduces because assets don’t go missing between purchase and deployment
  • Audit stops being an annual scramble because the trail is written as the work is done

 

If you are at the start of this journey, begin with defining the “ownership”. ServiceNow won’t solve your operating model problems by itself, but it gives you the right surfaces to design a lifecycle where each step sets the next one up for success. That is how the “join issue” disappears.