Modelling data structure in CSM supported by CSDM for Managed Service Provider (MSP) company

[JohnDF]

Hi everyone,

I ran into a issues and dont know how should I model the relations/data model for a use case. I want to map the current csdm into the csm supported csdm structure provided by ServiceNow in the the following picture:

https://docs.servicenow.com/en-US/bundle/sandiego-servicenow-platform/page/product/csdm-implementati...

The issue I've got is one scenario of the msp offering to a customer and I dont know ho to model this in the data model because a Install Base Item can only have one reference to a configuration item. Here is the current use case:

The Servers are the CI's and I would Model MSSQL Server as a Install Base item, but the problem is I can only reference a 1:1 relation from Install Base items to CI.

How would you model this in the data structure CSM supported by CSDM.

Any input would be helpful. Thanks in advance.

[Aaron W_ Smith]

@JohnDF Since the Install base data model was introduced I have perceived its use this way - hope the example helps:

• You would start by defining/creating Product models (#3 in the picture):
• Create one Product record for each SKU you sell (Home, Business, Enterprise / gold, silver, bronze / V1, V2, V3 / etc. based on the nature of the services you provide)
• You also create a Product for each of the sub-components of the product - level of detail are influenced by may factors
• Mix and match elements of suites - think Word, Excel, PPT, etc. in the different MS Office SKUs
• Sales and Marketing strategy - how they package/repackage for different markets, verticals, etc.
• Technical make up / Underpinning infrastructure - think hosting Servers, App or HW stacks, etc.
• Swap-able / upgradable components - think memory, CPU, cell phone SIM card, etc.
• Then you would relate the sup-components to the Suits using the embedded related lists (i.e.  compatibles, substitutes, model components, and bundles for all models or Suite Components/Parents for software)
• The above gives what you need to call to create the Sold Product records and can be published to the Catalog as Requestable items
• The Sold product record represents what I have sold my customer although it may just be 'sitting on a shelf' unused
• It is an 'instance' of the available Product/Service that I'm selling/supporting
• Potentially this is where I can stop unless...
• A) The customer installs the product AND I have a contract with the customer for support
  AND/OR
• B) I host/maintain/control/support the IT infrastructure components that makeup what is needed to deliver and support the Sold Product.
• Given A) I can skip having Install base item records (under the assumption that I'm not tracking the 'guts' of the service being consumed by the customer in my CMDB.
• Optionally if I have operational CIs (may be very generic/high level) in my CMDB I use for my ITSM, FSM or other platform applications needed to track their work I can still create Install base items for them to connect back to what is happening in CSM Cases (see guidance below on what level CI in the CMDB to select)
• Side note: I may track Assets for the products I have sold if they have unique identifiers and/or maintain inventory of replacement parts. (Remember Product models are used for Assets and CIs)
• i.e. I sold you a Lamp (main sold product) with a light bulb (compatible/bundled product) and I will be happy to sell you replacement bulbs from my consumable assets in my stockroom.  That will be easier if I know what bulbs work with your lamp.
• Given B) I will need to connect my Install base Item records to the CIs that provide the customer's Product/Service
• However... just like in the first step where I decomposed my Product offerings into "sellable" bundles of components, I need to consider the following:
• A) what level of detail am I tracking in my CMBD of the underpinning CIs
• B) Is the Sold product/Install item unique to, and only consumable by that customer (a custom built Application stack; a specific Circuit) OR is the product/item a shared Service that underpins multiple customer's services
• C) related to both above, where is my ability to detect a failure/outage/etc's impact to the customer(s) consuming that Product?

So Applying all the above to your example...

• Regardless if you have one or many customers consuming the Service Offering enabled by the  "Application Service" in your diagram, the Install base item for the Product you sold them would be connect to that app service CI because an issue on either of the branches of technology has the potential to impact the customer's service
• You would only set the Install base item to the SQL Instance or Server in your diagram if the customer's Sold Product directly resided/was provided by that CI directly.
• In other words you should generally aim to connect your Install base items to the highest CI in the 'stack' of infrastructure that provides the service described by your Products.

So... there is my rationale for this really long answer - we in IT generally make the mistake of looking from the technology outwards, trying to map from bottom to top... when in this case, to set up the data structures (and to meet the goal of CSM - providing great customer experiences) we need to look at the problem from the outside in.

[Tomas Lozano]

Heads up - install bases should be part of CSDM 5.0 - maybe we'll see them in the CSDM 4.1 draft that will come out (no idea when..).

I'm hoping for more prescriptive advise on the CMDB<>CSM linkage.