Пять главных изменений в области ИТ для полномасштабного внедрения Agile

| Статья

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

В последние пять лет многие компании из разных отраслей начали экспериментировать, пробуя внедрять принципы Agile и стараясь почувствовать преимущества адаптивности. Некоторые из них – банки, операторы связи, ритейлеры и другие компании – даже делают попытки внедрить систему Agile в масштабе всей организации: они создают гибкие организационные модели, которые непрерывно видоизменяются, что позволяет быстро использовать возможности, возникающие на рынке. При этом особое внимание уделяется активной вовлеченности персонала в эти процессы. Преимущества такого подхода очевидны: результаты исследования, проведенного McKinsey, показывают, что, компании, которые освоили принципы организационной адаптивности, могут повысить финансовый результат на 20–30%. Такое повышение общей эффективности обусловлено ростом эффективности операционной деятельности на 30–50%, увеличением показателя удовлетворенности клиентов на 10–30 баллов, а индекса вовлеченности сотрудников – на 20–30 баллов. В сочетании с имеющимся у традиционных компаний опытом и наработанной клиентской базой эта более высокая эффективность, в свою очередь, помогает им преодолеть отставание от цифровых игроков, меняющих рынок, и успешно с ними конкурировать.

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

Пять изменений в области ИТ для обеспечения адаптивности компании

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

рисунок 1

Изменение 1
Совместная работа: от изолированного ИТ-подразделения к кросс-функциональным agile-командам

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

Чтобы разрешить проблему взаимодействия ИТ и бизнеса, нужно изменить модель их сотрудничества: вместо изолированного ИТ-подразделения создать смешанные кросс-функциональные команды из специалистов – представителей бизнеса и ИТ. В таких командах сводится к минимуму количество передач из рук в руки заданий, решений и доработок, поэтому данная модель исключительно важна для ускорения разработки продуктов, вывода их на рынок и интеграции обратной связи. Ее основу составляют так называемые команды BizDevOps (business, development, operations – «бизнес, разработка, эксплуатация»). В каждой команде от пяти до девяти сотрудников, обладающих всем необходимым для достижения цели – компетенциями в сфере бизнеса, разработки и тестирования, а также обеспечения надежности при практическом использовании решения (рис. 2). Со стороны бизнеса в состав команд входят владельцы продуктов, специалисты по продуктам и специалисты по клиентскому опыту, которые определяют потребности в продуктах с учетом пожеланий клиентов и рентабельности инвестиций. Ежедневная работа инженеров заключается в создании готового к использованию ПО, а также автоматизации процессов для обеспечения надежности как релизов, так и работы ПО при эксплуатации. Благодаря постоянному взаимодействию членов команды на согласование требований уходят не месяцы, а всего лишь дни или даже часы. Это радикально сокращает сроки вывода продуктов на рынок и снижает количество бюрократических препятствий в работе.

рисунок 2

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

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

Изменение 2
Приложения и сервисы: от монолитных корневых ИТ-систем к независимым приложениям и сервисам с отдельными API1, за которые отвечают трайбы

Массивные, монолитные, многофункциональные ИТ-системы – пережиток прошлого. Современные ИТ-системы должны быть в достаточной степени фрагментированными, чтобы их части можно было постоянно совершенствовать независимо друг от друга. Раньше многие корневые системы, такие как автоматизированные системы в банках (АБС) и системы поддержки бизнеса (BSS) в телекоммуникационных компаниях, объединяли в себе множество функциональных возможностей в рамках одного приложения или нескольких связанных между собой монолитных приложений с запутанной системой взаимосвязей. Хотя такая структура имеет некоторые преимущества с точки зрения масштаба и скорости вычислений, но после изменения хотя бы одной функции, как правило, приходится проводить регрессионное тестирование всего функционала, чтобы убедиться, что в системе не возникло сбоев. Кроме того, многие системы, созданные в 1990-х и 2000-х гг., оптимизированы для работы в традиционных розничных каналах или даже для выполнения функций бэк-офиса. При этом в них не было предусмотрено функционала, который сделал бы их совместимыми с мобильными устройствами, платформами онлайн-магазинов, API партнеров и другими цифровыми каналами, которые с тех пор успели появиться и стать сложнее. Например, в одном банке при изменении тарифа или создании нового продукта приходилось корректировать до 30 систем. Разработкой параллельно занимались несколько подразделений, а на регрессионное тестирование для выявления ошибок уходили недели.

Замена таких корневых систем всегда была сопряжена со значительными затратами: на программу модернизации продолжительностью не в один год может уйти от 50 до 500 млн евро и более. Но такой план действий вовсе не обязательно будет лучшим вариантом для всех компаний.

В качестве альтернативы, стремясь обеспечить превосходный клиентский опыт и при этом разумно потратить средства, некоторые agile-компании начали использовать подход, предполагающий «выдавливание» старых систем новыми по частям, – Strangler pattern. Выбирают функции, которые меняются наиболее часто (например, процесс инициирования и одобрения кредитов, каталоги продуктов или тарифные модули, механизмы расчета рейтинга, модели данных или процессы взаимодействия с клиентами), назначают ответственными за них бизнес-трайбы или трайбы по работе с платформами и формируют выделенные команды BizDevOps для создания конкретных специализированных сервисов (так называемых микросервисов). В их основе лежит принцип «один сервис – одна функция»; с помощью таких сервисов из устаревших систем «вытягиваются» функции, которые не относятся к базовым, и в результате старое ядро постепенно теряет в весе (рис. 3). Подобный подход сокращает сроки разработки и корректировки функций, снижая при этом общую стоимость владения.

рисунок 3

Возможности такого подхода можно проиллюстрировать на примере двух банков. При том что базовые функции банковской системы (такие как ведение главной книги) должны были остаться – и в дальнейшем останутся – в ее ядре, один из этих банков смог облегчить монолитные корневые системы примерно на 35%. Он выделил вспомогательные функции в микросервисы или специализированные приложения (например, механизм определения ставок или сервис для взыскания задолженности), благодаря чему появилась возможность часто вносить изменения в не зависящие друг от друга микросервисы или модули. Другой банк применил этот подход избирательно – к ограниченному ряду процессов, таких как установление отношений с новыми клиентами и перекрестные продажи. Часто меняющиеся функции, необходимые для их поддержки, были выделены из старых систем в независимые микросервисы. В результате банку удалось сократить срок внедрения новых опций в рамках этих функций с нескольких месяцев до нескольких часов.

Изменение 3
Поиск ресурсов и подбор персонала: от аутсорсинга ИТ-услуг к балансу между стратегическим наймом ИТ-специалистов и привлечением партнеров и поставщиков

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

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

Чтобы удовлетворить свои потребности в квалифицированных специалистах, один европейский банк полностью реорганизовал штат подразделения ИТ, определив, какие инженеры на самом деле занимались написанием кода, и увеличив их долю приблизительно с 10 до 80%. Кроме того, для всех инженеров была разработана пятибалльная шкала уровня навыков (от начинающего специалиста до эксперта), и особое внимание было уделено формированию структуры персонала на основе схемы, имеющей форму ромба. При такой структуре увеличивается доля ИТ-специалистов уровня экспертов или высококвалифицированных инженеров (центральная часть ромба), которые многократно производительнее менее опытных специалистов, но при этом обходятся компании не во столько же раз дороже. В результате штат ИТ-специалистов, эквивалентный примерно двум тысячам полных штатных единиц, был кардинально обновлен: доля опытных инженеров теперь достигла 80%, а затраты сократились на 40%. Мы знаем международную телекоммуникационная компанию, которая сформировала кадровый ресурс из нескольких сотен инженеров – в основном за счет включения специалистов в штат, но также заключая B2B-договоры с независимыми инженерами и даже с компаниями-поставщиками на основе затрат их времени и материальных ресурсов. Еще пример: международный банк создал собственный штат инженеров из нескольких тысяч специалистов. Чтобы привлечь молодых и ценных сотрудников, он совместно с провайдерами облачных технологий и другими поставщиками сформировал кадровую экосистему и запустил программы переподготовки для повышения квалификации более чем шести тысяч разработчиков и ИТ-архитекторов.

Поставщики, в свою очередь, также адаптируются к меняющимся условиям и ищут новые форматы сотрудничества. С одной стороны, они предлагают ПО как услугу (SaaS) и платформы как услугу (PaaS) с более простым доступом через API – определенные функции, реализованные под ключ и полностью готовые к использованию. С другой стороны, по запросу, например в рамках стратегического партнерства, они могут предоставить опытных специалистов узкого профиля – в противовес стандартным пакетным предложениям, включающим и начинающих специалистов.

Изменение 4
Поставка ПО: от водопадного процесса к постоянному развитию (CI/CD)

Скорость поставки ПО – предмет постоянных обсуждений между генеральными директорами и директорами по ИТ. Генеральные директора часто сетуют на то, сколько времени в традиционной организации занимает прохождение всех этапов поставки при «водопадном» процессе. Директора же по ИТ предупреждают, что ускорение может стать причиной сбоев в работе ПО. Среднестатистическая компания способна проводить масштабное обновление функционала три-четыре раза в год; более быстрым удается ежегодно выпускать 10–12 релизов. Игроки же цифрового поколения, такие как Amazon, Google и большинство цифровых стартапов, могут выпускать обновления по мере необходимости буквально в любой момент – каждую неделю, день, каждый час. Это позволяет им проводить A/B-тестирование различных версий одного и того же функционала с разными клиентами, тестировать минимально жизнеспособные продукты в любое время, быстро вносить корректировки с учетом обратной связи от пользователей, а также постоянно совершенствовать бизнес, достигая поистине высокого уровня организационной адаптивности. Ряд европейских и азиатских традиционных банков и телекоммуникационных компаний последовали их примеру и смогли увеличить количество релизов (в том числе в рамках бэкенд-систем) до 20 тысяч за квартал.

Ради ускорения процесса поставки вовсе не обязательно жертвовать качеством. Привлечение компетентных инженеров и работа с автономными микросервисами – ключевые факторы, которые позволяют реализовать весь потенциал непрерывной интеграции и непрерывной поставки (CI/CD). Провести это преобразование можно за счет автоматизации задач, которая обеспечит возможность частых инкрементальных релизов (рис. 4). Автоматизируются все этапы поставки сервиса – от написания кода до тестирования и развертывания, включая тестирование безопасности в рамках непрерывных конвейеров DevOps с продуктами в разной степени готовности (этот подход обычно называют DevSecOps, то есть development, security, operations – «разработка, безопасность, эксплуатация»). Один прогрессивный международный банк пошел дальше и создал для разработчиков внутреннюю платформу как услугу. С помощью одного нажатия кнопки каждый из разработчиков может получить доступ к шаблонам сервисов через глобальный портал; им также автоматически доступны необходимая инфраструктура, конвейеры CI/CD, инструменты безопасности и определения API. Это решение позволило разработчикам сосредоточиться на написании кода для создания функций, актуальных для бизнеса, вместо того чтобы тратить время на настройку конвейеров и инфраструктуры.

рисунок 4

Разумеется, не все системы находятся на стадии полной готовности с первого дня работы, поэтому некоторым компаниям необходимо применять дифференцированный подход: для тех систем, которые готовы к подключению API, обеспечить возможность осуществления релизов в любой момент, а для других, требующих проведения регрессионного тестирования, внедрить конвейеры релизов, параллельно вкладывая средства в автоматизацию. За автоматизацию и ускорение процесса поставки ПО обычно отвечают специальные подразделения по работе с платформой поставки как услугой. Настраивая инструменты, например конвейеры CI/CD, и поддерживая их работу, они оказывают содействие всем трайбам организации («командам команд») во внедрении новых методов разработки.

Изменение 5
Инфраструктура: от физической инфраструктуры к облачным решениям и инфраструктуре как коду

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

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

Опыт показывает, что в сочетании с методами непрерывной интеграции или поставки (CI/CD) облачная инфраструктура позволяет принципиально улучшить несколько ключевых показателей в области ИТ – в основном за счет того, что не приходится тратить время на ожидание и доработки, а также благодаря возможности прогнозировать потребности. Например, в результате автоматизации и внедрения стандартизованных процессов компаниям удается уменьшить продолжительность цикла поставки, а также ускорить развертывание и тестирование ПО. Некоторые команды, которые раньше на регрессионное тестирование тратили два дня спринта, теперь могут решать те же задачи всего за два часа. У компаний есть возможность не только повысить производительность, но и значительно сократить накладные расходы на ИТ благодаря оптимизации использования ИТ-активов и более гибкому подходу к ИТ в целом для удовлетворения потребностей бизнеса. Сегодня провайдеры облачных услуг все активнее предлагают гораздо более сложные решения, чем базовые технологии вычислений и хранения информации, – такие как сервисы на основе больших данных и машинного обучения. Кроме того, практика показала, что использование облачной инфраструктуры и методов непрерывной интеграции или поставки ПО позволяет сократить сроки вывода продуктов на рынок и повысить качество сервисов благодаря способности стандартных решений к «самовосстановлению»: например, если объем базы данных приближается к критическому, для хранения информации автоматически выделяются дополнительные мощности3.


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

Explore a career with us