ГлавнаяСтатьиСемь шагов к провалу ITSM-проекта

Семь шагов к провалу ITSM-проекта

По мнению аналитиков Pink Elephant от 70% до 80% проектов по внедрению ITSM провальны, по крайней мере, тех, которые выполняются в организации впервые.

Несмотря на то, что кое-какие слова на тему того, как "внедрять ITSM" написаны и в ITIL®, к сожалению, пока прогресса в вышеупомянутом показателе не видно. В данной статье мы попробуем сформулировать основные причины, которые, по мнению автора, могут привести к провалу ITSM-проекта. Данный список не претендует на полноту, в конце концов, существует огромное множество сделать что-то неправильно и только небольшое количество путей сделать это правильно.

Построение Единой Теории Всего и Модели В Натуральную Величину

Часто бывает так, что увлёкшись дизайном решения, проектная команда пытается учесть все случаи жизни и предусмотреть для них соответствующую процедуру, автоматизацию или, хотя бы, инструкцию для исполнителя. Назовём такой подход "Построение Единой Теории Всего". При таком подходе не универсальное решение воспринимается как неполноценное, а значит совершенно непригодное! На любой вариант развития событий должна быть составлена инструкция и предусмотрена функция в автоматизированной системе, поддерживающей процесс.
Вторым проявлением чрезмерного проектирования является увлечение детализацией. Этот подход мы назовём "Построение Модели В Натуральную Величину". Здесь, например, объект учёта может получить 20 статусов своего жизненного цикла, а исполнитель будет обязан регистрировать любое действие в системе автоматизации.
Построение Единых Теорий Всего и Моделей В Натуральную Величину ведёт к нежизнеспособным решениям, в которых регламенты имеют объём не менее полусотни страниц, а интерфейс систем автоматизации похож на пульт управления космическим шаттлом. Хорошим лекарством от этого может быть применение широко известного принципа 80/20: 80% результата достигается 20% усилий. Постоянная проверка решений на соответствие изначально заявляемым целям является хорошим инструментом в отсечении избыточности. Расширяя границы или уточняя детали неплохо бы постоянно спрашивать себя: кому впоследствии нужна будет информация или результат деятельности? Много ли мы потеряем если не учтём того и не добавим этого?

Увлечение документированием и автоматизацией

Как мы помним, если мы хотим улучшить нашу систему управления ИТ, хорошие практики советуют нам воздействовать на четыре её компонента : людей, процессы, технологии, партнёров. Какой компонент из перечисленных сложнее всего поддаётся изменениям? Регламент процесса можно переписать, ПО - перенастроить, с партнёрами - пересмотреть условия договора, если это необходимо. С людьми всё сложнее, по крайней мере, путь к цели не так очевиден. К сожалению, в проектных планах часто можно увидеть, что значительная часть времени и ресурсов уделяется именно работе с "техникой": процедурами и автоматизацией. В лучшем случае, работа с людьми ограничивается тренингами - для проектной команды в начале проекта и для участников процесса в конце, с целью научить работать в рамках разработанного решения.
Безусловно, понятная и эффективная процедура важна. Разумеется, если инструмент автоматизации имеет простой интерфейс и поддерживает выполнение процедур удобными функциями - это значительно увеличивает шансы на успех. Однако инструменты и процедуры сами по себе не принесут вам желаемого результата, его могут достичь только люди.

По исследованию Project Management Institute (PMI), проведённому в 2011 году, только 64% проектов можно считать успешными. Что же отличает компании, проекты которых успешны, от тех, в которых проекты терпят неудачу? По результатам опроса самым массовым и растущим трендом является использование практик управления организационными изменениями (используют 73% опрошенных), фокусирующихся, прежде всего, на людях.

Отсутствие доказательств прогресса

Решая главную задачу по построению системы управления ИТ, часто забывают о реальных улучшениях, которые позволяют показать понятный и быстрый результат в глазах заказчика ИТ-услуг.
Само по себе внедрение процессов управления кроме, пожалуй, процесса управления инцидентами не несёт прямых, заметных, и достижимых в краткосрочной перспективе улучшений. Однако это не значит, что результаты ITSM-проектов должны появляться только где-то в отдалённой перспективе. Что же можно предпринять, чтобы показать результат и снизить риски внедрения? Предложим здесь следующие варианты:

  • До начала проекта уделить внимание разработке и получению метрик, связанных с решаемой проблемой. Со временем это поможет в демонстрации прогресса.
  • Начинать деятельность по внедряемому процессу уже в рамках проекта, даже когда ещё не все элементы системы управления готовы или внедрена система автоматизации. Этот подход позволяет опробовать спроектированную схему и показать также прогресс, что значительно способствует закреплению успеха и получению реальных результатов.
  • В рамках проекта оптимизировать некоторые аспекты предоставляемых ИТ-услуг. Например, внедряя Каталог услуг, можно навести порядок в организации работ по выдаче рабочих мест, упростив процедуру и сократив срок их выдачи новому сотруднику.

Стремление угодить всем

Что уж там скрывать, ITSM-проекты внедряются не для того, чтобы упростить жизнь рядовому работнику. Едва ли можно рассчитывать, что любой среднестатистический сотрудник нижнего звена проникнется целями проекта и по его завершению, во имя упорядоченности и контролируемости, стиснув зубы и выучив регламент, приступит к работе на всю катушку. Не все смогут смириться с изменениями и принять их. Чаще всего от значительной части вовлечённых можно увидеть противодействие различного оттенка: от простого безразличия до прямого саботажа. Кому-то не понравится достигаемая прозрачность работ и их учёт. Кто-то просто может скептически относиться "ко-всем-этим-модным-штучкам-которые-как-известно-в-России-не работают". В конце-концов, сопротивление изменениям - нормальная реакция человеческой психологии, поэтому важно быть к этому готовым.
Как правило, явно вам никто не выскажет, что боится изменений или, что его не устраивает достигаемый уровень прозрачности процесса. Вам могут указать, например, на то, что:

  • Интерфейс внедряемой системы неудобен;
  • Документация не учитывает каких-то крайне важных вариантов процесса;
  • Документация слишком детализирована;
  • Документация слишком общая;
  • Требуемый компонент системы управления ИТ совершенно невозможно внедрить без внедрения компонентов A, B, C и D, в придачу.

Ну и так далее.

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

Неготовность защищать свои решения

Выстраивание системы управления ИТ, достижение необходимых уровней упорядоченности, управляемости и гибкости сильно отличается от того, что обычно имеется ввиду под "ITSM-проектом". Часто по достижению формальной даты завершения проекта возникает желание ослабить натиск и сбавить обороты, однако поддаваться такому соблазну опасно. Кроме этого, неготовность к сопротивлению среды может привести к тому, что воли руководства будет недостаточно, чтобы его преодолеть. Окончание проекта - чаще всего середина, если не начало пути по изменению культуры организации так, чтобы внедрённые изменения стали для неё естественными. Что же можно сделать, чтобы обеспечить такое планомерное изменение культуры? На эту тему существует множество литературы и рекомендаций, однако здесь отметим следующие основные деятельности, которые могут помочь в преодолении сопротивления:

  • Заранее готовиться к работе с возражениями и понимать, как на них реагировать.
  • Продумывать чётко сформулированные преимущества решения для различных групп заинтересованных лиц, например: высшего руководства, линейного руководства, рядовых сотрудников, клиентов.
  • Готовиться к тому, что изменения не приживаются быстро, особенно в больших организациях и потребуется много усилий, прежде чем желаемый эффект действительно будет достигнут.

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

Неверное использование услуг консультантов

Именитый и высокооплачиваемый тренер не может выиграть чемпионат вместо своей команды. Также и при внедрении ITSM-проекта, как бы дорого не стоили услуги консультантов и какими бы они компетентными не были, они не добьются улучшений за вас. К сожалению, часто бывает так, что как только консультанты выходят за порог компании, всё возвращается на круги своя, решение не приживается или демонстрирует редкий пульс на грани нитевидного. Признаками грядущих проблем могут быть следующие факты:

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

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

Не вовлечение в проект заказчика, на которого влияет результат

Это может показаться странным, но часто в проекты, результаты которых будут каким-то образом влиять на заказчика ИТ-услуг, этот самый заказчик не привлекается. В таких случаях в ходе проекта ИТ-специалисты самостоятельно формулируют мнение заказчика, исходя из того, как они его понимают. В лучшем случае будет иметь место некоторое расхождение в оценках, что потребует коррекции решения при его развёртывании или сразу после. В худшем, решают не те проблемы или имеет место прямое противоречие интересов. Например, когда целью внедряемого процесса изменениями ИТ-услуг фактически оказывается не оперативная и надёжная реализация изменений, а сокращение их количества.
Привлечение в проект всех заинтересованных сторон - один из ключевых факторов успеха для ITSM-проекта. Ещё лучше это сделать заранее, ещё на этапе его оценки и утверждения. Это позволит убедиться в главном: те ли мы задачи решаем, которые следовало бы, и верным ли способом.