8.2.Какие риски бывают в проекте внедрения ERP-системы

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

Риски границ проекта:

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

Риски со стороны заинтересованных сторон:

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

Технические риски:

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

Организационные риски:

• Обучение пользователей и отторжение ими системы. Мотивация и эмоциональная составляющая проекта внедрения и ожиданий от системы сотрудниками, которым с этим работать дальше.
• Саботирование работ сотрудниками заказчика. Игнорирование административных процедур, прикрываясь другими задачами, неучастие в обучении и опытной эксплуатации. Без полноценных и своевременных данных система не сможет работать: «Мы не работаем в системе, т. к. в ней ничего нет» – порочный замкнутый круг, в системе ничего не будет, если в ней не начать работать.
• Нет времени у пользователей на изучение системы. Подразумевается, что проект идет фоном к основной работе сотрудников, но, чтобы стать пользователями, они должны приложить определенные усилия, иметь запас времени на знакомство с системой.
• Пользователи не могут пройти аттестацию (не изучают систему, не хватает квалификации). Итерации на аттестацию, сдвиги сроков или повышенная нагрузка на поддержку в момент начала работ пользователей без должных навыков, риски неверных данных.
• Начальные данные в текущей системе имеют недостаточную детализацию или ошибки, сложности с инициализацией данными внедряемой системы.
• График оплат и его соблюдение. Исполнитель, живущий за счет финансирования выполняемого проекта, несет риски своевременности поступления платежей (это при успешных и вовремя закрытых актами фазах проекта). Возникновение кассовых разрывов и задержки в оплате сотрудникам могут повлечь потерю квалифицированного персонала (не будут без оплаты работать).
• Усталость и демотивация специалистов. В попытке уложиться в сроки – длительный период авралов и сверхурочной работы, потеря внимательности, рост вероятности ошибок; эмоциональные реакции, межличностные конфликты.
• Наложение периода выполнения фаз проекта на сезон отпусков или болезней: связанные задачи сдвигаются по цепочке, ждут исполнителей или перепоручаются другим исполнителям, которым задачу делать сложнее – нужно больше времени, ниже качество.
• Утверждение технических заданий «не читая». Не выделяется достаточно времени (или, скорее, внимания специалистов, т. к. календарно времени может быть достаточно) на согласование документации проекта, затягивается процесс согласования. Формальное согласие с ТЗ по принципу «потом в процессе работы доделаем, как нужно». Задержки согласования со стороны заказчика приводят к простоям специалистов исполнителя.
• Отказ от согласованных технических заданий, по которым ведется (или уже завершена) разработка. Запросы на изменения функциональности (уровня «без этого мы работать не будем»), по которой уже прошло обучение и которая перенесена на рабочую базу и готова к работе.
• Риск привнесения ошибок в рабочую базу, если не разделены базы на разработку-тестирование и работу.
• Функциональные разрывы и противоречия в требованиях: системный архитектор не анализирует концептуальные проекты от разных консультантов по разным блокам, но конфликты возможны на стыках (общих справочниках и документах).
• Регрессионное тестирование при постоянных доработках не может завершиться, приходится начинать заново, тесты (тем более ручные) не могут пройти. Альтернатива – вообще нет регресс-тестирования, запускаем «кота в мешке», что само по себе риск.

Риски внешних условий. На что, как правило, нет возможности повлиять со стороны управления проектом внедрения – работаем с тем, что есть:

• изменение законодательства;
• доступность квалифицированного персонала;
• территориальная структура организации заказчика;
• природные явления.

Отправить