Спроектировали сервис для управления ценообразованием. Кейс Faberlic

Спроектировать сервис для управления ценообразованием, который будет понятен и удобен всем пользователям.

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

Какая была проблема?

Проблема, с которой сталкиваются компании, ведущие продажи в нескольких странах — ценообразование. В дистрибьюторской сети это многоэтапный процесс, в который вовлечены:

— филиалы, расположенные в разных странах и городах;

— множество сотрудников разных уровней;

— большие объемы данных;

— множество информационных систем.

При разработке цен сотрудники создают и передают на согласование из отдела в отдел несколько таблиц.

У нашего заказчика — Faberlic — этот процесс был частично автоматизирован на уровне импорта цен в информационные системы.

Но перед этим сотрудники все равно тратили много времени на подготовку нужных таблиц вручную. Учёт актуальных цен и история их изменения ведётся отдельными сотрудниками в таблицах, где они группируют правки по товарам по каждой категории товара в каждой стране.

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

Мы провели глубокое исследование и разобрали бизнес-процессы компании и сотрудников, которые участвуют в процессе ценообразование. Разложили их на схемы и пользовательские сценарии, определили, как работает каждый из бизнес-процессов, что в нём самое важное и что можно оптимизировать.

Работа состояла из следующих этапов:

1) Интервью с представителями заказчиков;

2) Составление карты пользовательских сценариев;

3) Описание бизнес-процессов в схемах;

4) Написание Технического Задания.

Подробнее про процесс и результат каждого этапа — ниже. 

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

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

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

Проблема 1. Жесткая привязка стран к регионам.

Страны объединяются в регионы присутствия, где действует единая тарифная сетка. Из-за этого невозможно гибко настраивать ценовые условия для отдельных стран.

Решение: мы предложили механику произвольного объединения стран в кластеры, чтобы была возможность гибкого формирования цены в конкретной стране или массового изменения во всех странах кластера.

Проблема 2. Невозможность независимого редактирования коэффициентов для разных скидочных цен в рамках страны.

Что снова приводило к ручным корректировкам в каждом отдельном случае.

Решение: мы заложили возможность вводить независимые коэффициенты на все виды цен для каждой страны или кластера.

Также предусмотрели возможность создания пользовательских модификаторов цен, что позволяет еще более гибко подходить к формированию цен для каждой страны в отдельности.

Проблема 3. Разделение процесса ценообразования на этапы формирования и внесения цен.

Из-за этого сотрудникам нужно было вручную сначала согласовывать, а затем вносить цены. А это множество таблиц с данным, которые замедляли внесение цен и увеличивали вероятность ошибки.

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

Проблема 4. Сложности с проведением маркетинговых активностей.

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

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

Проблема 5. Необходимость вручную уведомлять филиалы после внесения новых цен.

Решение: мы предусмотрели автоматическую рассылку уведомлений при срабатывании триггеров (начало действия цен, например.) Учли как предустановленные триггеры, так и те, который могут настроить пользователи. 

На основе выявленных проблем и возможных вариантов решения, мы смогли прописать все функциональные требования к будущей системе. Для удобства и наглядности представили их в формате карты пользовательских сценариев – User Story Map.

С помощью карты пользовательских сценариев мы смогли не только выявить проблемы всех вовлеченных в процесс ценообразования сотрудников и отделов, но и представить процесс в общем, доступном для всех виде и показать, что изменится в будущем.

Мы получили наглядное изображение процесса, зафиксировали все роли и зоны ответственности каждого участника: теперь каждый из них будет понимать, как и кто принимает решения в новом процессе.

После того, как мы проанализировали и зафиксировали все функциональные требования и пользовательские сценарии, мы прописали обновленные бизнес-процессы. Именно они легли в основу новой системы ценообразования.

На схеме бизнес-процессов мы отобразили:

— какой сотрудник, в какой последовательности и какие шаги должен совершить;

— к какому результату ведет каждое из действий;

— какие информационные системы и в какой момент обращаются за данными к сервису ценообразования для получения расчёта.

Такая схема существенно облегчает понимание работы будущего сервиса для всех вовлеченных в процесс его создания людей.

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

Есть несколько типов цен, которые используются внутри компании и при выводе для конечного пользователя на сайте. Например, в компании есть консультанты, у которых есть специальная скидка баллами, для отдельных клиентов есть персональные скидки. Это тоже нужно учитывать при расчёте цен.

Мы предусмотрели создание и редактирование видов расчётных цен и баллов внутри компании и для клиентов.

Поэтому при внесении цены товара в систему, автоматически для нее должны рассчитываться дополнительные цены с модификаторами. Модификаторы — это, например, курс валюты в выбранной стране или кластере, цена балла консультанта, фиксированные цены (если они установлены для товара) и другое.

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

Мы предусмотрели в системе несколько типов округления значений цен. Выбранные типы используются при расчете цен в определенной стране или кластере. Это нужно для того, чтобы в карточке товара всегда отображалась изначальная цена, а в публичном разделе сайта показывалась цена с учётом настроенного округления. Если для страны выбрано несколько типов округления, сотруднику доступна их ручная сортировка.

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

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

В зависимости от роли пользователя, изменения по заявке система сохраняет незамедлительно или отправляет на внутреннюю процедуру согласования. Менеджер или супервизор может изменить заявку до начала ее действия. 

При изменении структуры каталога может возникнуть ситуация, когда в момент создания заявки товар относился к одной категории, а после создания заявки этот же товар был перемещен в другую. Система автоматически пересчитает цену для такого товара, в соответствии с модификаторами, которые заданы в заявке для категорий. Затем направляется супервизору и менеджерам центрального офиса и страны с уведомлением, что цены по этому товару пересчитаны.

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

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

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

При проектировании сервиса особое внимание мы уделили анализу пользовательских сценариев и тем факторам, которые на них влияют:

— условия создания и особенности формирования цены;

— ценовые параметры для отдельных стран;

— маркетинговые акции;

— нюансы финансового расчёта;

— связка с другими системами;

— и прочее.

Мы предусмотрели в интерфейсе возможности для:

— просмотра и изменения нескольких видов цен отдельных товаров;

— просмотра истории изменения цен;

— изменения цен с помощью набора модификаторов.

Задача не тривиальная: из-за того, что компания очень большая, а также представлена в 43 странах мира, нам нужно было учесть большое количество групп пользователей и выстроить процесс ценообразования по всему миру для разных:

— стран;

— валют;

— рынков;

— групп пользователей.

Учесть, например, отдельно цены на косметологические услуги, цены на сайте, цены, по которым консультанты продают и покупают товары. Мы спроектировали все так, что большой набор цен будет объединен в отдельном сервисе, который будет общаться с другими системами и автоматически отсылать нужную информацию в них.

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