Производственник, который пришёл в IT. О том, почему до кода надо идти в цех.
Несколько лет назад наблюдал проект на одном производственном предприятии. Небольшое производство, человек 200. До нашего проекта руководство уже наняло специалистов 1С и начало автоматизировать учёт движения сырья и управленческую отчётность по сменам. Кто‑то посоветовал — мол, пора двигаться к нормальному учёту.
Когда мы пришли с проектом по бережливому производству, начали с диагностики. Построили карту потока текущего состояния — и начало появляться ощущение, что рановато на предприятии взялись за учёт. Окончательно стало понятно, когда сделали целевое состояние и нарисовали информационные потоки: 30% операций — это передача данных между подразделениями. Сформировали план изменений вместе с командой предприятия.
Уже к концу внедрения дошло: эти 30% операций никуда не делись. Просто переехали из бумаги в 1С. Только теперь в красивом интерфейсе.
Заказчику пришлось переделывать и процесс, и автоматизацию. Деньги на 1С потратили дважды.
Это и есть автоматизация хаоса. И это самая частая ошибка, которую я вижу за 15 лет работы на производстве, в консалтинге и в IT‑проектах.
Мне попалось исследование Pendo 2019 года: 80% фич в среднем SaaS‑продукте используются редко или вообще никогда. По моему опыту — на проблемных проектах примерно так и происходит.
Почему так происходит? Мне кажется, команды прыгают с вопроса «Зачем?» сразу к «Как?», то есть вместо цели сразу к реализации, пропуская «Что?». Все выполняют ТЗ, которое описывает чьё‑то смутное видение решения, а не корневую проблему. Ну скажите, кто не сталкивался с тем, что представитель заказчика присылает ТЗ — и мы сразу идём делать оценку, описывать техническое задание. И мало кто задаётся вопросами: а какая в этом цель, какой будет конечный результат и как это поможет добиться цели заказчику.
Я вижу проблему чуть глубже. Даже такие мощные методы, как DDD и EventStorming, часто применяются не к тем проблемам. Они отлично моделируют процесс, но если сам процесс — это набор лишних операций, на выходе получится точная цифровая копия неэффективности.
Я вынес единственный рецепт, который реально работает: гарантировать окупаемость ИТ‑инвестиций можно, только начав с тщательного анализа бизнес‑процессов. Сначала нужно найти звено в цепочке создания ценности, автоматизация которого сэкономит больше всего денег, и лишь потом — обсуждать архитектуру.
В этой статье я попытался выделить трёхэтапную схему, которая сочетает ИТ‑разработку с принципами бережливого производства.
Шаг 1: Картирование потока. От стикеров — в цех
Первое правило: никаких стикеров и досок, BPMN‑диаграмм, пока вы не пройдёте весь процесс своими ногами. Нельзя поставить диагноз по фотографии.
Идите на завод, в офис, в место, где создаётся ценность. Встаньте, как Тайити Оно, и просто наблюдайте. Вы увидите не отчётные KPI, а реальность: стопки бумаг, очередь у кабинета, рукописные заметки на станке, один принтер на четыре этажа, фактическую производительность оборудования.
Затем — откровенно говорите со всеми:
С заказчиками — об их целях, бюджете и ожиданиях.
С руководителями — об их боли и метриках успеха.
С исполнителями (о них чаще всего забывают!) — о реальных сбоях и причинах проблем. Успех проекта зависит от их готовности к изменениям.
Ошибка № 1 — замкнуть общение на уровне руководства. Так рождается «идеальное» кабинетное решение, оторванное от реальности. Процесс, описанный в инструкции и технологической документации, часто не соответствует действительности. Со временем всё меняется, даже если когда‑то инструкцию писали с фактического состояния. Меняются сотрудники, ломается оборудование, меняется сырьё.
Ошибка № 2 — потерять доверие ещё до старта. Если о проекте знает лишь узкий круг, остальные воспримут команду как закрытую секту. Решение — публичный запуск при участии спонсора. Он должен лично объяснить: ЗАЧЕМ это нужно, КАК это затронет каждого и ПОЧЕМУ мнение каждого важно. Без общего понимания даже лучший продукт станет ещё одним препятствием, которое сотрудники станут обходить и саботировать.
Картирование: как найти реальное «узкое горло»
Когда диагноз поставлен и команда собрана, можно рисовать карту потока создания ценности. Ключевая ошибка здесь — поверхностный набросок на стикерах. Это бесполезно.
Как в книге Голдратта «Цель», нужно найти истинное ограничение, которое редко совпадает с озвученным мнением сотрудников. Чтобы его обнаружить, анализируйте каждый этап через призму четырёх вопросов:
Готовность — что мы имеем перед началом определённого этапа процесса, какие материалы, как и в каком виде приходит информация, кто участвует в согласовании.
Результат — что мы получаем на выходе с этапа процесса, какие появляются артефакты, как меняются данные, что является готовым продуктом для данного этапа, какую ценность данный этап приносит.
Рабочий поток — как именно идёт работа, какая последовательность, какие инструменты используются, как передаётся информация, в каком виде она передаётся, как двигается продукт/полуфабрикат между этапами, в каком виде происходят перемещения.
Метрики — как мы понимаем, что каждый этап работает хорошо или плохо, как мы отслеживаем и отслеживаем ли вообще время цикла на каждом этапе, учитываем ли время простоя на этапах и как это влияет на производительность и отклонения от плана. А какая периодичность отслеживания этих (и других) показателей процесса, как они влияют на основную цель процесса и компании в целом.
Когда видишь весь процесс целиком и с количественными показателями на каждом этапе, будь то передача информации, планирование действий, совершение операций, когда есть понимание пропускной способности нашего потока и немаловажно — потребности (а сколько должны), когда видишь, где есть проблемы, причём не всегда эти проблемы могут быть связаны с самим потоком, они могут быть, как бы банально это ни звучало, связаны с организацией работы в целом. Тогда и только тогда можно понять, где в процессе появилось «узкое горлышко», оно может быть не одно, их может быть несколько, и при каждом приседании, при каждом изменении процесса оно может мигрировать. Устраняя по очереди эти «узкие горлышки», в том числе с помощью автоматизации, можно добиться максимального влияния на результативность проекта.
Только после такой диагностики у вас появляется не список «хотелок», а подкреплённая данными гипотеза: «Автоматизация шага X (нынешнего ограничения) окажет на бизнес эффект Y». Это ведёт нас ко второму шагу.
Шаг 2: Проверить гипотезу — без единой строчки кода
Задача определена, потенциальный эффект переведён в рубли. Самое время собрать команду для проектирования системы?
Стоп. Это ловушка.
Ещё не время приступать к проектированию, из карты мы достаём только гипотезы, что то или иное воздействие может потенциально принести «добро». На этом этапе важно проверить и приоритизировать эти гипотезы и уже из них сформировать план к действию. И проверить как можно дешевле.
Сначала нужно найти самый дешёвый способ проверить гипотезу. Покажу на двух кейсах.
Пример 1. Человек вместо конвейера (мебельное производство).
Команда хотела поставить ещё один кромкооблицовочный станок и конвейер, который должен связать часть операций производственного процесса, за счёт этого планировали поднять производительность на 25%. Это небольшие инвестиции, но всё же. Прежде чем тратить деньги, мы провели пилот, в рамках которого несколько участников команды выполняли роль конвейера и таскали дверные полотна по маршруту будущего конвейера, а вторая часть команды производила замеры времени на каждом этапе. В результате пилота мы получили данные, которые помогли приоритизировать данную идею среди остальных и внедрить её. Окупаемость составила полгода.
Пример 2. Тестирование на бумаге (химическое производство).
Гипотеза: более частый анализ данных «план‑факт» увеличит выход продукции. Вместо покупки дорогой BI‑системы запустили пилот на бумажных формах с вводом данных каждые 4 часа. Выход продукции вырос на 10% за короткий срок. Дальше было проще обосновать автоматизацию.
Вот как сделали это мы. Мастер организовал отбор проб каждые 4 часа и записывал результаты в обычную форму на бумаге — концентрация, выход продукта, отклонения от плана. По отклонениям сразу принимали решение — не раз в сутки, как раньше, а каждые 4 часа. Это значит, что мастер мог влиять на процесс три раза за смену, а не один.
За месяц такого «пилота» стало понятно две вещи. Первая — частый замер действительно даёт мастеру возможность вовремя корректировать процесс. Вторая — какие именно поля нужны в финальной системе, а какие оказались лишними. Когда дошло до автоматизации, у IT‑команды было чёткое ТЗ, основанное не на догадках, а на месяце реальной работы.
Главный принцип: «провал» на этапе проверки гипотезы — это не поражение. Это самая выгодная инвестиция. Она в 100 раз дешевле, чем провал на этапе внедрения готовой, но бесполезной системы.
Эти примеры из производства, но логика та же для любого IT‑проекта. Хочешь автоматизировать обработку заявок — попробуй неделю обработать их вручную по новому процессу. Хочешь BI‑дашборды — месяц собирай данные в Excel вручную. Самый дешёвый способ проверить гипотезу — почти всегда не код, а человек или бумага.
Теперь у нас есть доказанная гипотеза, подтверждённая экспериментом и расчётами. Мы точно знаем, что автоматизируем и какой экономический эффект это даст.
Шаг 3: Внедрение. И только теперь — фреймворки и код
Теперь мы понимаем, что нужно делать и самое главное — зачем.
Архитектура. Все ограничения и особенности известны — мы прошли весь процесс ногами.
Процесс. Есть измеримая цель. Каждый спринт можно сверяться с тем, движемся ли мы к намеченному эффекту или просто закрываем задачи.
Приоритизация. Не нужно спорить, что делать первым. «Узкое горло» найдено, и его расширение даст максимальную отдачу.
Но даже на этом этапе можно всё провалить. Вот что важно держать в голове, чтобы не потерять то, что нашли на шагах 1 и 2:
Не отдавайте бэклог «в чистый IT». Аналитики и разработчики легко уходят в техническое совершенство и забывают, ради чего всё это. Держите в команде хотя бы одного человека, который был с вами в цеху и разговаривал с исполнителями. Он будет тем самым «стоп‑краном», когда команда начнёт автоматизировать не то.
Каждый спринт сверяйтесь с метриками из шага 1. Не с количеством закрытых задач, а с тем самым «узким горлом». Если за три спринта движение к цели не появилось — что‑то идёт не туда, и пора остановиться, а не «ещё немного».
Демо для заказчика делайте чаще, чем раз в месяц. В первую очередь для того, кто запускал проект. Он ваш «лучший друг» и «союзник», пока он видит, что вы двигаетесь к нужному результату.
Не отрывайтесь от людей в цеху. После запуска возвращайтесь и смотрите, как пользуются системой. Не «по отчётам», а вживую. Каждый раз, когда я возвращался в цех через месяц после запуска, я видел минимум 2–3 вещи, которые работают не так, как планировалось. И только тогда система действительно начинает работать.
И главное — «союзник» внутри команды заказчика. Тот, кто участвовал в проверке гипотез, видел, как было до и как стало после. С таким «союзником» больше вероятность довести проект до конца, минуя бесконечные правки.
Это сложнее, чем взять ТЗ и сделать по нему. Нужно идти в цех, наблюдать, разговаривать. Но это единственный способ работать так, чтобы за тобой возвращались, а проекты окупались.
ссылка на оригинал статьи https://habr.com/ru/articles/1045472/