Звоните: +7 (495) 517-57-25

itsm-by-ones-own-forces

Основным мотивом, побудившим меня поразмышлять на данную тему, явилось выполнение проектов в необычном для меня формате — а именно сопровождение ITSM-проектов, которые заказчик выполнял самостоятельно.

На сегодняшний день существует множество источников информации об организации процессов управления ИТ-услугами — стандарт ISO/IEC 20000 и библиотека ITIL®, авторизованные и авторские учебные курсы, большое количество публикаций и статей, открытые и закрытые методики от производителей программного обеспечения для автоматизации процессов и так далее. Доступность информации помогает профессионально расти специалистам в области ITSM, что, в свою очередь, неизбежно ведет к соблазну попробовать внедрить процессы в своей организации собственными силами. Насколько это реально, и с какими сложностями может столкнуться организация, выбравшая такой путь?

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

По оценкам аналитиков Pink Elephant, более двух миллионов людей во всем мире имеют сертификацию в области управления ИТ-услугами (ITSM), однако 70-80% ITSM-проектов, которые выполняются впервые, заканчиваются неудачей.

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

Компетенция

КОМПЕТЕНЦИЯ (от лат. competo — добиваюсь; соответствую, подхожу) — способность применять знания, умения, успешно действовать на основе практического опыта при решении задач (Википедия). И если со знаниями у сотрудников обычно все в порядке (не проходит даром обучение и изучение профессиональной литературы), то вот с опытом дело обстоит сложнее. Да и где его взять, если первый раз выполняется подобный проект?

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

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

Еще хуже ситуация, когда проектирование процедур процесса происходит «с нуля». И если «коробочные» процессы хоть каким-то образом заставляют проектировщиков придерживаться канвы, то в случае проектирования с чистого листа дана полная свобода творчеству. Описания таких процессов трудно читать, и основная проблема — нарушение логической целостности. Это ошибки связей входов-выходов процедур (есть примеры, где входов и выходов нет вообще; или циклические связи без направлений, по которым можно «ходить вечно»), непонятные условия перехода инцидентов из статуса в статус, отсутствие фиксации ответственности (кто и на каком именно этапе отвечает за инцидент) и так далее.

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

В одном из проектов при обсуждении процедур процесса управления инцидентами положительную роль сыграло наличие определенного опыта у одного из сотрудников — этот человек раньше работал начальником службы поддержки в крупной компании. И он мог оперативно реагировать на внесение предложений по процессу, объясняя коллегам, какие негативные (или позитивные) последствия может принести то или иное решение.
Совет 1. Попытайтесь компенсировать отсутствие опыта у сотрудников — обмен информацией с коллегами из других организаций, которые прошли путь самостоятельного внедрения процессов; можно также найти много полезной информации на специализированных формах; наконец, можно отправить ключевых специалистов на учебные курсы — помимо получения знаний, как правило, происходит неформальный обмен опытом…

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

Организация проектных работ

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

Проект по внедрению процессов управления ИТ-услугами можно разбить на несколько этапов (названия, состав и количество могут различаться в каждом конкретном случае, в зависимости от используемого подхода):

  • инициация проекта;
  • проектирование;
  • автоматизация;
  • запуск.

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

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

Обычно наибольшие трудности вызывает организация работ на этапах проектирования и запуска процесса.

Проектирование

Проектирование традиционно разбивают на два вида: концептуальное и детальное.

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

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

А вот с концептуальным проектированием процессов большинство сталкивается впервые.

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

Совет 3. Чтобы избежать подобной ситуации необходимо «синхронизировать» людей, отвечающих за проектирование — обсуждением используемой терминологии, обучением по предметной области (в объеме основ ITIL или специализированного тренинга по конкретному процессу). Будет замечательно, если удастся составить и опубликовать небольшой глоссарий — в этом случае любой сотрудник может быстро получить трактовку используемых терминов и сокращений.

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

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

«Инициатива наказуема». Не правда ли, знакомое выражение? К сожалению, зачастую проектирование и формирование необходимой документации перекладывается на инициатора проекта. И этот один человек уходит на некоторое время и возвращается с готовым регламентом процесса. В этом случае обычно возникают следующие ситуации: регламент процесса начинает бесчисленное количество раз согласовываться с заинтересованными лицами, и так и не принимается; либо согласовывается всеми формально — после чего документ отправляется «в стол».

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

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

Вот типичный пример (выдержка из протокола): «разработана процедура оценки и совершенствования процесса». Все. Ни в самом протоколе, ни в приложении к нему нет подробного описания того, каким образом будут работать люди в рамках этой процедуры. Процедуру пришлось обсуждать еще раз, чтобы внести ее в регламент процесса.
Совет 6. Тщательно фиксируйте в протоколах детали процедур процесса.

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

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

Запуск процесса

На этапе запуска процесса сотрудники начинают работать в соответствии с новыми процедурами и использовать в своей деятельности новые инструменты.

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

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

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

Совет 8. Не забывайте провести обучение сотрудников, задействованных в процессе.

Существенное влияние на успех проекта также оказывает и «легитимность» процесса. Запуск всегда сопровождается появлением определенных документов (приказов и распоряжений), в которых фиксируется область ответственности сотрудников в рамках процесса и «место» процесса в организации. Один из рисков при самостоятельном внедрении — ошибка в выборе уровня управления, на котором должны утверждаться документы.

В одном из самостоятельных внедрений процесса управления инцидентами приказ о запуске процесса был выпущен на уровне руководства ИТ. Службой ИТ была проведена PR-акция для пользователей из бизнес-подразделений, объяснены преимущества обращения в централизованную службу поддержки. Однако пользователи игнорировали новые правила, потому что эти правила не были зафиксированы на уровне всей организации, а служба ИТ в первые дни запуска процесса не смогла обеспечить качественное обслуживание — пользователи были разочарованы и предпочитали использовать альтернативные способы разрешения своих проблем, не обращаясь в службу поддержки. В результате пользователей удалось «вернуть», выпустив приказ на уровне всей организации, подписанный генеральным директором.
Совет 9. Если в рамках процесса предполагается взаимодействие с сотрудниками из других бизнес-подразделений организации, необходимо добиться того, чтобы правила взаимодействия были доведены до сотрудников официальным путем (приказ по организации). Однако и про проведение PR-акций забывать нельзя — комбинация «кнута и пряника» работает более эффективно.

Но наибольшую проблему на этапе запуска и дальнейшей работы процесса вызывает сопротивление сотрудников организационным изменениям.

Сопротивление организационным изменениям

По оценкам аналитиков Pink Elephant, 52% ITSM-проектов оканчиваются неудачей из-за сильного сопротивления персонала организационным изменениям, которые являются неотъемлемой частью внедрения процессов управления ИТ-услугами. Всегда найдутся сотрудники, которые будут негативно относиться к новым правилам в работе и оценке деятельности.

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

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

Резюме

Я искренне убежден, что процессы управления ИТ-услугами можно внедрять своими силами. Более того, это позволяет организации сокращать прямые и видимые расходы на внедрение. Внедряя процессы управления ИТ-услугами можно добиться существенной экономии — расходы на внешний консалтинг могут составлять более 50% бюджета проекта. В этом случае придется потратиться только на средство автоматизации и на вовлечение собственных сотрудников в проект. Это также и хорошая возможность повысить компетенцию персонала. Внедрение силами собственных специалистов позволяет дать им толчок в профессиональном развитии, вывести их на новый уровень.

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

Автор: Михаил Тобурдановский.

Михаил Тобурдановский