С чего должна начинаться цифровая трансформация? На что надо обращать внимание в первую очередь? Как добиться того, чтобы она начала как можно быстрее приносить реальные результаты? Эти вопросы обсудили участники организованной CNews Conferences конференции «Цифровая трансформация 2019».

страницы:

Павел Ершов: Любая практика, ставшая «лучшей», дает все меньше конкурентного преимущества

Старые подходы к разработке, подразумевающие создание технического задания и строгое следование плану, уже не работают. А популярный Agile часто приводит к затягиванию работ. Выход – использование low-code платформ, уверен Павел Ершов, генеральный директор Directual.

CNews: Что такое цифровая трансформация, по вашему мнению?

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

На мой взгляд, все правы. Цифровизация — это максимальное использование цифровых каналов коммуникации для создания ценности. Это веб-сайты, мобильные приложения, боты в мессенджерах, IoT-системы и носимые устройства. Все эти продукты решают какую-то задачу, внутреннюю для компании или проблему клиента, с использованием цифровых технологий.

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

CNews: Что мешает цифровизации?

Павел Ершов: Размышляя о причинах срывов проектов по цифровизации, мы выделили два аспекта, на которые надо обращать внимание: методологический и технологический. Первое – о том, как построить процессы постановки целей, выбора проектов, работы над проектами, сбора обратной связи. Второе – о выборе подходящих технологий, которые смогут обеспечить процессы разработки продуктов и стать базой для их масштабирования.

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

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

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

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

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

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

Но в последние годы на рынке стали появляться так называемые low-code платформы, которые позволяют добиться гибкости разработки «с нуля», при этом показывая очень высокую скорость и надежность. Такие платформы — своего рода LEGO-конструкторы для сборки ИТ-систем. Правильное применение таких технологий — это путь к тому, чтобы проект цифровизации шел успешно, а эффект от него можно было получить уже в первые месяцы.

CNews: Как можно упросить и ускорить процесс?

Павел Ершов: Гибкие low-code платформы позволяют реализовать в рамках компании так называемую двухскоростную ИТ-архитектуру. Этот термин был введен компанией McKinsey. Он подразумевает, что базовые бизнес-процессы, которые уже автоматизированы и составляют основу бизнеса, работают на legacy-системах типа SAP, Oracle или 1С. Эти процессы меняются редко и требуют, в первую очередь, стабильности. Но все новые продукты требуют гибкости и скорости. Именно для них создается agile-слой из систем другого класса, low-code платформ. Этот слой интегрируется с существующим ИТ-ландшафтом, что позволяет использовать данные в новых продуктах.

Важной особенностью хороших low-code платформ является реализация микросервисной модели. При ней разные команды могут работать параллельно над своими продуктами, но все системы будут интегрированы через шину обмена данными. Это позволяет создавать единое информационное пространство со множеством эффективных продуктов. Эта самая эффективность достигается коротким циклом разработка-тестирование. В качестве примера можно привести автоматизацию HR-процессов. Можно создавать отдельными микросервисами продукты по автоматизации согласования отпуска, проведения перевода или оформления командировки. Но данные все продукты будут получать из базовой кадровой системы.

CNews: Какие ресурсы нужны?

Павел Ершов: Этот подход сближает ИТ-департамент и бизнес. На западе, где применение low-code подхода уже более распространено даже появился термин – citizen-developer. Это бизнес-аналитик, обладающий навыками работы с low-code инструментами. Благодаря тому, что обучение обычно занимает 1-2 недели, появление таких специалистов не является проблемой и в отечественных компаниях. Проектные команды обычно включают бизнес-заказчика, одного-двух аналитиков, специалиста по UI/UX и тестировщика. ИТ-ресурсы подключаются при необходимости создания новых интеграций.

В нашей практике ситуация обычно выглядит следующим образом. Мы поставляем клиенту low-code платформу Directual сразу с прицелом на 1-2 проекта, которые нужно реализовать как можно раньше. Вместе с платформой предоставляем полностью укомплектованную команду, которая вместе с бизнес-заказчиком создает первые продукты, параллельно обучая сотрудников клиента работе с платформой. Через 2-3 итерации продукты уже проходят боевое тестирование, которое приносит десятки новых идей, к реализации которых уже подключаются новые обученные аналитики. Таким образом, постепенно в компании создается центр создания инноваций, который начинает быстро приносить результат в виде работающих цифровых продуктов. По-сути, этот центр и становится двигателем цифровой трансформации компании.


страницы: