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

Роль контроля

Пример из практики. Создается промышленное предприятие, одновременно строится базовая инфраструктура – внедряются средства автоматизации производства, учетные системы Enterprise-уровня (ERP, CRM, BI), MES-системы (управление производственным процессом) и т. д. Реализуется сложная программа, где от координации действий всех вовлеченных сторон зависит общий результат. И вот на очередном этапе выясняется, что иностранный подрядчик по внедрению MES-системы свой участок работ не выполнил в плановый срок. Выправление ситуации и устранение выявленных дефектов займут несколько месяцев, но программа не прерывается – всё должно быть доведено до конца.

Из-за того, что никто не отслеживал ситуацию, она буквально свалилась на голову. Команде по внедрению придется резервировать свои ресурсы на весь период исправления недочетов – и всё это время должно оплачиваться каждому сотруднику команды. В ERP-команде, например, более 70 специалистов, стоимость которых крайне высока, в итоге простой в два-три месяца может вылиться в значительное удорожание всего проекта. И это только прямые убытки, не считая упущенной прибыли из-за переноса ввода предприятия в эксплуатацию.

Всего этого можно было избежать в случае надлежащих процессов контроля качества: зарождение проблемы было бы очевидным на самых ранних сроках для всех участников проекта – и заказчика, и подрядчиков по различным направлениям. Такая ясность всегда дает возможность смягчить последствия, а в идеале вовсе не допустить простоя и переноса сроков сдачи проекта. Например, можно было поднять приоритетность MES-направления, бросив на него дополнительные ресурсы, чтобы устранить разрыв с другими подрядчиками по срокам сдачи. Без КК же случилось то, что случилось.

Предлагаемый подход: «соучастник проекта»

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

Внешний КК, как правило, организуется через привлечение профильной экспертизы со стороны компании, которая обладает как минимум сопоставимым опытом внедрения аналогичных решений в той же отрасли, а также имеет опыт ведения контроля качества. Такие услуги обходятся недешево, однако применительно к проектам стоимостью от $5 млн подобные траты нельзя назвать необоснованными, учитывая цену возможных ошибок. Если проект стоит от $10 млн и выше, КК с привлечением внешнего игрока можно назвать обязательным условием успеха. Подобная формула применима к ИТ-проектам в любой отрасли – от нефтегаза, металлургии и химической промышленности до ретейла, банкинга и телекома.

Следует подчеркнуть также базовое требование к внешнему исполнителю КК, помимо релевантного опыта реализованных end-to-end-проектов в отрасли. Прежде всего необходимо, чтобы за его плечами был опыт работы с теми же решениями и технологиями, которые внедряются на контролируемом проекте, вплоть до конкретной версии продукта. Программные продукты в зависимости от версии могут отличаться коренным образом, и опыт внедрения условной «Платформы 2.0» при внедрении «Платформы 3.1» будет совершенно неприменим.

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

Организация процесса

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

Конечно, конфликты интересов и разногласия неизбежны. Проект крупного внедрения ИТ-системы может длиться не один год, пройти через такой срок интенсивной и сложной работы без разногласий не получится. Все острые вопросы нужно обговорить на встречах представителей команд через обмен информацией по проблемным участкам. Решение о путях корректировки потенциально опасных ситуаций должно приниматься коллективно, встречи необходимо проводить регулярно, а коммуникация сторон должна поддерживаться на постоянной основе. Все это важно для сохранения конструктивного диалога.

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

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

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

Отнестись со всей серьезностью

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

В свою очередь, примерно равные доли имеют низкая эффективность управления программой изменений при внедрении системы (9%), недостаточно четкие условия договора (8%), недооценка сложности решения и ошибки управления ожиданиями (7%). Негативную роль могут также сыграть недостаток опыта у руководства, нехватка ресурсов и навыков (5%), некорректные вводные и допущения (6%), незрелость вендорского решения (4%). Аккумулируясь в рамках проекта, эти факторы умножаются на его масштаб, что довольно быстро приводит к проблемам.

Например, недостаток квалифицированных кадров сегодня можно часто встретить в направлении «1С», где скачок спроса по понятным причинам пока не находит адекватного предложения услуг специалистов. Контролем качества в таких проектах невозможно спокойно пренебречь: исправления в готовом решении и простой из-за ошибок по отдельным направлениям обходятся гораздо дороже, чем затраты на организацию и поддержку КК-составляющей проекта.

Источник: IT World