The Cynical Side of ITSM - Why the Backlash?
David Mainville, перевод и комментарии Евгения Шилова (Cleverics). Перевод выполнен с разрешения автора.
Евгений Шилов: Всё больше ИТ-руководителей, особенно в наше непростое время, ищут способы выживания в условиях растущих требований и сокращающихся бюджетов. И, как это обычно бывает, услышав об успешном опыте других, с готовностью берутся его повторять, надеясь получить те же результаты. Однако, ITSM - та область, которая не позволяет слепо копировать, брать и использовать, поэтому последнее время часто слышатся негативные отзывы и призывы идти другой дорогой. Я полностью разделяю мнение Девида Мейнвилля - дело не в том, что подход плохой, а в том, что надо уметь им пользоваться, приложить некоторые усилия и только тогда будут результаты.
Говорить про продукт, что он «Сертифицирован для ITIL v3» - все равно, что сертифицировать способность молотка забивать гвозди: это, конечно, правда, но не делает вас плотником.
За последний год я заметил увеличивающийся уровень скепсиса по отношению к внедрению IT Service Management и особенно к ITIL® v3. Честно говоря, меня самого тоже называют циником (и даже еретиком), потому что я отказываюсь стоять на коленях перед алтарем ITIL. Не поймите меня неправильно, я твердо верю в дух Service Management, но определенно не считаю его догмой.
У меня есть некоторый опыт, я в ITSM уже 30 лет. Начинал с управления инцидентами, внедрил бессчетное количество изменений, управлял и документировал конфигурации, оценил, спроектировал и внедрил больше процессов, чем я могу себе представить... и большую часть из них до того, как ITIL стал популярен в Северной Америке.
Я верю в ценность лучших практик - в основном потому, что я не раз видел, что это работает. Кроме того, зачем проектировать свои процессы с нуля, без использования того, что работает у других? Поэтому методология ITIL и стала стандартом де факто. Так почему же тогда возникает скепсис по отношению к ITIL и ITSM в целом?
По моему мнению причина в том, что люди путают «методологию лучших практик» с выполнением серьезной работы по управлению их собственными ITSM-программами. Когда кому-то не удается сбросить лишний вес, что лучше - ругать диету или честно подсчитать, сколько калорий было потреблено и сколько - потрачено? Если физические упражнения не дают эффекта, вы ругаете составителя программы или задумываетесь о нагрузках, частоте и продолжительности тренировок? Аналогии с диетой и фитнесом подходят и к ITSM.
Если вы не получаете ожидаемого результата от ваших инициатив в области ITSM, то возможно это потому, что вы не следуете намеченному плану. Легко спроектировать процесс и внедрить средство автоматизации - сложнее заставить людей работать в заданном направлении.
Сложно не зациклится, когда вы видите незрелость большинства ITSM-инициатив. В ходе недавнего опроса на Consulting Portal (5th Annual ITSM Industry Survey) мы подсчитали, что по данным 189 практиков ITSM менее 30% организаций организовали руководство системой управления услугами. Этот же опрос показал, что большинство организаций внедрило лишь небольшую часть процессов ITIL и только 31% внедрили CMDB.
Так почему, если ITSM и ITIL так хороши, столь немногим организациям удается добиться успеха в их применении? Я верю в то, что проблемы начинаются в самом ITSM-сообществе. Мы прилагаем массу усилий чтобы рассказать всем о ценности, которую несет ITIL, но ничего не делаем для того, чтобы все знали ценой каких усилий это дается. Другими словами, обещать можно все что угодно, но рано или поздно вам придется это обеспечить. Есть проблема и в производителях средств автоматизации ITSM. «ITIL из коробки» был девизом одного производителя программных продуктов для ITSM. Подразумевается, что «внедряя наш продукт, вы внедряете ITIL». Иллюзия того, что программа может решить все проблемы управления ИТ-услугами, усиливается благодаря стараниям OGC и APM Group, запустившим свою схему сертификации программных продуктов.
Конечно, стандартизация терминологии и базовых понятий приносит пользу, но лучшие практики по определению не могут учитывать специфику конкретной организации. Никакие средства автоматизации не внедрят для вас ваш процесс. Важно дополнять лучшие практики организационными, технологическими и культурными особенностями, а также ограничениями вашей организации. Говорить про продукт, что он «Сертифицирован для ITILv3» - все равно, что сертифицировать способность молотка забивать гвозди: это, конечно, правда, но не делает вас плотником.
Любой стоящий ITIL-практик скажет вам, что необходимо проектировать процесс с учетом особенностей вашей организации до, или вместе с внедрением средства автоматизации. А после внедрения необходимо обеспечить контроль и управление работой процессов для получения ожидаемых результатов. «Серебряной пули» не существует. Вы можете использовать лучшие практики, но вы не можете внедрить их прямо из книги.
Что с этим делать?
После такого количества сомнений и скепсиса, будет справедливым предложить несколько решений.
Для начала, некоторые доказательства того, что ITSM работает: работая в начале 80-х в компании Amdahl в качестве инженера по сопровождению мейнфрейма, я отвечал за решение инцидентов и поиск их корневых причин. Наиболее мощным инструментом, находившимся в моем распоряжении, была система автоматизации процесса управления инцидентами. Эта система была доступна по Dial Up через терминал TTY (телетайп) и содержала базу всех известных проблем, обходных и структурных решений.
Система постоянно использовалась как средство помощи при решении инцидентов и не раз помогла обнаружить закономерности, связанные с инженерными дефектами, устранение которых повысило надежность для наших клиентов и сберегло миллионы долларов компании Amdahl на обращениях пользователей и запасных частях. Но не система заставляла процесс работать, а дисциплина и управление, которые гарантировали, что все следуют процессу, вводят корректные данные, анализируют метрики, отслеживают и закрывают инциденты. Ни одна система не сделает это за вас!
Успешная программа ITSM требует дисциплины для постоянной оценки, пересмотра и управления вашими процессами. Оценка ваших процессов - это основа для выявления узких мест и определения отправной точки для последующей оценки ROI. Проектирование процессов - это больше, чем рисование диаграмм в Visio. Вам придется окунуться в дебри определения данных, метрик, управления, процедур, потоков работ, требований к системе автоматизации и многого другого.
Но главное - вам необходимо руководство. Люди должны отвечать - не только номинально - за свои части процессов. Вам необходимо определить специальные задачи по управлению, назначать их, контролировать их выполнение и принимать меры, если их не выполняют.
Легко быть экспертом или циником, постоянно бросающим камни в ITSM. Среди этих камней есть немало моих, что в сочетании с многолетней работой в сфере ITSM создает у меня несколько шизофреническое ощущение. Если и вы собираетесь быть циником по отношению к ITSM, примените свою критику там, где ей место. То есть критикуйте плохие внедрения или чрезмерную веру в «серебряные пули», а не принципы ITSM сами по себе.
