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

Публикация № 850319

Методология - Управление проектом

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Специальные предложения

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


слово теория в названии как бы намекает ))
19. genayo 25.06.18 12:40 Сейчас в теме
(17) Да это же чисто маркетинг, продать методику, претендующую на научность, можно дороже и более широкому кругу потребителей.
23. pm74 163 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 9482 06.07.18 09:36 Сейчас в теме
Друзья, прошу прощения за спам - поучаствуйте в голосовании.
Оставьте свое сообщение

См. также

7-ой PMBoK - конец классического проектного управления? Часть 1-ая

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

В новой версии PMBoK традиционные рекомендации по управлению проектами перевернуты с ног на голову. В этой статье расскажу свою точку зрения, в чем, на мой взгляд, основные изменения, и как это может сказаться на проектах внедрения…   

23.01.2020    3761    MariaTemchina    6       

1C:Предприятие для программистов: Запросы и отчеты. Второй поток. Онлайн-интенсив с 17 марта по 16 апреля 2020 г. Промо

Данный онлайн-курс предусматривает углубленное изучение языка запросов и возможностей системы компоновки данных, которые понадобятся при разработке отчетов, работающих на платформе “1С:Предприятие” в рамках различных прикладных решений. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие”, а также для опытных пользователей различных прикладных решений, которые используют в своей работе отчеты разного назначения.

6500 рублей

Про одну Тётю

Статья no Нет файла Бесплатно (free) Управление проектом

Суровое челябинское распределение ресурсов

24.12.2019    4323    1c-intelligence    32       

20 мыслей об ИТ-проектах. Мысль №3. "О правильных требованиях к системе"

Статья no Нет файла Бесплатно (free) Управление проектом

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

14.10.2019    3762    chavalah    16       

Базовый курс по обмену данными в системе 1С:Предприятие. Онлайн-интенсив с 12 по 28 мая 2020 г. Промо

Данный онлайн-курс предусматривает изучение механизмов платформы “1С:Предприятие”, обеспечивающих обмен данными между различными прикладными 1С-решениями и взаимодействие с другими информационными системами. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие”.

5500 рублей

Незакрытый проект на 1000 часов

Статья no Нет файла Россия Бесплатно (free) Управление проектом

История о незакрытом проекте, о бессонных ночах, о попытках его выгрести, о бесплатной работе, о вселенской боли.

19.09.2019    9150    ogroup    161       

Стратегия выживания в корпоративных войнах

Статья no Нет файла Бесплатно (free) Управление проектом

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

16.09.2019    6526    GSoft    15       

Подборка решений для взаимодействия со ФГИС «Меркурий» Промо

С 1 июля 2019 года все компании, участвующие в обороте товаров животного происхождения, должны перейти на электронную ветеринарную сертификацию (ЭВС) через ФГИС «Меркурий». Инфостарт предлагает подборку программ, связанных с этим изменением.

Мастер-класс СППР

Статья Программист Руководитель проекта Нет файла Бесплатно (free) Управление проектом СППР

Сергей Наумов, в прошлом разработчик подсистемы бюджетирования в конфигурации «1С:ERP», на мастер-классе конференции INFOSTART EVENT 2018 EDUCATION поделился опытом управления проектами с помощью «1С:Системы проектирования прикладных решений» и показал, как использовать эту программу в работе над разными задачами: для сбора, классификации и хранения требований; для управления разработчиками и консультантами; в качестве системы документирования; в качестве баг-трекера на этапе опытно-промышленной эксплуатации.

30.08.2019    7068    SergeyN    4       

Быстрый старт: минимальный набор автоматизации типовых процессов

Статья no Нет файла 1С:Франчайзи, автоматизация бизнеса Бесплатно (free) Управление проектом

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

16.08.2019    5638    Hissin    18       

Онлайн-курс "Подготовка к экзамену 1С:Эксперт и 1С:Профессионал по технологическим вопросам" с 7 по 24 апреля 2020 г. Промо

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

16450 рублей

Как заработать миллион или История успешного сотрудничества

Статья Программист Нет файла Бесплатно (free) Управление проектом

Многие мечтают один раз что-то создать, а потом жить на заработанные деньги до конца своих дней. Но миллионерами становятся не все, их единицы. Среди них – разработчик Андрей Карпов. Человек, который сумел за полтора года заработать 2 миллиона рублей чистой прибыли, поделился с гостями конференции Infostart своими секретами.

05.08.2019    5937    karpik666    77       

Бизнес-аналитика с помощью Power BI

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

11.07.2019    9126    pbazeliuk    18       

INFOSTART MEETUP Krasnodar. 14 февраля 2020 г. Промо

Краснодар станет первым в 2020 году местом, где пройдет региональная встреча IT-специалистов сообщества Инфостарт. Тема мероприятия - управление и технологии автоматизации учета на платформе "1С: Предприятие". Стоимость участия - 5000 рублей. Цена действительна до 26.12.2019.

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

Статья Бизнес-аналитик Руководитель проекта Нет файла УУ Финансовый учет и бюджетирование (FRP) Бесплатно (free) Управление проектом

Автоматизация бюджетирования позволяет максимально эффективно планировать ресурсы предприятия и управлять масштабированием компании. Как учесть особенности бюджетирования, встроить его в процессы стратегического планирования, чтобы получить гибкий инструмент управления и аналитики, рассказал Сергей Наумов на конференции INFOSTART EVENT 2018 EDUCATION.

28.06.2019    4825    SergeyN    1       

Внедрение решений: как выполнять все обязательства в срок в условиях ограниченных ресурсов

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Многие менеджеры вынуждены работать в условиях многоклиентской среды с ограниченными ресурсами. И вовремя сдавать проекты в таких условиях сложно. Как добиться того, чтобы поставки делались без нарушений сроков, рассказал гостям и участникам конференции Infostart Event 2018 управляющий партнер BIPULSE.RU Алексей Васильев.

24.06.2019    4289    sbase    9       

1C:Предприятие для программистов: Расчетные задачи (зарплата). Онлайн-интенсив с 01 по 17 июня 2020 г. Промо

Данный онлайн-курс предусматривает изучение механизмов платформы “1С:Предприятие”, которые предназначены для автоматизации периодических расчетов, а именно - для расчета зарплаты. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие”, а также для опытных пользователей прикладного решения “1С:Зарплата и управление персоналом” и прочих прикладных решений, в которых реализован функционал расчета зарплаты.

4900 рублей

Риск - благородное дело!.. Часть первая

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Несколько рекомендаций по управлению рисками в ИТ-проектах.

18.06.2019    5307    MariaTemchina    8       

Мы в ответе за то, чего вовремя не послали. Матрица ответственности в проектах внедрения

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

31.05.2019    5753    MariaTemchina    23       

Готовые переносы данных из различных конфигураций 1C Промо

Рекомендуем готовые решения для переноса данных из различных конфигураций 1C. C техподдержкой от разработчиков и гарантией от Инфостарт.

Что важно, а что - срочно?

Статья no Нет файла Бесплатно (free) Управление проектом

Поговорим о приоритетах

20.05.2019    5989    1c-intelligence    16       

Подборка программ для взаимодействия с ЕГАИС Промо

ЕГАИС (Единая государственная автоматизированная информационная система) - автоматизированная система, предназначенная для государственного контроля за объёмом производства и оборота этилового спирта, алкогольной и спиртосодержащей продукции. Инфостарт рекомендует подборку проверенных решений для взаимодействия с системой.

Устав писать Устав

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Ответы на вопросы про то, нужен ли Устав для проектов автоматизации, и если нужен, то зачем?

06.05.2019    5263    MariaTemchina    8       

Базовый курс по управлению ИТ-проектами. Курс проходит с 26 февраля по 22 апреля 2020 года. Промо

Отличительная черта курса - органичное сочетание трех вещей: 1.Теория проектного управления (PMI®+Agile Alliance+Российские ГОСТ+Методологии от 1С); 2. Опыт внедрения продуктов 1С (опыт франчайзи и успешных компаний + тренды Infostart Event и Agile Days); 3. Разбор реальных проблем и рекомендации экспертов по проектам слушателей. Мы будем фиксироваться на тех инструментах, которые реально оказываются полезными в практике руководителей проектов внедрения. Ведущая курса - Мария Темчина.

от 11000 рублей

Путь джедая в управлении проектами 1С: умение быть, а не казаться

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Чем руководитель проекта “на бумаге” отличается от “настоящего” руководителя проекта, умеющего направлять команду и выдавать ценный результат?

15.04.2019    8472    MariaTemchina    15       

Голосование за доклады на INFOSTART MEETUP Kazan - до 25 февраля. Промо

Выбирайте и голосуйте за самые интересные доклады! Лучшие из лучших попадут в окончательную программу казанского митапа. Оставить свой голос можно до 25 февраля 2020 года.

Стыд и Скрам, часть вторая

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

14.03.2019    9638    MariaTemchina    47       

20 мыслей об ИТ-проектах. Мысль №2. "С какой стороны подойти к новому проекту?"

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

13.02.2019    5926    chavalah    22       

INFOSTART MEETUP Kazan. 13 марта 2020 г. Промо

Инфостарт продолжает путешествие по России. Следующая остановка - Казань. Тема мероприятия - управление и технологии автоматизации учета на платформе "1С: Предприятие". Ждем всех: докладчиков и участников! Стоимость участия - 5 500 рублей. Цена действительна до 30.01.2020

5 500

Стыд и скрам - Чему нас учит Scream Guide

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Название "Scream Guide" можно вольно перевести на русский как “Вопль ужаса от того, как Scrum применяют на практике”

12.02.2019    7481    MariaTemchina    20       

Бизнес, не горюй

Статья no Нет файла Бесплатно (free) Управление проектом

Про цели автоматизации.

04.02.2019    7323    1c-intelligence    64       

Сдача регламентированной отчетности из программ 1С Промо

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

от 1500 руб.

Лучший домик для поросенка, или Что нужно знать руководителю проекта внедрения

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

31.01.2019    6304    MariaTemchina    0       

Ошибки управленцев: как топ-менеджеров убивает перфекционизм

Статья no Нет файла Бесплатно (free) Управление проектом

В преддверии онлайн-конференции «Гнев и слезы руководителя» мы решили заранее познакомить нашу аудиторию со спикерами, причем сделать это через видео-истории. Начнем с видео-приглашения от Миланы Джиджоевой и ее виденья диджитализации рекрутинга в России.

24.01.2019    7717    user809424    11