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

Видео по ссылке 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 - сырая ерунда (сам с ней мучаюсь)

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

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

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

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

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

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

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

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

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

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

Самый эффективный способ преодоления сопротивления при внедрении учета

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

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

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

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

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

Принцип звучит так: "Нет данных в системе - значит эту работу не работал"

Приведенный алгоритм работает и со сделкой и с окладом. Про оклад ниже опишу как.

Алгоритм следующий

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

2. Взаимодействуете, собираете обратную связь, вносите коррективы
3. В конце месяца при выдаче зарплаты говорите сотруднику сколько бы он получил согласно системе (сколько работ он туда навносил)
4. В начале второго месяца опять выступаете перед всеми и напоминаете что в этом месяце все получат ровно столько сколько наотмечают работ. И тут желательно это под роспись довести.
5. Далее в течение месяца каждую неделю напоминаете: "Напоминаю, что ЗП будет начисляться на основе внесенных в систему данных"
6. Накануне выдачи ЗП спросить: "все всё внесли в систему? завтра поблажек не будет"
7. Выдать ЗП согласно рассчитанных данных.

Вот тут будет много нытья и тп. Но все предупреждения, про которые я говорю, неспроста и сводят диалог к следующему:
- тебя месяц назад предупреждали?
- да
- в этом месяце каждую неделю слышал?
- да
- 3 дня назад напоминал слышал?
- да
- какие еще вопросы?

В такой ситуации крайне тупо ныть, когда тебя 10 раз предупредили.

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

Как быть с окладной системой

Тут решение простое: оклад - это договоренность с сотрудником что он за эту сумму вырабатывает норму. Имея ежедневные отчеты можно построить отчет по выработке и понять сколько смен и с какой эффективностью он отработал и привязать это к мотивацию. Если не будет отмечать - выработка и ЗП не будет расти (крайне важно, она не уменьшится, а просто НЕ увеличивается). На канале есть видео про мотивацию по выработке.

Вот такой вот алгоритм. Берите на вооружение, работает безотказно) неоднократно проверено.

Коллеги, всем привет!
Решил обратиться к Вам с просьбой.

Хочу начать вести периодически эфиры на канале и надо понять что Вам интересно обсудить, какую тему раскрыть.

Напишите, пожалуйста, в комментарии под постом, интересующие Вас вопросы по оперативному управлению производством, ведению и внедрению учета/планирования.

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

Заранее благодарю за отклик)

Основная проблема ручного управления и что с ней делать.

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

Однажды я был на встрече с одним начальником производства, и к нему каждые 3 минуты подходили люди и спрашивали что делать дальше. Каждый отдельно! И каждые 3 минуты надо было решать что дальше, выбирать из заказов, анализировать и тп. Как по мне - это бред, начальник производства не этим должен заниматься.

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

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

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

Автоматизация решений производится ИСКЛЮЧИТЕЛЬНО за счёт создания рабочих правил, потому что именно правила однозначно определяют как действовать в той или иной ситуации. И вот эта однозначность и есть автоматизация принятия решения.

Чем правила проще - тем они надежней.

Например
"запускать в работу только заказы с полной комплектацией"

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

Чем меньше рабочих ситуаций охватывают ваши правила, тем больше ручных решений надо принимать.

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

Так что начните создавать четкие правила и жить уже станет легче)