Метод параноика. Принципы создания цифровых продуктов для бизнеса в условиях неопределенности

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

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

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

Второй путь – это заимствовать бизнес-модель у аналогичных компаний и использовать проверенные технологические системы и решения (тип «Седина»). В этом случае необходимо привлекать специалистов с опытом создания подобных цифровых сервисов. Если используются существующие продукты, степень неопределенности низкая и можно точно оценить стоимость и сроки проекта. В то же время неопределенность возрастает, если бизнес-модель готова, но для ее реализации требуется создание нового технологического продукта, хотя и аналогичного тем, что работают у конкурентов. Если за такой проект возьмутся специалисты без опыта в этой области, то для них задача будет иметь тип «Мозги», что не позволит им спрогнозировать объем и сложность работ.

Выбор способа запуска нового направления определяется амбициями и стратегией развития бизнеса. Если речь идет о венчурных компаниях и стартапах, которые делают ставку на инновации и отрыв от конкурентов, то проект типа «Мозги» оправдан. Для бизнеса с другими способами привлечения заказов предпочтительнее вариант с использованием уже проверенных цифровых инструментов и решений, конечно если они существуют в данной отрасли.

Работающий бизнес, развивающий свои цифровые сервисы

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

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

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

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