Ещё одна таблица: как мы считали потребность в сырье по данным 1С

У одного из сотрудников TRI было около шести Excel-таблиц. Он выгружал данные из 1С, переносил их в свои файлы и занимался тем, чем приходится заниматься после переноса данных: сводил, пересчитывал, проверял. Когда в компании решили выяснить, сколько времени на это уходит, продуктовый директор Магомед Ахматов предложил завести ещё одну таблицу. В ней предполагалось учитывать время, потраченное на предыдущие.

Магомед рассказал нам об этом, когда мы обсуждали результаты внедрения аналитики. Компания производит клеи, герметики, компаунды и гидроизоляционные покрытия. Наша команда делала для неё несколько отчётов, а здесь я остановлюсь на одном: расчёте потребности в сырье. В этом проекте мы сначала собирались использовать рецептуры, затем нашли другой источник данных и довольно долго сверяли результат с человеком, который раньше считал всё вручную.

Что происходило после изменения прогноза

Менеджеры TRI планировали продажи по месяцам и товарным группам. За разные части каталога отвечали разные люди, каждый готовил свой прогноз. Потом эти планы попадали к сотруднице отдела закупок, которой предстояло определить, какие продукты потребуется выпустить, сколько компонентов на них уйдёт и чего не хватает на складе.

На этом уровне товарная группа переставала быть удобной единицей планирования. Внутри неё находились отдельные артикулы с разным составом, причём один материал мог использоваться сразу в нескольких продуктах. Нужно было пройти от общего плана до каждого из них, рассчитать расход и собрать одинаковые компоненты обратно в общий список закупок.

Прогнозы менялись, менеджеры сообщали об этом в личных сообщениях и заодно спрашивали, когда появится нужный материал. Сотруднице приходилось возвращаться к таблицам и пересчитывать потребность. Изменение нескольких чисел в плане создавало работу, которой в самом плане видно не было.
Автоматизировать мы собирались именно эту последовательность. Сотрудница должна была получать расчёт по материалам, понимать, откуда взялось количество, и решать, сколько заказывать. Её опыт нам ещё предстояло использовать для проверки того, что получится.

Рецептуры остались у разработчиков

Первое предложение выглядело разумно: взять рецептуры продуктов и считать потребность по ним. Рецептуры у TRI были, их составляли собственные разработчики. Они хранились в закрытых таблицах, которые устраивали людей, работавших с ними каждый день.

После знакомства с форматом стало понятно, что извлечение составов потребует отдельной разработки. Предстояло разбирать таблицы скриптами и приводить сведения к виду, пригодному для регулярного расчёта. Заказчик, кроме того, не собирался переносить исходные рецептуры за пределы компании. У разработчиков продуктов были свои основания хранить их именно так, а наша задача от этого проще не становилась.

Мы начали смотреть, какие сведения уже есть в производственном учёте, и нашли отчёт 1С о выпуске продукции. В нём были артикул, объём изготовленной партии и количество использованных компонентов. Для закупочного прогноза из этих записей можно было получить средний расход материала на килограмм или литр готового продукта.

Вместо разбора исходных рецептур мы могли опираться на уже выпущенные партии, но должны были принять ограничения такого подхода. Между партиями встречались различия, в том числе при использовании компонентов разных производителей. Средний расход давал приближение к будущей потребности, и пригодность этого приближения мы обсуждали с заказчиком. Исходные таблицы разработчиков в итоге не переносили, хотя сведения о расходе тоже оставались чувствительными: по ним можно судить о составе продукции.

Как считали потребность

Прогноз по товарной группе мы распределяли между артикулами по истории продаж. Полученный объём каждого продукта умножали на средний расход его компонентов, затем суммировали потребность в одинаковых материалах и учитывали складские остатки.

Возьмём условный пример с двумя продуктами(все числа здесь вымышлены ибо NDA). На следующий месяц запланировано продать 10 тонн продукции одной группы, в которой на продукт А исторически приходится 60% продаж, а на продукт Б — 40%. Для простоты считаем, что готовой продукции на складе нет и весь объём предстоит произвести; поступления и резервы сырья в этом примере не учитываем. Один из материалов входит в оба продукта:

Всего понадобится 2 600 кг материала. Если на складе есть 1 000 кг, доступных для этого выпуска, недостающая потребность составит 1 600 кг. После изменения прогноза расчёт повторяется с новыми объёмами.

Больше всего внимания потребовали значения среднего расхода. Можно взять короткий период и получить сильное влияние отдельных партий, можно взять длинный и продолжать учитывать то, что производство уже делает иначе. Мы сравнивали разные способы усреднения и статистику за три и шесть месяцев, а сотрудница отдела закупок сопоставляла результат со своей оценкой.

В целом она заказала бы примерно такие же количества. По отдельным позициям предлагала увеличить или уменьшить объём, после чего расчёт уточняли. Процента точности из такой проверки не получается, зато можно понять, годится ли результат человеку, которому предстоит им пользоваться. Для нового продукта без истории выпусков или после изменения состава прежнее среднее пришлось бы проверять отдельно.

Где можно было разобраться с расхождением

Закупщику мало видеть итоговую цифру, особенно если собственная оценка с ней не совпадает. Мы сделали отдельное представление с производственными данными: по продукту можно было открыть дату последнего выпуска, объём партии и расход компонентов. По материалу были видны продукты, в которых он используется.

Если количество вызывало сомнение, сотрудница могла дойти до этих записей и посмотреть, что именно учтено. Решение о заказе оставалось за ней. В этой части проекта участие человека, чью ручную работу мы автоматизировали, оказалось необходимым: он знал, какие результаты стоит перепроверить.

Технически данные проходили несколько этапов. Отдельный подрядчик разработал расширение для 1С, которое ежедневно по расписанию выгружало файлы в S3-совместимое хранилище. Наша команда загружала их в ClickHouse, выполняла преобразования и расчёты, а результат показывала в Yandex DataLens. Использовали сведения о выпуске и остатках, прогноз и историю продаж.
На дашборде также был индикатор изменения прогноза. Он обращал внимание сотрудницы на ту часть расчёта, к которой следовало вернуться. Насколько изменилось количество и что делать с ранее запланированной закупкой, она разбирала сама. Производственные данные при этом обновлялись с частотой ежедневной выгрузки.

Откуда взялись 250 тысяч рублей в месяц

Когда Магомед назвал оценку эффекта, я предположил, что речь пойдёт о результатах более точного планирования. Оказалось, в компании начали с того, что могли измерить: с рабочего времени. Тот самый сотрудник с несколькими Excel-файлами в течение квартала учитывал часы, потраченные на подготовку аналитики. Затем время соотнесли с зарплатой. По словам Магомеда, стоимость такой работы по нескольким сотрудникам составляла около 250 тысяч рублей в месяц. Оценка относилась ко всему набору внедрённой аналитики, включая продажи, валовую прибыль и снабжение, поэтому приписать её одному расчёту сырья нельзя.

«Я думал, вы от принятых решений отталкивались, а вы по трудозатратам посчитали», — сказал я. Меня больше интересовало, сколько компания выигрывает, когда лучше планирует закупки и производство. Магомед тоже говорил об этом эффекте, но отделить его от других изменений оказалось сложнее, чем посчитать часы.
Так что у нас осталась оценка стоимости ручной работы и понимание того, какие операции сотрудники перестали повторять. Это не означало, что расходы компании автоматически сократились на ту же сумму. Подтверждённой суммы экономии на запасах в этом расчёте тоже не было.

Людям ещё нужно было захотеть этим пользоваться

Внедрение Магомед, по его собственным словам, продавливал. Он разговаривал с руководителями производства и снабжения, начальником склада и руководителем группы координации производственных процессов. Сотрудников отвлекали от текущих задач, иногда после рабочего дня. Чтобы в будущем у них стало меньше ручной работы, некоторое время им приходилось работать больше.

В таком положении отсутствие восторга не особенно удивляет. Нужно объяснить привычный порядок действий, проверить чужой расчёт, найти расхождения, вернуться с замечаниями. Свои обязанности на время проекта никто не отменял.

Освоение не закончилось в один определённый день. Со склада продолжали приходить пожелания, и иногда Магомед в ответ просто показывал страницу дашборда, где нужная функция уже была. Люди пользовались инструментом и заодно узнавали, что ещё в нём можно найти.

После очередной правки прогноза сотруднице отдела закупок больше не требовалось заново собирать весь расчёт. Она могла открыть обновлённую потребность, проверить сомнительные позиции и внести поправки перед заказом.
Старые таблицы при этом запрещать не стали. По воспоминанию Магомеда, примерно на четвёртый-пятый месяц сотрудники сами перестали поддерживать прежние дублирующие файлы. Нужные сведения уже можно было открыть по ссылке, а повторять ту же работу в Excel постепенно перестало иметь смысл.