В США есть компания COBOL Cowboys, где работают программисты пенсионного возраста, работающие с давно «вышедшими на пенсию» языками программирования – COBOL, Fortran. Казалось бы, кому сегодня нужны компетенции в языках, на которых писали компьютерные системы 60-х годов прошлого века? Но фирма процветает. В первую очередь, из-за того, что на этих языках написаны ядра автоматизированных банковских систем, которые до сих пор работают в таких крупных банках, как, например, JP Morgan Chase. Менять систему – сотни миллионов долларов и колоссальные, непрогнозируемые риски. Специалистов, которые знают эти языки – исчезающе мало. Поэтому сейчас COBOL Cowboys процветают. А что будет дальше? Ждет ли крупнейшие мировые банки «цифровой коллапс»?
Технический долг
Директорам по ИТ давно известна проблема «технического долга» – когда старые ИТ-системы, которые невозможно поддерживать и развивать, но от которых крайне проблематично избавиться, тормозят развитие ИТ в компании. А сегодня, когда цифровая трансформация стала абсолютно насущным требованием времени, у бизнеса возникает постоянная потребность в оцифровке все новых бизнес-процессов и внедрении новых сервисов, невозможность интеграции новых и устаревших систем создает проблемы, напрямую влияющие на конкурентоспособность компаний. Сегодня практически любой CEO признает, что «технический долг» – не просто функциональная проблема, а одно из основных препятствий для развития бизнеса в целом, особенно если это высокотехнологичный бизнес – банкинг, ретейл, телеком. В ходе глобального исследования Accenture 70% опрошенных подтвердили крайне негативный характер «технического долга», 72% отметили его роль в затруднении адаптации передовых ИТ-инструментов, а еще 69% заявили, что технический долг существенно сокращает маневренность их компаний в плане скорости реакции на рыночные перемены.
Если говорить о Казахстане, то в первую очередь с проблемой «технического долга» сталкивается банковская отрасль. АБС, которые были внедрены 10, а то и 20 лет назад, сегодня сложно, крайне затратно, а порой и невозможнопроинтегрировать с насущными сервисами. И вариантов здесь у руководства банков сегодня два: либо проводить очень дорогую и очень рискованную программу по замене этих систем, причем это высокий риск, и вероятность того, что «взлетит», крайне низкая, либо провести процесс так называемого «цифрового декаплинга» (decoupling – расстыковка, рассоединение связей).
Цифровой декаплинг
Проще всего объяснить стратегию декаплинга на примере. Допустим, у банка есть задача – показывать баланс по всем продуктам клиента в мобильном банке или во фронтальной системе сети отделений (так называемая функциональность «Клиент на 360 градусов»), и делать это очень быстро. Делать это старые системы не могут или могут очень ограниченно: им сложно собрать эту информацию, сложно отдать ее во фронт-энд системы, интернет или мобильный банк, и это все занимает время и огромные ресурсы с точки зрения сбора этой информации. А современный «цифровой запрос» таков, что банк должен предоставить клиенту информацию здесь и сейчас, а еще лучше – снабдить ее какой-то прогнозной аналитикой. На будущее.
Поэтому суть цифрового декаплинга – задействовать новые технологии, методики разработки софта и миграции в новые форматы цифровых сред для построения новых цифровых систем «поверх» старых унаследованных. Фактически, из старых систем в новую цифровую платформу выносятся необходимые для цифровых сервисов элементы, где они реализуются на новом «современном» стеке технологий.Самое сложное здесь с точки зрения технологий – обеспечить корректную постепенную реализацию новой цифровой архитектуры без ущерба производительности и надежности.
«Дорожная карта» трансформации
Ключевая задача, которую надо решить, запуская проект по декаплингу, – это четкое целеполагание: что мы хотим от будущей трансформации. Надо понимать, кто наш будущий клиент, какие продукты мы продаем, какой уровень сервиса обеспечиваем, в какие системы интегрируемся, или какие экосистемы мы создаем с нуля. Надо ответить на данные бизнес-вопросы, при этом нужно четко понимать, какой эффект, возврат инвестиций от проекта по декаплингу получит организация. Далеко не все казахстанские компании, к сожалению, умеют просчитать этот эффект.
Есть два подхода, как считать окупаемость проектов по цифровому декаплингу. Массовый, масштабный подход – посчитали бизнес-кейс, провели маркетинговое исследование, поняли, какие сегменты и клиенты нам интересны, прикинули затраты, сформировали программу на 2-3 года, учли международный опыт и приступили. При том, что компания хорошо понимает процесс и видит картину в комплексе, у такого подхода есть один огромный риск: цифровой мир чудовищно быстро устаревает. Планирование на несколько лет вперед в нем невозможно.
Второй подход – это так называемый test and data driven approach, когда выбирается какой-то основной сервис и вокруг него создается, часто в режиме MVP (минимального набора рабочих функций), дополнительный продукт, который тестируется и меняется фактически «на живом». Например, у банка есть услуга расчетного счета для малого бизнеса. Добавляем к ней функцию удаленной бухгалтерии, выставления счетов, начинаем тестировать на каком-то ограниченном количестве клиентов, смотреть их реакцию, учитывать ошибки – если все позитивно, то масштабируем сервис дальше. В современном мире такой подход оправдан гораздо больше.
«Слоеный пирог» из сервисов
Очень опасный момент в таких проектах декаплинга в крупных организациях – это когда старые системы обрастают такими новыми цифровыми сервисами и в итоге у ИТ-команды получается в управлении лоскутный набор технологических компонентов. Поэтому в стратегии декаплинга очень важно прописать, какой именно набор технологий, правила и архитектуры будут использоваться.
Если мы говорим о полноценной цифровой трансформации, в частности в банке, то главный тренд сегодня – это создать промежуточную цифровую платформу, состоящую из десятка современных компонентов. И уже вокруг этой платформы начать «ткать» ту функциональность, которую мы хотим реализовывать, те новые элементы бизнеса, которые мы хотим выпускать на рынок. Большая ловушка для организаций – влиться в огромную, очень тяжелую программу по сносу старого и замене на новое. Элементы функциональности из старых систем надо постепенно переносить на новые платформы, на которых уже можно свободно реализовывать современные функции, такие как динамический прайсинг, next best offer, cross-sell, upsell – то, что предыдущее поколение систем не давало реализовать.
Появляется трехслойная логика такой архитектуры: слой визуальной логики – то, что видит в интерфейсах клиент или оператор банка. За ним стоит слой новой цифровой платформы, в котором, собственно, реализуются и бизнес-процессы, и новая расчетная логика, и любаядополнительная функциональность.
А базовые системы старого поколения превращаются просто в транзакционные машины, хранилища контрактов, задача которых – просто учитывать транзакции, вся современная продуктовая логика выносится за пределы этих систем.
Проблема казахстанского рынка в использовании такого рода подхода – это, в первую очередь, недостаточные количество и квалификация персонала. Людей на рынке мало, специалисты востребованы в большом количестве существующих инициатив. И найти команду, соответствующую масштабам и сложности задач, сегодня довольно трудно. Поэтому для «светлого цифрового будущего» завтра – компании должны озаботиться подготовкой кадров для него уже сегодня.
Автор: Антон Мусин, управляющий директор Accenture Казахстан
