Как подготовить бизнес к цифровой трансформации

Нужно ли оптимизировать бизнес-процессы заранее

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

Пример

ов».

Допустим, один из руководителей компании в отдалённом регионе узнал, что компания-лидер в его отрасли сделала B2B-портал. Это вдохновило его, он «загорелся» и захотел сделать то же самое: оцифровать всё взаимодействие со своими оптовыми клиентами. Но сейчас бизнес-процессы в его компании абсолютно не автоматизированы. Заказы делают по телефону, отгрузку оформляют вручную, а согласование распечатанного на бумаге приказа занимает две недели.

Так делает большинство игроков рынка в его регионе, и его клиентам это кажется нормальным и даже удобным. Зачем ему цифровизация и, главное, как ему подступиться к работе с подрядчиком, чтобы потом не было мучительно больно? Инвестировать крупные суммы в IT-продукт ради самого продукта? Но как тогда оценивать успех разработки - неужели шкала для оценки будет содержать всего два значения («Сделано» или «Не сделано»)?

Когда у заказчика есть желание создать B2B-портал, но нет чётко сформулированной цели, зачем ему это нужно, стоит заняться целеполаганием с использованием метода Impact Mapping. Более подробно я писал об этом в статье «Impact Mapping, юнит-экономика и PDCA: грамотное управление разработкой e-Commerce». Метод Impact Mapping помогает чётко формулировать цели проекта в соответствии с целями всего бизнеса. Для этого нужно провести глубокий анализ и ответить на четыре главных вопроса.

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

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

Все эти детали неочевидны на старте проекта - они будут выявлены, уточнены и улучшены уже после выхода MVP в процессе реального взаимодействия IT-продукта и конечного пользователя. В результате разработчики внесли необходимые изменения и доработки, выявленные именно в результате получения живой обратной связи, а не чьих-то устаревших гипотез, зафиксированных в ТЗ. И после релиза портал получил высокий NPS от пользователей (индекс потребительской лояльности).

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

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

B2B-закупки тоже совершают люди, а не роботы, которые при прочих равных условиях предпочтут быстрый и лёгкий заказ); - оптимизация структуры заказов (продавец может стимулировать спрос на товары выгодным ему образом: люди часто заказывают то, что рекомендует система, а не то, что они привыкли заказывать); - повышение прибыли за счёт дополнительных сервисов (сопровождение тендеров, финансовые, юридические услуги и т. д.).