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