Agile давно покинул пределы стартапов, где он чувствовал себя относительно органично, и проник в индустриальные компании. Иногда — вместе с презентациями, где слово “value” употребляется 17 раз за слайд. И всё бы ничего, но agile в промышленности часто приживается хуже, чем чужеродный орган без иммуносупрессии.
Тем временем, по другую сторону сцены, стоит Enterprise Digital Twin — попытка отразить компанию как систему. Большую, инертную, многоуровневую. И вот вы застряли между двумя реальностями: с одной стороны — дикие спринты, с другой — необходимость стратегического контроля над трансформацией. Что с этим делать?
Цифровая трансформация без модных слов
Цифровая трансформация — это не “внедрение чего-то цифрового”. Это — структурная перестройка предприятия через изменение того, как управляются, измеряются и взаимодействуют между собой процессы, данные, решения и люди. Никакой мистики.
Компания до трансформации — это треугольник: уровни управления, функционалы, потоки.
Представьте себе свою компанию в виде треугольника: уровни бизнес, функции, операции.
До трансформации - пусто внутри. После трансформации - закрашенный. Не сразу. Не полностью. Но последовательно, от стратегических задач до цифровых следов в каждой зоне ответственности.
Вот модель: вы раскрашиваете пирамиду. Главное не начинать там, где проще, а двигаться сверху вниз. Стратегия → цели → процессы → данные → ИТ-системы.
Почему agile-команды не спасают трансформацию (но могут её добить)
Agile-команды без стратегической рамки превращаются в управляемую энтропию. Они заняты, у них “velocity”, у них demo. Только вот через полгода никто не может объяснить, зачем всё это, кроме “сделали backlog меньше”.
Это не проблема Agile. Это проблема того, что пирамиду решили закрашивать методом точечной росписи. Сегодня — MES на производстве. Завтра — PLM в инжиниринг. Послезавтра — что-то в электронных таблицах, “чтобы интегрировать быстрее. Скрипт то я мигом напишу”.
В итоге у вас есть «цифровой» участок, который получает данные от соседнего департамента через электронную почту, в теле письма.
Как должно быть: декомпозиция сверху вниз, поток за потоком
Цифровая трансформация начинается, когда генеральный директор или операционный директор ставит четкую стратегическую цель. Например: «сократить цикл вывода продукта на рынок».
Далее: разбить по слоям. Где узкое место? Валидация? Конфигурация? Поставщики?
Затем: какие потоки данных отсутствуют? Где нет прозрачности? Где решение принимается интуитивно, потому что данных нет?
Только после этого: какие технологии имеют смысл? Какие команды должны это реализовать? Где начинаются и заканчиваются их зоны ответственности? Кто и как принимает результат?
Даже создавая компанию с чистого листа, определите для себя минимально жизнеспособный объем процессов PLM — так вы сможете осмысленно планировать его развитие и отслеживать прогресс.
Сквады нужны. Но не все подряд и не везде
Каждая команда (agile-сквад) должна работать в рамках конкретного потока, с чётко определённой точкой входа и выхода. Причём “выход” — это не “мы выложили в Confluence”, а “соседняя команда приняла результат и встроила его в свой процесс”.
Если этого не происходит, вы не трансформируетесь. Вы просто размазываете активность по организации, называя это цифровизацией. Заставьте команды работать вместе, чтобы развернуть выработанный стратегический поток сверху вниз в нужных вам рамках.
У вас нет десяти итераций. У вас есть три. Максимум.
Вы не компания-разработчик программного обеспечения, которая может выкатить бета-версию, собрать обратную связь, и «допилить». Вы не можете выпустить бета-версию самолета и залатать ее на следующей неделе. Вы строите самолеты, корабли или атомные электростанции. Все должно работать.
Допуск на ошибку — минимальный. Количество итераций конечно. Результаты должны интегрироваться. Команды должны быть синхронизированы — не через Slack, а через архитектуру.
Хотите управлять трансформацией? Просите пирамиду
Если вы генеральный директор — попросите команду показать вам пирамиду трансформации. Визуально. Какие потоки уже охвачены? Где у вас есть живые данные (затраты, проблемы, статусы)? Где голуби все еще несут бумажные поручения?
Пирамида должна быть понятной. Иначе трансформация — это PowerPoint с KPI, которых никто не считает.
Цифровая трансформация — это не культ. Это проектирование с намерением. Инженерия смысла.
И если вы хотите, чтобы agile действительно стал частью этого процесса — научитесь ставить цель, дробить её на потоки и измерять прогресс не по тикетам, а по решённым ограничениям.
И если вы хотите, чтобы Agile действительно стал частью этого процесса — научитесь ставить цели, разбивать их на потоки и измерять прогресс не по количеству тикетов, а по устраненным ограничениям.
От Протех. Автор материала — Антон Семянин, старший бизнес-консультант Dassault Systèmes. На практике реализует проекты цифровой трансформации, включая работу с Jaguar Land Rover.
Хотите узнать больше или задать вопросы Антону — например, об управлении качеством в автопроме? Задавайте вопросы в нашей группе в Телеграм.
Хотите узнать больше или задать вопросы Антону — например, об управлении качеством в автопроме? Задавайте вопросы в нашей группе в Телеграм.
