Цифровая Трансформация – основная цель, задача и тема разговоров крупного и среднего бизнеса. Однако из-за присутствия огромного количества мифов, легенд и романтики вокруг цифровизации компании не могут увидеть результатов от своих действий многие годы.
Это проблема не только российских компаний. Nike, Ford, Burberry, Procter & Gamble и многие другие известные транснациональные корпорации показали в ряде проектов в лучшем случае неоднозначные результаты, а иногда – абсолютно ужасные, что приводило к увольнениям, сокращениям и убыткам.
Мы изучили истории провалов, провели интервью с представителями крупного и среднего бизнеса, проанализировали ошибки, вывели ряд закономерностей и в последствии пришли к своему решению. Но об этом в конце.
Рассмотрим ТОП 4 самых распространенных ошибок.
1. Отсутствие видения
Если сказать односложно, то у лидеров не было ответа на вопрос «Мы запускаем цифровую трансформацию, чтобы что..?».
Опрос Wipro Digital (зарубежные коллеги в области цифровой трансформации) показал, что более трети усилий по цифровизации проваливаются, так как не было четких критериев успешности и понимания эффекта от действий команды.
К этому примешивается желание полностью перекроить все устои, снести старое и построить новое. Достаточно распространенная болезнь менеджмента.
Решение
В общении с клиентами, перед которыми стоит задача оцифровать свою деятельность, мы рекомендуем начать всегда с анализа текущей ситуации, определения основных драйверов роста, поиска «узкого горлышка» в процессах, интервьюирования членов команды и т.д.
Иными словами, перед тем как что-то строить, необходимо понять, что мы хотим построить. В чем реальная проблема и реальная боль? Где мы приобретаем максимальную выгоду? Какие факторы риска имеются? В чем наше текущее преимущество?
Только после этого этапа можно перейти к вопросу «А как это сделать?».
Если провести аналогию со строительством дома, то мы создаем проект. Отсутствие проекта стабильно приводит к увеличению сметы минимум на 20%. И не важно, что мы создаем: дом, сайт, приложение или завод.
Оборотная сторона
Внедрение инноваций всегда сопряжено с сопротивлением. Часто даже члены команды воспринимают все в штыки и вставляют палки в колеса: кто-то из страха остаться без работы, кто-то хочет сохранить свое положение, кто-то имеет свою уникальную точку зрения и т.д.
Соответственно во время сбора мнений, если делать неосторожно, можно получить искаженную информацию о реальном положении дел. А значит, если мы получим неверные данные, то сделаем неверный вывод, на основании чего выберем неверную стратегию.
2. Все и сразу
Все мы люди, а значит как и все люди мы бы хотели получить результат в максимально короткие сроки. В эту ловушку попадают многие руководители компаний. Возникает желание откинуть все компромиссы и «начать улучшать все».
В итоге это приводит к тому, что силы команды распыляются вместе с вниманием и фокусом. В то же время, это огромный стресс для всей компании, ведь такими действиями создается нагрузка на каждый элемент бизнеса. Появляется сотня пожаров, которые необходимо постоянно тушить. В итоге, команда разработки большую часть своей времени начинает тратить не на создание нового, а на исправление существующего.
Решение
В сегодняшнем мире естественным образом стало популярным управление проектами по гибким методологиям – Agile. Популярность подход обрел именно ввиду высокой скорости изменений на рынке.
Соответственно, все проекты делаются поэтапно. Из всего обилия компонентов бизнеса выбирается наиболее приоритетный на основании соотношения затрат к выгодам.
При таком подходе мы тратим рациональное количество ресурсов, при этом сохраняя гибкость в управлении ходом проекта. Бонусом мы получаем возможность оценить финансовый эффект от внедрения.
Когда мы внедряем «сразу 10» нововведений, то достаточно сложно определить, какой фактор оказал максимальное влияние. Работая поэтапно, мы можем оценить каждое свое действие в цифрах.
Оборотная сторона
Данный подход не сработает в культуре, которая основана на жестких дедлайнах, низкой степени ответственности, низком моральном духе и общей «зелености» команды. Перед тем как внедрять подобный подход необходимо убедиться в зрелости и команды и ее готовности к изменениям.
В противном случае, мы попадем в ситуацию полной анархии и непредсказуемости.
Другой риск сопряжен с желанием довести все до идеала. Команда разработала новый модуль, который дал добавленную ценность, а после годами работает лишь над ней. В итоге, система не развивается.
Таким образом, культура важнее квалификации.
3. Низкий уровень подготовки организационной культуры
Всегда найдется группа людей, которые будут всячески саботировать любые изменения. Часто ряд топ-менеджеров и даже рядового персонала не хочет, чтобы их бизнес-процесс стал прозрачным и понятным. Причины могут быть разными: от низкой цифровой грамотности до теневых закупок и веру в теорию заговора.
На самом деле, команда имеет полное право не понимать для чего и что делается, а человеческая сущность такова, что мы воображаем наиболее ужасный сценарий.
Решение
Изменения наступают не в ситуации, когда приходит инициатива сверху или снизу. Изменения наступают только в ситуации, когда инициатива проявляется на всех уровнях. Любая инновационная деятельность требует подготовленной почвы.
Крайне важно внедрять цифровую трансформацию с предварительной образовательной и просветительской программой для членов команды. Культурный код необходимо обновить к современным реалиям.
Оборотная сторона
Во всем хороша мера. Если чрезмерно долго тратить время на разговоры и подготовку, то произойдет не менее печальная ситуация. Люди имеют свойство утомляться, когда им подолгу рассказывают о светлом будущем, особенно если эти слова не трансформируются в действия.
Некоторые руководители так сильно увлекаются процессом подготовки, что уже стремятся создать «идеальную» почву для запуска. Но единственное, к чему это приведет – к демотивации команды и нулевым инициативам.
4. Фокус на технологиях, а не на пользователях
О цифровой трансформации задумываются только те компании, у которых уже есть некий IT-ландшафт. Как правило, эта IT-среда в той или иной мере устарела. Это издержки раннего успеха. Компании начинали 10-20-30 лет назад и выстраивали свой бизнес на базе решений тех лет.
Со временем это все обрастает новыми элементами и некогда легкая и гибкая система превращается в неповоротливого монстра. Это и есть Legacy – наследственная IT-система.
И в этот момент появляется соблазн достроить поверх очередной слой решений с надеждой, что это полностью изменит картину. Аргументация достаточно простая: «У нас же есть эти технологии, да еще и специалисты. Чего париться-то?»
На деле же получается картина, когда руководитель пытается исправить стратегический просчет в виде крайне ограниченной системы с помощью косметических решений. При этом, совершенно забывая про то, для кого и для чего мы это делаем. Цифровая трансформация предназначена прежде всего для пользователей (как внутренних, так и внешних), а не для компании. Наша задача построить такую среду, в которой максимально быстро внедряется дополнительная ценность. Иными словами, максимально снижаем time-2-value и time-to-market.
Решение
Что бы мы не делали, основной фокус должен быть на пользовательском опыте. Необходимо постоянно проводить тестирование нового функционала на живых пользователях, проводить интервью и строить и улучшать пользовательские/поведенческие карты.
Когда мы сталкиваемся с Legacy-системами, то команда часто не может дать пользователям новую ценность, так как она ограничена существующим функционалом, плюс, текущими задачами по поддержанию жизнеспособности IT-ландшафта.
Существует 4 выхода из ситуации.
Первый путь. Начать разработку новой системы «рядом». Это означает, что система строится автономно и на запускается в реальные бизнес-процессы. Все это время бизнес функционирует на базе старых решений.
Данный подход очень дорогой и крайне рискованный. Чтобы разрабатываемая система возымела успех необходимо с точностью до 95% понимать, что мы хотим от системы и как она должна выглядеть. На практике это не работает, так как достаточно большой пласт задач и реальных болей/проблем неизвестен. Соответственно, задача превращается в исследовательскую, но с реальными и существенными ставками.
Отдельный «кот в мешке» – насколько плавно удастся внедрить новую систему.
Второй путь. Разбить всю экосистему на маленькие модули и запустить поэтапную разработку. Один модуль за другим. Сделали - протестировали в реальной среде – внедрили - перешли к следующему кусочку. По сравнение с первым вариантом, этот путь менее рискованный, менее дорогостоящий, однако отнимает много времени. Примерно в 1,5-2 раза дороже и дольше. Из несомненных плюсов – мы достаточно быстро видим первые результаты и можем понять, стоит ли продолжать дальше.
Третий путь. Найти готовое решение. Часто хоть и не всегда дешевле чем оба предыдущих варианта, однако здесь мы сталкиваемся с ограничениями коробочных решений. Компании, которые разрабатывают подобные решения, включают в свой продукт наиболее популярный на рынке функционал.
Но часто команды сталкиваются с тем, что все-таки приходится использовать несколько решений от разных компаний, а потом вручную настраивать взаимодействие всех компонентов. То есть, мы улучшаем ситуацию, но попадаем в некое промежуточное состояние. Вроде все обновили, но вроде как и снова можем попасть в капкан разнородности экосистемы.
Четвертый путь - Гибридный. Объединяем лучшее из каждого варианта. Наиболее оптимальный путь, когда внутри компании большое количество сотрудников, процессов и клиентов.
Суть подхода проста: с помощью некой платформы создается «срединный слой», который позволяет эксплуатировать текущий IT-ландшафт с новыми модулями. Таким образом, команда концентрируется на разработке новых сервисов и приложений на новой платформе, при этом продолжает использовать старые компоненты для решения текущих задач. В моменте мы получаем уже современную систему, в рамках которой мы по кусочкам заменяем старый ландшафт новым. Это как раз тот путь, который выбрала наша команда.
Оборотная сторона
Часто за стремлением угодить пользователю забывается важная суть: любые инициативы должны приносить еще и пользу компании в денежном эквиваленте. Можно создать идеальный продукт для пользователя, который полностью обескровит компанию, что не является целью цифровой трансформации.
Отдельно про решение 4-го типа по избавлению от нагрузки Legacy. Если гибридная платформа не предоставляет возможности создания собственных сервисов и не оптимизирует производственные процессы, то данное решение не изменит стратегического положения компании.
Новая платформа должна позволять быстро разрабатывать приложения, автоматизировать рутинные задачи и не просто объединять старое и новое, но и снижать влияние старой системы на вероятность успеха реализации проекта.
Платформа должна делать жизнь пользователей лучше.
Что придумала наша команда
Мы достаточно плотно работали с компаниями, в которых проблема перехода в новую реальность стояла достаточно остро. На базе этого опыта мы разработали собственную платформу, которая как раз и нацелена на то, чтобы переход с Legacy осуществлялся максимально комфортно и быстро. Разрабатывали изначально для себя, чтобы быстрее выполнять собственные задачи, но мы быстро поняли, что подобный продукт интересен и другим участникам рынка.
Мы поняли, что самое важное сегодня – уметь быстро и предсказуемо разрабатывать новые сервисы, а значит, нужна платформа, которая позволит упростить жизнь разработчикам.
Мы поставили перед собой задачу создать платформу, с помощью которой команды смогут в конвейерном режиме создавать продукты как для внутренних пользователей, так и для внешних.
Мы назвали ее PoDT - Platform of Digital Transformation (Платформа Цифровой Трансформации).
С чего все начиналось: API Gateway
Первое, с чего мы начали, это тот самый «клей», который позволяет объединить старое и новое.
С помощью API Gateway мы научились связывать как модули нашей платформы, так и внутренние и внешние сервисы компании-клиента. На самом деле, именно с этого модуля и начался наш путь к созданию нашей платформы, так как часто у наших клиентов стояла задача как раз объединить Legacy и новые сервисы.
Эволюция платформы
У больших компаний много данных, которые необходимо правильно «складировать», правильно заполнять и регулярно использовать. Часто встречаются дубли в справочниках, неправильное заполнение полей и атрибутов, битые файлы. Поэтому весьма плавно и логично мы разработали свою MDM (систему по управлению мастер-данными) и ECM (система по управлению документами).
Внедрение только этих модулей в ряде кейсов позволяло сэкономить десятки миллионов рублей в год за счет централизации, дедупликации и нормализации данных. Частный кейс: если раньше составление отчетов по поставщикам могло занять несколько месяцев, то с новым модулем это время сократилось до нескольких недель.
Единая точка входа
Большая компания обретает конкурентное преимущество за счет постоянной оптимизации процессов. Например, внутренние данные компании и доступ к ним – весьма чувствительная тема. Поэтому доступ к каждому сервису обычно под паролем. Так как сервисов может быть достаточно много, то весьма неудобно и затратно постоянно вводить пару логин-пароль. Поэтому опять же весьма естественным образом появилась наша IDMка (система по управлению пользователями и правами доступа).
Модуль позволяет полностью настроить все права и доступы вплоть до отдельных атрибутов справочников системы, ну и разумеется – появляется функция единой точки входа (SSO), а значит, пользователю достаточно ввести пароль к своему ПК или ноутбуку, и он автоматически залогинится во всех необходимых сервисах.
Редактор бизнес-процессов (BPM движок)
Ну и конечно, никакая цифровая трансформация невозможна без инструментов автоматизации бизнес процессов.
Построенный на базе Camunda модуль позволяет выстроить все процессы на визуальном уровне и внедрить все стандарты в производство. Можно задать любую логику взаимодействия и последовательности: как простые ручные задачи, так и сложные иерархичные задачи с вложенными алгоритмами.
Вишенка на торте - единый интерфейс
Еще одна приятная особенность платформы в том, что внутренним пользователям не нужно переключаться между компонентами системы, ведь доступ ко всем модулям проводится через единый интерфейс.
Ускоряйте Time-2-Value и Time-2-Market в своей компании
И это все? Разумеется нет. Возможности платформы намного шире. Мы не даем закрытую экосистему, в которой нельзя ничего менять. Задумка платформы в том, чтобы дать максимальную гибкость командам разработки, избавив их от наиболее рутинных и дорогих разработок, таких как MDM, ECM, BPM – и сконцентрировались на самом важном. А самое важное – это быстро и предсказуемо разрабатывать сервисы, которые приносят дополнительную ценность для компании и ее клиентов.