Почему надо считать загрузку. Пример когда расчет помог вырасти в 3 раза за год.

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

И иногда это отмазка, а иногда реальный факт, но пока не посчитаешь реальную загрузку - не поймешь.

У нас был смешной случай в одном проекте, где начальник производства убеждал учредителей что они на полгода загружены и надо новое оборудование. А в ответ слышал "да не парься, за 3 месяца справимся")

В итоге когда посчитали загрузку выяснилось, что ключевые ЧПУ станки загружены на 7,5 месяцев при условии что уже работают 24/7.

Учредители это увидели и поехали станки покупать. В результате - за год по выпуску выросли в 3 раза.

Бывали и зеркальные ситуации, но это уже другая история)

Выложил в ютубе нашу супер-фичу как мы собираем нормировки в проектах.

Берите на вооружение)

ВИДЕО

ЮТУБ

РУТУБ

Топ 3 ошибки при внедрении планирования и автоматизации производства

1. Вера в волшебную таблетку: "вот сейчас куплю программу и все полетит"

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

2. Вера в супермена: "вот сейчас найму человека с большого завода и он мне все построит"

Я еще называю эту ситуацию "водитель майбаха") это когда производство в ручном режиме, типа такое Жигули. И хотят из нее сделать Майбах и нанимают водителя Майбаха.

И тут диалог в стиле:
- мне нужно чтобы ты сделал из моей Жигули - Майбах
- ну я же Майбах только водил
- ну ты же знаешь как там все устроено

А по факту - он знает как хорошо водить Майбах, а не как превращать Жигули в Майбах. Это задача инженеров - совсем других людей.

3. "Надо сразу все делать по уму"

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

Аналогия из спорта: не поставив базовые навыки пытаться сразу качать навыки профессионалов, которые по факту без базы не освоить. Например в единоборствах пытаться разучивать комбинации ударов, когда техника ударов не поставлена.

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

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

Видео по ссылке: https://clck.ru/39kSEL

Почему технологам трудно внедрять учет

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

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

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

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

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

Что тут делать?

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

Всем привет. Часто в проектах встречаю ситуация с неразберихой в номенклатуре, что она не упорядочена. Поиск новых позиций на словах затруднен, потому что одно и то же называют по-разному.

Поэтому решил записать небольшой гайд как быстро присвоить артикулы продукции и упростить взаимодействие между подразделениями и внутри них.

Ссылка на видео: https://youtu.be/DgBLsYJydTs

Выступление Виктории Нестеровой (продолжение)

Больше всего фич в удержании

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

Большим открытием стало когда опросили рабочих чего еще хотелось - самым популярным оказались грамоты!
Люди хотят грамоты за свои заслуги)

Итоги

Надо бить по всем 3м этапам, причем по 2 и 3 активнее.
Сейчас время сотрудника, он выбирает где лучше условия труда
Если вы платите ниже рынка - от вас свалят 100%. Так же как рынок - будут сравнивать по условиям и комфорту труда.

Новое видео на канале.
Рассказываю про решение проблемы невыполнения плана, когда люди работают на сделке и вроде как ради денег должны работать больше, но все равно не вырабатывают норму.

Ссылка на видео: https://youtu.be/iNSCfUjVQWI

На РУТУБЕ

Как бывший зам директор хлебозавода утопил в долгах небольшую фабрику

Кейс из категории "водитель майбаха".

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

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

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

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

В чем была проблема

Собственник поставил управлять бизнесом бывшего зама директора большого хлебзавода. Ну мол он большим заводом управлял, то и мне тут построит.

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

В результате этот руководитель полгода обещал "ну вот щас все пойдет" и ничего не менялось. При этом собственник ушел в долги, поперезанимал денег у кого только мог, чтобы зарплаты и аренды платить, потому что производство не окупалось. А процессом заведения новых позиций в сеть так никто и не занимался. Образцы делали по 1-2 месяца, потому что по 2 недели не могли согласовать покупку банки варенья. Ответственный за тестовые образцы сотрудник еще цехом руководил и образцы делали по остаточному принципу.

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

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

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

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

Как производства сами себе усложняют жизнь закупаясь под заказы.

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

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

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

Если нет возможности обеспечить всем заранее, надо стремиться чтобы хотя бы типовое было всегда.

Потому что самое бестолковое что может быть в таких производствах это когда производство встало из-за того что забыли заказать типовое сырье. Не хватает проблем с уникальным, так еще и типовое забывают)

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

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

Для этого существуют как минимум 2 методологии управления запасами:
1. мин-макс
2. управление запасами по потреблению.

Про каждую из них можно часовое видео записать, но вкратце суть следующая

Мин-макс

Это когда по каждой позиции определяете максимальное и минимально допустимое значения остатков и потом когда проваливаетесь ниже минимального значения - заказываете сколько не хватает до максимального

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

Управление по потреблению

По сути это апгрейд мин-макса. Тут определяется верхнее значение общего количества запасов, которые находятся на складе и в пути (заказаны у поставщика и не приехали).

Ключевое отличие - это то что заказ происходит не когда запасы опустились до определенной отметки, а регулярно (1-3 раз в неделю-две) и ровно столько сколько потратили с прошлого заказа.
Например МДФ 16 покупаете пачками, храните 5 пачек и заказываете раз в неделю по чт.
Наступает чт и в наличии 3 пачки - значит 2 пачки надо заказать. Если уйдет 3 - закажите 3. Главная задача - рассчитать нормы так чтобы пополнение успевало приехать до того как все закончится.

Плюс подхода - высокая оборачиваемость и запасы ниже чем в мин-макс.
Минус - сложнее внедрить.

Изучайте, внедряйте и упрощайте себе работу)

Новое видео на канале.
Рассказываю про ошибки в наборе компетенций в проектных командах на внедрение автоматизации на производстве, и какой набор необходим для успеха.

Видео по ссылке https://youtu.be/AT_sKGc8MJE

#лайфхак

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

Получается там смотрели как что размещать чтобы не повредить и по факту заполнения ячейки заказывали машину.

Как вам такое решение?)

Всем привет. С прошедшим праздником Великой Победы!

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

Видео по ссылке: https://youtu.be/yUuN8Kmu1J8

Сила, что тормозит запуск любого проекта

Я ранее писал почему технологам тяжело внедрять учет, что они пытаются учесть все нюансы технологии.
Но есть еще одна очень похожая проблема, причем это проблема сильно думающих людей с хорошей фантазией)

Это попытка предусмотреть все возможные ситуации стечения обстоятельств и застраховаться от них всех.

На практике это выглядит как выдумывание каких-то коней в вакууме в стиле "а что если и то произойдет, и то, а еще и этим усугубится... вот как тогда быть?"

На эту тему есть хороший анекдот про то когда генерал у солдата спрашивает "а что будешь делать если на тебя и танки пойдут, и самолеты, и террористы" на что тот отвечает "товарищ генерал, а я что один в нашей армии воюю?"

Мы когда подобные фразы слышим задаем всего один вопрос - "как часто такие ситуации возникают"
Самое смешное что ответ почти всегда такой: "ну пока не случалось (за 5-10 лет), но вдруг произойдёт..."

Еще эти фразы могут начинаться так: "ну вот если вырастим в 20 раз, то там может произойти такая ситуация что..."

Продолжая так фантазировать и в 2 раза не вырасти!

В чем беда

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

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

Как быть

Первое решение (именно первое, о нем речь) задачи (автоматизации или регламент какой-то) никогда не надо строить вокруг 5-10% случаев. Новая система или правило должно хорошо отрабатывать в 80-90% ситуаций, остальное как-то костыльно должно проходить.

Логика такая что создание системы, решающей 80% задач может занять например 3 месяца, а 85% - уже 5-6 мес. Потому что эти дополнительные 5% в 2 раза усложняют всю систему и требуют усложненного алгоритма работы для первых 80% системы. Т.е. требуют работать по усложненному алгоритму даже там, где этого не требовалось.

Пример
На производстве трансформаторных подстанций можно вести учет на уровне элементов (например шкафов), а можно на уровне отдельных деталей (стоек, крышек и тп).

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

Решение

1. Проверяйте реалистичность "хотелок" своих людей (или самих себя, если вы являетесь таким человеком), задавая вопрос: "как часто озвученные ситуации возникают" и отсекайте все "гипотетические ситуации".
2. Научитесь говорить: "СТОП, давайте пока хоть что-то запустим, а потом будем улучшать." Иначе старт никогда не наступит

P.S. в следующем посте расскажу как в одной из крупнейших ИТ компаний мира работают с этой же проблемой и откуда у нее ноги растут.

Как запустить онлайн учет простоев оборудования за 1 день.

Видео как выглядит и работает
На ютубе https://youtu.be/c2gnytcbVc4
На рутубе https://clck.ru/3GFQca

Запросить шаблон с инструкцией сразу https://clck.ru/3GFQaF

Главная проблема технарей, которой не избежать даже Майкрософт

Все кто давно пользуется операционной системой Windows наверняка заметили, что они делают удачную систему через 1 версию

98й - норм
2000 - не очень
ХР - отличный
Vista - ужас
7ка - отличная система
8ка - что-то не понятное
10ка - опять норм
11 - сырая ерунда (сам с ней мучаюсь)

Почему так происходит

На рынке ПО так же как в любом бизнесе лучше быть первым, чем лучшим. И разработчикам надо выпускать новые версии своих программ.
У них стоит дедлайн, когда они должны выпустить систему.
И у Майкрософта когда они создают новую платформу к этому дедлайну как правило все очень сыро, но надо выпускать. И они вываливают на рынок полную жуть, потом хапают г*вна и проклятий от пользователей, и на основе этой всей обратной связи запиливают новую систему с решением всех этих проблем, и называют ее по-новому, мол она не та, тут все хорошо.

Схема рабочая как видите)

Но почему так происходит, почему выпускают сырое.

А потому, что если не ставить дедлайн - релиз не выпустят НИКОГДА))

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

Разработчики, да и вообще технари, очень часто перфекционисты. Они реализуют функцию, потом смотрят свой код и думают: "о, а это же можно сделать так..." и начинают переделывать. Это так работает, поверьте, я сам технарь и такой ерундой страдал пока не стал предпринимателем.

А предпринимателю (менеджеру) важно решить задачу, причем не важно каким образом, и идти дальше. И поэтому в ИТ компаниях менеджеры контролируют готовность задач и требуют делать другие задачи, а не переделывать старые, которые сделаны "на троечку")

Как вам это использовать

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