Можно ли подготовить бизнес к цифровой трансформации и зачем это делать: гайд и кейсы на примере создания b2b-портала

Меня зовут Андрей Путин, я управляющий партнёр kt.team. В разработке уже более 19 лет: начинал как интернет-провайдер, далее был техническим директором на стороне клиента, а последние шесть лет — партнёр-собственник ИТ-компании.

Создание b2b-портала или маркетплейса — важный шаг в цифровой трансформации бизнеса. За последние два года мы реализовали шесть крупных проектов разработки B2B-порталов для логистических, производственных, торговых компаний. Часто заказчикам кажется, что создание B2B-портала — настолько сложный процесс, что к нему нужна особая подготовка. Но тормозить с разработкой тоже не хочется: зачем упускать потенциальную выгоду? Руководителей IT-отделов и владельцев бизнеса волнуют следующие вопросы.

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

Цель разработки портала или маркетплейса должна быть максимально осознанной. Вариант «конкуренты сделали B2B-портал, значит, нам тоже нужно, причём срочно» — плохой.

Не стоит поддаваться карго-культу в надежде, что как только вы подготовите B2B-площадку, с неба посыпятся миллионы. Степень вашей технической и финансовой готовности может сильно отличаться от готовности конкурента. Разработка — это всегда большие затраты ресурсов: финансовых, трудовых, организационных. Сначала убедитесь при помощи юнит-экономики, что затраты на разработку окупятся, и составьте карту целей и влияния — Impact Map.

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

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

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

Метод Impact Mapping помогает чётко формулировать цели проекта в соответствии с целями всего бизнеса. Для этого нужно провести глубокий анализ и ответить на четыре главных вопроса.

Владельцу бизнеса из этого примера я предложил бы провести две-три консультации на тему целеполагания. Когда он оцифрует свои цели и мы увидим ясные метрики проекта, будем обсуждать сотрудничество не абстрактно («хочу как у конкурента»), а конкретно («хочу получить результат, выраженный в количественных показателях Х и качественных показателях Y»). Более подробно о целевых показателях для B2B-портала мы поговорим в конце статьи.

При работе в парадигме Agile подробное ТЗ, на подготовку которого раньше заказчики тратили по полгода, не имеет смысла. Почему? Подробное объяснение читайте в статье моей коллеги Джеклин Баффо «MVP, или как не попасть в бесконечную разработку».

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

IT-компания разработала MVP (минимально жизнеспособную версию) B2B-портала для оптового поставщика и начала собирать обратную связь от ретейлеров, которые были достаточно лояльны к этому поставщику и согласились поучаствовать в тестах.

Оказалось, что ретейлеры — клиенты платформы выбирают товар и собирают его в партии не совсем так, как представлял себе заказчик.

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

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

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

B2B-портал — это производная большой сложной трансформации. Что такое создание B2B-портала? Это попытка оптимизировать некоторые процессы: лучше узнать своего клиента, уменьшить затраты на операционную обработку, повысить качество сервиса за счёт лучшей организации труда.

Результат можно выразить в следующих количественных метриках:

Просто технической реализацией «сайта с ЭДО/EDI» ни один портал не ограничивается. В процессе разработки 100% будет множество процессов, которые придётся улучшать по ходу действия. Но ускорение движения не происходит за счёт увеличения количества задач. Главное — выбор правильных приоритетов.

Определять приоритеты помогает PDCA-цикл, смысл которого прост: выберите метрики, которые хотите изменять, убедитесь в их сбалансированности (количество/качество), декомпозируйте при необходимости на более узкие метрики, которые можно изменить в рамках спринта, выберите задачи для их изменения, которые поместятся в спринт, проверьте метрики и научитесь (получите опыт — изменились ли метрики или нет).

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

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

Подведём итоги. Пересматривать бизнес-процессы до автоматизации:

Главное — определить метрики и уже по ходу дела менять бизнес-процессы, чтобы изменения происходили вместе с разработкой согласно циклу Деминга.

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

Итак, мы с вами обсудили типичные заблуждения относительно цифровизации B2B-бизнеса. Если думать, что залог успеха — это подробное ТЗ и перевод рутинных действий в онлайн, результат может сильно разочаровать. Такая подготовка бизнесу не нужна!

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

Одной из новых строк будет гипотеза «Разработка B2B-портала», и вам нужно будет оценить, как она повлияет на столбцы «Доход» и Gross Profit.

Пример простого юнит-калькулятора в формате XLS и инструкции к нему смотрите здесь.

Если юнит-калькулятор показывает, что изменение конверсии даже на 0,01 % даст значимый финансовый результат, то начинать улучшения стоит с самых узких мест воронки продаж. И не факт, что влиять на это будет именно автоматизация бизнес-процессов — возможно, лучше оптимизировать что-то другое.

Метод Impact Mapping помогает чётко формулировать цели проекта в соответствии с целями всего бизнеса в разрезе ролей. Для этого нужно построить интеллект-карту с ответами на четыре главных вопроса.

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

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

Цикл определяется тем, как мы можем поставить ценность и оценить её. Например, с помощью количественных метрик:

Мы перечислили количественные метрики, нужно уравновесить их качественными:

Это владельцы не только самого продукта, но и смежных систем. Обычно B2B-портал тесно интегрирован с другими ИС (ERP, CRM и т. д.), и кто-то должен быть назначен ответственным за взаимодействие с ними. При этом все лица, принимающие решения, должны ориентироваться на один общий параметр, все отделы должны быть заинтересованы в этом параметре и физически включены в проект. Ответственность за сбор этих метрик, их обсуждение и утверждение с командой несёт владелец продукта.

Часто случается так, что если система, например, состоит из шести частей, то все части начинают реализовывать последовательно: первая, вторая, третья и т. д. Это неправильно — нужно работать над ними одновременно и пытаться сделать MVP, т. е. такую систему, которой можно было бы пользоваться как можно раньше. Пусть это будет очень простая реализация с большими допущениями, но уже через месяц она будет доведена до ума, потому что нужно как можно раньше получить полноценную обратную связь. Разработка ведётся с учётом циклов Деминга с регулярным пересмотром целей и метрик.

И никакого технического задания.

Я — за ориентацию на бизнес-показатели в планировании разработки.

Главное в подготовке портала или маркетплейса не то, как вы напишете ТЗ и напишете ли его вообще. Например, нам бы оно не понадобилось.

И не то, как быстро вы успеете пересмотреть свои бизнес-процессы, чтобы разработка прошла легче и эффективнее (от этого она легче и эффективнее не станет).

Главное — понимание цели и окупаемость этого продукта.