Implementation of Service Desk and CRM. 13 main causes of failure and how to avoid them?
According to The Standish Group in the USA and Europe for 2015:
Total: 83.8% (actually 8 out of 10) failures versus 16.2% success.
Over the past 10 years, these numbers have not changed much - when implementing IT systems, a business is faced with typical problems that can be grouped as follows:
And what leads to failures in the implementation of Service Desk and other systems in Russia?
We are developing a Help Desk system for automating all after-sales service processes in service companies . After talking with more than 5,000 representatives from a wide variety of service sectors (medium and small businesses), we decided to share the reasons for the unsuccessful implementation of Service Desk in Russia / CIS and methods to overcome most difficulties! In fact, the problems turned out to be “universal” for the implementation of any IT systems and IT projects.
We are sure that this will allow you to prepare and avoid at least some of them.
Communication with 5000+ service companies operating in the b2b segment in Russia and the CIS countries does not provide accurate statistics on projects, but allows us to identify similar groups of problems (not without local specifics). Next, we consider each item in more detail, focusing on the most popular "representatives" of failures. It is worth noting that the classification of problems used is conditional and selected only for convenience of presentation. Selected groups intersect with each other. For example, the fear of change is inextricably linked to organizational issues, etc.
Many truly believe that an automation system will solve all problems. In the current processes of most service companies, chaos reigns, and it seems that the introduction of Service Desk or CRM will allow you to get full control over the situation regarding sales or customer support.
This is a big mistake. There is a well-known saying: “If your company has chaos, then the result of the introduction of an automation system will be automated chaos . ”
No tool can solve pressing internal problems. The effect of introducing Service Desk in companies with low maturity will undoubtedly have a serious effect (for example, it will eliminate the loss of applications, reduce the delay of SLA , etc.). But the successful completion of a project with understandable and measurable results, which can be further developed, is hardly possible in the general case without changing the organizational component.
This problem is characteristic of a larger and more bureaucratic business.
As a rule, the processes in such companies have been developing for a long time, some kind of management scheme is taking shape. On top of this system there is “patchwork” automation - Service Desk in some specific areas, different CRMs in different departments, etc. But the business wants to get a single centralized and automated system, linking all processes to each other. The mistake is that at the same time he does not want to adapt to the existing systems and best practices in accordance with which they are developed, trying to "pull" the selected product on his requirements. And to do this is extremely difficult.
To achieve the result, together with the implementation project, you will have to change approaches to work, carry out organizational changes and even get rid of some people or, conversely, introduce new roles in the state. And all this must be done reasonably, understanding what indicators are required to be achieved.
Service companies really consider something like this:
They are not even ready to try to change the existing scheme of work, for example, by proposing new, simpler and more convenient testing mechanisms to several of their clients. From the very beginning, they have the confidence that customers will reject everything new. This means that it makes no sense to launch a project, or, conversely, a launched project is not brought to an end.
This problem is largely associated with the introduction of service desk systems because of the comparative complexity of support processes. Refusal of projects is associated with a fear of reorganization. But often, such changes benefit the business. They can be based on “best practices and libraries” in which they are aggregated - ITIL, or the approach to organizing ITSM service management , but small and medium-sized businesses, of course, refuse to use these “best” practices.
A great example is a service company where 10 or more people are engaged in maintenance, not 2-3. On such a scale, firstly, there is already a large flow of applications, and secondly, there is a clear gradation of people in terms of competencies and payment. The reorganization of the support service involves the allocation of the first, second, third lines, a change in interaction with contractors and much more.
Not taking into account the reorganization, companies are either afraid to launch projects for introducing service desk systems, or they are implementing them, but they do not get the desired result (automate chaos).
Companies postpone the implementation of tools when they realize that the real time costs of employees when working with the new service desk system are growing. And this is true!
At first, you really have to spend more time. For example, you will have to register 100% of applications, note the actions performed during their processing, write off labor costs, etc. But inefficiency points cannot be identified without fixing activities and tracking metrics on them. Therefore, before starting the project, you just need to answer the question “What do we want as a result of the implementation of the service desk?”
In Russian business, “familiarity” relations are very common. And the more “home” a company is, the more complex it is. This is especially evident in companies on the periphery - in the business for 10 - 20 people who have been working together for a long time.
Cronyism raises difficult moral questions when changes or dismissals of those who work poorly are required. Often in such situations, the project is suspended, and the new tool is not used, because within the company there is discontent or an unanswered question: “How so?”
In such a situation, you will have to prioritize. If cronyism is more important, then it makes no sense to think about business performance and the activities your company is engaged in calling business in principle. And even more so introduce tools revealing bottlenecks. But if you need results, you have to be tough. The implementation of the Service Desk will just allow making objective and informed decisions regarding service support and after-sales customer service.
Employees of companies do not like changes in the existing way of life. For example, the dispatcher sat and in a magazine in a pen, in the old fashioned way, wrote down all appeals from residents of the house about the inoperability of the elevator, calmly drank tea. And here he is forced to fix something in an incomprehensible system. Naturally, he resists.
The problem is also related to age. The older the team, the more difficult it is in terms of adopting a new, changing work formats.
To a large extent, this is true for medium and small businesses. The leaders of such companies are forced to be "multi-worker". They sell, and provide customer support, and solve bureaucratic problems. And when they have no real interest in the project, it does not end with anything good.
In any project, you need a "driver". He can "come" from senior management - the best option. Otherwise, the middle manager or the person responsible for the process unit within the company will have to “sell” it inside and be responsible for the result.
When companies do not allocate people responsible for the result of introducing the service desk system, nothing happens.
If the project is small and there are few people in the company, a dedicated team is not needed. But there must be a project manager with authority. He is obliged to lead the project to his final point, being responsible for budgets and people, having the opportunity to apply organizational influences or motivational schemes.
By the way, it is necessary not only to single out people with clear powers and responsibilities, but at least partially to simultaneously remove from them activities in other areas.
Often the company has a dedicated project team and even its leader, but there is no time for those who will be affected by the implementation of the service desk system. For example, engineers, executing applications or programmers (if we include them in the support process in the form of a third line). When their time is not allocated and, most importantly, people do not have motivation and understanding why this is necessary, the project rests on internal resistance and “sabotage”.
Such problems are often found in the West: at the start there are no clear requirements for either the service desk system or the project results. This leads, among other things, to an endless process of decision making. Such customers have a desire to automate absolutely everything - to tighten the system to their requirements (more about this above), or the requirements for the system are constantly changing.
Ultimately, projects abandon without starting: they test 20 systems several times and realize that none are suitable. Even worse, if the project was launched, some budgetary and timeframes were determined, and then the requirements “spread”, which leads to a significant disruption to the deadline and seriously “inflated” domestic costs. At a certain stage, it becomes easier to abandon it.
Many companies, having obtained primary results (sometimes very good, especially if nothing had been automated before), stop improving the system and the processes for which it is intended to be automated. They cease to control indicators and, most importantly, to follow up on the results of this control.
Any project resembles a spiral. There is a so-called Deming cycle - Plan -> Do -> Check -> Act. If we talk about Service Desk, then one of the typical tasks of implementing such a system is to reduce the delay in SLA. But after the start of work, many companies, in principle, do not use reports. And some of those who still use it do not plan subsequent changes in their processes, which allow them to achieve somehow better indicators. Without this, final satisfaction cannot be obtained from the project.
Until now, many, especially small companies, have the belief that you can find a system or people who can do everything quickly, efficiently and almost for free. In the presence of this hope, the project ends with nothing - it turns out for a long time, not very expensive, and of poor quality.
The client’s desire to develop their own Service Desk system is also related to this category of problems (why we didn’t need to do this, we wrote in detail in our article). If the company has the opportunity to allocate 2-3 programmers, for example, for six months - a year, then your business is very bad - the business is not focused on what it should do. In those areas that are not key for business, it is better to attract people or use systems “from the outside,” rather than reinventing your bicycle.
Here are some universal recommendations that will allow you to save time at the stage of launching a project and implementing a Service Desk system:
Note published based on material from the Okdesk blog
- 31.1% of all IT projects are stopped and not completed;
- 52.7% of all IT projects were completed with a deadline, a significant increase in the originally planned budget or a radical change in the originally planned goals;
- only 16.2% of all IT projects met expectations.
Total: 83.8% (actually 8 out of 10) failures versus 16.2% success.
Over the past 10 years, these numbers have not changed much - when implementing IT systems, a business is faced with typical problems that can be grouped as follows:
- Organizational difficulties and problems.
- Errors in planning and administering the implementation project (budget, deadlines, and other errors associated with the project approach).
- Problems related to infrastructure and work tools (including practices and systems that should help implementation).
And what leads to failures in the implementation of Service Desk and other systems in Russia?
We are developing a Help Desk system for automating all after-sales service processes in service companies . After talking with more than 5,000 representatives from a wide variety of service sectors (medium and small businesses), we decided to share the reasons for the unsuccessful implementation of Service Desk in Russia / CIS and methods to overcome most difficulties! In fact, the problems turned out to be “universal” for the implementation of any IT systems and IT projects.
We are sure that this will allow you to prepare and avoid at least some of them.
Implementation of Service Desk. Russian realities
Communication with 5000+ service companies operating in the b2b segment in Russia and the CIS countries does not provide accurate statistics on projects, but allows us to identify similar groups of problems (not without local specifics). Next, we consider each item in more detail, focusing on the most popular "representatives" of failures. It is worth noting that the classification of problems used is conditional and selected only for convenience of presentation. Selected groups intersect with each other. For example, the fear of change is inextricably linked to organizational issues, etc.
silver bullet
“Service Desk system itself will solve all problems”
Many truly believe that an automation system will solve all problems. In the current processes of most service companies, chaos reigns, and it seems that the introduction of Service Desk or CRM will allow you to get full control over the situation regarding sales or customer support.
This is a big mistake. There is a well-known saying: “If your company has chaos, then the result of the introduction of an automation system will be automated chaos . ”
No tool can solve pressing internal problems. The effect of introducing Service Desk in companies with low maturity will undoubtedly have a serious effect (for example, it will eliminate the loss of applications, reduce the delay of SLA , etc.). But the successful completion of a project with understandable and measurable results, which can be further developed, is hardly possible in the general case without changing the organizational component.
“Pull” on our requirements
This problem is characteristic of a larger and more bureaucratic business.
As a rule, the processes in such companies have been developing for a long time, some kind of management scheme is taking shape. On top of this system there is “patchwork” automation - Service Desk in some specific areas, different CRMs in different departments, etc. But the business wants to get a single centralized and automated system, linking all processes to each other. The mistake is that at the same time he does not want to adapt to the existing systems and best practices in accordance with which they are developed, trying to "pull" the selected product on his requirements. And to do this is extremely difficult.
To achieve the result, together with the implementation project, you will have to change approaches to work, carry out organizational changes and even get rid of some people or, conversely, introduce new roles in the state. And all this must be done reasonably, understanding what indicators are required to be achieved.
Implement Service Desk. Fear of change
"Our customers are not so used to it."
Service companies really consider something like this:
“It won’t work because our customers aren’t used to it.”
They are not even ready to try to change the existing scheme of work, for example, by proposing new, simpler and more convenient testing mechanisms to several of their clients. From the very beginning, they have the confidence that customers will reject everything new. This means that it makes no sense to launch a project, or, conversely, a launched project is not brought to an end.
“Reorganization required”
This problem is largely associated with the introduction of service desk systems because of the comparative complexity of support processes. Refusal of projects is associated with a fear of reorganization. But often, such changes benefit the business. They can be based on “best practices and libraries” in which they are aggregated - ITIL, or the approach to organizing ITSM service management , but small and medium-sized businesses, of course, refuse to use these “best” practices.
A great example is a service company where 10 or more people are engaged in maintenance, not 2-3. On such a scale, firstly, there is already a large flow of applications, and secondly, there is a clear gradation of people in terms of competencies and payment. The reorganization of the support service involves the allocation of the first, second, third lines, a change in interaction with contractors and much more.
Not taking into account the reorganization, companies are either afraid to launch projects for introducing service desk systems, or they are implementing them, but they do not get the desired result (automate chaos).
“Real time costs will increase”
Companies postpone the implementation of tools when they realize that the real time costs of employees when working with the new service desk system are growing. And this is true!
At first, you really have to spend more time. For example, you will have to register 100% of applications, note the actions performed during their processing, write off labor costs, etc. But inefficiency points cannot be identified without fixing activities and tracking metrics on them. Therefore, before starting the project, you just need to answer the question “What do we want as a result of the implementation of the service desk?”
Familiarity: "Colleagues will be unhappy"
In Russian business, “familiarity” relations are very common. And the more “home” a company is, the more complex it is. This is especially evident in companies on the periphery - in the business for 10 - 20 people who have been working together for a long time.
Cronyism raises difficult moral questions when changes or dismissals of those who work poorly are required. Often in such situations, the project is suspended, and the new tool is not used, because within the company there is discontent or an unanswered question: “How so?”
In such a situation, you will have to prioritize. If cronyism is more important, then it makes no sense to think about business performance and the activities your company is engaged in calling business in principle. And even more so introduce tools revealing bottlenecks. But if you need results, you have to be tough. The implementation of the Service Desk will just allow making objective and informed decisions regarding service support and after-sales customer service.
Organizational Errors and Difficulties in Implementing Service Desk
Internal resistance
Employees of companies do not like changes in the existing way of life. For example, the dispatcher sat and in a magazine in a pen, in the old fashioned way, wrote down all appeals from residents of the house about the inoperability of the elevator, calmly drank tea. And here he is forced to fix something in an incomprehensible system. Naturally, he resists.
The problem is also related to age. The older the team, the more difficult it is in terms of adopting a new, changing work formats.
There is no real interest in management / decision-makers (decision-makers)
To a large extent, this is true for medium and small businesses. The leaders of such companies are forced to be "multi-worker". They sell, and provide customer support, and solve bureaucratic problems. And when they have no real interest in the project, it does not end with anything good.
In any project, you need a "driver". He can "come" from senior management - the best option. Otherwise, the middle manager or the person responsible for the process unit within the company will have to “sell” it inside and be responsible for the result.
Lack or problems with the design approach
No dedicated team and project manager
When companies do not allocate people responsible for the result of introducing the service desk system, nothing happens.
If the project is small and there are few people in the company, a dedicated team is not needed. But there must be a project manager with authority. He is obliged to lead the project to his final point, being responsible for budgets and people, having the opportunity to apply organizational influences or motivational schemes.
By the way, it is necessary not only to single out people with clear powers and responsibilities, but at least partially to simultaneously remove from them activities in other areas.
There is no time available for those affected.
Often the company has a dedicated project team and even its leader, but there is no time for those who will be affected by the implementation of the service desk system. For example, engineers, executing applications or programmers (if we include them in the support process in the form of a third line). When their time is not allocated and, most importantly, people do not have motivation and understanding why this is necessary, the project rests on internal resistance and “sabotage”.
There are no real requirements and use cases (scope of the project)
Such problems are often found in the West: at the start there are no clear requirements for either the service desk system or the project results. This leads, among other things, to an endless process of decision making. Such customers have a desire to automate absolutely everything - to tighten the system to their requirements (more about this above), or the requirements for the system are constantly changing.
Ultimately, projects abandon without starting: they test 20 systems several times and realize that none are suitable. Even worse, if the project was launched, some budgetary and timeframes were determined, and then the requirements “spread”, which leads to a significant disruption to the deadline and seriously “inflated” domestic costs. At a certain stage, it becomes easier to abandon it.
No “impact” (Check - Act)
Many companies, having obtained primary results (sometimes very good, especially if nothing had been automated before), stop improving the system and the processes for which it is intended to be automated. They cease to control indicators and, most importantly, to follow up on the results of this control.
Any project resembles a spiral. There is a so-called Deming cycle - Plan -> Do -> Check -> Act. If we talk about Service Desk, then one of the typical tasks of implementing such a system is to reduce the delay in SLA. But after the start of work, many companies, in principle, do not use reports. And some of those who still use it do not plan subsequent changes in their processes, which allow them to achieve somehow better indicators. Without this, final satisfaction cannot be obtained from the project.
The tale of "quality / fast / free"
Until now, many, especially small companies, have the belief that you can find a system or people who can do everything quickly, efficiently and almost for free. In the presence of this hope, the project ends with nothing - it turns out for a long time, not very expensive, and of poor quality.
The client’s desire to develop their own Service Desk system is also related to this category of problems (why we didn’t need to do this, we wrote in detail in our article). If the company has the opportunity to allocate 2-3 programmers, for example, for six months - a year, then your business is very bad - the business is not focused on what it should do. In those areas that are not key for business, it is better to attract people or use systems “from the outside,” rather than reinventing your bicycle.
Implementation of Service Desk. How to avoid mistakes?
Here are some universal recommendations that will allow you to save time at the stage of launching a project and implementing a Service Desk system:
- The company should have a “driver” for the system implementation project . At the same time , he should have the authority to make decisions , including unpopular ones, and all the project participants and those who will be affected by the system following the launch should be aware of these powers.
- It is necessary to define goals and record requirements (for the system, project, results). Before starting the search for a service desk system, it is necessary to determine the goals, because in their absence this epic may not end in anything.
- Budget / time / team should be highlighted . All of these resources obviously depend on requirements. There should be no illusions: the desire to tighten the system to individual requirements will lead to high costs (a suit to order is always more expensive). The project scope also determines the time that needs to be allocated by drivers and project participants, as well as by all people who will be affected by the use of the system.
- No need to be afraid of changes and the "new . " Changes can be tested on parts of customers or users, for example, on several customers. Yes, you will have to spend more time reorganizing the structure, especially after identifying foci of inefficiency. It is difficult and sometimes painful, especially considering cronyism. But this is necessary if we focus on the effectiveness of the organization and business in itself.
- Persistently overcome resistance - the right to "sell . " Service desk systems are designed not only to control work, but also to build transparent relationships with customers. Employees, even older ones, understand this and other reasonable arguments.
- Focus on your core business . When companies decide to invent their own bike in six months or a year, they’ll develop CRM, Helpdesk, etc. - it almost always ends in failure. But the main thing is an indicator of how ineffective your business is currently.
- Stop believing in fairy tales about “free, cheap, high-quality” . Itself does not “fly”. The main problem of implementing all systems is precisely the organizational difficulties and changes that will have to be carried out, otherwise the system, although it will bring results, but it will not be exactly the one that could be obtained.
Note published based on material from the Okdesk blog
All Articles