What follows are some tips on loading purchases into ServiceNow to support your Asset Projects.
This came up while writing a series of topics on how ServiceNow Programs in the Federal space can facilitate the rekindled efforts to modernize technology in Federal IT Environments. The topic of using Asset Management (EAM, HAM, SAM, and Cloud Cost Management) emphasized the importance of gathering purchase data, but I was not able to fit all these tips on how to accomplish it.
I’ll start with some quick context for anyone just starting in this area. In Asset Management, loading purchase information is a valuable tool to initiate your asset inventory, support request processes, and maximize value by understanding costs. Purchase data is handled a bit differently in each product:
- For Enterprise and Hardware Asset Management, purchases are tracked in the Purchase Order table.
- In Software Asset Management, purchases are tracked directly as assets using the Software Entitlement table.
- In Cloud Cost Management, purchases are collected in the Cloud Provider integration and tracked as Billing data.
With that established, below are some things to consider when loading purchases to ServiceNow. Feel free to challenge them or add your own in the comments.
Procurement Plugin
If you don’t see the Procurement application menu, you will need to activate the procurement plugin.
- When searching for “Purchase Order” in the Filter Navigator, don’t confuse the Contracts > Purchase Order menu module with the Procurement > Purchase Order menu module.
- When you activate the Procurement Plugin, don’t confuse it with the new Procurement store application. That is different. The plugin you want is snc_procurement shown below:
Track Purchase Order attributes from the Source of Record
You will be loading Purchase Orders and Purchase Order lines from your procurement Source of Record (such as SAP Ariba, Oracle Procurement, Coupa, Jaggaer, etc.). On the Purchase Order [proc_po] table, I like to preserve helpful information from SoR system. This typically includes at minimum the assigned PO Number, a database id for the record, the PO Status in the SoR, and a URL to that system’s record. On the PO Line, I find it helpful to track the PO SoR’s information about the item being purchased. In ServiceNow it is a Model, but the procurement system will have its own reference and information. Remember, it isn’t just the PO table, you may be tracking purchases in a combination of:
- the Purchase Order table
- the Software Entitlement table
- the Contracts table (I’ll discuss later)
Determine the required time range for purchases
For your initial data load, determine the appropriate time range for the purchase data to load to ServiceNow by discussing with your asset and procurement teams. The goal of a historical purchase load is to help build the asset inventory and find gaps. If your asset lifecycle is four years, try to get at least five years of purchase data. You will want a longer time range for Enterprise Assets. This may be driven by requirements from financial compliance policies.
Create “Inferred” Purchases for missing data
Add a method to tag “Inferred” purchases. This indicates that you couldn’t find a purchase record for found assets, but you can infer the purchase was made based on other data.
I use a custom True/False field called “Inferred” on my Purchase Order, PO Line, and Software Entitlement tables. If you identify a purchase of assets from other data sources, say a receiving log, but have no purchase record from your procurement data source, you can create an inferred PO and PO Line record. When you create a corresponding purchase record (be it Contract, PO, SW Entitlement), but flag it as “inferred” so you know it is more of a ‘best guess’ than an import.
For example: when loading four years of SW purchase data, there were cases where I only had SW Support or Renewal Rights, with no original purchase. Without the original purchase entitlement, this will report as out of compliance. Rather than spending hours with procurement archives or vendor communications, I create an ‘inferred’ purchase knowing the renewal could not be done without the original purchase. By flagging these records, we can come back later to research that purchase particularly in an audit.
Align Model Records
For an initial load consider a “Transition” model table. It works like this: say you are loading data from your procurement system where you purchase seven Acme Model 123 Laptops. As it turns out, your existing Hardware Model data already has an Acme Model-123 record (note the added dash) created from a network scan such as Discovery. There are some things you should consider in this case:
- First, if this is a one-time load you don’t want to pollute your Hardware Model table, you’ll need to go back and normalize those records.
- Second, you don’t want to add a barrier to completing your import load by manually checking every failed record.
- Third, you may want to delegate aligning this data rather than leverage the ServiceNow implementer developing the integration.
My solution is to create another table extended from the base Product Model, perhaps called “procurement”. If this is a one-time load, I create that table in a temporary scope (coded as a transition scope) so it can be removed after my implementation, thus keeping my instance clean. I configure my PO loader to coalesce to the appropriate model table but create a record in procurement if nothing matches. Since the PO Line Item references the base model table, the system will have no problem pointing to your procurement table data.
With the data loaded, irrespective of whether it matched existing models, you’ll work with your asset or technology management team over time to normalize the records in the Procurement Model table, creating new Hardware/Software/Other Model records as required until the transition Procurement Model table is empty.
This technique is a typical part of my data migration strategy in my technology modernization efforts. I use this technique for one-time loads, but it could be incorporated into a procurement integration process with a permanent transition table.
Leverage Contracts
In the past, specifically in the Federal Government, I’ve had success getting purchase data from PRISM, the most widely used contract management tool. I believe this is equally valid on PD2, CLM, SPS, eCMS, DAPA, etc. The key idea is that contracts in the Federal space are used to track purchases. Conceptually, they are the basis for Purchase Orders, SW Entitlements, Product and Vendor Catalogs (blanket purchase agreements), support contracts, and more. In this way, you can have a single integration to the Contract system to create Contracts in ServiceNow, then use these records to create Purchase Orders, Software Entitlements, Vendor Catalogs, etc.
There is a bit of technical work to achieve this. Specifically, you will want to:
- Create a scope with elevated security policies since the data may be sensitive
- Extend Contract into that scope use Caller Access
- Add a Contract Line Item, which is not present in baseline Contract Management
This is more nuanced, but I also track the contract function, either:
- Menu, such as a BPA/IDIQ
- Funding Obligation
- Order / Call
The Contract Function changes the linked ServiceNow entities. The Contract Line-Item links to Vendor Catalog Item, Budget Line Item, or PO Line accordingly. There are a lot more details but this is the concept.
I found it worth creating this custom app to support EAM, HAM, and SAM. The architecture outlined follows a good solutioning practice: it is typically best to link to ServiceNow’s baseline entities, in this case Vendor Catalog, Budget, and PO, and let them behave as designed rather than trying to modify their behavior.
With ServiceNow’s new capabilities in Document Intelligence and AI, I plan to revisit this application with clients soon to improve how we process line item text to extract useful information such as Model IDs, or in the case of SAM, Publisher Part Numbers.
