Relations between Service and Service offering

[Rob Mollee]

I'm currently working on a Service Model for our Customers, but I have encountered a difference between CSDM 2.0 and a previous presentation used in Knowledge 19. In CSDM 2.0 Whitepaper, there is a reference between the Service Offering and the Technical and/or Business Service; In  the CSDM Intro presentation used on Knowledge19, however, there is still a Contains::Contained by Relation between Business/Technical Service and the Service offering. 

Has this insight changed with CSDM 2.0? Or more specifically, should we define the Suggested Relationship between Service and Service offering?

[CasperJT]

I have realised, that perhaps it is not necessary to manage the duplication of parent and relationships in order to get the dependency view functionality.

By leveraging the 'Map related items' feature, you can actually configure ServiceNow to show reference data in the Dependency map.

For example, Business Service -> Business Service Offerings can be shown in the dependency view by configuring a related item that looks at the Service table as a CI, Service Offering as the related item and Parent as the related field. Please note the related field is defined by the related item so you should see the CI as the parent and Related item as the child.

It works like this:
For Service Offering 'Normal Change' I have defined a Parent called Service Management (Service) and I have added a Depends on::Used by relationship with the CI SN - Change Management, which in turn has a Depends on::Used by relationship with ServiceNow - Prod.

The dependency view looks like this:

[KN8]

Hi Casper, thanks for pointing to this feature!

That "service - service offering" ngbsm_related_item record is already available ootb (at least in Quebec), so no need to configure it manually.

However I ran into the same issue with it as Alec below: when running a dependency view from a service, this Map Related Item feature works as expected, mapping an SO and downstream dependencies. But when I run a dependency view from an SO, you would expect it to show the upstream service - much like on your last screenshot. But instead I am getting Alec's results.

I wonder if you might suggest what Alec and I missed?

Thanks!

[Fredrik v S]

Hi,

So in order to leverage all neat features around the Service Offering, you must have the reference in there simply because it ensure that you have only one service selected from a service offering. A lot of functionality around Commitments, Service Levels and so fourth heavily relies on this in the platform. This is the technical reason for it.

However, there is nothing stopping you from also creating a relationship in order to visualize this in the dependency maps for a "human readable" way of showing it all, but it isn't a requirement in the platform except for if you do financials around it.

Best regards,

Fredrik

[Rob Mollee]

Hi Frederik, 

Thanks for your reply;

Yes, I'm aware of the fact that you definitely need the reference: For me it would be a case of creating both the reference AND the relationship..

I'm just wondering whether or not there was a specific reason for ServiceNow to remove the relationship from the pictures (it was in CSDM 1.0).. 

Best regards, Rob

[LB6]

How about this: In addition to the reference attribute (required to leverage current/future OoTB SPM functionality) - a new relationship can be defined, use case is visualising the relationship between service and offering only, when viewing whole of service BSM models in tool?  And maybe down the track ServiceNow could look at the feasability of auto-managing (add/remove) this relationship as a result of adding/removing reference attributes in the parent service object... 😉

eg. Service (parent) > stratified by :: stratifies < Service Offering (child)