В последнее время все больше российских торгово-закупочных компаний среднего уровня сталкиваются с проблемой формирования и поддержания оптимального товарного складского запаса. Зачастую подобное связано с отсутствием четкой и ясной стратегии деятельности компании и, как частный случай, некорректным подходом к самой методологии формирования товарного портфеля (либо вообще отсутствием таковой). Подавляющее большинство подобных компаний делают упор лишь на оперативное управление, в то время как вопросы снабжения и распределения товара целиком и полностью находятся в компетенции менеджеров по закупке и логистике.
Последние, в большинстве случаев, не имеют прописанной методологии и действуют по наитию, либо применяя простейшие схемы (к примеру, просто переадресуя заказы от клиентов своим поставщикам, либо формируют запасы, исходя из средних продаж за некоторый выбранный период). Надо отметить, что в последнее время в связи с обострением конкуренции на большинстве российских рынков руководители компаний пытаются решать данную проблему. Однако в большинстве случаев они ограничиваются лишь внедрением в некой информационной системе (как правило, учетной системе компании) тех же самых простейших алгоритмов, которые применялись менеджерами в «ручном» режиме.
Подобный подход, безусловно, способен привести к некой оптимизации оперативных бизнес-процессов. Но касается он, в основном, только оптимизации бизнес-процессов деятельности менеджеров как таковых, не являясь при этом каким-то качественным инструментом по оптимизации общего процесса по формированию сбалансированных складских запасов. Плюс к тому, подобные решения дают результат лишь в краткосрочной перспективе, в то время как причины «болезни» по-прежнему не устранены. А потому первоначальная задача по оптимизации товарного портфеля компании зачастую остается нерешенной.
Таким образом, в большинстве компаний, пытающихся как-то реорганизовать и оптимизировать свои процессы, происходит подмена понятий – вместо качественной замены процессов происходит некоторое видоизменение существующих. И только редкие компании пытаются идти дальше, пытаясь внедрить более сложные механизмы в процесс формирования сбалансированного товарного портфеля, с целью как оптимизировать деятельность менеджеров по логистике и закупкам, так и получить мощный и достаточно гибкий инструмент управления данными по движению товарных потоков.
Как правило, результатом внедрения становится некая информационная среда (ИС), представляющая из себя программный комплекс, подключенный к некой базе данных (БД), из которой (и в которую) извлекается вся необходимая информация о товародвижении в целом и о самих товарах в частности. При этом указанная ИС обладает достаточно серьезным математическим аппаратом, позволяющим проводить сложные и достаточно точные вычисления с целью проведения расчетов по прогнозируемым продажам (остаткам, перемещениям и др.) в течение будущих отчетных периодов, и, как итог, построением планов продаж, закупок, финансовых и т.п.
Существует множество вариантов решения задачи по внедрению информационных систем, позволяющих проводить оптимизацию товарных потоков. Общемировая тенденция такова, что наибольшее распространение в мире получили глобальные ИС класса ERP, MPR и т.п., охватывающие практически всю деятельность компании в целом. Это продукты от таких корпораций как SAP, Microsoft, Oracle и др. При всех их несомненных преимуществах, внедрение подобных систем обходится компаниям во многие миллионы рублей, чего не может себе позволить большинство отечественных компаний среднего уровня. В добавление к этому, на постсоветском пространстве на текущий момент недостаточно квалифицированных специалистов, способных не только внедрять и настраивать столь сложные системы, но и поддерживать и модифицировать их под собственные нужды компании (а этого зачастую требует специфика бизнеса).
Таким образом, для большинства отечественных компаний подобные системы не приемлемы, по крайней мере в обозримом будущем. Таким образом, не у всех есть возможность внедрять системы подобного уровня, а потому всегда существуют более дешевые и простые аналоги, разработанные под специфику отечественного бизнеса и учета. На нашем рынке существуют разработки и отечественных производителей ПО (к примеру, 1С, Парус, Галактика и др.), целью которых также является внедрение ИС, пытающихся охватить все сферы деятельности компании. Внедрение и сопровождение подобных отечественных систем на порядок ниже по стоимости, по сравнению с «брендовыми» аналогами, что является неоспоримым преимуществом для большинства руководителей компаний при выборе ПО.
Дополнительным положительным моментом является также и наличие специалистов по внедрению, настройке и доработке систем под нужды заказчика (стоимость работы подобных специалистов также значительно ниже по сравнению с внедренцами «бренд»-систем). Казалось бы, внедрение отечественных систем способно оказать положительное влияние на деятельность компаний в целом, и на проблему оптимизации товарных запасов, в частности. Однако и здесь существуют свои подводные камни. Самый большой плюс в практическом применении таких «всеобъемлющих» систем (как отечественных, так и зарубежных) заключается, по мнению многих экспертов, в возможности хранения всех данных в одном месте и использование их в режиме онлайн по первому требованию пользователя, в необходимых отчетах.
На этом, на мой взгляд, серьезные плюсы и заканчиваются. Даже более того, с этого момента начинаются минусы. Во-первых, хранение всех данных (для каждого из направлений – учет управленческий, учет товарный, учет бухгалтерский, маркетинг, аналитика, взаимодействие с клиентами и др.) приводит к постоянной и достаточно серьезной нагрузке на единую базу данных (ЕБД) ввиду великого множества запросов; во-вторых, возникают некоторые технические сложности с разграничением прав доступа к данным от различных подразделений; в-третьих, с ростом самой ЕБД в значительной мере снижается ее гибкость и увеличивается время на запросы и обработку данных; в-четвертых, значительно возрастает физическая (техническая) нагрузка на сервер; в-пятых, для всех направлений деятельности компании вся ЕБД в целом является источником избыточной информации; и в-шестых, как ни крути, а эти системы в большинстве своем являются просто учетными системами, предназначенными для внесения, хранения и извлечения данных, и осуществления оперативной деятельности.
В добавок к озвученному выше, использование глобальных систем порождает множество проблем при осуществлении различных видоизменений и доработок (которые постоянно проводятся) по мере развития бизнеса либо некоторых из его направлений. Поскольку какие-либо видоизменения в одном блоке системы с большой долей вероятности влияют и на смежные области, а спрогнозировать все потенциальные угрозы не всегда представляется возможным, техническим специалистам приходится лезть все глубже и глубже в систему, чтобы, решая одну проблему, не породить другие. И в итоге, решив одну локальную проблему, на поверхности все-таки появляются три новых, и процесс этот цикличен.
Ввиду озвученных выше причин в последнее время все больше компаний переходят к декомпозиции общей ИС компании на отдельные блоки, каждый для своего направления, сохраняя при этом единое информационное пространство в целом по компании. Каждое из направлений использует для решения своих задач специализированную систему, разработанную строго для решения поставленных узконаправленных задач, и пользуется данными непосредственно из своей локальной базы данных. Все данные в локальных базах хранятся в строго структурированном виде, не обладают избыточностью, легко извлекаются и обрабатываются.
При необходимости настраивается взаимосвязь между различными базами, и по регламентированному протоколу проводится обмен необходимой информацией между ними. К примеру, для большинства локальных ИС первичные данные извлекаются из ЕБД, после чего обрабатываются и дополняются данными из других БД либо из внешних источников. Полученные таким образом данные используются в локальных (специализированных) ИС, исключая при этом какое-либо серьезное воздействие на «соседние» локальные ИС и на ЕБД. Подобный подход снимает большинство озвученных выше проблем, характерных в случае одновременной работы всех систем непосредственно в ЕБД. Безусловно, решив одни проблемы, компании порождают другие – к примеру, некоторым менеджерам приходится иногда открывать две программные системы вместо одной для формирования каких-либо отчетов. Однако, на мой взгляд, серьезность данной проблемы на порядок меньше всех остальных, озвученных выше, и компенсируется повышением общего качества работы и получаемого результата. Поэтому в ряде случаев решение проблем по внедрению систем прогнозирования и планирования также выносят в качестве отдельной ИС – для формирования методологии прогнозирования и планирования, и реализации ее в программном виде с целью оптимизации товарного портфеля компании и поддержания его в сбалансированном состоянии.
Предлагаю рассмотреть на примере одной из компаний решение задачи по реализации проекта по внедрению системы планирования, позволяющей решать поставленные задачи по оптимизации товародвижения. Ранее на этом на сайте автором уже представлялась методология проведения расчетов, позволяющая осуществлять формирование планов продаж и закупок, а также финансовых планов на их основе (Павел Бондарев: Просто о непростом: планирование торгово-закупочной деятельности компании). Вторым этапом были представлены результаты реализации и внедрения программного комплекса по прогнозированию и планированию деятельности в одной из компаний (представлено в печатной публикации – журнал «Логистика и управление» № 3/2008). Теперь же предлагается дать более расширенное представление реализованных результатов в виде программных комплексов по автоматизации процессов товарно-логистического прогнозирования и планирования, дистрибьюции и финансово-экономического планирования.
Одним из направлений деятельности рассматриваемой компании является сельскохозяйственная техника и запчасти к ней, номенклатура свыше 20 тыс. позиций, порядка 20 филиалов по территории РФ, ярко выраженная сезонность. В связи с тем, что сезонность представляется «пиковой» дважды в год, а большая номенклатура не позволяет менеджерам по закупкам корректно проводить расчеты по прогнозам продаж и планам закупок «вручную» по множеству позиций, было принято решение о внедрении системы, которая взяла бы на себя всю техническую и расчетную работу, выдавая менеджерам соответствующие рекомендации для дальнейшего анализа и принятия решений.
Автор данной публикации возглавлял в компании подразделение аналитики и планирования, одним из направлений деятельности которого была разработка, реализация и внедрение различных систем по оптимизации бизнес-процессов компании. В компании было принято решение пойти по пути декомпозиции общей ИС на отдельные информационные блоки и источники хранения данных. Для решения задач управленческого учета и бухгалтерии была взята на вооружение 1С версии 7.7, маркетинговые задачи решались с помощью системы «Marketing Analytic», в качестве CRM использовалась система «Монитор» версии 3.0. Все системы работают в своих локальных базах данных, за исключением 1С, работающей непосредственно на исходных данных из ЕБД.
Время показало корректность данного подхода. Когда же стал актуальным вопрос по оптимизации товарных запасов компании, выбор напрашивался сам собой – необходимо внедрить, по аналогии, независимую систему планирования товарных запасов. Проанализировав рынок систем прогнозирования и планирования, пришли к заключению, что не существует готовой удобной и достаточно гибкой системы, которая бы позволила решать задачи компании в вопросах прогнозирования и планирования продаж, планирования закупок, и, в общем, в вопросах оптимизации движения товарных потоков.
Использование существующих математических систем (к примеру, Statistica, SPSS, Sales-Forecast и др.) показалось неэффективным и нецелесообразным ввиду относительно высокой стоимости продуктов и излишней локализации решаемых задач. Поскольку поиск систем, удовлетворяющих нашим потребностям, не привел к ожидаемому результату, пришлось браться за самостоятельную разработку и внедрение подобной системы, удовлетворяющей следующим требованиям:
1. Предоставление пользователю всей необходимой статистической информации как по каждой товарной позиции, так и по группам позиций за установленный анализируемый период, с необходимой дискретизацией – продажи, закупки, неудовлетворенный спрос, складской остаток, тенденции продаж и др.
2. Предоставление результатов прогнозов продаж на основании статистических данных на будущий отчетный период, с необходимой дискретизацией. Расчеты прогнозов должны быть представлены несколькими методами, с выбранным наиболее оптимальным результатом, и возможностью пользователем вносить свои корректировки по мере необходимости.
3. Предоставление всей необходимой информации по отдельной товарной позиции на текущий момент – продажи с начала отчетного периода, текущие остатки (как в целом, так и с разбивкой по всем филиалам), прогноз продаж до конца отчетного периода, складские нормативы, поставщики и их условия, сроки поставки товарных позиций, и мн.др.
4. Предоставление результатов аналитических расчетов по необходимым объемам и срокам закупки – по каждой товарной позиции, по группе позиций, по менеджеру, по поставщику, и т.д.
5. Формирование предварительных планов продаж, закупок и финансовых планов, как за отчетный период, так и за год, с установленной дискретизацией.
6. Формирование отчетов по состоянию склада с разбивкой по позициям, группам, срокам оборачиваемости, менеджерам, поставщикам, и т.п.
7. Возможность импорта (и экспорта) данных из БД существующей учетной системы и других локальных БД компании.
8. Простота в настройках и управлении.
9. Невысокая стоимость внедрения и сопровождения программного комплекса.
На основании представленных требований была разработана, реализована и внедрена в действие система, состоящая из следующих блоков:
- расчет и визуализация статистических и прогнозируемых данных, представление всех информационно-технических данных для каждой товарной позиции;
- расчет объемов товарных запасов и расчетных рекомендаций по текущим объемам закупок, для всех товарных позиций в целом, по группам, по отдельности для каждой товарной позиции;
- расчет и представление нормативов, а также всей текущей информации по остаткам, продажам, прогнозам и т.п. в текущем отчетном периоде, по отдельности для каждой товарной позиции;
Ввиду принятия решения о декомпозиции данных для каждого из направлений деятельности компании, для данной задачи также была сформирована собственная база данных, куда из ЕБД ежедневно, по расписанию (в ночное время), стекается вся необходимая для проведения аналитических расчетов информация – все движения по всем товарным позициям за прошедший день накопительным итогом. Хранение данных осуществляется в аналитической базе данных (АБД) на сервере под управлением MS SQL. Для наиболее качественного расчета прогнозов продаж и построения планов продаж и закупок в АБД также накопительно хранятся статистические помесячные суммарные данные по движению товарных позиций за прошедшие 48 месяцев (продажи, остатки, закупки и т.п.).
Поскольку специфика данного бизнеса не подразумевает частых постоянных отгрузок товарных позиций, было принято решение установить отчетный период средней длительности, то есть в рассматриваемом случае нам было достаточно ограничить себя месячными учетными периодами, и все проводимые расчеты по прогнозированию и планированию строить исходя из указанных временных интервалов. Согласно разработанному регламенту, ежемесячно, 25 числа, проводится расчет прогнозируемых продаж на последующие 12 месяцев, начиная со следующего, для каждой товарной позиции, каждый вновь полученный результат прогноза анализируется с прошлыми результатами прогнозов и фактическими движениями товарных позиций, с целью внесения корректировок в прогнозы и повышения общего качества прогноза; 15 числа следующего месяца проводятся очередные перерасчеты и вносятся корректировки. Все прогнозы строятся на основе методов с выделением трендов, сезонных компонент и величины погрешности; для каждой товарной позиции хранятся данные результатов прогнозов, полученных тремя-четырьмя методами, из которых система выбирает наиболее оптимальный.
Выбор наиболее оптимального метода прогноза происходит по разработанному и внедренному в систему алгоритму, позволяющему на основе различных параметров определить наиболее оптимальный вариант. Каждый из параметров, таких как величина погрешности, локальная динамика продаж, уровень неудовлетворенного спроса, маркетинговые экспертные оценки и т.п., имеет собственный вес, который может быть оперативно изменен аналитиком, в связи с объективными условиями. Поскольку сезонность является ярко выраженной, то, с целью снижения рисков, были введена система экспертных оценок и корректирующих коэффициентов, накладываемых на товарные группы по мере необходимости.
К примеру, перед входом в сезон автоматически повышается дискретность закупок с одновременным уменьшением заказываемого количества в каждой партии – система ежедневно отслеживает локальную динамику, вводит необходимые расчетные коэффициенты и выдает соответствующие рекомендации менеджерам. В добавление к этому, на полученные расчетные прогнозы накладываются экспертные коэффициенты (получаемые в процессе совместного обсуждения представителями подразделений по аналитике, продажам, закупкам, маркетингу, рекламе – к примеру, на основе метода Дельфи).
Полученные экспертные коэффициенты позволяют повышать либо понижать расчетные результаты прогнозов в зависимости от ситуаций, и в дальнейшем проводить анализ расчетных и фактических данных, с целью повышения качества будущих прогнозов. Данные в АБД хранятся в строго структурированном оптимальном виде и в случае необходимости могут быть экспортированы в любую систему (учетная система, бухгалтерская система, маркетинговая система, CRM система, а также электронные таблицы Excel либо Access) посредством прописанных протоколов и регламентов. С целью оптимизации бизнес-процессов менеджеров по закупке, логистике и аналитике был реализован интерфейс, позволяющий без особого труда получать и визуализировать всю необходимую информацию по движению товарных позиций, и принимать решение исходя из представленных системой рекомендаций. Интерфейс данной ИС представлен ниже в детализированном виде.
Программная реализация комплекса
Блок прогнозирования
Блок прогнозирования (Рис. 1) представляет пользователю все необходимые данные по товарной позиции (статистические, прогнозируемые, информационные), предназначен для менеджеров по закупкам, логистике, аналитике и содержит следующие элементы:
Рис.1. Блок прогноза - общий вид
1. Список товарных позиций в виде уникальных числовых кодов (юникоды). Юникод представляет из себя специально введенный цифровой код, индивидуальный для каждой товарной позиции. Кроме того, существует «Юникод-2», отражающий взаимосвязь между товарными позициями и объединяющий взаимозаменяемые товары.
2. Блок информации о выбранной позиции. Товарная группа, оптимальный поставщик, название, чертежный код, ответственный сотрудник, принадлежность к ABC-группе, цена закупки, цена продажи и наценка, срок поставки товара. Здесь под АВС-группой подразумевается оптимизированные маркетинговые группы, сформированные на основе распределения по объемам продаж, по объемам маржинального дохода, а также частоты и постоянства спроса.
3. Блок информации о режиме отбора. Группа по АВС-классификации, поиск товарной позиции по названию или чертежному коду. Раздел «Результаты поиска» (открывается при нажатии кнопки «Найти») содержит информацию о заданной строке поиска, о количестве найденных позиций, о найденных позициях (товарная группа, чертежный код, название, текущая цена по прайсу, принадлежность к АВС-группе, ФИО ответственного сотрудника), а также позволяет перейти к выбранной позиции.
4. Объем продаж в количественном выражении. Раздел содержит информацию об общем количестве проданного товара за последние четыре года (отсчет в прошлое, начиная от текущего месяца), а также погрешность прогноза по выбранному методу и прогнозируемая сумма продаж на следующий год.
5. Графическое представление статистических данных. Данный блок позволяет отображать помесячно в виде графика или гистограммы статистические данные о фактических продажах, неудовлетворенном спросе, возможных продажах, остатках, закупках, трендах и прогнозируемых продажах.
6. Результаты прогноза. Данный блок содержит расчетную информацию о прогнозируемых продажах, как в целом по компании, так и по филиалам, а также доверительный интервал прогноза. Кроме того, в системе существует возможность для менеджера (аналитик, логист либо менеджер по закупкам) вносить свои данные прогноза, по усмотрению, с сохранением в АБД.
7. Результаты прогнозов. В данном блоке представлена информация о суммарных результатах прогнозов и их погрешностях. Пользователь обладает возможностью выбрать результаты другого метода, отличного от выбранного системой, с сохранением результата в АБД (либо внести в систему свои данные по прогнозируемым продажам, см. «блок 6»).
8. Настройка режимов отображения графика. Установленные галочки показывают, какие данные будут отображаться в графическом виде. Кроме того, в данном блоке реализована возможность установки интервала сетки отображения на графике и возможность представлять данные «как есть» либо в сглаженном виде.
9. Блок для перехода в другие разделы комплекса. В данном блоке реализованы возможности для перехода в другие разделы программного комплекса – в раздел с информацией о прогнозируемых помесячных запасах на год и необходимых закупках в текущем месяце для выбранной товарной позиции; для перехода в раздел управления закупками; для перехода в раздел с информацией о продажах, закупках и складских остатках за предшествующие 48 месяцев, а также колонкой, позволяющей менеджерам вносить и сохранять в АБД свои данные по прогнозам (рис. 2).
Рис. 2. Численное представление статистических данных
10. Меню программного комплекса. С помощью главного меню программного комплекса пользователь может настраивать режим отбора позиций прайс-листа: по товарным группам либо по сотруднику; запускать справочную систему комплекса; фильтровать список анализируемых товарных позиций; выбирать анализируемого сотрудника (данный выбор реализован для руководства; менеджеры могут выбрать только себя); выбрать необходимые отчеты (см. Рис.3), возможность формирования которых разграничена по компетенциям сотрудников. Реализация отчетов проведена как непосредственно в самой системе (в случае небольших отчетов для выполнения оперативных мероприятий), так и с экспортом во внешнюю среду (в частности, в Excel). Различных отчетов множество, и их количество постоянно растет с увеличением числа задач, из базовых были реализованы следующие:
- отчет о складских излишках с потоварной детализацией по складам, с дискретизацией по ответственным сотрудникам и товарным группам;
- отчет об излишках товаров в ожидаемом приходе;
- отчеты по дилерским обязательствам с детализацией и сводные;
- отчеты о состоянии склада по оборачиваемости товара, с разбиением на группы товаров, сроки оборачиваемости, товарные группы, ответственных менеджеров и т.п.;
- отчеты о потребностях в товарных позициях с учетом изменяющихся сроков поставки;
- отчеты по контролю заказов за выбранные отчетные периоды с разбивкой по категориям (к примеру, заказано в рамках нормативов, больше либо меньше нормативов);
- отчеты о недостатках товарных позиций на складе и превышении нормативов;
- отчеты о контроле деятельности менеджеров; сравнительные отчеты по различным периодам (прогнозы, планы, факты, отклонения и т.п.);
- статистические отчеты о движении товарных позиций в различных отчетных периодах (с учетом остатков, неудовлетворенного спроса, сроков оборачиваемости и т.п.);
- отчеты об остатках на складах филиалов (с учетом всех возможных статистических данных за выбранные периоды);
- и многие другие.
Рис. 3. Меню «Отчеты»
Рис. 4. Отчет «Экспорт прогнозов в Excel»
В качестве примера представлен отчет «Экспорт прогнозов в Excel», предназначенный для экспорта из ИС данных по прогнозу продаж и плану закупок в случае необходимости. К примеру, в случае обращения к менеджеру по закупкам нового поставщика (либо одного из существующих, но с новыми условиями), менеджер может оперативно провести анализ прогнозов продаж на перспективу и оценить ориентировочное количество закупаемого товара, с разбивкой по месяцам (варьируя в отчете сроки поставки, суммы и т.п.). Для этого менеджер выбирает позицию из списка (блок 1) и, собирая найденные результаты (блок 2), перемещает их в поле анализируемых позиций (блок 3; либо выгружая их из файла Excel – блок 4), затем, устанавливая интересующие анализируемые периоды (блок 5), выбирает предмет анализа (закупки либо продажи, блок 6) и проводит расчет с одновременным экспортом данных (блок 7). Таким образом, в случае каких-либо непредвиденных обстоятельств, менеджер может оперативно провести аналитические расчеты по интересующим его позициям, и экспортировать полученные результаты в иную систему для дальнейшей обработки и импорту в учетную систему. По аналогии реализованы и остальные отчеты.
11. Вспомогательный блок. Данный блок содержит вспомогательную информацию. В частности, здесь реализована функция калькулятора, функция зуммирования графиков, а также функция представления подневных данных о товарной позиции по всем складам (с учетом филиалов) за последние 30 дней: продажи, неудовлетворенный спрос, остатки по центральному офису и по филиалам.
12. Блок выбора периодов для графика. В данном блоке выбираются интересующие периоды, и по мере нажатия кнопки «Показать» открывается дополнительное окно с графиком по выбранным годам.
13. Блок информации о проведенных корректировках. Блок просмотра, сохранения и удаление проводимых корректировок по прогнозам в АБД.
14. Блок дополнительной информации о товаре В случае необходимости ответственный менеджер обладает возможностью внесения какой-либо дополнительной информации о товаре в АБД.
Блок расчета необходимых закупок
Блок расчета закупок (Рис. 5) представляет пользователю все необходимые данные об остатках и закупках по каждой товарной позиции, предназначен для менеджеров по закупкам, логистике, аналитике, и содержит следующие элементы:
Рис. 5. Блок закупок - общий вид
- Список позиций. В данном блоке указаны основные сведения о позициях – название, код, принадлежность к товарной группе, принадлежность к группе по АВС-анализу, остатки на складах, резервы, количество заказанной продукции, а также рекомендуемые количества для закупки, пополнения ассортиментного запаса филиалов и перемещения излишков со складов филиалов на центральный склад. Расчет рекомендуемых количеств осуществляется по разработанному алгоритму, согласно которому расчет заказа осуществляется в том случае, если расчетный остаток товара к моменту прихода его, при условии заказа на текущий день, ниже минимального нормативного порога, а рекомендуемое прогнозируемое количество берется из расчета наличия нормативного запаса по товарной позиции к моменту прихода товара, с учетом текущего срока поставки (текущий срок поставки определяется автоматически, исходя из текущей минимальной цены поставщика).
- Информация о выделенной позиции. В данном блоке выводится необходимая дополнительная информация о выделенной товарной позиции – ФИО ответственного специалиста, название, коды, поставщик, срок поставки, складской остаток, кнопка «Перерасчет», закупочная и прайсовая цены, наценка для выбранной позиции. Кнопка «Перерасчет» предназначена для проведения расчета величины закупки для произвольного срока поставки и/или произвольного остатка на складе (необходимо для различных форс-мажорных обстоятельств – обращение нового поставщика с более выгодными условиями, анализ остатков в различные периоды времени, и т.п.).
- Установка приоритетов закупки. Блок управления отбором позиций по приоритету – наивысший приоритет у тех позиций, которые должны быть закуплены в первую очередь. Переключатели позволяют выбрать необходимый режим отбора, позволяющий открывать списки позиций с выбранным уровнем приоритета («Высокий», «Средний» или «Низкий»). В первом режиме представлены позиции, которые необходимо заказывать в настоящий момент. Во втором – те позиции, которых на складе недостаточно, но эти позиции уже заказаны. Условие того, заказана позиция или нет, определяется либо автоматически – раз в день по полученным данным из базы, либо специалистом по закупкам – при нажатии кнопки «Заказано» для позиции из первой группы. В последнем случае позиция из первой приоритетной группы перемещается во вторую. В третьем, низком, режиме приоритета – позиции, которых на складе достаточно.
- Блок управления записями. В данном блоке реализованы функциональные возможности, позволяющие переводить товарные позиции в иные уровни приоритета, переходить в блок «Прогнозы», производить поиск необходимых товарных позиций и экспортировать полученные данные в Excel.
- Результаты прогнозов. В данном блоке указаны различные варианты расчета количества товара, необходимого к закупке. Выбранный автоматически вариант расчета выделяется синими цифрами.
- Меню выбора товарной группы. Позволяет отобразить в списке товарные позиции только из определенной товарной группы, с целью формирования дискретных заказов.
- Информация о поставках. В данном блоке представлена информация о датах и количестве ожидаемых поставок товара. В случае, если дата ожидаемой поставки меньше текущей, данные выделяются.
- Суммы на закупки. В указанном блоке представлены данные по рекомендуемым закупкам в суммовом выражении. Ниже указано количество позиций в списке выбранного приоритета.
Блок расчета складских нормативов и запасов
Расчета складских нормативов и запасов (Рис.6) представляет пользователю все необходимые данные о локальном движении по товарной позиции, а также данные по складским нормативам по позиции на весь отчетный годовой период; предназначен для менеджеров по закупкам, логистике, аналитике, и содержит следующие элементы:
Рис. 6. Блок расчета складских нормативов и запасов - общий вид
- «Графическое представление складских нормативов». График планов по складским запасам на конец каждого месяца (на ближайшие 10 месяцев, включая текущий; прогноз и допустимый интервал).
- «Численное представление складских нормативов».«Статистика и прогноз продаж и остатков». Блок информации о продажах и неудовлетворенном спросе в текущем месяце.
- «Статистика остатков с дискретизацией». Блок информации о складских остатках с учетом остатков на складах филиалов (с всплывающей детализацией по остаткам и излишкам по каждому из филиалов), резервов и размещенных заказов.
- «Рекомендации по закупкам». Блок информации о закупках – двухмесячный запас на следующие два месяца и необходимые закупки для его пополнения (а также для пополнения запаса на текущий месяц, при необходимости).
Таким образом, реализовав представленный программный комплекс, была решена задача по оптимизации бизнес-процессов сотрудников компании, непосредственно вовлеченных в процесс товародвижения, а также повышен качественный уровень самой системы планирования в целом. Реализованный и внедренный программный комплекс позволяет менеджерам качественно оптимизировать свою оперативную деятельность, предоставляя полный набор необходимой информации для принятия решения, и значительно снижая время на обработку и анализ информации; руководителям – позволяет анализировать состояние складских запасов в оперативной и среднесрочной перспективе, контролировать деятельность сотрудников компании, оперативно вносить необходимые корректировки как в деятельность сотрудников, так и в процессы деятельности компании.
Кроме того, на основе представляемых системой результатов производится формирование планов продаж и закупок (как в количественном, так и в суммовом выражении). К сожалению, ввиду большого объема информации по описанию реализованных блоков в представленной публикации автором кратко показаны только общие результаты без детализации каждого из реализованных блоков. Однако, даже такой краткий вид способен дать приблизительное представление подхода к реализации комплекса по прогнозированию и планированию.
Блок расчета нормативов по складам филиалов и дистрибьюция
Поскольку задача по реализации и внедрению программного комплекса по оптимизации товарного портфеля была успешно выполнена, было принято решение о реализации следующего блока – для оптимизации распределения товара среди филиалов компании. По аналогии с первым блоком, был реализован и внедрен программный комплекс, позволяющий прогнозировать потребности филиалов компании и планировать распределение товаров между ними. В частности, по аналогии был введен в эксплуатацию блок по прогнозированию потребностей филиалов, и дистрибьюции товара между ними (Рис. 7), блок по расчету отгружаемого товара (Рис. 8), а также блока по расчету нормативов и складских запасов по филиалам (Рис. 9), с учетом глубины детализации (Рис. 10, Рис. 11):
Рис. 7. Блок расчета потребности филиалов и дистрибьюции
Рис. 8. Блок расчета отгружаемого на филиалы товара
Рис. 9. Блок расчета складских нормативов
Рис. 10. Блок расчета нормативов по филиалу
Рис. 11. Статистика запасов по филиалу
Блок финансово-экономического планирования
В дополнение к описанному выше последним блоком шла реализация системы финансового планирования, как в оперативной, так и в долгосрочной перспективе. Финансовые планы строились исходя из планов продаж, планов закупок и прочих потоков (Рис. 12). Данный блок общей системы планирования позволяет не только представлять данные в графическом виде (это, в принципе, может быть сделано в любой табличной системе – к примеру, в Excel), но также позволяет в полуавтоматическом режиме осуществлять расчет прогнозируемых «всплесков» и «провалов», и выдавать расчетные рекомендации о потребностях в заемных средствах и оптимальных подходах в их погашении (Рис. 13).
Безусловно, результаты программных расчетов не являются элементом, обязательным к исполнению. Однако, данный элемент в значительной мере упрощает работу специалистов в области экономики и финансов, позволяя им рассматривать различные варианты развития событий, «играя» с различными параметрами, с целью достижения наиболее оптимального результата. Сразу хочется отметить, что данная методология для рассматриваемой компании позволила достаточно точно спрогнозировать развитие событий в деятельности компании на среднесрочный период (1 год), и по факту расхождение с прогнозируемыми данными за данный временной интервал составило менее 0,5% в общем суммовом эквиваленте. Достаточно неплохо для крупной компании, на мой взгляд.
Рис. 12. Блок финансового планирования в общем виде
Рис.13. Блок расчета кредитов и их погашения
Выводы
С целью оптимизации товарного портфеля рассматриваемой в качестве примера компании были формализованы и откорректированы процессы, непосредственно влияющие на формирование товарного портфеля компании, а также разработан, реализован и внедрен программный комплекс, позволяющий проводить прогнозирование продаж и планирование закупок в оперативной и долгосрочной перспективе. В основе комплекса лежит идея расчета прогноза продаж индивидуально для каждой товарной позиции, на основании статистических данных по продажам и неудовлетворенному спросу в предшествующих периодах, а также различных экспертных (маркетинговых) коэффициентов. Статистические данные рассматриваются с учетом нехарактерных пиков как продаж (к примеру, в случае крупных разовых сделок), так и неудовлетворенного спроса (с учетом сезонного фактора, мониторинга конкурентами и т.п.). Для каждой товарной позиции формируется помесячный прогноз и план продаж на год вперед несколькими методами, из которых автоматически выбирается наиболее оптимальный для каждой товарной позиции. При этом у менеджера по закупкам (логистике, аналитике) существует возможность вручную установить иной метод расчета прогноза, либо задать значения прогноза, построенного самостоятельно.
Резюмируя, отмечу, что на основе рассчитываемых прогнозируемых значений, был реализован программный комплекс:
- для формирования прогнозов для целого ряда параметров (продажи, закупки, маржинальный доход и т.п.);
- для получения статистических данных (продажи, закупки, неудовлетворенный спрос, маржинальный доход, дебиторской и кредиторской задолженностях и др.);
- для оперативного анализа торгово-закупочной деятельности компании;
- для оперативного распределения товара между складами филиалов;
- для долгосрочного финансово-экономического планирования.
Комплекс включает в себя:
- программное приложение – рабочее место менеджера, позволяющее получать всю необходимую информацию для формирования заказа поставщику и распределению товара между складами компании (статистика, прогноз, рекомендации программы по закупке, товарные характеристики, отчеты);
- программное приложение – рабочее место аналитика, с еще более широкими возможностями;
- программное приложение – рабочее место руководителя, с целью осуществления контроля как за деятельностью менеджеров, так и за процессом товародвижения, и проведения анализа;
- программные приложения для получения аналитических отчетов (как непосредственно из системы, так и посредством экспорта данных в Excel), в том числе интерактивные;
- программное приложение для руководителей финансово-экономических подразделений для формирования финансовых планов на долгосрочную перспективу;
- другие средства для обеспечения функционирования программного комплекса.
С появлением в компании комплекса появилась возможность:
- прогнозировать потребности рынка в товаре;
- своевременно формировать оптимальный складской запас для предотвращения неудовлетворенного спроса;
- предоставлять поставщикам план закупок, основанный на прогнозе, и получать за счет этого более выгодные условия сотрудничества;
- улучшить структуру складских запасов филиалов, за счет чего снизить издержки и расширить ассортимент товаров;
- оптимизировать финансово-экономическую деятельность компании.
Анализируя результаты внедрения программного комплекса в рассматриваемой компании, уже по прошествии года можно было говорить о полученных результатах (сравнения результатов по месяцам, непосредственно перед внедрением комплекса в эксплуатацию и год спустя):
- объем продаж вырос на 41%;
- уровень неудовлетворенного спроса уменьшился на 50%;
- произошло снижение складских запасов на 7%;
- произошло снижение складских излишков (неликвиды, балласт) на 71%.
Безусловно, столь впечатляющие успехи по оптимизации товарного портфеля компании достигнуты не только лишь внедрением программного комплекса. Это – результат серии мероприятий по оптимизации товародвижения, таких как формализация и корректировка бизнес процессов; разработка, внедрение и контроль регламентации по взаимодействию между сотрудниками и подразделениями; осуществление анализа деятельности сотрудников и контроль исполнения ими необходимых мероприятий, и т.п. Программный комплекс в данном случае выступает только лишь как технический инструмент, позволяющий качественно улучшить условия деятельности. Однако необходимо отметить, что без подобного инструментария достигнуть столь качественного результата было бы достаточно сложно.
В связи с этим, родилась идея двигаться дальше в том же направлении, и внедрить подобные системы в деятельность подразделения по дистрибьюции товаров в регионы (по филиальной сети), а также реализовать по подобной методологии инструменты финансового планирования, основанные на планах продаж и закупок с дальнейшим расширением сферы финансового планирования. Обе поставленные задачи также были успешно реализованы, и показали отменные результаты. Таким образом, можно подвести итог – рассмотренная выше методология оказалась достаточно мощным и гибким инструментом, позволяющим повышать качественный уровень торгово-логистической деятельности компаний, планировать как товарно-логистическую, так и финансовую деятельность компании, и увеличивать ее прибыль.
Фото в анонсе: pixabay.com
Артем, по пунктам:
1. Не понятно - зачем Вам писать АБД? Она же у вас уже есть (см. выше). Если Вы имеете виду некий комплекс для расчетов и т.п., по аналогии описанного мной, то сроки будут исчисляться от 1 месяца до 3 месяцев. Это будет зависеть от того, какой сложности комплекс Вы планируете, какие задачи ему необходимо решать, на чем будет разрабатываться, сколько человек будут ''ваятелями'' и т.п.
2. Нет, погрешность измеряется среднеквадратичным отклонением. Сравнения план-факт влияют на корректировку методов прогноза (для повышения его ''качества''); этакая система предиктор-корректор.
По поводу динамики продаж вверх-вниз. Как правило, на складах я держал запас в размере ''продажа за период +N%'' (N может варьироваться, к примеру от 30% до 70%). Если вдруг динамика роста продаж прет вверх, то нехватка покрывается из этого N и тут же включается система дозакупки. Если, наоборот, идет вниз, то при следующих плановых дозакупках объемы дозакупок снижались на ''нераспроданную дельту''. И всё. Что-то типа страхового запаса. Конечно же, в этом случае оборачиваемость несколько снижается. Однако в процессе выбора между шашечками и ехать, я основывался, в первую очередь, на эффективности деятельности компании в целом, пусть даже и с некоторым ущербом для оборачиваемости. Но это сугубо индивидуально - на некоторых рынках более оптимальным является отклонение в сторону неудовлетворенности клиента при снижающейся оборачиваемости.
3. Круть! :) если Ваши б-м еще и курьерами и экспедиторами выступают, то вообще здорово - какая экономия ФОТ! шутка, конечно же... Но в каждой шутке обычно присутствует шутка. Вообще, это не задача б-м заниматься анализом и формированием прогнозов. Если номенклатура небольшая и фирмочка махонькая, то да, можно и на них возложить. Но в больших компаниях с большой номенклатурой этим должны заниматься аналитики, а б-м должны выставлять нормативы по уже посчитанным прогнозам.
4. Это здорово, вещь действительно полезная. Уже неоднократно убеждался, чуть-чуть исправив бизнес-процесс, можно добиться офигительнейшего результата - это тот самый случай. Практика показывает, что на получение данных, общение с сотрудниками из других отделов, получение уже существующей в компании информации, сотрудники тратят львинную долю своего рабочего времени. Устранив это ''горлышко'' можно высвободить для них кучу времени. Но, опять же, это работа оперативная... А прогнозирование - работа тактическая и в некоторых случаях стратегическая. То есть одно не заменяет другое, а лишь дополняет его!
5. Ну если на пальцах... Есть два поставщика - П1 и П2, со сроками поставки, соответственно, 20 дней и 30 дней. Цены на товар Т у них, допустим, 1000 руб и 800 руб. Система ежедневно анализирует условия поставщиков и выбирает, на основе разработанных алгоритмов (экономических), какой поставщик сегодня более оптимален (сколько товара осталось, на какой срок, сколько будет стоить закупка у того и другого, во сколько обойдется транспортировка и т.п.). На основе проведенного анализа выбирается поставщик, пусть П2. После этого система считает - сколько товара останется на складе, если сегодня дозакупок проводиться не будет (учитывается фактический товарный остаток на складе, товар в пути, который должен прийти к определенному сроку, и размещенные заказы, тоже со сроками поставки). Если будущий остаток выше минимального предела, система по данной позиции дает отбой. Если равен или ниже, включается процесс расчета, к примеру, норматив минус текущий остаток плюс объем ориентировочных продаж к моменту поступления товара на склад (при условии сегодняшнего заказа). Примерно так...
По п. 2 и далее:
2) Не, без формулы не пойму. Не секрет, что Вы берёте для расчёта дисперсии при определении погрешности (извините, мы сами с филологическим образованием)?
3) Вам смешно, а вначале так и было: заказ сделал – поехал сам как экспедитор к поставщику (в районе 2000 года).
4) В идеале я бы и хотел избавить сотрудников от рутинной работы.
5) Т.е. «текущий срок поставки определяется автоматически, исходя из срока поставки поставщика, имеющего на данный момент минимальную цену»? Классно, только, боюсь, нам не пригодится – у наших поставщиков цены могут меняться несколько раз в неделю, сравнивать цены можно только по счетам, полученным в один и тот же день.
6) «Циклическая компонента, которая редко берется в расчет» - это что? Она как-то связана с тем, что для определения тренда я беру данные за прошлую неделю, а не за месяц (для повышения «чувствительности» прогноза)?
Артем, если честно, за неимением времени ''ниасилил'' текст :) Постараюсь на выходных вчитаться, поглядеть Ваши идее более детально.
Мне, получается, тоже надо извиняться, не сразу ответил.
1. Документ формируется не в учётной системе, т.к. мы вроде бы сошлись во мнении, что учётную систему нельзя перегружать аналитическими функциями - для них создаётся АБД. В принципе, у нас такой подход уже практикуется: сейчас у нас даже запрещено делать отчёты в учётной БД – есть параллельная расчётная, со вчерашними остатками.
Программа формирует документ по расписанию (раз в неделю), после чего в порядке автообмена экспортирует в 1С. По факту импорта документа 1С генерирует задачу менеджеру «Проверить документ». Менеджер проверяет и проводит документ, перемещения с этого момента начинают формироваться, исходя из новых норм. Если менеджер не проверяет, на первом этапе я бы оставлял документ непроведённым, а на втором, когда система отлажена и менеджеры делают минимальные изменения, проводил бы документ автоматически, если менеджер в течение рабочего дня не внёс в него изменения.
2. Максимальный остаток – это МО-1+НП (норма минимального остатка (МО) -1+ норма поставки (НП)). Дискретность поставок сейчас составляет 1-5 раз в неделю для филиалов с удалением в 500 км, и до 2 раз в день для филиалов с удалением до 20 км. И тенденция складывается в пользу дальнейшего увеличения частоты поставок: количество филиалов растёт, ассортимент растёт, особенно в этой связи важно, что растёт оборот В- и С-позиций. Так что уйти от увеличения частоты поставок не получится.
3. Ответственное лицо – менеджер. Поскольку в 1С 8 уже есть функционал, позволяющий автоматически создавать задачи менеджерам, то, получается, проверка менеджером корректности автоматически сгенерированного документа будет происходить в учётной системе. Если создание такого функционала в АБД – простая задача, то и этот процесс можно оставить в АБД. В идеале хотелось бы выводить в текст задачи максимальные изменения норм, чтобы, если эти изменения незначительны, менеджер мог оставить задачу без рассмотрения.
4. Создание отдельных файлов нужно, я надеюсь, будет только на первом этапе. Конечно, намного изящнее вариант, когда АБД непосредственно меняет реквизиты, к которым впоследствии обращается учётная база (УБД). Но пока мы не знаем, насколько этот процесс безупречен, его надо контролировать вручную. Работать в УБД с документами, в которых больше 1000 позиций – очень неудобно (они очень подолгу открываются, сохраняются, проводятся). Комментарии отображаются в журнале документов и нужны опять же для того, чтобы в журнале документов сразу найти нужный, а не ждать по 2-3-5 минут, пока откроется документ, чтобы убедиться, что это не то. Так что комментарии к документам, с которыми потом предвидится работа, менеджеры у нас заполняют – жизнь заставила. Писать их, конечно, никто не любит, поэтому если есть возможность генерировать их автоматически, то её надо использовать.
5. В идеале – по расписанию. Сисадмин должен контролировать, что процесс проходит успешно, т.е. выполнились все нужные предыдущие автообмены, ничего не заткнулось. Корректность промежуточных аналитических данных, честно говоря, не знаю, нужно ли вообще контролировать. Итоговые значения новых норм минимального остатка (МО) и норм поставки (НП) контролируют менеджеры и начальник отдела, они же инициируют изменения в процедуре.
6. к п. А. Количество полей увеличить, конечно, можно. Но нужно ли? Группировки, по опыту, нужны в трёх случаях. «Производитель» обычно нужен при изменении ассортимента (обновлении модельной линейки, появлении новой линейки) и при подготовке какой-либо акции. «Тип» нужен для рутинной работы. «Склад» нужен постольку, поскольку есть разные форматы магазинов.
Посмотреть на другие ТЗ, конечно, интересно. На martem@enkor.ru , пожалуйста. Или прямо тут, на форуме – вдруг ещё кому-то будет интересно.
7. к п. Б. Цена – розничная. Перегружать таблицу этого документа ещё и другими ценами и себестоимостью смысла не вижу, это же не приходная накладная.
8. к пп. 6, 7, 8. Неделя кажется мне оптимальным периодом, т.к. у нас по ряду товарных групп есть очень резкая сезонность. Индекс сезонности (ИС) мы можем просчитать на материале предыдущих 5 лет. ИС, конечно же, используется дополнительно к тренду, заданному предыдущей неделей.
Грубость анализа обусловлена дискретностью итоговых величин: это будут в лучшем случае штуки, очень часто это будут упаковки. Будет в итоге округляться до единицы 0,6 или 0,58375842 – не так уж важно. Тем более что у меня часто идёт округление «вверх до целого», т.е. всё равно, 0,000194837457 или 0,9974837: в норму будет занесена единица.
«Брать несколько трендов по длине периодов» - интересное предложение. Для позиций с большим размахом ИС и позиций А-группы, на самом деле, целесообразнее брать меньший период (предыдущую неделю), чтобы увеличить чувствительность нормообразования к тренду. А для позиций В- и С-групп с низким или средним размахом ИС – брать предыдущий месяц, чтобы сгладить случайные всплески продаж, не допустить их влияния на нормы минимального остатка (МО) и нормы поставки (НП).
9. к пп. 10, 11. Нерабочие дни не учитываются, т.к. продажи в эти дни равны 0, а остатки больше 0. Поэтому при недельном учётном периоде перерыв в 2 дня (например, учёт в магазине или праздники, которые не каждый год выпадают на эту неделю), может создать статистическую картину понижающегося тренда, а это ни к чему, тем более что отложенный спрос никто не отменял. Или вопрос относился не к учёту нерабочих дней?
10. к пп. 12, 13. Период оборота (ПО) – это количество дней, за которое продаётся имеющийся на складе товар. В данном аналитическом процессе это ПО – исторический показатель, и к нюансам работы с поставщиками отношения не имеет (заказы поставщикам делаются по другому алгоритму, хотя нормы минимального остатка (МО) и нормы поставки (НП) в нём участвуют). Просто если ПО какой-то позиции выше среднестатистической в своей группе, то менеджер должен или обосновать присутствие этой позиции в ассортименте, или убрать её.
Поскольку при расчёте ПО в знаменателе оказывается средняя продажа за неделю, то надо предусматривать замену 0 (если средняя продажа за неделю=0), чтобы формула работала.
11. к п. 14. У менеджера есть общие нормы для отдела, необходимость уменьшать ПО для увеличения оборота в условиях дефицита оборотных средств. По конкретным позициям (а их у него 3-5 тыс.) менеджер устанавливает нормы сам.
12. к п. 15. Постоянство складского запаса (ПСЗ) – это тоже исторический показатель. ПСЗ зависит от того, насколько правильно назначены нормы МО и НП, а также насколько центральный склад удовлетворял заказы филиалов.
13. к п. 16. Поскольку с наличием товара тоже может быть не всё хорошо, и ПСЗ может оказаться равным 0 (за всю неделю ни разу не появился на складе или был каждый раз продан в день поставки), то опять же пришлось вводить заменяющий коэффициент.
Неудовлетворённый спрос в данном аналитическом процессе не учитывается. При возникновении потребности в каком-то товаре создаётся документ «Счёт», по проведению которого товар из этого счёта заносится в резерв и, если это не особо дорогостоящий или крупногабаритный товар, добавляется в следующее перемещение с центрального склада в данный филиал или заказывается поставщику. Если это дорогостоящий или крупногабаритный товар (с реквизитом «не учитывать резерв»), то он добавляется в следующее перемещение с центрального склада в данный филиал или заказывается поставщику только после оплаты счёта. Т.е. в итоге неудовлетворённого спроса у нас как бы нет. Но, в принципе, можно сделать режим расчёта с вычитанием резерва из остатков, чтобы учесть неудовлетворённый спрос. Надо только, опять же, ввести какие-то повышающие коэффициенты для случаев, когда остатки окажутся отрицательными.
14. к п. 21. Допустимое количество отгрузок в неделю (ДКОН) – это норма, учитывающая стоимость складских операций. Первоначально присваивается ДКОН=7. Если стоимость перемещения (в смысле – обработки на складе при отгрузке и обработки в филиале при приёмке) какой-то позиции больше стоимости хранения в филиале в течение хотя бы 7 дней, то присваивается ДКОН=1, и тогда любое превышение будет работать на увеличение нормы поставки (НП). Т.е. если ДКОН=1, а отгрузок за неделю произошло 3, то, при отсутствии динамики ПСЗ, ПО и ИС, норма поставки (НП) по формуле увеличится в 3 раза.
15. к п. 22. Если выполнение заказа (ВЗ) не 100%, а 30% или 70%, то нормы минимального остатка (МО) и нормы поставки (НП) для филиала не изменяются.
16. к п. 23. «Случайный» всплеск приведёт к некоторому увеличению нормы минимального остатка (МО) и нормы поставки (НП). Если на следующей неделе растущий тренд не подтвердится, МО и МП уменьшатся, и тогда возникнет некоторое превышение складского остатка нормы МО-1+НП. У нас уже сейчас есть в УБД отчёт, который формирует перечень излишков, т.е. формируется готовый документ «Перемещение»: можно легко отобрать такой товар и отправить его на центральный склад. Излишки возникают не только после понижения МО и МП, но и вследствие сезонности.
Если возврат излишков на центральный склад происходит не каждую неделю, то, значит, период оборота по позиции, имевшей «случайный» всплеск продаж, увеличится, но, поскольку уже через неделю после действительно случайного всплеска нормы уменьшатся, повторных излишних поставок не будет.
17. к пп. 24, 25, 26.
17.1. В основном хранение и распределение идёт централизованно. Есть ещё 1 дополнительный распределительный центр, но он работает не по всей номенклатуре.
17.2. АВС – по объёму продаж, что у нас фактически = частоте спроса. Мы очень клиентоориентированная компания ;)
17.3. Мы делим неудовлетворённый спрос на подтверждённый и неподтверждённый. Подтверждённый формируется документами «Счёт». Неподтверждённый формируется документами «Заказ покупателя» (это такой документ, на основании которого водится документ «Счёт»). В документ «Заказ покупателя» вносятся все позиции, которые запросил покупатель (или файл с заявкой покупателя). На ряд отсутствующих позиций программа предлагает замены, и в документ «Счёт» попадают уже замены. Так что неподтверждённый спрос имеет смысл учитывать только по безальтернативным позициям. Сейчас мы его практически не учитываем.
18. Я бы поостерёгся учитывать неудовлетворённый спрос наравне с фактическими продажами.
19. Прежде чем усложнять методологию расчёта, хотелось бы убедиться, что точность анализа будет существенно больше и превысит дискретность норм, на корректировку которых направлен анализ.
20. Анализ транспортных расходов и складских расходов (не только на хранение, но и на обработку товара) я бы тоже провёл, но в рамках другого анализа. Стоимость финансов известна: это стоимость кредита.
21. Схему данного процесса я бы, разумеется, не менял, т.к. привык к этой и пока не вижу, что она уже исчерпала свои возможности. ;)