Можно ли подготовить бизнес к цифровой трансформации и зачем это делать: гайд и кейсы на примере создания 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 помогает чётко формулировать цели проекта в соответствии с целями всего бизнеса. Для этого нужно провести глубокий анализ и ответить на четыре главных вопроса.
- Why? Зачем нужен этот продукт? Какую задачу бизнеса он должен решить?
- Who? Кто может влиять на достижение этой цели?
- How? Что он может сделать, чтобы приблизить проект к бизнес-цели?
- What? Какие конкретные шаги должен сделать ответственный в рамках своих задач? Здесь нужно прописать подробный функционал для каждой задачи.
Владельцу бизнеса из этого примера я предложил бы провести две-три консультации на тему целеполагания. Когда он оцифрует свои цели и мы увидим ясные метрики проекта, будем обсуждать сотрудничество не абстрактно («хочу как у конкурента»), а конкретно («хочу получить результат, выраженный в количественных показателях Х и качественных показателях Y»). Более подробно о целевых показателях для B2B-портала мы поговорим в конце статьи.
2. Как составить техническое задание на разработку B2B-портала или B2B-маркетплейса?
При работе в парадигме Agile подробное ТЗ, на подготовку которого раньше заказчики тратили по полгода, не имеет смысла. Почему? Подробное объяснение читайте в статье моей коллеги Джеклин Баффо «MVP, или как не попасть в бесконечную разработку».
Мы придерживаемся гибких подходов к управлению разработкой и считаем, что перед созданием сложного софта нужно создать сначала MVP, протестировать его на реальных пользователях и только после этого «допиливать» и внедрять улучшайзинг. ТЗ — пустая трата времени и денег, а информация в нём устаревает уже в процессе написания. Пока заказчик пишет ТЗ, часть людей может уволиться, в бизнесе может многое измениться, само ваше видение идеала может стать совсем другим. В итоге спустя несколько месяцев вам приходит запрос на тестирование всего функционала, но не факт, что вы вообще помните, как он должен работать.
Пример
IT-компания разработала MVP (минимально жизнеспособную версию) B2B-портала для оптового поставщика и начала собирать обратную связь от ретейлеров, которые были достаточно лояльны к этому поставщику и согласились поучаствовать в тестах.
Оказалось, что ретейлеры — клиенты платформы выбирают товар и собирают его в партии не совсем так, как представлял себе заказчик.
Например, при оформлении заказа им важно контролировать загруженность фуры. Но как именно это должно быть реализовано с точки зрения функционала платформы? Всегда ли клиент располагает данными о точном типе фуры, предельной загрузке и т. д.? Все эти детали неочевидны на старте проекта — они будут выявлены, уточнены и улучшены уже после выхода MVP в процессе реального взаимодействия IT-продукта и конечного пользователя.
В результате разработчики внесли необходимые изменения и доработки, выявленные именно в результате получения живой обратной связи, а не чьих-то устаревших гипотез, зафиксированных в ТЗ. И после релиза портал получил высокий NPS от пользователей (индекс потребительской лояльности). В этом кейсе и команда, и заказчик очень хорошо прочувствовали на себе, каких потерь помогает избежать MVP и насколько важно получать быструю обратную связь о продукте.
3. Нужно ли пересматривать все свои бизнес-процессы и оптимизировать их до того, как обращаться к разработчикам?
Делать это заранее не нужно. В процессе разработки B2B-портала всё равно происходит ревизия, пересмотр, оптимизация всех бизнес-процессов. Мы работаем в запутанных средах, где нам нужно понимать текущее местоположение, желаемую конечную точку и в каждом спринте отталкиваться не от фич, а от изменения метрик, и после постановки цели формировать задачи, проверять изменение метрик.
B2B-портал — это производная большой сложной трансформации. Что такое создание B2B-портала? Это попытка оптимизировать некоторые процессы: лучше узнать своего клиента, уменьшить затраты на операционную обработку, повысить качество сервиса за счёт лучшей организации труда.
Результат можно выразить в следующих количественных метриках:
- увеличение частоты заказов (вспомните себя — наверняка вы тоже чаще покупаете в том онлайн-магазине и чаще заказываете такси в том приложении, где есть автозаполнение форм и уже привязана ваша карта. B2B-закупки тоже совершают люди, а не роботы, которые при прочих равных условиях предпочтут быстрый и лёгкий заказ);
- оптимизация структуры заказов (продавец может стимулировать спрос на товары выгодным ему образом: люди часто заказывают то, что рекомендует система, а не то, что они привыкли заказывать);
- повышение прибыли за счёт дополнительных сервисов (сопровождение тендеров, финансовые, юридические услуги и т. д.).
Просто технической реализацией «сайта с ЭДО/EDI» ни один портал не ограничивается. В процессе разработки 100% будет множество процессов, которые придётся улучшать по ходу действия. Но ускорение движения не происходит за счёт увеличения количества задач. Главное — выбор правильных приоритетов.
Определять приоритеты помогает PDCA-цикл, смысл которого прост: выберите метрики, которые хотите изменять, убедитесь в их сбалансированности (количество/качество), декомпозируйте при необходимости на более узкие метрики, которые можно изменить в рамках спринта, выберите задачи для их изменения, которые поместятся в спринт, проверьте метрики и научитесь (получите опыт — изменились ли метрики или нет).
Пример
Вы внедрили B2B-портал, но в процессе использования у вас не улучшилась ни одна метрика, и каждый менеджер продолжает вручную обрабатывать данные из электронных форм.
Так происходит, потому что, когда посетитель заполняет форму регистрации на B2B-портале, его электронная почта попадает к сотруднику, который должен зайти на сайт и вручную добавить этого пользователя на B2B-портал. Получается, метрика качества (коэффициент загрузки менеджера) осталась прежней или даже ухудшилась. Как только это обнаружено, в ближайшем спринте нужно сделать так, чтобы клиенты регистрировались самостоятельно. Так эта метрика будет улучшаться.
Подведём итоги. Пересматривать бизнес-процессы до автоматизации:
- затруднительно (и всё равно в процессе снова потребуются изменения);
- неэффективно с точки зрения бережливого производства, т. к. эти действия не дают результата сейчас, это потери.
Главное — определить метрики и уже по ходу дела менять бизнес-процессы, чтобы изменения происходили вместе с разработкой согласно циклу Деминга.
Внедрение B2B-портала, как правило, имеет целью улучшение культуры управления, оптимизацию бизнес-процессов. Это ещё один довод в пользу того, что пересматривать бизнес-процессы нужно вместе со всеми целями и метриками.
4. Итог: пошаговый план действий по подготовке к разработке B2B-портала
Итак, мы с вами обсудили типичные заблуждения относительно цифровизации B2B-бизнеса. Если думать, что залог успеха — это подробное ТЗ и перевод рутинных действий в онлайн, результат может сильно разочаровать. Такая подготовка бизнесу не нужна!
Главная часть подготовки к цифровой трансформации со стороны заказчика — целеполагание. Надо определиться с целями компании в целом, определить количественные и качественные метрики и декомпозировать их на задачи.
Для этого нужна экспертиза и определённые усилия. В первую очередь стоит задуматься о развитии собственной команды в этом направлении, росте внутренней экспертизы. И, конечно, постараться выстраивать такие взаимоотношения с IT-подрядчиком, которые позволят вам вместе заниматься не разработкой ради разработки, а продуктом, каждая часть функционала в котором приближает вас к достижению бизнес-цели.
Порядок действий при подготовке к разработке B2B-портала будет следующим.
Шаг первый. Расчёт юнит-экономики всего проекта
Одной из новых строк будет гипотеза «Разработка B2B-портала», и вам нужно будет оценить, как она повлияет на столбцы «Доход» и Gross Profit.
Пример простого юнит-калькулятора в формате XLS и инструкции к нему смотрите здесь.
Если юнит-калькулятор показывает, что изменение конверсии даже на 0,01 % даст значимый финансовый результат, то начинать улучшения стоит с самых узких мест воронки продаж. И не факт, что влиять на это будет именно автоматизация бизнес-процессов — возможно, лучше оптимизировать что-то другое.
Шаг второй. Построение целей верхнего уровня и карты влияния (Impact Map)
Метод Impact Mapping помогает чётко формулировать цели проекта в соответствии с целями всего бизнеса в разрезе ролей. Для этого нужно построить интеллект-карту с ответами на четыре главных вопроса.
- Зачем нужен этот продукт? Какую задачу бизнеса он должен решить?
- Кто влияет на достижение этой цели?
- Что он может сделать?
- Какие конкретные шаги в рамках целей ему нужно сделать?
Шаг третий. Декомпозиция целей на задачи
1. Выбрать показатели, которые мы будем отслеживать в качестве процесса и на которые команда будет ориентироваться.
2. Определить итеративность — минимально возможный период поставки новых ценностей в продукте. Как правило, это зависит от бюрократических возможностей. Если владелец продукта доступен и уделяет много времени проекту, то это могут быть недельные спринты. Но если функционал сложный либо клиент вынужден постоянно отвлекаться от проекта, то это две недели и более на один цикл.
Цикл определяется тем, как мы можем поставить ценность и оценить её. Например, с помощью количественных метрик:
- количество автоматизированных операций;
- количество операций, переведённых в новую систему;
- количество коммуникаций без оператора;
- процент пользователей B2B-портала или B2B-маркетплейса от общего числа клиентов организации (пример значений: из 2000 клиентов сейчас пользуются порталом 0 человек, а наша цель — 1000 человек).
Мы перечислили количественные метрики, нужно уравновесить их качественными:
- количество повторных операций (клиент один раз с трудом оформил заказ и больше не будет пользоваться);
- время прохождения одной заявки, покупки, совершения сделки;
- процент использования;
- уровень удовлетворённости клиента и его готовности рекомендовать компанию (NPS).
Шаг четвёртый. Выбор лиц, которые могут быть decision maker'ами
Это владельцы не только самого продукта, но и смежных систем. Обычно B2B-портал тесно интегрирован с другими ИС (ERP, CRM и т. д.), и кто-то должен быть назначен ответственным за взаимодействие с ними. При этом все лица, принимающие решения, должны ориентироваться на один общий параметр, все отделы должны быть заинтересованы в этом параметре и физически включены в проект. Ответственность за сбор этих метрик, их обсуждение и утверждение с командой несёт владелец продукта.
Шаг пятый. Начало разработки
Часто случается так, что если система, например, состоит из шести частей, то все части начинают реализовывать последовательно: первая, вторая, третья и т. д. Это неправильно — нужно работать над ними одновременно и пытаться сделать MVP, т. е. такую систему, которой можно было бы пользоваться как можно раньше. Пусть это будет очень простая реализация с большими допущениями, но уже через месяц она будет доведена до ума, потому что нужно как можно раньше получить полноценную обратную связь. Разработка ведётся с учётом циклов Деминга с регулярным пересмотром целей и метрик.
И никакого технического задания.
Я — за ориентацию на бизнес-показатели в планировании разработки.
Главное в подготовке портала или маркетплейса не то, как вы напишете ТЗ и напишете ли его вообще. Например, нам бы оно не понадобилось.
И не то, как быстро вы успеете пересмотреть свои бизнес-процессы, чтобы разработка прошла легче и эффективнее (от этого она легче и эффективнее не станет).
Главное — понимание цели и окупаемость этого продукта.