Модели зрелости организации (референс-модели). CMMI forDevelopment, уровни зрелости, основные процессные области

CapabilityMaturityModelIntegration (CMMI) [14] — набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности.

Включает: CMMI-DEV, CMMI-SVC и CMMI-ACQ. Версия № 1.3 вышла в ноябре 2010 года.

CMMI является развитием методологии CMM (SW-CMM), которая разрабатывалась со второй половины 1980-х годов SoftwareEngineeringInstitute (SEI), CarnegieMellonUniversity.

К настоящему времени в России понятие «зрелости организации» стало очень модным, в особенности для ИТ-компаний, хотя на Западе это понятие известно и используется около 30 лет. С другой стороны, если абстрагироваться от текущей «модности», то следует признать бесспорную эффективность этого понятия именно для России.

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

И действительно, даже в России известны разные модели зрелости:

SW СММ (CapabilityMaturityModelforSoftware), 1993 г. (появился в результате взаимодействия министерства обороны США и института SoftwareEngineeringInstitute — SEI);

модель ОРМЗ, 2003 г. (от сообщества PMI): определяет уровень зрелости по направлению управление проектами; существуют и иные модели, оценивающие зрелость в управлении проектами;

частично идеи зрелости содержатся в стандарте ИСО 9000 в версии 2000 года;

модель SPICE (Software Process Improvement and Capability determination);

стандарт ISO 15504;

CMMI интегрированная модель технологической зрелости;

модели зрелости консалтинговых фирм.

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

Уровень зрелости (оценка, балл) Характеристика уровня

Уровень 1 Начальный, нулевой уровень

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

Уровень 2 Уровень осознания

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

Уровень 3 Уровень управляемости

В организации задокументированы и стандартизированы все бизнес-процессы. Система управления оказывается отделенной от всего персонала организации, т.е. появляется внутренний «свод законов». Этим законам следует весь персонал организации, включая топ-менеджмент.

Уровень 4 Уровень измеряемости

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

Уровень 5 Уровень совершенствования

На основе анализа количественных показателей в компании проводится корректировка (реинжиниринг) бизнес-процессов. Коррекции отражаются во внутренних документах. Важно то, что процесс коррекции носит постоянный, системный характер.

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

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

9. Проектный процесс – гибкость или дисциплина. Выбор процесса:

• Правило 4”П” по Архипенкову

• Boehm’sstar: сравнение по 5 критическим факторам

Те, кто пытается следовать описанным в книгах моделям, не анализируя их применимость в конкретной ситуации, показания и противопоказания, уподобляются последователям культа «Карго» - религии самолетопоклонников. В Меланезии верят, что западные товары (карго, англ. груз) созданы духами предков и предназначены для меланезийского народа. Считается, что белые люди нечестным путём получили контроль над этими предметами. В наиболее известных культах карго из кокосовых пальм и соломы строятся точные копии взлётно-посадочных полос, аэропортов и радиовышек. Члены культа строят их, веря в то, что эти постройки привлекут транспортные самолёты (которые считаются посланниками духов), заполненные грузом (карго). Верующие регулярно проводят строевые учения («муштру») и некое подобие военных маршей, используя ветки вместо винтовок и рисуя на теле ордена и надписи «USA». Все это для того чтобы снова с неба спустились самолеты и этих предметов стало больше.

АлистерКоуберн, один из авторов «Манифеста гибкой разработки ПО» [14] проанализировал очень разные программные проекты, которые выполнялись по разным моделям от совершенно облегченных и «гибких» до тяжелых (СММ-5) за последние 20 лет [15, 16]. Он не обнаружил корреляции между успехом или провалом проектов и моделями процесса разработки, которые применялись в проектах. Отсюда он сделал вывод о том, что эффективность разработки ПО не зависит от модели процесса, а также о том, что:

 У каждого проекта должна быть своя модель процесса разработки.

 У каждой модели - свое время.

Это означает, что не существует единственного правильного процесса разработки ПО, в каждом новом проекте процесс должен определяться каждый раз заново, в зависимости от проекта, продукта и персонала, в соответствие с «Законом 4-х П» (Рисунок 4). Совершенно разные процессы должны применяться в проектах, в которых участвуют 5 человек, и в проектах, в которых участвуют 500 человек. Если продуктом проекта является критическое ПО, например, система управления атомной электростанцией, то процесс разработки должен сильно отличаться от разработки, например, сайта «отдохни.ру». И, наконец, по-разному следует организовывать процесс разработки в команде вчерашних студентов и в команде состоявшихся профессионалов.

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