ERP-систему и подрядчика выбирают в таком порядке: сначала предприятие описывает свои ключевые сценарии и требования, затем проверяет короткий список систем на этих сценариях, а подрядчиков сравнивает по одинаковому запросу — по тому, как они поняли задачу, кто конкретно будет работать, как устроены этапы, приёмка и изменения. Цену сравнивают последней, когда предложения приведены к одним границам. Главное решение фиксируется в договоре: если в нём нет критериев приёмки, состава команды и порядка изменений, выбор ещё не сделан.
Типичная картина: три интегратора провели презентации, все показали красивые экраны, цены различаются в разы, а руководителю нужно подписать договор на год работы. Сравнивать приходится впечатления, а не предложения. Разберём, как построить выбор так, чтобы сравнивались ответы на одни и те же вопросы.
Почему выбор часто проходит неудачно
- Выбирают систему по демонстрации поставщика. Стандартный показ проходит по сценарию продавца, и на нём хорошо выглядит любая зрелая система. Особенности предприятия остаются за кадром.
- Сравнивают цены разного объёма. Одно предложение включает перенос данных и интеграции, другое — нет; одно рассчитано на все площадки, другое — на пилот. Как привести их к одной базе, разобрано в материале «Сколько стоит и сколько длится внедрение 1С:ERP».
- Выбирают компанию, а работает команда. На переговорах — опытные руководители, в проекте — другие люди.
- Договор описывает часы и акты, а не результат. Приёмка «по акту» без рабочих сценариев — частая причина затянувшихся внедрений (см. «Внедрение ERP затянулось»).
Шаг 1. Описать сценарии и требования
До встреч с поставщиками предприятие фиксирует, что система должна делать именно у него.
- Цели и границы. Какие управленческие задачи решает проект, какие подразделения и площадки входят в первый этап, что точно не входит.
- Ключевые сквозные сценарии. Обычно их немного — от пяти до пятнадцати: например, «заказ клиента от приёма до отгрузки и оплаты» или «закупка под производственный заказ». Каждый описан шагами, участниками и документами, с реальными примерами предприятия.
- Требования с приоритетами. Что обязательно, что желательно, что можно отложить. Отдельно — особенности, из-за которых типовое решение может не подойти.
- Окружение. Какие системы остаются, с чем нужен обмен данными, какое оборудование подключается.
Если класс системы ещё не ясен — нужна ли ERP, отдельная MES или WMS, — стоит начать с материала «ERP, MES, WMS: что выбрать». А если сомнения в том, нужна ли ERP вообще, — с материала «Когда предприятию не нужна ERP».
Шаг 2. Проверить систему на своих сценариях
Короткий список — две-три системы. Каждую проверяют сценарным показом: поставщик или подрядчик проходит сценарии предприятия на его примерах, а не на своих.
| Что проверить в системе | Как проверить |
|---|---|
| Ключевые сценарии | Сценарный показ на примерах предприятия; по каждому шагу — «есть в типовом решении», «настройка», «доработка» |
| Объём и характер доработок | Список доработок с оценкой; как они переживают обновления системы |
| Отраслевые особенности | Есть ли отраслевое решение и где оно уже работает; что в нём придётся менять |
| Обмен с другими системами | Какие обмены есть готовыми, какие придётся разрабатывать |
| Масштаб | Число пользователей, документов, площадок; на чём это проверено |
| Лицензии и инфраструктура | Состав лицензий, требования к серверам, стоимость владения после запуска |
| Требования к российскому ПО | Если предприятие обязано применять российские программы, проверяют наличие системы в едином реестре российских программ для ЭВМ и баз данных; требования уточняют у юриста |
| Специалисты на рынке | Насколько легко найти исполнителей для сопровождения, если подрядчик сменится |
Отметка «доработка» не делает систему плохой. Важно, чтобы доработок было разумное число и чтобы они касались действительно особых участков, а не того, что предприятие могло бы делать по типовой схеме.
Шаг 3. Отправить подрядчикам одинаковый запрос
Подрядчикам передают один и тот же пакет: цели и границы, сценарии, требования с приоритетами, окружение, желаемые этапы. И просят ответить в единой структуре:
- понимание задачи и вопросы к предприятию;
- состав работ по этапам и что не входит;
- команда: роли, имена ключевых людей, их занятость в проекте;
- что требуется от предприятия: роли и время специалистов;
- оценка трудоёмкости и стоимости по частям, отдельно — доработки и перенос данных;
- порядок изменений, приёмки и сопровождения.
Вопросы подрядчика к предприятию сами по себе показательны. Тот, кто сразу называет цену и срок, не задав вопросов о данных, интеграциях и особых участках, скорее всего, оценивал не этот проект.
Шаг 4. Проверить подрядчика
| Что проверить | На что смотреть |
|---|---|
| Опыт похожих проектов | Отрасль, масштаб, похожие сценарии; разговор с заказчиками этих проектов, а не только список логотипов |
| Команда | Кто руководитель проекта и архитектор, сколько времени они уделяют проекту, участвовали ли в переговорах |
| Метод | Как устроены этапы, когда проектирование, когда настройка, как принимаются решения |
| Доработки | Как оформляются требования, кто их утверждает, как проверяется качество, как доработки переносятся при обновлениях |
| Данные | Кто готовит справочники и остатки, как проверяется перенос |
| Приёмка | Есть ли приёмка на рабочих сценариях, кто подписывает |
| Передача результатов | Документация, исходный код доработок, права на них; можно ли продолжить проект с другим исполнителем |
| Статус у разработчика системы | Для проектов на 1С — партнёрский статус, например «1С:Центр ERP», и сертификаты специалистов; проверяют на официальном сайте фирмы «1С» |
Статус и сертификаты подтверждают, что у компании есть компетенции и опыт внедрений. Но работать в проекте будет конкретная команда, поэтому разговор с ней важнее любых статусов.
Какие вопросы задать до подписания договора?
- Кто конкретно руководитель проекта и архитектор? Можно ли заменить их без согласия предприятия?
- Что входит в каждый этап и что не входит? Где это записано?
- По каким сценариям и критериям принимается этап? Кто со стороны предприятия подписывает приёмку?
- Как оценивается и согласуется изменение требований? Кто решает, входит ли изменение в бюджет?
- Что должно сделать предприятие и к какому сроку? Что происходит, если оно не успевает?
- Кто готовит данные для переноса и кто отвечает за их проверку?
- Как устроена оплата: по времени, по этапам, за результат? Есть ли связь оплаты с приёмкой?
- Кому принадлежат доработки и исходный код? Какая документация передаётся?
- Как исправляются ошибки после запуска и сколько длится гарантия?
- Как доработки будут совместимы с обновлениями системы?
- Что происходит при расторжении договора: какие материалы передаются, как проект продолжит другой исполнитель?
Ответы на эти вопросы — не формальность. Большинство споров в ERP-проектах возникают из-за того, что одна из сторон понимала один из этих пунктов иначе.
Признаки, на которые стоит обратить внимание
- оценка без вопросов о данных, интеграциях и особых участках;
- отказ проходить сценарии предприятия — только стандартный показ;
- команда не названа или названа «по мере необходимости»;
- обещание закрыть любые требования доработками, без оценки их влияния на обновления;
- приёмка без сценариев — только акт выполненных работ;
- в договоре нет обязанностей предприятия, сроков его решений и порядка изменений.
Учебный пример: два ответа на один запрос
Учебный пример. Ситуация создана для объяснения метода и не описывает конкретное предприятие.
Производственное предприятие передало двум подрядчикам одинаковый пакет: шесть сквозных сценариев, требования с приоритетами и список систем, с которыми нужен обмен. Один из сценариев — заказ клиента, который выполняется частично из запасов, частично из нового производства.
Первый подрядчик провёл стандартную демонстрацию, а в предложении указал общий срок и сумму. Второй задал вопросы о том, как сейчас ведутся остатки и кто утверждает изменения в спецификациях, прошёл сценарии на примерах предприятия и по каждому шагу отметил: типовое решение, настройка или доработка. Доработок получилось четыре, каждая с оценкой и объяснением, почему типовая схема не подходит.
Предложение второго подрядчика было дороже. Но только оно позволяло понять, за что предприятие платит и что будет принято на каждом этапе. Сравнение по цене здесь сравнивало бы разный объём работ.
С чего начать
Выпишите пять–десять сквозных сценариев, без которых предприятие не может работать, и для каждого — один реальный пример с документами. Это основа и для сценарного показа систем, и для запроса подрядчикам, и для критериев приёмки в договоре.
Если внутри предприятия нет человека, который проведёт выбор и будет держать архитектуру проекта, эту роль может выполнить независимый руководитель на стороне заказчика. О том, как устроены такие проекты, — на странице «Нестандартные проекты на 1С и ERP», а о предпроектном обследовании — на странице «Обследование и анализ бизнес-процессов».