Формализованные подходы к внедрению ERP-систем

С точки зрения управления проектами, проекты внедрения систем управления ресурсами предприятия (ERP, Enterprise Resource Planning) никаких принципиальных особенностей не имеют. Но есть нюанс. В отличие от проектов строительства дома, корабля или моста, где результат работы достаточно нагляден, внедрение ERP-систем ведется незаметно для глаз, и результат становится доступен в момент старта системы. Учитывая, что ERP-проекты достаточно дороги (сотни тысяч долларов) и продолжительны (от шести месяцев до года и более) отсутствие очевидного результата заставляет заказчика изрядно понервничать. Тем более что многие проекты развиваются по следующему, достаточно известному сценарию:

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

К сожалению, такое развитие событий не столь уж редкое явление.

Для исключения подобной практики, снижения риска провала, сокращения сроков внедрения и возможности оценки проекта еще до момента начала внедрения, в мировой практике применяются формализованные подходы к ведению проектов внедрения ERP-систем.

Одним таких подходов, показавшим отличные результаты на практике, является методика ASAP, рекомендуемая компанией SAP AG при внедрении своей системы R/3.

ОСНОВНЫЕ ПОЛОЖЕНИЯ МЕТОДИКИ ASAP

Создание инструмента внедрения системы обусловлено несколькими целями:

• создание фундамента для эффективного использования системы SAP R/3 глубины и широты функциональных возможностей, гибкости и конфигурируемости (вместопрограммирования), высокой степени интеграции всех составляющих компонент;
• быстрое определение объемов и требований к проекту внедрения, четкое их соблюдение;
• завершение проекта в срок, в соответствии с бюджетом, с гарантированным качеством;
• учет «мягких» факторов (административные обстоятельства, руководство проектом, управление организационными изменениями, интеграция всех внутренних и внешних участников).

Методология внедрения ASAP содержит описание последовательности шагов внедрения проекта (маршрутной карты), базы знаний по проекту, инструмента внедрения и дополнительных сервисов.

Маршрутная карта (ASAP Roadmap) предписывает четко определенные этапы проекта внедрения, определяет цели проекта и каждого из этапов, набор завершающих документов по этапу и проекту, список решаемых задач.

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

Инструментарий внедрения (Implementation Assistant) содержит базу вопросов и ответов для обследования объекта внедрения, руководство по настройке системы и генератор профилей пользователей. Интегрируется непосредственно с системой SAP R/3.

Этапы проекта

Проект внедрялся двумя командами — командой консультантов и командой заказчика.

По мере внедрения происходит передача знаний от консультантов к ключевым пользователям, от которых знания передаются всем остальным пользователям. Наличие центров обучения в представительствах SAP позволяет сделать этот процесс более успешным.

Для реализации такой процедуры проект разбивается на несколько этапов, каждый из которых имеет свою цель и завершается созданием определенных документов.

Подобная организация снижает для заказчика риски провала, а для проектанта — риски неоплаты работ. Кроме того, наличие единой методики предоставляет заказчику возможность проводить независимый аудит проекта и, в случае возникновения недоверия к проектанту, передавать проект от одной внедренческой организации другой, что, соответственно, снижает риски для заказчика.

Далее кратко перечисляются цели каждого из этапов (или фаз) проекта внедрения. Также указаны основные документы, которые создаются для каждого из этих этапов.

Подготовка. Цель — первоначальное планирование и подготовка проекта R/3.

Создаваемые документы:

• устав внесения изменений — цели и задачи управления организационными изменениями;
• план проекта — это первый пункт, фокусирующийся на требуемых этапах и пакетах работ, детали в нем пока не рассматриваются;
• объем — задается первоначальное определение проекта, входные данные цикла сбыта;
• формирование проектной группы — назначение ответственных за проект;
• стандарты и процедуры — определение задач и методов выполнения проекта.

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

Создаваемые документы:

• анализ потребностей для каждой ссылочной структуры и определения SAP с помощью формуляров описания исходных данных клиента (используя базу данных вопросов и ответов);
• концептуальный проект — ключевой документ для следующей фазы, получается в результате работы с базой данных вопросов и ответов.

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

Создаваемые документы:

• определение бизнес-процессов и транзакций, которые должны быть реализованы в системе R/3;
• требования по конфигурированию и тестированию конфигурации;
• требования к внешнему программированию;
• учебные материалы для конечных пользователей — обучающие материалы и документация по бизнес-процессам.

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

Создаваемые документы:

• протоколы стресс-тестирования и объемного тестирования — для подтверждения возможностей аппаратного обеспечения в режиме продуктивной эксплуатации;
• план подготовки к продуктивному запуску — подробная информация по переходу к промышленной среде и запуску системы в промышленную эксплуатацию;
• протокол готовности системы к промышленному старту;
• приказ по предприятию о начале промышленной эксплуатации.

Эксплуатация и поддержка. Цель — переход от среды, ориентированной на проект, к предварительной продуктивной среде для успешной и эффективной эксплуатации.

Создаваемые документы: •

• протокол завершения проекта.

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

Процедуры проекта

База данных вопросов и ответов, поддерживаемая ASAP, может быть интегрирована с системой SAP R/3, получив непосредственное отражения в настройках ссылочного IMG (Implementation Management Guide, Руководство по внедрению).

Поскольку само IMG построено на основе иерархии стандартных бизнес-процессов, база вопросов и ответов построена по такому же принципу.

Ссылочная структура R/3 в базе данных вопросов и ответов (SAP Reference Structure) — это условное представление системы, которое является важным средством коммуникации для всех сотрудников компании, участвующих в проекте внедрения.

Оно позволяет:

• существенно упростить ознакомление с функциями и процессами R/3;
• уменьшить риск и сократить усилия, требуемые для выполнения анализа требований и выработки концептуального проекта.

Ссылочной структурой для пользовательской настройки является ссылочное IMG. В него включены все операции, которые необходимы для настройки системы R/3.

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

Диаграмма матрицы выбора процессов предоставляет альтернативный способ просмотра выбранных параметров объема проекта по каждой из сфер деятельности предприятия в базе данных вопросов и ответов ASAP. Вместо графического представления (управляемая событиями цепочки процессов, УСЦП) диаграмма показывает процессы, которые задействованы в сценарии сферы деятельности предприятия, или варианты процессов, задействованные в наборе выбранных вариантов сценариев. Диаграмма матрицы выбора процессов может оказаться полезной в качестве быстрого наглядного «контрольного списка процессов» при выполнении операций разработки концептуального проекта.

Вместо Diagram Explorer ASAP может интегрироваться с ARIS для R/3 (IDS), ERP modeler (CASE Wise), Life model (Intellicorp).

Ссылочное IMG содержит все операции пользовательской настройки, определенные в системе R/3. После рассмотрения бизнес-процессов в инструментарии внедрения настройки могут быть транспортированы в IMG для дальнейшего тестирования и развития.

Сценарии реинжениринга

Методология внедрения предусматривает проведение реинжениринга. Для этого проводится анализ бизнес процессов «как есть» и предлагаемого сценария ведения бизнеса. Между двумя сценариями лежит документ организационных изменений.

На практике часто эта часть проекта либо не проводится либо выполняется формально. Опыт показывает, что анализ бизнес-процессов демонстрирует заказчику, как будет протекать бизнес после внедрения, сколько необходимо рабочих мест, как будут определены бизнес-роли сотрудников.

Обсуждение с заказчиком схемы существующих и предполагаемых бизнес-процессов формирует документ организационных изменений компании.

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

Отсутствие анализа бизнес-процессов существенно снижает качество проекта, приводит к суете и неразберихе при продуктивном старте системы.

Основные типы реинжениринга

Существует пять основных типов реинжениринга при внедрении R/3:

• внедряются стандартные бизнес-процессы SAP и под них создается инфраструктура компании;
• проводится бизнес-процесс реинжениринг (БПР) и только потом внедряется система;
• БПР проводится как самостоятельный проект, исходя из концептуальных требований, на которых внедряется и SAP проект;
• БПР и SAP внедряются одновременно, с взаимным воздействием друг на друга;
• внедряется стандартная функциональность SAP. Производится оптимизация БП внедренной системы. Производится БПР компании под оптимизированные БП системы.

Проектная группа

Методология предполагает определение ролей участников в проекте: спонсор, руководитель проекта от консультантов, руководитель проекта от заказчика, ключевые пользователи, администраторы и т. д. (список довольно обширен).

Особые требования предъявляются к руководителю проекта, который является ключевой фигурой и практически определяет успех внедрения. Очень крупно повезет, если человек, который возглавит проект, будет личностью. Именно этот человек будет определять насколько удачно будут потрачены проектные средства, насколько приятным или драматичным будет весь процесс внедрения.

При распределении ролей между членами команды, что, как правило, делает руководитель проекта, следует учитывать типы людей:

(а) обучены, могут выполнять данную роль и хотят ей следовать;
(b) обучены, могут выполнять данную роль, но цельность натуры может быть недостаточной и зависеть от настроения;
(c) обучены, выполняли подобные работы, но данная роль является новой и результат вызывает сомнения, либо не обучены, но полны желания следовать роли;
(d) не обучены, новая незнакомая роль, но имеются все предпосылки для успеха;
(е) не обучен, не может и/или не хочет выполнять роль в проекте.

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

Распределение усилий и внимания со стороны руководителя проекта нарастает от типа (а) к типу (d), а последний тип (e) требует решения от руководителя: продолжать ли держать человека на проекте и уделять ему практически непрерывное внимание или исключить его из проекта.

Если исключить, то возникают новые две проблемы — кем заменить и куда деть (или чем занять) исключенного из проекта.

ПЛАНИРОВАНИЕ И ОЦЕНКА ПРОЕКТА

Планирование начинается с детального и максимально наглядного представления цели, с осознания того, что представляет собой момент завершения проекта, что значит завершение проекта для каждого из участников как со стороны команды консультантов, так и со стороны команды заказчика. Исходя из цели, определяется объем внедрения.

Четырехфакторное планирование. Планирование — процесс достижения цели, управляемый четырьмя составляющими: дата внедрения, трудоемкость (стоимость — производная от трудоемкости), функциональность (объем внедрения), качество.

Если дата внедрения определена договором, а трудоемкость определена целью, то задачей планирования проекта может стать правильное определение трудоемкости. В случае, когда ресурсов в необходимом количестве найти не удалось, то качество проекта — последний ресурс, которым придется пожертвовать.

Методология внедрения SAP R/3 предлагает план с детализацией работ и ориентировочными продолжи — тельностями этих работ. Перед руководителем проекта стоит задача доработать этот план в программу внедрения проекта.

При этом следует определить:

• идентификацию цели;
• наглядное представление цели (как выглядит завершение проекта, что действительно представляет собой проект, почему люди хотят внедрить проект, какие амбиции удовлетворит проект, как изменится уровень достатка участников и т. п.);
• список работ;
• последовательность работ;
• балансировку загрузки участников.

Хороший план предусматривает наличие запасной позиции, отсутствие которой может поставить весь проект под сомнение. Наличие многих запасных позиций нежелательно, это может дезориентировать. Если нужда заставит перейти на запасную позицию, тогда можно наметить новую запасную позицию, исходя из сложившейся ситуации.

Критерии оценки. Как бы не был хорош план, это всего лишь прогноз. А каждый прогноз имеет процент погрешности, и эта погрешность должна быть учтена в плане проекта (в виде резервного времени). Этот резерв может быть замаскирован (под видом всякого рода «анализов») или указан явно. В любом случае он должен присутствовать и, по мнению автора, составлять не менее 20% от критического пути.

Имеется ряд критериев, позволяющих оценить план проекта:

• цель определена;
• критерий завершения определен;
• критерии приемки определены;
• промежуточные этапы определены (как пример: подготовка проекта — 42%, концептуальный проект — 15%, реализация — 46%, заключительная подготовка — 19%, эксплуатация и поддержка — 8%);
• организационная структура создана;
• запасные позиции подготовлены;
• детализация шагов произведена (например, как диаграмма Ганта);
• загрузка участников распределена во времени;
• резервы времени созданы (20%);
• бюджет определен.

Анализ плана. Управление проектом заключается в анализе выполнения плана и адекватной реакции на происходящие отклонения.

Если отклонений нет — все хорошо. Наличие отставания требует немедленной реакции, так увеличение отставания на 5% каждый день может привести к отставанию на 50% через 10 дней (хотя в данном примере простые арифметические операции могут оказаться несостоятельными).

Каждое отставание анализируется по двум критериям: возможно ли нагнать упущенное или невозможно. В первом случае составляется план необходимых дополнительных мероприятий. Во втором случае производится перепланирование.

Если все резервы исчерпаны, предстоит тяжелая процедура выяснения ситуации с заказчиком. Поиски виновных — процедура для заказчика неинтересная, а для проекта неконструктивная. Если все же виновный очевиден, значит стоит пересмотреть распределение ролей в проекте.

Признаки состояния проекта. Хотя это может показаться наивным, из собственного опыта могу назвать косвенные, но весьма характерные признаки ухудшения или улучшения состояния проекта.

Положительные:

• люди ходят слегка самодовольно;
• доверие руководителю высоко;
• самочувствие великолепно и не зависит от условий работы;
• ощущение, что худшее позади;
• вера в собственные силы усилилась;
• меньше напряжения и раздражительности;
• больше розыгрышей и подшучивания;
• людям нравится в команде;
• планы выполняются.

Отрицательные:

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

Но самое настоящее преступление — знать о заложенной в проекте бомбе и скрывать это от всех.

Климат в проектной группе — последнее условие успеха, хотя строить проекты только на этом было бы безумием (хотя в период развитого социализма это было наоборот).

Контроль качества. Методика предусматривает формальный и неформальный контроль качества проекта. Формально — оценка уровня проработки предписываемых шагов на этапах проекта. Неформально можно оценить качество глубины проработки решений.

Оценка рисков. Методика ASAP предполагает оценку и анализ рисков внедрения. Оценка рисков предоставляется заказчику поэтапно — для принятия решений (в первую очередь продолжать или дорабатывать проект на текущем этапе).

ВЫВОДЫ

В рамках статьи невозможно познакомить с методикой ASAP в деталях, это лишь самые ключевые ее положения, дополненные рекомендациями из практики автора.

Опираясь на мировой опыт, можно утверждать, что методика ASAP дает высокий процент успеха в проектах внедрения SAP R/3. Все те случаи практических внедрений, когда соблюдались все рекомендации методики, оказались успешными. В большинстве неудачных внедрений имелись либо существенные отклонения от ASAP, либо в основе внедрения лежали иные методики.

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

Причина, как мне кажется, в недостаточном уровне или культуре менеджмента. Вторая причина — ничем не оправданная амбициозность руководителя.

Логичность и полнота методики позволяют снизить риски внедрения, главный из которых — человеческий фактор.

Об авторе:

Буренин Сергей Борисович — начальник отдела ERP-систем, корпорация "Инком".