CSDM

[Jishnu Jayakris]

Technical service offering is a service offering type defined as a stratification of the technical service into options including localization/geography, environment, pricing, availability, capability, support group (for incident), assignment group (for change), technical approval group (for change), and packaging options (commitments).

Could someone help me know what does this actually refer to , much appreciated if someone describe it with a  real time use case. Thanks

[Andreas Borell]

A Technical Service or Business Service describe areas of responsibility. For instance, a Technical Service might be Application Management, while a Business Service might be Application Support (simplified examples using TBM as foundation ). For each such service, you need at least one offering. If you have only one offering, that means that everyone and anyone who receives this service call of / subscribe to that offering. But lets say you don't want to treat everyone the same - some members in your company (C-suite, for example) may warrant different application support than other employees. Then you can have [application support : global standard offering] and [application support : VIP offering] and by adding the right people to the right groups to subscribe to the right offerings, you get stratification or differentiation of what you offer to whom, but it is still the same general service, aka area of responsibility. The SLAs applicable for the VIP offering can be tighter than the global standard, the default support groups can be more experienced resources directly working with VIPs compared to the general service desk valid for most employees etc.

[Jishnu Jayakris]

Thank you for Response @Andreas Borell 

"But lets say you don't want to treat everyone the same - some members in your company (C-suite, for example) may warrant different application support than other employees. Then you can have [application support : global standard offering] and [application support : VIP offering] and by adding the right people to the right groups to subscribe to the right offerings, you get stratification or differentiation of what you offer to whom, but it is still the same general service, aka area of responsibility. The SLAs applicable for the VIP offering can be tighter than the global standard, the default support groups can be more experienced resources directly working with VIPs compared to the general service desk valid for most employees etc. "

Thanks for starting it for me into right direction, referring to the above example would like to know how the business could benefit by doing so, what is the output ?

Just to get clarified on this phrase "localization/geography, environment, pricing, availability, capability, support group (for incident), assignment group (for change), technical approval group (for change), and packaging options (commitments). "  How this is related to technical services ?

Lets say we follow the CSDM process from top level Business Service to Infrastructure level, what benefits we can leverage out from this process and mappings, use case if you can refer please...

[Andreas Borell]

Your first question : "... referring to the above example would like to know how the business could benefit by doing so, what is the output ?"

The benefit for an organization to stratify a service is contextual. In a very small organization, no stratification at all may be needed - and services in general can even grow organically. But as soon as you grow above a certain size, it will start to make sense to not just let your services to grow organically, but to design them. As soon as you have more than a handful of people working across an organization, it will almost always be true that not all of them work on the same things - and they therefore need different services or different variants (offerings) of the same service provided. This comes back to the design statement above - have an internal dialogue about what services are needed, who owns them, who consumes them etc is by itself a meaningful exercise. It often ends up in patterns - managers above a certain level expect VIP treatment, not all IT systems are seen as equally important, some activities are outsourced etc - and by making a conscious decision and document it (aka a service with an offering and a commitment) is a way to keep track of those agreements that you design. So the benefits are twofold - you get documentation of what you have agreed, and you also should end up with "offerings" that are closer to what is agreed to be needed and right for your organization at that given time that drive functionality in the system in order to help you deliver.

Regarding the second question about Technical Services (TS), they are areas of responsibility.

Using TBM (referenced in earlier message) as example, you may have a technical service for Application Management. As part of that service, you may have two offerings. One offering is "Application management of productivity tools" (aka Office365 etc) and another offering could "Application Management of ERP". By leveraging the CSDM modelling, you could then indicate through the offerings that the default support group for ERP systems is "ERP support group" while for productivity tools it is "Productivity support group". Same for change groups. How many offerings you need and how you use them to segment "application management" will depend on your local context, Maybe you run one ERP instance for every country and want to manage them differently? Different offerings. 

Another type of technical service may be more related to development tools. Here you may have one offering to management of the whole development stack (someone needs to take care of Jira for Jira to work, for example). But you may also have another offering in that technical service that is about managing and providing virtual machines to developers. To this offering you may then link one or more catalog items to request virtual machines to be created, refreshed, deleted etc. By using "subscription" on the offering, you can control who is allowed to use those catalog items to raise requests.

These are but a few high level examples. 

[Jishnu Jayakris]

Referring to this architecture, how organization can take the leverage of ServiceNow, Is it catalog request , incident , change or reporting ?