В течение последних 20 лет цифровые компании активно развивались. Это заставило традиционных игроков во всех отраслях кардинально пересмотреть операционные модели, для того чтобы повысить скорость работы, улучшить клиентский опыт и гибко реагировать на изменения. Существующие процессы и технологии мешают им адаптировать свои предложения и вести обслуживание в цифровом формате. А новые цифровые игроки способны быстро предлагать сервисы, ориентированные в первую очередь на мобильное обслуживание: для того чтобы открыть банковский счет или настроить домашний интернет, их клиентам требуется всего пара минут и несколько кликов.
В последние пять лет многие компании из разных отраслей начали экспериментировать, пробуя внедрять принципы Agile и стараясь почувствовать преимущества адаптивности. Некоторые из них – банки, операторы связи, ритейлеры и другие компании – даже делают попытки внедрить систему Agile в масштабе всей организации: они создают гибкие организационные модели, которые непрерывно видоизменяются, что позволяет быстро использовать возможности, возникающие на рынке. При этом особое внимание уделяется активной вовлеченности персонала в эти процессы. Преимущества такого подхода очевидны: результаты исследования, проведенного McKinsey, показывают, что, компании, которые освоили принципы организационной адаптивности, могут повысить финансовый результат на 20–30%. Такое повышение общей эффективности обусловлено ростом эффективности операционной деятельности на 30–50%, увеличением показателя удовлетворенности клиентов на 10–30 баллов, а индекса вовлеченности сотрудников – на 20–30 баллов. В сочетании с имеющимся у традиционных компаний опытом и наработанной клиентской базой эта более высокая эффективность, в свою очередь, помогает им преодолеть отставание от цифровых игроков, меняющих рынок, и успешно с ними конкурировать.
Независимо от отрасли и размера компании, успешные agile-организации придерживаются схожего подхода к пяти ключевым элементам: стратегии, структуре, процессам, персоналу и технологиям. В отношении первых четырех из этих элементов многие компании добиваются успеха, но работа с технологиями зачастую все еще представляет сложность. В этой статье мы рассмотрим типичные проблемы, возникающие при внедрении модели Agile в масштабах всей компании, через призму ИТ. Мы в общих чертах опишем пять изменений, которые генеральные директора и директора по ИТ могут совершить совместными усилиями. Эти преобразования помогут компаниям встать на правильный путь развития, добиться порой десятикратного ускорения ИТ-процессов, а также сократить затраты на ИТ и таким образом достичь уровня цифровых лидеров.
Пять изменений в области ИТ для обеспечения адаптивности компании
Чтобы конкурировать с игроками «цифрового поколения», компаниям необходимо совершить пять преобразований: создать по-настоящему кросс-функциональные команды под совместным управлением бизнеса и ИТ; «расшить» монолитные корневые ИТ-системы; нарастить собственный инженерно-технический потенциал в области ИТ; автоматизировать поставку программного обеспечения; внедрить облачную инфраструктуру (рис. 1). Каждое из этих преобразований вносит свой вклад в формирование организационной адаптивности за счет достижения конкретных бизнес-результатов. При этом решаются задачи как генерального директора, так и директора по ИТ: повышаются скорость поставки ПО, качество работы и производительность, улучшается клиентский опыт, снижается общая стоимость владения.
Изменение 1
Совместная работа: от изолированного ИТ-подразделения к кросс-функциональным agile-командам
От генеральных директоров часто приходится слышать, что подразделение ИТ похоже на черную дыру: задержки проектов и перерасход средств очевидны, а измерить производительность отдела проблематично. Со своей стороны, директора по ИТ жалуются, что бизнес-подразделения забрасывают их отделы бесконечными требованиями, но у команд нет ресурсов, чтобы их выполнять, а тем более устранять технический долг. С момента, когда бизнес- и ИТ-подразделения начинают определять и согласовывать требования, до написания первой строчки кода в организациях с традиционной структурой может пройти от трех месяцев до полугода.
Чтобы разрешить проблему взаимодействия ИТ и бизнеса, нужно изменить модель их сотрудничества: вместо изолированного ИТ-подразделения создать смешанные кросс-функциональные команды из специалистов – представителей бизнеса и ИТ. В таких командах сводится к минимуму количество передач из рук в руки заданий, решений и доработок, поэтому данная модель исключительно важна для ускорения разработки продуктов, вывода их на рынок и интеграции обратной связи. Ее основу составляют так называемые команды BizDevOps (business, development, operations – «бизнес, разработка, эксплуатация»). В каждой команде от пяти до девяти сотрудников, обладающих всем необходимым для достижения цели – компетенциями в сфере бизнеса, разработки и тестирования, а также обеспечения надежности при практическом использовании решения (рис. 2). Со стороны бизнеса в состав команд входят владельцы продуктов, специалисты по продуктам и специалисты по клиентскому опыту, которые определяют потребности в продуктах с учетом пожеланий клиентов и рентабельности инвестиций. Ежедневная работа инженеров заключается в создании готового к использованию ПО, а также автоматизации процессов для обеспечения надежности как релизов, так и работы ПО при эксплуатации. Благодаря постоянному взаимодействию членов команды на согласование требований уходят не месяцы, а всего лишь дни или даже часы. Это радикально сокращает сроки вывода продуктов на рынок и снижает количество бюрократических препятствий в работе.
На практике команды BizDevOps работают параллельно в разных направлениях бизнеса. Например, многие европейские и азиатские банки и телекоммуникационные компании сформировали большое количество таких команд, из которых складываются «команды команд» – так называемые «трайбы». Трайбы по работе с сегментами отвечают за весь пакет продуктов для тех или иных сегментов бизнеса, обеспечивая поддержку коммерческой деятельности; трайбы по работе с продуктами разрабатывают характеристики продуктов и «клиентские пути» – циклы всех взаимодействий клиента с компанией, связанные с определенными продуктами. Чтобы компенсировать издержки автономности трайбов по работе с сегментами и с продуктами, сохранить целостность архитектуры и эффективность затрат на ИТ, компании также формируют поддерживающие трайбы по работе с общими платформами, разрабатывающие общие сервисы и создающие компоненты повторного использования для облегчения работы инженеров из бизнес-трайбов. В зону ответственности трайбов по работе с платформами могут входить, например, кибербезопасность как услуга, инфраструктура как услуга или данные как услуга – в этих случаях они создают автоматизированные инструменты, предполагающие использование в режиме самообслуживания. Другой пример – трайбы по работе с корневыми ИТ-системами: в их ведении находятся давно существующие в компании сложные монолитные системы, которые используются несколькими трайбами и не могут быть разделены и распределены, по крайней мере на данный момент.
Во многих случаях трайбы вбирают в себя весь ИТ-персонал компании, а в их сферу ответственности входят все ее ИТ-системы – подразделение ИТ в традиционном понимании перестает существовать. Тем не менее сохраняется необходимость в надзоре за устранением технических недоработок, контроле технического качества поставки ПО и бесперебойной работы, а также в привлечении и развитии ИТ-специалистов. За все эти аспекты по-прежнему несет ответственность директор по ИТ. Чтобы сохранить баланс, компании могут назначить для каждого трайба как руководителя со стороны бизнеса («генерального директора» трайба), так и руководителя от ИТ («директора по ИТ» трайба). Зачастую руководитель трайба со стороны бизнеса подчиняется руководителю направления бизнеса компании (как правило, это член правления, например коммерческий директор), а руководитель трайба от ИТ – директору по ИТ, обеспечивая для него механизм контроля и подотчетности.
Изменение 2
Приложения и сервисы: от монолитных корневых ИТ-систем к независимым приложениям и сервисам с отдельными API1, за которые отвечают трайбы
Массивные, монолитные, многофункциональные ИТ-системы – пережиток прошлого. Современные ИТ-системы должны быть в достаточной степени фрагментированными, чтобы их части можно было постоянно совершенствовать независимо друг от друга. Раньше многие корневые системы, такие как автоматизированные системы в банках (АБС) и системы поддержки бизнеса (BSS) в телекоммуникационных компаниях, объединяли в себе множество функциональных возможностей в рамках одного приложения или нескольких связанных между собой монолитных приложений с запутанной системой взаимосвязей. Хотя такая структура имеет некоторые преимущества с точки зрения масштаба и скорости вычислений, но после изменения хотя бы одной функции, как правило, приходится проводить регрессионное тестирование всего функционала, чтобы убедиться, что в системе не возникло сбоев. Кроме того, многие системы, созданные в 1990-х и 2000-х гг., оптимизированы для работы в традиционных розничных каналах или даже для выполнения функций бэк-офиса. При этом в них не было предусмотрено функционала, который сделал бы их совместимыми с мобильными устройствами, платформами онлайн-магазинов, API партнеров и другими цифровыми каналами, которые с тех пор успели появиться и стать сложнее. Например, в одном банке при изменении тарифа или создании нового продукта приходилось корректировать до 30 систем. Разработкой параллельно занимались несколько подразделений, а на регрессионное тестирование для выявления ошибок уходили недели.
Замена таких корневых систем всегда была сопряжена со значительными затратами: на программу модернизации продолжительностью не в один год может уйти от 50 до 500 млн евро и более. Но такой план действий вовсе не обязательно будет лучшим вариантом для всех компаний.
В качестве альтернативы, стремясь обеспечить превосходный клиентский опыт и при этом разумно потратить средства, некоторые agile-компании начали использовать подход, предполагающий «выдавливание» старых систем новыми по частям, – Strangler pattern. Выбирают функции, которые меняются наиболее часто (например, процесс инициирования и одобрения кредитов, каталоги продуктов или тарифные модули, механизмы расчета рейтинга, модели данных или процессы взаимодействия с клиентами), назначают ответственными за них бизнес-трайбы или трайбы по работе с платформами и формируют выделенные команды BizDevOps для создания конкретных специализированных сервисов (так называемых микросервисов). В их основе лежит принцип «один сервис – одна функция»; с помощью таких сервисов из устаревших систем «вытягиваются» функции, которые не относятся к базовым, и в результате старое ядро постепенно теряет в весе (рис. 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. Это решение позволило разработчикам сосредоточиться на написании кода для создания функций, актуальных для бизнеса, вместо того чтобы тратить время на настройку конвейеров и инфраструктуры.
Разумеется, не все системы находятся на стадии полной готовности с первого дня работы, поэтому некоторым компаниям необходимо применять дифференцированный подход: для тех систем, которые готовы к подключению API, обеспечить возможность осуществления релизов в любой момент, а для других, требующих проведения регрессионного тестирования, внедрить конвейеры релизов, параллельно вкладывая средства в автоматизацию. За автоматизацию и ускорение процесса поставки ПО обычно отвечают специальные подразделения по работе с платформой поставки как услугой. Настраивая инструменты, например конвейеры CI/CD, и поддерживая их работу, они оказывают содействие всем трайбам организации («командам команд») во внедрении новых методов разработки.
Изменение 5
Инфраструктура: от физической инфраструктуры к облачным решениям и инфраструктуре как коду
Наконец, говоря об использовании современных технологий в формировании организационной адаптивности, нельзя не упомянуть облачную инфраструктуру, которая может быть публичной, частной и гибридной. Подобно тому, как этому же способствуют процессы автоматизации, она позволяет компаниям по мере необходимости пользоваться вычислительными мощностями и хранилищами данных, обходить бюрократические процедуры и сокращать время конфигурирования среды с нескольких недель до нескольких секунд. Как показало предыдущее исследование McKinsey, около 80% предприятий планируют в течение ближайших трех лет перевести в публичную облачную среду по меньшей мере 10% своих операций.
Несколько банков и телекоммуникационных компаний в Европе и в России уже пользуются услугами провайдеров облачных технологий при решении задач эксплуатации и тестирования. Например, один западноевропейский банк гибко использует облачные мощности для хостинга сред тестирования, восточноевропейский банк – для хостинга тестовых и эксплуатационных сред в рамках работы над отдельными приложениями и циклами всех взаимодействий клиента с банком и его продуктами в соответствии с требованиями федерального законодательства, а европейская телекоммуникационная компания полностью разместила в облачной среде слой API. Наиболее прогрессивные организации используют концепцию инфраструктуры как кода, получая мощности посредством API: они напрямую запрашивают дополнительные среды через ПО, вместо того чтобы настраивать физическое оборудование. Обычно за этот процесс отвечает трайб, работающий с ИТ-инфраструктурой2.
Опыт показывает, что в сочетании с методами непрерывной интеграции или поставки (CI/CD) облачная инфраструктура позволяет принципиально улучшить несколько ключевых показателей в области ИТ – в основном за счет того, что не приходится тратить время на ожидание и доработки, а также благодаря возможности прогнозировать потребности. Например, в результате автоматизации и внедрения стандартизованных процессов компаниям удается уменьшить продолжительность цикла поставки, а также ускорить развертывание и тестирование ПО. Некоторые команды, которые раньше на регрессионное тестирование тратили два дня спринта, теперь могут решать те же задачи всего за два часа. У компаний есть возможность не только повысить производительность, но и значительно сократить накладные расходы на ИТ благодаря оптимизации использования ИТ-активов и более гибкому подходу к ИТ в целом для удовлетворения потребностей бизнеса. Сегодня провайдеры облачных услуг все активнее предлагают гораздо более сложные решения, чем базовые технологии вычислений и хранения информации, – такие как сервисы на основе больших данных и машинного обучения. Кроме того, практика показала, что использование облачной инфраструктуры и методов непрерывной интеграции или поставки ПО позволяет сократить сроки вывода продуктов на рынок и повысить качество сервисов благодаря способности стандартных решений к «самовосстановлению»: например, если объем базы данных приближается к критическому, для хранения информации автоматически выделяются дополнительные мощности3.
Вместе взятые, пять рассмотренных преобразований могут обеспечить огромное множество положительных изменений, основой которых будет целенаправленная работа с такими аспектами корпоративной модели Agile, как стратегия, структура, процессы и персонал. Кросс-функциональный характер организационной структуры минимизирует цепочки передачи информации, и в результате скорость работы возрастает. За счет использования более автономных и специализированных сервисов, автоматизированных инструментов разработки, тестирования и развертывания ПО, а также облачной инфраструктуры ускоряется появление новых релизов. А наличие собственных высококвалифицированных ИТ-специалистов ведет к повышению эффективности, развитию институциональных знаний и более рациональным отношениям с поставщиками. Каждый из этих факторов способствует снижению общей стоимости владения, высвобождению капитала для реинвестирования или прямому сокращению затрат. В пилотных проектах положительные результаты становятся заметны уже через три месяца после начала преобразований. Безусловно, для любой организации эти преимущества стоят того, чтобы проанализировать осуществимость преобразований и оценить связанные с ними затраты.