Design Question on ITSM Categorization and it's usability

[Vivek_Hegde]

Fellow Experts,

I am designing ITSM for one of my clients and I think I have a very valid question on the startegy of maintaining categories. In the ITSM, be it a Service Request or Incident; they are driven by Categorization. We have catergorization schema designed based on the current customer need. However once the ITSM is operational there mighty be need to change/add/modify the Categorization Schema in ITSM.

So what is the vision of SAP  when it comes to maintaining the Categorization Schema in ITSM? Should we give access to end user to modify categorization or should it rest with Administrator? If it is end user driven then how can we simplify the experience of adding/modifying categories in ITSM for an end user?

Your thoughts are much appreciated.

Regards

Vivek

[former_member204161 · Accepted solution]

Hi Vivek ,

My thoughts on your query - the categorization of tickets is an organisation wide thing , and is usually decided at a high level , at the time of the requirement analysis itself . Any changes to it should be done only by the administrator . If end users are allowed to edit it , there may be many users making changes and activating the versions , leading to confusion . All these edits will effect all new tickets .

The administrator can collect requests for new categories from different key users/org units , and make the changes at one go , updating the version of the categorization schema . This would help in tracebility too

Changes in category should be treated in same way as requests to add new org structure/Ibase ie. they can logged and done by the Solman consultant/ administrator .

Regards,

Shaswat

[Vivek_Hegde]

Thanks All for your inputs.

In practical scenarios I have seen; the client do not want to keep one resource just to manage the Categories. Because once we hand over the ITSM setup to client; the client expects maintaining Categories to be a simpler task. In the current design  I am working for a client; they have 400+ categories and all the  BRF+ rules rely on them.  Since the client does not want to hire a person just to maintain these categories; I am suggesting them to train the Basis guys to handle this.

Even I agree with all of you that, maintaining categories job should never be given to end user; it leads to disaster of entire setup. I liked the idea of having periodic maintanence model for Categories with Bi monthly or Monthly review/release.

Thanks Again;

Regards,

Vivek

[prakhar_saxena]

Hi Vivek

Just to add, it also varies based upon customer future direction or amount of usage of Solution Manager....also for big and small customer of sap this scenario changes a lot practically

Because Basis can create master data but won't be able to make any changes from functional perspective like process change or improvement or any other ALM Module integration, they would like to have it later.

Best Regards

Prakhar

[prakhar_saxena]

Hi Vivek

I am not sure if you checked my reply but it is branched here

http://scn.sap.com/thread/3460425

let us know further

Regards

Prakhar

[Former Member]

Hi Vivek,

Never ever give authorizations for End-users to maintain this, Categorization schema have many dependecies and powerfull possibilities like BRF+, copy control rules, reporting and etc.

Btw there is a possibility to insert 2 categorization schemas to one tr. type just in case you need it.

I agree with Sebastien and Shaswat.

Rg Dan

[sebastien_duprez01]

Hello,

I regard the multi-level categorization changes as quite critical in the systems. In most of the customer implementations I have managed, the categorization was a central piece of the process execution.

It would be used to support BP determination (with BRF+) and also be a very structuring information for reporting. Sometimes we even have 'dependencies' between the categorization and the Org. Model (PPOMA_CRM).

This means : not changeable by end-user and to be treated as sensitive. Requires a strict testing before delivering changes to production

Regards, Sebastien