Основным мотивом, побудившим меня поразмышлять на данную тему, явилось выполнение проектов в необычном для меня формате – а именно сопровождение ITSM-проектов, которые заказчик выполнял самостоятельно.
На сегодняшний день существует множество источников информации об организации процессов управления ИТ-услугами – стандарт ISO/IEC 20000 и библиотека ITIL®, авторизованные и авторские учебные курсы, большое количество публикаций и статей, открытые и закрытые методики от производителей программного обеспечения для автоматизации процессов и так далее. Доступность информации помогает профессионально расти специалистам в области ITSM, что, в свою очередь, неизбежно ведет к соблазну попробовать внедрить процессы в своей организации собственными силами. Насколько это реально, и с какими сложностями может столкнуться организация, выбравшая такой путь?
Безусловно, внедрение своими силами имеет хорошие шансы на успех. Однако практика показывает, что в этом случае существует большое количество нюансов, которые необходимо учитывать.
Мой собственный опыт во многом совпадает с представленной статистикой. Передавая сотрудникам заказчика самостоятельное управление проектом, полную ответственность за проектирование, автоматизацию и запуск процессов, я видел, насколько трудно исполнителю справиться с этой работой. Анализируя этот опыт, я пришёл к выводу, что при самостоятельном внедрении процессов необходимо обращать пристальное внимание на три ключевых аспекта: компетенцию сотрудников, организацию проектных работ и преодоление сопротивления персонала.
Компетенция
КОМПЕТЕНЦИЯ (от лат. competo – добиваюсь; соответствую, подхожу) – способность применять знания, умения, успешно действовать на основе практического опыта при решении задач (Википедия). И если со знаниями у сотрудников обычно все в порядке (не проходит даром обучение и изучение профессиональной литературы), то вот с опытом дело обстоит сложнее. Да и где его взять, если первый раз выполняется подобный проект?
Возьмем, к примеру, процесс управления инцидентами. Он наиболее востребован, и по нему можно найти большое количество информации. Обычно его и внедряют своими силами.
Во многих случаях берут готовые схемы «из коробки» и пытаются адаптировать к своей организации. И хорошо, если такую схему не нужно менять. Но «коробочные» процессы не всегда подходят, а значит состав и наполнение процедур приходится корректировать. И в этот момент сказывается недостаток опыта – нет понимания, какие риски несет то или иное изменение. Например, в одной организации решили, что в процессе необходимо наличие процедуры по созданию и обработке типовых решений, однако приобретенный программный продукт не позволил автоматизировать эту процедуру. В другой – на этапе закрытия обращений честно связывались с пользователями по телефону, чтобы получить подтверждение о выполнении, что вызвало сильное недовольство VIP-пользователей. В третьей – напротив – на этапе закрытия обращений решили вообще отказаться от подтверждения выполнения, что в конечном итоге привело к частым случаям повторной регистрации обращений.
Еще хуже ситуация, когда проектирование процедур процесса происходит «с нуля». И если «коробочные» процессы хоть каким-то образом заставляют проектировщиков придерживаться канвы, то в случае проектирования с чистого листа дана полная свобода творчеству. Описания таких процессов трудно читать, и основная проблема – нарушение логической целостности. Это ошибки связей входов-выходов процедур (есть примеры, где входов и выходов нет вообще; или циклические связи без направлений, по которым можно «ходить вечно»), непонятные условия перехода инцидентов из статуса в статус, отсутствие фиксации ответственности (кто и на каком именно этапе отвечает за инцидент) и так далее.
Конечно, хорошее знание теории может помочь минимизировать некоторые риски, тем более что наиболее типичные описаны в литературе (например, в библиотеке ITIL в описании каждого процесса есть стандартный раздел «Трудности, ключевые факторы успеха и риски»). Однако недостаток опыта все равно накладывает свой негативный отпечаток.
Кроме компетенции сотрудников очень сильное влияние на успех проекта оказывает и то, каким образом организовано выполнение работ.
Организация проектных работ
Как правило, ИТ-менеджеры хорошо знакомы с управлением проектами. Но здесь хотелось бы обсудить не контроль исполнения и управление проектами в целом, а опуститься на уровень ниже – обсудить состав и выполнение некоторых работ, специфичных для проведения организационных изменений.
Проект по внедрению процессов управления ИТ-услугами можно разбить на несколько этапов (названия, состав и количество могут различаться в каждом конкретном случае, в зависимости от используемого подхода):
- инициация проекта;
- проектирование;
- автоматизация;
- запуск.
Многих сложностей в проекте можно избежать (или снизить их влияние) если задуматься о них заранее. Начать выявлять проектные риски и планировать контрмеры лучше на этапе инициации проекта. Действуя таким образом, вы получите возможность своевременно включить в проект дополнительные мероприятия, предусмотреть вовлечение руководства, лучше оценить сроки выполнения отдельных задач и проекта в целом. Выявленные риски необходимо зафиксировать и с каждым из них связать ответственного, задача которого – вовремя отреагировать на реализацию риска, оповестить менеджера проекта и других руководителей, инициировать спланированные контрмеры.
Обычно наибольшие трудности вызывает организация работ на этапах проектирования и запуска процесса.
Проектирование
Проектирование традиционно разбивают на два вида: концептуальное и детальное.
Основным результатом концептуального проектирования является регламент процесса; детального – техническое задание на автоматизацию процесса.
Определение требований к системе автоматизации не является чем-то экстраординарным для сотрудников службы ИТ. Так или иначе, они постоянно сталкиваются с задачей создания технического задания на автоматизацию «чего-либо», поэтому особых проблем детальное проектирование не вызывает.
А вот с концептуальным проектированием процессов большинство сталкивается впервые.
Для успешного проектирования процедур процесса необходимо, чтобы члены проектной группы общались на одном языке. Но при самостоятельном внедрении про это забывают. Мне известны случаи, когда члены проектной группы путались в терминологии, не понимали, что считать инцидентом, а что – запросом на обслуживание. И это происходило уже при финальном обсуждении процедур процесса.
Определение целей процесса – еще одна важная и трудная задача при самостоятельном внедрении. Попробуйте провести эксперимент: каждому члену проектной группы выдайте домашнее задание по формулированию цели процесса. Скорее всего, вы удивитесь – у каждого будет свое видение того, для чего нужен процесс. До того момента, когда цели и задачи процесса будут сформулированы и приняты каждым членом рабочей группы – может пройти немало времени в обсуждениях и спорах. Но это очень важно – процесс должен решать конкретные проблемы в конкретной организации.
«Инициатива наказуема». Не правда ли, знакомое выражение? К сожалению, зачастую проектирование и формирование необходимой документации перекладывается на инициатора проекта. И этот один человек уходит на некоторое время и возвращается с готовым регламентом процесса. В этом случае обычно возникают следующие ситуации: регламент процесса начинает бесчисленное количество раз согласовываться с заинтересованными лицами, и так и не принимается; либо согласовывается всеми формально – после чего документ отправляется «в стол».
Постоянные проблемы возникают и с фиксацией того, о чем члены проектной группы договорились на рабочих встречах. Для этого используют стандартный механизм – ведут протоколы. К сожалению, очень часто в протоколы вносят только высокоуровневые тезисы, не опускаясь до деталей – а они очень важны. Поэтому когда по прошествии некоторого времени нужно написать регламент процесса, оказывается, что в протоколах не хватает важной информации. Приходится собираться снова и снова, обсуждать те же самые процедуры.
Для того, чтобы понять, насколько процесс соответствует своим целям, необходимо создать систему измерений. К формулированию метрик зачастую подходят формально – проще говоря, попросту списывают из доступных источников. Иногда складывается парадоксальная ситуация: однажды я спросил проектировщиков, что они хотят измерить с помощью одной из метрик (случайно указал на одну из списка), каковы для нее будут целевые значения? Никто из членов рабочей группы на вопрос ответить не смог. В другом проекте мне пришлось выдержать давление со стороны сотрудников заказчика, которые просили дать им готовый набор метрик. Через некоторое время они смогли разработать их самостоятельно, и метрик получилось немного – всего пять. Однако теперь заказчик мог точно сказать, для чего они нужны, какие целевые значения для них будут установлены и как это связано с целью процесса.
Запуск процесса
На этапе запуска процесса сотрудники начинают работать в соответствии с новыми процедурами и использовать в своей деятельности новые инструменты.
Важным фактором успеха при запуске процесса является понимание сотрудниками для чего нужен этот процесс, каким образом работать в рамках процедур, как пользоваться новыми инструментами (системой автоматизации). Для этого необходимо провести обучение, о чем при самостоятельном внедрении иногда забывают.
Обучение обычно разбивают на две части: теоретическая часть о процессе (и будет очень хорошо, если теория привязана к конкретной ситуации – это более понятно сотрудникам), и практическая часть, посвященная работе в рамках процесса.
Существенное влияние на успех проекта также оказывает и «легитимность» процесса. Запуск всегда сопровождается появлением определенных документов (приказов и распоряжений), в которых фиксируется область ответственности сотрудников в рамках процесса и «место» процесса в организации. Один из рисков при самостоятельном внедрении – ошибка в выборе уровня управления, на котором должны утверждаться документы.
Но наибольшую проблему на этапе запуска и дальнейшей работы процесса вызывает сопротивление сотрудников организационным изменениям.
Сопротивление организационным изменениям
По оценкам аналитиков Pink Elephant, 52% ITSM-проектов оканчиваются неудачей из-за сильного сопротивления персонала организационным изменениям, которые являются неотъемлемой частью внедрения процессов управления ИТ-услугами. Всегда найдутся сотрудники, которые будут негативно относиться к новым правилам в работе и оценке деятельности.
Часто неудачу провоцируют сами инициаторы внедрения – используется принцип «внедрили и забыли». Отсутствие контроля процесса со стороны владельца и менеджера процесса формирует риск постепенного частичного или полного отказа от новых правил работы и исходных целей проекта. Сотрудники видят, что это очередной пример инициатив руководства, которые можно игнорировать, поскольку они отменяются быстрее, чем доходят до реализации.
Резюме
Я искренне убежден, что процессы управления ИТ-услугами можно внедрять своими силами. Более того, это позволяет организации сокращать прямые и видимые расходы на внедрение. Внедряя процессы управления ИТ-услугами можно добиться существенной экономии – расходы на внешний консалтинг могут составлять более 50% бюджета проекта. В этом случае придется потратиться только на средство автоматизации и на вовлечение собственных сотрудников в проект. Это также и хорошая возможность повысить компетенцию персонала. Внедрение силами собственных специалистов позволяет дать им толчок в профессиональном развитии, вывести их на новый уровень.
Однако, несмотря на привлекательность внедрения своими силами, необходимо оценивать и минимизировать риски таких внедрений.
Автор: Михаил Тобурдановский.
