In my opinion you should build your models through your processes/flows and not let a discovery tool find them.
There are plenty examples in ServiceNow that tells you to populate ServiceNow in the correct order.
Try to fill in the "Assigned to" on an Asset record and then a CI record, you will quickly notice the difference (hint: auto fill in of related fields).
My advise is always to build your model through processes so your discovery tools can expand and verify data on your already created records. Build your assets before you build your CIs
I would like to thank you for sharing your experience and giving us some "wise advice" on a critical aspect of digital product & service modelling. It is always inspiring for me to include your points in my thoughts.
Yeah, I totally agree with that. Discovery is an "after the fact, cleanup process." It inherently misses all of the context and knowledge that is known earlier in the CI lifecycle (when the CIs are requested/created) such as "who's is this, what is it doing for us" and other non-discoverable elements.
I'm new to models in SN, but I am very interested in the logical (not asset-linked) concept of Service Model (those with a model category of 'application service'). This snippet: "A service model is a class of product models to define Software as a Service (SaaS) products. It defines the service and contains the different attributes, choices, and components that can be configured to a customer’s specifications" (from Utah: Create a service model (servicenow.com) but a broken link in Vancouver: the doc page immediately above Bundled models (servicenow.com) in LHS nav is dead?) sounds like what I am trying to represent... specifically for the CSM use cases (Customer Service Management examples (servicenow.com) that can link these Service Models to the Business Service Offerings and Sold Products associated with a customer's Install Base Items.
Can anyone suggest any resources that are useful in this space? Most of the collateral I find is heavily skewed towards asset/CI classes and IaaS and not this logical/service domain. I'm trying to understand any constraints (or recommendations) around the tooling to capture many attributes representing hosted application service scenarios, eg
- can blended model categories (eg Software and Service) be mixed/nested within each other?
- bundles of bundles? limits to this, or when does it get unwieldy
- use of custom model categories pros/cons
- use components, vs keeping flat
- key/value constructs to represent customer optionality, vs cutting a new model entirely
- data type constraints around model metadata fields - eg lengths of fields
- ...etc
Any pointers appreciated 🙂
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
