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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Также очень важен уровень зрелости заказчика. Наивно было бы пытаться создавать развитый процесс управления уровнем услуг, когда заказчик не знает что такое SLA (Соглашение об уровне предоставления услуги (SLA) — это формальный договор между заказчиком (в рекомендациях ITIL заказчик и потребитель — разные понятия) услуги и её поставщиком, содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги), и не готов его обсуждать и подписывать.

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

· Критичность процесса для предоставления услуг.

· Текущий уровень зрелости.

· Уровень зрелости связанных процессов.

· Уровень зрелости потребителя услуг, и внешних поставщиков.

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

Дата добавления: 2014-01-07