ITSM: обзор методологии
Этот текст — даже не обзор, а только попытка немного осветить само понятие ITSM, ITIL и иже с ними.
20.03.2015 | Автор: Владимир Завертайлов, Сибирикс (Генеральный директор) 
Есть ли объективная потребность внедрять канонический ITSM в нашей отрасли? Вряд ли, 99% всех IT-компаний, которые занимаются вебом, — малый бизнес, которому такие навороты даром не нужны. Может быть, ITSM уже присутствует в более-менее стройных процессах той или иной студии? Отчасти так.
Методология с относительно недавних пор докатилась и до России, появились ITSM-консультанты и вендоры. Удариться в культизм можно запросто — чем популярнее подход, тем больше людей хочет его внедрить. Такая вот природа человека.
IT Service Management (ITSM) — один из подходов к управлению услугами ИТ-отдела. Сердце ITSM — это свод знаний ITIL (IT Infrastructure Library). В библиотеке тщательно и системно расписаны все процессы, которые повышают качество ИТ-услуг в сторону их ориентированности на бизнес. Библиотека ITIL появилась по заказу правительства Великобритании еще в начале 90-х, с тех пор вышло три редакции ITIL, а общее количество книг достигло 30.
Как вы понимаете, просто так взять и внедрить ITIL-принципы у себя в компании будет сложновато. Как и изложить в рамках одной маленькой статьи, конечно.
Ключевые слова и фразы для ITSM ИТ-услуга — сама по себе ценность, ориентированность на бизнес, KPI, системность, ITIL, CobiT, Service Desk.
Суть методологии ITSM Если классический подход направлен на совершенствование самого программного продукта, то при ITSM акценты смещаются на удовлетворение потребностей бизнеса. Через совершенствование программного продукта, да. Но так как между бизнесом (с его философией, ценностями и целями) и ИТ — пропасть, нужен определенный буфер. Методология ITSM помогает управлять ИТ-отделом эффективно, по KPI, понятным как бизнесу, так и айтишникам.
Но самое главное — ITSM направлен на трансформацию сознания людей, культуры ИТ-компании или отдела. По большому счету, любая методология без трансформации культуры превращается в карго-культ, которому так легко и приятно следовать, но который не прибавляет ценности ни на грамм.
Следует различать вот что. Есть ИТ-отделы внутри компаний. А есть ИТ-компании. Первые, как правило, плевали на дружелюбность и ориентированность на клиента (в данном случае на руководство). Вторые — изо всех сил стараются быть похожими на «зрелый» бизнес, делать продукты «для людей», думать о продажах, клиентском сервисе и т.д.
Поэтому ИТ-компании (особенно только зародившиеся) так падки на новые методологии, у них на это минимум две причины.
Они хотят соответствовать Большому Бизнесу. Это похоже на то, как сын подражает отцу. Отрасль ИТ все еще молода, к ней относятся с недоверием и высокомерием. Для большинства крупных бизнесов, «ИТ-компания» — это сборище «компьютерщиков», бородатых и вечно с бодуна. Чтобы показать серьезность своего бизнеса, ИТ искусственно увеличивает собственную важность: рейтинги, сертификаты, методологии, ассоциации. Они хотят получить конкурентное преимущество. Чем рядовая вебдев-студия может похвастать, зацепить заказчика? Она работает по Scrum? Половина уже работает по Scrum (ну, или так заявляет). Она делает интерфейсы «для людей»? А кто не делает. Схватив тренд погорячее, каждый пытается воздеть его на длинное древко и махать над головой. Роб Ингланд, автор книг по ITSM и ITIL, спрашивает: «вы видели инженеров, ежегодно предлагающих новые крутые способы строительства, скажем, мостов (как правило — более дорогие и менее надежные, чем те, что применялись на протяжении многих лет)?».
В ИТ же один способ круче другого. Но ITSM сама по себе методология сложная, громоздкая, с множеством метрик. Подходит ли она для того, чтобы просто увеличить собственную важность в глазах клиентов?
Помимо всего, ITSM — процесс цикличный, это тот же Continual Process Improvement, как и в DevOps. Например, так выглядит жизненный цикл ITSM:
Представьте, сколько ресурсов нужно будет бросить веб-студии со штатом, скажем, в 15 человек, на жизнеобеспечение ITSM. Рационально? Вряд ли.
Есть такой принцип «если работает — не чините!». Отлично подходит для ИТ-компаний. Нужно понимать, что это не новая ИТ-библия и не свод жестких указаний. Здесь все нужно адаптировать. Если вы студия, вы живы и хорошо себя чувствуете — вероятнее всего, вы правильно поставили и процесс продаж, и производство, и клиентский сервис. Что-то улучшить, подкрутить — пожалуйста. Внедрять новое с нуля только потому, что это передовой опыт и самая распространенная методология управления ИТ-процессами — глупо.
Другое дело — ИТ-отделы в крупных компаниях с прогрессивным руководством. Почему у них есть острая потребность в ITSM?
Почему ITSM нужен ИТ-отделам Бизнесу больше не нужна кучка бородачей, неуправляемых и непредсказуемых. Бизнес хочет рулить всем, все измерять и корректировать траекторию развития.
«ИТ-служба сегодня должна управляться как полноценное бизнес-подразделение, а порядок и дисциплина в ней напоминали те, что приняты у инженеров. Процессы и роли структурированы вокруг предоставляемых услуг, а не обеспечивающих их предоставление технологий. Например: управление проблемами, изменениями, доступностью, уровнем услуг, а не серверов, сетей, приложений и т.п».
Роб Ингланд
Итак, у нас есть большая компания (не ИТ). У компании есть ИТ-отдел. Бизнес видит ИТ как придаток, слабо понимая, какую ценность он несет, признавая ИТ только как инструмент, который время от времени устраняет технические аварии, позволяя другим сотрудникам компании приносить реальную ценность.
Руководство, бухгалтерия, продажи, проектный отдел и другие — с одной стороны. ИТ — с другой. Они говорят на разных языках, по-разному выглядят, воспринимают друг друга соответствующим образом.
Так бизнес видит ИТ:
Так ИТ видит бизнес:
У бизнеса есть два справедливых желания:
Ставить задачи ИТ-отделу так, чтобы все выполнялось строго в соответствии с задачами бизнеса. Контролировать выполнение, отслеживать эффективность работы ИТ-отдела. Первая задача худо-бедно выполняется, если в штате есть менеджер с техническими знаниями, который способен переводить задачи бизнеса на язык айтишников. Либо, что на грани фантастики, задача решается наличием айтишников, способных правильно интерпретировать задачи бизнеса, «думать, как пользователь» и т.д.
Вторая задача решается в основном никак. То есть эффективность работы ИТ-отдела можно как-то попытаться измерить, взглянув на эффективность работы отдела, который айтишники обслуживают. Поздно починили 1С, не отправили отчет в налоговую, получили штраф — кому выписать люлей? (правильный ответ: ответственному менеджеру).
То есть ИТ-услуги, как уже говорилось, воспринимаются исключительно как дополнение к «основным» услугам. В то же время, ИТ-отдел избавлен от большей части ответственности, а если вдруг что-то идет не так по вине ИТ, то он всегда может спрятаться за терминологией, «загрузить» начальство по самые уши, спихнуть вину на некорректную постановку задачи и так далее.
Поэтому по предписаниям ITSM процесс работы ИТ-отдела меняется в соответствии с такими принципами:
Первый приоритет — восстановление услуги. Приоритет задач определяется с учётом услуг, с которыми они связаны. Новые идеи оцениваются на основе того, улучшают ли они услуги. Изменения управляются так, чтобы сделать жизнь легче, а не так, чтобы «всё записывать». Пользователи рассматриваются как коллеги, нуждающиеся в помощи, а не как приставучие неудачники; их запросы — как требующие ответа, а не как заведомо глупые; Основное направление коммуникаций с ними — проактивная помощь, а не старательное избегание.
Сказать «процесс меняется» легко. На деле ни одна не айтишная компания не способна внедрить ITSM самостоятельно. Поэтому приглашаются или независимые сертифицированные эксперты, или вендоры. В России других вариантов нет, да и даже названные влетят компании в копеечку. Это все при условии, что руководство действительно понимает ценность ИТ-отдела, стремится этим управлять и готово платить.
Конкретика? Практически методология не предлагает ничего сверхнового — стоит почитать любую литературу по ITSM. Цикл Деминга? Мы и раньше про него знали (тот же канбан отчасти на нем базируется). KPI? Если вы думаете, что в ITIL будет четкое указание: для управления инцидентами применяйте такие-то метрики — то забудьте сейчас же. Как уже говорилось, любая методология адаптивна. Поэтому:
Брать KPI из чужого опыта, литературы или форумов — неправильно. Причина: чужой опыт никогда в точности не ляжет на ваш. Не KPI должны определять задачи бизнеса, а наоборот. Вывод KPI — процесс творческий. Здесь, думаю, всем понятно. Измерять максимум KPI, сколько вообще возможно (информация-то лишней не будет!). Тоже заблуждение. KPI должны выводиться на основании конкретно ваших целей, а вы при этому должны отдавать себе отчет: для чего вам этот KPI и к чему вы хотите в итоге прийти на определенном уровне управления ИТ. Кстати, сами уровни достаточно неплохо расписаны вот здесь.
ITSM и ITIL — это отнюдь не сборник конкретных рекомендаций, как действовать в какой ситуации. Это еще одна философия.
Аналоги ITIL Разбираться в библиотеке ITIL сходу, не нюхав методологий ранее, — самоубийство. Поэтому эксперты рекомендуют начинать с чего полегче:
Во-первых, присмотритесь к облегченной версии ITIL, официальное название — ITIL Small-Scale Implementation5. Это официальное издание ITIL, в котором авторы попытались смасштабировать ITIL для нужд малого бизнеса. FITS7 — пожалуй, самый недооцененный из подходов этого класса. Разработанный для британских учебных заведений, он оказался реально работающим подходом к управлению ИТ-услугами, отлично подходящим ИТ-командам из нескольких человек, начиная с одного. ISM1 — «коробочное решение для управления ИТ-услугами». Звучит очень многообещающе, но только для тех, кто умеет разговорить Яна ван Бона. Core Practice3 («Основные практики», СоРr) — интересная новая разработка, достойная внимания.
Русскоязычных источников теоретических знаний не так много. Есть книги в переводе:
И сообщества, гугл в помощь.
Вроде заключения Даже вооружившись правильными KPI и произведя правильную «трансформацию» процессов своего ИТ-отдела или ИТ-компании, вы оставляете открытым главный вопрос. А изменит ли это культуру людей, ваших сотрудников? Раз конечная цель — ориентированность на бизнес и пользователя, то эта мысль должна засесть в мозгу у каждого. Как понимаете, сертификат не сможет поменять людей изнутри.
Поэтому, кто заинтересовался, готовьтесь идти трудной дорогой привыкания к изменениям.
Полный текст статьи читайте на CMS Magazine
