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

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

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

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

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

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

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

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

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

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

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

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

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «