SLA philosophy: about query priorities

I continue the cycle of articles about SLA, publishing what doesn’t fit into the main article How to write a good SLA .

It is no secret that starting from a certain level of maturity in IT companies start registering requests in special systems, trackers. This allows you to understand who does what and what, analyze the current situation and the work already done and a lot of useful things - with the proper formulation of the case, the benefits significantly outweigh the bureaucracy. The order of execution of requests is governed by priorities.

For many, many years of work in supporting a variety of IT systems, I really liked the system of the four priorities, which will be discussed below. This system has shown itself so well in practice in a variety of projects that I am genuinely surprised to meet with other approaches to priorities. So I am ready to make a certain amount of effort to popularize such definitions of priorities. So that they are used more often and met more often in life.

TL; DR or immediately about the essence

If you have no specific reasons (which you are ready to clearly formulate in writing), then in the support of IT systems, use the following priorities:

These priorities should be correctly understood and used by all IT company employees involved in the maintenance process.

For users of IT systems from business, priority should be set automatically based on the properties of the request specified by them, based on relevant, but possibly objective properties. For example, on criticality and degree of influence:

At the same time, for specific systems, criticality can be indicated right there. For example, for an ERP system, this could be the ranges of expected losses: over 100 million, from 1 to 100 million, to 1 million. It may be appropriate to use modifiers like "VIP-person involved", raising or lowering the priority. The compliance matrix should remain simple and transparent, but not allowing setting high priorities unreasonably.

The reason for this seeming "discrimination" is discussed below.

Further on this in more detail and in detail.

Why priorities are needed and what they should be

When we write the rules ourselves, we set the "rules of the game" ourselves. And it makes sense to establish such rules not anyhow, but to make it as convenient and effective as possible. This is a matter of experience, but you need to start dancing from something. Further already in place. Let's talk about how to prioritize. Let's start as usual with the main thing - with the answer to the question "why is this necessary."

We need priorities in order to isolate from the general mass of requests those for which we want more action. So we can:

1. Organize the work of the contractor - tasks with a higher priority should be solved earlier.
2. Introduce into SLA different target values ​​of metrics depending on priority, which, on the one hand, will show that tasks with a higher priority are solved in a more urgent order, and on the other hand, they will allow to evaluate how well these rules are implemented.

Convenient to have 3-5 priorities. Usually this is enough for all occasions, another number of priorities is more exotic. For priorities to work properly, requests of higher priority must be 5-10 times less than the previous one. It turns out such a characteristic ladder (see fig.). And then a request with a higher priority due to its exotic nature will attract natural attention and will not get lost in the total mass of requests of a particular performer. It is assumed that during normal download, on each artist, on average, 5-15 open requests are hanging, and half of them require action from someone else. Then, with an increased priority, each performer will, on average, have no more than 1-2 requests, and it is perfectly clear from which end you should start working.

I would also like to have such priorities that are logical and well understood by all participants in the process. Because a change of priority can change too much the target metrics of work, and if one of the parties disagrees, then there will be a conflict, which I would like to avoid. Changes in priorities should occur when the scale of the problem being solved changes or when new information appears that significantly changes the initial formulation of the problem.

In my many years of experience, the system of four priorities is very convenient. I have already quoted them in the article " How to write a good SLA ". Well, at the beginning of this article. These are the three main priorities (Low, Medium, High) and one extraordinary (Highest) for those very cases when everyone throws everything and only begins to deal with this problem to the bitter end.

Such a prioritization system is rather intuitive. Less than three regular priorities use is not good, it does not scale well. More than three are not really needed, and Ockham did not order.

Prioritization

It remains to justify the definition of priorities. This can be done in different ways. You can simply determine without justifying. You can and justify. Without claiming universality, I will give one of the approaches. It is interesting only in that it can be repeated for other specific conditions. The approach will be as follows. We will come up with a criterion that allows us to highlight those that require more attention from the general mass of requests. Then from those selected to choose those that require even more attention. The course of thought, I hope, is clear. And then from these criteria and make the determination of priorities. To make the definitions clear, we will try each time to choose such a criterion so that it is as simple and clear as possible.

Immediately, I note that by default, requests must always open with the lowest priority, and higher priorities must be justified in the request. Otherwise, the desired ladder will not work. The requirement to substantiate the increased priority in writing is important, since it forces the initiator of the request to ask himself the question whether the problem is really critical. Try it yourself and realize that this is a very good filter.

Let's return to the division into priorities. First of all, we will divide all requests for important and unimportant. All unimportant ruthlessly close.

Lyrical digression

There are no unimportant requests. If the problem is not important to anyone, do not waste time on it. This is a question of work efficiency. The most effective way to solve unimportant problems is to recognize the problem as unnecessary and close the request. Never leave open "for later" problems. That's when you're ready to deal with them, that's when you start. And if you suddenly do not remember, it means it was not necessary. Close up Otherwise, no SLA will help. The world is imperfect, there is nothing to try to eliminate all injustices in it (see fig.). Although agree with this and hard. My inner perfectionist also objected, but exactly until I put him in front of the fact that we would do unnecessary work in our spare time. If so hurts the conscience, then mark such closed requests so that you can return to them later. When, for example, a heap of all current problems was suddenly raked and there was nothing else to do. But this should not happen, if you regularly have nothing to do, it means that some of the resources need to be released for something else, more useful.

Now we have all the important requests, we will select from them urgent and critical. Because not every important problem must be urgent or critical. Quite the contrary, critical or urgent problems do not appear very often. If for some reason it seems to you that all problems are urgent and critical, then just try to formulate in writing what the importance and criticality of each is. These are those for which one doesn’t have to try and think up the reason for the importance or take it impudently (you don’t understand it yourself, this is very critical!), They will be critical.

Now, from urgent and critical, select those that do not have workarounds to solve the problem. Yes, it is not so rare that it is quite possible to cope with a specific situation without solving the original problem. To count with hands on a piece of paper, to collect a report in Excel, to carry out a manual operation instead of a regular one, etc. These are all workarounds. Nobody argues that it is inconvenient to do this, and that it is necessary to solve the problem, because why do we need an IT system if it does not work. But if there is a workaround, you can spend more time on solving. Therefore, if a workaround exists, then it should be used immediately. While the performer is trying to solve the problem in a general way, the initiator immediately, without losing time, proceeds to use a workaround. And if the initiator can afford to wait for the solution of the problem, then the problem is most likely not so important or urgent, for which he tried to issue it, you can lower the priority.

More lyrical digression

This principle of parity is generally very important in the process of supporting any IT systems. Neither side of the process should need more than the other. Must be parity. If one side says "well, then you yourself, and I - home, in the morning so that everything is done," then the priority should immediately be lowered and also go home. What is the point of working hard, to find a solution in the dead of night, so that it remains unclaimed until the next working day? Either everything is working, or everything is diverging. This rule works especially well in emergency mode. Avral and need to go to work around the clock? Ok, the IT department is ready to work in this mode, if necessary, for this purpose it was created. Is the business ready? .. I do not even consider the reverse situation (when the business needs it, but IT is not ready). Such IT should be immediately dispersed at full strength, since it does not understand who for whom the IT department works is incompetent.

Let's go back to the priorities. Do I need to allocate something more important to a separate priority? Yes, it seems to be no longer needed. Then only a hint.

Thus, we managed to break all the requests into classes, and each next class of requests is more rare and requires more attention and faster response, which is what we wanted:

• important, but critical requests (by default, all new requests fall);
• urgent and critical (a rationale for why is required);
• urgent and critical, for which there is no workaround (also of course with justification).

And of course super priority:

• all throw and deal only with this problem without sleep and rest.

The last priority is usually allocated from the general number for the reason that it works around the clock, unlike all previous ones, for which work is carried out during working hours. If the principle of parity of necessity is observed, this priority is not even particularly necessary to determine. No one in common sense will not initiate a round-the-clock mode, if in fact he does not pripret.

Total got four clear priorities. The wording of the definitions on the clerical (so that you can take in its regulations and correct in place), see the plate above.

You can take the names suggested by me, but you can take neutral numeric ones - the first (highest), second, third and fourth. And it happens that someone's hand does not rise to open requests with priority, which is called "Low". For example, I used to use both.

Priorities for business systems users

All of the above about priorities applies to those people who are engaged in technical support for duty. Support staff should be familiar with the overall picture of IT and be able to set priorities objectively and consistently in accordance with internal regulations. It is better for users of IT systems from business not to give an opportunity to choose a priority, but to set it automatically. A good approximation is the diagonal matrix of influence and criticality from the classical definition of ITIL priority. An example has already been given above.

Why is that? It's not a matter of mistrust to users, they say, they are poor and miserable. Just for the user of the IT system, any problem that interferes personally with him will always be of the highest priority. Because it prevents him from doing his own work, and right now it interferes. And in fact, as always, non-time broke, just when it was necessary. Otherwise, the user would not have gotten into the system and, moreover, would not have contacted the help desk. He already has something to do from his immediate duties. If he had a lot of requests, then he could place priorities in them. But the user in most cases there is only one request for support. And the overall picture of IT is unknown to him, and uninteresting, unlike the support staff.

And an ordinary user contacts the support service infrequently and, even trying to be objective, may simply incorrectly issue a request, indicating the wrong priority, or even not indicating it at all, or pointing out the priority higher just in case (it’s better to err ). Well, and so on.

Therefore, users will put any priority, but not the one that should be, and there is no reasonable force that would cause them to set the right priorities. So it is better not to give them the opportunity to make mistakes. Let it be better to fill in a couple of mandatory attributes in the request, and the output will be something pretty good looking like priority.