Почему методология ITSM не работает?
Одно из преимуществ ITSM или сервисной модели – скорость внедрения от 2 до 10 дней.
Однако, на практике запуск растягивается на недели, а то и месяцы. В ИТ-отделах разводят руками – “мы выполнили свою часть работы, непонятно, почему так”, а бизнес требует результатов.
На словах причин много – от несовместимости систем или сложности настройки до недостатка знаний и “сырости” бизнес-процессов. Но на деле всё проще.
Как всё работает «в бою»?
Эксплуатация ИТ-инфраструктуры – это про достижение результатов за рамками технической работы. Процессы и регламенты должны быть не целью, а инструментом.
Бизнесу важна не только стабильность работы, но и гибкость, а та самая «эффективная эксплуатация» — это не только техника, но и поиск лучших практик для поддержки инициатив. Так процессы не препятствуют развитию.
На практике, если регламент препятствует достижению бизнес-целей, последние часто отступают перед формальными правилами, потому что «так принято». И это проблема. Такой дисбаланс приводит к избыточной бюрократии и замедлению принятия решений.
Как это выглядит?
Разберём на живых примерах. Все совпадения с реальностью, как говорится, случайны =)
- Вертикальная иерархия. Руководители “оторваны” от исполнителей, просто так к ним не попасть, любые распоряжения обязательно беспрекословно выполнять, “руководитель всегда прав”. Если сотрудник нарушит инструкцию, то, скорее всего, назначат штраф, а если нет, но и не выполнит задание, то санкций не последует.Таким образом, согласование каждого процесса, документа, решения проходит “петлю” – от исполнителя к руководителю среднего звена, от него – к начальнику отдела, от него – к высшему руководству. И в обратную сторону, что, в силу занятости или отсутствия, замедляет процесс внедрения.
- Правила “прибиты гвоздями”. Регламент – последовательность действий, записанная для специалистов узкого профиля. Чтобы мастер, который изготавливает 1-2 детали, мог собрать автомобиль целиком. Однако, всё меняется – обстоятельства, технологии, люди, и регламенты превращаются из помогающего в ограничивающий фактор. И если мы видим, что правила не соответствуют текущему положению вещей – скорости, качеству, безопасности, удобству – то это повод их изменить.В то же время, во многих компаниях регламент неприкосновенен.
– Вы понимаете, что инструкция к этой технологии не подходит, просто не даёт ей развиваться? Дальше мы с ней не поедем.
– Нет, регламент есть, он со всеми согласован, подписан, его должны исполнять, даже если это ведёт к тому, что ничего не работает.
А для чего он нужен? Чем помогает? Ведь речь не о базовых принципах безопасности, например.
- Дискоммуникация между отделами. Проблемы возникают, когда подразделения изолированы друг от друга, и каждое из них сосредотачивается исключительно на своей зоне ответственности.
Пример:
Отдел ИБ составил регламент, по которому, в случае подозрения на вирусное заражение, необходимо отключить оборудование. При этом ИТ-специалисты отвечают за непрерывную работу систем.Возникает конфликт сторон:
ИБ:
– Закрыли обязательства – проинструктировать о мерах защиты ИС.
– Составили регламент.
– Добились результата в рамках зоны ответственности.
– Не заинтересованы в поиске компромиссов.
ИТ:
– Обязаны соблюдать регламент, чтобы не последовало наказание.
– Понимают, что причиной “зависания” инфраструктуры может быть не только стороннее воздействие.
– Несут ответственность за функционирование сервисов – в случае простоя компания понесёт финансовые и репутационные потери.
Пример 2:
ИТ-отдел написал технические требования для закупки оборудования. В госорганизациях сделки сопровождают юристы, и начинается “война” с ИТ – нельзя писать жесткие критерии, которые ограничивают конкуренцию. Иначе может прийти ФАС с проверкой, оштрафовать или вызвать представителей компании в суд. Тем временем, бизнес-задача фирмы – закупить необходимое оборудование, и всё, в теории, должно быть подчинено этому. Остальное – сопутствующее.
- Проблемы с оценкой эффективности ИТ-специалистов. Как оценить работу грузчика? Мы знаем, сколько весит мешок цемента, и сколько необходимо принести, есть понятные критерии. Многие руководители подходят к оценке эффективности ИТ-шников аналогичным образом. Если они работают 8 часов в день и решают задачи в установленное время – компетентные.
На практике мы сталкивались с обратным. Традиционные методы оценки эффективности устарели и неприменимы для ИТ. Вот, например, первый специалист – следует регламенту, усердно работает 8-часовой рабочий день, не отвлекается… Однако считает количество событий в многомегабайтных логах с помощью поиска в текстовом редакторе.
А второй работает 3-4 часа, в остальное рабочее время сидит на YouTube и играет. Но он “умеет” в автоматизацию, всё исправно работает и претензий по его эффективности нет.
Оба случая – 2 стороны одной медали. Первый говорит о низкой квалификации сотрудника, а второй – что специалисту скучно на рабочем месте, он не развивается и не проявляет инициативы. Можно было бы, например, повышать квалификацию или обучать других сотрудников, изучать или разрабатывать новую технологию, но “зачем? И так всё работает”.
Второй подход: срез рабочего времени ИТ-специалиста. То есть, в течение рабочего дня он должен писать, какие задачи решает и сколько тратит на каждую. Однако, в таком случае у сотрудника возникает вопрос: “А зачем? Упрекнуть в том, что я не работаю? Или решил задачи за 4 часа, получается, остальные 4 я не работал?”. Как итог – приписки по времени и картина, далёкая от реальности.
Что делать?
Чтобы теория стала чуть ближе к жизни, нужен комплексный подход с исправлением недостатков и лечением “тонких мест”:
Определите границы
Чем не можем рисковать? А на какие уступки регламентам готовы? Например, наши приоритеты – информационная безопасность и непрерывность работы ИС – то, что может отразиться на сервисах заказчиков. В остальном можно придать регламентам более гибкий характер. Да, мы выведем людей вечером, пойдём напрямую, через 2-3 головы, будем использовать нештатные процедуры, но добьёмся результата.
И наоборот – если всё сделано правильно, по регламенту, но цели не достигнуты – отдел сработал неэффективно. Неверные инструкции, отпуск сотрудников, оплошности руководителя – не имеют значения. Результата нет – с тем же успехом можно было и не делать.
Что считаем результатом?
Задайте себе вопрос: Какие процессы критичны для достижения целей компании? Как это делать — писали тут. Развивайте именно их и привязывайте к ним результаты.
К примеру, для нас первичен сервис – это бизнес-задача. Если отдел ИБ запрещает внедрение той или иной технологии, то объясняет, почему, и предлагает альтернативное решение. Это, в том числе, о философии компании – каждый сотрудник тут лично заинтересован в результате.
Развивайте горизонтальное взаимодействие между отделами
Мы на своем опыте увидели, что в ИТ строгая вертикальная иерархия не работает. Если пришла задача, а айтишник понимает, что нужно сделать иначе, то, как профессионал, он прямо скажет об этом – и очень-очень важно его услышать.
Горизонтальные связи ускоряют решение проблем. Это снова пример того, как регламенты можно обойти – когда руководитель болеет, вне зоны доступа, в отпуске – мы не дожидаемся возвращения, а действуем.
Например, при решении задач или разборе инцидента, где участвуют несколько подразделений, мы собираем их представителей. Они не скажут: “Это не мои проблемы, разбираться не буду”, а придут и будут, причем, не только в своей зоне ответственности.
Будьте гибкими
Если есть понимание, что регламент не помогает, а ограничивает – следует его изменить.
Например, когда-то давно была подписочная модель почты и офиса, а теперь своя. Соответственно, регламент нужно скорректировать, чтобы сократить ограничения. То же самое относится к внедрению новых инструментов:
Видел я такое безобразие – порядка 20 разработчиков пишут на том, что хотят. То есть, нет никакого стека технологий общепринятого. Некоторые из них уже “мёртвые” – он сидит в компании 15-20 лет и пишет на том, что умеет.
Поэтому, если мы считаем технологии перспективными, но они не решают какой-то задачи, мы вводим новые. И наоборот – если новая технология не решает вопрос, редко, но мы можем вернуться к старому
Обучайте и развивайте персонал
Это станет стимулом для улучшения квалификации и снижения рисков, связанных с изоляцией в зонах ответственности. Например, мы:
- приветствуем передачу знаний, выделяем и посвящаем дни изучению технологий;
- создали базу знаний, где фиксируем описание технологий, процедур, ошибки и пути их исправления;
- прикрепляем опытного сотрудника за новым, и они проходят вместе технологию от и до.
Внедряйте гибкие методологии управления
Об Agile уже всё все знают, но если вы до сих пор не там, то настоятельно рекомендуем.
Например, для оценки работы ИТ-шников мы придерживаемся подхода с использованием решённых тикетов, формирования статистики по выполненным задачам, а не строгого контроля за временем работы. Это позволяет оценивать не только количество, но и качество.
Соберите заинтересованную команду
Важно работать на результат. Такие сотрудники легко идут на компромиссы и быстро обучаются. О том, как собрать эффективную команду мы уже писали тут, и сегодня не будем повторяться.
Также поощряем инициативу и стимулируем к поиску узких мест – будь то внедрение новой технологии или изменение схемы архитектуры.
Перенимайте опыт экспертов
Зачастую на изучение, внедрение, переход на новую технологию своими силами уходят годы.
Практика показала, что лучшее решение – обратиться к команде, которая выступит “интерфейсом” между отделами, теорией и практикой, изучением и внедрением. Когда сотрудники видят, что действия приносят результат, то начинают активно интересоваться и вовлекаться в происходящее.
Например, мы сотрудничаем с вами не только как поставщики услуг, но и в рамках обмена опытом и достижения бизнес-целей с помощью ИТ. О том, как сопоставить ИТ и бизнес в рамках единой стратегии – рассказывали тут.
А конкретный пример обмена экспертизой с ИТ-отделом - тут.