В2В-порталы: как сделать так, чтобы не получился грандиозный фейл
Зачем компаниям, работающим в В2В сегменте, создавать порталы для клиентов, партнеров и сотрудников, что это дает бизнесу, и как минимизировать риски неудач в таких проектах, — об этом поговорили Александр Руднев, управляющий партнер компании OmniLine, и Егор Головнин, руководитель проектов компании Industrial Information Technologies.
Александр Руднев: Для начала ответим на вопрос: зачем вообще компаниям порталы? Во-первых, чтобы стать ближе к клиентам. Они сокращают цепочки продаж, убирают звенья субдистрибуции и становятся основной точкой контакта со всеми своими клиентами. Во-вторых, для сокращения затрат на дорогие в эксплуатации офлайн-каналы продаж — офисы, шоу-румы и пр. Да и быть в офлайне сейчас не всегда получается — из-за эпидемиологической обстановки. В-третьих, повышение эффективности за счет снижения других затрат, например, на оплату работы менеджеров.
Плюс — желание быть в тренде и хайпануть на цифровой трансформации. Классические компании хотят быть цифровыми. Они смотрят на топовые компании и хотят быть хоть в чем-то на них похожими.
Егор, а на твой взгляд, какие проблемы решают порталы?
Егор Головнин: Портал позволяет решить три главные проблемы.
Первая — это хранение документов и информации о заказах. Обычно документы хранятся у всех в разных местах, они теряются и т.д. А в личном кабинете пользователя на портале хранится вся история заказов и документов по ним. К ним всегда можно обратиться, отсортировать, выгрузить для себя и так далее. Таким образом устраняется проблема хранения документов, лишней коммуникации по поводу заказа документов.
Вторая — привязка ко времени. Если компания работает на федеральном уровне, то часто ей нужны документы сейчас, но из-за разницы во-времени с поставщиком она может получить нужное только на следующий день. Портал помогает организовать процесс таким образом, что заказчик ко времени работы компании вообще не привязан.
Третья — недопонимание между менеджером и клиентом. Например, клиент какой-то заказ делает через почту, а ему сотрудник отгружает не тот товар. Когда клиент сам выбирает все это в личном кабинете, сделать такую ошибку сложно: что он выбрал, то он и выбрал.
В целом у порталов есть два огромных преимущества — это снижение человеческого фактора в принятии решений и сокращение количества ресурсов за счет минимизации работы менеджеров. Как итог — повышается качество сервиса и эффективность работы бизнеса.
А.Р.: Компания решила создать портал— с чего начать, какие первые шаги?
Е.Г.: Первое, что нужно сделать, — это разобрать свои основные бизнес-процессы, связанные с клиентами, и разбить их на блоки.
● Продажи — все, что касается самостоятельного выбора клиентом товара или услуги и покупки.
● Документы — все необходимые шаблоны, условия для заключения договора, оформления счета и пр.
● Обращения — все, что касается претензий и рекламаций.
С этими пунктами, как правило, связано много проблем и практически все они одинаковые. Плюс — эти процессы легко автоматизировать.
А.Р.: Допустим, процессы определили. Что дальше?
Е.Г.: Портал — это в большинстве случаев интеграционная платформа. Поэтому нужно понять с какой системой интегрируется каждый блок — откуда берет информацию, куда передает дальше. Как правило, это большое количество разных систем — CRM, ERP, CMS, биллинги и другие.
Далее нужно разделить их по приоритетам. Например, первостепенная задача, чтобы пользователь мог сделать заказ. Получается, что компания должна дать ему возможность выбора товара, чтобы он смог оформить его и отправить к нам, а мы могли осуществить отгрузку. Продумываем этот процесс полностью и реализуем.
Потом смотрим, как система, с которой делаем интеграцию, будет взаимодействовать с другими. Чаще всего для того, чтобы товар получить, нужно “связаться с бухгалтерией, чтобы получить документы, узнать остатки на складах. Склад чаще всего интегрирован еще с какой-то системой. Таким образом раскручиваем весь клубок, составляем логические связи. Получается, что все дальнейшие этапы просто присоединяются как звенья к существующей логической цепочке, которую мы создали в самом начале.
А. Р.: Есть еще одна особенность. Когда начинаем собирать информацию, вылезает куча проблем. Например, отсутствует нормативно-справочная информация, клиенты в разных системах по-разному записаны и т.д. Приходится все по-новому стандартизировать. Соответственно, это влияет на сами бизнес-процессы — они меняются. Как проект по созданию портала должен это учитывать?
Е. Г.: Мне кажется, что бизнес-процессы, которые мы привязываем к порталу, должны быть, во-первых, гибкими, и заказчики должны понимать, что они изменятся. Во-вторых, должна проводиться работа с пользователями, с лицами, принимающими решения, с регламентами самих сотрудников, чтобы они включались в работу, давали обратную связь по ней, и бизнес-процесс дорабатывался уже на стадии MVP (minimum viable product, минимально жизнеспособный продукт), чтобы он работал верно, проще, удобнее для самих пользователей.
А. Р.: Как сделать так, чтобы этот портал потом клиентам был удобен, понятен и они им пользовались? Так как часто случается, что интегрировали, строили-строили, меняли процессы, внедряли с кровью. А в итоге - портал неудобный и туда ни один пользователь не заходит. Что нужно, чтобы портал был user friendly?
Е.Г.: Надо стараться с каждым релизом упрощать систему по сравнению с тем, как ее сделали первично в том же MVP. Потому что там дается какой-то работающий продукт, но после получения обратной связи становится ясно, что некоторые его части можно убрать. Например, есть некий важный документ, который запрашивается раз в полгода, переход на него не должен быть в реальности на главной странице, но в MVP его показываешь там, чтобы просто заказчик увидел. А потом в ходе работы такие ненужные “кнопки” убираются.
А.Р.: Подытожу сказанное тобой. Мы берем некую пилотную ограниченную по численности группу клиентов. Делаем MVP, где размещаем весь основной функционал. Дальше смотрим, что из этого не используют — это переносим в отдельные блоки, чтобы функционал сохранился, но не мешал. И далее каждый следующий шаг отслеживаем поведение пользователей на сайте, на портале, в личном кабинете и делаем новую гипотезу о том, как и что еще можно упростить? Правильно?
Е.Г: Да. Иногда вообще кажется, что этот процесс никогда не закончится.
А.Р.: Да, он наверно никогда не закончится. Если пользователь увидел какую-то приятную фишку в одной компании, то он хочет видеть это и в других, с которыми взаимодействует. Например, Apple в свое время был трендсеттером интерфейсов. До них не было иконок, были выпадающие меню, они сделали иконки – все, выпадающие меню умерли. Получается, надо постоянно саппортить, отслеживать изменения поведения пользователей на портале, чтобы как минимум поддерживать тот же приемлемый уровень использования, а то и увеличивать. Правильно я понимаю?
Е.Г: Да, все верно. Я бы тут вот еще что добавил. В2C-компании имеют дело с большим количеством пользователей, чем В2В-компании. Они могут собирать широкую аналитику и видеть, что 90 пользователей работают вот так, а 10 - работают иначе. И оперативно вносить правки в свои решения, порталы и т.д.
В B2B немного иначе. Здесь не такое огромное количество клиентов. Мне кажется, что здесь пользователи всегда на шаг впереди, потому что у них много опыта использования разных сервисов. И если они где-то видят новую функцию, то хотят видеть ее и в других компаниях.
А.Р.: Нас часто спрашивают, что делать с высоко нагруженными проектами? Говорят: “Ребята, вы что, какой портал? У нас куча пользователей, десятки тысяч, и очень сложные процессы, которые тоже ресурсоемкие”. Как делать высоко нагруженные решения?
Е.Г: Здесь основное – это архитектура самого решения.
А.Р: Но архитектуру как закладывать? Ее же как-то надо в начале увидеть. Вначале ведь очень маленькая нагрузка, а потом продукт выкатил, туда пришло несколько тысяч человек — и все легло.
Е.Г.: Во-первых, нужно сделать гипотезу, сколько пользователей в итоге будет заходить на портал. Во-вторых, мы всегда рассчитываем, что есть несколько резервных серверов, которые могут в критический момент подключиться. В-третьих, при создании архитектуры крайне важно проделать большую работу с IT-службой клиента. С кем ты интегрируешься, куда ты направляешь и как получаешь запросы. Если IT-служба сильная, то у них, скорее всего, есть какие-то регламенты, либо архитектура уже прописана. Если этого нет, нужно проводить большую подготовительную работу.
А.Р.: Как правило, внутри компании-заказчика — большие проблемы с отчетностью...
Е.Г.: Да, причем не только с внутренней отчетностью бардак, но и с клиентской. Приходит банальный запрос: “Сколько заказов за год было”. И никто не может дать эту информацию.
А.Р.: С чем это связано, и как это победить?
Е.Г.: Изначально нет стандартов по сбору и хранению информации. Сотрудники копируют информацию из одной эксельки в другую, а третья подгоняет все данные. Приходится наводить порядок в самих отчетах внутри какой-то системы. Ну и дополнительно “прикручивать” к системам всякие решения, которые позволяют быстро выгружать отчеты.
А.Р.: Их тоже можно интегрировать в портал?
Е.Г.: Да, причем сделать это несложно. Плюс, если присоединить отчетность, можно видеть данные совершенно разных платформ в одном интерфейсе. Так же клиент на B2B-портале сможет видеть и статистику по задачам (по сервис деску), и по количеству товаров — все в одном интерфейсе. А руководителю ничего не надо делать, он в своем B2B-портале сидит, отчеты смотрит, управленческие решения принимает. Составление этих отчетов – это большая боль. Если у вас есть какая-то логика по тому, как работать с клиентами, помогать им в этом случае, – мне кажется, это прямо "мастхэв" вообще для всех клиентов.
А.Р.: Последний вопрос — про юзабилити. Я со многими клиентами общался, они говорят: “Да, делали портал, но никто не пользуется”. И действительно, несмотря на все “плюшки”, клиенты обращаются к менеджеру. Поэтому надо не только процессы продумать, но и ожидания клиентов.
Е.Г.: Да, клиенту иногда проще выдернуть менеджера, чем сделать то, что нужно в автоматизированном виде. Особенно это касается людей, которые старше 55-ти. Они не хотят пользоваться никаким супер-удобным интерфейсом. Они лучше спросят у Васи, сколько и чего надо. И это исправить крайне сложно.
Но нужно убедиться, что с процессами на портале все ок.
А.Р.: Подведу итоги нашей беседы. Почему с порталами все кажется так сложно. Первая причина — неопределенность среды. Успех портала зависит от пользователей, а они, их привычки меняются. То есть постоянно нужно мониторить, чего хотят пользователи от портала. Это постоянная работа: делаем-тестируем-меняем-делаем-тестируем-меняем. Да, в В2В мало данных для аналитики, но с конечным пользователем можно связаться напрямую и получить фидбек. Можно даже объединиться в одну рабочую команду — ведь для пользователей в работе портала тоже есть выгоды. Или мотивировать их, например, предложив какие-то спецусловия.
Вторая причина — необходимость интеграции большого количества разных систем, с разными форматами данных и пр. Здесь решение одно: сделать интеграцию хорошо, сами или с нами. Как говорится, нормально делай — нормально будет.
И третья причина — необходимо менять бизнес-процессы. Как раньше уже не будет. Да, плохая новость в том, что изменения необходимы и это никому не нравится. Но хорошая новость в том, что все изменения всегда к лучшему и к ним нужно просто быть готовыми.
