По данным The Standish Group в США и Европе за 2015 год:
- 31,1% всех ИТ-проектов остановлены и не завершены;
- 52,7% всех ИТ-проектов были завершены с нарушением сроков, значительным увеличением первоначально запланированного бюджета или радикальным изменением первоначально запланированных целей;
- только 16,2% всех ИТ-проектов оправдали ожидания.
За последние 10 лет эти цифры практически не изменились – при внедрении ИТ-систем предприятия сталкиваются с типичными проблемами, которые можно сгруппировать следующим образом:
- Организационные трудности и проблемы.
- Ошибки в планировании и управлении проектом реализации (бюджет, сроки и другие ошибки, связанные с проектным подходом).
- Проблемы, связанные с инфраструктурой и инструментами работы (включая методы и системы, которые должны поддерживать реализацию).
Пообщавшись с более чем 5000 представителями самых разных сфер услуг (среднего и малого бизнеса), мы решили поделиться причинами неудачного внедрения Service Desk в России/СНГ и методами преодоления большинства трудностей! На деле проблемы оказались «универсальными» для реализации любых ИТ-систем и ИТ-проектов.
Мы уверены, что это позволит вам подготовиться и избежать хотя бы некоторых из них.
Внедрение Сервисдеска.
Российские реалии Общение с 5000+ сервисными компаниями, работающими в сегменте b2b в России и странах СНГ, не дает точной статистики по проектам, но позволяет выявить схожие группы проблем (не без местной специфики).
Далее мы рассмотрим каждый пункт подробнее, остановившись на самых популярных «представителях» неудач.
Стоит отметить, что использованная классификация задач произвольна и выбрана лишь для удобства изложения.
Выбранные группы пересекаются между собой.
Например, страх перемен неразрывно связан с организационными проблемами и т. д.
Серебряная пуля
«Система Service Desk сама решит все проблемы»
Многие люди искренне верят, что система автоматизации решит все проблемы.В существующих процессах большинства сервисных компаний царит хаос, и кажется, что внедрение Служба поддержки или CRM позволит вам получить полный контроль над ситуацией в плане продаж или поддержки клиентов.
Это большая ошибка.
Есть известная поговорка: «Если у вас в компании хаос, то результатом внедрения системы автоматизации будет автоматизированный хаос» .
Ни один инструмент не решит насущные внутренние проблемы.
Эффект от внедрения Service Desk в компаниях с низкой зрелостью, несомненно, будет иметь серьезный эффект (например, исключит потерю заявок, сократить задержки по SLA и т. д.).
Но успешное завершение проекта с четкими и измеримыми результатами, которые можно развивать в дальнейшем, в общем случае вряд ли возможно без изменения организационной составляющей.
«Мы растянем» под наши требования
Эта проблема характерна для более крупных и бюрократизированных предприятий.Как правило, процессы в таких компаниях развиваются в течение длительного периода времени и формируется некая схема управления.
Поверх этой системы идет «лоскутная» автоматизация — Service Desk на каких-то конкретных участках, разные CRM в разных отделах и т. д. Но бизнес хочет получить единую централизованную и автоматизированную систему, связывающую все процессы между собой.
Ошибка в том, что он не хочет адаптироваться к существующим системам и лучшим практикам, в соответствии с которыми они разрабатываются, пытаясь «подтянуть» выбранный продукт под свои требования.
А это сделать крайне сложно.
Для достижения результатов вместе с реализацией проекта придется менять подходы к работе, проводить организационные изменения и даже избавляться от некоторых людей или, наоборот, вводить новые роли в штате.
И все это нужно делать разумно, понимая, каких показателей необходимо достичь.
Внедрить службу поддержки.
Страх перемен 
«Наши клиенты к такому не привыкли»
Сервисные компании на самом деле считают примерно так:«Это не сработает, потому что наши клиенты к этому не привыкли».Они даже не готовы попытаться изменить существующую схему работы, например, предложив нескольким своим клиентам новые, более простые и удобные механизмы тестирования.
Они с самого начала уверены, что клиенты откажутся от чего-либо нового.
Это значит, что нет смысла запускать проект или, наоборот, запущенный проект не доведен до конца.
«Нужна реорганизация»
Эта проблема во многом связана с внедрением систем службы поддержки из-за сравнительной сложности процессов поддержки.Отказ от проектов связан со страхом перед реорганизацией.
Но зачастую такие изменения идут бизнесу на пользу.
Они могут быть основаны на «лучших практиках и библиотеках», в которых они агрегированы — ITIL, или подход к организации управления ITSM-сервисами , но малый и средний бизнес, конечно, должен отказаться от использования этих «лучших» практик.
Отличным примером является сервисная компания, где обслуживанием занимаются уже не 2-3, а 10 и более человек.
При таком масштабе, во-первых, уже есть большой поток заявок, во-вторых, существует четкая градация людей как по компетенциям, так и по оплате труда.
Реорганизация службы поддержки предполагает выделение первой, второй, третьей линии, изменение взаимодействия с контрагентами и многое другое.
Без учета реорганизации компании либо боятся запускать проекты по внедрению систем службы поддержки, либо внедряют их, но не получают необходимого результата (автоматизируют хаос).
«Затраты в реальном времени увеличатся»
Компании откладывают внедрение инструментов, когда понимают, что реальные затраты времени сотрудников, работающих с новой системой службы поддержки, растут. И это чистая правда! Поначалу вам действительно придется потратить больше времени.Например, вам придется регистрировать 100% заявок, отмечать выполненные действия при их обработке, списывать трудозатраты и т. д. Но точки неэффективности невозможно выявить без фиксации активности и отслеживания метрик по ним.
Поэтому перед запуском проекта нужно просто ответить на вопрос «Чего мы хотим в результате внедрения сервисдескаЭ»
Знакомство: «Коллеги будут недовольны»
«Дружеские» отношения очень распространены в российском бизнесе.И чем более «отечественной» является компания, тем больше сложностей это вызывает. Особенно это проявляется в компаниях на периферии — в предприятиях с 10 — 20 людьми, которые долгое время работают вместе.
Знакомство поднимает сложные моральные проблемы, когда требуются изменения или увольняются те, кто плохо работает. Часто в таких ситуациях проект приостанавливается и новый инструмент не используется, потому что есть недовольство внутри компании или вопрос без ответа: «Как это возможноЭ» В такой ситуации вам придется расставить приоритеты.
Если семейные отношения важнее, то нет смысла думать об эффективности бизнеса и называть деятельность, которой занимается ваша компания, бизнесом в принципе.
И даже более того, внедрите инструменты, выявляющие узкие места.
Но если вы хотите результатов, вам придется быть жестким.
Внедрение Service Desk позволит вам принимать объективные и обоснованные решения в вопросах сервисной поддержки и послепродажного обслуживания клиентов.
Организационные ошибки и сложности при внедрении Service Desk
Внутреннее сопротивление
Сотрудники компании не любят изменения существующего образа жизни.Например, диспетчер сидел и в журнале ручкой по старинке записывал все обращения жильцов дома о неработоспособности лифта и спокойно пил чай.
И здесь он вынужден что-то записывать в непонятной системе.
Естественно, он сопротивляется.
Проблема также связана с возрастом.
Чем старше команда, тем сложнее ей принимать новое и менять форматы работы.
Нет реальной заинтересованности руководства/лиц, принимающих решения (лиц, принимающих решения)
Это более актуально для среднего и малого бизнеса.Менеджеры таких компаний вынуждены быть «многостаночниками».
Они продают, обеспечивают поддержку клиентов и решают бюрократические проблемы.
А когда у них нет реального интереса к проекту, это плохо кончается.
Любому проекту нужен «драйвер».
Оно может «прийти» от высшего руководства – лучший вариант. В противном случае менеджеру среднего звена или лицу, ответственному за блок процессов внутри компании, придется «продавать» его внутри компании и нести ответственность за результат.
Отсутствие или проблемы с проектным подходом
Нет выделенной команды и руководителя проекта.
Когда компании не выделяют людей, ответственных за результаты внедрения системы службы поддержки, ничего не происходит. Если проект небольшой и в компании мало людей, выделенная команда не нужна.
Но должен быть руководитель проекта с полномочиями.
Он отвечает за доведение проекта до финальной точки, несет ответственность за бюджеты и людей, имеет возможность применять организационные воздействия или мотивационные схемы.
Кстати, необходимо не просто выделить людей с четкими полномочиями и обязанностями, но хотя бы частично одновременно снять их деятельность и в других сферах.
Для тех, кого это затронет, не выделено время.
Часто в компании есть выделенная проектная группа и даже ее руководитель, но у тех, кого затронет внедрение системы службы поддержки, нет времени.
Например, инженеры, выполняющие запросы, или программисты (если мы включим их в процесс поддержки в качестве третьей линии).
Когда их время не распределяется и, самое главное, у людей нет мотивации и понимания, зачем это нужно, проект наталкивается на внутреннее сопротивление и «саботаж».
Нет реальных требований и вариантов использования (объем проекта)
Подобные проблемы часто встречаются на Западе: на старте нет четких требований ни к системе службы поддержки, ни к результатам проекта.Это приводит, помимо прочего, к бесконечному процессу выбора решений.
У таких заказчиков возникает желание автоматизировать абсолютно все — адаптировать систему под свои требования (об этом выше), либо требования к системе постоянно меняются.
В конечном итоге проекты бросают еще до того, как они начались: несколько раз тестируют 20 систем и понимают, что ни одна из них не подходит. Еще хуже, если проект запущен, определены бюджет и сроки, а затем требования «разлетаются», что приводит к значительному сдвигу сроков и серьезному «завышению» внутренних затрат. На определенном этапе от него становится легче отказаться.
Нет «воздействия» (Проверить – Действуть)
Многие компании, получив первоначальные результаты (иногда очень хорошие, особенно если раньше ничего не автоматизировалось), перестают совершенствовать систему и процессы, которые она призвана автоматизировать.Они перестают следить за показателями и, самое главное, предпринимать последующие действия по результатам этого контроля.
Любой проект напоминает «спираль».
Существует так называемый цикл Деминга – Планируй -> Делай -> Проверяй -> Действуй.
Если говорить о Service Desk, то одна из типичных задач внедрения такой системы — сокращение задержки SLA. Но после начала работы многие компании вообще не используют отчеты.
А некоторые из тех, кто его использует, не планируют последующих изменений в своих процессах, которые каким-то образом позволили бы им добиться лучших результатов.
Без этого невозможно получить окончательное удовлетворение от проекта.
Сказка про «качественно/быстро/бесплатно»
До сих пор во многих, особенно небольших компаниях, бытует убеждение, что можно найти систему или людей, которые сделают все быстро, качественно и практически бесплатно.При наличии этой надежды проект заканчивается ничем — он долговечен, не очень дорог и некачественен.
К этой категории проблем относится и желание клиента разработать собственную систему Service Desk (о том, почему этого не следует делать, мы подробно писали в нашей статье).
Если у компании есть возможность выделить 2-3 программистов, например, на полгода-год, то дела у вас очень плохи — бизнес не ориентирован на то, чем он должен заниматься.
В тех сферах, которые не являются ключевыми для бизнеса, лучше привлекать людей или использовать системы извне, чем изобретать велосипед.
Внедрение Сервисдеска.
Как избежать ошибок? 
Вот несколько универсальных рекомендаций, которые позволят вам сэкономить время на этапе запуска проекта и внедрения системы Service Desk:
- В компании должен быть «драйвер» проекта внедрения системы .
В которой он должен иметь полномочия принимать решения , в том числе непопулярные, и эти полномочия должны быть известны всем участникам проекта и тем, на кого система повлияет после запуска.
- Необходимо определить цели и записать требования (к системе, проекту, результатам).
Прежде чем приступить к поиску системы службы поддержки, необходимо определить свои цели, ведь при их отсутствии эта эпопея может ничем не закончиться.
- Бюджет/время/команда должны быть распределены.
.
Все эти ресурсы, очевидно, зависят от требований.
Иллюзий быть не должно: желание адаптировать систему под индивидуальные требования приведет к большим затратам (костюм, сшитый на заказ, всегда дороже).
Объем проекта также определяет время, которое необходимо уделить водителям и участникам проекта, а также всем людям, на которых будет влиять использование системы.
- Не нужно бояться перемен и «нового».
.
Изменения можно протестировать на подмножестве клиентов или пользователей, например, на нескольких клиентах.
Да, вам придется потратить больше времени и реорганизовать структуру, особенно после выявления областей неэффективности.
Это сложно и порой болезненно, особенно учитывая привычность.
Но это необходимо, если вы ставите во главу угла эффективность организации и самого бизнеса.
- Настойчиво преодолевайте сопротивление – правильно «продавайте» .
Системы службы поддержки призваны не только контролировать работу, но и выстраивать прозрачные взаимоотношения с клиентами.
Сотрудники, даже старшего возраста, понимают этот и другие разумные доводы.
- Сосредоточьтесь на своем основном бизнесе .
Когда компании решают за полгода-год изобрести велосипед — разработать CRM, Helpdesk и т. д. — это практически всегда заканчивается провалом.
Но главное – это показатель того, насколько неэффективно в данный момент работает ваш бизнес.
- Хватит верить в сказки про «бесплатно, дешево, качественно» .
Самостоятельно оно не «полетает».
Основная проблема при внедрении всех систем заключается именно в организационных трудностях и изменениях, которые придется внести, иначе система хоть и принесет результаты, но не совсем те, которые можно было бы получить.
-
Изменения Облачных Тарифов
19 Oct, 24 -
Манифест Младшего Премьер-Министра
19 Oct, 24 -
Интел! Амд! Плитка?
19 Oct, 24
