Про необходимость digital-трансформации любой поисковик вам выдаст сотни тысяч статей, на разные лады повторяющих лозунг о том, что «выживает тот, кто быстро приспосабливается к изменениям». Далеко не в каждой из них можно найти хотя бы общие цели, к которым ведёт этот трудный и тернистый путь. Цели эти всегда сулят невероятное будущее и трудноуловимый успех, в случае достижения. Иногда приводится общий набор ограничений готовности бизнеса к трансформации, которые сложно, но, несомненно, преодолимы, особенно если привлечь необходимых экспертов. Доказательства сопровождаются кейсами из жизни мировых лидеров индустрии или стартапов-единорогов, отчётливо попахивающих «ошибкой выжившего».

Гораздо сложнее найти ответ, который раскроет, как работает эта магия? Как именно digital-трансформация позволяет получить явные и осязаемые результаты, выражающиеся в прибылях и KPI?

Тут существует несколько уровней проблематизации, со своими специфическими сложностями. Разобрать их все в рамках одной статьи не получиться, придётся есть этого слона по кусочку. Сегодняшняя тема о проблемах и ошибках верхнего уровня управления является первой в серии под общим заголовком «Особенности национальной ИТ-трансформации». А дальше мы будем двигаться по контурам организационной структуры от топ-менеджмента до непосредственно команд разработки, разбирая ожидания и решения, которые даёт переход к гибким практикам управления.

Никогда не было и вот опять!

Тот факт, что изменения для бизнеса важны, нужны и полезны сомнений не вызывает. У компании может быть стабильный продукт, который давно и успешно живёт на рынке и радует потребителей. Однако, рынок крайне переменчив, а запросы потребителей неизменно повышаются. Это относится и к качеству, и к функциональности продукта, который поставляет компания.

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

Адекватный бизнес всегда так или иначе существует в поле изменений. Бизнес-модели и бизнес-процессы тщательно отстраиваются с учётом динамики рынка и факторов внешней среды. Бизнес живёт в той самой парадигме гибкости и адаптации без всякой digital-трансформации. И действительно недоумевает, зачем ему навязывают необходимость радикальной перестройки бизнес-моделей и управляющих структур по довольно-таки мутным мотивам.

Какие проблемы позволяет решить digital-трансформация?

Давление конкурентного рынка, возрастающие требования к качеству продукта, развитие технологий, изменение среды коммуникации, да и чего уж греха таить – весь тот хайп, который развели вокруг темы digital-трансформации, создают благоприятную среду для того, чтобы бизнес задумался о новых формах развития. Но вслед за этим возникают разумные сомнений в том, что серьёзная трансформация принесёт благо, а не крах всей с таким трудом отстроенной системы.

С другой стороны, в России среда, в которой развивается бизнес, сама по себе является довольно агрессивной. Количество требований, ограничений, согласований и прессинг со стороны государственной управляющей системы огромные. К тому же правила игры постоянно меняются, причём не в пользу облегчения и послаблений для бизнеса.
Поэтому у компаний любого масштаба есть острая необходимость знать свой бизнес лучше, чем надзорные органы, и быть готовым к любым вмешательствам.

Цифровая трансформация предлагает преодоление этих проблем за счёт оптимизации управления корпоративными данными. В этом контексте выделяется несколько направлений:

• Продвинутая аналитика на основе больших данных;
• Цифровизация процессов, которая позволяет обеспечить их прозрачность и гибкость благодаря автоматизации, мобильности и удалённому доступу к ресурсам компании;
• Новые технологии индустрии 4.0, такие как Интернет вещей, искусственный интеллект, блокчейн, дополненная реальность, дроны, автономные роботы и много другого прекрасного и интригующего.

Что потребует изменений?

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

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

Существенная особенность разработки ИТ-решений заключается в том, что она представляет собой разновидность интеллектуальной деятельности, результатом которой является поставка нематериального продукта. Платить за специфическое ничего бизнесу всегда больно. Но за долгие годы взаимовыгодного сотрудничества бизнес и ИТ формируют определённый «пакт о ненападении». Бизнес смиряется с тем, что эффективность интеллектуальной деятельности сложно измерима и трудно поддаётся оценке; разработчики смиряются с тем балансом требований и ресурсов, которые предоставляет бизнес. Сложившаяся система функционирует более или менее стабильно и результативно.

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

За что платит бизнес?

А вот тут часто начинается магия и миссионерство. Как хорошо сказал один мой знакомый ИТ-директор, ритуал – это действие, механизма которого человек не понимает, но считает, что его выполнение позволит ему достичь запланированного результата.

Жить в волшебном мире очень просто – достаточно не учить физику и математику, и все происходящие исполнится глубокого смысла, но начисто утратит возможность контроля и предсказуемого развития.

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

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

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

Чего хочет бизнес?

Чаще всего понимание необходимости изменений, обусловленных давлением внешних факторов, первым приходит к руководителям высшего звена. А дальше типичное развитие ситуации имеет вид, когда перед ИТ-директорами ставится задача примерно в такой формулировке: «Сделайте так, чтобы очень-очень быстро разрабатывалось много софта такого качества, которым пользователи будут довольны».

Задача, сформулированная, мягко говоря, не по SMART. И никаких вменяемых критериев измерения успеха.

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

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

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

Когда говорят про Agile и сопутствующие практики, основное, что слышит бизнес – ему обещают быструю поставку функциональности и фокусировку на потребностях заказчика. Agile воспринимается как инструмент, который заставит разработчиков придерживаться постоянной упорядоченной работы на результат. Это попадает в болевую точку и вызывает желание применить на практике.

В чем бизнес может ошибаться? 

И вот тут очень часто начинается «Agile по-русски», когда команды разработки и бизнес-пользователи не то, что не сотрудничают, а вообще не контактируют друг с другом. Внутренние заказчики совершенно не горят желанием принимать участие в процессе создания ИТ-решений: тестировать не будем, логику проверять не будем, документация не нужна – у нас же Agile! Но если что-то пойдёт не так, виноваты, конечно же, разработчики, не удержавшие фокус на требованиях. О приоритизация тоже нет представлений: вот вам бэклог из пары тысяч задач, делайте уже что-нибудь, там все нужное, зря что ли умные люди их формулировали.

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

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

Какие бизнес-идеи должны идти в работу?

Реализация конкретной бизнес-идеи должна приносить измеримую отдачу. Если невозможно оценить, какую пользу доставит решение той или иной задачи, велика вероятность того, что многие из них будут просто «греть воздух в компьютерах разработчиков», создавать видимость производимой работы.

Исследуя и оценивая пользу от реализации бизнес-идеи, мы проверяем ее качество и необходимость принятия в работу. Ожидаемая выгода обязательно сопоставляется с теми затратами, которые повлечёт проработка задачи. ИТ-специалисты стоят немалых денег и должны окупаться. Поддержка адекватного функционирования ИТ-сектора обходится бизнесу дорого, но без неё он существовать не может. Значит, не надо размениваться на ненужную работу, не доставляющую ценности.

Казалось бы, это очевидные вещи, диктуемые здравым смыслом. Однако в реальности контроль за развитием информационных систем у многих компаний осуществляется никак. Есть упование на компетенции функциональных архитекторов и непосредственных заказчиков каждого решения. Но архитекторы склонны увлекаться творчеством и созданием избыточной функциональности в силу своего художественного видения. А заказчики, наоборот, не склонны думать о системе в целом, и просто накидывают изменения по мере текущей потребности.

Как выбор бизнес-задач влияет на процесс разработки?

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

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

Разработчики работают медленно? Делают не то, что нужно? А у них есть выбор?

Как решают эту проблему гибкие практики и продуктовый подход?

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

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

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

Например, Scaled Agile Framework (SAFe) – это фреймворк для организационного управления, при котором требуется координация работы на масштабе информационных систем, обслуживающихся пятью или более командами. Он позволяет реализовать определённые менеджерские функции, которые отсутствуют на уровне управления гибкой командой разработки, а также управляющие функции бизнес-архитекторов. Или Large Scale Scrum (LeSS) – фреймворк, который позволяет достичь масштабирования Scrum-команд, сохраняя и развивая общее понимание бизнес-целей и функционального развития продукта в целом, а не отдельного кусочка, принадлежащего конкретной команде разработки.

Как определяется готовность бизнеса к изменениям?

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

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

Только преодолев этот стартовый барьер, можно будет говорить о работе с практическими ожиданиями бизнеса от ИТ-трансформации, такими как ускорение поставки, повышение качества, изменение границ бизнеса, получение новых источников дохода, достижение баланса в разработке и улучшение процессов. При этом, конечно, возникают свои проблемы нового уровня, о которых речь пойдёт в следующих публикациях из серии «Особенности национальной ИТ-трансформации».

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление изменениями и конфигурациями в ИТ

Повысить долю успешных изменений, снизить риски, знать всё про конфигурации