
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-26-2023 11:55 PM
Good morning,
In our instance we use Services (cmdb_ci_service_business and cmdb_ci_service_technical) for multiple purposes, such as IT Financials mgt., and SPM. We use them as service domains, rather than 1:1 with a business application or tech service LCM responsibility. This is mainly because we handle around 1200 unique business applications, and cannot have 1200 parent services and still maintain a good overview.
Now we have started adding "real" business services, ie. services that do not have IT LCM as scope. This can be Legal, Tax, Facilities, etc. These are useful for Business Continuity Mgt., since they represent the parts of the organization that have to mitigate when an IT related crisis emerge. They will also be used for Transfer Pricing of cost to daughter companies, and for calculating product profitability. We therefore started investigating if 'In scope' and 'Out of scope' could help us separate these from the IT related business services, so that they are not selectable for IT Incidents, etc.
What I would like to do, is to use 'In scope' and 'Out of scope' for all services to define what they deal with. But as we use service offerings rather than services for managing ITSM, ITOM, ITAM, VR, etc., it would be more useful to define the scopes on the service offering records, and then simply aggregate these scopes on the parent service records. But these do not have those related lists. For instance, if a service offering deals with both Application development, maintenance and end user support, and another service offering deals with all of these plus Infrastructure monitoring, Events and Alerts mgt., then the parent Business service would have all of these scopes in their "aggreagtion" related list.
At the moment more and more teams in our organization move to the cloud, and become self serviced on infrastructure development and operations, but remain on premise for some of their older applications. The 'In scope' on each service offering record could therefore be useful for Vulnerability response as well, as we can route VITs to the Tech teams that do DevOps, but other infrastructure related VITs belonging to their non-Cloud apps would go to the centralized Cloud Platform team. But then this needs to be marked on a service offering level in order to work, I believe.
Anyone who has found a solution to this? Am I thinking wrong?
Best regards,
Kristine
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-01-2023 05:33 AM - edited ‎03-01-2023 05:36 AM
The "In Scope" list uses a table (service_in_scope) which has two fields, one for the Scope (service_scope), and the other for the Service (cmdb_ci_service). Since the Offering actually is a Service, you can just define it on the Offering instead of defining it on the parent Technical/Business Service. Then the only additional thing you would need to do is to create a custom list on Service using the link I mentioned above, which would enumerate the In Scope lists from all of its child Offerings, as well as any In Scope entries defined for the service itself, and display them all in a single list.
You would have to consider what to do about Scopes that are listed as In Scope for one offering and Out of Scope for another offering? Do you put them in the In Scope list for the parent Service? Something to consider from a UX and a Service Owner perspective.
The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-27-2023 12:12 AM
Hi Kristine,
is it a fixed construct or can it be ordered like that?If it is fixed then it sounds like depends on offerings. If not then as a result of an order you subscribe to several offerings.
Do you have the real business services parent in a Service Portfolio? (not sure from the input)
BR,
Barry

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-27-2023 01:00 AM - edited ‎02-27-2023 01:01 AM
Hi Barry,
I am not sure if I understand your first question. We relate catalog items to service offerings, as prescribed by CSDM 4.0, for all IT and Non-IT. So the non-IT service offerings have catalog items too (although not many yet).
"Real" business services: we have created a Non-IT portfolio for these, since we use service portfolios with TBM taxonomy nodes for the IT portfolio. So all non-IT services belong to the Non-IT portfolio. We can then add taxonomy nodes to these. Currently they are inspired by the TBM taxonomy nodes, as the names on the nodes suit equally well the non-IT services.
Regards,
Kristine

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-27-2023 01:26 AM
Hi Kristine,
I think the setup with Business Portfolio and IT portfolio is good.
I usually link those together from a Business Service Offering record.
In the related list (in spm views) you can see the depends on option (also in service builder).
In a way it is a service decomposition/supply chain but I wasn't sure if you had the same in mind.
 
BR,
Barry
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-27-2023 07:38 AM
If you are simply looking to aggregate the Scope entries in the Service Offering to the parent Business Service, I think this is pretty straightforward to do with a custom related list without having to do anything different in the data model itself. It would just require aggregating that list on the fly. Here is an article that describes how to do this: https://www.servicenow.com/community/developer-articles/servicenow-create-custom-related-list-servic...
The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.