13 причин провалов внедрения help desk системы и как с ними бороться

По данным The Standish Group в США и Европе за 2015 год:

• 31,1% от всех ИТ-проектов остановлены и не завершены;
• 52,7% от всех ИТ-проектов завершены со срывом сроков, значительным увеличением первоначально запланированного бюджета или кардинальным изменением изначально запланированных целей;
• только 16,2% от всех ИТ-проектов оправдали ожидания.

Итого: 83,8% (фактически 8 из 10) неудач против 16,2% успеха.

И последние лет 10 эти цифры практически не меняются — при внедрении проектов бизнес сталкивается с типовыми проблемами, которые можно сгруппировать следующим образом:

• Организационные сложности и проблемы.
• Ошибки планирования и администрирования проекта внедрения (бюджет, сроки и прочие ошибки, связанные с проектным подходом).
• Проблемы, связанные с инфраструктурой и инструментами работы (в т.ч. с практиками и системами, которые должны помогать внедрению).

А что у нас приводит к неудачам внедрения help desk и других систем?

Мы поговорили с более чем 5000 сервисных компаний и готовы представить результаты. А заодно и методы преодоления большинства трудностей!

Данная статья является сокращенным вариантом вебинара. Полную запись которого вы можете увидеть в самом конце страницы.

Основные причины неудачного внедрения help desk

Общение более чем с 5000 сервисными компаниями, работающими в сегменте B2B в России и странах СНГ, не дает точную статистику по проектам, но позволяет выявить похожие группы проблем (не без локальной специфики). Далее каждый пункт мы рассмотрим подробнее, остановившись на самых популярных «представителях» неудач.

Стоит отметить, что использованная классификация проблем условна и выбрана лишь для удобства изложения. Выделенные группы друг с другом пересекаются.

К примеру, боязнь изменений неразрывно связана с организационными моментами.

Серебрянная пуля

Система сама решит все проблемы

Многие действительно верят, что система автоматизации решит все проблемы.

В сложившихся процессах большинства сервисных компаний царит хаос, и кажется, что внедрение Service Desk или CRM позволит получить полный контроль над ситуацией в части продаж или клиентской поддержки.

Это большая ошибка.

Есть известная поговорка: «Если у вас в компании хаос, то итогом внедрения системы автоматизации будет автоматизированный хаос». Никакой инструмент не решит назревшие внутренние проблемы.

Эффект от внедрения help desk в компаниях с низкой зрелостью, несомненно, даст серьезный эффект (например, позволит исключить потерю заявок, сократить просрочку SLA и т.д.). Но успешное завершение проекта с понятными и измеримыми результатами, которое и дальше можно развивать, в общем случае вряд ли возможно без изменения организационной составляющей.

«Натянем» на наши требования

Эта проблема характерна для более крупного и бюрократизированного бизнеса.

Как правило, процессы в таких компаниях развиваются в течение длительного времени, складывается какая-то схема управления.

Поверх этой системы существует «лоскутная» автоматизация — help desk в каких-то конкретных направлениях, разные CRM в разных депаратментах и т.д. Но бизнес хочет получить единую централизованную и автоматизированную систему, увязав все процессы друг с другом.

Ошибка в том, что при этом он не хочет подстраиваться под существующие системы и лучшие практики, в соответствии с которыми они разрабатываются, пытаясь «натянуть» выбранный продукт на свои требования. А сделать это крайне сложно.

Для достижения результата вместе с проектом внедрения придется менять подходы к работе, проводить организационные изменения и даже избавляться от каких-то людей или, наоборот, вводить новые роли в штате.

И все это нужно делать обоснованно, понимая, каких показателей требуется достичь.

Боязнь изменений

«Наши клиенты так не привыкли»

Сервисные компании действительно считают примерно следующим образом: «Это не заработает, потому что наши клиенты так не привыкли».

Они не готовы даже попробовать изменить существующую схему работы, например, предложив новые более простые и удобные механизмы на тестирование нескольким своим клиентам.

С самого начала у них есть уверенность, что клиенты отторгнут всё новое. А значит, и нет смысла запускать проект или, наоборот, запущенный проект не доводят до конца.

Потребуется реорганизация

Эта проблема в бОльшей степени связана с внедрением именно help desk систем из-за сравнительной сложности процессов поддержки.

Отказ от проектов связан с боязнью реорганизации. Но зачастую такие изменения идут на пользу бизнесу. В их основу могут лечь передовые практики и библиотеки, в которых они агрегированы — ITIL, или подход к организации сервисного управления ITSM.

Отличный пример — сервисная компания, где обслуживанием занимается уже не 2-3, а 10 и более человек.

При таких масштабах, во-первых, уже имеется большой поток заявок, во-вторых, четкая градация людей и по компетенциям, и по оплате. Реорганизация службы поддержки подразумевает выделение первых, вторых, третьих линий, изменение взаимодействия с подрядчиками и много всего прочего.

Не учитывая реорганизацию, компании либо боятся запускать проекты внедрения help desk систем, либо внедряют их, но не получают требуемого результата (автоматизируют хаос).

«Реальные временные затраты вырастут»

Компании откладывают внедрение инструментов, когда понимают, что реальные временные затраты сотрудников при работе с новой help desk системой вырастают. И это чистая правда!

Времени, на первых порах, действительно придется тратить больше.

Например, придется регистрировать 100% заявок, отмечать выполненные действия при их обработке, списывать трудозатраты и т.п. Но точки неэффективности не выявить без фиксации активностей и отслеживания метрик по ним. А потому перед стартом проекта нужно просто ответить себе на вопрос «Чего мы хотим по итогам внедрения help desk?»

Панибратство или «Коллеги будут недовольны!»

В российском бизнесе очень распространены «панибратские» отношения. И чем более «домашней» является компания, тем больше это вызывает сложностей.

Особенно ярко это проявляется в компаниях на периферии — в бизнесе на 10 — 20 человек, которые давно работают вместе.

Панибратство порождает сложные моральные вопросы, когда требуются изменения или увольнения тех, кто работает плохо. Часто в таких ситуациях проект приостанавливается, а новый инструмент не используется, потому что внутри компании возникает недовольство или вопрос без ответа: «Как же так?»

В подобной ситуации придется расставить приоритеты.

Если важнее панибратские отношения, то нет смысла думать об эффективности бизнеса и деятельность, которой занимается Ваша компания называть бизнесом в принципе. А тем более внедрять инструменты, обличающие «узкие» места. Но если нужны результаты, придется проявлять жесткость.

Внедрение help desk как раз позволит принимать объективные и обоснованные решения в вопросах сервисной поддержки и постпродажного обслуживания клиентов.

Организационные ошибки и сложности

Внутреннее сопротивление

Сотрудники компаний не любят изменений сложившегося уклада.

Например, сидел диспетчер и в журнале ручкой по-старинке записывал все обращения от жителей дома о неработоспособности лифта, спокойно пил чай. А тут его заставляют что-то фиксировать в непонятной системе.

Естественно, он сопротивляется.

Проблема в том числе бывает связана с возрастом.

Чем старше коллектив, тем он сложнее в части принятия нового, изменения форматов работы.

Нет реальной заинтересованности руководства / ЛПРов (лиц, принимающих решения)

В бОльшей степени это актуально для среднего и малого бизнеса.

Руководители таких компаний вынуждены быть «многостаночниками». Они и продают, и осуществляют поддержку клиентов, и решают бюрократические проблемы. И когда у них нет реальной заинтересованности в проекте, ничем хорошим он не заканчивается.

В любом проекте нужен «драйвер».

Он может «прийти» от высшего руководства — оптимальный вариант. В ином случае руководителю среднего звена или человеку, отвечающему за блок процессов внутри компании, придется его внутри «продать» и отвечать за результат.

Отсутствие проектного подхода

Нет выделенной команды и руководителя проекта

Когда компании не выделяют людей, отвечающих за результат внедрения сервис деск системы, ничего не получается.

Если проект небольшой и людей в компании мало, выделенная команда не нужна.

Но должен быть руководитель проекта, наделенный полномочиями.

Он обязан вести проект к своей финальной точке, отвечая за бюджеты и людей, имея возможность применить организационные воздействия или мотивационные схемы.

Кстати, нужно не просто выделить людей с понятными полномочиями и обязанностями, а хотя бы частично одновременно снять с них активности по другим направлениям.

Нет выделенного времени у тех, на кого это повлияет

Зачастую в компании есть выделенная проектная команда и даже ее руководитель, но нет времени у тех, на кого повлияет внедрение сервис деск системы. Например, инженеры, исполняющие заявки или программисты (если мы включаем их в процесс поддержки в виде третьей линии). Когда их время не выделяется и, самое главное, у людей нет мотивации и понимания, зачем это нужно, проект упирается во внутреннее сопротивление и «саботаж».

Нет реальных требований и сценариев использования

Такие проблемы часто встречаются и на западе: на старте нет четких требований ни к системе help desk, ни к результатам проекта. Это приводит, в том числе, к бесконечному процессу выбора решений. У таких заказчиков есть желание автоматизировать абсолютно всё — натянуть систему на свои требования (об этом — выше), либо предъявляемые к системе требования постоянно изменяются.

В конечном счете проекты забрасывают, не начав: тестируют 20 систем по несколько раз и осознают, что ни одна не подходит.

Еще хуже, если проект был запущен, определены какие-то бюджетные и временные рамки, а потом требования «расползаются», что приводит к значительному срыву срок и серьезно «раздутых» внутренних затрат.

На определенном этапе становится проще его забросить.

Нет «воздействия»

Многие компании, получив первичные результаты (иногда очень неплохие, особенно если до этого ничего автоматизировано не было), перестают улучшать систему и процессы, для автоматизации которых она предназначена.

Они перестают контролировать показатели и, самое главное, по итогам этого контроля предпринимать последующие воздействия.

Любой проект напоминает «спираль».

Есть так называемый цикл Деминга — Plan -> Do -> Check -> Act.

Если говорить про help desk, то одна из типовых задач внедрения такой системы — сокращение просрочки по SLA. Но после начала работы многие компании в принципе не пользуются отчетами. А часть тех, кто все-таки пользуется, не планирует последующие изменения в своих процессах, позволяющие добиться как-то лучших показателей.

Без этого итоговой удовлетворенности от проекта не получить.

Сказка про «качественно/быстро/бесплатно»

До сих пор у многих, особенно небольших компаний, есть убеждение, что можно найти систему или людей, которые все сделают быстро, качественно и практически бесплатно. В присутствии этой надежды проект заканчивается ничем — получается долго, не очень дорого, и некачественно.

К этой категории проблем стоит отнести и желание клиента разработать собственную help desk систему (почему этого не стоит делать мы подробно писали в нашей заметке).

Если у компании есть возможность выделить 2-3 программистов, например, на полгода — год, значит дела у вас очень плохи — бизнес не сфокусирован на том, чем он должен заниматься.

По тем направлениям, которые не являются для бизнеса ключевыми, лучше привлекать людей или использовать системы «со стороны», а не изобретать свой велосипед.

Как избежать ошибок при внедрении

Вот несколько универсальны рекомендаций, которые позволят вам сэкономить время на этапе запуска проекта и внедрения help desk системы:

• В компании должен быть «драйвер» проекта внедрения системы. При этом у него должны быть полномочия для принятия решений, в том числе, непопулярных, и об этих полномочиях должно быть известно всем участникам проекта и тем, на кого повлияет система по итогам запуска.
• Необходимо определить цели и зафиксировать требования (к системе, проекту, результатам). Прежде чем начинать поиск help desk системы, необходимо определить цели, потому что в их отсутствии эта эпопея может ничем не закончиться.
• Следует выделить бюджет / время / команду. Все эти ресурсы, очевидно, зависят от требований. Не должно быть иллюзий: желание натянуть систему на индивидуальные требования приведет к большим затратам (костюм на заказ — всегда дороже). Scope проекта также определяет время, которое нужно выделять со стороны драйверов и участников проекта, а также у всех людей, на кого повлияет использование системы.
• Не нужно бояться изменений и «нового». Изменения можно тестировать на части клиентов или пользователей, например, на нескольких заказчиках. Да, придется тратить больше времени, реорганизовывать структуру, особенно после выявления очагов неэффективности. Это сложно и иногда больно, тем более с учетом панибратства. Но это нужно, если ставить во главу угла эффективность организации и бизнес сам по себе.
• Настойчиво преодолевать сопротивление — правильно «продавать». Сервис деск системы предназначены не только для контроля работы, но и для выстраивания прозрачных отношений с клиентами. Сотрудники, даже возрастные, понимают эту и другую разумную аргументацию.
• Сфокусируйтесь на основном бизнесе. Когда компании решают за полгода-год изобрести свой собственный велосипед — разработать CRM, Helpdesk и т.п. — это почти всегда заканчивается провалом. Но главное — это показатель того, насколько ваш бизнес на текущий момент работает неэффективно.
• Перестать верить в сказки про «бесплатное, дешевое, качественное». Само не «полетит». Основная проблема внедрения всех систем — это как раз организационные сложности и изменения, которые придется проводить, иначе система хоть и принесет результат, но он будет не совсем тот, который можно было бы получить.

Полная запись вебинара о проблемах внедрения help desk и путях их преодоления

Полезные материалы

Дважды в месяц о развитии и автоматизации сервиса, техподдержки и выездного обслуживания.

 

Подписаться

Нажимая на кнопку «Подписаться», вы даете согласие на обработку своих персональных данных.

Кирилл Федулов

Сооснователь и директор по развитию Okdesk. Около 10 лет проработал в компании Naumen, где занимался внедрением ITSM и service desk систем в крупнейших российских компаниях: Полюс, Тинькофф, ЛСР и др. Эксперт в области организации и автоматизации процессов техподдержки, сервиса и выездного обслуживания