Метка: OLAP

12Ноя/14

Авенир — автозаказ и оптимизация складских запасов [дистрибуция]

Заказчик

ООО фирма»Авенир» является крупнейшим дистрибьютором продуктов питания в СКФО и ЮФО.

г.Ставрополь 2012г.

Задача

Уменьшить складские запасы путём их оптимизации. Увеличить оборачиваемость товара. Сократить средства, выделяемые на хранение товара.

За основу было взято решение от BaseGroup — Deductor ISO (оптимизация складских запасов). Подробнее можно почитать в статье Demand Forecast – оптимизация складских запасов на платформе Deductor. Решение доработали под запросы заказчика в разделе получения плана продаж.

Реализация

  • Создали хранилище данных на Fire Bird.
  • Настроили регламенты и процедуры импорта данных из учетных систем, очистки данных и экспорта в хранилище данных.
  • Настроили алгоритмы очистки от всплесков и обогащения от пропусков по каждой территории.
  • Настроили прогнозные модели под данные заказчика. В решении используется 5 (пять) прогнозных моделей.
  • Получили наилучший план из возможных вариантов.
  • Провели анализ договоров с производителями и источников дохода фирмы. Создали иерархию источников дохода по каждому контракту. Это:
    • выполнение плана продаж,
    • выполнение плана закупок,
    • выполнение плана по хранению стоков товара,
    • прогноз спроса.
  • Создали алгоритм, который позволяет перевести план продаж в рублях в «Сколько и какого товара, по какой цене, в какую торговую точку нужно продать, что-бы выполнить план продаж».
  • Получили план продаж скорректированный на маркетинговые и прочие акции.
  • Учли график подачи заявок (заказов) производителю.
  • Получили заказ производителю учитывающий:
    • Скорость реализации товара в местах и днях продаж;
    • Запасы на складе в днях продаж и в местах;
    • Плечо доставки (оформление заявки у заказчика + обработка заявки у заказчика + сроки доставки);
    • Объём и грузоподъёмность транспортных средств;
    • Планы продаж и закупок в рублях;
    • Маркетинговые акции;
    • Дни подачи заявок производителю.
  • Если транспортное средство недогружено, то алгоритм добавляет товары групп [АХ, ВХ, АY]. Если транспортное средство перегружено, то алгоритм убирает товары групп [BZ, CZ, CY].
  • Настроили автоматический запуск процессов.
    • Ежедневный — по импорту данных из учетных систем.
    • Еженедельный — по прогнозу.
    • Ежедневный — по получению.

Результаты

  • Формализовали процесс создания заказа поставщику и закупки товара. После трёх месяцев тестовой эксплуатации и настройки, система стала показывать ошибки операторов.
  • Качество прогноза по фирме за 33 недели составило 88%. т.е. среднее отклонение прогноза от факта составило 11,98% Качество прогноза
  • Получаем наилучший прогноз из возможных. Математически подтверждаем «почему тот или иной прогноз наилучший на данный момент». Кстати… Такого подтверждения нет ни в одной системе конкурентов. Адекватность прогноза
  • Система автоматически определяет какой прогноз адекватен, какой требует экспертной оценки (большой разброс прогноза и факта), а какой требует экспертного вмешательства (как правило, это товары новинки и товары, которые выбывают из продаж).
  • Система работает полностью в автоматизированном режиме. Каждый день у менеджера по закупкам, утром, есть план закупок.
  • План закупок учитывает сроки доставки и транспорт, которым доставляется товар.
  • Сократилось количество менеджеров по закупкам.
  • Побочные эффекты:
    • Отдел продаж еженедельно получает документ отражающий «Сколько какого товара, в какую торговую точку и по какой цене нужно продать что-бы выполнить план продаж».
    • Отдел продаж получил дополнительный инструмент по оценке качества работы торговых представителей.
    • Навели порядок в справочниках учетной системы.
    • Дополнительные отчеты для финансового отдела.

P.S.

  • В 2016 году мигрировали на MSSQL

Сохранить

Сохранить

Сохранить

Сохранить

08Дек/08

Новые технологии [производство]

Новые технологииЭто был наш первый крупный проект такого масштаба.

2007 год, мы только стали представителями аналитической платформы Deductor.
В городе Невинномысске есть предприятие «новые технологии». Занимается выпуском монтажной пены для бытовых и промышленных нужд. С учётом, у них, всё в порядке. Но есть одно «НО».
Согласно технологического процесса выпущенный баллончик с пеной перед продажей доукомплектовывался трубочкой и крышечкой. А так как трубочки и крышечки для всех баллонов одинаковые, то их проводили по учету как «предпродажная подготовка«. Операция одна на всю продаваемую партию. Телодвижений для бухгалтера минимум. ПБУ такой финт позволяют делать. Проверки регулярно проходят. Прибыль по предприятию считают. Всё красиво. Только есть один нюанс.
Руководитель не видит доходности каждого, отдельно взятого, баллончика. «Сверху» цену давит рынок, а «снизу» себестоимость. Зазор очень маленький.
Тогда главный бухгалтер берёт Эксель и 10 дней, ручками, распределяет затраты на каждую партию. Причём не только «предпродажная подготовка», а ВСЕ затраты. По сути — делает прибыли и убытки по каждому виду проданной продукции.

Руководитель и главный бухгалтер приглашали ТРИ (!) 1с-ные фирмы. Все, в один голос, отказались браться за этот проект. Мотивировали тем, что не берут на себя ответственность за баланс. Мол «поплыть» может весь учет.

За дело взялись мы с Олегом Павловичем.

  1. Определили источники возникновения затрат.
  2. Определили технологические циклы. И описали карты.
  3. Разделили затраты на прямые и распределяемые по технологическим картам.
  4. Перегруппировали некоторые затраты в соответствии с здравым смыслом.
  5. Написали сценарий на платформе Deductor, который «достаёт» данные по производству, затратам и продажам из 1с. Затем перегруппировывает затраты в соответствии с п.4. Распределяет затраты двумя способами (опять-же «здравый смысл» рулит). Одним способом на произведенную продукцию, а другим на проданную. Потом произведённая и проданная продукция приводится к одним координатам и считается «фактическая себестоимость проданной продукции«.
  6. На следующем этапе посчитанная себестоимость сравнивалась с фактической продажной ценой. На основании этого сравнения руководитель принимал решение о целесообразности выпуска той или иной продукции и о доходности каждого вида продукции.

Проект делали 3 месяца. 2 раза переделывали полностью.
Что в итоге:

  • После проведения последних документов и обработок главный бухгалтер, в конце рабочего дня, нажимал на один ярлычек и выключал монитор.
  • По началу обработка работала 7 часов. Через 2 года — 13 часов.
  • Потом ещё через год я её немного дописал и обработка стала работать 3 часа.
  • Утром следующего дня руководитель мог видеть подробный анализ выпущенной и проданной продукции.
  • Попутно был сделан анализ затрат в виде OLAP куба. Через 2 года главный бухгалтер стал сам использовать это решение для сдачи отчетности по производству в налоговую.
  • Решение, в практически неизменном виде, проработало до конца 2012 года. Потом сменился руководитель, а новому информация по «фактической себестоимости реализованной продукции» была неинтересна.