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