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

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

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

  • Конкуренты сделали B2B-портал, значит, и нам обязательно нужно? Это универсальное средство повысить продажи, привлечь новых клиентов, увеличить прибыль?
  • Как составить техническое задание на разработку B2B-портала?
  • Можно ли начинать разработку портала, если в компании пока нет автоматизации? Или нужно сперва навести порядок и упорядочить документооборот? Нужно ли оптимизировать бизнес-процессы заранее?
  • В целом как эффективно подготовиться к разработке B2B-портала?

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

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

1. Зачем вам 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-портала мы поговорим в конце статьи.

2. Как составить техническое задание на разработку B2B-портала или B2B-маркетплейса?

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

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

Пример

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

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

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

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

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

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

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

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

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

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

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

PDCA-цикл для определения приоритетов

Пример

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

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

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

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

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

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

4. Итог: пошаговый план действий по подготовке к разработке B2B-портала

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

Главная часть подготовки к цифровой трансформации со стороны заказчика — целеполагание. Надо определиться с целями компании в целом, определить количественные и качественные метрики и декомпозировать их на задачи.

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

Порядок действий при подготовке к разработке B2B-портала будет следующим.

Шаг первый. Расчёт юнит-экономики всего проекта

​Пример простого юнит-калькулятора

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

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

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

Шаг второй. Построение целей верхнего уровня и карты влияния (Impact Map)

Пример Impact Mapping

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

  1. Зачем нужен этот продукт? Какую задачу бизнеса он должен решить?
  2. Кто влияет на достижение этой цели?
  3. Что он может сделать?
  4. Какие конкретные шаги в рамках целей ему нужно сделать?

Шаг третий. Декомпозиция целей на задачи

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

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

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

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

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

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

Шаг четвёртый. Выбор лиц, которые могут быть decision maker'ами

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

Шаг пятый. Начало разработки

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

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

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

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

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

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

0
13 комментариев
Написать комментарий...
Николай Цыганов

[шутка про фамилию]

Ответить
Развернуть ветку
Maxim Gubin

мастерски ты место зарезервировал! 

Ответить
Развернуть ветку
Artem Rudi

Ничего личного, минус не вам, минус путину.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Олег

Вам точно

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Олег

Очень просто.

Ответить
Развернуть ветку
Сергей Шаболов

А вы случаем не родственник путина?

Ответить
Развернуть ветку
Dmitry Frolov

Очевидно, что Путин его отец... но не тот, скорее всего :)

Ответить
Развернуть ветку
Dmitry Frolov

Подскажите, а как быть с ценообразованием? Ну если на старте объём работ ещё не понятен, то как платит заказчик? По времени разработки?

Ответить
Развернуть ветку
Андрей Путин
Автор

Дмитрий,

Agile гласит что команда производит за спринт ценность, которая согласована в цифровом эквиваленте с заказчиком (у задачи две оценки - Value, Story Points, т.е. ценность и "сложность", желательно числами Фибоначчи).

Как правило, команда может сказать какую ценность за какое количество месяцев она может поставить. Это и является "фиксированной" стоимостью: стоимость команды умножается за это время.

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

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

Ответить
Развернуть ветку
Олег

Доводить заказ до ума и попытаться вновь не просто же так отказался.

Ответить
Развернуть ветку
Илья Щербаков

Когда зашел в комменты почитать шутки про фамилию

Ответить
Развернуть ветку
10 комментариев
Раскрывать всегда