Оно никогда не взлетит. Или всё же...?

Одна из особенностей нашей страны состоит в том, что мы очень изолированы. Расстояния и культура дают о себе знать, и мы не всегда в курсе что и как делают соседние или не очень соседние страны. Вот в Европах другое дело — там всё рядом, границ нет, обмен опытом, практиками и знаниями вести легче.

Эту же особенность можно наблюдать и в ITSM-мире. Мы хорошо знаем как делаем проекты сами, примерно знаем как их делают другие российские компании, и уже не так хорошо представляем себе как оно делается в остальном мире.

Тем интереснее сравнить.

Возможность для такого сравнения есть — на конференции itSMF UK было довольно интересное выступление аж трёх человек разом, которые в одном докладе рассказали об успехах ITSM в компании Virgin Atlantic Airways. Я, конечно же, не смогу воспроизвести здесь их доклад, но ключевые моменты их "путешествия" готов изложить. Кстати сказать, на этом докладе аудитория была заполнена чуть более, чем полностью — организаторам пришлось устраивать доп.места и закрывать вход для опаздывающих, т.к. сажать их было решительно некуда. Очень немного докладов пользовалось такой популярностью.

Итак, о внедрении ITSM в компании Virgin Atlantic.

Сначала несколько слов о компании: авиаперевозчик со штаб-квартирой в Англии, принадлежит на половину (точнее, 51%) Ричарду Бренсону, на вторую почти половину — Сингапурским авиалиниям. Рейсы в основном из Великобритании в Северную Америку, на Карибы, в Африку, Австралию, Азию... Располагает широкофюзеляжными самолётами, в прошлом году перевез почти 5,5 млн.пассажиров (это примерно как наш "Трансаэро").

Про сотрудников: всего в компании трудится около 8000 человек. Из них ИТ составляет примерно 250 человек, распределённых по миру следующим образом: около 100 — в Великобритании, ещё около 100 — в Индии, остальные поделены между Минском (!) и другими площадками.

Про основание для большого ITSM-проекта известно немногое. Есть только лозунг: "An opportunity for a new era in IT service delivery at VAA". К сожалению, трактовать его можно очень широко.

ITSM-программа началась в июне 2008 года. Первая фаза заняла полгода и состояла из планирования, оценки текущего состояния, подготовки и утверждения бизнес-обоснования. Радар зрелости ДО начала проекта был таков:

Следующая фаза состояла из:

  • Service Desk
  • управления инцидентами
  • управления запросами на обслуживание
  • управления проблемами и знаниями
  • управления уровнем услуг
  • элементов управления конфигурациями
  • управления изменениями

При этом "инциденты", "проблемы" и "знания" переведены в промышленную эксплуатацию в сентябре 2009, а "изменения", "запросы" и "задания" — в январе 2010. На замечание из зала "что-то как-то не быстро" был дан ответ: "Так у нас 120 проектов одновременно идёт".

Внедряемая система BMC Remedy заменила собой использовавшуюся ранее "небольшую" ITSM-систему. Принцип внедрения — OOTB, только коробка. Минимальные доработки. Atrium не внедряется. Зато и система, и процессы теперь стали едиными по всей компании (раньше было совсем не так).

Третья фаза, которая сейчас идёт, включает в себя:

  • расширение управления запросами
  • расширение SLM
  • отчётность об уровне услуг
  • Single Sign On
  • улучшение каталога запросов

Причём на третьей фазе приняли решение отойти от принципа "только коробка".

Работают в паре с консалтинговой компанией, которую выбирали по конкурсу. Из интересного — консультант подписался на fixed price, насколько я понял — на все три фазы. Ключевые специалисты заказчика (они же докладчики) консультанта сильно хвалят. Консультант выглядит уставшим.


По ходу изложения я специально старался избегать собственных оценок и суждений, чтобы не искажать картинку.

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

PRINCE2 Управление ИТ-проектами на основе PRINCE2

Трёхдневный аккредитованный учебный курс с интерактивным кейсом.
 

Узнайте больше!

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

    1. Олег Скрынник Автор

      Не, ну почему же глупость 🙂

      Информации об этом измерении зрелости почти нет, только картинка. На докладе товарищи не конкретизировали. Думаю, что это делали те самые внешние консультанты, но на что они опирались и как сделали шкалу — не знаю, к сожалению.

      0
      0
    1. Олег Скрынник Автор

      Юр, только стандартные слова: динамичная компания, серьёзный бизнес, надо соответствовать и т.д.

      То есть никакой конкретики.

      Из важного, кажется, сказали, что айтишники раскиданы по разным не то чтобы площадкам — странам, и отсутствие единых процессов сильно мешает работе. Очень часто вспоминали Минск как пример места, где у них есть ИТ-персонал. Прикольно звучало — у нас ИТ расположено в Великобритании, в Индии, и в Минске. Как будто это край света 🙂

      0
      0
  1. Руслан

    1.0 июнь—ноябрь(6) 2008 — Обследование, Обоснование, Целеполагание

    2.1 январь—сентябрь(9) 2009 — Инциденты, Проблемы и Знания

    2.2 октябрь—январь(4) 2010 — Изменения, Запросы и Задания

    3.0 январь—декабрь(12) 2010 — Расширение, наращивание

    Немного непонятно с третьей фазой, чего такого год делают?

    И в целом, как-то всё в «вэдва» стиле сформулировано 😉

    0
    0
  2. Дмитрий Исайченко

    > Atrium не внедряется

    Atrium — часть ITSM Suit'а и внедряться отдельно она не может. А суть видимо в том, что не внедряется config management и вот это интересный пункт. Т.е. согласно «кейсу» люди посчитали, что лучше реализовать INC, RFF, PRB, CHG, SLM без CMDB, чем тратить силы на ее создание и актуализацию (есть только непонятные элементы управления конфигурациями, интересно что это). Очень любопытный момент, сам об этом думаю.

    0
    0
    1. Руслан

      Может имелась в виду монстрообразная и бесполезная флеш-консоль?

      Как-то странно без управления конфигурациями внедрять процессы. Орг-структура, местоположения и хотя-бы виртуальные модели систем (оборудования) всё равно нужны.

      0
      0
      1. Дмитрий Исайченко

        > Как-то странно без управления конфигурациями внедрять процессы. > Орг-структура, местоположения и хотя-бы виртуальные модели систем > (оборудования) всё равно нужны.

        Странно в смысле непривычно — да. Но вопрос интересный.

        Что касается оргструктуры — обычно это вопрос интеграции с AD или HRM. CMDB это называть у меня язык не поворачивается (да, помню у авторов ITIL поворачивается) и процесс управления конфигурациями для этого не нужен. Местоположения — примерно та же история.

        А вот модели систем — да, я тоже считаю, что это нужно. НО Вы наверно знаеете немало компаний, которые смогли реализовать какой-то INC, PRB и даже какой-то CHG. А теперь внимание вопрос: у какой части этих компаний CMDB обеспачивает логическую модель инфрастрктуры, а не просто список имущества? То-то. А если можно реализовать эти процессы с почти бессмысленной CMDB, то почему бы не сделать еще один шаг и сознательно отказаться от CMDB, экономя силы и средства, и внося вклад в сокращение энтропии во вселенной?

        0
        0
        1. Руслан

          +1.

          Очень высокоуровневая модель всего ИТ — вот максимум, который требуется от CMDB, по моим наблюдением. Если нужно учитывать оборудование — не вопрос, только без связей между собой, максимум — привязать к этой самой модели.

          У меня сформировались такие требования к модели:

          1. Представлена графически;

          2. Умещается на А4.

          Пока кажется, все задачи сервисного управления с помощью такой модели решаемы.

          0
          0
              1. Дмитрий Исайченко

                Вот как. Возьмем типичный профиль нашего клиента:

                — сотни серверов (обычно от 200 и больше);

                — сотни единиц сетевого оборудования;

                — десятки каналов передачи данных (иногда сотни);

                — 50-100 информационных систем (всякие АРМЫ не считаем)

                — несколько площадок (к примеру возьмем 5)

                — от 2 000 рабочих мест (иногда гораздо больше)

                Теперь положите перед собой лист А4. Положили? Попробуйте решить хотя бы одну здачу — определение взаимного влияния компонент и систем.

                В качестве ответа прошу прислать скан получившейся картинки.

                0
                0
                1. Руслан

                  Сделать простое сложным может каждый. Сделать сложное простым, простым до изумления – это и есть творчество.

                  «определение взаимного влияния компонент и систем» — это вымышленная задача, у неё нет заказчика. Никому, кроме консультанта её решение не нужно.

                  0
                  0
                    1. Руслан

                      На здравом смысле. Ни в какой области знаний или деятельности подобный подход (видеть детальную картину взаимосвязей всего) не используется. Есть предел многообразия доступный для понимания человеком, есть нормы управления. Если сложность объекта управления велика и, соответственно, количество задач управления велико, его(объект) либо делят на части, либо представляют в виде иерархии. Разбиение задач управления следует за разбиением объекта.

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

                      Отдельно стоит упомянуть сложности с построением такой схемы, вызываемые современной направленностью технологий в сторону виртуализации. В некоторых случаях фактическую связь сервер-система никто и определить-то не сможет. Возникает связь не объект-объект, а группа-группа, как только связывать группы станет привычно и понятно, всё уместится на А4. Просто группы покрупнее, а связей поменьше. 😉

                      0
                      0
                    2. Дмитрий Исайченко

                      «видеть детальную картину взаимосвязей всего»

                      Как раз по-человечески построенная CMDB позволяет уйти от такой, согласен, тупиковой постановки задачи. У меня примеры из жизни есть, я не книжку цитирую.

                      «Просто группы покрупнее, а связей поменьше»

                      Ну так это же прекрасно. Присылайте картинку 🙂

                      Добавлю. Редукционизм, предложенный Вами, действительно полезен. Надо упрощать. Но в данном случае сложность модели определяется сложностью объекта управления. И такое укрупнение очень быстро может привести к тому, что полезных выводов на основании такой картинки сделать не получится. А значит и ценности в ней не останется. И возвращаемся к исходному вопросу: чем создавать бессмысленную CMDB может по чесноку отказаться, оценить / принять последствия и решать свои задачи без нее?

                      Впрочем, согласен с Романом, это уже немного оффтоп. Мы ж за VAA говорили 🙂

                      0
                      0
                    3. Руслан

                      "Ну так это же прекрасно. Присылайте картинку "

                      Не пришлю 😉

                      «И возвращаемся к исходному вопросу: чем создавать бессмысленную CMDB может по чесноку отказаться, оценить / принять последствия и решать свои задачи без нее?»

                      +1.

                      0
                      0
      2. Дмитрий Исайченко

        Добавлю. Возможно, мы не достигнем 4-го уровня зрелости процессов без CMDB. Но так же возможно это нужно далеко не всем компаниям. Достаточно банального внутреннего учета и контроля. Совершенствование же во внутреннюю практику может и не превратиться, оставаясь на уровне отдельных инициатив, в том числе с привлечением консалтинга. На самом деле для многих компаний L4 одинаково не достижим что с CMDB, что без оной.

        0
        0
        1. Роман Журавлёв

          Не сочтите за рекламу... довольно много и подробно об управлении конфигурациями без CMDB написано в той самой новой книжке Скептика на русском. Он ведь давно и настойчиво говорит о такой возможности. Глава показательно называется «CMDB не бывает».

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

          0
          0
  3. Дмитрий Исайченко

    И да, я думаю (надеюсь?) оно взлетит. Потому что если у заказчика есть люди, готовые работать по-другому, то даже если это «по-другому» сначала окажется кривовато реализованным, оно рано или поздно наладится. И наоборот — даже отличная реализация будет в короткие сроки убита банальным нежеланием работать со стороны руководителей.

    И темп мне кажется разумным. Это не медленно, я бы так и делал — надо успевать перестраиваться под новые правила, а не просто регламенты процессов в стол пачками складывать. Есть другие «горячие» и к сожалению абсолютно реальные примеры из серии «6-7 процессов за год». Успехи в реализации таких лозунгов мягко говоря не впечатляют.

    Так что я за VAA 🙂

    0
    0

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ДЕК
18
Учебный курс:
Основы DevOps
ДЕК
20
Учебный курс:
Основы ITIL (очно)