Перейти к основному содержимому

Выбор ERP — требования, тендер и fit-gap

Аналитику Руководителю

С чего начинается выбор

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

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

Типичные нефункциональные требования к КИС:

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

Функциональные отвечают на вопрос «что должна делать система» (модули продаж, закупок, производства, казначейства, учёта и т.д.).

Критерии хорошей формулировки

КритерийСмысл
ПолнотаОписан сценарий целиком
ТочностьБез «прозрачной» и «гибкой» без метрик
ОсуществимостьТехнически возможно
НеобходимостьНе «хотелки» без владельца
ПриоритетЧто в первую очередь
ПроверяемостьКак примем на приёмке

На раннем сборе допустимы черновые фразы; перед тендером их уточняют. Пример проверяемой формулировки: «Отчёт по всем организациям за месяц строится не дольше 3 минут с разрезами X, Y, Z».


Тендер и запрос предложений

На рынке ERP выбор часто идёт через тендер. Цепочка документов может включать:

ДокументНазначение
RFIЗапрос информации — знакомство с рынком
RFPЗапрос предложения — требования и условия участия
RFQУточнение цены по выбранному варианту

В RFP передают спецификацию требований (часто по модулям ERP). Исполнители отвечают коммерческим предложением и заполненным fit-gap.

Нет требований — нет проекта

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

Дополнительно на этапе выбора проверяют нагрузочные тесты (типовой сценарий под число пользователей и объём данных), перспективный ИТ-ландшафт и обоснование окупаемости (ROI) автоматизации.


Fit-gap анализ

Fit-gap — сопоставление требований заказчика с возможностями конкретной ERP: где подходит (fit), где разрыв (gap).

Исполнитель (внешний или внутренняя команда) берёт таблицу требований из RFP и для каждой строки ставит оценку. Расширенный шаблон может включать столбцы:

СтолбецЗначение
ТребованиеКраткое описание
Приоритет1 (высший) … 10
ОбязательностьMust have на первом этапе
Из коробкиШтатная функция
НастройкаБез программирования
МодификацияНужна разработка
Стороннее решениеИнтеграция + лицензия
В roadmap вендораПоявится в версии
Не поддерживаетсяОграничение платформы
КомментарийПояснение оценки

Упрощённый вариант — два столбца fit / gap или шкала 0–10, но тогда нюансы («поддерживается, но только после доработки») уходят в комментарии.

Как заполняют: рассылка экспертам по блокам, совместный разбор в переговорной, уточнения у заказчика при двусмысленности. Заказчик потом сравнивает несколько систем по одной структуре таблицы.

Разница настройка и модификация критична для TCO: модификации проверяют при каждом обновлении платформы. Сторонние решения добавляют интеграцию и лицензии.

Пример фрагмента таблицы

Упрощённый фрагмент для модуля «Продажи» (одна ERP в тендере; для сравнения вендоров — те же строки, разные столбцы оценки):

IDТребованиеMustОценкаКомментарий
S-01Резервирование товара под заказ клиентадаНастройкаТиповой механизм резервов
S-02Скидка от объёма по 5 уровням прайсадаИз коробки
S-03Автоотправка КП на email из карточки заказанетМодификацияНужна интеграция с почтовым шлюзом
S-04Учёт серийных номеров при отгрузкедаНастройка + обучениеРедкая операция — проверить на ОЭ

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


После выбора

Выбранная система и исполнитель переходят в жизненный цикл внедрения. Требования из fit-gap становятся основой ИСР, оценок и плана доработок.

Для аналитика углубление в сбор требований и BPMN — в разделе Аналитика; EPC и ERP — в статье про нотации.

См. также

Другие статьи этого же раздела в боковом меню (как на странице "О разделе").