Dear ServiceNow: The "itil" role

[Fabian Kunzke]

Hello,

My name is Fabian Kunzke and i am currently working as a solution architect/developer. Within the last year i had the pleasure to work with a growing amount of smaller companies interested in the plattform. Each an every project varied in topic, reaching from a small MSPs to the use of a financial application. In all of these projects on question persisted:

Is it possible to not use anything but the incident management?

Such a simple question. Most of the time i would suggest to utilize the switch to another plattform to reinvent the internal ITSM processes to include change, request or problem management. To go further than "just switching". But for a smaller company, changes like these are not easily achieved.

On the contrary bigger companies, which i have been blessed to work with, wanted a cleaner, more flexible onboarding process for new users. To let them start with the incident management and then expand to other processes as their knowledge and expirience grew.

So two different inputs, same question:

Is it possible to not use anything but the incident management?

Well, possible for sure. But at what cost? OOB? There we would have the itil role. A role not only known as a process oriented one, but also for beeing woven into the fundamental architecture of each and every ITSM-Process on the plattform. In short: whoever has the itil role better be doing all of it.

How come? How is a plattform, known for flexibility, so strictly pushed into a static position. Why does this role even exist? Not only is it used for ACLs, Business Rules, Client Scripts, Views, Modules and any other technical goody, it is also directly assigned to users.

So is it possible to not use anything but the incident management? No. No it is not.

Splitting roles to seperate between users working on problems and those who just want to stick to incidents cause they have not yet been educated in the process? Not possible. Not until you remove the itil role and replace it with your own. But why?

Dear servicenow:

Why does the itil role still exist? Will it be reworked into a more flexible structure?

Greetings

Fabian

[HugoFirst]

Hello Fabian,

I am NOT a ServiceNow employee, but I've used/supported/developed on ServiceNow for several years.

I'm puzzled about your negative opinion about the use of roles. Could you provide some specific issues with the use of roles?

I've had a different experience and I'd like to learn more about your opinion and what underpins it.

To answer your question about "Can you use just incident", the answer is Yes.     All the other modules can be deactivated quite easily and later reactivated if needed.

I recommend that you deactivate the change module to see what I mean.

I look forward hearing more of your thoughts on the use of roles.

[Fabian Kunzke]

Hello,

Sure you could deaktivate everything. But what really do you achieve? The tables can still be accessed by anyone with the itil role. The functionality is not deactivated. It is just hidden. And how would you seperate between two users, one who is using incident and problem, the other one who is using just incident?

And to be honest the way the roles are implemented is probably even more puzzleing. Everything happens on one layer. Adding a new functionality always meant to either assign it to a new role or stick to the "one size fits all" approach.

Don't get me wrong. I am not saying, that this does not work. But in a market which thrives towards flexibility a more flexible rolestructure is needed (imo). I did not say it is not possible. In fact i'd just implement a workaround to this by completly reworking the roles, but i question why it is like this.

Good news: Of course you can get the system to work. But: You should not have to.

Thanks for your insight.

Greetings

Fabian

[HugoFirst]

So if I understand,   the issue is the way roles are implemented out of the box.

So this leads me to the question:   What would a more flexible/effective implementation look like?

[Fabian Kunzke]

Hallo Steve,

Good question. I personally follow a pretty simple construction:

1. Separate between technical and administrative level

As an administrator i want to simply hand somone the role to create a problem (for example). On a technical level this means, that this user needs the right to read users, companies, maybe incidents, potentially CMDB-records and so on. As a developer i would set up a role, let's call it "problem contributer", and give that role the access to whatever it may need to create, write and solve problems. The administrator can then assignt that role. This means, if the developer changes something in the problem implementation, he can use the bottom layer of roles (e.g. the role to create a problem record). The administrator himself does not have to touch that layer. Therefore the developer has freedom in creating/changing functionalities and the administrator has freedom to administer.

2. Never assign technical roles

This basically allows to encapsule an implemented application. Somone needs to use it? There should be a role for that which is not bound to the technical Implementation. Otherwise we loose the developers freedom from point 1. And: If a developer decides to change roles, he can still reassure, that the assigned roles work as before. Therefore, changing a functionality should not impact the abilities of the user.

3. Never assign roles to users (i think this is already a best practice)

As administrator i now have a set of roles which i can "build" my set of group-functions. E.g.: My ServiceDesk only works with incidents: well that group gets the "incident-contributer". The 3rd Level Team of 3 people for linux servers don't work with incidents but changes and problems instead: they get the "change-contributer" and "problem-contributer" role. Someone switches between those teams? Just move him from one team to the other, no roles to assign here.

I have picked this up on my old working place, so it is not from me and probably not unknown. Actually its pretty simple and works brilliantly with agile development. Since development and administration is separated.

I hope i could answer your question.

Greetings

Fabian