Первый полезный модуль закупок — заявка с участниками, маршрутом, историей решений и понятным итогом. Важнее проверить возврат, повтор и изменение условий, чем сразу подключить все отделы и документы.
Отделите согласование от исполнения закупки
Подача потребности, выбор поставщика, согласование, заказ, приёмка и оплата — разные события. Не стоит объединять их одним статусом «одобрено». Утверждённая заявка ещё не означает, что заказ отправлен или товар получен.
Начните с границ: какое событие запускает модуль и чем он заканчивается. Например, сотрудник создаёт заявку, руководитель подтверждает необходимость, закупщик уточняет предложение, финансовая роль проверяет условия, затем согласованный заказ передаётся в учётную систему. Это пример маршрута, который нужно адаптировать к вашей компании.
Соберите достаточные данные в заявке
Поля должны помогать принять решение. Обязательными сделайте только те сведения, без которых нельзя двигаться дальше. Предложение поставщика может появиться после первичной заявки, а итоговую сумму иногда уточняют при согласовании.
Отделяйте комментарии от данных: если цена или количество живут только в переписке, система не сможет проверить изменение условий. Значимые значения должны иметь собственные поля и историю версий.
- Что требуется, в каком количестве и для какой задачи.
- Подразделение, инициатор и ожидаемый срок.
- Предполагаемая сумма, валюта и сведения о поставщике, когда они известны.
- Основание и связанные документы.
- Ответственный за следующий шаг и текущая версия заявки.
Определите роли и маршрут
Опишите, кто может создать, изменить, согласовать, вернуть и отменить заявку. Затем задайте условия маршрута: подразделение, категория, сумма или проект. Для каждого решения должны быть понятны согласующий, срок и основание.
Для отсутствующего сотрудника нужен порядок замещения. Если условия не позволяют определить согласующего, заявка должна попасть к ответственному за разбор, а не исчезнуть в неопределённом статусе. Параллельное согласование тоже требует правила: нужны все решения или достаточно одного.
| Ситуация | Предлагаемое поведение | Что проверить |
|---|---|---|
| Не хватает данных | Вернуть инициатору с причиной и сохранить историю. | После уточнения видно, какая версия снова отправлена. |
| Изменилась сумма | Применить согласованное правило повторного рассмотрения. | Старое одобрение не используется без проверки новых условий. |
| Согласующий отсутствует | Передать назначенному заместителю. | У заместителя есть нужные права; решение записано от его имени. |
| Заявку отправили повторно | Продолжить существующий процесс по её идентификатору. | Не появились второй заказ и повторные уведомления. |
Сохраните историю и свяжите исполнение
В истории нужны действия, автор, время, причина и версия данных. Пользователь должен видеть следующий шаг и препятствие: ожидается решение, не заполнено поле или произошёл сбой обмена. Уведомление помогает заметить задачу, а её состояние хранится в системе.
При передаче в ERP или 1С используйте общий идентификатор заявки и запись результата обмена. Если внешняя система не ответила, необходимо отличать неизвестный результат от подтверждённого отказа. Повторная передача должна учитывать возможность, что заказ уже создан.
Проверьте первый модуль на примерах
Согласуйте небольшой набор заявок: обычную, возвращённую, изменённую, отменённую и требующую замещения. Пройдите их с будущими пользователями. Для интеграции добавьте недоступность внешнего сервиса и восстановление обмена.
До запуска зафиксируйте исходные показатели: время ожидания решения, число возвратов и количество случаев, когда статус приходится уточнять лично. После запуска повторите измерение за сопоставимый период. Сам факт появления модуля ещё не показывает, насколько процесс стал быстрее.
- Для каждого статуса определены допустимые действия.
- Изменения после согласования обрабатываются по правилу.
- Доступы проверены для каждой роли.
- Повторное действие не создаёт дубль заказа.
- Видно, где заявка задержалась и кто может продолжить процесс.