Изображение Jonathan Mueller CC
Создание ITIL: дрессируя зоопарк решений
Первый свод лучших практик по организации процессов в IT-сфере был составлен в Великобритании в конце 1980-х. Чтобы лучше понять, откуда растут ноги у ITIL, стоит сделать краткий экскурс в тогдашнее состояние британской сферы информационных технологий.
В 1980-х в Великобритании проводилась целенаправленная компьютеризация правительственных учреждений. Через какое-то время у каждого госоргана и частного подрядчика сложилась собственная методология управления IT-процессами.
Стремительно увеличиваясь, отраслевая среда оказалась донельзя разрозненной. Каждый её элемент действовал по своим правилам, а одни и те же ошибки регулярно повторялись в разных частях системы, что влекло за собой, помимо прочего, высокие издержки. Так что единый свод лучших практик был жизненно необходим.
На тот момент в Великобритании существовало ведомство, которое занималось вопросами внедрения информационных технологий и их унификации — Центральное компьютерное и телекоммуникационное агентство (CCTA). В его обязанности входила помощь частным компаниям в разработке продуктов и услуг для правительства. Поначалу CCTA в основном занималось закупками оборудования, но в конце 80-х переключилось на реализацию бизнес-ориентированного системного подхода к управлению IT.
Правительство Великобритании поставило перед CCTA задачу объединить лучшие практики организации процессов в области информационных технологий — с целью исключительно прагматической: повысить окупаемость государственных расходов на компьютеризацию.
Агентство, в свою очередь, поручило исследовательской группе собрать необходимую информацию у представителей примерно 2,5 тыс. крупных и малых предприятий в различных отраслях. Как утверждает один из специалистов, принимавших участие в создании библиотеки, идея заключалась в том, чтобы выделить наиболее удачные наработки и сформировать стандартизованный подход к выстраиванию рутинных процессов, который в дальнейшем могла бы приспособить к своим нуждам абсолютно любая организация.
Важную роль в составлении свода сыграла корпорация IBM, которая к тому моменту уже выработала собственный системный подход к управлению IT-услугами. Она назвала его Information Systems Management Architecture (ISMA). На основе рекомендаций IBM и во многом на базе ISMA был сформирован прообраз ITIL — Government IT Infrastructure Management Method (GITIMM). Документ содержал несколько разделов, включая «Управление изменениями», «Управление проблемами» и «Управление доступностью».
Позже член совета CCTA Рой Диббл (Roy Dibble) настоял на том, чтобы изменить заглавие документа. Из него исключили слова «правительство» и «метод». Первое не подходило, так как предполагалось, что эти разработки будут использоваться и частными компаниями, а второе не соответствовало сути проекта (поскольку это набор лучших практик). В итоге от названия осталось только IT Infrastructure Management. А в 1989 году оно превратилось в IT Infrastructure Library, сокращённо ITIL.
Поваренная книга айтишника: три версии ITIL
В том же 1989 году была опубликована первая книга библиотеки ITIL — «Управление уровнем IT-услуг». Новые тома выходили на протяжении следующих семи лет. Появились: «Управление изменениями», «Управление проблемами», «Управление конфигурацией», «Управление затратами», «Управление доступностью» и многие другие. Всего ITIL v1 включала в себя более 30 книг.
По сравнению с будущими версиями, ITIL v1 имела ярко выраженный уклон в техническую сторону. Впрочем, это не помешало крупным компаниям и правительственным учреждениям Европы без проволочек начать внедрять её в свою практику. В США ITIL проникла в 1996 году — с открытием первых сертификационных курсов по изложенным в ней практикам.
Вокруг британского подхода к управлению IT постепенно складывался круг приверженных ему лиц и организаций. Формирование сообщества создатели библиотеки планировали с самого начала. По первому времени оно представляло собой группу «активных пользователей», а впоследствии выросло в IT Service Management Forum (itSMF) с представительствами в разных странах.
Тем временем концепции управления IT эволюционировали. Частные компании, взявшие свод на вооружение, теперь старались связать технологии с бизнес-процессами, для чего требовалось упростить и обновить библиотеку. Работа над ITIL v2 началась в конце 1990-х. Первый том серии — ITIL Service Support — вышел в 2000 году. К тому моменту на смену CCTA пришла Государственная торговая палата Великобритании (Office for Government Commerce), и та перехватила эстафетную палочку в координации работы над библиотекой.
При подготовке второй версии ITIL разработчики решили ограничиться семью томами — каждый об отдельном аспекте развития проектов в сфере информационных технологий. Они назывались: «Поддержка услуг», «Предоставление услуг», «Планирование внедрения управления услугами», «Управление приложениями», «Управление инфраструктурой информационно-коммуникационных технологий», «Управление безопасностью» и «Бизнес-перспектива». Таким образом, фокус ITIL был смещён с технической составляющей на сервисную.
В 2000 году компания Microsoft использовала ITIL в качестве основы для разработки Microsoft Operations Framework (MOF) — своего комплекса рекомендаций для эффективной работы IT-инфраструктуры.
Вторая версия ITIL оставалась актуальной до конца 2006 года. К тому времени Государственная торговая палата Великобритании передала компании HP право на составление глоссария ITIL. В 2006 году тот был переиздан. Его публикация ознаменовала собой плавный переход к третьей версии ITIL.
Обновлённая версия библиотеки была выпущена в мае 2007 года. Число томов снова сократилось — на сей раз до пяти: «Стратегия обслуживания», «Проектирование услуг», «Преобразование услуг», «Эксплуатация услуг», «Постоянное совершенствование услуг». Каждый том служит сводом рекомендаций по автоматизации процессов в соответствующей области и описывает необходимые для этого инструменты.
Изображение Roland Tanglao CC
В третьей ипостаси ITIL v3 описано 26 процессов и функций — втрое больше, чем в предыдущей версии. И она ещё более тесно связана с интеграцией IT в бизнес-процессы.
В этот период сформировалось еще несколько систем управления IT на базе ITIL, кроме ранее упомянутого MOF: стандарт ISO 20000, ITSM Reference Model от HP, Process Reference Model for IT от IBM.
В 2011 году третью версию ITIL обновили. Концептуально это была всё ещё ITIL v3, но с несколько переделанной структурой: ряд процессов добавили, некоторые пересмотрели. Например, ревизии подверглась «Стратегия обслуживания», были введены такие сущности, как «управление взаимоотношениями с бизнесом», «управление стратегией», «управление спросом», «координация проекта».
Будущее ITIL: практики к практикам
В 2013 году торговая марка и права на разработку ITIL были переданы компании Axelos — совместному предприятию правительства Великобритании и компании Capita. Axelos лицензирует организации для использования интеллектуальной собственности ITIL, аккредитует экзаменаторов и отвечает за реализацию новых версий библиотеки и её пополнение. Именно эта компания анонсировала предстоящее обновление.
Из слов главы Axelos следует, что ITIL 2018 будет совместима с методологиями DevOps, Agile и Lean. Отрасли это действительно необходимо: многие компании и без того комбинируют названные практики, а обновление библиотеки упростит их взаимную интеграцию.
Нынешний вектор развития ITIL и вся её история — хороший пример того, как концепция, зародившаяся в государственном секторе, переломила стереотипы о его бюрократизме и неповоротливости и легла в основу инструментария, который востребован крупнейшими компаниями из списка Fortune 500.
О чем еще мы пишем на Хабре:
Комментарии (24)
scruff
15.10.2018 08:32Как понять ITIL? Сколько не пытался читать/понять/смотреть содержимое — не дается. Любая тех.документация дается мне в разы проще, потому что есть четкие метрики, что мы получаем в замен производимых действий. В доках по ITIL этих метрик я не прослеживаю и трактовать значимые вещи можно по своему. Так что, без четких примеров «что сделали и что получили» все эти книги — набор красивых слов и формулировок. Но еще больше меня поразило — ITIL «пестрит» постоянным улучшением/модернизацией услуг, но думаю для всех не новость, что любое изменение это прежде всего изменение цены (не ценности) услуг. Поэтому улучшать услуги и их ценность без пересмотра цены — это работать себе в убыток. Другая позиция — цену можно не пересматривать, но чтобы не остаться «в минусе», нужно пересмотреть затраты, а один из самых больших источников затрат это что? Правильно — персонал. Вывод в соответствии с ITIL очевиден — сокращение персонала/затрат на персонал (страховка, питание, развозка и з/п), и перевод некогда своего персонала в какое-нибудь ТОО «Рога и Копыта», откуда все разбегутся как мыши. Я проходил через внедрения практик ITIL, не как внедренец, а как обычный сис.админ. Тот еще цирк. Может быть «внедритель» был некомпетентен — хз. Но осадок остался. Перспектива перехода в ТОО «Рога и Копыта» и впахивание за троих не доставляла положительных моментов. Послал весь этот цирк «до начала представления».
ggo
15.10.2018 09:49Ну вот открыл навскидку ITIL v3 Incident Management, метрики:
¦ Total numbers of Incidents (as a control measure)
¦ Breakdown of incidents at each stage (e.g. logged,
work in progress, closed etc)
¦ Size of current incident backlog
¦ Number and percentage of major incidents
¦ Mean elapsed time to achieve incident resolution or
circumvention, broken down by impact code
…
И далее т.п.
По мне, так вполне себе конкретные метрики.
А проблема внедрения — это верно подмечено, режет все на корню. Но очевидно, это не проблема ITIL (или PMI, или ...)
scruff
15.10.2018 10:48Метрики есть, а дальше? Как всё это начать «митигировать»? Как должна работать та же самая система trouble-тикетов. Как понять, что у нас всё хорошо? Понятно, что инциденты будут всегда — мелкие/крупные — не важно. Или как понять, на что можно забить? А самое главное — как весь этот фрэймворк безболезненно и с умом внедрить? Пока для меня ITIL даёт больше вопросов, чем ответов, особенно на стадии внедрения. ITIL предполагает детальное логирование в тикет-системе, которое отнимает кучу времени. Много ли здесь желающих отдать хотя бы час в день, чтобы всё логировать все действия, инценетды, решения к ним (база знаний)?
paranoya_prod
15.10.2018 11:33На вопрос «как делать?» ИТИЛ не отвечает, он отвечает на вопрос «что надо делать?». Как — это уже зависит от предприятия.
scruff
15.10.2018 11:45Это значит процесс внедрения пойдёт таким образом, как будет угодно «внедрителю». По мне — уже не правильно.
phaggi
15.10.2018 13:38Лет 10 назад, когда знакомился с ITIL, понял для себя так:
ИТ- подразделение должно стать как-бы государством в государстве; начать работать как подрядчик по отношению к основной компании-заказчику; все сотрудники ИТ должны начать вести учёт для того, чтобы можно было подтвердить перед заказчиком объёмы и затраты и получить соответствующее обеспечение (или оправдать бюджет).
Ну и когда это всё начало работать как предписано, следующим шагом надо начинать оптимизировать (в т.ч. сокращать персонал, если по результатам анализа отчётности будет очевидно, что где-то его избыток; но и добавлять персонал, если по результатам анализа будет очевидна потребность).
Не уверен, что понял верно, но у меня именно такая сложилась картинка.
Nova_Logic
15.10.2018 14:35ITIL это не волшебная палочка. При внедрении ITIL и софта, автоматизирующего ITIL процессы _НЕОБХОДИМО_ активное участие заказчика. Причём как бизнес-подразделений и ответственных, так и IT. Т.к. обычно компаниям без ITIL прийдётся поменять парадигму работы.
ITIL как методология даёт общие рекомендации в части набора процессов, основных схем этих процессов, взаимосвязей этих процессов
paranoya_prod
15.10.2018 15:12Именно поэтому многие внедрения ИТИЛа проваливаются. Люди думают, что внедрение ИТИЛа — это сделать так, как написано в книге, но ИТИЛ — это выжимка, основа для построения ИТ-процессов по ИТИЛ исходя из жизни и целей конкретного бизнеса. Любая система связанная с построением процессов на предприятии, при внедрении предполагает изменения существующих процессов для обеспечения достижения поставленных целей, а не для того, чтобы их внедрить.
То есть, сначала определить цель изменения процесса или процессов — уменьшить расходы на ИТ, уменьшить время реакции ИТ-отдела на проблемы, уменьшить срок простоя при сбоях и т.д.
Затем надо решить что делать, для этого берём ИТИЛ, или, в случае других процессов — COBIT, AGILE. Пример (навскидку) — уменьшение времени реакции требует наличия HelpDesk системы с такими-то возможностями и вот таким процессом организации работы первой линии обороны ИТ.
И только после этого идёт «как» — поиск, выбор, тестирование подходящей системы, её внедрение, затем анализ (подошла ли, или мы накосячили на этапе «что делать»), затем корректировка и если всё нормально, то живём и радуемся тому, с какой скорость обрабатываются заявки пользователей.
ggo
15.10.2018 20:09Обсуждения проблем внедрения ITIL мне поразительно напоминает обсуждение проблем например внедрения Scrum. Здесь много публикаций посвященных оному, и в комментариях ожесточенная полемика.
Имхо, первая ошибка — ошибка целеполагания. Что мы хотим? Какую проблему решаем?
Если цель, безболезненно и с умом внедрить ITIL, скорее всего получится что-то, что будет вызывать вопросы у первого руководителя, на хера все это. И вопросы справедливые.
Если цели бизнес-ориентированы, например 20% звонков клиентов теряется, давайте сделаем так, чтобы терялось не более 3%, то это понятно сколько стоит(убытки), и сколько за это бизнес готов платить. Дальше начинаем погружаться в решение вопросы и становится понятен, а про что Event Mgmt, как он смотрит на Incident Mgmt, а тот в свою очередь на Problem Mgmt, Change Mgmt и пошло поехало.
Очевидно умные слова лучше оставить для подчиненных, а с бизнес-подразделениями общаться на языке бизнеса. Правда бизнес бывает разный, иногда эффективность и рост за счет внутренних резервов неинтересны. Тогда либо переходите на сторону зла, либо ищете другую работу.
ITIL предполагает детальное логирование в тикет-системе, которое отнимает кучу времени. Много ли здесь желающих отдать хотя бы час в день, чтобы всё логировать все действия, инценетды, решения к ним (база знаний)?
Традиционное заблуждение.
Логироваться должно ровно то, и с таким уровнем детализации, и таким способом, который позволяет с одной стороны не тратить много ресурсов на логирование, с другой — решать бизнес-проблемы с нужным уровнем качества. Т.е. не тратим усилия на достижение каких-то мифических метрик, потому что вычитали эту метрику в талмуде по ITIL (или консультант так насоветовал), а тратим усилия на достижение понятных бизнесу целей, которые выражаются в очевидных бизнесу метриках, типа теряем 20% звонков, хотим терять 3%, когда достигли этого, удерживаем, и ставим вторую цель (ну например, время на релокацию одной точки продажи не более 3 дней)
paranoya_prod
15.10.2018 11:23Сам насколько раз читал ITIL — просвещение пришло не сразу. После первого прочтения в голове был бардак. Но когда начал погружаться в тему изучая профильные сайты и форумы, то пришло понимание.
Сокращение персонала подразумевает переделку ИТ-процессов так, чтобы хватало минимального количества людей на поддержку ИТ, что и является в некой степени тем, для чего ИТИЛ и сделан.scruff
15.10.2018 11:39Если где-то рассчитано на «минимально», то где подразумевается максимально — в смысле загруженности персонала вне своего рабочего времени 5*8. Простой закон если где-то убыло, значит где-то прибыло.
paranoya_prod
15.10.2018 15:33Убыло у нас — прибыло у других, закон работает. :) Закон, ведь так работает?
Сам лично создал и поддерживал инфраструктуру на 200 рабочих станций, пять серверов и 4К юзеров. Но это поддержка была чисто техническая (что-то перестало запускаться) и управленческая (учётки юзеров, права), всё вопросы «как в Экселе уместить табличку в A4» отправлялись в Гугл и иногда решались лично. При этом никакого ИТИЛа и 98% свободного времени в рабочее время.
PS. Если где-то один и тот же конкретный персонал загружен 24*7, то в этом где-то что-то не так. И не понятно, как этот персонал такое выдерживает.
anonymous
15.10.2018 11:55«Как понять ITIL?» Очень просто — это бизнес, кстати очень доходный, такой же как и MBA и прочая лабуда. Все правильно ты и не должен понимать о чем там речь, ведь есть чудесные платные курсы))).
Еще не в одной большой компании мне не встречалась нормальная реализация ИТ процессов. А я работал с Пепси, Кока-колой и еще +10500 брендов.
Проблема одна и таже:
1) руководитель ИТ не заинтересованный словоблуд, задача которого клепать красивые отчетики для начальства
2) раздутый штат
3) уход в формальности(заполните 10500 заявок)
4) долгие сроки реакции
5) cложная схема иерархии.
6) переключение задач с сотрудника на сотрудника.
Kelv13
15.10.2018 15:29-11) руководитель ИТ не заинтересованный словоблуд, задача которого клепать красивые отчетики для начальства
2) раздутый штат
3) уход в формальности(заполните 10500 заявок)
4) долгие сроки реакции
5) cложная схема иерархии.
6) переключение задач с сотрудника на сотрудника.
Разве это не следствие применения ITIL?
DmMel
15.10.2018 12:09+1ITIL, DevOps, Agile, Lean… Цифровизация!!!
Как же я понимаю некоторые песни Шнура…
Крик души в тему:
Опуститесь на бренную землю
Посмотрите правде в глаза
Какая на… й цифровизация
Когда кругом тормоза!
Тормоза в процессах, проектах, подходах, беседах…
Никого не хочу обидеть. Просто так есть. И это скорее практика, чем исключения из нее.
Поговорите об ИТИЛ с «хозяевами» — владельцами, руководителями, старшими менеджерами.
Им надо ДРУГОЕ!!! Увеличение прибыли, сокращение затрат, минимизация рисков. Вот их язык.
С 2000 года прохожу «внедрения ИТИЛ» в разных компаниях, в разных ролях — от инженера поддержки, до руководителя. Классная это штука. Вот только применять ее у нас надо с учетом особенностей наших. Местных. Знаете, как продавцы говорят? Продать самовар в Туле и в Москве — это совершенно разные вещи! ITIL там и тут — это тоже совершенно разные вещи!
Для себя нашел такую его реализацию — Менеджер по счастью. Приношу счастье используя принципы сервисного подхода для оптимизации бизнес-процессов. Слова «ITIL, DevOps, Agile, Lean» — НЕ УПОТРЕБЛЯЮ!
Проходит на «отлично» (смотрите мой блог, писал об этом ранее).
Статья хорошая, для понимания «откуда ноги растут» — нужная.
Но я за «бренную землю» и реалии.Nova_Logic
15.10.2018 14:44Им надо ДРУГОЕ!!! Увеличение прибыли, сокращение затрат, минимизация рисков. Вот их язык.
ITIL и есть про сокращение затрат, минимазацию рисков и увеличение прибыли. Это и есть язык ITIL. Он вот прямо целиком обо всём вот этом вот и для этого в первую очередь и нужен.
Чтобы можно было деятельность как минимум ИТ обмерять целиком в деньгах, и даже риски измерить в деньгах.
Incident — про сокращение затрат из-за прерываний оказываемых услуг(в т.ч. про стоимость устранения инцидентов т.к. у людей работающих над инцидентом есть почасовая цена).
Change — про расчёт рисков, затрат на исполнение RFC, стоимости необходимых активов и денег на оплату человеческого времени, необходимого для внедрения RFC
Problem — для группировки инцидентов и ведения сложноустранимых ошибок, вызывающих множественные инциденты с разных сторон
Workorder — учет затрат времени/денег на выполнения какой-либо базовой работы, чаще всего в рамках change.
Config& Asset — думаю и так понятно что в конфигах и asset калькулируется стоимость актива/софта на КЕ и т.Д
абсолютно все процессы в ITIL ориентированы на то чтобы:
1)Бизнес знал сколько стоит ИТ и почему столько стоит и увидеть дыры, которые заставляют компанию терять деньги
2)измерить эту самую деятельность ИТ загоняя всех в процессы, по которым можно отслеживать сколько и над чем именно работал Инженер1, Инженер2, Инженер3
Возможно вы просто ITIL не с той стороны щупали. ITIL просто насквозь про бабки и про учет времениDmMel
15.10.2018 14:55Попробуйте то же самое написать кратко для бизнес руководителя.
Которому пофиг Incident это или Problem в терминологии ITIL.Nova_Logic
15.10.2018 15:15Повторюсь,
ITIL — не волшебная палочка, и он нацелен как раз на то чтобы у бизнес-руководителя появилсь инструменты, которые помогут ему понять текущую ситуацию с ИТ и адекватно что-то прогнозировать.
При этом как бизнес, так и ИТ руководство должны погрузиться в свои срезы ITIL, чтобы с этого был выхлоп. Не просто так речь о процессах. Как можно выстроить в компании какой-либо процесс, если даже руководство не имеет понятия о том как они протекают?DmMel
15.10.2018 15:36«руководство должны погрузиться в свои срезы ITIL»…
Повторюсь — опуститесь на бренную землю.
Руководство — должно. Вы сами-то в это верите?
Бизнес-руководителю можно и нужно это донести. Вот тут я с вами согласен. Хорошо, если есть кому это сделать. Чаще — некому.
Знаете какой наиболее частый вопрос мне задают после выступлений на ИТ-мероприятиях?
— Как вам удалось донести это до бизнес-руководителей?
Вот это реально интересно. Как донести до бизнеса принципы ITIL доходчиво.Nova_Logic
15.10.2018 15:51Вот это реально интересно. Как донести до бизнеса принципы ITIL доходчиво.
Тут индивидуальный подход в консультациях. Ибо все люди мыслят несколько по-разному, соответственно это надо адаптировать, поскольку речь об огромном пласте данных.
Руководство — должно. Вы сами-то в это верите?
Верю, но под этим подразумеваю участие консультантов, которые помогут разобраться.DmMel
15.10.2018 15:59Вот и пришли к взаимопониманию!
Я как раз и занимаюсь консультациями бизнеса, используя индивидуальный подход. С учетом знаний и опыта ИТ + ITIL, реально интересно!Nova_Logic
15.10.2018 16:17А иначе это как сказать человеку: «Через два дня чтобы рассказал войну и мир», потом взять 4 тома и каждым из них настучать по морде, в надежде что это поможет человеку понять суть:-)
В это нужно очень хорошо погрузиться чтобы понять всё со всех сторон(как с бизнеса, так и с ИТ, не говоря уже об ролях в каждом из процессов). Слишком всё глубоко связано между друг другом
BigD
Расскажите заодно про другие фреймворки типа COBIT, TOGAF, BRMBOK, BABOK, SWEBOK и т.д.
antonary Автор
Спасибо, что читаете. Да, планируем рассмотреть эти темы.