Меня зовут Кирилл и в последние несколько лет я «болею» цифрами, аналитикой и автоматизацией бизнес-процессов.
Человек, болеющий Цифроманией:)
Болезнь «Цифромания» началась, когда я трудился РОПом. Ежедневные рутинные операции по составлению управленческих отчетов из разных источников: CRM система и системы бухгалтерского учета, каждый день я делал ctrl+C и ctrl+V в одних и тех же таблицах и приводил форматирование к единому виду. Одни и те же действия, каждый день с понедельника по пятницу - и я «заболел». Заболел автоматизацией процессов.
Сначала были просто автоматические шаблоны – нужно было только добавить новые данные, (например, выгрузки из CRM-системы) и все показатели в таблице автоматически пересчитаются, графики изменятся, и уже можно анализировать актуальные данные.
В дальнейшем из нескольких таких шаблонов я сделал единую систему управленческой отчетности, в которой я объединил показатели как процесса продаж (данные CRM-системы), так и показатели результата продаж (данные бухгалтерской системы учета). Все данные в единой системе автоматически обновлялись, были связаны между собой, была возможность отобразить информацию за выбранный период, а также были настроены различные права доступа для линейных сотрудников (показатели процесса продаж и данные CRM-системы) и для руководителей отделов продаж и собственников компании. Подробнее о работе и наполнении такой системы - https://vk.com/@rezenov-proekt-sistema-otchetnosti-dlya-otdela-prodazh
Архитектура ERP-системы на базе Google-таблиц
В первой части я рассказал о том, как у нас появились оцифрованные процессы складского учета. Сотрудники склада принимают готовые изделия на склад (фиксируют приход на основании данных с последнего этапа производства) и осуществляют отгрузку готовых изделий покупателям и на склады в других регионах РФ для пополнения их остатков.
Процесс отгрузки продукции с основного склада
Предприятие загружает производство на полную мощность, производя продукцию как для реализации через свои каналы сбыта, так и для оптовых заказчиков. Соответственно, складской учет организован раздельно.
Блок «Система управления остатками на складах и маркетплейсах»
Свою продукцию предприятие реализует через две самые крупные площадки маркетплейсов в РФ. Назовем маркетплейсы как Площадка1 и Площадка2.
Заказчик в одном из обсуждений высказал свою мечту: «Вот бы сделать так, чтобы я всегда мог видеть сводную информацию по заказам моей продукции на Площадках! Ведь тогда я бы смог максимально точно планировать производство, я бы оптимизировал расходы на закуп материалов на производство и рекламу, я бы …» он задумался на несколько секунд. «И вообще! Я хочу видеть, что у меня продается, с каких складов сколько-чего, когда отгружается и вообще. Вообще хочу видеть все!»
Ну что ж. Отказывать заказчику в желании нельзя!
На первый взгляд то, что хочет клиент, помещается в 1 или 2 дашборда: по продажам и по отгрузкам. Разбивка по товарам, регионам продажи, по количеству, по деньгам и тд. Слишком все просто. Взял паузу, на то, чтобы полностью обдумать ТЗ заказчика. Семь раз отмерь – один отрежь! Чем детальнее понимаешь весь процесс от входа до выхода, тем меньше времени в последствии потратишь на доработки и изменения.
Вы удивитесь, но после нескольких встреч с заказчиком и уточнения всех деталей, ТЗ кардинально изменилось. Итак, представьте себе ситуацию:
Вы продавец и торгуете своим товаром на 2х маркетплейсах: Площадка 1 и Площадка 2. На обеих площадках есть какие-то остатки товаров. Когда покупатель создает заказ на одной площадке, количество остатка этого товара на другой площадке должно уменьшиться на единицу, чтобы не получилось так, что товар заказали, а на остатках его нет. В этом случае продавцу будет выставлен штраф за наличие некорректных остатков.
2 витрины - один склад. Как может возникнуть штраф за некорректные остатки на маркетплейсах
Здесь у продавца, по сути, 2 выхода. Держать на удаленных складах большие остатки, которые создают дополнительные складские расходы. Или сокращать расходы: оперативно управлять остатками на удаленных складах и синхронизировать информацию о наличии товара между Площадкой 1 и Площадкой 2, чтобы не «попасть» на штрафы.
Хмм… хорошо. Но ведь остатки сами собой не появляются! Кто-то как-то сейчас управляет остатками на Площадках? Значит нужно связать с собой процесс складского учета «отгрузки» с системой, которая будет управлять остатками на Площадках.
Как должна работать система управления остатками
Т.е. в итоге нам нужно заставить работать вместе внутреннюю систему учета и внешние системы обеих Площадок.
Первоначально синхронизация остатков работала так: система сравнивала текущие остатки на обеих Площадках, находила минимальный остаток и выравнивала его на каждой Площадке. В такой форме реализации важнейшую операцию ВЫЧИТАНИЕ мы отдаем на сторону Площадки и просто регулярно забираем данные о текущих остатках, которые каждая Площадка определяет сама: ТЕКУЩИЙ ОСТАТОК = НАЧАЛЬНЫЙ ОСТАТОК – КОЛ_ВО ЗАКАЗА.
В тестовом режиме я установил период обновления данных в 10 мин. Все было хорошо, ровно до момента, когда один и тот же артикул заказывали на Площадках одновременно. Остатки задваивались в минус. Возможным решением покажется сокращение периода обновления. Но даже с учетом сокращения риск одновременного заказа остается.
Автоматизация процесса направлена на то, чтобы исключить ошибки, возникающие при ручном выполнении задач, и снизить зависимость от внешних факторов.
Верное решение нашлось с другой стороны продажи. Я начал смотреть с конца, с остатков, а правильно было смотреть на начало – на самое начало процесса Продажа – на этап Заказа.
API обеих площадок позволяет получать данные о новых заказах в автоматическом режиме через специальный запрос. Согласно документации API одной из Площадок данные по новым заказам можно получать не чаще, чем раз в 30 минут. Это условие мы изменить не можем. Поэтому период обновления всей нашей системы будет по умолчанию 30 минут.
Т.е. каждые 30 минут получаем данные о новых заказах за последние 24 часа от обеих Площадок. Далее нам нужно решить несколько важных задач:
Как выделить только новые заказы из всего списка заказов за последние 24 часа?
Как объединить данные по новым заказам от Площадок?
Как сделать автоматический приход продукции на остатки Площадок после операции РАСХОД с склада производства?
Как синхронизировать пункт 3 с пунктом 4?
В решении вопросов выше использовал свою собственную логику и последовательность процесса, формулы FILTER, QUERY, VLOOKUP(ВПР), работу с массивами ARRAYFORMULA и немного скриптов GAS (Google App Script).
Мой алгоритм управления текущими остатками
После загрузки данных о заказах за последние 24 часа при первом запуске системы мы получим данные по заказам, которые уже учтены и списаны с остатков Площадок. Через 30 минут API Площадок отдадут нам новые данные о заказах за последние сутки. Это будут как новые заказы, так и частично старые, т.к. начальная дата и время начала отсчета всегда будут смещены на 30 минут вперед.
На этом этапе крайне важно разделять новые заказы от старых. Т.к. операцию ВЫЧИТАНИЕ сейчас будем делать мы, а не Площадка и для корректной работы системы нам каждый раз нужны только новые, уникальные заказы. Здесь и реализовал логику формирования резерва для списания. После каждого запуска, скрипт получает от Площадки список заказов за последние 24 часа:
во вкладку «Все заказы» скрипт сохраняет накопительным итогом новые, т.е. уникальные заказы.
затем во вкладку «Новые заказы» скрипт оставляет только новые заказы, которые были получены, но которых еще нет в вкладке «Все заказы».
Из списка всех заказов будут сделаны несколько дашбордов. Т.к. информация в этой вкладке будет добавляться накопительным итогом и будет содержать только уникальные заказы, дашборды будут отображать всегда актуальную информацию и показывать свежие данные о динамике заказов по складам, артикулам, количестве и др. данным.
Информация в вкладке «Новые заказы» перезаписывается после каждого обновления заказов. Это позволяет нам получить динамические данные по количеству товаров в новых заказах. Это и будет нашим резервом для списания.
Вкладка для формирования резервов для списания
Данные по резервам формируются с помощью функции IF, работы с массивами ARRAYFORMULA и используют следующую логику:
Если нет новых заказов: вернуть 0. Есть новые заказы: кол-во SKU в заказах Площадка1 + Кол-во SKU в заказах Площадка2 = РЕЗЕРВ
Здесь у нас уже есть данные начальных остатков и появилось понимание сколько продукции у нас заказали на каждой Площадке, и в общем количестве товаров, заказанных за последние 30 минут. На основе этих данных мы получаем новый остаток.
Логика списания резервов из остатков
Из-за того, что данные в вкладке «Новые заказы» каждый раз после обновления перезаписываются, нам нужно сохранять информацию по новым остаткам, которые к следующему обновлению станут уже начальными остатками, и уже из этих новых остатков будут минусоваться новые заказы.
Здесь нам помогает простейший скрипт, который просто сохранят данные по новым остаткам в временную вкладку temp без форматирования, красоты - только данные.
Временная вкладка temp для сохранения текущего остатка
Итого у меня получилось реализовать следующие этапы в работе системы:
Алгоритм управления остатками. Я использовал формулы и скрипты Google-таблиц
Этот цикл повторяется каждые 30 минут. Работа над модулем «Выравнивание остатков на Площадках» завершена. Можно переходить к следующей задаче – как к этому циклу Выравнивания остатков прикрутить приход продукции с основного склада?
Блок «Из расхода с производства в приход на Площадку»
Что такое Приход продукции с основного склада в нашем созданном цикле? Это просто изменение значения Резерва. В текущей логике Резерв формируется как
кол-во SKU в заказах Площадка1 + Кол-во SKU в заказах Площадка2 = РЕЗЕРВ
А что, если один раз в сутки чуть изменить формирование Резерва и добавить к нему цифры прихода с основного склада? Тогда получится следующая логика
Алгоритм добавления прихода продукции на остатки маркетплейса
Если интегрировать эту логику в наш цикл Выравнивания остатков на Площадках, получится, что один раз в сутки нужно «подменить» временные данные по новым остаткам на остатки с Приходом.
При следующем обновлении система будет уже использовать данные остатков с Приходом как Новые остатки. Для реализации такой логики работы я ввел два новых показателя: «Резерв с учетом прихода» и «Новые остатки с учетом прихода» и добавил простой скрипт копирования этих данных в временную вкладку temp, где каждый раз перезаписываются данные о новых остатках.
Раз в день – новые остатки с учетом Прихода. Каждые 30 минут – новые остатки за минусом Резерва.
Финальным этапом реализации всей системы было решение задачи объединения ERP системы с системой управления остатками на складах и маркетплейсах, а именно – как передать данные от процесса расхода с склада производства на остатки Площадок?
Для реализации я использовал функцию IMPORTRANGE, чтобы автоматически передавать данные с таблицы, где сотрудники склада проводят операции расхода, с таблицей системы управления остатками на Площадках. В режиме реального времени передаются данные в виде:
Данные по отгрузке продукции с основного склада
С помощью функции FILTER фильтруются данные только по тем складам, которые записаны в системе управления остатками. У каждой отгрузки есть параметр «Дата отгрузки»
С помощью функции TODAY()-1 я сделал задержку в 1 день для добавления прихода.
Сотрудник склада в течении дня может проводить несколько операций «расход с основного склада». Все данные расходов с вчерашней датой я буду учитывать как приход сегодняшней датой, поэтому СЕГОДНЯ минус ОДИН день.
Соединения операции расход с основного склада и операции приход на складе маркетплейса
Итогом разработки и внедрения получилась автоматизированная система, которая регулярно выравнивает остатки на Площадках, когда продавец торгует с одного склада.
Система выравнивания остатков последовательно интегрирована в общую ERP-систему и завершает полный производственный цикл изделия: от плана до выпуска, складской учет и отгрузку конечному потребителю через систему складов.
Осталось только создать дашборды на основе данных о новых заказах. Здесь полет фантазии безграничен. Есть много параметров заказа: дата, время, артикул, регион продажи, финансовые данные и тд.
От начального желания заказчика «Хочу Дашборд, хочу все видеть», создание «Системы Управления остатками на складах и маркетплейсах» и объединение ее с системой ERP позволило заказчику здесь и сейчас исключить риски возникновения расходов из-за штрафов за некорректные остатки. Экономия здесь и сейчас.
Оцифрован и автоматизирован производственный цикл от планирования до выпуска готового изделия.
Внедрен этап дополнительного контроля качества готовых изделий через оцифровку процесса «Прием изделий» в процессах складского учета.
Организовано управление процессом отгрузки изделий с склада производства на удаленные склады.
Внедрена система автоматического выравнивания остатков на складах маркетплейсов.
Оцифрован весь жизненный цикл изделия от плана до отгрузки конечному потребителю через систему складов.
Ссылки на канал в ТЛГ не будет, его нет:)
Донаты не знаю как подключать, но от заказов работ на автоматизацию бизнес-процессов не откажусь.
