Вернуться на главную
Навигация
Овервью
С нуля спроектировал CRM/OMS для крупного B2B-бизнеса. Система связала заказы, склад, оплаты и логистику, сделала проблемные заказы видимыми за 13 секунд, а бизнес получил инструмент для защиты до 10 млн ₽ выручки в месяц от зависших процессов и ручных ошибок.
Продукт
KUKA HOME / Jason Furniture - крупный мебельный и интерьерный бизнес. В одном филиале 200+ сотрудников, около 1000 заказов в день и несколько отделов, которые постоянно завязаны друг на друга.
Проблема
Через бизнес проходило около 1000 заказов в день со средним чеком около 30 000 ₽, то есть до 900 млн ₽ заказов в месяц. Но продажи, склад, оплаты, логистика и коммуникация жили в разных системах. Из-за этого проблемные заказы терялись между отделами, статусы уточнялись вручную, а поиск критического заказа занимал больше 10 минут.

При таком объёме даже 1% проблемных заказов превращался в миллионы рублей риска.

Зачем бизнесу нужна была своя CRM?
Компания уже использовала готовые CRM-системы, но они закрывали только отдельные куски процесса. Бизнесу нужна была своя система, способная связать заказ, склад, оплату, логистику и возвраты в один управляемый контур.

Мы с продактом оценили: если хотя бы 1-1,2% заказов зависает из-за ручных ошибок, задержек и несинхронной работы отделов, бизнес рискует терять или замораживать до 10 млн ₽ выручки в месяц.

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

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

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

RetailCRM закрывала продажи и клиентскую часть. МойСклад закрывал склад. Но между ними оставались закупки, частичные отгрузки, возвраты, перемещения между складами, контроль оплат и коммуникация.

Я разложил обе системы на скринфлоу и отметил, где операции дублируются, где конфликтуют, а где процесса вообще нет.
После этого стало понятно: копировать готовую CRM нельзя. Нужно проектировать свою систему под реальную операционку компании.
Интервью: разные роли видят один заказ по-разному
Провел больше 10 интервью с руководителями и сотрудниками опта, розницы, склада и логистики. Быстро стало видно: все говорят про один заказ, но смотрят на него с разных сторон

Опт думает про резерв, крупные партии и отгрузку. Розница - про скорость счёта, оплату и передачу на склад. Склад - про наличие, сборку и приоритет. Директор - про деньги, долги, оборачиваемость и эффективность отделов.

Это стало основой для ролей, сценариев и будущей архитектуры.

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

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

Архитектура CRM
После исследования я собрал архитектуру вокруг основных сущностей: заказ, товар, счёт, склад, закупка, отправка, возврат, сотрудник, роль.

В системе появились модули: заказы, оплаты, склад, закупки, логистика, возвраты, отчёты и настройки ролей.

Но важнее было не просто нарисовать меню. Нужно было понять, какой роли что показывать первым. Менеджеру важны задачи и проблемы по заказам. Складу - сборка, резерв и поступления. Руководителю - сводка по деньгам, отгрузкам и эффективности.

Проблема: 100+ статусов не помогали управлять заказом
В старой логике у заказа было больше 100 статусов. Формально система пыталась описать всё: оплату, склад, сборку, закупку, доставку, возврат, частичные изменения и ручные исключения.

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

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

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

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

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

Проблема была не только в лишнем инструменте. Закупка выпадала из общего процесса заказа. В CRM заказ мог выглядеть «в работе», но внутри уже был риск: товар не куплен, срок неизвестен, склад не понимает, когда ждать поступление, менеджер держит клиента на ручных обещаниях.
Гипотеза: встроить закупку прямо в карточку заказа
Я предложил не оставлять закупку отдельной таблицей, а сделать её частью заказа. Если позиции нет в наличии, менеджер может создать заявку на закупку прямо из карточки заказа.

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

Так закупка перестала быть ручным обходом и стала управляемым этапом. Для бизнеса это снижает риск потерять выручку на заказах, которые раньше зависали между менеджером, складом и поставщиком.

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

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

Бизнес хотел понятную и привычную CRM-логику. Разработка переживала за сложность мультисклада и этапов. Пользователи не хотели учиться новой системе с нуля.

Я постоянно балансировал между этими сторонами. Где-то нужно было упростить решение до MVP. Где-то наоборот продавить сложную логику, потому что без неё продукт не решал бы задачу.

Результаты: метрики после запуска
  • Поиск критического заказа сократился с 5-10 минут до примерно 13 секунд.
  • Оформление возврата стало быстрее почти на 90%.
  • Создание заказа ускорилось на 68,5%.
  • Резервирование товара - на 39%.
  • Количество задач на UI/UX-доработки после внедрения дизайн-системы снизилось на 21%.
Масштаб проекта
CRM/OMS быстро выросла из нескольких экранов в большую рабочую систему: заказы, склад, оплаты, закупки, логистика, возвраты, роли, статусы, пустые состояния, ошибки, права доступа и тому подобное.

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

CRM уже показывает состояние заказа. Следующий шаг - чтобы она помогала принимать решения.

Например, если заказ долго висит на оплате, система должна не просто подсветить статус, а предложить действие. Если закупка задерживается - предупредить менеджера заранее. Если отдел стабильно тормозит на одном этапе - показать это руководителю.

То есть следующий уровень продукта - не больше интерфейса, а меньше ручного контроля.
Вернуться на главную