"Support", how much in this word ...
So, I continue a series of articles “from creative leave”, this time we will consider such “scary” things as “product support”, “technical support”, “support service”, etc.
This article will not address issues of team management, deployment of a call administration system, and details of the work of support department heads. Rather, the article is a kind of introduction to the issue of "support for IT products"
So, traditionally, let's start with the basics. Let's try to answer the question:
Let’s say we have a bus manufacturer company that has departments for “development and production” and a department for “technical services” that provide warranty service for buses sold. There is also a second company, a consumer, who bought one of the buses to carry their employees along a certain route inside the campus / office campus. So, in this specific example, we get the following picture:
The consumer company has:
And in the manufacturing company we have:
Obviously, an attempt to completely transfer the approaches to the organization of work of the “support service” adopted in one type of company to a company of another type is at least not smart, but often harmful.
But this is clearly seen in the example of buses, but, for some reason, is not at all obvious in the case of IT.
Let's try to understand a little more.
Formally, support and support services for software products are at the junction of ITSM and CRM. And, as it usually happens, several nannies have a child without supervision. At the same time, with the organization of the work of administrators, the issuance and maintenance of IT equipment - often there are no difficulties. It turns out a kind of paradox, it seems that both here and here are the IT sphere, and both here and there are quite competent employees and managers, but in one case everything basically works quite acceptable for itself, and in the other how it works out. What is the difference? Why can we provide support for equipment, operating systems, web services, but at the same time with the support of business platforms, such as accounting systems, data analysis systems, document management, business process management and others, are there often difficulties? What could be the catch?
Let's take another example, a little closer to our subject. So, we have a company that uses some kind of “standard” configuration of the accounting system (no matter which). Since the configuration is standard, the company does not have a staff of developers to make corrections and changes to the system used. It is quite obvious that users have various kinds of problems and questions with the use of this system. Users are people who are somewhat far from IT (“sales people”, accountants, bosses, etc.) and they don’t have a hard time understanding the details of how it actually works inside, and it’s just no time.
At this point, let's dwell a little more. So, with us this is a pure company - a consumer. That is, the company itself does not produce the product it uses, but buys it on the side. In this case, if there is no “support service”, then end users themselves will try to solve the problems that arise. As a result, a lot of time, nerves are lost, miracles with data begin, etc. In general, everything is as always.
And the head of the newly organized “support service” asks himself two main questions:
We go further, but how to evaluate the work of the employees of this service? The speed of solving the problem? More likely no than yes, since they cannot and should not go inside the configuration or platform of the accounting system. Therefore, we exaggerate a little, and it turns out that their tasks are also quite obvious - make sure that:
The last point is, unfortunately, still rare, but it is very desirable in real life.
So, at the moment, we are, in general, moving in the right direction. About this we are told books from ITIL, a lot of articles read, and the logic also confirms this. And in fact, there is no revelation. But they will come next.
So, our manager did everything well, everyone is happy, and already the company, the manufacturer of this very accounting system, invited him / her to establish their “support service”. And here miracles begin. In a new place, he / she again asks the same questions as before:
Иными словами, в данном случае, заказчиком услуг «службы поддержки» являются уже не пользователи, а разработчики. И им уже не нужно требовать, чтобы сотрудник отдела что-то там собирал и отдавал им, тут уже необходимо, чтобы эта служба была в состоянии сама решатьmost of the problems. Do you understand the difference?
It turns out that with a similar name, and, it seems, as one function, departments have completely different requirements for their work. That is, we have two poles, two pure and completely opposite approaches to organizing the work of the “support service”. Unfortunately, few people see this difference, and of those who see it, they often ignore it.
Indeed, the same ITIL does not denote this difference, and the vast majority of interpretations are based precisely on the approach for consumer companies. For this reason, I prefer the option of “support service” for manufacturing companies to name “technical support”, to distinguish it from “customer support service”, “software support department” and other “service desks” in consumer companies.
Summarizing, we get the following picture:
Obviously, in real life, we have to use a compromise and a mixture of these two opposites, but, nevertheless, knowing these “ingredients”, the leader will already be able to prepare his own recipe that best suits the conditions of a particular organization, build the appropriate processes and prepare the SLA, which will be in the interest of all interested parties (including the support / support department).
Well, and as a bonus, a small list of unsuccessful approaches to the organization of support services.
That’s all for me. Your comments and reasoned comments are in every way welcome.
Good luck and success to all.
Sources of images:
1. “Frozen” doggie - from here
2. “Stern” dog - from here
3. Call center: from here
4. Bus service from here
This article will not address issues of team management, deployment of a call administration system, and details of the work of support department heads. Rather, the article is a kind of introduction to the issue of "support for IT products"
Where does it all begin
So, traditionally, let's start with the basics. Let's try to answer the question:
What is a support service and what is it for?Although the question sounds simple, the answer to it is not so simple. And the reason for this is far from the complexity of this sphere of activity. The reason is that there is a small feature here - “support service”, as well as “support” in general, are not universal concepts. Their values are very dependent on the specific situation that we are considering. And to show this, I will give one very sketchy example.
Let’s say we have a bus manufacturer company that has departments for “development and production” and a department for “technical services” that provide warranty service for buses sold. There is also a second company, a consumer, who bought one of the buses to carry their employees along a certain route inside the campus / office campus. So, in this specific example, we get the following picture:
The consumer company has:- users are bus passengers
- “Support service” is a dispatcher, or help desk, and conductors in the bus itself,
And in the manufacturing company we have:
- developers is a department of "development and production"
- and also, a “support service” - in this case, it is already a department of “technical maintenance”
Obviously, an attempt to completely transfer the approaches to the organization of work of the “support service” adopted in one type of company to a company of another type is at least not smart, but often harmful.
But this is clearly seen in the example of buses, but, for some reason, is not at all obvious in the case of IT.
Let's try to understand a little more.
Formally, support and support services for software products are at the junction of ITSM and CRM. And, as it usually happens, several nannies have a child without supervision. At the same time, with the organization of the work of administrators, the issuance and maintenance of IT equipment - often there are no difficulties. It turns out a kind of paradox, it seems that both here and here are the IT sphere, and both here and there are quite competent employees and managers, but in one case everything basically works quite acceptable for itself, and in the other how it works out. What is the difference? Why can we provide support for equipment, operating systems, web services, but at the same time with the support of business platforms, such as accounting systems, data analysis systems, document management, business process management and others, are there often difficulties? What could be the catch?
Let's take another example, a little closer to our subject. So, we have a company that uses some kind of “standard” configuration of the accounting system (no matter which). Since the configuration is standard, the company does not have a staff of developers to make corrections and changes to the system used. It is quite obvious that users have various kinds of problems and questions with the use of this system. Users are people who are somewhat far from IT (“sales people”, accountants, bosses, etc.) and they don’t have a hard time understanding the details of how it actually works inside, and it’s just no time.
At this point, let's dwell a little more. So, with us this is a pure company - a consumer. That is, the company itself does not produce the product it uses, but buys it on the side. In this case, if there is no “support service”, then end users themselves will try to solve the problems that arise. As a result, a lot of time, nerves are lost, miracles with data begin, etc. In general, everything is as always.
And the head of the newly organized “support service” asks himself two main questions:
- What is the purpose of the “support service”? Who do they work for?There should not be any difficulties with the answers. This service is created in order to take on the work with the manufacturer / supplier and save end users from technical manipulations that they do not need. That is, the customer (consumer) of the results of the “support service” are end users.
- What should be the ideal employee of this service?
We go further, but how to evaluate the work of the employees of this service? The speed of solving the problem? More likely no than yes, since they cannot and should not go inside the configuration or platform of the accounting system. Therefore, we exaggerate a little, and it turns out that their tasks are also quite obvious - make sure that:
- when performing the recommended and / or available actions, the system does not function as expected;
- famous "dances with a tambourine" do not help;
- the description of the problem is translated from the language of users into the language of terms of the system used;
- all necessary information is collected and transferred to the manufacturer / supplier as soon as possible;
- the user got the opportunity to solve their problems in another way, if possible.
The last point is, unfortunately, still rare, but it is very desirable in real life.
So, at the moment, we are, in general, moving in the right direction. About this we are told books from ITIL, a lot of articles read, and the logic also confirms this. And in fact, there is no revelation. But they will come next.
So, our manager did everything well, everyone is happy, and already the company, the manufacturer of this very accounting system, invited him / her to establish their “support service”. And here miracles begin. In a new place, he / she again asks the same questions as before:
- What is the purpose of the “support service”? Who do they work for?И вот в этом случае, ответы уже будут очень сильно отличаться от того, что мы видели ранее. Итак, мы имеем дело с компанией – производителем. То есть компания имеет штат разработчиков, которые придумывают и воплощают в жизнь свои идеи в некоем продукте, которым пользуются другие компании. И получается, что при отсутствии «службы поддержки», именно разработчики вынуждены отвлекаться от своей основной работы и заниматься пустяковыми (по их мнению) проблемами, в то время, когда «вселенная нуждается в идеальной учетной системе».
- What should be the ideal employee of this service?
Иными словами, в данном случае, заказчиком услуг «службы поддержки» являются уже не пользователи, а разработчики. И им уже не нужно требовать, чтобы сотрудник отдела что-то там собирал и отдавал им, тут уже необходимо, чтобы эта служба была в состоянии сама решатьmost of the problems. Do you understand the difference? It turns out that with a similar name, and, it seems, as one function, departments have completely different requirements for their work. That is, we have two poles, two pure and completely opposite approaches to organizing the work of the “support service”. Unfortunately, few people see this difference, and of those who see it, they often ignore it.
Indeed, the same ITIL does not denote this difference, and the vast majority of interpretations are based precisely on the approach for consumer companies. For this reason, I prefer the option of “support service” for manufacturing companies to name “technical support”, to distinguish it from “customer support service”, “software support department” and other “service desks” in consumer companies.
Summarizing, we get the following picture:
Customer support | Technical support service | |
|---|---|---|
Customer (consumer services department) | End users | Development / Testing Department |
Employee Tasks |
|
|
Employee Requirements |
|
|
Obviously, in real life, we have to use a compromise and a mixture of these two opposites, but, nevertheless, knowing these “ingredients”, the leader will already be able to prepare his own recipe that best suits the conditions of a particular organization, build the appropriate processes and prepare the SLA, which will be in the interest of all interested parties (including the support / support department).
What usually come
Well, and as a bonus, a small list of unsuccessful approaches to the organization of support services.
- Using chat bots. Recently, this trend is gaining momentum and many people think that this is a great way to save on the number of employees. At the same time, no one even thinks about why people are contacting the support and support department. So, chat bots and other search capabilities are strictly necessary when the user cannot (with a poorly structured or complex and confusing organization of the so-called "knowledge base") or does not want (due to excessive employment or laziness) to search for information on his own. In other words, only if the user does not understand or cannot find the necessary information in the online documentation quickly enough, then an advanced search tool or chat bot will help him in this. Chatbot should not concern any non-standard or technical problems. Unfortunately, few people understand this. Of course, there is a huge desire to force users, finally, to use the documentation and articles posted on the corresponding portal, and not to contact the department for already painted and simple questions. However, it is more correctly and simply solved by administrative methods, and not by an attempt to aggravate everything. And the second point, connecting the support service to help “for every sneeze” for users is not the most commercially viable solution. On the one hand, the company takes responsibility for the solutions provided, and on the other, it is not compensated in any way. In other words, this approach takes bread from the departments of implementation / professional service. However, it is more correctly and simply solved by administrative methods, and not by an attempt to aggravate everything. And the second point, connecting the support service to help “for every sneeze” for users is not the most commercially viable solution. On the one hand, the company takes responsibility for the solutions provided, and on the other, it is not compensated in any way. In other words, this approach takes bread from the departments of implementation / professional service. However, it is more correctly and simply solved by administrative methods, and not by an attempt to aggravate everything. And the second point, connecting the support service to help “for every sneeze” for users is not the most commercially viable solution. On the one hand, the company takes responsibility for the solutions provided, and on the other, it is not compensated in any way. In other words, this approach takes bread from the departments of implementation / professional service.
- Savings on employees . It is very popular to divide employees by qualifications into support levels, and to set the “dumbest” (that is, the cheapest) to the first lines of support. Although initially it was implied that the division into support levels is functional rather than qualifying in nature. It turns out as a variant of the previous paragraph with chat bots. Managing staff are simply unable to organize the interaction with the employees of the department users, and tries to solve the problem head-on - a set b of ng bigger the number of employees for a price that is available. As a result, the quality of service simply falls, and, to the complete surprise of managers, the load on “qualified” employees only increases.
I am already silent about the special training of support staff. - Using your phone as your primary way to get support. In general, it’s rather strange to see that when organizing support / support departments, it is often preferred to create call centers. If we are talking about support for IT systems, then one phone call requires about the same amount of resources as processing 2-3 incidents filed through a portal, forum or email. Calls are sometimes necessary and important, but not so expensive (for the department) type of communication is rational and convenient from the point of view of organizing support for users and / or customers. Even if you do not go into the details of monitoring the quality of the product and / or services, organizing comfortable communication with users / customers, even the issues of accessibility and dissemination of experience and knowledge within the team, with telephone communications, require additional effort and cost.
- Using Support as a Secretariat. In other words, when the first line of support plays the role of a kind of dispatching department and directs users to the right employees, depending on the issues and problems encountered. In fact, this is an alarming “bell” that the company “something went wrong.” The support service, although it is an integral part of CRM (Customer Relationship Management) - a customer relationship management system, is precisely its part, and not its substitution. Therefore, when a customer contacts support with a problem that he has expired the product license, this means that the acronym CRM in the company is a tick, and the profile departments (in this case, the sales department) are engaged in anything but their direct work.
- Imitation of "personal" accompanimentwhen employees of support departments subscribe only by name, for example, “Maria”, “Ivan”, etc. Of course, I understand that this is an ordinary phenomenon abroad and, on the one hand, alludes to "warm friendly relations", and on the other hand, it somewhat amuses the pride of Western users (the servants did not have last names), but even there it makes sense only very rare cases. In the practice of IT support, this creates only difficulties. The simplest situation: in the department, four people are named “Alexey” (a real case), and due to circumstances, only one of them is present in the office (the second is on vacation, the third is ill, the fourth is on a business trip) and there is a problem for one of incidents, which was served by a certain "Alexei". As expected, the one in the office has no idea what is at stake. What to do to the supervisor / leader or department head,
On the other hand, when a certain “Fedor” speaks to you, it is far from always comfortable, since you do not know this person, no one has imagined him to breed “familiarity” and, in general, how can you be sure that “Fedor” Is this his real name?
Therefore, always, with any response from the company, the signature should contain at least the name and surname of the person who sent the message. Even if this letter / message comes from the team as a whole. In addition, if one employee began to process the appeal, then he will work on this particular incident to the end, without constantly switching participants from the company. Change is allowed only if necessary (for example, he gets sick, or is overloaded with more important requests, or “technical support” employees “picked up” the work) and the new responsible employee should always introduce himself and indicate whether he will work until the end of the application, or only temporarily processes it. In general, all this is very strange and it seems that many managers simply do not know the basics of administrative work. - Creation of departments “Customer Success”, “Technical Enablement” and other “Fulfillment” . Again, this is a recent fashion, mainly related to the enthusiasm of the "Agile" development methods and is an attempt to establish feedback, as they say, "in the forehead." Unfortunately, in reality this is usually an indicator that having failed in organizing the normal operation of both Deployment, Training, User Support / Support Departments in particular, and in implementing CRM methods - in general, people began to sculpt alongside some already working departments, a new duplicate service. Alas, quite often with the same success.
- Cargo Cult ITIL / ITSM . In fact, this is the biggest problem in organizing the work of support services. The framework artifacts require a sufficiently deep analysis before their implementation and a clear understanding of what we are doing, for the sake of what, how and why. For example, take CMDB - a database of configuration / settings and the history of their changes. Consider a simple question: what information / attributes and their changes do we need if we support a certain business platform (for example, an accounting system)? There is a temptation to add everything that is possible there, but for companies of the “1C” level, with tens of thousands of customers, this will turn the system into a repository of unnecessary details to anyone.
But most often the creation of CMDB is simply ignored, storing information in disparate files, letters, and even on pieces of paper. The difficulty is that the selection criteria for configuration / changeable parameters are not given in ITIL manuals (for example, in the same third book “ITIL Service Transition”). There is only a classification and some examples taken for cases of administrative work. Therefore, literally everything depends on the qualifications, experience and intuition of the ITIL implementation architect.
I hope this at least shed some light on the fact that “knowledge of ITIL / ITSM” alone does not guarantee anything and requires first of all understanding that there is support, why it is needed in this particular case and that is a sign of the success of its work. - "Curves" KPI . This item goes “out of competition”, like all performance metrics in general. The fact that they are needed is now understood by everyone. But here are the questions: “for what?” and "which ones?" - are already “backfill questions” for the vast majority of managers. The same is the case in the case of evaluating the effectiveness of the support / support departments. The simplest example: how to evaluate the utility of an individual department employee? How many incidents have been handled? If so, does this mean that 100 solved problems in a week is better than 10? In real life - it does not mean far. These 10 incidents can be so complex and important, and the hundred are simply the easiest to compare amounts in the forehead - it is simply pointless. Unfortunately, few people recall that the essence of KPI is a numerical characteristic for routine, repetitive andsimilar work / processes. Therefore, it is not so easy to display the contribution of support staff in numbers as it seems at first glance and it will be expressed by a certain integral metric.
In addition, an analysis of the work of support services allows us to evaluate the quality of work of external service providers and / or the development department. This part of the activity analysis is often ignored altogether.
That’s all for me. Your comments and reasoned comments are in every way welcome.
Good luck and success to all.
Sources of images:
1. “Frozen” doggie - from here
2. “Stern” dog - from here
3. Call center: from here
4. Bus service from here
