Критерии выбора поставщика ERP-проекта

Источник: блог Владлена Березина на сайте ko-online.com.ua

Название темы отражает мою позицию по критериям выбора ERP для себя - не выбор ERP-системы, а выбор ERP-проекта. Разница принципиальна. Об этом ниже...

При попытке выбора ERP-продукта (собственно - системы) принимаются во внимание факторы, которые выбирающий де факто не может оценить. Что за факторы?

1) Стоимость

2) Функциональность

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

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

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

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

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

Этого достаточно? Нет, конечно... Что упущено в данном подходе? Ответ - все, что связано с самым рискованным элементом - самим проектом внедрения.

Принципиально другой подход - выбор ERP-ПРОЕКТА - рекомендую.

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

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

1) Наличие у компании-поставщика проекта системы управления проектами (методология, руководители проектов, процедуры, наборы документов, подход к планированию и ценообразнию).

2) Наличие у компании-внедренца персонала, способного выполнять работы по настройке и модификации ПО.

3) Опыт компании-внедренца по реализации проектов подобного типа.

4) Риски проекта, связанные, как с внутренними ограничениями (персонал, процедуры, модели учета), так и с внешними (ограничения по длительности, стоимости).

5) Функциональность (встроенная) ПО и возможность его изменения (это крайне важно для компаний среднего бизнеса).

6) Бренд разработчика ПО и количество РЕАЛИЗОВАННЫХ (не проданных!) проектов, например, в Европе и на Украине в частности.

Данный подход значительно меняет акценты с ПО на ПРОЕКТ, т. е. подвергает жесткому анализу сам проект, а не ПО, которое будет внедряться, потому что ПО и все, что с ним связано, является одним из элементов, причем, не критических, определяющих успех или провал любого ERP-проекта. И не забываем, что стоимость без учета проектных рисков есть пшик, а проект НИКОГДА не имеет 100%-ную вероятность (как и нулевую) успешного завершения.

Удачных вам всем проектов!