Цифровая трансформация по формуле 7R

Логотип компании
Цифровая трансформация по формуле 7R
7R – концепция, состоящая из набора критериев и рекомендаций для проведения цифровой трансформации через миграцию на облачную платформу провайдера. Все ее элементы – термины, начинающиеся с буквы R, отсюда и название.

1. Retain: оставь так

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

Это первое (и одно из двух главных) ‘R’ в дереве принятия решений по цифровой трансформации сегодня. Означает оно retain, то есть сохраняем всё как есть. По большому счету это то, самое родное: «работает – не трогай».

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

Кто-то привязан к своиму серверному «железу», на котором крутятся ключевые для бизнес-модели приложения и данные. Современные условия для перемен в этом плане не выглядят для таких компаний очевидными: «Когда-нибудь мы переедем в облако, обновим стэк, но не сейчас».

2. Retire: старье – в утиль

Второй базовый вариант и еще одно важное ‘R’, определяющее ИТ-стратегию бизнеса, – Retire. Полная противоположность сохранению статус-кво.

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

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

Старый цифровой ландшафт организации при таком подходе отправляется «на пенсию».

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

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

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

3. Reimagine: пора переосмыслить себя

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

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

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

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

4. Rearchitect: от концепции к действию

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

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

Все это влечет за собой пересмотр кода конкретных решений, подходов к управлению жизненным циклом приложений (ALM, Application Lifecycle Management) и процессам интеграции компонентов в обновленный ИТ-ландшафт.

5. Replace: заменяем и меняемся   

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

Это вариант Replace, включающий в себя приобретение коробочных или SaaS-продуктов и/или лицензий с развертыванием на уже существующей платформе и ее конфигурированием.

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

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

6. Replatform: меняем фундамент

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

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

Это довольно серьезный сценарий, который предусматривает фундаментальные варианты апгрейда. Например, если компания видит необходимость более широкого привлечения инструментов анализа больших объемов данных и ИИ, это неизбежно потребует больших инфраструктурных изменений. Соответствующий для этих задач софт (скорее, целую функциональную платформу) не так просто купить, развернуть, настроить и интегрировать в сложившийся на локальном «железе» ландшафт.

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

7. Rehost: Ctrl+C – Ctrl+V

Седьмой R-вариант появляется на горизонте развития компании, когда для достижения ощутимых преимуществ в работе ИТ-составляющей бизнеса необходимо сменить место «прописки» систем с локальной на облачную. Тогда происходит миграция в облако по модели Lift & Shift – перемещение существующего ландшафта (систем, приложений и данных) в облачную инфраструктуру с минимальным перепроектированием или модификацией, а в некоторых вариантах – совсем без них.

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

Заключение

Универсального применения всех вариантов развития на практике не существует, порядок их перечисления – довольно условный. Очень многое зависит от целей, задач, а также уровня цифровой зрелости компании. Например, в каких-то случаях в отношении ряда приложений оптимальным выбором будет Rehost, а решения в рамках Retain и/или Retire в отношении других составляющих ИТ-ландшафта можно принять позже.

Однако в самом общем виде множество современных задач по оптимизации инфраструктуры можно и нужно прорабатывать через 7R-подход как своего рода матрицу типичных вариантов развития корпоративных ИТ-систем.

Опубликовано 18.01.2023

Похожие статьи