Главная Случайная страница Контакты | Мы поможем в написании вашей работы! | ||
|
Когда я говорю про СМК, я имею в виду систему качества, которая адаптирована к выполнению определенных проектов.
Она может быть очень эффективной (высокая степень вероятности достижения всех запланированных результатов проекта) для конкретной ИТ-компании, но при этом иметь много отклонений (и подчас существенных) именно от модели 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.
Дата публикования: 2015-01-04; Прочитано: 508 | Нарушение авторского права страницы | Мы поможем в написании вашей работы!