Автоматизация управления компаниями

Слияния и поглощения. Поиск компании-цели | Главная | Организационные структуры и команда проекта внедрения ERP-системы

Октябрь 9, 2006

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    

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

    1. 3BEP пишет:

      Не согласен! Вероятность неудачи проекта легко определяется подбрасыванием монетки.

      Современная модель ведения бизнеса со стороны Исполнителя не позволяет проводить успешные внедрения. Цель любой компании - получение дохода. Правило 10/90(20/80) вроде никто не отменял. Итак успешной компанией-Исполнителем можно считать ту, которая выполняет только 10% работ. Дальше надо объяснять?

    2. beskov: Шаблоны описания бизнеса пишет:

      […] Денис Бесков-Доронин (beskov) wrote,@ 2006-10-10 10:05:00      Шаблоны описания бизнеса Вобщем-то очевдное наверное наблюдение, с которым я пока нигде не сталкивался в явном виде - специфичность для данного предприятия возрастает от 1 к 4:Модель предметной области (бизнес-сущности).Бизнес-правила.Модель информационных потоков.Модель бизнес-процессов.Т.е. если описания типа 1-2 могут в значительной мере быть общими для целой отрасли, то 3 и 4 - всё больше know-how (а скорее, просто сложившаяся система) конкретной организации.Отсюда “очевидно, что” можно достаточно эффективно и полезно создавать шаблоны моделей предметной области, то что называется традиционно (Domain) Analysis Patterns, и они будут полезны для любых проектов по созданию информационных систем в этой области, а вот модели бизнес-процессов в значительной степени более неустойчивы, т.к. зависят от множества факторов. И это на мой взгляд проясняет неуспешность многих проектов по внедрению ERP на основе использования заложенных в неё референтных (эталонных?) моделей, в добавок к организационным и квалификационным причинам, о которых говорит Рафаэль Инсапов.(Post a new comment) corneff 2006-10-10 05:36 pm UTC (link) Проблема еще в том, что разные предметные области довольно сильно пересекаются. И каждое предприятие может обладать целым набором предметных областей.Поясню примером бизнес-доменов для предприятия:1.

    3. êàðòà ðóìûíèè пишет:

      ðóìûíèÿ îòäûõ âåíóñ…

      îòäûõ â àâñòðèè…

    4. phentermine on line пишет:

      phentermine…

      phentermine capsules…

    5. medicine vasodilan пишет:

      vasodilan…

      classification of vasodilan…

    6. Анонимно пишет:

      feed…

    7. Системный анализ в IT » Blog Archive » Шаблоны описания бизнеса пишет:

      […] Отсюда “очевидно, что” можно достаточно эффективно и полезно создавать шаблоны моделей предметной области, то что называется традиционно (Domain) Analysis Patterns, и они будут полезны для любых проектов по созданию информационных систем в этой области, а вот модели бизнес-процессов в значительной степени более неустойчивы, т.к. зависят от множества факторов. И это на мой взгляд проясняет неуспешность многих проектов по внедрению ERP на основе использования заложенных в неё референтных (эталонных?) моделей, в добавок к организационным и квалификационным причинам, о которых говорит Рафаэль Инсапов. […]

    8. Немец пишет:

      Замечательно написано, но как говорится, для более точного представления нужно как минимум три источника :)

    Оставьте, пожалуйста, ваш комментарий