ITIL Non-Compliance in SM 7.11?

[Greg_Shrout]

Does it make sense to try to use the ITIL Compliant version of Service Manager? We're having a hard time implementing by using Services/Affected CI's with generic Category, Area, and Sub-Areas - even to the point of considering implementing the older, non-ITIL compliant version SM 6.x.
Coming from Remedy, we route tickets based on Category, Type and Items, and we are having a hard time getting into the right mind-set/usage with Services/CI's. We've even toyed with the idea of adding back in the obsolete field problem-type.
Is anyone having luck with SM 7.11? Or are you struggling with Category, Area, and Sub-Area too?

[Beth Tuttle · Accepted solution]

We recently migrated from another help desk tool to SM 7.10. Because we did not have the concept of CI/Service in our prior tool and we were changing so much other culture in our shop, we took the easy road and decided to implement service/CI at a later date.

We are strongly using Interaction/Incident/Change and are dabbling in Problem/KE. Our prior system did not have the same concept of Problem, so we are getting to the ITIL standard slowly.

We created a service/CI in SM that mirrored our Incident Assignment Groups since "service to assignment group" drives the incident assignments. It is as simple as that.

My plan is once we have good CI data automatically populated in uCMDB, then we build out those areas of CI/Service in SM.

[KyleParker]

We ran into the same challenge. I added back the problem.type field and it works a lot better for our business needs now. We dont really use the Service, but we do use the afected CI(mainly just for what pc/printer the problem is with.)

[Greg_Shrout]

Beth and Kyle, Thanks!
1. Part of what we are struggling with is that we have several teams that are broken down into sub-teams, e.g., the Oracle team has DBAs, Programmers, and Business Analysts.
When something breaks, the Help Desk doesn't know who gets the ticket, they just know it's Oracle. If they assign it to Oracle Team, rather than then Programmers, for example, nobody is going through and re-assigning to the right team - there has to be some accountability. So then you get to the situation where "That's not mine." or "I thought HE was looking at that ticket."
2.After the ticket is solved, we need to have root cause, so that days or weeks later we can say: There were 52 tickets for the HP Printer on 3rd Floor. Closure code is not descriptive enough to do a root cause analysis chart. I wonder if Problem-Type would help with that?

[KyleParker]

Your #2 point is exactly why we brought back the problem type field. We just couldn't find any value in the closure code field for our business needs.

As far as your #1 challenge do you have a secondary assignment group? Or does the Helpdesk just pick the Oracle Team and hope somebody picks up the record?

[John Stagaman_1]

For your point #2, I've addressed this differently at several customers; the OOB model for resolution codes often does not work well for reporting. Some of the solutions used were:
--resolution codes based on the Service (a resolution codes array added to device and mandatory for a bizservice device).
--resolution codes based on the CI Type. (a resolution codes array added to the devtype field; for tickets where the CI was not populated, the generic resolution codes were used).
--I've even had a customer who based the available resolution codes on the Assignment Group that owned the ticket at closure.

I've actually had great success with moving former ServiceCenter clients to the new Services model. It can be challenging initially, but in my experience there's a huge benefit to identifying the service and system experiencing an issue separately from the classification of the issue itself--which the new cat/area/sub-area structure does well.

[Greg_Shrout]

The way it works now, picking Service narrows the list of assignment groups to one or a few groups. But can the Help Desk make good decisions of picking Service? Out of nearly 150 Services, here are a few:
INF: (for Infrastructure) DHCP Server
INF: Desktop Imaging
INF: Firewall
HR: Time and Labor
HR: Payroll
Log: Labor Mgmt
Log: Ship Track
Log: RF Handhelds
An issue that is perhaps even bigger is the category, area, sub-area. Seems like the workflow depends on category - if it is incident, it behaves differently from how it would if the category is complaint. That leaves area and sub-area to describe the problem. So, like Kyle suggested, we're thinking about bringing back the problem-type field. That way we can have three layers of potential problems.

[Greg_Shrout]

Also, I would add that category, area, sub-area are in no way related to Service or Affected CI.
Maybe it would make sense to add logic that causes area and sub-area to queue off of Service; based on what is chosen as Service will determine what will be displayed as area?

[coldbeer]

hi,

1) each of these sub-teams should have its own assignment group.

team members should grab tickets (and first thing to put themselves as assignee) team Leaders should be on the lookout for unassigned tickets in their team. and assigning them. (use views or dasboards or alerts)

The team members or team leaders then can re-assign to another team if needed.

Service Desk staff should be making use of KM to see which team resolved similiar incidents in past. They need to do some "spade work".

2) Problem Management would resolve your printer problem (52 tickets) a problem ticket would have a Known Error or workaround associated with it as well as 52 linked incidents.

Johns last point is good it will be benefit to have services it is great benefit to all modules. esp incident/problem and Change.

And afer all IT report to business on Services. like Payment Delivery (may have several appplications) but business knows it as one Service. In my previous SD site they had a service for each app. there were over 180 services... they realised the mistake 18 months down the track then had to re jig it all down to about 20. This meant lots of work to fix for SD as well as reporting teams. So if you do go down this path then spend some time researching, and check with all parties, reporting, business, config, SLA/SLM, incident etc......


btw, we haven't done it here yet!! Lack of management buy-in and/or interest. I pointed it out when researching 711 upgrade but we are public service so no one makes a decision. (and the idiot here who designed it here originally used "keywords", because that was what he used 25 years ago!)

hooroo


peter

[John Stagaman_1]

Greg,

OOB of box, it actually provides the list of assignment groups for BOTH the service and any selected CI. So if both the Service and a CI are entered, and each has a list of support groups, the escalation wizard will show the groups from both. This provides a little more flexibility than just tying to service.

There's no issue at all with bringing back the problem.type field if you need it.

[Greg_Shrout]

John: that would be great if is easy to bring back problem-type. I see it in the database - that's good. To do it:
1. add field to forms designer
2. add links - I'm kinda shakey with this.
3. add Format Ctrl, if any
4. will need to add to SD.open.interaction, SD.update.interaction, IM.open.incident, IM.update.incident.
Links is the weak area for me.
What else am I missing?

[John Stagaman_1]

The Validity App is used to validate that the combination of category, subcategory, product.type, and problem.type are valid. In SM7 the validity components for problem.type are no longer invoked by the subroutine call to validity in format control.
--you would need to add the problem.type field to the array of fields passed to validity in the subroutine inputs.

--If you plan to alter the link from subcategory (area), product.type (sub-area), and problem.type so that they no longer are category based, you will need to disable the validity validations.

--Note also that should you need to do so, it is fairly easy to add additional categories and extend the escalation process to accommodate them. I've had to do so when an SM7 system was used for both IT and HR issues, so that the HR categories could use a different formset.