Внедрение изменений в автоматизированном бизнесе

20.06.18

Бизнес-анализ

Кто, на самом деле, мешает внедрять изменения?

Когда на предприятии затевается внедрение информационной системы, особенно силами внешнего подрядчика, то почти всегда говорится: самое большое препятствие – это люди. Сама система, кодирование нового функционала, обучение – это просто трудозатраты. А вот преодолеть саботаж внедрения, переломить мышление, особенно руководителей, заставить выйти из зоны комфорта старой системы (даже если она ужасна) – это действительно трудно. Причем, внедренцы обычно говорят: основная работа по «изменению людей» должна лежать и лежит на заказчике.

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

В ней есть все нужные объекты – документы, справочники, отчеты, формочки, интеграция. До, или после, или в процессе у нас появляется сайт, портал для работы с поставщиками, CRM-система, MDM-система, PLM, PDM, MES и т.д. И все это интегрировано между собой в необходимой степени. Все системы удовлетворяют требованиям компании, зафиксированным на момент внедрения. Грубо говоря, перед нами – снапшот компании в информационном поле. Ну разве не прелесть?

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

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

С точки зрения директора по закупкам, да и с обывательской, изменение простое, плюнуть и растереть. План продаж известен, динамика продаж известна, скорость отгрузки по каждой позиции известна (сколько штук отгружается, например, за месяц), время пополнения известно (количество дней от заказа у поставщика до поступления на склад). Просто выкидываем план закупа, и заменяем его целевым уровнем. Раньше в плане продаж было написано «купить 100 втулок», теперь в целевом уровне написано «поддерживать запас в 40 втулок на складе». Вместо работы месяцами, теперь надо работать каждый день, причем по очень простой математике: смотришь, сколько втулок на складе, добавляешь количество уже заказанных поставщикам – если получилось меньше 40, заказываешь недостающее количество. Все.

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

Все, счастье близко. Дефицитов не будет, простоев не будет, неликвидов не будет, запасы на складе (= замороженные деньги) снизятся. Что дальше? Автоматизация, будь она неладна. Нельзя же все расчеты вести на коленке?

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

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

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

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

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

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

Но претензии появляются, и очень быстро. План закупа в системе есть, а его выполнения – нет. Они ведь заказывают не 100 штук, как в плане, а 5, 4, 13 и т.д. Они не ходят продавцам объяснять, что те никогда не продавали 100 втулок в месяц, и цифра эта взята с потолка – продавцы просто страхуются от дефицита, затаривая склад. Потому что склад, его динамика и неликвиды находятся вне зоны ответственности продавцов. В итоге цифра, которая называется «план/факт закупа», быстро становится «плохой». В идеале должно быть 100%, а в реальности получается то 30 %, то 150 %, потому что объем реального закупа теперь диктуется скоростью отгрузки, а не фантазиями.

Директора по закупкам теперь начинают напрягать не только за желание выбросить миллионы на ветер, но и за банальное неисполнение своих обязанностей. Кто конкретно это делает – зависит от орг.структуры компании, но такая служба всегда найдется.

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

Почему так произошло? Можно во всем винить политику, бюрократию, корпоративные интересы и подковёрные игры, но в чем первопричина? Почему такое простое изменение, на внедрение которого в самом функциональном подразделении уходят часы или дни, в остальных, взаимосвязанных отделах не может даже начаться?

Основная причина – информационная система и ИТ-отдел, главная задача которого вытекает из старой программистской мудрости – «не трогай то, что работает».

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

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

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

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

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

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

Вернемся еще раз к исходной ситуации, и представим идиллию – никто не сопротивляется, все двумя руками «за», все поддерживают изменения и болеют за предприятие. Бывает же такое? Наверное.

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

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

Двигаемся дальше, ждем месяц-два, и вот система готова. Ура! Всего два месяца! Еще пару месяцев тратим на изменения в тех частях системы, которые отвечают за взаимодействие со смежными службами – те же бюджеты, статический план продаж выкидываем (он вроде не нужен больше), вместо него будет динамический портфель заказов, и т.д. Хватит пару месяцев? Пожалуй, нет… Ладно, пусть будет 4 месяца. Итого полгода. Все, счастье наступило. Вся компания напрягалась, работала, внедряла изменения, и наконец – все нюансы учтены, все критерии успешности достигнуты, все заказчики довольны, система работает. Запасы снижаются, продажи растут, денежный поток выравнивается, сроки отгрузки клиентам снижаются. Прелесть!

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

Схема просто прекрасна. Теперь 40 деталей лежат не на нашем складе, а на складе поставщика. А мы просто забираем на свой склад в любой момент столько, сколько нам нужно. Или даже не забираем себе – зачем лишнее звено? — просто грузим в машину и сразу отправляем покупателю. Наш склад вообще не участвует, даже в качестве транзитного.

Ну разве не прелесть? Особенно, если платить мы будем только за те детали, которые физически забрали, а не за весь объем произведенного поставщиком. Транспортные расходы снижаются, внутренние услуги по погрузке/разгрузке больше не требуются в прежнем объеме – можно сократить кладовщиков и грузчиков. Запасы снижаются еще сильнее, вплоть до освобождения прежде занятых складских помещений – теперь их можно использовать иначе, от сдачи в аренду до использования под производственные мощности.

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

И вот герой с горящими глазами бежит к ИТ-директору. У того глаза уже несколько попритухли, после полугодового напряга с изготовлением нового снапшота – «информационной системы, удовлетворяющей всем требованиям заказчика». Слушает, кивает, пытается делать заинтересованное лицо. А про себя думает: ёёёёёё, это ж как мы будем учитывать запасы поставщиков? Это ж какую-то интеграцию с их системами надо делать? Мааааааать моя… А там у них наверняка такой зоопарк систем, которые и интегрироваться-то не умеют. С каждым отдельный обмен данными писать, наша система ведь не имеет никакой шины интеграции. Потому что ни в одной из версий снапшота о такой возможности речи не было. Остальные руководители на идею реагируют так же вяло. Юристы беспокоятся о перезаключении договоров. Бухгалтерия – о внедрении системы ответственного хранения (черт, там же еще и забалансовые счета придется использовать, раньше избавлял от них Господь как-то). Транспортники переживают об усложнении маршрутов – не поедешь же за пятью деталями в другой город? Надо ехать сразу к нескольким поставщикам, чтобы был сборный груз. Отдел качества недоумевает, как ему теперь детали проверять – раньше-то ему во двор все привозили. А теперь как? Выездные проверки делать? Системы контроля качества согласовывать? Блин, не знали горя…

Общий энтузиазм равен нулю, или почти нулю. Совместное мнение – ты, конечно, классный чувак, здорово заботишься об изменениях и судьбе компании… Но ведь из-за тебя полгода напрягались, а ты, не дав отдохнуть, затеваешь новые изменения. Давай хоть годик отдохнем, привыкнем, мы еще свои процессы не устаканили, периодически сбои возникают. Горшочек, не вари.

По какому сценарию двинется изменение?

См. также

Фаза пресейла: насколько глубоко нужно погружаться в бизнес-домен?

Анализ предметной области Анализ потребностей и поиск решений Бесплатно (free)

В статье объясним значение погружения в бизнес-домен, расскажем о возможных проблемах и ограничениях, а также путях поиска информации о бизнес-домене.

25.03.2024    231    0    alenkaiva    0    

2

Как реорганизовать работу проектного департамента, чтобы быть №1

Внедрение изменений Бесплатно (free)

Методики быстрореагирующего производства и QRM-ячейки применимы не только к станкам, но и к проектным командам. О том, как за счет разделения проектного офиса на многофункциональные QRM-ячейки обеспечить равномерную загрузку работу сотрудников, вырасти в два раза и существенно повысить лояльность заказчиков и коллектива, пойдет речь в статье.

14.02.2024    558    0    user1270271    2    

7

Управление ожиданиями на проекте

Работа с заинтересованными сторонами Бесплатно (free)

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

08.02.2024    453    0    izybaevda    0    

5

Как внедрить 1С:ERP за 2 года и не сойти с ума

Анализ предметной области Анализ потребностей и поиск решений Внедрение изменений Бесплатно (free)

Для руководителей подразделений новые проекты вызывают желание получить максимальный эффект от реализации идей, а также опасения, верно ли выбран ориентир нововведений. О том, как справиться с трудностями, дойти до цели и внедрить 1С:ERP на производственном предприятии, ежедневно выпускающем десятки тысяч единиц готовой продукции, расскажем в статье.

30.01.2024    6707    0    user1578851    16    

16

Свободное программное обеспечение в крупной компании – миф или реальность? Как мы переводили 2500 пользователей на Linux

Внедрение изменений Бесплатно (free)

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

29.01.2024    2418    0    user1063453    2    

5

Зачем нужны аналитики на проектах автоматизации

Анализ потребностей и поиск решений Бесплатно (free)

Исторически сложилось так, что аналитик 1С многими воспринимается как вечный падаван, который обеспечивает разработчиков информацией, а пользователей – инструкциями. Не согласимся с таким подходом и на примере реального кейса покажем, почему именно аналитик должен стать лидером проекта автоматизации.

18.01.2024    1592    0    user1754524    19    

12

Радио "Аналитик", 7 выпуск 2 сезона. Про работу аналитика с бизнесом и повышение бизнес-компетенций с Константином Семёновым

Анализ предметной области Работа с заинтересованными сторонами Анализ потребностей и поиск решений

В седьмом выпуске второго сезона подкаста Радио “Аналитик“ поговорили о том, что такое бизнес-компетенции, для чего они нужны аналитику, к чему может привести их отсутствие и как их развивать.

28.11.2023    414    0    Radio_Analyst    0    

2
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. coolseo 79 21.06.18 08:41 Сейчас в теме
Прочитал на одном дыхании!
2. yyv-911 21.06.18 13:03 Сейчас в теме
Всем понятно что изменения они постоянны и будут. Всем понятно что идеально не сделаем. Но почему то все всегда пытаются сделать именно скриншот текущего состояния или довести до идеала прежде чем пустить в продуктив.
А текущее состояние всегда прошлое и как следствие старое. А вот определить следующие ключевые точки будущего (направление) не могут. Хотя бы на 1-2 шага вперед. Не способен бизнес планировать. Даже применяя каты - в начале нужно дойти (определить целевое состояние) и только потом спланировать следующую точку. Только вот целевое состояние уже изменилось....
Если люди способны на фантазию и абстракцию получаем направление развития на десятки лет вперед. Поболтали в курилке - все поняли куда бежим. Все ньансы болтунов заложились в систему хотя бы на уровне плана. Оставлены заглушки, выполнен специальный вызов процедур с заделом на будущее, что бы не переделывать и т.д. Сам оставляю запас на переделку. Да и начальника то как таковое получается в такой системе нет.

Контора досталась после франча - все сделано как скриншот.
Стандартные запросы на доработку сейчас - а пусть в момент проведения (когда я "ОК" нажимаю) Отчета за смену формируется ещё и требование накладная по времени чуть раньше чем ОПЗС. Это же так правильно - это же автоматизация.


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

2. Нам нужна отсылка по почте только при проведении реализации. А при проведении поступления? Зачем? Никогда этого не будет.

Часто выполнением в лоб грешат франчи.
Нужно при проведении приходной накладной - отправлять на почту предупреждение
франчи пишут и все работает. деньги получены, все довольны.

А потом следующая задача:
А давай отправку на почту ещё и при проведении реализаций.
2 дня работы. а почему так долго? нам же уже отправку на почту сделали в прошлый раз.
Вам её сделали исключительно для конкретной отправки из поступления. А сейчас все либо заново делать, либо переделывать всю отправку.

Там где соглашаются на дополнительные траты на переделку и универсальность. Жутко довольны. И система получает дальнейшее развитие, определяются дальнейшее будущее. И получаются и заказы. Теперь уже в результате небольшой доработки (без программиста) отправка идет уже из 5 документов.
Там где не хотят делать правильно - а воз и ныне там. Лично встречал 4 процедуры отправки на почту (в одной конфигурации) писем по одной логике. Пароль и почта прямо в коде прописаны в каждой процедуре.
3. pm74 199 25.06.18 10:20 Сейчас в теме
(0)
просто выкидываем план закупа, и заменяем его целевым уровнем. Раньше в плане продаж было написано «купить 100 втулок», теперь в целевом уровне написано «поддерживать запас в 40 втулок на складе». Вместо работы месяцами, теперь надо работать каждый день

выделил (имо) ключевую фразу
Динамическое управление буфером вещь конечно хорошая , и наглядная , но могут быть нюансы.
например если в организации несколько тысяч SKU , их трудно мониторить в ежедневном режиме
4. 1c-intelligence 12771 25.06.18 10:24 Сейчас в теме
(3) периодичность - легко регулируемый параметр. Ну, вы и сами знаете.
5. pm74 199 25.06.18 10:36 Сейчас в теме
(4) я говорю о программном управлении величиной целевого уровня
как насчет проблемы описной например http://tocpeople.com/2017/01/dinamicheskoe-upravlenie-buferom-ideya/
когда размер буфера очень быстро увеличивается или уменьшается системой
6. 1c-intelligence 12771 25.06.18 10:40 Сейчас в теме
(5) в примере из статьи речь шла не об управлении размером буфера, а о периодичности заказа поставщику для его пополнения. Когда работают по месячному плану, периодичность заказа очень большая, а когда по буферу - намного меньше.

Часто менять буфер - зло. У нас был проект, руководил которым (в методическом аспекте) автор сайта tocpeople.com (Вальчук). Он сказал, что менять размер буфера надо после периода наблюдений не меньше, чем период пополнения.
7. pm74 199 25.06.18 11:02 Сейчас в теме
(6) я как раз сейчас и занимаюсь этой темой на одном заводе
есть один снабженец и очень большой ассортимент SKU с разными сроками поставки, - фактически нереально отслеживать целевые уровни вручную , т.е. нужен алгоритм
начал экспериментировать с различными моделями поведения системы и разными параметрами (периодичность заказа , сроки поставки , начальная величина буфера , периодичность ревизии и проч. ) пока результаты неутешительные
проблема неконтролируемого роста/уменьшения осталось , хотя удалось ее немного нивелировать
8. 1c-intelligence 12771 25.06.18 11:07 Сейчас в теме
(7) у нас алгоритм был примерно такой.
Берем состояние буфера за период пополнения.
Если оно в основном красное, то повышаем ЦУ на треть
Если оно в основном зеленое, то понижаем уровень на треть.

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

Смысл вроде в том, чтобы не мельчить с изменением буфера, а бахать сразу на треть.
9. pm74 199 25.06.18 11:12 Сейчас в теме
(8)
Если оно в основном красное, то повышаем ЦУ на треть

как при повышении , так и при снижении , может случиться ситуация "всегда в красном" или "всегда в зеленом"
я это к вопросу , возможно ли управлять буфером совсем без человеческого участия ?
10. 1c-intelligence 12771 25.06.18 11:17 Сейчас в теме
(9) на то и было рассчитано - обработка изменения ЦУ работала автоматом, без участия человека. Идеалом, как я понял, была ситуация "всегда в желтом".
11. pm74 199 25.06.18 11:19 Сейчас в теме
(10)
деалом, как я понял, была ситуация "всегда в желтом".

все по "классике жанра"
завтра доеду на завод и выложу графики
12. pm74 199 25.06.18 11:23 Сейчас в теме
(10) слегка выправила ситуацию функция контроля скорости расхода с момента последней поставки
13. genayo 25.06.18 12:09 Сейчас в теме
(9) Можно, но, согласно ТОС, не правильно :))
14. pm74 199 25.06.18 12:19 Сейчас в теме
(13) не видел таких условий нигде
15. genayo 25.06.18 12:28 Сейчас в теме
(14) Там-же, на http://tocpeople.com где-то была такая дискуссия. И ТОС ведь не наука, чтобы нельзя было что-то свое привносить.
Аргументация там такая была примерно - человек, отвечающий за размеры буфера, быстрее (а, может быть, и раньше, чем условия изменятся) увидит, что по какому-то SKU изменились некоторые условия, и для него надо менять модель расчета уровней буфера.
16. pm74 199 25.06.18 12:33 Сейчас в теме
(15)
человек, отвечающий за размеры буфера

вот тут и засада
резонный вопрос от снабженца будет - " Почему программа сама не может это сделать согласно теории"
18. genayo 25.06.18 12:39 Сейчас в теме
(16) Очевидно, что программа сможет это делать, если будет обладать полными данными по условиям применения, закупки, доставки по всем СКЮ в реальном времени. Снабженец готов отслеживать и вносить все эти данные ?
20. pm74 199 25.06.18 12:44 Сейчас в теме
(18) все данные в наличие есть
программа должна лишь определить нужно или нет снижать или увеличивать целевой уровень
21. genayo 25.06.18 12:46 Сейчас в теме
(20) Есть данные, что Поставщик изменит через 2 недели квант/периодичность заказа, или, например, что вы через месяц меняете технологию, и количество сырья А уменьшится на 70%, а сырья Б возрастет на 50%?
22. pm74 199 25.06.18 12:51 Сейчас в теме
(21) даже в том случае если ничего не меняется
коротко опишу проблему :
допустим программа знает , что нужно увеличить размер буфера при наступлении определенного события , например уровень запаса завис "в красном" N дней , но при увеличении буфера красный уровень тоже увеличивается появляется ситуация "всегда в красной" . Мы покупаем все больше и больше до бесконечности
человек легко увидит эту коллизию на графике
24. genayo 25.06.18 13:21 Сейчас в теме
(22) Так вопрос в том, на сколько вы увеличиваете буфер. Если увеличили достаточно, то после следующей закупки мы должны оказаться как минимум в желтой зоне (а лучше в зеленой).
25. pm74 199 25.06.18 14:15 Сейчас в теме
вот иллюстрации ошибок ,
как минимум в желтой зоне (а лучше в зеленой)

голубая линия - заказы как видите по уровню зеленой зоны ,
первый пример более показательный т.к. в данном случае человек не стал бы снижать уровень запаса а система это сделала
можно конечно сказать , что настройки выбраны не оптимально , и проч. , я экспериментировал с разными вариантами
Прикрепленные файлы:
26. genayo 25.06.18 14:37 Сейчас в теме
(25) Я не понимаю, зачем менять уровень буфера, если мы всегда в зеленой зоне? И почему на однократный всплеск потребления мы увеличиваем уровень буфера? Кстати, это хорошая иллюстрация, почему конечное решение об увеличении уровня буфера должен принимать человек.
27. pm74 199 25.06.18 14:43 Сейчас в теме
(26) я и говорю , что человек бы отследил такую ситуацию

это простая модель , где решение принимается системой только по заданному количеству дней
29. genayo 25.06.18 15:11 Сейчас в теме
(27) Нет, я не понимаю зачем вообще изменять буфер, если мы все время в зеленой зоне? Зеленая зона - это значит все хорошо, и ничего менять не надо.
30. pm74 199 25.06.18 15:13 Сейчас в теме
(29) согласно "теории" вы должны снизить размер буфера если долго находитесь в зеленой зоне
32. genayo 25.06.18 15:15 Сейчас в теме
(30) Да, но только после того, как вы получили подтверждение, что модель работает, и проработали на ней достаточное время. Если вы только начали внедрять - это неправильно.
33. pm74 199 25.06.18 15:17 Сейчас в теме
(32) это пока еще не внедрение , а моделирование на реальных данных по расходу прошлых периодов
обработку кстати скачал здесь на ИС , к сож. не помню точный адрес
34. pm74 199 25.06.18 15:23 Сейчас в теме
(32) что значит модель работает ?
и какая должна быть модель ?
можно ли сказать что модель работает по графику ?

есть общие фразы типа снижайте когда зеленая повышайте когда красная
36. genayo 25.06.18 15:32 Сейчас в теме
(34) Вот общие фразы точно не стоит на веру принимать, чревато быстрым разочарованием.

Модель - Это, в терминах ТОС, МТО/МТА, например, в зависимости от модели выбираются начальные размеры буфера.
Ну и, по моему мнению, чистое управления запасами по буферу возможно далеко не всегда.
37. pm74 199 25.06.18 15:44 Сейчас в теме
(36) с mto вроде бы проблем (расчетных) должно быть меньше. есть размеры, сроки этот вариант уже отчасти работает , как минимум снабженец видит в своем арм светофор по срокам
35. pm74 199 25.06.18 15:26 Сейчас в теме
(32) далее стал вводить различные другие параметры напр. скорость расхода с момента поступления , график немного выровнялся , но не могу сказать , что идеально
28. pm74 199 25.06.18 14:46 Сейчас в теме
(26) но если количество sku очень велико что делать ?
31. genayo 25.06.18 15:13 Сейчас в теме
(28) Выдавать человеку для решения только те позиции, которые в красной зоне, несмотря на то, что поставки делались согласно размерам буфера. Если их очень много - значит вы ошиблись с моделью своего производства/продаж или с размерами буфера.
38. pm74 199 25.06.18 15:47 Сейчас в теме
(31)
Выдавать человеку для решения только те позиции, которые в красной зоне


похоже придется остановится на этом варианте
17. pm74 199 25.06.18 12:37 Сейчас в теме
(15)
ТОС ведь не наука


слово теория в названии как бы намекает ))
19. genayo 25.06.18 12:40 Сейчас в теме
(17) Да это же чисто маркетинг, продать методику, претендующую на научность, можно дороже и более широкому кругу потребителей.
23. pm74 199 25.06.18 13:11 Сейчас в теме
очень грустно , если всё только вручную
41. l1ike 09.07.18 10:39 Сейчас в теме
(17) Голдрат, как бы, не сам всю теорию придумал, если хотите больше теории, можно обратиться к первоисточникам. Пример с пополнением складских остатков встречал в http://baguzin.ru/wp/donella-medouz-azbuka-sistemnogo-mysh/
39. doctor_z 04.07.18 10:36 Сейчас в теме
Дичь какая-то.
На месте гендиректора такого it гнать нахер с работы. Хотя скорее всего он его родственник.
Ибо бизнес это живая материя, и постоянное изменение стратегии и тактики суть жизнедеятельности. Как в Алисе. Надо бежать со всех ног, чтобы остаться на месте. А чтобы двигаться, надо бежать еще быстрее.
40. 1c-intelligence 12771 06.07.18 09:36 Сейчас в теме
Друзья, прошу прощения за спам - поучаствуйте в голосовании.
Оставьте свое сообщение