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

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

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



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

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

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


Мы разрабатываем Help Desk систему для автоматизации всех процессов постпродажного обслуживания в сервисных компаниях. Поговорив с более чем 5000 представителями из самых различных сервисных отраслей (средний и малый бизнес), мы решили поделиться причинами неудачных внедрений Service Desk в России/СНГ и методами преодоления большинства трудностей! На самом деле проблемы получились «универсальные» для внедрения любых ИТ систем и ИТ проектов.
Уверены, это позволит вам подготовиться и избежать хотя бы часть из них.

Внедрение Service Desk. Российские реалии

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

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

«Service Desk система сама решит все проблемы»

Многие действительно верят, что система автоматизации решит все проблемы. В сложившихся процессах большинства сервисных компаний царит хаос, и кажется, что внедрение Service Desk или CRM позволит получить полный контроль над ситуацией в части продаж или клиентской поддержки.
Это большая ошибка. Есть известная поговорка: «Если у вас в компании хаос, то итогом внедрения системы автоматизации будет автоматизированный хаос».
Никакой инструмент не решит назревшие внутренние проблемы. Эффект от внедрения Service Desk в компаниях с низкой зрелостью, несомненно, даст серьезный эффект (например, позволит исключить потерю заявок, сократить просрочку SLA и т.д.). Но успешное завершение проекта с понятными и измеримыми результатами, которое и дальше можно развивать, в общем случае вряд ли возможно без изменения организационной составляющей.

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

Эта проблема характерна для более крупного и бюрократизированного бизнеса.
Как правило, процессы в таких компаниях развиваются в течение длительного времени, складывается какая-то схема управления. Поверх этой системы существует “лоскутная” автоматизация — Service Desk в каких-то конкретных направлениях, разные CRM в разных департаментах и т.д. Но бизнес хочет получить единую централизованную и автоматизированную систему, увязав все процессы друг с другом. Ошибка в том, что при этом он не хочет подстраиваться под существующие системы и лучшие практики, в соответствии с которыми они разрабатываются, пытаясь «натянуть» выбранный продукт на свои требования. А сделать это крайне сложно.

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

Внедрить Service Desk. Боязнь изменений

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

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

“Это не заработает, потому что наши клиенты так не привыкли”.

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

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

Эта проблема в бОльшей степени связана с внедрением именно service desk систем из-за сравнительной сложности процессов поддержки. Отказ от проектов связан с боязнью реорганизации. Но зачастую такие изменения идут на пользу бизнесу. В их основу могут лечь «передовые практики и библиотеки», в которых они агрегированы — ITIL, или подход к организации сервисного управления ITSM, но малому и среднему бизнесу от использования этих «лучших» практик, конечно, отказаться.
Отличный пример — сервисная компания, где обслуживанием занимается уже не 2-3, а 10 и более человек. При таких масштабах, во-первых, уже имеется большой поток заявок, во-вторых, есть четкая градация людей и по компетенциям, и по оплате. Реорганизация службы поддержки подразумевает выделение первых, вторых, третьих линий, изменение взаимодействия с подрядчиками и много всего прочего.
Не учитывая реорганизацию, компании либо боятся запускать проекты внедрения service desk систем, либо внедряют их, но не получают требуемого результата (автоматизируют хаос).

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

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

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

В российском бизнесе очень распространены «панибратские» отношения. И чем более “домашней” является компания, тем больше это вызывает сложностей. Особенно ярко это проявляется в компаниях на периферии — в бизнесе на 10 — 20 человек, которые давно работают вместе.

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

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

Организационные ошибки и сложности при внедрении Service Desk

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

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

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

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

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

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

Отсутствие или проблемы с проектным подходом

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

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

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

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

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

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

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

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

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

Нет «воздействия» (Check — Act)

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

Любой проект напоминает «спираль». Есть так называемый цикл Деминга — Plan -> Do -> Check -> Act. Если говорить про Service Desk, то одна из типовых задач внедрения такой системы — сокращение просрочки по SLA. Но после начала работы многие компании в принципе не пользуются отчетами. А часть тех, кто все-таки пользуется, не планирует последующие изменения в своих процессах, позволяющие добиться как-то лучших показателей. Без этого итоговой удовлетворенности от проекта не получить.

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

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

К этой категории проблем стоит отнести и желание клиента разработать собственную Service Desk систему (почему этого не стоит делать мы подробно писали в нашей заметке). Если у компании есть возможность выделить 2-3 программистов, например, на полгода — год, значит дела у Вас очень плохи — бизнес не сфокусирован на том, чем он должен заниматься. По тем направлениям, которые не являются для бизнеса ключевыми, лучше привлекать людей или использовать системы «со стороны», а не изобретать свой велосипед.

Внедрение Service Desk. Как избежать ошибок?

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

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

Заметка опубликована на основании материала из блога Okdesk