Курсы в Москве

SCHEDULE Расписание курсов

ITILF Курс «Основы ITIL®»

COBIT5F «Основы COBIT 5»

OSA Курс «Service Desk и процессы оперативного управления ИТ-услугами в соответствии с ITIL®»

RCV Курс «Проведение изменений в ИТ в соответствии с ITIL®»

ITAM Курс «Управление ИТ-активами. Основы и практики»

PPO Курс «Оптимальное проектирование ИТ-услуг в соответствии с ITIL®: информационная безопасность, мощность, доступность, непрерывность»

ITHR Курс «Управление ИТ-персоналом»

COBIT ICS Курс «Система внутреннего контроля ИТ по модели COBIT(COBIT Internal Control System)»

SOA Курс «Управленческие инструменты организации отношений ИТ с бизнесом на основе ITIL®»

MALC Курс «Управление жизненным циклом услуг»

ITSS Курс «Управление стратегией ИТ-услуг на основе ITIL®»

ITILF Курс «Основы ITIL®» (Вечерний)

M_o_R Курс «Основы управления рисками по модели M_o_R®»

ITSO Курс «Эксплуатация услуг по модели ITIL®»

ITILF Курс «Основы ITIL®» (Вечерний)

ITPR Курс «Практика внедрения и адаптации рекомендаций ITIL®»

ITILF Курс «Основы ITIL®» Онлайн

ITILF Курс «Основы ITIL®» (Утренний)

OSA Курс «Service Desk и процессы оперативного управления ИТ-услугами в соответствии с ITIL®» Онлайн

RCV Курс «Проведение изменений в ИТ в соответствии с ITIL®» Онлайн

SOA Курс «Управленческие инструменты организации отношений ИТ с бизнесом на основе ITIL®» Онлайн

RCV Курс «Проведение изменений в ИТ в соответствии с ITIL®»

PRINCE2 Курс «Основы PRINCE2®»

PPO Курс «Оптимальное проектирование ИТ-услуг в соответствии с ITIL®: информационная безопасность, мощность, доступность, непрерывность»

SOA Курс «Управленческие инструменты организации отношений ИТ с бизнесом на основе ITIL®»

AWS Курс «Мастерская проектирования ИТ-решений»

ITMA Курс «Автоматизация управления ИТ»

ITSD Курс «Проектирование услуг по модели ITIL®»

ITST Курс «Преобразование услуг по модели ITIL®»

CSI Курс «Постоянное совершенствование услуг по модели ITIL® (ITIL Continual Service Improvement)»

Тренажер подготовки к экзамену ITIL Foundation
Страховой сертификат повторной сдачи экзамена
  • 31243

    Количество выданных сертификатов

  • 2754

    Количество проведенных игр и семинаров

Уровни зрелости управления ИТ

Мысль о зависимости бизнеса от ИТ уже весьма не нова, и не требует дополнительной аргументации. С увеличением этой зависимости руководство бизнеса предъявляет все возрастающие требования к эффективности управления ИТ. Один из показателей эффективности управления – зрелость системы управления.

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

Что такое процесс?

Согласно ITIL®, процесс – это структурированный набор видов деятельности, направленный на достижение определенной цели. Из этого определения следует, что если у ИТ подразделения есть пользователи, и у этих пользователей периодически ломаются компьютеры, то в ИТ есть процесс починки компьютеров. Или, "по научному" процесс Управления Инцидентами.

Этапы развития процесса

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

Первый этап мы уже рассмотрели: есть определенная цель (например, устранять инциденты) и есть определенные виды деятельности в разных подразделениях, ведущие к этой цели. Специалисты внутри различных подразделений должны взаимодействовать между собой. В жестко иерархической структуре все взаимодействие осуществляется через руководство. Однако, при такой схеме, начальник превращается из руководителя в диспетчера информационных потоков. Собственно на руководство времени не остается.

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

И это второй этап – появляются устоявшиеся практики, закрепленные договоренностями.

Однако, договоренности забываются, люди, их заключившие, увольняются, и т.д.

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

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

После того, как деятельность документирована и цель этой деятельности четко определена, встает вопрос: а как мы узнаем, что цель достигается, как померить, насколько мы близки к цели? И другой не менее важный вопрос: рационально ли мы работаем, оправдывает ли цель те средства, что тратятся на ее достижение?

Очевидно, чтобы ответить на эти вопросы необходимо ввести некие измеримые показатели. Иногда эти показатели называют Key Goal Indicator (показатели результативности) и Key Performance Indicator (показатели рациональности). Таким на образом, четвертом этапе мы добавили к нашей деятельности (или процессу) измеримость. А ведь нельзя управлять тем, что нельзя измерить.

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

Уровни зрелости

Итак, мы разобрали пять этапов развития процесса. Возникает вопрос: существуют ли формальные методики определения этапа развития процесса? Такие методики существуют и называются Моделями зрелости. Например, такая модель описана в методологии CobiT.

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

Зачем мерить зрелость?

Нужен ли нам формальный способ измерения зрелости? И если нужен, то чем он может быть полезен?

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

Использование, общепринятых в отрасли методик определения зрелости позволяет определить наше место по отношению к конкурентам.

Следующее, для чего это может быть полезно – определить риски связанные с теми или иными процессами. И, следовательно, риски в предоставлении услуг, поддерживаемых этими процессами. Чем более зрелый процесс, тем меньше рисков.

Важно понимать, что высокая зрелость процесса отнюдь не дает гарантии его эффективной работы в любой ситуации, но дает определенную, измеримую степень уверенности. Т.е. чем выше зрелость, тем больше вероятность того, что процесс эффективен. Оценка рисков может быть особенно полезна при планировании внедрения новых услуг. Например, компания планирует внедрять ERP систему. Встает вопрос: сможет ли ИТ служба оказать адекватную поддержку? Оценка зрелости – один из инструментов, позволяющих ответить на этот вопрос.

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

Как мерить зрелость?

Существуют различные методики оценки уровня зрелости. Например, в CobiT для каждого процесса предложена своя модель зрелости.

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

Оценка проводится путем опроса ключевых сотрудников. В некоторых случаях могут требоваться документальные подтверждения выполнения критериев.

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

Сама по себе измеренная цифра ни о чем не говорит. После того как мы определили текущую зрелость, надо ответить на вопрос

Какой уровень зрелости нам нужен?

Эффективность работы процесса, конечно, зависит от уровня его зрелости, однако, зависимость это не линейная.

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

При этом затраты на обеспечение зрелости растут тоже не линейно, а по экспоненте. Т.е. поднять уровень зрелости с уровня 2.5 до 3.5 стоит не очень дорого, а вот поднять зрелость с 4.8 до 4.9 стоит очень дорого. Это видно на графике ниже.

Уровни зрелости управления ИТ

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

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

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

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

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

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

Таким образом, можно сформулировать несколько критериев, определяющих целевую зрелость процесса.

Возвращаясь к управлению ИТ можно сказать, что деятельность по управлению – тоже процесс, зрелость которого складывается из зрелости всех поддерживающих процессов.

Консультанты IT Expert

Подробнее эта тема обсуждается на следующих курсах: Схожие вопросы затрагивались в следующих проектах:


Данная заметка отражает мнение автора, которое может не совпадать с уважаемыми первоисточниками (ITIL® v2, ITIL® v3, COBIT, MOF и проч.). Комментарии и предложения темы для следующей заметки можно отправлять на items@itexpert.ru.

Вверх

Закажите услугу обратный звонок, после чего наши менеджеры свяжутся с вами




CAPTCHA
*