3 вещи, которые нужно изменить в своем подходе к цифровой трансформации

Источник · Перевод автора

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

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

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

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

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

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

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

Кейт отмечает, что невозможно создать DX в банке, который работает с 1834 года. Ее компания, например, не может интегрироваться с клиентами с точки зрения документооборота. Они используют стороннюю платформу SaaS для финансового учета и обычно ждут шесть месяцев для любого запроса на новые функции. Представьте себе большую бюрократическую структуру. У него часто есть независимые отделы, которые были созданы в результате поглощения других компаний, и каждый из них имеет устаревшие монолитные самописные программы, которые не поддерживались последние 30 лет.

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

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

Анализируя эти истории, я понял, что мой опыт работы с DX можно оценить как успешный. Я принадлежу к восьми процентам самых удачливых людей, которые, согласно исследованиям Bain & Company, смогли достичь намеченных бизнес-результатов за счет своих инвестиций в цифровые технологии – они ускоряются, экономят и масштабируются. Во многом из-за того, что я работаю в IT, где имею хорошую техническую компетенцию.

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

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

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

Мечты, риски и трудный выбор

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

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

Эволюция составного предприятия

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

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

Что делать по-другому

Оценивая возможность дальнейшего развития и масштабируемости, рекомендую учесть следующие моменты:

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

Подводя итог, очевидно, что DX неизбежен, поскольку промышленная революция в свое время. Те компании, которые не занимаются инновациями, выйдут из бизнеса, как Nokia несколько лет назад. Реальность сегодняшнего дня такова: вводи новшества или умри. Другой возможности нет.

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