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

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

Опубликовано 23 ноября 2011
Рубрики: Аналитика: точка зрения, Постоянное улучшение, Процессы
Комментарии

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

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

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

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

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

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

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

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

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

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

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

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

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

Также по теме:

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

  • Дмитрий Исайченко

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

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

    • Константин Нарыжный

      Я находился под впечатлением от комментария Яна ван Бона здесь http://blogs.forrester.com/stephen_mann/11-09-23-whats_the_problem_with_problem_management#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. Кстати, в ИТ-интеграторах, по крайней мере, внутренние ИТ процессы нельзя отнести к “настоящим”, обычно они оставляют желать лучшего – сапожник, как известно, без сапог. Сказывается “заточенность” на зарабатывание денег вовне. А с “внешними” ИТ процессами, направленными на заказчика – все очень по-разному…

    • Константин Нарыжный

      Но здесь в классификации какая-то, пардон, несуразица
      =)
      Вадим, вы, по-моему, точно воспроизвели модель Киркпатрика: http://www.realitsm.ru/2011/02/itsm-trensformaciya-kak-uchebnyj-proekt/
      Это именно так и есть в жизни практиков ITSM, вполне похоже на мою эволюцию и главное: ваших уровней 1-3 можно счастливо избежать, если в процессе чтения умных книжек осознать простую вещь: самое главное слово в ITIL – ADAPT. Адаптированием и будут заниматься те, кто делает Дорогой процесс.
      Я недостаточно структурировал свой полёт мысли: цели достижения уровня зрелости процессов у меня рассмотрены. Вторым абзацем в каждом пункте.

      • Вадим

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

        • Константин Нарыжный

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

          • Вадим

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

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.