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