Владимир Аврутин, [email protected]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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