В последние годы вызовы, с которыми сталкивается реальный бизнес, все менее и менее прогнозируемы. Сложившаяся ситуация требует от бизнеса и ИТ-подразделений более быстрой реакции на постоянные изменения. Как справиться с таким положением вещей и как ИТ-отделам успевать обрабатывать все запросы извне?
Помимо внешних вызовов, в общую копилку свою лепту вносит общая экосистема, внутри которой все крупные и средние игроки пытаются прогнозировать будущее, стараются выжить, продолжать свое развитие и выстраивание собственных, внутренних экосистем.
Как ИТ отвечать на эти вызовы?
Основным базисом, на который мы опираемся при реализации стратегии в отношении технологических департаментов, является задача по формированию микрокоманд. Эта идея далеко не нова, а суть ее в том, что конечное решение по тому или иному вопросу может приниматься внутри самих микрокоманд, а не после того, как по цепочке проблема дойдет до высших звеньев в иерархии предприятия. Децентрализация принятия решений приводит к тому, что микрокоманда имеет полное право и соответствующие полномочия для принятия финальных решений и сама несет за них ответственность. И это задача номер один для ИТ-подразделений XXI века.
У этой концепции есть очевидные преимущества:
Любые проблемы решаются гораздо быстрее, а не застревают в «узком горлышке» принятия решений на уровне топов.
Микрокоманды могут выпускать мини-релизы независимо друг от друга, то есть работа над большим декомпозированным ИТ-продуктом может вестись параллельно, а не последовательно, что значительно ускоряет процесс.
Право принимать решения позволяет микрокомандам проводить постоянные эксперименты внутри себя, а это значит, они получают возможность находить оптимальные решения для развития и поддержания ИТ-продуктов.
При этом микрокоманды могут и должны быть взаимозаменяемы: если одна выходит из строя, остальные от нее не зависят и продолжают работать, а на замену микрокоманды потребуется в разы меньше времени, чем на замену большой команде.
Вторая задача — это формирование корпоративной ИТ-архитектуры, которая позволяет компании максимально гибко и оперативно встраивать новые сервисы и успешно решать новые задачи вне зависимости от степени турбулентности рынка в целом. В связи с этим максимально эффективной себя показала так называемая микросервисная архитектура, в которой оркестрация взаимодействия между системами, находящимися в ИТ-ландшафте той или иной компании, осуществляется на базе API. Взаимодействие между микрокомандами, продуктовыми командами и любыми другими командами уже происходит на уровне соблюдения API-контрактов. Кроме того, API-центричная архитектура — это решение любой продуктовой проблемы.
Возникает вопрос, как внедряются различные продукты в такую архитектуру? Благодаря тому, что конечная имплементация на каждой API-точке может быть заменена в любой момент времени, компания имеет возможность использовать продукты сегодня одного производителя программного обеспечения, а завтра другого, послезавтра третьего и так далее. Потому что API-центричная архитектура подразумевает, что API-контракт неизменен, а вот имплементация за ним может меняться. Так и выстраивается определенный API-фасад, в котором все оперативно можно поменять без ущерба существующим процессам и окружению.
В то же время технологический радар должен формироваться, исходя из того, какой будет ситуация через 3–7 лет. Состояние турбулентности в котором пребывает энтерпрайз сейчас, за это время никуда не исчезнет. Следовательно, любая архитектура должна быть выстроена так, чтобы все возможные изменения внутри нее можно было внедрять, не создавая помех работе остального окружения. Это, пожалуй, самый важный момент.
Show must go on
Все было бы очень легко, если бы не было так сложно. Потому что на этапе внедрения чего бы то ни было нового – технологий, методик, практик, любого программного обеспечения топ-менеджмент всегда сталкивается с одной и той же ситуацией: изменение чего-то одного часто влечет за собой целую лавину перестроек в бизнес-процессах. А это почти всегда требует серьезных вложений, человеческих ресурсов и, конечно, времени.
Кроме того, show must go on. Нельзя остановить развитие и реализацию бизнеса на время перестройки. Нельзя все сломать и начать строить заново. Нужно внедрять изменения таким образом, чтобы бизнес продолжал работать. Поэтому менять существующий ИТ-ландшафт под новую реальность нужно плавно и незаметно для внешнего мира, чтобы производство не встало, логистика не сломалась, а магазины продолжали в достаточном количестве обеспечивать население необходимыми товарами. Только такие плавные изменения позволят грамотно распределить имеющиеся ресурсы и, если что-то вдруг пойдет не так, всегда останется возможность «откатить» последние изменения до базовых настроек.
Идеология и ментальность
Стоит также отметить, что даже плавный переход на новую API-центричную архитектуру — это процесс глобальной цифровой трансформации для любой компании. Но чтобы достичь этой цели, она должна быть готова к такому шагу с точки зрения внутренней идеологии и общей ментальности сотрудников.
Если же, например, обмен данными внутри осуществляется посредством традиционных таблиц, то компания не готова к таким кардинальным изменениям. Если компания предполагает, что для решения вопросов на уровне применения той или иной системы требуется согласование вплоть до ИТ-директора или генерального, то она опять же не готова к этому.
На самом деле ситуация очень проста: у нас есть все предпосылки для изменения бизнес-процессов, для их цифровизации. Вспомните, в разгар пандемии и всеобщего карантина у бизнеса был один набор задач: логистика, доставка, бесконтактная оплата. Теперь этот набор трансформировался, но не остановился. Изменения будут происходить и дальше, а бизнесу придется регулярно адаптироваться к чему-то новому. Так что эффективно ответить на надвигающиеся вызовы, о которых мы, возможно, пока еще даже не подозреваем, можно только тогда, когда процессы будут управляемы. Это так называемый управляемый хаос-тренд, который зародился не сегодня, а несколько лет назад и который со всей ответственностью можно назвать долгосрочным.
Отсюда и возникает набор стратегических и тактических задач как для ИТ департаментов, так и для самого бизнеса:
создание микрокоманд, попутно не разрушая, а улучшая первичные паттерны, и не затрагивая core-системы;
выстраивание API-центричной архитектуры;
применение лучших DevOps-практик;
создание системы, которой свойственен управляемый хаос до той степени, когда API-контракты можно спокойно заменять друг на друга, а имплементация на API-точках будет постоянной.
И, пожалуй, еще одна важная задача для бизнеса — это более оперативное улучшение навыков и развитие компетенций своих сотрудников. Причем делать это нужно максимально быстро.