Код успеха: как выбрать подход к цифровизации бизнеса
Какое решение выбрать
Компании, которые способны быстро меняться и запускать новые сервисы, более конкурентоспособны в современном мире. Поэтому все больше организаций понимают важность цифровой трансформации (Digital Transformation, DX) для достижения успеха. В процессе цифровизации IT-системы играют роль транспортных магистралей: они либо поддерживают быстрые изменения, либо становятся бутылочным горлышком. Зачем приступать к этому процессу и какое техническое решение выбрать, рассказала Mind VP Delivery Management, Innovecs, Наталья Зуб.
Рынок DX в цифрах
Согласно Gartner, расходы на цифровую трансформацию достигнут $3,9 трлн к концу 2021 года, а COVID продолжит быть главным катализатором изменений. Ожидается, что среднегодовой темп роста рынка DX составит 23% за период с 2019 по 2023 год.
Наглядный пример успешной цифровизации внутренних бизнес-процессов демонстрирует ŠKODA AUTO HR. Компания экономит более 40% времени на подбор персонала после внедрения виртуального помощника на базе сервисов IBM Watson.
Но не все кейсы диджитализации столь же эффектны: по данным Everest Group, 73% компаний не увидели какой-либо ценности для бизнеса после завершения цифровой трансформации.
Даже крупные компании порой терпят неудачи в процессе DX. Так, корпорация General Electric начала создавать свою IoT-платформу еще в 2011 году. Несмотря на то что гигант потратил миллиарды долларов на масштабные изменения, цена акций неумолимо падала, что сказывалось на многих операционных сегментах.
Очевидно, что не существует единого протокола, по которому можно было бы провести Digital Transformation в абстрактной компании в вакууме. Мир бизнеса меняется так стремительно, что традиционные подходы начинают устаревать еще до момента практического внедрения.
Однако можно выделить наиболее частые причины неудач цифровизации компании, среди которых:
- работа без четких целей;
- непонимание руководством важности изменений;
- отсутствие опыта;
- фокус только на технологиях.
Подведем итог: на кейсы надейся, а сам не плошай.
Выбор технического решения для DX
Обычно компании выбирают один из описанных ниже путей.
Коробочное решение
Из плюсов – относительно быстрое развертывание. Но стоит учесть, что дальше все модификации будут зависеть от провайдера. Не всегда третья сторона заинтересована в оперативных изменениях, которые, возможно, будут критически важны для бизнеса.
Самописная система
Путь разработки с нуля – всегда долгий и опасный, даже для компании, специализирующейся на создании автоматизированных софтверных систем. Существует риск получить к концу затянувшейся разработки морально устаревший продукт.
Услуги аутсорсера
Стоит рассматривать такой вариант только в том случае, если у внутренней команды есть планы развить компетенции Product Owner. Ни одна аутсорс-компания не может вникнуть абсолютно во все процессы и не будет идеально изучать бизнес-домен. Максимум, на который стоит рассчитывать: подрядчик предоставит команду и наладит процесс разработки. А дальше – черед компании-заказчика.
Готовые SaaS-решения
Если каждый отдельный департамент будет использовать свое решение, в итоге велика вероятность получить разрозненные модули, а не единую экосистему. В результате сквозная аналитика с зависимостями так и останется мечтой, цифровая трансформация замаскируется под автоматизацию и возникнет необходимость нового интеграционного проекта. Такая интеграция скорее всего обойдется в несколько раз дороже изначальных изменений.
Оптимальный комбинированный вариант
Идеальное решение компании следует собрать индивидуально под свои потребности – как конструктор.
Для зрелых бизнес-процессов стоит использовать коробочное решение или SaaS, для уникальных или недостающих – написать небольшие приложения самостоятельно.
Подумать о единой централизованной базе данных. В большинстве случаев подойдет Data Warehouse – корпоративное хранилище данных, разработку которого вполне безопасно отдать на аутсорс.
Если внешние и внутренние условия позволяют, то интеграционный проект лучше запустить до выбора систем. А выбор позволить сделать инженерам, а не руководителям отделов.
По моему опыту, эти процессы хорошо «параллелятся», и реализация занимает не дольше года. При этом самое ценное – данные и компетенция – накапливается внутри компании.
Подход к постановке задачи и внедрению
Рассмотрим наиболее распространенные подходы к процессу разработки, а также их достоинства и риски.
Попытка формализовать 100% требований
Даже если задаться целью и четко описать все требования и структуры данных, к сожалению, предусмотреть все нюансы не получится. Вместо этого документация загонит разработчиков в жесткие рамки и перекроет дорогу более удачным решениям.
Гибкая методология разработки
Метод Agile предполагает в конце каждого спринта запуск потенциально готового к поставке инкремента продукта – shippable product increment. В случае цифровизации корпоративных процессов такой подход сложно реализовать, ведь отделить shippable increment практически невозможно, не нарушив жизненно важных взаимосвязей.
Гибкая разработка всего продукта целиком
Этого слона нужно есть не частями, а слоями, то есть необходимо работать с неделимой системой. Результат такой разработки можно описать терминами PoC (дословно – proof of concept, «проверка концепции») и MVP (minimum viable product, «минимально жизнеспособный продукт»). Первый слой можно получить, описав один жизненный цикл продукта, проекта или функционала сотрудника.
Для прояснения детальных требований у будущих пользователей оптимально подойдет метод Design Driven Development. Подход подразумевает, что сначала рисуется интерфейс, который тестируют в реальной обстановке, и только затем инженеры разрабатывают функционал. Эта концепция работы над продуктом экономит массу времени, ведь обратная связь может быть получена до этапов утверждения функционала, разработки, тестирования, внедрения и обучения.
Самое главное – помнить: проще поменять что-то в процессе, чем нагромождать очередной костыль к существующей сложной системе. Тогда не придется ждать «полный автомат» за миллион и через год, когда «полуавтомат» можно запустить с приемлемым бюджетом уже через месяц.
Авторы материалов OpenMind, как правило, внешние эксперты и специалисты, которые готовят материал по заказу редакции. Но их точка зрения может не совпадать с точкой зрения редакции Mind.
В то же время редакция несёт ответственность за достоверность и соответствие реальности изложенной мысли, в частности, осуществляет факт-чекинг приведенных утверждений и первичную проверку автора.
Mind также тщательно выбирает темы и колонки, которые могут быть опубликованы в разделе OpenMind, и обрабатывает их в соответствии со стандартами редакции.
