Портал №1 по управлению цифровыми
и информационными технологиями

Реальная модель зрелости процессов

Голова пошла кругом от PAM, CMMI и прочих моделей. Чтобы вернуться в реальность, я попытался честно ответить себе на вопрос — зачем вообще повышать зрелость процессов? Решил поделиться ответом с вами =)

Я вижу всего 4 последовательных и значимых уровня зрелости ИТ-процессов:

  • Не-процесс. Когда работа просто выполняется. Документации нет или её мало или она устарела. Отчётность составляется от случая к случаю, для "разбора полётов". Автоматизация лоскутная, возможно, дорогими "микроскопами".

Такой "процесс" есть у всех: работа просто выполняется.

  • Дорогой процесс. За него мы платим экспертам "на зарплате", внешним консультантам или вендорам. Есть вся документация и формы отчётов, за которые заплатили. Причём отчётность и реакция на её анализ уже заложены в регламенты и процедуры — пока этого нет, процесс Дорогим не станет. Автоматизация поддерживает процесс. 

Дорогой процесс обычно нужен тем руководителям, кто хочет продемонстрировать кому-либо зрелость ИТ-организации. После демонстрации Дорогой процесс чаще всего начинает деградировать к "не-процессу". Получить Настоящий процесс, не пройдя этап Дорогого, увы, нельзя.

  • Настоящий процесс. Соответствующим духу книг и аудируемым (по ISO 20000) становится Дорогой процесс, если о нём долго никто не забывает после внедрения. Появляются доказательства существования процесса: например, артефакты и протоколы. На этом уровне появляется осведомлённость о процессе и работает система мотивации на основе процессных метрик. Автоматизация поддерживает изменения в процессе.

Настоящие ИТ-процессы нужны только если их результаты критичны для бизнеса: в ИТ-службах медицинских и военных учреждений, в банках, в ИТ-интеграторах, а также в романтических коммерческих организациях.

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

Развивать процесс до уровня звезды следует исключительно крупным поставщикам ИТ-услуг, которые испытывают значительное давление со стороны конкурентов. Процессы-звёзды будут создавать конкурентные преимущества для такой организации. Делать звёздами стоит только высокоуровневые процессы: управление доступностью, мощностями, спросом, отношениями.

Ещё не продумывал детально, подходит ли такая классификация к процессной деятельности вообще, но в ИТ, похоже, укладывается.

Расскажу подробнее и буду благодарен за критику в комментариях!

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

Комментариев: 15

  • «Делать звёздами стоит только высокоуровневые процессы: управление доступностью, мощностями, спросом, отношениями.»

    Интересно. Почему так?

    • Я находился под впечатлением от комментария Яна ван Бона здесь blogs.forrester.com/steph...nt#comment-14751

      Ян пишет, что большинство верхнеуровневых процессов ITSM — это просто ипостаси управления рисками. И мне кажется что управлять рисками стоит на как можно лучшем уровне, в т.ч. и проактивно.

      А получить отдачу от самосовершенствуемого процесса управления сервисными инцидентами... я даже не очень понимаю, как это сделать рентабельно... Закопался, да?

      • Для меня совершенствование — вполне практичное понятие. И к управлению инцидентами применимо в той же мере, что и к тактическим процессам. Жизнь идёт, что-то меняется, требуется адаптировать классификаторы инцидентов (чтобы улучшить маршрутизацию и первичную диагностику), отчётность (чтобы фиксировать новые типы нарушений и стимулировать их предотвращение), нормативы (чтобы быть ближе к требованиям пользователей), базу знаний (чтобы быстрее решать новые повторяющиеся инциденты) и так далее.

        Совершенствование должно стать повседневной жизнью процесса, оно же должно стать основной деятельностью менеджера процесса (вместо того, чтобы бегать и решать конфликты, как на ранней стадии работы процесса).

        А для того, чтобы это не превратилось в «процесс ради процесса», нужны критерии необходимости улучшений. И они должны базироваться на качестве предоставляемых услуг, на удовлетворённости их потребителей.

        Поэтому поднять уровень организации операционных процессов выше 4 (по традиционной шкале) без рабочего сервисного подхода едва ли возможно. Поэтому уровни процессов, начиная с 4, начинают зависеть друг от друга и создать изолированный процесс на уровне 5 так же невозможно, как коммунизм в отдельно взятой деревне.

        • На уровне Настоящего процесса совершенствование осуществляется именно в описанном вами виде. Но — на основании периодического анализа отчётности.

          А вот на уровне звезды я подразумеваю совершенствование не по результатам (check-act) работы процесса, а некое, так скажем, изобретательство. К основным входам в процесс добавляются триггеры, не влияющие на выходы напрямую: информация от поставщиков, информация о грядущем финансовом кризисе, рационализаторское предложение об упрощении бланков и т.п.

          Мне кажется, что постоянное совершенствование управления инцидентами редко бывает вообще возможно: менеджер процесса всё равно бегает и решает заявки, работает MIM'ом, ведет регулярные и запланированные улучшения, короче — с трудом поднимает голову от рутинной работы.

          • Вадим

            постоянное совершенствование управления инцидентами редко бывает вообще возможно: менеджер процесса всё равно бегает и решает заявки, работает MIM'ом, ведет регулярные и запланированные улучшения, короче — с трудом поднимает голову от рутинной работы

            горько и больно это слышать мне ©

            менеджер должен управлять, а не бегать! процесс должен быть построен так, чтобы не менеджер участвовал в решении заявок, а по некоторым критериям оценивал ситуацию и, например, изменял график работы сервисдеска или изменял количество операторов или направлял их на обучение и тд и тп. вот это его рутина: откуда новых операторов взять, как быстро их обучить, а не заявки отрабатывать.

  • Peshkov Alexander

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

    • Александр — я написал выше. Пожары и так идут постоянно. Я сомневаюсь что в нормальной организации (с бодрым потоком инцидентов) будут ресурсы на обозрение всей карты пожаров постоянно.

      • Peshkov Alexander

        Мое мнение сводится буквально к следующему: «вместо того, чтобы тушить постоянный пожар, нужно перекрыть шланг, из которого хлещет бензин». К процессу управления инцидентами и запросами это применимо в той же мере, как и к остальным процессам. Всегда есть, что улучшать — скорость доставки (точность уже не улучшить после того, как она достигла 100%, а это несложно), скорость взятия в исполнение, качество исполнения, качество заполнения Решения, информированность пользоватлей о правилах работы со Службой поддержки, информационные рассылки о перерывах в работе сервисов и тд.

        Задача менеджера процесса как раз и заключается в Check и Act, он не должен сидеть с огнетушителем и ждать, когда загорится, он должен постоянно с микроскопом наперевес искать места возможного снижения уровня сервиса.

        • ...вот Дмитрий выше хорошо сказал: "для того, чтобы это не превратилось в «процесс ради процесса», нужны критерии необходимости улучшений. " Тот факт, что «всегда есть, что улучшать» не является достаточным условием для того, чтобы бежать улучшать. Часто лучше, чем нужно, — не нужно. Это и называется рациональностью. Поэтому менеджеру процесса стоит время от времени откладывать микроскоп и соотносить свою работу с целями, а не только с возможностями.

          • Peshkov Alexander

            Роман, согласен. Постановка вопроса подразумевает обзор пожарища и принятие решений о том, что нужно, а что не нужно. Такие решения должны приниматься совместно с SLM, и тогда, в итоге, выходит, что ДА, можно улучшать процесс управления инцидентами и извлекать из этого пользу для бизнеса. «Выше скорость доставки = своевременее предоставление услуги = возможность клиенту возобновить свои бизнес-операции без финансовых потерь» и тд и тп. Вобщем, Настоящий процесс в вышеописанной классификации. Кстати, такой процесс нужен не только в романтических коммерческих организациях, но и на самых обычных производствах, потому что там «нет ЕРП = нет отгрузки со склада = есть финансовые потери», да еще куча примеров, когда организации нужен Настоящий процесс. Другой вопрос — насколько это оправдано. Если потери при отгрузке больше стоимости оптимизации процесса, тогда такая оптимизация будет нерациональной. Практика показывает, что организации сферы производства, логистики, ИТ-провайдеры (и думаю, многие другие) стремятся к 100% доступности своих систем, т/е стоимость простоя выше стоимости оптимизации процессов.

  • Вадим

    Ян не зря пишет про риски. зрелость определяется способностью их увидеть и что-то с этим сделать...

    К тому же некоторое время назад была издана модель CMMI for Services, которая, кстати, здесь тоже обсуждалась. Там вроде все было понятно: есть такой-то набор процессов — значит такая-то зрелость, раз такая зрелость, то следующими шагами-процессами для достижения следующего уровня будут такие-то.

    Но здесь в классификации какая-то, пардон, несуразица, с ad-hoc все более-менее понятно — наверное каждый либо сам через это состояние проходил, либо видел у других. А с остальными — IMHO беда, и связано это с нерассматриванием цели, для чего это все нужно выстраивать.

    От себя могу внести следующие «коррективы» в «модель» c точки зрения понимания делателей:

    0. ad-hoc

    1. осознание неправильности (возникает после курсов, чтения книг на тему, общения к кем-то знающим)

    2. книжные улучшения (самостоятельные, а иногда не только, попытки построить работу по книжке — обычно неудачные)

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

    4. просветление (в результате которого наконец появляется работающая модель, причем модель, безусловно, процессная, и не обязательно ITIL'овская)

    P.S. Кстати, в ИТ-интеграторах, по крайней мере, внутренние ИТ процессы нельзя отнести к «настоящим», обычно они оставляют желать лучшего — сапожник, как известно, без сапог. Сказывается «заточенность» на зарабатывание денег вовне. А с «внешними» ИТ процессами, направленными на заказчика — все очень по-разному...

    • Но здесь в классификации какая-то, пардон, несуразица

      =)

      Вадим, вы, по-моему, точно воспроизвели модель Киркпатрика: www.realitsm.ru/2011/02/i...uchebnyj-proekt/

      Это именно так и есть в жизни практиков ITSM, вполне похоже на мою эволюцию и главное: ваших уровней 1-3 можно счастливо избежать, если в процессе чтения умных книжек осознать простую вещь: самое главное слово в ITIL — ADAPT. Адаптированием и будут заниматься те, кто делает Дорогой процесс.

      Я недостаточно структурировал свой полёт мысли: цели достижения уровня зрелости процессов у меня рассмотрены. Вторым абзацем в каждом пункте.

      • Вадим

        как говорится, фишечка в том, что модель зрелости процессов управления относится не к исполнению, а к управлению — менеджменту то есть, и даже в сторону governance.

        немного не понял фразу «Адаптированием и будут заниматься те, кто делает Дорогой процесс»

        что вы вкладываете в термин делает? «делает» — это тот, кто исполняет, грубо говоря внутренний ИТишник? или это внешний консультант?

        Если второе, то такой способ неработоспособен (нет, конечно консультант работу выполнит, процесс напишет, работу сдаст, деньги получит, но это неживая конструкция). А с внутренними ИТишниками тоже часто встречается засада: т.к. они исполнители — они редко могут ОРГАНИЗОВЫВАТЬ процессы, даже в собственной деятельности. Этому (а это и называется менеджмент) вообще-то нужно специально учиться... С виду получается замкнутый круг, но на самом деле это не так.

        • Делает — это эвфемизм для «внедряет».

          То что Дорогой процесс неработоспособен без исполнителей и управленческого воздействия на исполнителей — это само собой... Если управленческое воздействие успешное — то процесс станет Настоящим.

          • Вадим

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

            во всех остальных случаях цена такому внедрению не очень высокая, разве что с точки зрения участников=исполнителей.


Добавить комментарий для Роман ЖуравлёвОтменить ответ

Ваш адрес email не будет опубликован.

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Внедрение ИИ для вашей службы поддержкиВнедрение ИИ для вашей службы поддержки
      Но что на самом деле означает внедрение ИИ для возможностей ITSM вашей организации, особенно для службы технической поддержки?
    • Бесплатная конференция IT-Entrance для тех, кто хочет стать айтишниками
        28 мая в Минске пройдет бесплатная 11-я международная конференция IT-Entrance. Это мероприятие для тех, кто хочет попасть в IT, для начинающих IT-специалистов уровня junior с
    • ITIL 4 Specialist: High-velocity IT. Что внутри?
      В дополнение к уже опубликованным обзорам курсов по направлению Managing Professional (MP) сертификационной линейки ITIL4, сегодня мы рассмотрим еще один модуль – ITIL 4 Specialist: High-velocity IT (HVIT).
    • Весення уборка в бэклоге продукта: порядок за четыре шага!
      Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы. 
    • Warranty и Utility в ITIL4
      У услуг, которыми мы управляем в рамках Service есть две основные характеристики: гарантия — Warranty и Utility — полезность. Эти характеристики нужны нам, чтобы определить, будет ли услуга способствовать достижению результатов, которые нужны пользователю, а как следствие — создавать для них ценность.
    • Шесть практик для лучшего взаимодействия бизнеса и ИТ
      Хотели бы вы, чтобы руководители предприятий и ИТ могли лучше работать вместе, совместно работать над проектами и в полной мере обмениваться информацией? Если вы похожи на большинство ИТ-руководителей, ответ — да. Преимущества эффективного сотрудничества между бизнесом и ИТ включают в себя специальные проекты, которые лучше соответствуют бизнес-целям, улучшенное управление изменениями и более активное участие в новых инициативах.
    • Используйте технологии для повышения эффективности рабочего процесса вашей ИТ-команды
      Эффективное рабочее место создает, так сказать, хорошо смазанную машину, повышая итоговую прибыль и, как следствие, успех вашего бизнеса. Дополнительное время на работе не всегда означает большее достижение. Важно то, что вы делаете с тем временем, которое у вас есть, а это все об эффективности рабочего процесса.
    • Хранение данных и «внутренний хомяк»
      Хранение информации, которая больше не пригодится, сопряжено со огромным количеством рисков. Иллюстрация этому — череда сливов персональных данных пользователей крупных сервисов, которую мы могли наблюдать с января по март. Кажется, что предприятиям нужны правила, когда и как избавляться от данных.
    • Action BiasAction Bias — известная ловушка, в которую мы всё равно постоянно попадаем
      Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.
    • бэклог27 антипаттернов бэклога продукта
      Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT