Модели СМК для проектной деятельности

Когда я говорю про СМК, я имею в виду систему качества, ко­торая адаптирована к выполнению определенных проектов.

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

Например, такая СМК может вообще не иметь руководства по качеству (а это существенное отклонение!) — его с большим ус­пехом может заменить репозитарий моделей всех БП компании (рис. 1.8). Уже давным-давно существует ПО ARIS (Architecture of Integrated Information System), где в электронной базе репозитария БП предусмотрены вся необходимая детализация и их ре­сурсное окружение вплоть до уровня рабочего места [8]. ARIS — это методология и базирующееся на ней семейство программных продуктов, разработанных для структурированного описания, анализа и последующего совершенствования БП (рис. 1.9).

Инструментальное средство ARIS Toolset представляет процесс в виде иерархии. Перекрестные ссылки, хранящиеся в репозита­рии, обеспечивают целостность и непротиворечивость архитек­туры процессов.

Модели процессов можно предоставлять в распоряжение дру­гим сотрудникам предприятия, участвующим в выполнении про­ектов. Эту возможность обеспечивают многопользовательские и сетевые функции ARIS. Причем отпадает необходимость в созда­нии положений о подразделении и специальных рабочих инст­рукций для персонала. Соответствующие права доступа пользо­вателя и привилегии гарантируют ему санкционированный доступ к нужным частям базы данных ARIS, и каждый сотрудник видит на своем компьютере только те процессы и функции, в которых он участвует, а руководители имеют всю информацию по данным мониторинга всех метрик и самих КПД. В такой СМК отпадает необходимость и в должностных инструкциях — все действия персонала «по умолчанию» уже расписаны в процедурах того же репозитария БП.

Такой СМК не нужна и процедура управления документацией (а это тоже существенное отклонение) — ее с большим успехом заменяет любая система электронного документооборота (там все уже предусмотрено: и индентификация, и прослеживаемость, и защита, и архивирование, и т. п.).

Корректирующие и предупреждающие действия в такой СМК уже встроены в механизм управления проектами в виде процедур управления проблемами и рисками, соответственно, они не нуж­даются в отдельных процедурах (и это тоже существенное откло­нение от требуемого стандартом ISO 9000 необходимого набора документированных процедур).

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

Поэтому для проектных компаний сертификация по ISO 9000 — мера вынужденная, так как заказчики о других стандартах на про­екты разработки ПО и внедрения ИС (описанных выше) просто ничего не знают, и всем проектным компаниям приходится втис­киваться в «прокрустово» ложе ISO 9000.

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

Качество выполнения, например, для ИТ-проектов [6, 9] скла­дывается:

• из определения требований потребителей к ИС или ПО;

• отображения требований на функциональность ИС или ПО;

• разработки и внедрения ИС или ПО с характеристиками, обеспечивающими соответствие установленным к ним тре­бований потребителя;

• поддержания характеристик, заложенных при разработке ИС или ПО при их внедрении в компании потребителя;

• технической поддержки внедренной ИС или ПО в течение их срока жизни с целью сохранения заложенных в них ха­рактеристик.

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

А именно управлению несоответствующей продукцией стан­дарт ISO 9000 уделяет особое внимание — он и заточен под то, чтобы заказчик получал продукт только установленного качества. И для заводов и фабрик это как раз то, что нужно.

Понятно, что для ИТ-проектов гораздо более уместно заказ­чику потребовать от компании соответствие модели управления именно проектами — например, РМВоК 2000 или более стро­гой — SPICE.

РМВоК создана именно для управления отклонениями имен­но в процессе выполнения проекта (a SPICE и Tick-IT вообще заточены под ИТ-проекты) и для повышения вероятности до­стижения запланированных в нем результатов [6].

Рассмотрим, например, необходимость четких должностных инструкций для персонала.

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

проектов, они все разные и завтра потребуются те навыки и зна­ния, которые просто не требовались в предыдущих проектах?

А вот процессу постоянного обучения и повышения квалифи­кации в ИТ-компаниях в этих обстоятельствах надо уделять го­раздо больше внимания, чем это требует ISO 9000: для ИТ-услуг это просто жизненно необходимая задача — ведь сами ИТ разви­ваются катастрофически быстро!

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

Рассмотрим совершенствование уровней качества потенциа­ла компании* — уровни КПК (рис. 1.10).

Для того чтобы добиться «мирового класса», компании необхо­димо разрабатывать СМК уже совсем по другой модели: «...и мы знаем эту модель» — СММ [3]. Уровни организации КПК по мо­дели СММ как раз полностью соответствуют необходимым уров­ням КПК.

Кстати, именно поэтому на Западе далеко не все ИТ-компании сертифицированы именно по ISO 9000 (например, Microsoft — кстати, СММ у него тоже нет).

Многим это и не нужно. Для них гораздо важней вместо ISO 9000 иметь хотя бы третий или лучше четвертый уровень СММ (рис. 1.11). '

А если отечественная компания, мобилизовавшись и затратив большие ресурсы, получит даже четвертый уровень СММ, то на какого нашего отечественного заказчика это произведет хоть ка­кое-то впечатление?

Ни на какого.

А вот ISO 9000 — «Это мы знаем!»

Теперь рассмотрим реализацию процесса управления каче­ством проекта.

* Термин введен автором.

Концепция управления качеством проекта

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

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

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

Кроме того, проектный бизнес имеет еще следующие обще­признанные особенности:

• интеллектуалоемкий характер предметной области боль­шинства проектов;

•сильная зависимость успеха проектов от поведения заказчика;

• повышенные риски нарушения сроков и бюджета, прекра­щения либо приостановки проекта;

• повышенные требования к качеству, имеющие конструктив­ный, то есть объективно проверяемый, характер;

• высокая степень индивидуализации под клиента и важное значение организации «плотной» работы с ним;

• быстрая потеря актуальности их результатов;

• высокая вероятность появления новых, ранее не выполняв­шихся работ, для которых методология, технология и сис­тема управления создаются «на лету»;

• высокие требования к квалификации менеджеров и испол­нителей, их высокая стоимость;

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

Высокая степень индивидуализации необходима просто пото­му, что невозможно загнать всех заказчиков в «прокрустово» ложе готовых решений вроде считающегося долгое время универсаль­ным SAP/R3. Это время проходит, сейчас заказчик не хочет ло­мать свои бизнес-процессы и подстраивать их под готовые ре­цепты. Ему нужны решения, которые учитывают его специфику, помогают создавать оригинальную продукцию и поддерживают удобный ему стиль управления. Только такой подход позволяет быстро находить гибкие и высокоэффективные решения..

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

Пример модели обеспечения качества проекта уже был пока­зан выше на рис. 1.5.

Пример концепции функционала управления качеством при реализации требований ISO 9000:2000 и РМВоК 2000 показан на рис. 1.12, а на рис. 1.13 соответственно представлен пример кон­цепции управления качеством проекта.

Для каждого конкретного проекта в соответствии с ISO 9001 и РМВоК [4,6] сравнительно нетрудно разработать логичный ком­плекс мер по обеспечению качества. Этот комплекс может быть оформлен как план обеспечения качества (Quality Assurance — QA[3]) (рис. 1.14). QA-план, как правило, является составной частью плана-графика всего проекта, но может выделяться и для больших проектов, и как самостоятельный план (подпроект).

Выполнение QA-плана и процедур управления качеством обыч­но приводит к удорожанию проекта на 10—15 %. И для больших и серьезных проектов это абсолютно оправданно — это как раз пример необходимого предупреждающего действия (я бы даже назвал мегапредупреждающего) для снижения риска высокой неопределенности при старте проекта.

Технически это прежде всего связано с постановкой и монито­рингом специальных процедур (по ISO, PMBoK или СММ), ко­торые, собственно, и обеспечивают качество проекта (рис. 1.15).

В то же время отказ от управления качеством вообще может привести к очень опасным рискам и даже к провалу всего проек­та. Это наиболее характерно как раз для больших проектов вне­дрения ERP-систем.

Возьму на себя смелость предположить, что широко публику­емый в литературе процент неудачных проектов (по разным дан­ным, от 78 до 84 %) является как раз следствием либо отсутствия, либо не выполнения QA-плана.

Рассмотрим отдельно роль и влияние планирования на обес­печение качества проекта.

Роль и влияние планирования на качество проекта

Внедрение всех типов интегрированных ИС является хорошим примером проекта, в котором как раз особое внимание необхо­димо уделять процессу планирования. Поэтому именно в таких проектах значение QA-плана возрастает многократно — напри­мер, в модели СММ предусматривается обязательное наличие QA-плана, разработка которого является ключевой практикой — Оценка (гарантирование) качества товаров и процессов (Process and Product Quality Assurance) [3].

И вот почему.

Попробуем проанализировать влияние результатов этапов, на­пример, проекта внедрения ИС Axapta на качество всего проек­та. Практика аудитов таких проектов показывает, что на качество проекта основное влияние оказывают именно начальные этапы: анализ требований, планирование (и создание QA-плана в том числе) и диагностика компании заказчика (рис. 1.16).

Теперь поговорим подробнее о технике планирования — самом важном с точки зрения управления качеством проекта.

Этап планирования является, по моему мнению, главным фак­тором, влияющим на качество проекта. На этом этапе определя­ются задачи, бюджет и сроки проекта. Довольно часто планиро­вание понимают только как составление графика работ, упуская из виду управление ресурсами, составление бюджета, управле­ние рисками и качеством (рис. 1.17).

Полноценная техника планирования на практике должна со­стоять из следующих этапов.

1. Определение целей проекта и их описание. Довольно часто проекты начинаются без четкой цели.

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

3. Для технологических стадий необходимо определить спи­сок задач, указать их взаимосвязи (последовательность) и прогнозируемую длительность (зависит от назначенных ре­сурсов).

4. Согласование вопроса о выделяемых проекту ресурсах. Следует отметить, что все ресурсы компании должны рас­пределяться централизованно. Довольно часто возникает ошибка планирования, связанная с тем, что некоторые де­фицитные ресурсы используются одновременно в двух раз­ных проектах в одно и то же время.

5. Анализ и оценка рисков. Это приводит к возникновению новых задач и к привлечению дополнительных ресурсов.

6. Цена ресурсов определяет бюджет. Одна из типичных оши­бок заключается в том, что бюджет назначают, не обращая внимания на прогнозируемую себестоимость проекта.

Бюджет, график работ и план управления качеством образуют формальный документ «План проекта».

Довольно часто некоторые из указанных документов отсутству­ют, что приводит к провалу проекта.

И на первом месте в обеспечении качества идет, конечно, ана­лиз рисков [3, 4, 6].

К сожалению, в России культура управления рисками в нефи­нансовой среде еще недостаточно развита, и именно из-за низ-

кой степени проработки проектных рисков терпят неудачи даже типовые проекты.

Сформулируем, что такое проектный риск. Надо согласиться, что это зафиксированная возможность возникновения потерь. А потери прежде всего сказываются именно на качестве.

Для конкретного проекта потери могут быть выражены в форме:

• недостаточного качества конечного продукта;

• увеличения стоимости проекта;

• превышения сроков;

• провала в достижении целей проекта.

Другими словами, риск — это проблема, готовая появиться.

Управление рисками — это процессы, связанные с идентифи­кацией, анализом рисков и принятием решений, которые вклю­чают максимизацию положительных и минимизацию отрицатель­ных последствий наступления рисковых событий [6, 9]. Процесс управления рисками проекта обычно включает выполнение об­щих процедур (рис, 1.18).

Как видно на рис. 1.18, все эти процедуры взаимодействуют друг с другом, а также с другими процедурами СМК и имеют раз­ное влияние на реализацию качества проекта.

Но риск — это только возможность, но не неизбежность по­терь — кто предупрежден, тот вооружен!

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

Неучтенный (или возникший в ходе выполнения) риск — это всегда потеря качества проекта.

Удивительно, но в большинстве случаев основные типовые про­ектные риски уже хорошо известны членам команды. Но большую опасность представляют те, которые не являются типовыми. Для идентификации этих рисков у нас, например, применяется экс­пертная оценка в форме «мозгового штурма» (рис. 1.19).

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

Посмотрим теперь пример результата идентификации воз­можных рисков для их дальнейшей оценки и управления ими (табл. 1.7)*.

Действительно, до начала работ зачастую неизвестно, что во­обще предстоит сделать в области оптимизации бизнес-процес­сов и последующих за этим организационных изменений.

Таблица 1.7 Идентификация возможных рисков**

* Пример заполненного после анализа шаблона матрицы управления рис­ками в уставе проекта. Текст в столбцах таблицы удален, так как это конфи­денциальная информация.

** Степени оценки вероятности: 4-ОВ — очень высокая, 3-В — высокая, 2-С — средняя, 1-Н — низкая.

Продолжение #

---------------------^——"——^—^^^ факторы риска	Оценка вероят­ности возник­новения	Влияние фактора риска на проект	Управ­ление риском	Послед­ствия влия­ния риска	Фак­тиче­ское состоя­ние
Риски, связанные с управле­нием проектом и поддержкой высшего менеджмента
Куратор проекта из числа высшего менеджмента не определен
Риски, связанные с целями и содержанием проекта
Неточное или неполное определение требований к...
Факторы риска	Оценка	Влияние	Управ-	Послед-	Фак-
	вероят-	фактора	ление	ствия	тиче-
	ности	риска на	риском	влия-	ское
	возник-	проект		ния	состоя-
	новения			риска	ние
Изменение первоначально
утвержденных требований к...
Риски, связанные срасписа-
нием проекта
Задержка сроков работ по на-
правлению... по вине заказчика
Сдвиг сроков проекта в связи
с запаздыванием начала про-
екта по оптимизации бизнес-
процессов
Риски, связанные с организа-
цией бизнеса
Отсутствие стратегии разви-
тия компании-заказчика
Изменение бизнес-процессов
заказчика и организации биз-
неса в связи с внедрением
системы
Риски, связанные с персона-
лом (проектной команды)
Недостаточная квалификация
сотрудников проектной ко-
манды от исполнителя в свя-
зи с уникальностью проекта
Не утвержден состав проект-
ной команды от заказчика
Риски, связанные со смеж-
ными проектами
Необходимость разработки
и поддержки интерфейсов
со смежными проектами

Таблица 1.7 (продолжение)

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

Вот именно системное планирование и реализация изменений в проекте — те обширные поля, «засеянные» многочисленными рисками процесса реализации проекта.

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

Практика проведения проектного аудита (более 100 выполнен­ных проектов) показала, что потери качества проекта происхо­дят в основном по одним и тем же причинам.

Предлагаю свой вариант распределения потерь качества в те­чение типового ЖЦ проекта внедрения ИС, например Axapta (рис. 1.21).

Вот почему QA-план в первую очередь (согласно ISO 9001) пре­дусматривает обязательный анализ результатов каждой фазы про­екта, прежде чем приступить к следующей.

Понятно, что реализации процессов QA необходимо обеспе­чить необходимое взаимодействие всех участников проекта. Для этого нужно реализовать правильную модель коммуникаций с за­казчиком [3, 4, 6, 9].

В целом пример необходимой модели организации взаимодей­ствия команды исполнителя и заказчика для обеспечения каче­ства проекта представлен на рис. 1.22.