Покупатель оформил заказ, менеджер обещал доставку, а на складе выяснилось, что товар уже зарезервирован для другого клиента. Сайт, отдел продаж и склад могли сработать каждый по своей инструкции. Проблема возникает между ними: участники используют разные сведения об одной продаже.
В Гуси-Лебеди мы предлагаем разбирать ERP именно через такие рабочие ситуации. Сначала нужно понять, какие процессы связать и какие данные считать достоверными. Затем выбирать систему и проектировать обмен с сайтом. Ниже пройдём этот путь на условном примере интернет-магазина.
Что такое ERP и какую работу она объединяет
ERP расшифровывается как Enterprise Resource Planning, планирование ресурсов предприятия. ERP-система связывает операции компании и сведения о них: например, закупки, склад, производство и финансовый учёт. В определении Oracle речь идёт об управлении повседневными бизнес-процессами и обмене данными между ними. Конкретный набор функций зависит от продукта, модулей и настройки.
Проще представить ERP через движение товара. Компания получает заказ, проверяет возможность поставки, выделяет товар, оформляет отгрузку и отражает операцию в учёте. Если позиции нет, может понадобиться закупка или производство. У каждого этапа свои участники, документы и правила. ERP помогает организовать эту связанную работу.
При этом сама установка программы ещё не отвечает на вопросы: когда заказ считается принятым, кто разрешает отгрузку, какой остаток доступен покупателю? Эти правила задаёт компания. Их нужно перенести в систему и проверить вместе с людьми, которые будут работать по новому процессу.
Модуль выбирают под задачу. Для склада важны движение и доступность товара; для закупок, потребность и поступление; для производства, материалы и выпуск; для финансового учёта, отражение операций. Наличие слова «склад» в презентации продукта не подтверждает, что он поддерживает нужное вам резервирование или работу с вариантами товара.
Мы советуем взять одну продажу и посмотреть, сколько раз сотрудники переписывают её сведения. Где меняется название позиции? Кто вручную передаёт количество? На каком этапе нужно спрашивать коллегу о состоянии заказа? Такая карта даёт предмет для обсуждения с поставщиком системы.
ERP стоит рассматривать, когда задача касается нескольких связанных участков. Если нужно только хранить контакты клиентов или вести небольшой каталог, сначала сравните более узкие решения. Масштаб компании сам по себе не объясняет необходимость ERP: важнее сложность операций и требования к их согласованности.
ERP, CRM и сайт: где проходит граница
CRM организует работу с клиентами: обращения, коммуникации, сделки и следующие действия менеджера. ERP рассматривает более широкий круг ресурсов и операций предприятия. Сайт предоставляет покупателю каталог, личный кабинет или возможность оформить заказ. Эти роли могут пересекаться, поэтому границы нужно определять по конкретным продуктам и процессу.
Например, менеджер ведёт переговоры в CRM, сайт принимает заказ, а ERP участвует в обеспечении и отгрузке. Это возможная схема, а не обязательная архитектура для любого бизнеса. В вашем проекте часть действий может выполняться иначе.
| Система | Что спросить на примере заказа |
|---|---|
| Сайт | Что видит покупатель и что означает сообщение после оформления? |
| CRM | Кто общается с клиентом и где фиксирует договорённости? |
| ERP | Где проверяют обеспечение, выполняют операции и отражают результат? |
Одни и те же слова могут означать разные состояния. Для сайта «заказ создан» может означать сохранённую заявку. Для менеджера «подтверждён» означает согласованную покупку. Для склада важно, выделен ли товар. Лучше описать эти события отдельно, чем передавать всем одно поле «успешно».
То же относится к остаткам. Количество на складе и количество, которое можно продать, могут различаться из-за согласованных резервов или других правил. До интеграции нужно выяснить, какое значение передавать на сайт и что делать, если оно ещё не обновилось.
Для каждого объекта назначьте источник данных. Где создаётся товар и его идентификатор? Кто меняет цену? Какая система разрешает переход заказа в следующий статус? Если изменение допускается в двух местах, заранее определите обработку конфликта. Иначе обмен просто перенесёт противоречие из таблиц в программы.
Мы предлагаем сохранять эти решения в описании интеграции. Оно нужно не только разработчику: менеджер и сотрудник склада тоже должны понимать, почему на сайте показано именно такое состояние.
Как связать ERP с сайтом и проверить путь заказа
Начните с одного законченного сценария. Допустим, покупатель выбирает вариант товара и оформляет заказ. Нужно проследить не только отправку сообщения, но и конечный результат: нужная позиция определена, количество передано, заказ обработан по правилам компании, покупатель получил корректный статус.
- Сопоставить справочники. Зафиксируйте идентификаторы товара, варианта и единицы измерения. Похожее название не заменяет согласованное соответствие: две разные позиции могут называться почти одинаково.
- Описать передачу. Укажите, какие поля и в каком направлении идут между системами, что запускает обмен и где можно увидеть его результат. Отдельно согласуйте, какие сведения действительно необходимы получателю.
- Разделить получение и выполнение. Принятое сообщение ещё не обязательно означает подтверждённый заказ или резерв. Опишите ожидаемые состояния и условия перехода между ними.
- Сверить результат. Проверьте товар, количество, цену и статус на обеих сторонах. Успешный технический ответ подтверждает только то, что предусмотрено протоколом; смысл данных проверяют отдельно.
Способ подключения выбирают по возможностям ERP и платформы сайта. Это может быть штатный модуль, программный интерфейс или предусмотренный формат обмена. Нельзя заранее считать любой из вариантов подходящим для вашей конфигурации.
Показательный пример: страница модуля обмена 1С-Битрикс для конкретного релиза ERP содержит требования к совместимости. Это не рекомендация установить указанный там старый релиз. Это напоминание проверить точные версии, поддерживаемые объекты и ограничения своего решения до начала работ.
При разработке серверной части обмена мы предлагаем включать в задание исключения. Что произойдёт, если система не знает позицию, ответ задержался или одно событие пришло повторно? Для каждого случая нужны понятное поведение и место проверки.
Повтор заказа. Сайт не дождался ответа и отправил сообщение ещё раз. Нужно сохранить связь с исходной операцией и проверить, не появились ли два заказа. Решение зависит от протокола и возможностей систем, поэтому его согласуют и испытывают заранее.
Задержка остатков. Обновление не завершилось. Решите, какие сведения остаются на витрине, как обрабатывается новая покупка и кому становится известно о задержке. Не обещайте покупателю подтверждённое наличие, если процесс его ещё не подтвердил.
Неизвестный вариант товара. Сообщение получено, но сопоставить позицию не удалось. Ошибка должна быть доступна ответственному, а операция иметь понятное состояние. Потерявшаяся запись опаснее явного отказа, который команда может разобрать.
Для диагностики полезно связать события одним идентификатором: что отправили, когда получили и какой результат сохранили. В записи не нужно включать пароли, токены и лишние сведения о покупателе. А после исправления следует сверить результат самой операции, не ограничиваясь исчезнувшим уведомлением.
Как выбрать решение и принять внедрение без сюрпризов
Попросите поставщика показать ваш сценарий на демонстрации. Каталог возможностей может быть большим, но вас интересует конкретная работа: заказ с вариантом товара, частичная поставка, отмена или изменение состояния. Если нужный шаг требует доработки, это должно быть видно до согласования проекта.
Обсудите существующие данные. Справочники могут содержать дубли, несовпадающие единицы измерения и разные правила названий. Нужно решить, что переносить, как проверять соответствия и кто утверждает исправления. Сам перенос не подтверждает, что новая база пригодна для работы.
Вариант размещения тоже влияет на обязанности. Для системы на инфраструктуре компании нужно определить порядок эксплуатации. Для облачного продукта изучите договорные условия, ограничения обмена и выгрузку. Если решение предоставляется по подписке, пригодится наш разбор выбора SaaS-сервиса для бизнеса.
Стоимость обсуждайте по составу проекта. Лицензии или подписка, обследование, настройка, перенос данных, интеграция, обучение и сопровождение могут быть отдельными статьями расходов. Сравнение только цены программы не объясняет, во сколько обойдётся ваш рабочий процесс. Суммы и сроки должны опираться на предложение для конкретной задачи.
На приёмке пройдите обычный заказ и важные исключения на подготовленных данных. Для каждого сценария запишите исходное состояние, действие, ожидаемый результат и фактически полученный результат. Так другой участник сможет понять, что проверено и что остаётся открытым.
Проверьте работу пользователя: сотрудник находит нужный заказ, выполняет разрешённое действие и видит результат. Затем проверьте согласованность данных между ERP и сайтом. Это разные стороны приёмки, и одна не заменяет другую.
Обучение имеет смысл связывать с такими же операциями. Команда должна знать, как обработать заказ и куда обратиться при непонятном состоянии. Передача общего руководства ещё не показывает, что сотрудники могут выполнить свою работу.
Согласуйте владельцев систем и порядок поддержки. Кто разбирает ошибку обмена? Кто отвечает за справочник? Что проверяют после обновления ERP или сайта? Условия реакции и сопровождения должны быть определены отдельно от факта запуска.
И наконец, отделите успешную приёмку от экономического эффекта. Чтобы оценить изменение времени обработки или количества ручных действий, нужны фактические данные до и после по сопоставимым операциям. Проверенный тестовый заказ не доказывает окупаемость всей ERP.
В Гуси-Лебеди мы предлагаем начинать проектирование веб-сервиса и его интеграций с понятной карты процесса. Что делает сайт, за что отвечает ERP, какие данные передаются и чем подтверждается результат. Такой документ помогает обсуждать систему предметно и принимать работающий сценарий, а не только факт соединения двух программ.