How did you implement the incident management process on CA SDM ?

[Legacy User]

Hello,

 

We are going to update the implementation of the incident management process on CA SDM in my society.

After some workshops with our users, some subjects seem to be satisfying but, I would know how did you implement this process in your society.

 

I am particularly interested about :

- Categories : our declination is really bad, and very hard to maintain (one category for each application...and that's not the worst...believe me). We're looking for a very restrictive list and I would know what is yours ?

- The workflow : the list of your statutes, in wich case do you use the workflow tasks ?

- Rootcauses : in our case, this field is never filled because it is not mandatory. How did you solve this problem ? And what is your rootcauses list ?

- Priority management : we juste have a minimized matrix, priority is the result of the impact and the emergency. But in not any case, this emergency increase. How did you handle this setting ? In wich case ?

- Closure : is there any automation ? Is your servicedesk check the good solution with the user ?

 

As you can guess, I would like to share your experience because I can't find any best practice. I am sure I can learn about your answers, so please, any help is welcome.

 

Thank you very much.

[Giedrius Bekintis]

Hi,

This is typical result from process design with the customer

Categories: categories are used for routing purposes, for example you may have locations based autoassigment for workstation support, and default group for email related issues.

Workflow: It is normal to use workflows for request, but incident resolution is the firefighting process, they should be resolved ASAP. Typical statuses Open, Work in Progress, Resolved, Closed, Transfered 3rd party, Returned form 3rd party, Avaiting User Response, Response Provided. The only statuses that stops service type clock is resolved and closed. If you will use statuse like hold and etc You simply will cheat on SLA and will hide the existing problems.

Rootcause: Use trigger and spel code to check whatever rootcaus is specified on incident resolution, Typical rootcause examples: User error, Application error, DB error, HW failure, Connection failure, Configuration mismatch and etc.

Closure: Typicaly we allow for analyst to set status to resolved, then we use status transition types that allows end uses to close or reopen incident within 2 or 5 working days, after that incident is automaticaly closed without possibility to reopen.