Почему методология ITSM не работает?

Одно из преимуществ ITSM или сервисной модели – скорость внедрения от 2 до 10 дней.

Однако, на практике запуск растягивается на недели, а то и месяцы. В ИТ-отделах разводят руками – “мы выполнили свою часть работы, непонятно, почему так”, а бизнес требует результатов. 

На словах причин много – от несовместимости систем или сложности настройки до недостатка знаний и “сырости” бизнес-процессов. Но на деле всё проще.

Как всё работает «в бою»?

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

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

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

Как это выглядит?

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

1. Вертикальная иерархия. Руководители “оторваны” от исполнителей, просто так к ним не попасть, любые распоряжения обязательно беспрекословно выполнять, “руководитель всегда прав”. Если сотрудник нарушит инструкцию, то, скорее всего, назначат штраф, а если нет, но и не выполнит задание, то санкций не последует.
   
   Таким образом, согласование каждого процесса, документа, решения проходит “петлю” – от исполнителя к руководителю среднего звена, от него – к начальнику отдела, от него – к высшему руководству. И в обратную сторону, что, в силу занятости или отсутствия, замедляет процесс внедрения.

2. Правила “прибиты гвоздями”. Регламент – последовательность действий, записанная для специалистов узкого профиля. Чтобы мастер, который изготавливает 1-2 детали, мог собрать автомобиль целиком. Однако, всё меняется – обстоятельства, технологии, люди, и регламенты превращаются из помогающего в ограничивающий фактор. И если мы видим, что правила не соответствуют текущему положению вещей – скорости, качеству, безопасности, удобству – то это повод их изменить.
   
   В то же время, во многих компаниях регламент неприкосновенен. Диалог из практики:
   
   “ – Вы понимаете, что инструкция к этой технологии не подходит, просто не даёт ей развиваться? Дальше мы с ней не поедем.
   – Нет, регламент есть, он со всеми согласован, подписан, его должны исполнять, даже если это ведёт к тому, что ничего не работает”
   
   А для чего он нужен? Чем помогает? Ведь речь не о базовых принципах безопасности, например.
   
   
3. Дискоммуникация между отделами. Проблемы возникают, когда подразделения изолированы друг от друга, и каждое из них сосредотачивается исключительно на своей зоне ответственности. 
   
   Пример:
   Отдел ИБ составил регламент, по которому, в случае подозрения на вирусное заражение, необходимо отключить оборудование. При этом ИТ-специалисты отвечают за непрерывную работу систем.
   
   Возникает конфликт сторон:
   ИБ:
   – Закрыли обязательства – проинструктировать о мерах защиты ИС.
   – Составили регламент.
   – Добились результата в рамках зоны ответственности.
   – Не заинтересованы в поиске компромиссов.
   
   ИТ:
   – Обязаны соблюдать регламент, чтобы не последовало наказание.
   – Понимают, что причиной “зависания” инфраструктуры может быть не только стороннее воздействие.
   – Несут ответственность за функционирование сервисов – в случае простоя компания понесёт финансовые и репутационные потери.
   
   Пример 2:
   ИТ-отдел написал технические требования для закупки оборудования. В госорганизациях сделки сопровождают юристы, и начинается “война” с ИТ – нельзя писать жесткие критерии, которые ограничивают конкуренцию. Иначе может прийти ФАС с проверкой, оштрафовать или вызвать представителей компании в суд.
   
   Тем временем, бизнес-задача фирмы – закупить необходимое оборудование, и всё, в теории, должно быть подчинено этому. Остальное – сопутствующее.

4. Проблемы с оценкой эффективности ИТ-специалистов. Как оценить работу грузчика? Мы знаем, сколько весит мешок цемента, и сколько необходимо принести, есть понятные критерии. Многие руководители подходят к оценке эффективности ИТ-шников аналогичным образом. Если они работают 8 часов в день и решают задачи в установленное время – компетентные.
   
   На практике мы сталкивались с обратным. Традиционные методы оценки эффективности устарели и неприменимы для ИТ. Вот, например, первый специалист – следует регламенту, усердно работает 8-часовой рабочий день, не отвлекается… Однако считает количество событий в многомегабайтных логах с помощью поиска в текстовом редакторе.
   
   А второй работает 3-4 часа, в остальное рабочее время сидит на YouTube и играет. Но он “умеет” в автоматизацию, всё исправно работает и претензий по его эффективности нет.
   
   Оба случая – 2 стороны одной медали. Первый говорит о низкой квалификации сотрудника, а второй – что специалисту скучно на рабочем месте, он не развивается и не проявляет инициативы. Можно было бы, например, повышать квалификацию или обучать других сотрудников, изучать или разрабатывать новую технологию, но “зачем? И так всё работает”.
   
   Второй подход: срез рабочего времени ИТ-специалиста. То есть, в течение рабочего дня он должен писать, какие задачи решает и сколько тратит на каждую. Однако, в таком случае у сотрудника возникает вопрос: “А зачем? Упрекнуть в том, что я не работаю? Или решил задачи за 4 часа, получается, остальные 4 я не работал?”. Как итог – приписки по времени и картина, далёкая от реальности.

Что делать?

Чтобы теория стала чуть ближе к жизни, нужен комплексный подход с исправлением недостатков и лечением “тонких мест”:

Определите границы 

Чем не можем рисковать? А на какие уступки регламентам готовы? Например, наши приоритеты – информационная безопасность и непрерывность работы ИС – то, что может отразиться на сервисах заказчиков. В остальном можно придать регламентам более гибкий характер. Да, мы выведем людей вечером, пойдём напрямую, через 2-3 головы, будем использовать нештатные процедуры, но добьёмся результата.

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

Что считаем результатом? 

Задайте себе вопрос: Какие процессы критичны для достижения целей компании?

К примеру, для нас первичен сервис – это бизнес-задача. Если отдел ИБ запрещает внедрение той или иной технологии, то объясняет, почему, и предлагает альтернативное решение. Это, в том числе, о философии компании – каждый сотрудник тут лично заинтересован в результате.

Развивайте горизонтальное взаимодействие между отделами

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

Горизонтальные связи ускоряют решение проблем. Это снова пример того, как регламенты можно обойти – когда руководитель болеет, вне зоны доступа, в отпуске – мы не дожидаемся возвращения, а действуем.

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

Будьте гибкими

Если есть понимание, что регламент не помогает, а ограничивает – следует его изменить.

Например, когда-то давно была подписочная модель почты и офиса, а теперь своя. Соответственно, регламент нужно скорректировать, чтобы сократить ограничения. То же самое относится к внедрению новых инструментов:

“Видел я такое безобразие – порядка 20 разработчиков пишут на том, что хотят. То есть, нет никакого стека технологий общепринятого. Некоторые из них уже “мёртвые” – он сидит в компании 15-20 лет и пишет на том, что умеет.

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

– Роман Горнев, директор по ИТ-продуктам CORTEL.

Обучайте и развивайте персонал

Это станет стимулом для улучшения квалификации и снижения рисков, связанных с изоляцией в зонах ответственности. Например, мы:

1. приветствуем передачу знаний, выделяем и посвящаем дни изучению технологий; 
2. создали базу знаний, где фиксируем описание технологий, процедур, ошибки и пути их исправления;
3. прикрепляем опытного сотрудника за новым, и они проходят вместе технологию от и до. 

Внедряйте гибкие методологии управления

Об Agile уже всё все знают, но если вы до сих пор не там, то настоятельно рекомендуем.

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

Соберите заинтересованную команду

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

Также поощряем инициативу и стимулируем к поиску узких мест – будь то внедрение новой технологии или изменение схемы архитектуры. 

Перенимайте опыт экспертов

Зачастую на изучение, внедрение, переход на новую технологию своими силами уходят годы. Практика показала, что лучшее решение – обратиться к команде, которая выступит “интерфейсом” между отделами, теорией и практикой, изучением и внедрением. Когда сотрудники видят, что действия приносят результат, то начинают активно интересоваться и вовлекаться в происходящее.

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

А конкретный пример обмена экспертизой с ИТ-отделом любимых клиентов – тут.