Модульные платформы (Composable Enterprise) – не волшебная палочка в руках программистов. Успех любой трансформации, включая цифровую, начинается с видения бизнеса и его развития на несколько лет вперед.
Когда бизнес захочет масштабироваться, запускать новые продукты и локации, внедрять новые решения, пробовать новые технологии, все системы придется поддерживать вам. Сможете ли вы сделать это с монолитом, сторонними SaaS (software as a service – программное обеспечение как услуга. – Прим. ред.) и текущей IT-инфраструктурой?
Враги трансформации: устаревший код, бюрократия и «олдскул»
Недавно мы с друзьями делились мыслями о цифровой трансформации. Денис – владелец продукта международной e-commerce платформы, Катя – коммерческий директор производственной компании, Майк – IT-директор в логистической компании. У каждого из нас была своя история о том, что стоит на пути к цифровой трансформации (ЦТ).
Денис рассказал о клиенте, владельце фермерского хозяйства в европейской глубинке, который не успел вовремя оплатить пакет услуг. Он поехал в райцентр сделать платеж в банк по реквизитам, но забыл указать назначение.
С учетом операционного времени банка деньги шли несколько дней. За это время локальная бухгалтерия пыталась выяснить, чьи деньги пришли, чтобы активировать оплату. И таких клиентов тысячи.
Компания Дениса в свою очередь не может интегрироваться с локальными банками, потому что в банке устаревшая система и нет API.
Катя отметила, что невозможно сделать цифровую трансформацию в банке, который работает с 1834 года. Ее компания, к примеру, не может интегрироваться с клиентами по документообороту. Они используют 3rd party SaaS-платформу для финансового учета и любой запрос на новый функционал ждут по полгода.
Нужно представить себе большую бюрократическую структуру. В ней часто существуют самостоятельные отделы, которые создавались путем поглощения других компаний, и в каждом из них устаревшие монолитные самописные программы, которые не поддерживаются последние 30 лет.
Майк руководит отделом разработки больше 20 лет. Их компания создает свою систему, так как нет альтернативных решений – такова специфика рынка.
Поскольку IT – это ядро бизнеса и главное конкурентное преимущество, Майк осознает, как важно быть гибкими, выпускать новые сервисы, функционал, модули быстрее конкурентов. Но и здесь подводный камень: технологии устаревают с бешеной скоростью.
Цифровая трансформация, которую сделала я
Слушая друзей, я понимала: мой опыт цифровой трансформации с применением composable enterprise можно оценить как успешный.
Я принадлежу тем 8% счастливчиков, которые, по статистике, достигают целевых показателей ЦТ – ускоряются, экономят и масштабируются. Во многом благодаря тому, что я работаю в IT, где есть хорошая техническая компетенция.
Полтора года назад я думала, что поддерживать новую систему в постоянно меняющейся среде придется именно моему отделу и, понимая всю ответственность, не хотела создавать себе проблем в будущем. Потому я определила основные критерии успеха ЦТ и принципы, на которые мы будем ориентироваться в нашем сomposable enterprise:
- Независимость от провайдера. И это не только о сроках и качестве разработки. Моя компания должна иметь доступ к своим данным в реальном времени, в полном объеме и неограниченные возможности формировать любые отчеты с любым количеством измерений (dimensions). И эти данные должны быть структурированы.
- Простота в поддержке. Мы не конфигурируем системы заново при изменении структуры компании, а запросы на новый функционал или добавление новых сервисов доставляется пользователю в течение недели. Возможность управлять временем (time to market).
- Единая точка входа информации. Здесь со всей настойчивостью и перфекционизмом я была несгибаема: если что-то ввели один раз, оно проходит по всем процессам и идентично существует во всех системах. Ни одного дублирования. Никогда.
Я точно не хочу ждать ЦТ несколько лет и выкинуть миллионы долларов, а потом понять, что приняла неправильное решение. Принципы iterative agile development (итеративная гибкая разработка) и MVP (минимально жизнеспособный продукт) как нельзя уместны и полезны в цифровой трансформации.
Мечты, риски и сложность выбора
Просматривая одно демо за другим предлагаемых рынком решений, путаясь в многообразии SaaS, я предавалась мечтам. Мне хотелось, чтобы существовал некий каркас, на который можно нанизывать комплектующие решения, заменять их при устаревании.
Данные, собираемые процессами и датчиками, хорошо бы «сливать» в единый Data Warehouse (хранилище данных), откуда мы бы с легкостью формировали любой отчет.
Сейчас каждое из этих решений по отдельности – риск, возможность решить одну задачу, проседая в других. Ни один человек в компании даже не знает точно, сколько у нас систем. У каждого отдела есть что-то свое. Нужно потратить несколько дней, чтобы собрать простой отчет – он устареет через пару часов.
Возникла мысль: а что если мы возьмем несколько готовых решений, настроим под наши процессы, подружим между собой, чтобы они общались и обменивались данными?
Эволюция модульных платформ
Если задаться целью освоить API (интерфейс программирования приложения) и микросервисы, ты дальше входишь во вкус и не можешь остановиться. Вот в нашем сознании, как и на рынке в целом, эволюционируют модульные платформы.
Сопоставляя частички и ожидая, что они будут вращаться без нашей помощи, я представляла вселенную. Важно воздействовать на них силой гравитации: притянуть их к ядру – жестко регулируемой и защищенной системе.
Система Core Master – необходимый каркас для composable enterprise, от которого будут отходить ветви процессов и workflow (поток работ). Он должен находиться внутри организации и быть написан под нашу уникальность. Остальные системы – легко настраиваемые SaaS-решения с API – это лишь комплектующие, которые можно менять так часто, насколько это необходимо.
Что бы я сделала по-другому
Для меня наша цифровая трансформация с модульными платформами composable enterprise – успех. Тем не менее, оценивая возможность дальнейшей эволюции и масштабируемости, я бы сделала некоторые вещи по-другому:
- Не смотрела бы на готовый функционал и не брала бы готовые решения, предлагаемые SaaS. Никогда. Даже если UI (интерфейс пользователя) выглядит симпатично. Вы будете ограничены во всем, даже в экспорте данных. Все процессы, которые мы конфигурировали самостоятельно на формах, workflow, скриптах, работают, эволюционируют и легко меняются. Те процессы, которые соблазнились взять в готовом виде, – сплошная головная боль.
- Была бы осторожнее с API – многие вопросы решаются конфигурацией. Если нужно писать сложный скрипт – подумайте еще. Возможно, стоит сходить к пользователю и выяснить, что решение его задачи лежит в другой плоскости. Просто помните о том, что с изменением политики авторизации у провайдера вам придется внести изменения в каждый скрипт – вручную и во всех системах.
- Не стала бы недооценивать предварительную работу с пользователем и UAT (пользовательское тестирование). Некоторые процессы никогда не будут работать. Сядьте с пользователем и посмотрите, куда он нажимает. Когда вы увидите, что он использует Tab для введения данных, то форма с длинным горизонтальным скроллом покажется лучшим решением, чем современный, красивый адаптивный (responsible) UI под все браузеры, на который вы потратили неделю.
Очевидно, что ЦТ неизбежна, как в свое время промышленная революция. Те компании, которые не занимаются инновациями, окажутся вне бизнеса, как Nokia несколько лет назад. Реалии сегодня таковы: innovate or die (англ. вводи инновации или умри. – Прим. ред.). Третьего не дано.
