Создание B2B-портала или маркетплейса — важный шаг в цифровой трансформации бизнеса.
За последние два года команда kt.team реализовала шесть крупных проектов разработки B2B-порталов для логистических, производственных, торговых компаний. Часто заказчикам кажется, что создание B2B-портала — настолько сложный процесс, что к нему нужна особая подготовка. Но тормозить с разработкой тоже не хочется: зачем упускать потенциальную выгоду? Руководителей IT-отделов и владельцев бизнеса волнуют следующие вопросы.
- Конкуренты сделали B2B-портал, значит, и нам обязательно нужно? Это универсальное средство повысить продажи, привлечь новых клиентов, увеличить прибыль?
- Как составить техническое задание на разработку B2B-портала?
- Можно ли начинать разработку портала, если в компании пока нет автоматизации? Или нужно сперва навести порядок и упорядочить документооборот? Нужно ли оптимизировать бизнес-процессы заранее?
- В целом как эффективно подготовиться к разработке B2B-портала?
В статье разберёмся со всеми этими проблемами, и я предложу тот план действий, который — по нашему опыту — спасает IT-менеджмент от огромного количества проблем.
В2В-портал и B2B-маркетплейс представляют собой онлайн-площадки для оптовых покупателей. Сделать оптовый заказ на такой площадке почти так же легко, как купить продукты в розничном интернет-магазине. Конечно, есть и отличия, ведь в сфере B2B гораздо больше факторов ценообразования, сложнее документооборот и логистика и, например, поиск по артикулу используется чаще, чем по цвету или размеру.
Более подробно о том, как работают такие площадки, в чём их особенность и как они упрощают продажи, читайте в нашей недавней статье «Как B2B-портал избавляет маркетинг и менеджмент от головных болей: 9 примеров».
Зачем вам B2B-портал? О важности целеполагания
Цель разработки портала или маркетплейса должна быть максимально осознанной. Вариант «конкуренты сделали B2B-портал, значит, нам тоже нужно, причём срочно» — плохой.
Не стоит поддаваться карго-культу (в наиболее известных культах карго из кокосовых пальм и соломы строятся «точные копии» взлётно-посадочных полос, аэропортов и радиовышек. Последователи культа строят их, веря в то, что эти постройки привлекут транспортные самолёты (которые считаются посланниками духов), заполненные грузом) в надежде, что как только вы подготовите B2B-площадку, с неба посыпятся миллионы. Степень вашей технической и финансовой готовности может сильно отличаться от готовности конкурента. Разработка — это всегда большие затраты ресурсов: финансовых, трудовых, организационных. Сначала убедитесь при помощи юнит-экономики, что затраты на разработку окупятся, и составьте карту целей и влияния — Impact Map.
Допустим, один из руководителей компании в отдалённом регионе узнал, что компания-лидер в его отрасли сделала B2B-портал. Это вдохновило его, он «загорелся» и захотел сделать то же самое: оцифровать всё взаимодействие со своими оптовыми клиентами.
Но сейчас бизнес-процессы в его компании абсолютно не автоматизированы. Заказы делают по телефону, отгрузку оформляют вручную, а согласование распечатанного на бумаге приказа занимает две недели. Так делает большинство игроков рынка в его регионе, и его клиентам это кажется нормальным и даже удобным. Зачем ему цифровизация и, главное, как ему подступиться к работе с подрядчиком, чтобы потом не было мучительно больно? Инвестировать крупные суммы в IT-продукт ради самого продукта? Но как тогда оценивать успех разработки — неужели шкала для оценки будет содержать всего два значения («Сделано» или «Не сделано»)?
Когда у заказчика есть желание создать B2B-портал, но нет чётко сформулированной цели, зачем ему это нужно, стоит заняться целеполаганием с использованием метода Impact Mapping. Более подробно я писал об этом в статье «Impact Mapping, юнит-экономика и PDCA: грамотное управление разработкой e-Commerce». Метод Impact Mapping помогает чётко формулировать цели проекта в соответствии с целями всего бизнеса. Для этого нужно провести глубокий анализ и ответить на четыре главных вопроса.
1. Why?
Зачем нужен этот продукт? Какую задачу бизнеса он должен решить?
2. Who?
Кто может влиять на достижение этой цели?
3. How?
Что он может сделать, чтобы приблизить проект к бизнес-цели?
4. What?
Какие конкретные шаги должен сделать ответственный в рамках своих задач? Здесь нужно прописать подробный функционал для каждой задачи.
Владельцу бизнеса из этого примера я предложил бы провести две-три консультации на тему целеполагания. Когда он оцифрует свои цели и мы увидим ясные метрики проекта, будем обсуждать сотрудничество не абстрактно («хочу как у конкурента»), а конкретно («хочу получить результат, выраженный в количественных показателях Х и качественных показателях Y»). Более подробно о целевых показателях для B2B-портала мы поговорим в конце статьи.
Как составить техническое задание на разработку B2B-портала или B2B-маркетплейса?
При работе в парадигме Agile подробное ТЗ, на подготовку которого раньше заказчики тратили по полгода, не имеет смысла. Почему? Подробное объяснение читайте в статье моей коллеги Джеклин Баффо «MVP, или как не попасть в бесконечную разработку».
Мы придерживаемся гибких подходов к управлению разработкой и считаем, что перед созданием сложного софта нужно создать сначала MVP, протестировать его на реальных пользователях и только после этого «допиливать» и внедрять улучшайзинг. ТЗ — пустая трата времени и денег, а информация в нём устаревает уже в процессе написания. Пока заказчик пишет ТЗ, часть людей может уволиться, в бизнесе может многое измениться, само ваше видение идеала может стать совсем другим. В итоге спустя несколько месяцев вам приходит запрос на тестирование всего функционала, но не факт, что вы вообще помните, как он должен работать.
Пример
IT-компания разработала MVP (минимально жизнеспособную версию) B2B-портала для оптового поставщика и начала собирать обратную связь от ретейлеров, которые были достаточно лояльны к этому поставщику и согласились поучаствовать в тестах.
Оказалось, что ретейлеры — клиенты платформы выбирают товар и собирают его в партии не совсем так, как представлял себе заказчик.
Например, при оформлении заказа им важно контролировать загруженность фуры. Но как именно это должно быть реализовано с точки зрения функционала платформы? Всегда ли клиент располагает данными о точном типе фуры, предельной загрузке и т. д.? Все эти детали неочевидны на старте проекта — они будут выявлены, уточнены и улучшены уже после выхода MVP в процессе реального взаимодействия IT-продукта и конечного пользователя.
В результате разработчики внесли необходимые изменения и доработки, выявленные именно в результате получения живой обратной связи, а не чьих-то устаревших гипотез, зафиксированных в ТЗ. И после релиза портал получил высокий NPS от пользователей (индекс потребительской лояльности). В этом кейсе и команда, и заказчик очень хорошо прочувствовали на себе, каких потерь помогает избежать MVP и насколько важно получать быструю обратную связь о продукте.
Нужно ли пересматривать все свои бизнес-процессы и оптимизировать их до того, как обращаться к разработчикам?
Делать это заранее не нужно. В процессе разработки B2B-портала всё равно происходит ревизия, пересмотр, оптимизация всех бизнес-процессов. Мы работаем в запутанных средах, где нам нужно понимать текущее местоположение, желаемую конечную точку и в каждом спринте отталкиваться не от фич, а от изменения метрик, и после постановки цели формировать задачи, проверять изменение метрик.
B2B-портал — это производная большой сложной трансформации.
Что такое создание B2B-портала? Это попытка оптимизировать некоторые процессы: лучше узнать своего клиента, уменьшить затраты на операционную обработку, повысить качество сервиса за счёт лучшей организации труда.
Результат можно выразить в следующих количественных метриках:
- увеличение частоты заказов (вспомните себя — наверняка вы тоже чаще покупаете в том онлайн-магазине и чаще заказываете такси в том приложении, где есть автозаполнение форм и уже привязана ваша карта. B2B-закупки тоже совершают люди, а не роботы, которые при прочих равных условиях предпочтут быстрый и лёгкий заказ);
- оптимизация структуры заказов (продавец может стимулировать спрос на товары выгодным ему образом: люди часто заказывают то, что рекомендует система, а не то, что они привыкли заказывать);
- повышение прибыли за счёт дополнительных сервисов (сопровождение тендеров, финансовые, юридические услуги и т. д.).
Просто технической реализацией «сайта с ЭДО/EDI» ни один портал не ограничивается. В процессе разработки 100 % будет множество процессов, которые придётся улучшать по ходу действия. Но ускорение движения не происходит за счёт увеличения количества задач.
Главное — выбор правильных приоритетов.
Определять приоритеты помогает PDCA-цикл, смысл которого прост: выберите метрики, которые хотите изменять, убедитесь в их сбалансированности (количество/качество), декомпозируйте при необходимости на более узкие метрики, которые можно изменить в рамках спринта, выберите задачи для их изменения, которые поместятся в спринт, проверьте метрики и научитесь (получите опыт — изменились ли метрики или нет).
Пример
Вы внедрили B2B-портал, но в процессе использования у вас не улучшилась ни одна метрика, и каждый менеджер продолжает вручную обрабатывать данные из электронных форм.
Так происходит, потому что, когда посетитель заполняет форму регистрации на B2B-портале, его электронная почта попадает к сотруднику, который должен зайти на сайт и вручную добавить этого пользователя на B2B-портал. Получается, метрика качества (коэффициент загрузки менеджера) осталась прежней или даже ухудшилась. Как только это обнаружено, в ближайшем спринте нужно сделать так, чтобы клиенты регистрировались самостоятельно. Так эта метрика будет улучшаться.
Подведём итоги. Пересматривать бизнес-процессы до автоматизации:
- затруднительно (и всё равно в процессе снова потребуются изменения);
- неэффективно с точки зрения бережливого производства, т. к. эти действия не дают результата сейчас, это потери.
Главное — определить метрики и уже по ходу дела менять бизнес-процессы, чтобы изменения происходили вместе с разработкой согласно циклу Деминга.
Внедрение B2B-портала, как правило, имеет целью улучшение культуры управления, оптимизацию бизнес-процессов. Это ещё один довод в пользу того, что пересматривать бизнес-процессы нужно вместе со всеми целями и метриками.
Мы рассмотрели основные ошибки, которые мешают заказчику правильно подготовиться к разработке B2B-портала. Избежать этих ошибок вам поможет пошаговый план подготовки — им мы поделимся во второй части статьи.
.png)
