Обновить

Автоматизация хаоса: почему IT‑проекты на производстве не дают результата, даже когда сданы в срок

Уровень сложностиСредний
Время на прочтение8 мин
Охват и читатели6.5K
Всего голосов 4: ↑4 и ↓0+8
Комментарии8

Комментарии 8

почему IT‑проекты на производстве не дают результата

Потому что техник/мастер/кладовщик не то занес, не туда занес, забыл/забил занести; вместо суммы указал количество, серийные номера поставил в комментарий... и вообще - не нужна мне ваша автоматизация, я без нее тут 20 лет работаю и всё нормально! :(

Недавно приобщился к промышленности - тут как раз наоборот люди страдают от бумажек, от 5 версий экселевского документа с разными данными в каждом подразделении. "без нее тут 20 лет работаю и всё нормально!" сейчас кажется сложно встретить, большинство успели поработать с хоть как то рабочими системами...

Это та самая боль, про которую я и пишу. Сначала надо разобраться в корневых причинах, почему так происходит, и только потом автоматизировать. Если кладовщик 20 лет работает без системы и считает, что "всё нормально" — значит, у него работают какие-то компенсаторные механизмы. Память, блокнот, "так исторически сложилось". Эти механизмы для него — работающий процесс. Сломать его внедрением какой-либо новой кнопки не получится.

В таких случаях у меня работало две вещи:
1. Идти не с автоматизацией, а с разговором "где у тебя сейчас больше всего боли". Реальные ответы в основном получал не на рабочем месте, а в курилке или в перерыве. Там же выясняется, что "всё нормально" на самом деле "я три раза в день пересчитываю вручную и матерюсь, но привык".
2. Включать спонсора проекта в коммуникацию с этими людьми лично. Не отдавать им новую систему сверху, а позвать в разработку требований — как ему удобнее.

Тогда из саботажника человек превращается в соавтора. Без этой работы любая автоматизация — это та самая красивая цифровая копия хаоса.

Статья в точку, всё так и есть!

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

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

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

Это самая тяжёлая ситуация, согласен. Когда спонсор проекта/лицо принимающее решения — сам же главный блокер изменений. Из опыта: в таких случаях обычно работают два пути. Первый — через метрики, которые понятны ему лично. Не "повысим эффективность", а "уменьшим количество извещений на ... штук в месяц" и т.д. Тогда даже "директор советского дуба" может увидеть конкретный понятный результат и разрешить пилот. Второй — через "случайную поддержку сверху". Если у такого директора есть свой начальник или собственник — иногда удавалось показывать им разрозненные данные, а они уже сами вытягивали изменения через директора. Это медленнее, но иногда единственный рабочий путь. Если оба пути не работают — честно говоря, в моей практике это обычно знак, что проект надо заканчивать. Можно делать его в стол, но рано или поздно директор всё равно остановит. Лучше потратить силы на что-то другое.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации