CSDM data in Incident Management

[Srikkanth Ajja1]

Hello All,

I have been struggling to get this understanding right. Please help me with your advise.

An Incident can be of two types, it can be an Application issue OR it can be an Infrastructure issue.

1)Application related issue:

If an issue has to be raised by an agent, the Incident is raised with a Business Service Offering (ADP Payroll) in the Service Offering field, and  Application Service (example : ADP Payroll - Production) in the CI field. Since the first assignment group ServiceDesk may not be familiar with where the issue lies, it sends to the Incident to the ADP application Support by changing the Service Offering from a Business Service Offering (ADP Payroll) to Technical Service Offering (Application Management Services)

2)Infrastructure related Issue:

Once the Application Support team comes to know if is an issue with the DB, then it sends the Incident to DB support team by Changing the Service offering again to a Technical Service Offering ( for example : Oracle management Services).

In both cases, it is the Technical Service Offerings that is used for routing the Incidents, hence my question is, what is the role of Business Service Offerings in Incident Management.

One of my guesses is that, it is used in Impacted Services to understand the Impacted Business Services.

Awaiting for your thoughts, Please feel free to correct if have misunderstood the concept.

[Michael Dul]

Hi Srikkanth,

I love you have asked that question. I will start by saying, CSDM gives you the data model and unfortunately not all modules are quite explicit about how they use the given model. I will walk you how I "usually" approach this.

My first step would be to determine what you convey by each field on the Incident. OOTB you have Service, Service Offering, and CI. Alongside this you will have related lists of Impacted Services that will populate based on the upstream "impact propagation". App Services, as Services OOTB show in both Service Fields and CI fields (I believe). Offering is not mandatory which makes sense as App Services do not have Offerings. You can drive commitments of CI fields and Offerings based on the properties.

My starting point...

I would normally standardise below:

• CI - is an element that is "best to our knowledge" causing the issue. In what you called "infrastructure" issues, that would be for example a DB, for App issues - it would be cmdb_ci_app (if you use them as Primary Class) or App Service, if you don't. I normally would not allow offerings and services to be used in the CI field for one reason. It would indicate the issue is with the "Service" itself. This can of course be done, but makes Problem Management and data analysis across Incidents more problematic.
• Service Offering - I would normally advise to mark it as "technically responsible". For one reason - this field OOTB drives Commitments and allows for a consistent reporting across IT.

And now...

For some organisations this is enough and you can enhance it by:

• Hiding Service field, or make it read only, or deprived from offering
• You can make automated offering selection based on the CI selected
• You can make CI selection dependent on the Offering
• Etc.
• You can also introduce App Service (seen this many times) as a separate field that works as a third level of context (or Dynamic CI groups for non-App groups)

This gives you the IT base, that is normally my starting point. In such case Business Offerings are only populated on the related lists which allows for impact communication and other functionalities you might want to drive from this. But it fails to address your main concern, how do we deal with Business Offerings.

The problem statement...

The problem we get is the duality of information registration. If you allow for Business to Technical Offering switch you need to either provide a very clear guidance on when such switch happens and how will you interpret that data. One of the options is for example to keep business services only engaged when there is a service disruption but it was not caused by a technical fault. This however proves to be problematic with a lot of ITIL specialists. Another option is to always register Business Offering (aka. as perceived by user) and then only engage technical offerings as a context for CIs. This works well but requires standard OOTB commitments and reporting to be done on the business offering level and not on the IT level. Few big companies I've worked with would allow for that, the maturity is just to low.

My last approach...

With my last client what we have done is created additional field of Business Offering. This is the level that captures the offering that "user perceives to be impacted". Out of that we then contextually provide technical offerings to be selectable and apps and CIs. The rest is as it was. Technical offering context is then a combination of what comes from CSDM from the Business Offering Association and CI association. We then allow the group assignment to be taken from any of those levels. As our commitment based SLAs are driven of the OOTB field it doesn't affect the overall IT measuring but provides that first simplification for Service Desk. Service Desk can also close tickets at the level of Business Service without engaging deeper levels of infrastructure support if this is not a technical issue (aka. issue with infrastructure). This approach works for both app and infra use cases but we do have technical offerings for app services as well.

Hope this helps as an example. In the end however, it needs to work for you.

Best Regards,

Michael

[Barry Kant]

Hi Srikkanth, 

the model concept is that:
Business Offerings link to Business agreed KPIs/Commitments to certain subscribers. 
Technical Offerings link to Fulfiller agreed KPIs/Commitments with a providing party (internal/external). 

Beside the real-live feedback from Michael, I give a more ideation view of the process. 

I like to see the usage of incident management like this:
1 - There are Business initiated Incidents (by consumers of IT), that will/can register an Incident on a Business Offerings. The Business user in general have no idea about infrastructure etc, they know an application level or their used assets. 1st Line support or a Service Desk needs to triage what most likely is the root cause and if needed they dispatch the task to a more specialist team to resolve. When having a supply chain model the Business Offering are underpinned by certain Technical Offerings which can help for the triage/dispatching. (top-down)
2 - There are Technical initiated Incidents (monitoring, 2nd line tickets, third-party integrated tickets) that register an Incident on the Technical Offerings they support. Normally they know the impact CI level where that CI is within the responsibilty/managed by a Technical Offering. In this scenario you want to understand the potential impact to the Business (bottom-up impact). This impact analysis output will help an operator triaging the real impact so outages can be made to communicate to Business consumers. 

Depending if you heavily use KPIs/Commitments. 
The Offering related in the Task (Incident) is used for these calculations.
So a Business Offering will give Business consumption KPIs/Commitment output, and a Technical Offering will give Technical Provider KPIs/Commitment output.

BR, 
Barry

[Srikkanth Ajja1]

Thank you Barry Kant, I am able to relate to your explanation, the bottom up impact that you have mentioned was the keyword I was looking for, really helpful

[Srikkanth Ajja1]

Thank you Michael Dul, adding a additional field Business Offering was indeed a new learning to me, and it makes a lot of sense...