Склад: шпаргалка для оптимизатора

В последнее время все больше российских торгово-закупочных компаний среднего уровня сталкиваются с проблемой формирования и поддержания оптимального товарного складского запаса. Зачастую подобное связано с отсутствием четкой и ясной стратегии деятельности компании и, как частный случай, некорректным подходом к самой методологии формирования товарного портфеля (либо вообще отсутствием таковой). Подавляющее большинство подобных компаний делают упор лишь на оперативное управление, в то время как вопросы снабжения и распределения товара целиком и полностью находятся в компетенции менеджеров по закупке и логистике.

Последние, в большинстве случаев, не имеют прописанной методологии и действуют по наитию, либо применяя простейшие схемы (к примеру, просто переадресуя заказы от клиентов своим поставщикам, либо формируют запасы, исходя из средних продаж за некоторый выбранный период). Надо отметить, что в последнее время в связи с обострением конкуренции на большинстве российских рынков руководители компаний пытаются решать данную проблему. Однако в большинстве случаев они ограничиваются лишь внедрением в некой информационной системе (как правило, учетной системе компании) тех же самых простейших алгоритмов, которые применялись менеджерами в «ручном» режиме.

Подобный подход, безусловно, способен привести к некой оптимизации оперативных бизнес-процессов. Но касается он, в основном, только оптимизации бизнес-процессов деятельности менеджеров как таковых, не являясь при этом каким-то качественным инструментом по оптимизации общего процесса по формированию сбалансированных складских запасов. Плюс к тому, подобные решения дают результат лишь в краткосрочной перспективе, в то время как причины «болезни» по-прежнему не устранены. А потому первоначальная задача по оптимизации товарного портфеля компании зачастую остается нерешенной.

Таким образом, в большинстве компаний, пытающихся как-то реорганизовать и оптимизировать свои процессы, происходит подмена понятий – вместо качественной замены процессов происходит некоторое видоизменение существующих. И только редкие компании пытаются идти дальше, пытаясь внедрить более сложные механизмы в процесс формирования сбалансированного товарного портфеля, с целью как оптимизировать деятельность менеджеров по логистике и закупкам, так и получить мощный и достаточно гибкий инструмент управления данными по движению товарных потоков.

Как правило, результатом внедрения становится некая информационная среда (ИС), представляющая из себя программный комплекс, подключенный к некой базе данных (БД), из которой (и в которую) извлекается вся необходимая информация о товародвижении в целом и о самих товарах в частности. При этом указанная ИС обладает достаточно серьезным математическим аппаратом, позволяющим проводить сложные и достаточно точные вычисления с целью проведения расчетов по прогнозируемым продажам (остаткам, перемещениям и др.) в течение будущих отчетных периодов, и, как итог, построением планов продаж, закупок, финансовых и т.п.

Существует множество вариантов решения задачи по внедрению информационных систем, позволяющих проводить оптимизацию товарных потоков. Общемировая тенденция такова, что наибольшее распространение в мире получили глобальные ИС класса ERP, MPR и т.п., охватывающие практически всю деятельность компании в целом. Это продукты от таких корпораций как SAP, Microsoft, Oracle и др. При всех их несомненных преимуществах, внедрение подобных систем обходится компаниям во многие миллионы рублей, чего не может себе позволить большинство отечественных компаний среднего уровня. В добавление к этому, на постсоветском пространстве на текущий момент недостаточно квалифицированных специалистов, способных не только внедрять и настраивать столь сложные системы, но и поддерживать и модифицировать их под собственные нужды компании (а этого зачастую требует специфика бизнеса).

Таким образом, для большинства отечественных компаний подобные системы не приемлемы, по крайней мере в обозримом будущем. Таким образом, не у всех есть возможность внедрять системы подобного уровня, а потому всегда существуют более дешевые и простые аналоги, разработанные под специфику отечественного бизнеса и учета. На нашем рынке существуют разработки и отечественных производителей ПО (к примеру, , Парус, Галактика и др.), целью которых также является внедрение ИС, пытающихся охватить все сферы деятельности компании. Внедрение и сопровождение подобных отечественных систем на порядок ниже по стоимости, по сравнению с «брендовыми» аналогами, что является неоспоримым преимуществом для большинства руководителей компаний при выборе ПО.

Дополнительным положительным моментом является также и наличие специалистов по внедрению, настройке и доработке систем под нужды заказчика (стоимость работы подобных специалистов также значительно ниже по сравнению с внедренцами «бренд»-систем). Казалось бы, внедрение отечественных систем способно оказать положительное влияние на деятельность компаний в целом, и на проблему оптимизации товарных запасов, в частности. Однако и здесь существуют свои подводные камни. Самый большой плюс в практическом применении таких «всеобъемлющих» систем (как отечественных, так и зарубежных) заключается, по мнению многих экспертов, в возможности хранения всех данных в одном месте и использование их в режиме онлайн по первому требованию пользователя, в необходимых отчетах.

На этом, на мой взгляд, серьезные плюсы и заканчиваются. Даже более того, с этого момента начинаются минусы. Во-первых, хранение всех данных (для каждого из направлений – учет управленческий, учет товарный, учет бухгалтерский, маркетинг, аналитика, взаимодействие с клиентами и др.) приводит к постоянной и достаточно серьезной нагрузке на единую базу данных (ЕБД) ввиду великого множества запросов; во-вторых, возникают некоторые технические сложности с разграничением прав доступа к данным от различных подразделений; в-третьих, с ростом самой ЕБД в значительной мере снижается ее гибкость и увеличивается время на запросы и обработку данных; в-четвертых, значительно возрастает физическая (техническая) нагрузка на сервер; в-пятых, для всех направлений деятельности компании вся ЕБД в целом является источником избыточной информации; и в-шестых, как ни крути, а эти системы в большинстве своем являются просто учетными системами, предназначенными для внесения, хранения и извлечения данных, и осуществления оперативной деятельности.

В добавок к озвученному выше, использование глобальных систем порождает множество проблем при осуществлении различных видоизменений и доработок (которые постоянно проводятся) по мере развития бизнеса либо некоторых из его направлений. Поскольку какие-либо видоизменения в одном блоке системы с большой долей вероятности влияют и на смежные области, а спрогнозировать все потенциальные угрозы не всегда представляется возможным, техническим специалистам приходится лезть все глубже и глубже в систему, чтобы, решая одну проблему, не породить другие. И в итоге, решив одну локальную проблему, на поверхности все-таки появляются три новых, и процесс этот цикличен.

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

При необходимости настраивается взаимосвязь между различными базами, и по регламентированному протоколу проводится обмен необходимой информацией между ними. К примеру, для большинства локальных ИС первичные данные извлекаются из ЕБД, после чего обрабатываются и дополняются данными из других БД либо из внешних источников. Полученные таким образом данные используются в локальных (специализированных) ИС, исключая при этом какое-либо серьезное воздействие на «соседние» локальные ИС и на ЕБД. Подобный подход снимает большинство озвученных выше проблем, характерных в случае одновременной работы всех систем непосредственно в ЕБД. Безусловно, решив одни проблемы, компании порождают другие – к примеру, некоторым менеджерам приходится иногда открывать две программные системы вместо одной для формирования каких-либо отчетов. Однако, на мой взгляд, серьезность данной проблемы на порядок меньше всех остальных, озвученных выше, и компенсируется повышением общего качества работы и получаемого результата. Поэтому в ряде случаев решение проблем по внедрению систем прогнозирования и планирования также выносят в качестве отдельной ИС – для формирования методологии прогнозирования и планирования, и реализации ее в программном виде с целью оптимизации товарного портфеля компании и поддержания его в сбалансированном состоянии.

Предлагаю рассмотреть на примере одной из компаний решение задачи по реализации проекта по внедрению системы планирования, позволяющей решать поставленные задачи по оптимизации товародвижения. Ранее на этом на сайте автором уже представлялась методология проведения расчетов, позволяющая осуществлять формирование планов продаж и закупок, а также финансовых планов на их основе (Павел Бондарев: Просто о непростом: планирование торгово-закупочной деятельности компании). Вторым этапом были представлены результаты реализации и внедрения программного комплекса по прогнозированию и планированию деятельности в одной из компаний (представлено в печатной публикации – журнал «Логистика и управление» № 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. Блок закупок - общий вид

  1. Список позиций. В данном блоке указаны основные сведения о позициях – название, код, принадлежность к товарной группе, принадлежность к группе по АВС-анализу, остатки на складах, резервы, количество заказанной продукции, а также рекомендуемые количества для закупки, пополнения ассортиментного запаса филиалов и перемещения излишков со складов филиалов на центральный склад. Расчет рекомендуемых количеств осуществляется по разработанному алгоритму, согласно которому расчет заказа осуществляется в том случае, если расчетный остаток товара к моменту прихода его, при условии заказа на текущий день, ниже минимального нормативного порога, а рекомендуемое прогнозируемое количество берется из расчета наличия нормативного запаса по товарной позиции к моменту прихода товара, с учетом текущего срока поставки (текущий срок поставки определяется автоматически, исходя из текущей минимальной цены поставщика).
  1. Информация о выделенной позиции. В данном блоке выводится необходимая дополнительная информация о выделенной товарной позиции – ФИО ответственного специалиста, название, коды, поставщик, срок поставки, складской остаток, кнопка «Перерасчет», закупочная и прайсовая цены, наценка для выбранной позиции. Кнопка «Перерасчет» предназначена для проведения расчета величины закупки для произвольного срока поставки и/или произвольного остатка на складе (необходимо для различных форс-мажорных обстоятельств – обращение нового поставщика с более выгодными условиями, анализ остатков в различные периоды времени, и т.п.).      
  2. Установка приоритетов закупки. Блок управления отбором позиций по приоритету – наивысший приоритет у тех позиций, которые должны быть закуплены в первую очередь. Переключатели позволяют выбрать необходимый режим отбора, позволяющий открывать списки позиций с выбранным уровнем приоритета («Высокий», «Средний» или «Низкий»). В первом режиме представлены позиции, которые необходимо заказывать в настоящий момент. Во втором – те позиции, которых на складе недостаточно, но эти позиции уже заказаны. Условие того, заказана позиция или нет, определяется либо автоматически – раз в день по полученным данным из базы, либо специалистом по закупкам – при нажатии кнопки «Заказано» для позиции из первой группы. В последнем случае позиция из первой приоритетной группы перемещается во вторую. В третьем, низком, режиме приоритета – позиции, которых на складе достаточно.
  3. Блок управления записями. В данном блоке реализованы функциональные возможности, позволяющие переводить товарные позиции в иные уровни приоритета, переходить в блок «Прогнозы», производить поиск необходимых товарных позиций и экспортировать полученные данные в Excel.
  4. Результаты прогнозов. В данном блоке указаны различные варианты расчета количества товара, необходимого к закупке. Выбранный автоматически вариант расчета выделяется синими цифрами.
  5. Меню выбора товарной группы. Позволяет отобразить в списке товарные позиции только из определенной товарной группы, с целью формирования дискретных заказов.
  6. Информация о поставках. В данном блоке представлена информация о датах и количестве ожидаемых поставок товара. В случае, если дата ожидаемой поставки меньше текущей, данные выделяются.
  7. Суммы на закупки. В указанном блоке представлены данные по рекомендуемым закупкам в суммовом выражении. Ниже указано количество позиций в списке выбранного приоритета.

Блок расчета складских нормативов и запасов

Расчета складских нормативов и запасов (Рис.6) представляет пользователю все необходимые данные о локальном движении по товарной позиции, а также данные по складским нормативам по позиции на весь отчетный годовой период; предназначен для менеджеров по закупкам, логистике, аналитике, и содержит следующие элементы:

Рис. 6. Блок расчета складских нормативов и запасов - общий вид

  1. «Графическое представление складских нормативов». График планов по складским запасам на конец каждого месяца (на ближайшие 10 месяцев, включая текущий; прогноз и допустимый интервал).
  2. «Численное представление складских нормативов».«Статистика и прогноз продаж и остатков». Блок информации о продажах и неудовлетворенном спросе в текущем месяце.
  1. «Статистика остатков с дискретизацией». Блок информации о складских остатках с учетом остатков на складах филиалов (с всплывающей детализацией по остаткам и излишкам по каждому из филиалов), резервов и размещенных заказов.
  2. «Рекомендации по закупкам». Блок информации о закупках – двухмесячный запас на следующие два месяца и необходимые закупки для его пополнения (а также для пополнения запаса на текущий месяц, при необходимости).

Таким образом, реализовав представленный программный комплекс, была решена задача по оптимизации бизнес-процессов сотрудников компании, непосредственно вовлеченных в процесс товародвижения, а также повышен качественный уровень самой системы планирования в целом. Реализованный и внедренный программный комплекс позволяет менеджерам качественно оптимизировать свою оперативную деятельность, предоставляя полный набор необходимой информации для принятия решения, и значительно снижая время на обработку и анализ информации; руководителям – позволяет анализировать состояние складских запасов в оперативной и среднесрочной перспективе, контролировать деятельность сотрудников компании, оперативно вносить необходимые корректировки как в деятельность сотрудников, так и в процессы деятельности компании.

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

Блок расчета нормативов по складам филиалов и дистрибьюция

Поскольку задача по реализации и внедрению программного комплекса по оптимизации товарного портфеля была успешно выполнена, было принято решение о реализации следующего блока – для оптимизации распределения товара среди филиалов компании. По аналогии с первым блоком, был реализован и внедрен программный комплекс, позволяющий прогнозировать потребности филиалов компании и планировать распределение товаров между ними. В частности, по аналогии был введен в эксплуатацию блок по прогнозированию потребностей филиалов, и дистрибьюции товара между ними (Рис. 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

Расскажите коллегам:
Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии
Нач. отдела, зам. руководителя, Москва
Павел Бондарев пишет: Прогноз - он красный (пятый ''всплеск'' на графике). К сожалению на этих рисунках цвета плохо передаются -
У меня на рисунке видно только зелёный
Павел Бондарев пишет: Графиков по поступлению товара нет
Имел в иду график 11 - статистика запасов. В филиале получается плавный рост запасов, а потом ''плавный'' расход. Если не производитель, то плавный рост запасов не понятен :D. Вначале подумал, что у Вас точки только по месяцам.
Менеджер, Канада
Александр, зеленый - это границы допустимого интервала (мин и макс) :) Поскольку для данной позиции у данного метода достаточно маленькая погрешность, они у Вас сливаются. На Рис. 11 представлены статистические данные по филиалу за разные годы :) не графики закупки-отгрузки. Графики поступления и отгрузки товара аналогичны Рис.8 в http://www.e-xecutive.ru/community/articles/681043/ - на данном рисунке представлены данные в суммовом выражении; но для отдельно взятой позиции схема будет абсолютно идентична (с поправкой на цену закупки и цену отгрузки).
Нач. отдела, зам. руководителя, Воронеж

Уважаемый Павел Михайлович, большое спасибо за статью. Особенно радует, что Вы общаетесь со своими читателями.

Возникли вопросы:
1) Почему Вы с таким скепсисом относитесь к использованию 1С в этой области? Ведь она основана на том же SQL… Аналитическую БД, конечно, нужно выделять, но, насколько я знаю, при покупке лицензии оплачивается количество рабочих мест, а не количество обрабатываемых БД. К тому же в 1С 8 предполагается функционирование событий, т.е. можно организовать оповещение менеджера, например, о необходимости сделать заказ, пересмотреть складской норматив и т.д.
2) Не удобнее ли качественный реквизит «Приоритет» заменить на количественный «Текущая потребность» (= складской норматив – наличие – ожидаемый приход), который бы непосредственно участвовал в расчётах заказа?

Менеджер, Канада
Артем, добрый день! Общение с читателями (и вообще, с экспертами в своих областях) дело весьма интересное и полезное - живой практический опыт, на мой взгляд, порой бывает лучше сухих книг и статей (при условии, что база в виде прочитанной литературы уже есть :)). По вопросам: 1. Артем, я не выражал скепсиса по поводу 1С как таковой. Я выразил свое мнение насчет того, что попытки решать все задачи компании толкьо лишь одной 1С - некорректны и чреваты, поскольку 1С это только учетная система, пусть и с несколько расширенным функционалом в последних версиях. Никто же в здравом уме и трезвой памяти не пытается, к примеру, одним автомобилем и рекорды на гоночных трассах ставить, и землю пахать, и в ралли участвовать, и по воде плавать... и отсутствие этих попыток воспринимается нормально. Но почему при решении задач автоматизации процессов многие пытаются из обычной учетной системы сваять кадавра - и греца, и жреца и на дуде игреца. Конечно же, 1С, и восьмерка в частности, нормальная УС, обладающая широким функционалом, достаточно удобная для пользования во многих вещах, позволяющая формировать простые отчеты. Но она не обладает математическим аппаратом, способным решать серьезные задачи (а задачи прогнозирования, планирования я отношу к разряду серьезных задач - поскольку, не умея планировать свои запасы, не умея ими управлять, компания постоянно будет зарывать в песок кучу денег). То, что 1С работает с SQL - это мало что значит при расчетах. Безусловно, работа происходит быстрее чем на какой-нибудь DBF... ну и что? Это ж всего лишь способ хранения и обработки данных, не более того. Частный случай - в рассматриваемом примере (несколько тысяч позиций, по каждой несколько методов прогноза, несколько поставщиков, несколько складов с остатками запасов, товары в пути и т.п.) расчет прогноза длится порядка 4-6 часов, и это только по ночам, когда больше никаких запросов нет. И это только для того, чтобы утром менеджеры по закупкам видели развернутую картину по своим товарным позициям, с различными вариантами развития событий. Представьте себе ситуацию, что подобные расчеты шли бы а) днем, б) непосредственно в учетной системе. Думаю, остальные пользователи за это могли бы и побить... может быть даже и ногами :) Хорошо, если продажи постоянные и нет ярко выраженной сезонности - в этом случае можно ограничиться простейшими арифметическими действиями и не заморачиваться с какими-то сложными математическими системами. Тут я бы с Вами абсолютно согласился. Однако на моей практике подобных компаний еще не встречалось, увы. Безусловно, можно ограничиться каким-нибудь средним арифметическим... Но, Артем, попытайтесь по своим позициям провести небольшой ретроспективный анализ - к примеру, с февраля вернитесь на 6-12 месяцев назад, возьмите среднее по самым ходовым позициям и сравните полученное значение с фактическими продажами марта. Потом аналогичное проведите с февралем, январем... Думаю, картина станет более развернутой - сразу будет видно, сколько при подобном подходе товару было ''заморожено'' и сколько пошло в ''упущенную выгоду'' (если, конечно, у Вас ведется учет упущенной выгоды). 2. Не вполне понял Ваш вопрос. Не могли бы его развернуть? В Приоритетах я просто делю товары на те, которые 1) надо закупать срочно-обморочно, 2) можно, конечно, закупить... но не горит, 3) товара в достаточном количестве (если, конечно, мы говорим об одном и том же) С уважением, Павел
Нач. отдела, зам. руководителя, Воронеж

Не уверен пока, что смогу обогатить Вас живым практическим опытом :oops:
1) Я, уже не помню где, понаслушался об ущербности 1С, сам столкнулся пару раз с ситуацией, когда сервер затыкался из-за того, что формировался файл слишком большого объёма (анализ постоянства складского запаса по 2-3 тыс. поз.; расчёт по ежедневным остаткам), и начал выступать перед руководством с наездами на 1С. А программисты 1С сказали, что в SQL готовых операторов нет, всё равно это надо писать самим, и работать это быстрее не будет, только времени уйдёт больше на формирование интерфейса. На SQL.RU всяк кулик своё болото хвалит, при этом не нашёл никого, у кого был бы опыт, подобный Вашему. Кстати, у нас АБД выделена, работает хоть и в 1С, но самостоятельно (со вчерашними остатками) и даже на отдельном железе, так что текущей работе не мешает.
2) В Приоритетах участвуют только количества товара? Приоритет зависит от принадлежности к той или иной АВС-группе?

Менеджер, Канада

1. Ну вот, как у Вас всё замечательно :) Если еще при ''тяжелых'' запросах к АБД не висит весь сервак - это вообще классно!
Но Вы всё же попробуйте провести ретроспективный анализ, для своего интереса... ;) да и мне тоже было бы интересно посмотреть на результат - порой очень хорошие и простые методы проходят мимо. Вдруг у Вас этот самый случай - мы б и узнали, и обогатили мир новым методом.
2. да, только количества... Нет, принадлежности к маркетинговой группе нет - если надо товаром пополнить складские запасы, группа здесь роли не играет. Она выступает только в том случае, когда заходят разговоры о суммах. На одной из картинок (номер не помню, страница со статьей не открыта), связанной с закупками (там, где приоритеты выделены в группы) - в правом нижнем углу стоят суммы, необходимые на дозакупки. Я эти суммы и ввел как раз таки для того, чтобы можно было учитывать суммовые затраты. Во-первых, эта информация идет финансистам - для БДДС, а уже от них закупщикам - в случае, когда присутствуют кассовые разрывы и финансы не позволяют осуществлять закупки в полном объеме, тогда уже включаются пресловутые маркетинговые группы - получается как бы приоритет в приоритете... То есть из группы наиболее приоритетных для закупки позиций выделяются наиболее из наиболее :) приоритетных.

Нач. отдела, зам. руководителя, Воронеж

1) Т.е. даже если готовых операторов в SQL нет, и работать будут всё равно самописные, 1С добавит тормозов?

Ретроспективный анализ занимает много времени, если учитываются ежедневные остатки, но это не всегда нужно. Например, не вижу смысла ежедневно обновлять индекс сезонности (ИС), при определении которого нужно учитывать постоянство складского запаса, т.е. ежедневные остатки. Рассчитывать текущий период оборота можно тоже основываясь на данных не за прошлые 12 месяцев, а за 1.

Т.е. у нас прогноз и планирование основываются на складских нормативах (СН: минимальный остаток и минимальная партия), которые периодически корректируются (сейчас практически вручную). Получается, что ИС и СН как раз и аккумулируют статистические данные за прошлые годы, так что глубокие ретроспективы нам нужны не ежедневно (или это я просто привык к плохому?). АБД я бы загрузил, в первую очередь, еженедельной корректировкой СН для всех складов и филиалов, но это тоже достаточно громоздкий расчёт, и я бы из соображений экономии вычислительных ресурсов не брал бы для анализа период больше 1 недели.

2) Т.е. Приоритет основывается только на складских нормативах, а заказ можно составить любым из 3 методов – аддитивным, мультипликативным или Хольта-Винтерса, по выбору менеджера? Получается, что СН в Вашей системе включает только минимальный остаток? По какому методу он рассчитывается?

Менеджер, Канада

Артем, и снова добрый день!
1. 1С добавляет тормозов в любом случае, поскольку он ''не заточен'' под вычисления. Кроме того, структура хранения данных в 1С известна только 1С - соответственно, программер не может писать код, оптимизированный под запросы к конкретным объектам, данным. Код будет работать в системе 1С, которая уже будет ''переводить'' его, формируя запросы к БД.
Ретроспективный анализ много времени не занимает - банально строится прогноз, к примеру, на март месяц (десять-двадцать самых ходовых позиций, по одному значению на позицию :)), и сопоставляется с фактическими данными за этот же месяц. Поскольку март прошел, данные у Вас наверняка есть. Необходимо их сопоставить с фактом, и вуаля. Дело пары минут.
По индексу сезонности. А зачем его ежедневно обновлять? В системах, подобно той, что я представил, он рассчитывается автоматически; единстенно, что делается вручную, так это вносятся экспертные оценки на группы - всего несколько значений, и делается это для каждой товарной группы один (максимум два) раз в год, т.е. тоже не вижу с этим абсолютно никаких заморочек.
По нормативам. Не вполне понял... Как это прогноз и планирование строится на нормативах? Обычно всё происходит с точностью до наоборот - сначала прогноз, потом план, и только потом идет формирование нормативов: сначала идет статистический расчет по прошлым периодам (получаем прогноз на перспективу, по каждой позиции), потом данный расчет проходит аналитическую экспертную оценку (уже укрупненно, по каждой товарной группе), на выходе получаются те значения, которые, ориентировочно, будут проданы в будующих отчетных периодах (либо периоде, если речь идет о краткосрочном либо оперативном планировании). И уже на основании полученных значений продаж формируются нормативы, определяющие границы стоков! Вообще, нормативы не должны привязываться к конкретному числу - они привязываются в процентном либо долевом соотношении к некому параметру, изменяемому во времени (данный параметр - план продаж в отчетном периоде). Если же Вы выставляете нормативы (кстати, они откуда берутся?), и продаете в этих рамках, то у вас каждый раз будет либо неудовлетворенный спрос (в случае, если продажи идут вверх, и вы не успеваете пополнять запасы), либо идет замораживание финсредств (в случае, если продажи снизились, но закупщики придерживаются установленных рамок нормативов). К примеру, продажи помесячно составляют 100-150-200-500-600-300... как нормативы будут работать? Поставить широкую рамку - будет и упущенная выгода (в ''пики''), и заморозка средств (в ''межсезонье''); поставить узкую рамку - в межсезонье еще более-менее, в пик однозначно пойдет упущенная выгода. Менять ежедневно границы нормативов, проводя перерасчеты - не завидую Вашим логистам, они Вашу восковую фигурку всю иголками затыкают :) хорошо, если не горячими.
Далее - нужна ли ежедневная проверка необходимости допоставки товара. Здесь нельзя дать однозначный ответ, всё зависит от рода деятельности. Посмотрел Ваш сайт - занимаетесь электрооборудованием, то есть товар с ежедневной уходимостью. Наверняка несколько поставщиков (весь сайт не разглядывал, но не думаю, что вы являетесь монобрендовой компанией). Если не осуществлять анализ стоков ежедневно, это означает увеличение объема складских запасов. В случае, если поставщики расположены где-то далеко, и дискретность поставок низкая, то вопросов нет - может быть, достаточно ограничиться анализом 1-2 раза в неделю (тут уже вопрос финансовый, какие суммы вы можете себе позволить вкладывать в склад, и какую оборачиваемость склада держите). Если поставщики рядом и срок поставки маленький, то целесообразнее, на мой взгляд, провести оценку затратности транспортных расходов (+расходы на хранение) VS замороженные средства. Может быть, выгоднее будет увеличить затраты на транспортировку, но повысить оборачиваемость... В общем, надо считать! :)
По поводу загрузки АБД. А с какой целью Вы её ежедневно грузите? Думаю, вероятность того, что Вы сможете спрогнозировать продажи каждой товарной продукции на каждом складе с вероятностью хотя бы 80% - из разряда фантастики (в противном случае, я готов выехать в Воронеж в качестве ученика немедленно! :)). Если этой вероятности нет, то тогда не понимаю необходимость в ежедневных расчетах и корректировках СН. СН либо выставляются (раз-два в месяц, на основе расчетных прогнозов-планов) и их придерживаются, либо просто подвозят товар по мере вымываемости (хреновый вариант). Не думаю, что электротехнический товар обладает свойством иметь ярко выраженную сезонность в течении каждого месяца :)
2. Нет, ситуация с точностью до наоборот. Как я уже описывал выше - сначал идет прогноз (и упомянутыми методами в том числе), потом идет план продаж, потом идет расчет нормативов... Всё это делается 1-2 раза в месяц (в зависимости от свойств товара). Затем, ежедневно, проводится анализ а) складских остатков, б) ''оптимального поставщика'', в) (исходя из б)) сроков поставки; после чего проводится расчет того - сколько товара, ориентировочно, останется на складе к моменту прихода товара (при условии, что товар заказывается ''сейчас''), и, исходя из полученных потенциальных остатков, проводится расчет необходимой дозакупки. Это если в кратце...

да, что-то ''вкратце'' не получилось :)

Нач. отдела, зам. руководителя, Воронеж
1) Спасибо, теперь у меня есть аргументы по выбору ПО для АБД. Кстати, сколько стоит написать описанную в статье АБД и отладить её взаимодействие с 1С? 2) Т.е. погрешность у Вас вычисляется путём сравнения ретропрогноза с фактом по предыдущему месяцу? Как при этом сопоставлении учитывается постоянство складского запаса (ПСЗ) и динамика оборачиваемости? Ведь может оказаться, что прогноз продаж совпал полностью, но при этом ПСЗ<1, т.е. прогноз был меньше оптимального, и товара могло бы уйти больше при его наличии. Или может оказаться, что оборачиваемость ухудшилась, т.е. прогноз был больше оптимального. 3) Нормативы у нас, согласен, назначаются ''на глаз''. Это делают не логисты, а бренд-менеджеры - каждый по своей товарной группе (т.е. у каждого от 3000 до 15000 позиций), по 10 филиалам и складу. Делают они это без определённой периодичности, по своему усмотрению, основываясь на опыте, знании рынка, своих планах по управлению ассортиментом и т.д. Сказать, что они совсем не справляются, было бы неправильно, но успевают максимум за сезонностью, так что оборачиваемость у нас средняя по отрасли (а хотелось бы, конечно, иметь лучшую). Выручает то, что поставки достаточно оперативные, как правило, раз в неделю. Так что случаи, когда ходовой товар вымывается, – редкость (но это ещё не повод приезжать к нам учиться ;) ). Тем не менее нормативы надо назначать раз в неделю (у нас всё-таки есть сезонные колебания внутри месяца), что вручную – нереально. 4) Ежедневная проверка необходимости допоставки товара нам нужна. В 1С 8 планируем наладить оповещение менеджеров о клиентских спецзаказах – при поступлении такого заказа менеджер должен сразу видеть, на какую сумму сформируется текущий заказ тому поставщику, от которого надо привозить появившийся клиентский спецзаказ. В принципе, по каждому поставщику можно вбивать данные о минимальной партии, и, как только набирается заявка на нужную сумму, должно создаваться оповещение для менеджера (или чтобы в начале дня собирался отчёт, какие заказы «созрели»). 5) Спасибо, что не «вкратце», зато понятно. Поясните, пожалуйста, как «текущий срок поставки определяется автоматически, исходя из текущей минимальной цены поставщика» (раздел «Блок расчета необходимых закупок»).
Нач. отдела, зам. руководителя, Беларусь

Артему Матвееву
1(один) месяц - хороший срок если у вас приходы товара каждыйе 1-3 дня, и ''короткая'' логистика, в противном случае ИМХО срок должен быть не менее 2-3 месяцев.
Чем больше период для анализа - тем он точнее, если вы хотите съэкономить денег - вычислительный ресурс вас вообще не должен волновать, вас должны интересовать точность анализа и его своевременность.
В моем случае период для анализа всегда 3 и более месяцев.

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Названы топ-10 социально ответственных компаний России

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

Исследование: как IT-специалисты приходят в профессию

90% опрошенных сотрудников IT-компаний — выпускники профильных технических вузов.

Исследование: как разные поколения выбирают работу

Зумеры сильнее акцентируют внимание на work-life balance, миллениалы – на зарплате, а для поколения X важнее стабильность и надежность компании.

Сколько компании тратят на обучение топ-менеджеров

Треть компаний выделяют на обучение одного топ-менеджера от 500 тыс. руб. в год.