Правила джентльменского поведения в IT: история ITIL

    В начале 2019 года библиотеку инфраструктуры информационных технологий ITIL ждет самое серьёзное обновление с 2011. Уже почти 30 лет ею пользуются по всему миру — и в частном бизнесе, и в государственных структурах. Вспомним, для чего ITIL создали и как она менялась.


    Изображение 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.

    О чем еще мы пишем на Хабре:

    NAUMEN
    96,00
    Решаем истинные задачи
    Поделиться публикацией

    Комментарии 24

      +1

      Расскажите заодно про другие фреймворки типа COBIT, TOGAF, BRMBOK, BABOK, SWEBOK и т.д.

        +1
        Спасибо, что читаете. Да, планируем рассмотреть эти темы.
        0
        Как понять ITIL? Сколько не пытался читать/понять/смотреть содержимое — не дается. Любая тех.документация дается мне в разы проще, потому что есть четкие метрики, что мы получаем в замен производимых действий. В доках по ITIL этих метрик я не прослеживаю и трактовать значимые вещи можно по своему. Так что, без четких примеров «что сделали и что получили» все эти книги — набор красивых слов и формулировок. Но еще больше меня поразило — ITIL «пестрит» постоянным улучшением/модернизацией услуг, но думаю для всех не новость, что любое изменение это прежде всего изменение цены (не ценности) услуг. Поэтому улучшать услуги и их ценность без пересмотра цены — это работать себе в убыток. Другая позиция — цену можно не пересматривать, но чтобы не остаться «в минусе», нужно пересмотреть затраты, а один из самых больших источников затрат это что? Правильно — персонал. Вывод в соответствии с ITIL очевиден — сокращение персонала/затрат на персонал (страховка, питание, развозка и з/п), и перевод некогда своего персонала в какое-нибудь ТОО «Рога и Копыта», откуда все разбегутся как мыши. Я проходил через внедрения практик ITIL, не как внедренец, а как обычный сис.админ. Тот еще цирк. Может быть «внедритель» был некомпетентен — хз. Но осадок остался. Перспектива перехода в ТОО «Рога и Копыта» и впахивание за троих не доставляла положительных моментов. Послал весь этот цирк «до начала представления».
          0
          Ну вот открыл навскидку 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, или ...)

            0
            Метрики есть, а дальше? Как всё это начать «митигировать»? Как должна работать та же самая система trouble-тикетов. Как понять, что у нас всё хорошо? Понятно, что инциденты будут всегда — мелкие/крупные — не важно. Или как понять, на что можно забить? А самое главное — как весь этот фрэймворк безболезненно и с умом внедрить? Пока для меня ITIL даёт больше вопросов, чем ответов, особенно на стадии внедрения. ITIL предполагает детальное логирование в тикет-системе, которое отнимает кучу времени. Много ли здесь желающих отдать хотя бы час в день, чтобы всё логировать все действия, инценетды, решения к ним (база знаний)?
              0
              На вопрос «как делать?» ИТИЛ не отвечает, он отвечает на вопрос «что надо делать?». Как — это уже зависит от предприятия.
                0
                Это значит процесс внедрения пойдёт таким образом, как будет угодно «внедрителю». По мне — уже не правильно.
                  0
                  Лет 10 назад, когда знакомился с ITIL, понял для себя так:
                  ИТ- подразделение должно стать как-бы государством в государстве; начать работать как подрядчик по отношению к основной компании-заказчику; все сотрудники ИТ должны начать вести учёт для того, чтобы можно было подтвердить перед заказчиком объёмы и затраты и получить соответствующее обеспечение (или оправдать бюджет).

                  Ну и когда это всё начало работать как предписано, следующим шагом надо начинать оптимизировать (в т.ч. сокращать персонал, если по результатам анализа отчётности будет очевидно, что где-то его избыток; но и добавлять персонал, если по результатам анализа будет очевидна потребность).

                  Не уверен, что понял верно, но у меня именно такая сложилась картинка.
                    0
                    ITIL это не волшебная палочка. При внедрении ITIL и софта, автоматизирующего ITIL процессы _НЕОБХОДИМО_ активное участие заказчика. Причём как бизнес-подразделений и ответственных, так и IT. Т.к. обычно компаниям без ITIL прийдётся поменять парадигму работы.
                    ITIL как методология даёт общие рекомендации в части набора процессов, основных схем этих процессов, взаимосвязей этих процессов
                      0
                      Именно поэтому многие внедрения ИТИЛа проваливаются. Люди думают, что внедрение ИТИЛа — это сделать так, как написано в книге, но ИТИЛ — это выжимка, основа для построения ИТ-процессов по ИТИЛ исходя из жизни и целей конкретного бизнеса. Любая система связанная с построением процессов на предприятии, при внедрении предполагает изменения существующих процессов для обеспечения достижения поставленных целей, а не для того, чтобы их внедрить.
                      То есть, сначала определить цель изменения процесса или процессов — уменьшить расходы на ИТ, уменьшить время реакции ИТ-отдела на проблемы, уменьшить срок простоя при сбоях и т.д.
                      Затем надо решить что делать, для этого берём ИТИЛ, или, в случае других процессов — COBIT, AGILE. Пример (навскидку) — уменьшение времени реакции требует наличия HelpDesk системы с такими-то возможностями и вот таким процессом организации работы первой линии обороны ИТ.
                      И только после этого идёт «как» — поиск, выбор, тестирование подходящей системы, её внедрение, затем анализ (подошла ли, или мы накосячили на этапе «что делать»), затем корректировка и если всё нормально, то живём и радуемся тому, с какой скорость обрабатываются заявки пользователей.
                    0
                    Обсуждения проблем внедрения ITIL мне поразительно напоминает обсуждение проблем например внедрения Scrum. Здесь много публикаций посвященных оному, и в комментариях ожесточенная полемика.

                    Имхо, первая ошибка — ошибка целеполагания. Что мы хотим? Какую проблему решаем?
                    Если цель, безболезненно и с умом внедрить ITIL, скорее всего получится что-то, что будет вызывать вопросы у первого руководителя, на хера все это. И вопросы справедливые.
                    Если цели бизнес-ориентированы, например 20% звонков клиентов теряется, давайте сделаем так, чтобы терялось не более 3%, то это понятно сколько стоит(убытки), и сколько за это бизнес готов платить. Дальше начинаем погружаться в решение вопросы и становится понятен, а про что Event Mgmt, как он смотрит на Incident Mgmt, а тот в свою очередь на Problem Mgmt, Change Mgmt и пошло поехало.

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

                    ITIL предполагает детальное логирование в тикет-системе, которое отнимает кучу времени. Много ли здесь желающих отдать хотя бы час в день, чтобы всё логировать все действия, инценетды, решения к ним (база знаний)?

                    Традиционное заблуждение.
                    Логироваться должно ровно то, и с таким уровнем детализации, и таким способом, который позволяет с одной стороны не тратить много ресурсов на логирование, с другой — решать бизнес-проблемы с нужным уровнем качества. Т.е. не тратим усилия на достижение каких-то мифических метрик, потому что вычитали эту метрику в талмуде по ITIL (или консультант так насоветовал), а тратим усилия на достижение понятных бизнесу целей, которые выражаются в очевидных бизнесу метриках, типа теряем 20% звонков, хотим терять 3%, когда достигли этого, удерживаем, и ставим вторую цель (ну например, время на релокацию одной точки продажи не более 3 дней)
                  0
                  Сам насколько раз читал ITIL — просвещение пришло не сразу. После первого прочтения в голове был бардак. Но когда начал погружаться в тему изучая профильные сайты и форумы, то пришло понимание.
                  Сокращение персонала подразумевает переделку ИТ-процессов так, чтобы хватало минимального количества людей на поддержку ИТ, что и является в некой степени тем, для чего ИТИЛ и сделан.
                    0
                    Если где-то рассчитано на «минимально», то где подразумевается максимально — в смысле загруженности персонала вне своего рабочего времени 5*8. Простой закон если где-то убыло, значит где-то прибыло.
                      0
                      Убыло у нас — прибыло у других, закон работает. :) Закон, ведь так работает?

                      Сам лично создал и поддерживал инфраструктуру на 200 рабочих станций, пять серверов и 4К юзеров. Но это поддержка была чисто техническая (что-то перестало запускаться) и управленческая (учётки юзеров, права), всё вопросы «как в Экселе уместить табличку в A4» отправлялись в Гугл и иногда решались лично. При этом никакого ИТИЛа и 98% свободного времени в рабочее время.

                      PS. Если где-то один и тот же конкретный персонал загружен 24*7, то в этом где-то что-то не так. И не понятно, как этот персонал такое выдерживает.
                  +1
                  «Как понять ITIL?» Очень просто — это бизнес, кстати очень доходный, такой же как и MBA и прочая лабуда. Все правильно ты и не должен понимать о чем там речь, ведь есть чудесные платные курсы))).

                  Еще не в одной большой компании мне не встречалась нормальная реализация ИТ процессов. А я работал с Пепси, Кока-колой и еще +10500 брендов.

                  Проблема одна и таже:
                  1) руководитель ИТ не заинтересованный словоблуд, задача которого клепать красивые отчетики для начальства
                  2) раздутый штат
                  3) уход в формальности(заполните 10500 заявок)
                  4) долгие сроки реакции
                  5) cложная схема иерархии.
                  6) переключение задач с сотрудника на сотрудника.

                    –1
                    1) руководитель ИТ не заинтересованный словоблуд, задача которого клепать красивые отчетики для начальства
                    2) раздутый штат
                    3) уход в формальности(заполните 10500 заявок)
                    4) долгие сроки реакции
                    5) cложная схема иерархии.
                    6) переключение задач с сотрудника на сотрудника.


                    Разве это не следствие применения ITIL?
                    +3
                    ITIL, DevOps, Agile, Lean… Цифровизация!!!

                    Как же я понимаю некоторые песни Шнура…

                    Крик души в тему:
                    Опуститесь на бренную землю
                    Посмотрите правде в глаза
                    Какая на… й цифровизация
                    Когда кругом тормоза!

                    Тормоза в процессах, проектах, подходах, беседах…
                    Никого не хочу обидеть. Просто так есть. И это скорее практика, чем исключения из нее.

                    Поговорите об ИТИЛ с «хозяевами» — владельцами, руководителями, старшими менеджерами.
                    Им надо ДРУГОЕ!!! Увеличение прибыли, сокращение затрат, минимизация рисков. Вот их язык.
                    С 2000 года прохожу «внедрения ИТИЛ» в разных компаниях, в разных ролях — от инженера поддержки, до руководителя. Классная это штука. Вот только применять ее у нас надо с учетом особенностей наших. Местных. Знаете, как продавцы говорят? Продать самовар в Туле и в Москве — это совершенно разные вещи! ITIL там и тут — это тоже совершенно разные вещи!

                    Для себя нашел такую его реализацию — Менеджер по счастью. Приношу счастье используя принципы сервисного подхода для оптимизации бизнес-процессов. Слова «ITIL, DevOps, Agile, Lean» — НЕ УПОТРЕБЛЯЮ!
                    Проходит на «отлично» (смотрите мой блог, писал об этом ранее).

                    Статья хорошая, для понимания «откуда ноги растут» — нужная.
                    Но я за «бренную землю» и реалии.
                      0
                      Им надо ДРУГОЕ!!! Увеличение прибыли, сокращение затрат, минимизация рисков. Вот их язык.

                      ITIL и есть про сокращение затрат, минимазацию рисков и увеличение прибыли. Это и есть язык ITIL. Он вот прямо целиком обо всём вот этом вот и для этого в первую очередь и нужен.
                      Чтобы можно было деятельность как минимум ИТ обмерять целиком в деньгах, и даже риски измерить в деньгах.
                      Incident — про сокращение затрат из-за прерываний оказываемых услуг(в т.ч. про стоимость устранения инцидентов т.к. у людей работающих над инцидентом есть почасовая цена).
                      Change — про расчёт рисков, затрат на исполнение RFC, стоимости необходимых активов и денег на оплату человеческого времени, необходимого для внедрения RFC
                      Problem — для группировки инцидентов и ведения сложноустранимых ошибок, вызывающих множественные инциденты с разных сторон
                      Workorder — учет затрат времени/денег на выполнения какой-либо базовой работы, чаще всего в рамках change.
                      Config& Asset — думаю и так понятно что в конфигах и asset калькулируется стоимость актива/софта на КЕ и т.Д

                      абсолютно все процессы в ITIL ориентированы на то чтобы:
                      1)Бизнес знал сколько стоит ИТ и почему столько стоит и увидеть дыры, которые заставляют компанию терять деньги
                      2)измерить эту самую деятельность ИТ загоняя всех в процессы, по которым можно отслеживать сколько и над чем именно работал Инженер1, Инженер2, Инженер3

                      Возможно вы просто ITIL не с той стороны щупали. ITIL просто насквозь про бабки и про учет времени
                        0
                        Попробуйте то же самое написать кратко для бизнес руководителя.
                        Которому пофиг Incident это или Problem в терминологии ITIL.
                          0
                          Повторюсь,
                          ITIL — не волшебная палочка, и он нацелен как раз на то чтобы у бизнес-руководителя появилсь инструменты, которые помогут ему понять текущую ситуацию с ИТ и адекватно что-то прогнозировать.
                          При этом как бизнес, так и ИТ руководство должны погрузиться в свои срезы ITIL, чтобы с этого был выхлоп. Не просто так речь о процессах. Как можно выстроить в компании какой-либо процесс, если даже руководство не имеет понятия о том как они протекают?
                            0
                            «руководство должны погрузиться в свои срезы ITIL»…
                            Повторюсь — опуститесь на бренную землю.
                            Руководство — должно. Вы сами-то в это верите?

                            Бизнес-руководителю можно и нужно это донести. Вот тут я с вами согласен. Хорошо, если есть кому это сделать. Чаще — некому.

                            Знаете какой наиболее частый вопрос мне задают после выступлений на ИТ-мероприятиях?
                            — Как вам удалось донести это до бизнес-руководителей?
                            Вот это реально интересно. Как донести до бизнеса принципы ITIL доходчиво.
                              0
                              Вот это реально интересно. Как донести до бизнеса принципы ITIL доходчиво.

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

                              Верю, но под этим подразумеваю участие консультантов, которые помогут разобраться.
                                0
                                Вот и пришли к взаимопониманию!
                                Я как раз и занимаюсь консультациями бизнеса, используя индивидуальный подход. С учетом знаний и опыта ИТ + ITIL, реально интересно!
                                  0
                                  А иначе это как сказать человеку: «Через два дня чтобы рассказал войну и мир», потом взять 4 тома и каждым из них настучать по морде, в надежде что это поможет человеку понять суть:-)
                                  В это нужно очень хорошо погрузиться чтобы понять всё со всех сторон(как с бизнеса, так и с ИТ, не говоря уже об ролях в каждом из процессов). Слишком всё глубоко связано между друг другом

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое