Оценки зрелости процессов
Разработка архитектуры предприятия представляет собой сложный комплексный процесс, выполняемый в течение длительного срока – вообще говоря, в течение всего времени существования предприятия. Для его оптимальной организации необходимо обеспечить адекватное управление, которое, в свою очередь, должно базироваться на использовании определенных измеряемых параметров. Одним из таких интегральных параметров является понятие уровня зрелости процесса.
Уровни зрелости обычно определяются в соответствии с заданной моделью, которая описывает их иерархию и правила измерения (оценки), по которым можно, на основе изучения соответствия определенных характеристик процесса, отнести его к определенному уровню. Общепризнанное распространение получила модель уровня зрелости (Capability Maturity Model – CMM), предложенная Институтом системного инжиниринга (SEI) при Университете Карнеги-Меллона, прежде всего для оценки процесса разработки программного обеспечения. Все такие модели базируются на работах Кросби.
Предпосылками для создания этой модели явились прежде всего глобальные проблемы качества информационных систем, связанные с наличием большого числа дефектов программного кода, которые приводили к возникновению ошибок, сбоев и непредсказуемости работы приложений. Понятно, что наиболее критичным образом эти проблемы проявлялись в специализированных областях, прежде всего в военных системах и в научных расчетах, большая часть которых, опять же, была прямо или косвенно связана с решением военных задач. Однако бурное развитие информационных технологий с середины 50-х годов прошлого столетия привело к тому, что сейчас практически все аспекты жизни современной цивилизации немыслимы без применения компьютеров. Очередной скачок в понимании актуальности качества работы информационных систем был вызван появлением персональных компьютеров в начале 1980-х и резким увеличением числа разработчиков и пользователей. Другой аспект проблемы оказался связан с неудовлетворительной организацией управления проектами разработки программного обеспечения и с вытекающими последствиями в виде срыва сроков, превышения бюджета или даже отмены проектов. Хорошее описание возникающих проблем приведено в известных книгах Брукса [8.3] и Йордана [8.4]. Так что начало работы института SEI в данном направлении в 1986 году оказалось очень своевременным, а возможно даже слегка запоздалым.
Результатом работы SEI стало появление модели CMM для разработки программного обеспечения (версия 0.6 была опубликована в 1990 г., версия 1.0 – в 1991 г., версия 2 – в 1997 году). Для отнесения компании-разработчика программных систем к определенному уровню была предложена специальная система сертификации. По многим независимым оценкам, внедрение (подтвержденное соответствующей сертификацией) в организации практик, соответствующих высшим уровням модели, позволяет значительно повысить шансы на успешное завершение проекта – с типовых 30% до 85%.
Пожалуй, основной идеей CMM явилось понятие системы определенных Уровней Зрелости (Maturity Levels) процесса, которые охватывают набор так называемых ключевых областей (Key Process). В рамках CMM были определены 5 таких уровней, которые позволяют свести все многообразие вариантов организации процесса разработки к небольшому диапазону номеров уровней. Это позволяет решить первую задачу: обеспечить измеримость процесса в целом. Контролируемость и управляемость процесса определяются возможностями последовательного перехода с уровня на уровень при выполнении определенных условий.
Далее развитие стандарта в соответствии с пожеланиями основного заказчика проекта, Министерства Обороны США, продолжилось в рамках новой модели CMMI – CMM Integration. Обе эти модели очень схожи между собой по целям и подходам – обеспечение измеримости, контролируемости и управляемости процессов организации, но несколько отличаются в терминологии и структуре модели. При разработке CMMI использовались модели CMM для разработки не только программного обеспечения, но и других областей, так что CMMI служит, в определенном смысле, универсальным стандартом, который может применяться для управления качеством. Версия CMMI 1.1 была опубликована в 2002 году. CMMI, собственно говоря, является не описанием процессов, а скорее руководством по их разработке.
В рамках CMMI вводится дополнительная классификация более высокого уровня – разделение на непрерывную и поэтапную реализацию. Для непрерывной реализации вместо 5 уровней определяется 6, которые слегка отличаются по названию и содержанию от соответствующих уровней CMM – здесь вместо понятия уровня зрелости используется понятие уровня устойчивости. Вместо ключевых областей, определенных в CMM, в CMMI используется понятие областей процесса (process areas), которые направлены на достижение целей двух типов – общих (generic) и специфичных для данной системы.
В таблице 4.1 приведены сравнительные характеристики уровней зрелости для разработки программного обеспечения (в соответствии с моделью CMM) и поэтапной реализации в рамках CMMI.
| 1 | Начальный | Начальный (этот уровень присваивается по умолчанию) | Процесс разработки программного обеспечения спонтанен и во многом хаотичен. Успех зависит от индивидуальных способностей участников и не может быть повторен без их привлечения. Даже если созданные продукты работоспособны, проекты чаще всего существенно превышают заданные сроки и бюджеты |
| 2 | Повторяемый | Управляемый | Организация применяет методы лучшей практики для управления функциональностью, сроками и бюджетом проекта. Возможно повторное использование успешных решений |
| 3 | Определенный | Определенный | Процесс разработки документирован, стандартизован и утвержден. Процессы последовательно применяются в рамках всей организации |
| 4 | Управляемый | Управляемый количественно | Для процессов определены специальные метрики, которые позволяют количественно определить уровни организации и определить степень готовности продукта |
| 5 | Оптимизированный | Оптимизированный | Существует возможность предсказания результатов процесса и работоспособности продукта Производится постоянное усовершенствование процессов на основе анализа измеряемых результатов. Процессы направленным образом изменяются для достижения новых целей |
Достаточно содержательное введение в проблематику CMMI можно найти, например, в публикации [8.5].
Сама по себе CMMI не рассматривает многие домены архитектуры (данные, интеграция, безопасность, архитектуру ИТ-операций и т.п.). Кроме того, она приводит основные задачи (например, определить метрики для процессов), но не описывает, как именно нужно это делать, т.е. не содержит рекомендаций. Тем не менее, предложенный в рамках моделей CMM/CMMI подход оказался настолько удачным, что аналогичные шкалы уровней зрелости стали широко применяться и в смежных областях, которые не ограничиваются только разработкой программного обеспечения, – в том числе, управления поставками, кадровыми ресурсами или бизнес-процессами предприятия в целом (cм., например, http://www.bptrends.com).
Для наших целей наиболее интересно рассмотреть применение модели к оценке процесса разработки ИТ-архитектуры, а также процессов управления ИТ в организации – как в целом, так и для отдельных подпроцессов. Пример оценки зрелости процесса управления ИТ-активами более подробно будет рассмотрен далее.
