Если откажетесь от инноваций, вылетите с рынка, как Nokia: вот как развиваться, не тратя миллионы долларов

Модульные платформы (Composable Enterprise) – не волшебная палочка в руках программистов. Успех любой трансформации, включая цифровую, начинается с видения бизнеса и его развития на несколько лет вперед.

Когда бизнес захочет масштабироваться, запускать новые продукты и локации, внедрять новые решения, пробовать новые технологии, все системы придется поддерживать вам. Сможете ли вы сделать это с монолитом, сторонними SaaS (software as a service – программное обеспечение как услуга. – Прим. ред.) и текущей IT-инфраструктурой?

Враги трансформации: устаревший код, бюрократия и «олдскул»

Недавно мы с друзьями делились мыслями о цифровой трансформации. Денис – владелец продукта международной ecommerce платформы, Катя – коммерческий директор производственной компании, Майк – IT-директор в логистической компании. У каждого из нас была своя история о том, что стоит на пути к цифровой трансформации (ЦТ).

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

С учетом операционного времени банка деньги шли несколько дней. За это время локальная бухгалтерия пыталась выяснить, чьи деньги пришли, чтобы активировать оплату. И таких клиентов тысячи.

Компания Дениса в свою очередь не может интегрироваться с локальными банками, потому что в банке устаревшая система и нет API. 

Катя отметила, что невозможно сделать цифровую трансформацию в банке, который работает с 1834 года. Ее компания, к примеру, не может интегрироваться с клиентами по документообороту. Они используют 3rd party SaaS-платформу для финансового учета и любой запрос на новый функционал ждут по полгода.

Нужно представить себе большую бюрократическую структуру. В ней часто существуют самостоятельные отделы, которые создавались путем поглощения других компаний, и в каждом из них устаревшие монолитные самописные программы, которые не поддерживаются последние 30 лет.

Майк руководит отделом разработки больше 20 лет. Их компания создает свою систему, так как нет альтернативных решений – такова специфика рынка.

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

Цифровая трансформация, которую сделала я

Слушая друзей, я понимала: мой опыт цифровой трансформации можно оценить как успешный.

Я принадлежу тем 8% счастливчиков, которые, по статистике, достигают целевых показателей ЦТ – ускоряются, экономят и масштабируются. Во многом благодаря тому, что я работаю в IT, где есть хорошая техническая компетенция. 

Полтора года назад я думала, что поддерживать новую систему в постоянно меняющейся среде придется именно моему отделу и, понимая всю ответственность, не хотела создавать себе проблем в будущем. Потому я определила основные критерии успеха ЦТ и принципы, на которые мы будем ориентироваться: 

• Независимость от провайдера. И это не только о сроках и качестве разработки. Моя компания должна иметь доступ к своим данным в реальном времени, в полном объеме и неограниченные возможности формировать любые отчеты с любым количеством измерений (dimensions). И эти данные должны быть структурированы.
• Простота в поддержке. Мы не конфигурируем системы заново при изменении структуры компании, а запросы на новый функционал или добавление новых сервисов доставляется пользователю в течение недели. Возможность управлять временем (time to market).
• Единая точка входа информации. Здесь со всей настойчивостью и перфекционизмом я была несгибаема: если что-то ввели один раз, оно проходит по всем процессам и идентично существует во всех системах. Ни одного дублирования. Никогда.

Я точно не хочу ждать ЦТ несколько лет и выкинуть миллионы долларов, а потом понять, что приняла неправильное решение. Принципы iterative agile development (итеративная гибкая разработка) и MVP (минимально жизнеспособный продукт) как нельзя уместны и полезны в цифровой трансформации.

Мечты, риски и сложность выбора

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

Данные, собираемые процессами и датчиками, хорошо бы «сливать» в единый Data Warehouse (хранилище данных), откуда мы бы с легкостью формировали любой отчет. 

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

Возникла мысль: а что если мы возьмем несколько готовых решений, настроим под наши процессы, подружим между собой, чтобы они общались и обменивались данными? 

Эволюция модульных платформ

Если задаться целью освоить API (интерфейс программирования приложения) и микросервисы, ты дальше входишь во вкус и не можешь остановиться. Вот в нашем сознании, как и на рынке в целом, эволюционируют модульные платформы. 

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

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

Что бы я сделала по-другому

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

1. Не смотрела бы на готовый функционал и не брала бы готовые решения, предлагаемые SaaS. Никогда. Даже если UI (интерфейс пользователя) выглядит симпатично. Вы будете ограничены во всем, даже в экспорте данных. Все процессы, которые мы конфигурировали самостоятельно на формах, workflow, скриптах, работают, эволюционируют и легко меняются. Те процессы, которые соблазнились взять в готовом виде, – сплошная головная боль.
2. Была бы осторожнее с API – многие вопросы решаются конфигурацией. Если нужно писать сложный скрипт – подумайте еще. Возможно, стоит сходить к пользователю и выяснить, что решение его задачи лежит в другой плоскости. Просто помните о том, что с изменением политики авторизации у провайдера вам придется внести изменения в каждый скрипт – вручную и во всех системах.
3. Не стала бы недооценивать предварительную работу с пользователем и UAT (пользовательское тестирование). Некоторые процессы никогда не будут работать. Сядьте с пользователем и посмотрите, куда он нажимает. Когда вы увидите, что он использует Tab для введения данных, то форма с длинным горизонтальным скроллом покажется лучшим решением, чем современный, красивый адаптивный (responsible) UI под все браузеры, на который вы потратили неделю.

Очевидно, что ЦТ неизбежна, как в свое время промышленная революция. Те компании, которые не занимаются инновациями, окажутся вне бизнеса, как Nokia несколько лет назад. Реалии сегодня таковы: innovate or die (англ. вводи инновации или умри. – Прим. ред.). Третьего не дано.