What are the Use-Cases for Office365?

Steve Skinner
Tera Contributor

The recent post (CSDM2.0 - Office365 Model Example) seems a good place to discuss about use-cases. I’ve been occasionally browsing this Community and waiting for some genuine examples of how the different components are to be used – maybe I missed something, but I can’t remember seeing anything so far.

So, using the model provided by Stig, can anyone explain when to use each of the different components shown on his diagram? And why?

I also have a question about the 3 technical Service Offerings shown. The text on the left-hand side (2nd level, 3rd level etc) suggests they’re linked to the incident process and therefore potentially could be linked to incident response time SLAs (except they will be OLAs from the perspective of the Business Service). Again – what are the use-cases for these specific service offerings?

As an example, if a traditional call comes through to the service desk from an end-user with a problem accessing Skype – what information does the service desk analyst put into the incident record up front and, as the incident gets passed down through the different support levels, what might change?

4 REPLIES 4

JusCuz
Tera Guru

The best answer I can give, as it's what's really helped me is take the following course to start, read the included material:

CSDM Fundamentals on NowLearning - it includes use cases for incident, problem, change: https://nowlearning.service-now.com/lxp?id=overview&sys_id=5df9c9761be140145c28997fbd4bcbe5&type=cou...

There are also two very good breakout sessions from K20. I believe you can still register if you did not before to access this content. Just go to the K20 site and search for CSDM, find the 2 breakout sessions. They were very helpful to me.

Hi Jason

Thanks for pointing out the course, I'd missed that. However, although I haven't gone through the whole course yet I did look at the incident management use-case document and that doesn't answer to my point about changes during the incident life-cycle.

To explain further - it's always been my view that what you know about a particular incident changes as you work through it and that might mean updating the values in the Business Service / Service Offering / CI fields as you go along. However, there are a few things to consider:

1. If you're triggering SLAs from the Service Offering then you need to understand what will happen to the active SLA if you update the Service Offering

2. At the beginning of the incident I would say these 3 fields represent the 'symptom' i.e. what is originally reported. If you change them during the incident then by the end they should probably represent the 'cause' of the incident i.e. what was actually wrong. There is a actually an important link between these 2 states which may be useful in the future and so you may want to be able to analyse this.

3. If you're using one of the fields for auto-assignment, then you may also need to be updating them as you progress the incident e.g. from L2 to L3 or even to a completely different team, such as network.

4. Whatever you decide, it's really important that the support teams understand exactly how the various fields work and the value of filling them correctly. In my experience, if they can resolve the incident without referring to the CMDB then they probably won't bother to set the fields correctly.

Stig Brandt
Tera Guru

Very good observations, and I have tried to ask a number of similar questions to ServiceNow  and the Community, there is no really good answers, at this stage - even the 'Incident Use Case for CSDM 2.1' - doesn't give an answer to all your questions.

 

But how end users raise the ticket is as you know a complete different discussion, the model supports this - here I write how predictive intelligence should be part of the solution, by identifying the service/service offering based on user input in the short description. 

 

When agent should recognize when to escalate, should be doable quite easy in using the ordering attribute on Service Offering and relate all Service Offerings to the same Technical Business Service = O365.Service.

 

But this again doesn't answer the question, do we change the Service Offering record when escalating or do we create a child ticket?

 

Initially, I see it :

 

- Service = 0365

- Service Offering = O365 Office

- Affected CI = Word

 

When escalate the 2nd, 3rd or supplier level, I would have to use a child ticket, if I have SLA's/OLA's and commitments towards 1st level, 2nd level, 3rd level.

c016smith
Tera Contributor

These are all great conversations, and I really wish more direct responses would come from Service-Now on this.  
I can't @-mention Scott Lemm, but is he in here or anyone else from ServiceNow in the CSDM world going to add their own responses for this and try to provide clarity for us?  That would be super helpful!

Thanks

Chris