Comments 13
почему IT‑проекты на производстве не дают результата
Потому что техник/мастер/кладовщик не то занес, не туда занес, забыл/забил занести; вместо суммы указал количество, серийные номера поставил в комментарий... и вообще - не нужна мне ваша автоматизация, я без нее тут 20 лет работаю и всё нормально! :(
Недавно приобщился к промышленности - тут как раз наоборот люди страдают от бумажек, от 5 версий экселевского документа с разными данными в каждом подразделении. "без нее тут 20 лет работаю и всё нормально!" сейчас кажется сложно встретить, большинство успели поработать с хоть как то рабочими системами...
Это та самая боль, про которую я и пишу. Сначала надо разобраться в корневых причинах, почему так происходит, и только потом автоматизировать. Если кладовщик 20 лет работает без системы и считает, что "всё нормально" — значит, у него работают какие-то компенсаторные механизмы. Память, блокнот, "так исторически сложилось". Эти механизмы для него — работающий процесс. Сломать его внедрением какой-либо новой кнопки не получится.
В таких случаях у меня работало две вещи:
1. Идти не с автоматизацией, а с разговором "где у тебя сейчас больше всего боли". Реальные ответы в основном получал не на рабочем месте, а в курилке или в перерыве. Там же выясняется, что "всё нормально" на самом деле "я три раза в день пересчитываю вручную и матерюсь, но привык".
2. Включать спонсора проекта в коммуникацию с этими людьми лично. Не отдавать им новую систему сверху, а позвать в разработку требований — как ему удобнее.
Тогда из саботажника человек превращается в соавтора. Без этой работы любая автоматизация — это та самая красивая цифровая копия хаоса.
Статья в точку, всё так и есть!
Год за годом, десятилетие ща десятилетием - этот велосипед изобретают и изобретают, делятся и делятся своими "открытиями". Ремесленничество есть ремесленничество. ИТ-директора таких внедрений я имею ввиду. И тех, кто таких ИТ-директоров назначает.
Согласен — проблема десятилетиями не решается. Поэтому я и пишу: не потому что считаю это открытием, а потому что вижу, как из года в год одни и те же команды наступают на те же грабли. Если кому-то одному поможет — статья своё уже сделала.
Сомнительно, что такая форма передачи опыта кому-то поможет. Вы много и подробно пишете о своих переживаниях в различных ситуациях "неправильных внедрений", но бегло и расплывчато - о полезных приемах, и совсем никак - о трудностях этих самых приемов, и о сигналах необходимости о них вспомнить. Поэтому статья - фактически художественное произведение, очередная "Анна Каренина".
По существу согласен — приёмы описаны бегло. Это формат обзорной статьи, дальше планирую разворачивать каждый шаг в отдельный гайд с трудностями применения. Какой из приёмов кажется самым важным для разбора первым?
Это всё звучит здраво, но работает только когда руководитель предприятие более менее молодой и открыт готов реально разбираться. Вот у нас поставили директора советского дуба, этот мудак нацепил на проходную орден Ленина и начал бороться с извещениями. И естественно не разбираясь почему их так много выпускают, а просто запретами и кучу работы дебил просто застопорил
Это самая тяжёлая ситуация, согласен. Когда спонсор проекта/лицо принимающее решения — сам же главный блокер изменений. Из опыта: в таких случаях обычно работают два пути. Первый — через метрики, которые понятны ему лично. Не "повысим эффективность", а "уменьшим количество извещений на ... штук в месяц" и т.д. Тогда даже "директор советского дуба" может увидеть конкретный понятный результат и разрешить пилот. Второй — через "случайную поддержку сверху". Если у такого директора есть свой начальник или собственник — иногда удавалось показывать им разрозненные данные, а они уже сами вытягивали изменения через директора. Это медленнее, но иногда единственный рабочий путь. Если оба пути не работают — честно говоря, в моей практике это обычно знак, что проект надо заканчивать. Можно делать его в стол, но рано или поздно директор всё равно остановит. Лучше потратить силы на что-то другое.
Вы конечно правильно пишете, надо наводить порядок до автоматизации, не надо автоматизировать хаос, надо искать узкие места и т.д.
Но есть тут и подмена понятий. В приводимых изначально примерах про автоматизацию ведь ничего не было. Внедрение ERP на производстве - это цифровизация. Кто-то куда-то записывает циферки. Теперь будет записывать в 1С. Дело не в хаосе и отсутствии регламентов, а в том, что из записи цифр ничего само по себе не автоматизируется. Пример из химпрома как раз про это, суть не в том, что цифры стали чаще записывать, суть в том, что регулировки стали чаще делать.
Автоматизация хаоса: почему IT‑проекты на производстве не дают результата, даже когда сданы в срок