Что же такое «неуспешность» и можно ли для данного понятия ввести количественные метрики. Можно ли оценить факторы, влияющие на неуспешность и как их учитывать в ходе проекта. В настоящей публикации предпринята попытка ответить на эти и другие смежные вопросы.

Владимир Аврутин, VAvrutin@topsbi.ru

Неуспешные внедрения IT проектов: неизбежность или управляемый процесс

Наверное, многие задавались вопросом: «Почему в публикациях, докладах, на форумах и просто в разговорах так много информации о неуспешных проектах внедрения ERP – систем?» Иногда информация носит просто детективный характер с намеками на «месть» IT подразделений и компаний – внедренцев. Часто высказывается мнение о предопределенности неуспеха при внедрении ERP – систем, особенно «тяжелых» как следствие будто бы их «органической порочности».

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

Что такое «неуспешный проект»?

Очевидно это субъективное понятие, определяющее разность между конечным результатом внедрения и априорными представлениями о результатах внедрения (так называемые ожидания). С точки зрения Исполнителя успешность проекта, как правило, определяется степенью соответствия  его результатов c требованиями Технического задания (ТЗ). С точки зрения Заказчика успешность проекта определяется полнотой решения тех задач, ради которых проект, собственно, и планировался.

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

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

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

Внимательный читатель может задать вполне уместный вопрос: «а почему не рассматривается процесс управления ожиданиями заказчика?». Ответ прост. Да, управление ожиданиями заказчика позволит решить коммерческие аспекты проекта, но не снимает диссонансных явлений заказчика, анализу которых собственно и посвящена настоящая статья. Возможность доказать Заказчику, что он получил то, что хотел, относится, скорее, к области фантастики.

Факторы неуспешности

Какие же факторы и как влияют на неуспешность:

  1. Неточность в описании бизнеса Заказчика «как должно быть» на стадии формирования ТЗ.
  2. Существенные изменения бизнеса в ходе реализации проекта.
  3. Недостаточная эффективность управления изменениями в рамках заданных сроков и стоимости проекта.

Неточность описания бизнеса Заказчика обуславливается рядом субъективных и объективных причин. Рассмотрим эти факторы подробнее.

Основной объективной причиной является недостаточная детализация описания бизнес-процессов и неточная спецификация бизнес-операций – систематическая ошибка, возникающая практически при любой методологии описания бизнес-процессов.

К субъективным причинам можно отнести следующие:

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

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

Просто удивительно с какой настойчивостью заказчик иногда стремится решить свои бизнес-проблемы в рамках проекта внедрения ERP – системы: «Вот внедрим систему и заживем припеваючи».

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

Очевидно, что неправильная оценка «точки входа» пораждает существенные проектные риски. Таким образом уже на стадии формирования ТЗ закладываются расхождения между текущим пониманием бизнеса Заказчиком и Исполнителем.

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

Опытный консультант обычно еще на допроектной стадии определяет тенденции развития бизнеса Заказчика и планирует мероприятия по обеспечению успешности проекта.

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

Что касается управления изменениями в ходе проекта, то его эффективность ограничена рядом факторов:

Минимизация метрики неуспешности

Единственным способом минимизации метрики неуспешности является управление всеми вышеперечисленными факторами. Рычаги управления очевидны:

  1. Сформировать прогноз метрики неуспешности и психологической границы неуспешности. Определить организационные способы управления рисками неуспешности и зафиксировать их в Уставе проекта.
  2. Оценить «точку входа» в проект. При необходимости, рекомендовать заказчику провести предварительные проекты консалтингового характера. Целесообразно предложить заказчику выделить начальные стадии проекта внедрения в отдельный проект, в рамках которого уточнить функциональный, организационный и географический охваты проекта, стоимость и сроки проекта.
  3. Использовать для описания и моделирования бизнес-процессов методологии, нотации и средства, позволяющих описывать бизнес-процессы с требуемой степенью детализации. Бизнес-операции должны быть специфицированы с детальностью, исключающую неоднозначное трактование. Для бизнес-операции крайне желательно привести входящие и исходящие документы, алгоритмы и расчетные формулы и указать роль пользователя, ее выполняющего. Для каждой бизнес-операции должно быть указано место ее реализации: в системе или вне ее. Для отчетов должен быть приведен алгоритм формирования всех полей, обязательно наличие шаблонов.
  4. Заранее определить и согласовать список владельцев бизнес-процессов, заинтересованных лиц и исполнителей. Определить их роли и интересы в автоматизируемых бизнес-процессах. Реализовать действенную систему управления требованиями Заказчика по схеме 80/20.
  5. Достичь принципиальной договоренности со спонсором проекта о порядке внедрения «от бизнеса». Оценить степень готовности Заказчика на реинжениринг бизнес-процессов и принятие правил ведения бизнеса, заложенного в средстве автоматизации.
  6. Оценить динамику развития бизнеса Заказчика и максимально учесть ее в описании бизнеса «как должно быть». Для проектов, где предполагается существенные изменения в схемах ведения бизнеса, необходимо предусмотреть дополнительные ресурсы.
  7. Ввести реальную этапность проекта с фиксацией этапов по бизнес-срезам.
  8. Ввести в состав проектной команды опытных сотрудников с ролями «Контролер качества» и/или «Внутренний аудитор».

Напрашивается тревиальный вывод: Для минимизации рисков неуспешного внедрения необходимо и достаточно ответственного Заказчика, опытных внедренцев и современной методологии внедрения. Как говорится: «что и требовалось доказать».

С известной долей оптимизма можно констатировать, что на рынке внедрения ERP-систем  появляются компании, удовлетворяющие самым высоким требованиям к качеству проектной деятельности. Будущее, как говорится, за ними.

Заключение

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

Владимир Аврутин, VAvrutin@topsbi.ru