In scope and Out of scope on a service

[Kristine Naess]

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

[Kristine Naess]

Hi again,

and thanks for valuable insight. I was thinking more about what the scopes of the Offerings I depend on are. We have some tech offerings that do monitoring as part of their offering, and some that have to rely on another team for this. On the Business Services and Technical Services it is possible to define scope for the service, but not on the offerings. I would rather want this to be added on a service offering level, and summarized as a related list on the parent Business Service records. 

But I guess this wasn't thought of yet. 

Regards,

Kristine

[CMDB Whisperer · Accepted solution]

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.

[Barry Kant]

hi Kristine, 
a question to see if I understand the scenario right.

Is the Service a bundle of base and optional subservices?
Meaning some consumer have the base subservices and no optional subservices and some customer choose base subservices and optional subservices. So 2 type of offerings? In that scenario why would you aggregate it to the service level as the distinction is on the offering level?

the purpose is to have a more documented outline what the service is about rather than model it with depends on underpinning services as far as I can see it, right?

BR,
Barry