Зеркало
Rutube
Этот доклад
Дублирующий канал на Российской видеохплатформе.
Группа VK ВКонтакте
Этот доклад
Группа #UDM в социальной сети с дублями видео и комментариями.
Расшифровка видео:
я хочу пригласить Сергея Шебанина. Сергей Павлович здесь уже. Мы видим, во-первых, технического специалиста, который знает, как это все работает. Мы понимаем, что App-in-Source это своеобразный очень концепт, своеобразная среда, своеобразные отношения и своеобразная история и некоторое различие технологий. Все, что было хорошего сделано было на App-in-Source. Что бы мы делали сейчас без Linux и без Android?
00:27
Тем не менее, ERP-модули пошли по пути выделения в коммерческий продукт, за что их покрыли в тресвое лучами добра. Это второй момент, что пытается развивать свою концепцию и свою систему. Следующий вопрос, что мы сейчас будем говорить не о каких-то бантиках, а достаточно сложной методологии. То Сергей Павлович пообещал нам показать, как они запилили DGIMERP. То есть, это...
00:54
и сложная методика в плане ее понимания, потому что там нет методички делай раз, делай два, делай три. Это какой-то набор работающих практик, которые приводят в какой-то в каких-то случаях надо из них свой рисунок выкладывать. Второй вопрос. Это не так просто реализовать программно и еще сложнее это внедрить. Поэтому давайте мы посмотрим, как это работает.
01:18
ДДМРП, так сказать, штука такая уже достаточно известная, она уже не такая модная, там пять лет назад, когда о только Лапшин знал. Сергей Павлович, будешь демонстрировать экран? Да, сейчас я этим разберусь и все покажу. Пока все подгружается, поприветствую всех коллеги, добрый день. Сегодня действительно расскажу про ДДМРП, причем расскажу про конкретный кейс, завершенный кейс, сейчас компания работает по этой методологии.
01:47
Случилось это не так давно, но тем не менее, остается фактом, они уже работают. Для начала о чем вообще сегодня буду рассказывать. Вкратце расскажу про концепцию DDMRP, потому что очень мало на самом деле материалов русскоязычных. И даже те, которые есть, они, во-первых, используют разную терминологию.
02:14
свою терминологию где-то буду вводить, буду тоже по ходу рассказывать. А во-вторых, в основном, всего сводится к тому, что Ddmrp есть бусеры запасов с тремя красивыми зонами в виде светофорщика. А как же это все внедрить? Как вообще с нуля ответить на вопросы, где эти бусеры разместить? Как, зачем, как они настраиваются? Какие у них есть реальные управляемые параметры? И как их использовать для того, чтобы
02:42
эта концепция заработала в масштабах предприятия. Вот постараюсь об этом вкратце сегодня рассказать. Покажу функциональные возможности нашей системы. Нам заказчик разрешил определенную область в системе рабочей показать. Соответственно, на реальных данных смотреть. Это всегда интересно. Дальше расскажу про практику внедрения. Что мы делали, какой последовательности, какие шишки наломали.
03:11
какими проблемами сталкивались, как их решали. и постараюсь те выгоды, которые видны на сейчас, подсветить, показать некоторые даже численно. посчитали. Ну и будут вопросы, ответы, понятно. Коллеги, методология сложная достаточно, и терминология разнообразная. Серьез, тогда следующий слайд, который рассказывал. Это то, о чем я говорил, буду говорить.
03:40
Так, D-DMRP, как расшифровывается? Demand Driven Manufacturing Resource Planning, прошу прощения за свой английский, учился в Д-шка в свое время. Это планирование потребностей в материалах на основе спроса. То есть, как заявляет методология, они не используют прогнозирование при планировании, они ориентируются на текущий спрос. Для меня очень спорное утверждение, потому что прогнозы, так или иначе, система строит. Просто строит их в режиме реального времени на основе
04:11
текущего, текущая информация, которая есть. С каким-то окном в прошлое, может быть, каким-то окном в будущее, это все настраивается. И позволяет ответить на вопросы для предприятия, какой запас и где должен быть какого конкретного продукта. То есть мы планируем потребности не просто в масштабах предприятия, сколько всего должно быть на всех складах, а в каждой конкретной точке, в зависимости от цепочки поставки, как оно в предприятии организованных.
04:40
можно указывать вплоть до полки перед производством свой буфер и сколько там, в какой момент времени должно быть винтиков эта методология позволяет рассчитывать. Второй вопрос когда и сколько заказать? есть методология определяет точные критерии, говоря когда нужно заказывать, в каком объеме, для того чтобы сгладить колебания спроса и сгладить колебания сроки.
05:10
срока поставки, которые могут быть. Чтобы вообще в этой концепции разобраться, нужно сначала с тремя ключевыми понятиями познакомиться, которые здесь есть. Это точки развязки буферов. Это мой перевод, разные есть варианты перевода в разные литературе, по-английски Decoupling Point. Эта точка, я чуть подальше подробнее буду рассказывать на примере картинки.
05:39
что это за точка. Она определяется как точка перехода в цепочки поставки от стратегии МТС к стратегии МТО. МТС, напомню, это Make to Stock. Когда мы делаем на склад, формируем запас. МТО это Make to Order, стратегия, когда мы не формируем запас, а производим или закупаем только под конкретную потребность, под конкретный заказ, есть. Чуть подробнее буду дальше рассказывать. Профиг буфера.
06:08
цветовые зоны буфера. Это концепция, вводящая три зоны в каждом буфере, так называемые красную, желтую и зеленую. Красная страховая зона, желтая зона поставки, это ожидание поставки, и зеленая это рабочая зона, которой нас запас должен большую часть времени по-хорошему находиться. Управление буферами. Как
06:37
с ними работать, какие у них есть настройки, как в каких случаях эти настройки нужно трогать и зачем, и как с ними работать, как получать информацию оперативную, и что каждая конкретная роль третья должна с ними делать. Это третий блок. Коллеги. Да, я, наверное, пропустился с расшариванием экрана, не сказал важной вещей. Теория достаточно сложная, поэтому если возникают вопросы, лучше их задавать мне по ходу, потому что
07:07
одно не понятое здесь что-то, очень кратко буду сейчас рассказывать и дальше просто всё понимание может уже потеряться. Поэтому если есть вопросы, задавайте. Я рисовал в классическом PowerPonety, пытался долго заставить Neuralisate нарисовать классную картинку, которая бы объяснила всю концепцию, в итоге нарисовал стандартными фигурами. Мне кажется, достаточно понятно будет. Вот здесь
07:33
классическая цепочка поставки у нас есть готовые продукты которые делают из полуфабриката полуфабрикаты с двух компонентов еще один компонент прикручивают к полуфабрикатам для производства у нас есть срок поставки здесь он называется lead time это время прохождения от формирования потребности до того как эта потребность удовлетворена соответственно классики мы видим что lead time равен
08:02
Мы заказали компоненты, их нам привезли, потом мы подождали где-то в очереди, что эти компоненты будут поставлены в производство, из них произвели полуфабрикат, потом мы попали в очередь ожидание производства готового продукта, готовый продукт произвели, положили на склад, подождали пока его задерет или мы отгрузим клиенту и наконец отгрузили клиента. Вот это классическая цепочка поставки.
08:32
В DDMRP в эту цепочку вставляются так называемые точки развязки, decoupling point. Это как раз то, что я говорил. Место, где стратегия MTS превращается в MTO. Ну вот здесь сейчас на текущей точке, где для примера это отображено, означает, что мы полуфабрикатой с вами и компоненты накапливаем на складе, но готовый продукт собираем под заказ.
08:58
Эту еще стратегию такие предприятия в английской литературе называют MTA, Make to Assembly. То есть мы собираем узлы, агрегаты, компоненты, готовую финальную сборку делаем уже непосредственно по заказу и в отгрузке. Существуют другие крайние варианты, где можно разместить точку развязки. И еще одна крайняя точка. Мы размещаем
09:25
эту точку развязки в самом начале цепочки поставки. Это означает, что такое предприятие, ну, достаточно условное, идеализированное, но нам надо понимать крайние примеры. В таком предприятии нет никаких запасов. Все, что они делают для клиентов, они делают под заказ. То есть появился заказ, мы под него заказали компоненты, подождали, пока они приехали, сделали, и отгрузили там, все по цепочке сделали по конкретному заказу. Следующий пример.
09:54
Это следующий идеализированный пример, когда нас крайняя точка справа является точкой развязки, тогда все, что мы делаем, мы делаем на склад. Почему идеализированными? В какой-то мере здесь можно все эти дистрибьюторы считать предприятиями, которые работают по этой стратегии. То есть мы формируем готовый продукт на склад и только отгрузку мы делаем, собственно, по требованию клиента.
10:22
Идеализированные варианты истина всегда где-то между. Вот мы нашли эту точку развязки для конкретного предприятия, где им удобнее, исходя из их статифики, где это выгодно. И здесь ставим буфер запаса. Ну, ты только скажи, что это делается не для всего потока, а для вообще каждой из колужки. Да, это следующее.
10:46
следующий слайд. На самом деле эти буферы запасов они формируются, конечно же, в разных точках. Это вот сейчас вариант, для каждой номенклатуры у нас есть свой буфер запаса. Также он может быть еще для каждого места хранения на предприятии. Давай вернемся там, важные вещи на предыдущем не сказал. Вот здесь видно, что вот эта точка развязки DecouplingPoint, она разбивает
11:15
весь lead time на несколько компонентов, ну на два компонента из данного случая. Этот частный срок поставки в этой методологии называется decoupling lead time. Мы это перевели как изолированное время поставки или EVP сокращенное. Это время от одного буфера, грубо говоря, до другого буфера. То сколько нам стоит восполнить запасы в буфере, учитывая, что в цепочках поставки у нас где-то еще запасы буферизированы.
11:44
компонентов, которых это делается. Этот термин нам пригодится, потому что, когда мы будем понимать, как формируются размеры зон, он очень значимое влияние играет. Что еще здесь хотел сказать? В реальности, конечно же, буферы формируются не для всех нуменклатур и не во всех точках, где и как конкретно это достаточно сложный анализ, который зачастую мы начинаем с каких-то простых.
12:14
вариантов, понятных, известных, уже где на самом деле сейчас люди накапливают на предприятии запаса. Мы там ставим буферы, начинаем их измерять и дальше уже в развитии понимаем, что где-то может быть еще не хватает, а где-то они избыточны. Вот здесь приведем пример, когда у нас компоненты накапливаются, все остальное под заказ. Идем дальше. Другой пример.
12:40
Мы не накапливаем компоненты, накапливаем только полуфабрикаты, готовый продукт, как тоже может быть в каком-то прохедении. Это краткие варианты, где это может быть. Вот теперь, что же такой буфер-запас, и с чего он строится? Вот классическая схема буфера. У нас есть страховой запас, у нас есть зона ожидания поставки, и у нас есть рабочий запас. Кроме этого, у нас есть текущие снимки значения, сколько сейчас, то, что называется, оншенд, какой остаток на складе.
13:09
и какой прогноз в DLMRP его называют net flow position. Это сколько мы планируем, что будет этот запас с учетом всех плановых операций. То есть мы знаем, что к нам что-то едет, мы знаем, что у нас уже зарезервировано под конкретного клиента или под какой-то производственный заказ, и уже вот эта пунктирная линия, понимаем, что скоро будет вот такое значение. Давайте, Сереж, следующий слайд.
13:38
И на нем я покажу уже в динамике, и немного более понятно будет, как развивается ситуация с этим буфером. Понятно, что вот предыдущая картинка, это была мгновенная снимка. В динамике у нас меняется ситуация, меняется статистика спроса, меняются сроки поставки. И исходя из этого буфер динамически изменяется. И вот мы здесь можем видеть в динамике график остатка и график NetFlowPosition.
14:06
Мы здесь можем заметить, что остаток у нас гуляет приблизительно внутри зеленой зоны, немножко залезая в желтую, а Net Flow Position, так называемый, он живет большую часть времени непосредственно в желтой зоне. Демонстрация у нас у Сергея, поэтому я думаю, я мышкой здесь буду показывать, буду тогда словами объяснять немножко сложнее.
14:32
Вот, ну да, если Сергей мышкой будет комментировать, будет здорово. Смотрите, а что происходит? Когда нас остаток снижается и как только NetFlow Position касается желтой зоны, формируется заказ. Заказ на восполнение. Восполнение может быть через закупку, восполнение может быть через производство полуфабрикатов. И заказ сформировал в идеальной картине мира. Сразу снабженец или диспетчер производства или директор производства отреагировал.
15:02
и сформировал восполнение. Размер этого восполнения всегда до верха зеленой зоны. Пока этот заказ выполняется, у него есть какое-то время выполнения, ну давайте предположим, что из Китая нас что-то едет, да это долго обычно, пока это все едет, у нас расходуется еще этот компонент, и мы спускаемся ниже, и в идеале, когда мы коснулись красной зоны,
15:28
у нас этот заказ должен приехать, и мы должны восполниться. Понятно, что раз мы заказали до верха зеленой зоны, то заказанное количество у нас к верху зеленой зоны не вернется, а вот как на этой картинке возвращается немного ниже. И таким образом происходит вот это вот колебание. Видимые колебания. Пила здесь не видна классическая, потому что частота дискортизации, тут недельная, насколько я понимаю, на графике.
15:58
демонстрационном и несмотря на то что спрос меняется видно что система адаптируется и запас у нас всегда остается на границе желтой и зеленой зоны то есть разрывов поставки у нас не происходит как раз после этого можно рассказать детально и как формируются размеры как система рассчитывает тоже вкратце буду рассказывать
16:27
здесь не очень визуально, по большому счету, чтобы рассчитать вот эти зоны, нам нужно ответить на несколько вопросов. Насколько значим сбой срока поставки для запасов? Что это означает? Если нас срок поставки 90 дней, да, три месяца мы ждем из Китая что-то, то плюс-минус один-два дня в процентном отношении не очень сильно значим.
16:55
А если нас срок восполнения, например, мы производим это прямо в режиме ежедневном, у нас один день восполнения. Если мы на один день заковырялись с этим, кто-то там заболел, не знаю, запил на производство, все что угодно бывает, какой-то сбой в оборудовании, то задержка в один день у нас уже достаточно критична, то есть это по большому счету 50-процентное колебание в этом сроке восполнения. Второе. Насколько стабильен спрос?
17:24
спрос либо достаточно равномерный, либо у него есть всплески, он может быть очень сильно подвержен каким-то всплескам к 8 марта, к 23 декабря и так далее. Следующее, как часто удобно администрировать заказ? Что это означает? Если методология DTM RP, признана сделать остатки минимальными, насколько это возможно. Соответственно, при коротких сроках поставки
17:52
у нас заказ будет формироваться, ну если мы можем за один день произвести полуфабрикат, то у нас в система по умолчанию будет формировать ежедневно эти заказы. Ну потому что остаток хранить не нужно. Но это не всегда бывает удобно с точки зрения администрирования. То есть раз в день формировать заказы, ну по разным причинам бывает неудобно. Поэтому
18:20
Можно задать в настройках буфера, что я хочу заказ не чаще, чем раз в неделю. Зеленая зона вырастет, и мы будем заказывать больше, чтобы на неделю хватило как минимум. Какой минимальный размер заказа? Тут кратность заказа, я думаю, интуитивно, понятно и показательна. И следующие первые пять вот этих вопросов, на них нужно ответить вручную в нашей текущей реализации.
18:46
То есть это настраивается профилями буфера, конкретные есть настройки, сейчас в демонстрации мы их увидим. Следующие два вопроса. Они вычисляются автоматически. Какое среднесуточное потребление, оно же SSP, и вот изолированное время поставки, котором я вам рассказывал. Сколько нам нужно времени, чтобы восполнить этот продукт в этом конкретном месте от предыдущего буфера? Функциональные возможности нашего решения. Мы реализовали буферы запасов методологии DDRP.
19:16
определяет не только буферы запасов, но, собственно, мы здесь на текущий момент реализовали то, что дает 80 процентов результата в них. Автоматический пересчет буферов по изменению спроса, визуализация уровня запасов и генерация рекомендаций по заказам на закупку и производство, по сути, в режиме реального времени. И следующее, к чему мне надо переходить, это к демонстрации. А мы видим...
19:43
экран, которым чаще всего работают сотрудники этого предприятия. Сережа, слушай, давай я немножко помодерирую вопросы, потому что ты чат не видишь, а просил задавать их в реальном времени. Тут коллеги спрашивают, в каких индустриях это работает. Это, конечно, вообще клапшину вопрос, потому что у него больше, так сказать, опыта внедрения. понимали, что сейчас. Давай скажем так, что мы внедрили это в...
20:13
предприятии, которые производят косметику бытовую, с большим набором ассортимента, да, и с очень как бы плавающим спросом, который зависит от моды, от погоды, от праздников, там, я не знаю от чего. И со сложными цепочками поставки, с производством собственным, вплоть до там основы с закупками из Китая и со всей России разных компонентов, у них такая сложная логистика, сложно прогнозируем.
20:42
спрос тоже сильно плавающий. вот у них это в итоге по факту очень хорошо залетело. Давай если по поводу других индустрии тоже может. Control plus, сделай только чтобы было...
20:56
Скажите насколько, чтобы это Ещё раз. О, теперь всё круто. Единственное, что да, на таком размере не очень видны инкулатуры, но в принципе вы уже посмотрели. А их растянуть можно? Можно, нас уедет тогда немножко остальное. Так, приблизительно сделаю. Можно чуть-чуть поотключать здесь. Не такие прям принципиальные.
21:25
Но зато это реклама Odu, что все, что хочешь, все настроишь.
21:33
Сережа, ты на вопрос ответишь? Да, сейчас я его формулирую. меня там слайд был, я вспоминаю, что я там написал. Когда это работает? Когда у нас нестабильный спрос, когда у нас достаточно сложная цепочка производственная, и нам нужно много компонентов, нужно понимать, где они используются, сколько нужно, какое потребление. Ну, то есть вот, например, если мы говорим здесь про гелл-лаки,
22:02
какие-нибудь конкретно это клиента, то основа для гелилаков она одна, а продукции, которые из нее делают огромное количество, ее калируют. Там красители используются. И сколько же нужно, какая статистика потребления конкретно этой основы, нужно всегда считать совокупность по всем номенклатурам, которые она использует. Они до этого считали в Excel,
22:30
практически ежедневно там сидел человек с многомерными таблицами и использовал расширение Power Query, по-моему, оно для Excel называется, и с этим пытался сводить концы с концами. естественно, в Excel понимаете, что очень великая вероятность сбоя, постоянно на эти сбои они натыкались, и, собственно, поэтому пришли к нам. То есть первый вариант – это нестабильный спрос, сильно плавающий, а косметика, вы знаете, она сильно меняется в зависимости от сезона.
23:00
Второй – это сложная цепочка поставки со многим количеством компонентов. Третье – это применимо там, где ассортиментная база хоть и меняется, но она все-таки не под заказ, что называется. Не так, что каждый заказ уникален. Здесь эта методология скорее не подойдет. Вот, наверное, критерии, как понять, это может подойти. Это многокомпонентная сборка какая-то.
23:29
радиоэлектроника, электроника и прочее. Мебель, наверное, я так могу понять, что это подойдет для каких-то серийных производств мебель. Бытовая химия, соответственно, по аналогии. Вот из того, что видно, такие примеры. Ответил на вопрос, если кто-то или не ответил, задавайте еще. В правильном подходе почти в любом машиностроении это работает.
23:55
кроме того, когда это конкретно под заказ. Есть такие примеры. нас есть клиенты, когда они делают восстановление конструкторской документации по каждому заказу, и там повторяемость практически никакая. У них МТО-спратегия, скорее того, я говорил, очень развязки практически в начале. Хотя вот до каких-то компонентов типовых, стали, винтов, может быть, и ту сталь они под заказ заказывают.
24:24
Это, кстати, очень интересная вещь, надо ее как-то отдельно обсудить. Потому что даже на маленьком производстве бывает эффективно запустить три разные модели. Допустим, когда у нас аутсорс слишком дорогой, когда у нас какие-то вещи можно буферизовать, а какие-то нет. То есть, когда у нас что-то делается под заказом, оно точно будет востребовано и дальше. Или когда у нас нестабильный спрос на материалы. То есть, если есть колебания...
24:50
очень большие в сезонности материалов, рассматривать это отдельно. Кто-то играет этим, на бирже, покупает там вагонами и продает конкурентом высокие, а внизкую закупают, увеличивают буферы. То в каком-то объеме это применимо почти на каждом производственном предприятии. Я еще можно добавлю, я когда с Андреем Лапшиным тоже, он начинал когда-то...
25:13
решение свой DT Flow разрабатывать замечательно. Я с ним много общался, и мы еще думали, что это DTMRP методология отлично подходит не только для производства, но и для дистрибьюторских сетей для того, тоже логистику считать основываясь, допустим, на спросе дистрибьюторов. Ты там централизованный, допустим, склад, у тебя 4 региональных или там в каждом федеральном округе склады есть центральный в Москве или где-то в логистическом центре, и у тебя там куча дистрибьюторов, каких-то покупателей и так далее.
25:42
который спрос стекается в режиме реального времени практически. И если дистрибьютор запуферизировать таким же образом, то тоже можно будет хорошо считать, как перетекает, откуда-куда различного рода продукции. По сути, для продажи, для выстраивания сетки это тоже подходит и очень хорошо подходит. Спасибо. Спасибо, Сергей. Тут есть интересный опыт, рекомендую рассмотреть LD.
26:06
который построил инфосистему для всех дилеров. Не ждал пока каждый сайт себе сам настроит, которые свою производственную систему расширили до потребителя, есть накрыли дилеров, их переформатировали. То же самое сделали, кстати, из Трапичей и еще много кто. Ну, то есть, никогда у тебя ты управляешь поставками между собой и дилером, а когда ты создаешь некую крышу дилеру и...
26:31
управляешь уже видишь его потребление. Ну тоже что делает пятерочка, они же видят сразу кассы. То есть они не управляют заказом в магазин, они управляют тем, что ушло с касс. И вот это вот для тех, кто строит действительно взрослый бизнес, очень перфективная история. Давайте двигаться дальше. Демонстрация. Что мы здесь видим? У нас здесь буферы запасов. По умолчанию человек видит фильтр рекомендуемая закупка только, то есть только рекомендуемый заказ, да, наверное.
27:01
более точно было бы. Только то, что нужно нам сейчас заказать, то есть отправить в реальное производство или в Snapjent. Мы здесь видим тип товара, здесь у нас что-то есть производимое, что-то закупаемое. В этом случае я вижу только те буферы, которые в красной зоне и которые в желтой зоне. Если этот фильтр убрать, я также еще вижу то, что у нас в зеленой зоне. Сейчас к этому вернемся чуть позже.
27:30
что здесь можно еще увидеть. Во-первых, отсортировано все по этому столбцу, который означает прогноз, текущий прогноз в процентах к верхнему уровню зеленой зоны. есть насколько у нас сейчас этот прогноз ушел относительно, насколько он приоритетен по большому счету. То чем меньше это значение, тем приоритетнее восполнить эту недостачку. Соответственно, есть еще рекомендация.
27:59
которая рассчитана на основе статистики, на основе всех параметров, которых я говорил, вроде кратности заказа и так далее. человек может в одну кнопку нажать «Восполнить» и после этого него выполнить кнопку нажмёт здесь и уйдет все в реальный заказ. Уже к исполнению. Здесь можно провалиться в каждый буфер и здесь достаточно много
28:28
Наверное, найду какой-то более показательный, для более красивой картинки возьму вот этот вот буфер какой-нибудь. Здесь будет видно картинку нагляд. Что мы здесь видим? Что сейчас мы уже внизу золотой зоны. То есть система рекомендует заказ и, видимо, рекомендует это достаточно давно. Есть определенные причины, связанные там у клиентов на текущий момент с мощностью производства. Почему они это не восполняют?
28:57
до последней позиции, но тем не менее. Что у нас есть? Текущий прогноз сколько будет, какая рекомендация, какая сумма закупки, то есть это в размерах себестоимости еще, и рассчитанные показатели. ССП, среднесуточное потребление, то есть у нас в штуках это мерится, это нас конкретная наклейка, я взял какую-то для налаг, который наклеил. И ВП.
29:27
рассчитанная, то есть ее везут к нам, наверное, от какого-то поставщика 30 дней ориентируются на это. Соответственно, размер желтой зоны, давайте вернемся к тому, как он рассчитывается, так как это всего лишь ожидание поставки, то это произведение этих двух показателей. Сколько мы за 30 дней израсходуем этого продукта. Вкратце, как рассчитывается красная зона. Красная зона страховой запас рассчитывается, исходя из выбранного профиля буфера,
29:56
в котором указана коэффициент времени выполнения и фактор изменчивости. Мы сейчас клиенту подавляющей большинстве настроили средние значения, срединные для этих показателей, и в большинстве случаев их хватает. Есть некоторые позиции, только в которых это пришлось изменить, потому что они какие-то эксклюзивные. Соответственно, исходя из этого, рассчитана эта красная зона,
30:26
призвано смягчить любые колебания. есть мы промахнулись, ушли в красный, чтобы нам в ноль не упереться и не вызвать разрыв цепочки. Дальше есть несколько настроек, связанных с вот этой вот, я их называю, бизнес-параметром. Это сколько нужно административных, административное дополнительное время на то, чтобы сформировать заказ. Здесь так как это внутри производства все происходит, никуда ничего переслать, заказы не нужно.
30:55
нулевое. минимальное количество заказа иногда, когда это нужно делают. и минимальный цикл заказа здесь указан в днях. он равен и в вп на самом деле. но в общем случае может быть и не равен. здесь еще множитель на количество 816 наклеек. не знаю из каких соображений. у клиента это именно 816. вероятно какие-то привязки.
31:23
метражу, ли, ленты или бобины, на которые закупаются наклейки. Вот, минимальный размер партии и так далее. есть настройки. Что система нам просчитала, я уже тоже вам сказал. Рекомендация для восполнения и есть отображение того, где мы сейчас находимся. Давайте еще какие-то примеры Может быть, других.
31:52
показательных ситуаций. Мы в красной зоне, нам рекомендуют 895 заказать этих наборов собрать. Соответственно это от текущего объема до верха зеленой зоны. Опять же расчетимая. А покажи буфер производимого товара, чтобы там еще прогноз был. Да, вот это у нас производимый товар.
32:22
Ты, наверное, имеешь в прогноз… Плюс один, плюс два дня и всю эту историю. Плюс один день. Давай сейчас найдем просто его как-то. Это же тоже важно. Это бизнес-логика, которую мы доработали для клиента, потому что там информация стандартная. То есть система запрашивала… Я буквально краткий комментарий, прости. Тоже хочется сказать что-то умное. Значит, буферы как бы запаса по методологии рассчитывают необходимую потребность текущую.
32:51
моменте, да, там можно пересчитать буферы, она их автоматически пересчитывает по коронам, можно сделать это вручную. Но система выдает сколько надо сейчас конкретно по прогнозу, по модели. Но проблема в том, что производство, оно не резиновое, оно не справляется, оно не может вырабатывать столько продукции. Плюс там определенная смена команды произошла в рейслид, ну, бы в ходе проекта, сами понимаете, да, какое-то.
33:19
как весело, когда команда вся меняется. Вот. И мы добавили для них вот эту логику, что нужно произвести там в плюс один день, в плюс два, основываясь на приоритетизации по отгрузкам. Все, дальше Сергей слово. То есть мощности производства не хватает того, чтобы реализовать все. Поэтому у них очень важный еще один критерий. Это сколько нужно на плюс один и плюс два рабочих дня, по большому счету, сейчас...
33:47
этого компонента произнести, исходя уже из известных отгрузок, которые есть вверх по всей цепочке поставки. Вот они, собственно, здесь у нас есть расчетные. То есть конкретно для этой позиции еще заказ не дошел под подтвержденный спрос, но мы видим вверх по цепочке, что там где это используется уже есть подтвержденные отгрузки на завтра и на послезавтра. Соответственно, в некоторых ситуациях они ориентируются на эти цифры.
34:17
Здесь же можно увидеть, где с точки зрения такого рабочего пространства здесь можно увидеть, во-первых, для этого производимого продукта спецификацию, где она используется, из чего это будет произведено. Это скорее уже отсылка к другим компонентам нашей системы для полного аффинитизации производства, закупок, продаж и складского учета, где используется, каких спецификациях.
34:44
мы где-то находимся в полуфабрикате, который где-то используется, где-то из чего-то производится. что еще важно здесь, вернемся к списку, я смотрю, времени так много, я показал верх, топ, но очень интересно в технологии Ddmrp еще и низ вот этого списка. То есть я сейчас вернусь туда и можем увидеть здесь какие-то позиции, по которым у нас текущий запас
35:14
Ну очень большой, зеленая зона даже в одну точку здесь влево Среднесуточное потребление очень низкое Это что-то либо не пользующееся спросом, либо выбывшее уже из активной торговли Но у нас огромные складские запасы Естественно, очень важно понимать, что вот этот продукт нам на склад производить не нужно Более того, мы по этому клиенту
35:42
Я сейчас показываю какое-то подмножство буферов. Достаточно много всего, порядка 7000 буферов всего. Соответственно, если смотреть по всем этим буферам и найти те продукты, которых запасы, вот потребление есть, но запасы очень большой, например, бутылка белая без логотипа. Взять те запасы, которые выше, ну как 2-х кратного превышения зеленой зоны, то есть
36:12
запас больше рекомендуемого системы в два раза и больше совокупно мы подсчитали по всем позициям у клиента получается замороженно сейчас на складе где-то половина его месячного оборота то есть понятно что мы сейчас наблюдаем как это показатель снижается он вымывается достаточно медленно потому что это не ликвид в большей мере но тем не менее я прогнозирую что где-то процентов до 10 20 этот неликвид должен
36:39
мы таким образом клиента высовываем процентов 30 его месячного оборота связанного в лишних складских запасах. Слушай, а ты можешь показать, у нас это настроено на этой системе, что буфер может быть не в три столца, а в пять слоев. Когда у нас есть зеленая зона, есть желтая вниз, желтая вверх, есть красная вниз, это когда критически мало, и красная вверх, когда критически много.
37:09
скажу на каком-то моменте. А кстати, сроки хранения? Но ведь мы сейчас типа мат-модель, а на самом деле все это может протухнуть, и оно зеленое, а срок вышел, и сроки хранения, как это учитывается? Не зеленое, Игорь, здесь оно, знаешь как, зеленая зона это стратегия для продавцов, надо сливать то, что зеленое, а красная стратегия для производства, надо производить и восполнять то, чего не хватает. Просто видишь, когда мы говорим о неликвидах,
37:38
Мы можем понимать, там хорошо, нас там 30 миллионов, допустим, на складе лежит неликвидов, но структуру этих неликвидов я не знаю как понять. Вот меня был склад там, я не знаю, я понимал, что у меня дохрена всего, а почему это неликвиды? Что с ними делать там? Когда их и что куда? А здесь по обуферу, по расчёту, вот по всей этой статистике сразу видно, что конкретно эта позиция там будет нами расходоваться 10 тысяч лет, исходя из всей статистики. Но надо что-то с ней решать как бы приоритетно, иначе она реально...
38:07
Здесь есть очевидные решения, которые мы рекомендуем клиенту, пока он их не реализовал, давать прибавку менеджерам по продажам, те которые сбывают. того, А вот эта вот композиция, которая сейчас видна на экране, уже такое управление там в принципе получается неким объемом товарного запаса и как бы верхнюю сторону тоже. То есть когда система может сигнализировать, что на этот товар надо нафиг просто сливать, иначе мы морозим свои деньги.
38:35
Ну да, здесь это другой режим отображения, котором красной зоной становится и слишком большое количество запаса. есть зеленым считается зона, ну, какой-то вот оптимума, которому мы должны находиться. Соответственно, из этой зоны в любую сторону считается уже нарушением. Это другой подход. В реальности каждый человек на предприятии настраивает себе, я вот здесь до примера ограничиваю количество у каждого...
39:05
конечно, какой-то уровень ответственности. То есть это все разбито по категориям, это разбито по местам хранения. Они формируют себе конкретно под свою дону ответственности отчет, с которым работают, делают на эту закладку. И дальше к этой закладке возвращаются. То есть у конкретного человека есть несколько вот здесь вот вкладочек, закладок.
39:32
которым он перемещается и видит оперативные данные, которыми он работает ежедневно. По большому счёту, таком режиме они и работают. На этом, наверное, демонстрация у меня всё. Есть несколько слайдов. Может быть, какие-то есть, коллеги, пока я не ушёл от демонстрации. Киньте у нас помидорку, что ли. Да тут, какой помидорке? Я скучаю поставить там интерфейсу.
39:59
У меня же в основном приходится с 18-го и меня нет слева вот этой колонки, а сижу тут и плакаю. Слушай, колоку мы сами напилили. И закладки сами напилили, да. Блин, я думал, что это от 16 версии осталось. Не-не-не. Это хорошо, таксистам. Вопрос, расскажите по существу. Автозаказ и можем ли мы сюда подключить бестолкового производителя? Вот допустим...
40:28
делаем мы делаем все у нас хорошо, а тут у нас подрядчик мы рассчитываем на срок плановый, а он взял нас подвез, то запукали все на лесопилке или вот там пытались рельсу распилить. Мы можем ли это, насколько реально транслировать это вот на дилера, ну то есть вправо скажем и влево, насколько это реально транслировать эту систему. Что хорошего мы можем, если мы вот этими данными и методиками поделимся с поставщиками.
40:58
Поставщиками, если они себе внедрят свою собственную систему, здесь выгоды очевидны. Если мы попробуем каким-то образом затащить их в нашу систему, здесь выгода какая может быть? Мы можем им соответственно дать инструкцию, либо договориться с ними, что они свою собственную приоритизацию наших заказов тоже делают, на исходе из этих бутик.
41:23
Тут вопрос, что если поставщику выдать личный кабинет и каждый день его спрашивать, есть клянешься ты или этими заказами или наоборот из его системы подгружать какие-то данные или даже поставить на телеграмм напоминалку поверх личного кабинета. так делают, то у людей есть личный кабинет, они туда не ходят, но им ставят телеграмм бот, который напоминает, что него из системы есть... Напоминалка в модулях закутки у нас есть.
41:52
я сейчас не показываю то, что не относится к ZDMRP, ну и здесь по клиентской системе тоже не буду ходить влево-право, мы вот договорились об этом, чтобы показывать. Сергей, тут знаешь еще какой момент, я тоже закомменчу, Игорь, короче, у нас, конечно, внедрение там не 100 тысяч, не 100 500 как уважаемых коллег, там это все десятками исчисляется, где-то в каких-то местах единицами, но что удивительно, короче, может это наша недоработка или там может...
42:22
не знаю, но в общем чаще всего от автозаказов люди отказываются, они всегда, ну то есть это вот то, о чем Михаил возможно говорил, да, это страх как бы перед системой, это страх потери своей значимости и так далее, но все как один не хотят использовать методологию формирования автозаказа поставщику, казалось бы очевидная история, да.
42:47
что это выгодно и упрощает всем жизнь, но они всегда оставляют за собой право решения принять самостоятельно. Поэтому насчет втащить в систему, вообще следующий на самом деле шаг. Сначала должны в нее поверить, начать работать, люди смениться, которые не хотят в ней работать. Потом уже, наверное, можно втаскивать кого-то слева, справа. Если говорить технически, то автовосполнение включается вот этой настройкой галочкой в буфере.
43:17
позиции по которым это восполнение будет происходить в автоматическом режиме понятно что это всего лишь формирование ордера или заказа там на закупку и производство дальше оно обрабатывается людьми но даже на это пока люди не готовы ну я думаю что со временем постепенно когда появится уже сильное доверие сейчас доверие высокая но я прям не сказал что она подкреплено для руководства статистикой корей
43:43
Отсчет восполнения мы для этих целей же делали, где вот там вываливается или это стандартная штука? Я вижу вопрос, как выглядит график производства. График производства может быть таким же... Я сейчас, к сожалению, в этой демонстрации мы говорили с клиентом то, что можем показать и, соответственно, не считаю возможным куда-то еще дальше на другие зоны.
44:12
здесь в этой копии уходить. А график производства может выглядеть либо вот таким образом, списком здесь по плановым датам будут просто разбиты на заказы, что нужно произвести, в каком объеме. Либо, если мы включаем то, что называется MRP2 подход, тогда происходит планирование уже по-операционное. У нас есть механизм планирования, автоматического планирования, просто жадным алгоритмом сейчас это сделано.
44:41
когда с учетом сроков поставки, учетом производства всех полуфабрикатов и компонентов система просто в самые крайние точки раскидывает по рабочим центрам операции с учетом плановых длительностей. И есть мастер перепланирования, там есть диаграмма ГАНТа, на котором можно посмотреть как сейчас выглядит, если я перепланирую с учетом текущей ситуации, как это будет сложно применить.
45:08
теоретически к сожалению сейчас могу. Короче, график производства выглядит как диаграмма гантов привязки к производственным центрам, ну или в любом каком-то другом разрезе, который система поддерживает. если используется подход MRP2. Если простой планирование, то это список такой линейный, которым нужно указано, какую дату, что и в каком объеме нужно произвести. Если большие заказы, он выглядит красиво. Если неравномерные и разного масштаба, он выглядит ужасно.
45:38
Если коротко. Достаточно, да. Нормально, Игорь, масштаб можно поменять на диаграмме, растянуть, и всё выглядит опять красиво. Нормально выглядит рабочая история, на самом деле. Ну, тут вопрос этот. У меня плохой график был из-за того, что народ отказывался коротко называть центра. То есть, эта бюрократия, ну, канцеляризмы, что каждый рабочий центр назывался
46:06
фразой из 180 слов. Ну да, можно два поля в десяти в данном случае. Конкретно этот клиент, DnRT 2, подход пока не использует, они планируют сменными заданиями, наденут просто, в конце дня отражают факты. А мобильное приложение не используют? Мобильное приложение используют, но не для производственных целей, для коммуникации. Здесь же очень мощная система коммуникации в системе.
46:36
Да, минутка рекламы. У нас есть собственное мобильное приложение, которое не зависит от западных серверов, нет каких. Все работает в уше, полнофункциональный интерфейс, можно управлять предприятием по сути с телефона. Ну это круто, надо его как-нибудь показать. А кто больше счастлив? Сторона продажники или сторона закупщики? И кто больше запротивлялся?
47:05
У меня там слайды есть на эту тему подготовленные. Давайте так расскажу. Сопротивление было везде. И оно продолжается и приводит к тому, что в внедрениях, как правило, меняется состав. Не целиком, но меняется состав сотрудников у клиента. Потому что те, кто категорически не хочет меняться, привык к подходам стереотипным, они, по сути, вымываются. Вот сейчас у этого клиента, по сути,
47:34
сформировалась уже команда такие, практически единомышленников, которые в этой системе разбираются, они сильно разобрались в методологии, в подходах, они помогают друг другу, там, кто новички, учат их сами, и это прям я смотрю и меня очень радует. Укрепно очень хорошая кисть получается. Кстати, вопрос сразу немножко не по теме.
48:00
Проектный менеджмент вы им ставили, они в вашей же системе управляют этим всем проектом внедрением? Пока не ставили, Игорь, нет, нет. Мы еще не зашли так далеко. Получающий курс по этой штуке будете делать? Ну, я думаю, что будем, да. Давай. У меня к тебе на самом деле много предложений родилось по ходу этой конференции, мы потом вместе свяжемся. Я просто про этого клиента хочу немножко сказать. ну, случилась такая удивительная штука, чуть-чуть коллеги вашего.
48:28
времени от него, потому что это прикольная история. Они до последнего, они до последнего, три или четыре месяца нам затянули проект, не хотели переходить в систему. Не хотели переходить, более того там ушли из компании два ключевых собственника, они не хотели и все продолжали работать в своей угрюмой утешке и все, и не хотели. И в какой-то момент мне лично пришлось просто заставить всех и их, и нас, нашу команду.
48:57
просто реально заставить выключить нахрен эту систему 1S и включить нашу. И вот тут началось самое интересное, потому что они попали в ситуацию, когда них держатель, ну как бы секта свидетелей Excel уволилась в полном составе, а нашим планированием в нашей системе они пользоваться еще не научились, а те кто научились тоже уволился, вместе с сектой свидетелей Excel.
49:25
И они попали в ситуацию, когда предприятию надо работать, и никто не знает как. И вот это их предприятие очень сильно взбодрило. Они неправильно начали работать правильно. Ну нет, неправильно, но они объединились вокруг идеи, них растет как бы грамотность и зрелость использования этой системы, они уже понимают, как важно заносить каждому правильную и своевременную информацию на…
49:51
они видят вместе, как у них влияют действия каждого человека на ту информацию, которую получает другой, и на принятие решений, и на составление производственного графика на день, и там на закупки, на то, как что правильно надо заносить. То есть за месяц, по сути, сейчас в компании произошла такая тихая революция, на мой взгляд, которая меня вот лично очень радует и вселяет как бы в веру, и в наш подход, и в наше решение.
50:21
Но вот этот шаг веры был очень сложный в самом начале. Это было, конечно, прикольно всех заставлять его сделать. как маленькие дети в детсадике такие, ну я не хочу. Ну так вот. Ну а сейчас там мы наблюдаем, когда один говорит, смотри, по системе кликает, показывает источник информации, находит очень просто в несколько кликов, говорит, вот вот здесь видишь, ты неправильно отразил, не с того склада списала.
50:49
какой-нибудь комплектацию. Соответственно, у меня здесь... А когда вы к этому прикрутите склад и оборудование? Оборудование, что... председания реакторами, которые бодяжат. Считывать данные, не вводить ручками, а считывать их прямо с дезаторов, с упаковщиков, с маркеровщиков. У нас запущены с ними чуть более прозаичные проекты. Это внедрение честного знака, потому что них приближается дата перехода.
51:17
и автоматизация рабочих мест сборщиков с сканером стрихкода, который бы просто контролировал для начала бы корректность спецификации сборки. В смысле, пикер, который укладывает заказ? Не только заказы, и на производство. У них есть одна из номенкулатура, это наборы лаков, например. И большая проблема, что сборщик в коробку положил не те лаки, которые нарисованы на самой коробке, Покупатели жалуются.
51:45
им пришло не то. Ну собственно, этом уровне контроль. Это для них сейчас актуальная проблема, не решаем. Ладно, спасибо, Сергей, который поздняк. Я буду делать баттл, в Кабак не университетский, нельзя, может быть, в точке кипения. Ну с 12 по 14 точно, потому что нельзя уже терпеть. Уже ручку от лопаты приготовил, надо с искусственным интеллектом разбираться, потому что продавцы грабят уже мою личную кассу.
52:15
тех, кто меня кормит. нельзя. Так что пересечемся, если будешь в Екатте, то пересечемся и... Давай, давай, скорее всего буду, Ладно, большое спасибо. Спасибо. Но отдельное спасибо за то, что благодарю, что показали живую систему. Это важно, это хорошая традиция, хотелось бы расширять, потому что рассказы по презентациям – это одно, живая система, и тем более это данные заказчика, это вообще...
52:44
самый цимус, потому что ну, мозг так устроен, никто не хочет в это верить, потому что иначе придется посмотреть внутрь себя, а это страшно. И второй вопрос, что мы видим как Appinsource, пришли банда и справились все это, то есть резервирование помогло ему стоять против кибершторма, когда что-то там Apple с Microsoft что-то не поделили, и вот у нас теперь такая история.
53:13
Слушайте, ну а я тоже, Игорь, бы хотел со своей стороны сказать, во-первых, спасибо, что пригласил, в нас поверил. И второй вопрос, момент такой, что вот как бы мне сейчас стало больше понятно, что нам все-таки надо вместе с участником индустрии, цифровизации производств общаться, и все-таки мне хотелось бы, участники индустрии поверили и использовали наш продукт, потому что, ну, кто особенно Оду занимался?
53:42
Я навел тут справки, ушло больше года, чтобы донести его в реестр ПО. Сейчас у нас бухгалтерия свела капитализацию нематериального актива. Я вам даже не буду говорить, сколько там миллионов денег положено, в принципе, за время, которое формирование. И мы бы очень хотели, конечно, чтобы этот продукт полетел своими силами развивать его как интегратор и набирать десятилетиями тот опыт, который есть у вас, коллеги уважаемые. Но это такой путь в никуда.
54:10
Я, конечно, такой организатор сообщества со стажем 20-летним, очень хотел бы сделать какую-то коллаборацию, договориться о правилах игры, соблюсти интерес всех сторон и дать возможность использовать этот продукт и зарабатывать на нем деньги. Ничего не вижу плохого, что он нас идет в коммерческой модели по лицензированию. Это нормальная история. Содержать штат разработчиков это дорого, вы все прекрасно понимаете.
54:37
Но мы готовы это делать, нас инвестиции идут в это постоянно. Поэтому я за коллаборации, я за сотрудничество и нахер прекрасные ноти, включаясь микрофон, и с удовольствием буду слушать дальнейшие доклады по конференции. Спасибо большое. Да, благодарю ERP-модуле. Кстати, я вижу, вы же соседи, получается, по инополису, хотя я понимаю, что физически вы в разных местах, не буду их озвучивать.
55:06
потому что надо двигаться дальше. И вот у нас Малышев Станислав Олегович.
