Подобрать решение
ЗАКАЗАТЬ ОБРАТНЫЙ ЗВОНОК
Как ГК «Ренна» собрала клиентский сервис в единый контур: заказы, статусы и резервирование без ручной координации
Как ГК «Ренна» собрала клиентский сервис в единый контур:
заказы, статусы и резервирование без ручной координации
Когда компания работает через несколько производственных и торговых контуров, клиентский сервис начинает терять управляемость не в одной точке, а сразу в нескольких. Заказы приходят из разных систем, статусы живут отдельно от реального исполнения, взаимодействие между подразделениями уходит в почту, Skype и другие мессенджеры, а решение по конкретному заказу зависит от того, кто и что успел проверить вручную. С ростом количества заказов, уровень клиентского сервиса критично снижался, а штрафы и пени за несвоевременное исполнение заказов неуклонно росли.
С такой ситуацией ГК «Ренна» подошла к проекту по перестройке клиентского сервиса. Задача состояла не просто в том, чтобы добавить еще один ИТ-инструмент, а в том, чтобы собрать единый контур управления заказами: централизовать поток заказов, закрепить общую логику статусов, перенести взаимодействие по заказу в систему и дать рабочий инструмент резервирования на базе актуальных остатков.
С такой ситуацией ГК «Ренна» подошла к проекту по перестройке клиентского сервиса. Задача состояла не просто в том, чтобы добавить еще один ИТ-инструмент, а в том, чтобы собрать единый контур управления заказами: централизовать поток заказов, закрепить общую логику статусов, перенести взаимодействие по заказу в систему и дать рабочий инструмент резервирования на базе актуальных остатков.
О клиенте
ГК «Ренна» — крупная группа компаний в пищевой отрасли с собственными производственными площадками, торговым домом, сетью дистрибуции и разветвленной логистикой. Продукция компании представлена в десятках тысяч торговых точек по всей России и на внешних рынках.
Для проекта это важно по одной причине: клиентский сервис здесь — не локальная функция, а сквозной процесс между продажами, производственными площадками, логистикой, складами и исполнением заказов. Если в таком контуре нет единой точки управления, компания начинает терять скорость, прозрачность и качество сервиса.
Где процесс терял управляемость
На предпроектном этапе стало видно, что проблема не сводится к одной неудачной системе или отдельной ручной операции. Разрывы были встроены в саму схему работы.
Заказы не были собраны в одном месте
Заказы клиентов не были консолидированы и унифицированы на уровне группы компаний. Это означало, что у бизнеса не было единого источника данных, в котором можно оперативно увидеть:
-
сколько заказов сейчас в работе
-
на каком этапе находится каждый из них
-
где именно возникают сбои
-
каков реальный уровень сервиса по компании в целом
Пока заказы живут в нескольких системах, любая управленческая картина собирается с задержкой и требует ручной пересборки.
Статусы не отражали реальную ситуацию
Даже когда заказ формально присутствовал в системе, это не означало, что по нему можно понять фактическое состояние. Ключевые изменения по заказам не всегда отражались в ИТ-системах, а значит, команда управления клиентским сервисом видела не процесс, а его запаздывающую цифровую тень.
Из-за этого нельзя было системно анализировать исполнение заказов и разбирать причины отклонений на уровне фактов, а не переписки и отдельных комментариев.
Взаимодействие по заказам было вынесено за пределы системы
Сама обработка заказа и коммуникация между участниками шли через почту, Skype, Bitrix и другие мессенджеры. То есть критически важная часть процесса — передача задач, комментарии, согласование корректировок, реакция на отклонения — происходила вне общего управляемого контура.
Это создавало сразу несколько рисков:
- история работы по заказу распадалась по разным каналам;
- ответственность размывалась;
- контроль зависел от конкретных сотрудников;
- анализ причин ошибок становился трудоемким или невозможным.
- история работы по заказу распадалась по разным каналам;
- ответственность размывалась;
- контроль зависел от конкретных сотрудников;
- анализ причин ошибок становился трудоемким или невозможным.
Резервирование не имело надежной опоры в данных
Отдельная проблема была связана с остатками и резервированием. Текущие инструменты резервирования, не работали как полноценный рабочий механизм. У специалистов не было актуальной и полной картины по остаткам на складах компании и 3PL-складах. Дополнительно ситуацию усложняло отсутствие достоверных данных по срокам годности готовой продукции.
В такой схеме резервирование превращается в ручную координацию с высокой ценой ошибки: заказ можно принять, но исполнить не так, как ожидал клиент, или исполнить с лишними потерями для бизнеса.
Что делало проект сложным
На первый взгляд задачу можно было бы описать просто: собрать заказы, настроить статусы, добавить рабочее место для сотрудников. Но проект был сложнее, потому что компании нужно было скоординировать ряд действующих бизнес-контуров:
- ценообразование;
- бонусы;
- первичную обработку заказов;
- транспортную и складскую логистику;
- существующие обмены данными;
- реализации;
- складской учет.
Команда строила решение как отдельную независимую подсистему, интегрированную с остальными ERP-системами компании. То есть нужно было вернуть процессу управляемость, не останавливая текущую операционную работу и не ломая существующий ИТ-ландшафт.
Дополнительно сложность задавали:
- зависимость качества процесса от синхронизации нормативно-справочной информации
- разные бизнес-единицы
- необходимость работать в режиме, близком к реальному времени
- несколько систем-источников
- потребность закрепить единые правила работы не в регламенте «на бумаге», а в самой логике системы
Цели проекта
Проект разделили на оперативные и стратегические цели.
К оперативным отнесли то, что можно реализовать быстрее и что сразу влияет на качество клиентского сервиса:
- централизовать все заказы в одной подсистеме;
- разработать единую линейку статусов по заказам;
- автоматически собирать статусы из систем компании;
- формировать оперативную отчетность по состоянию заказов;
- формализовать взаимодействие по заказам и перенести его в единый контур;
- запустить централизованное резервирование на базе актуальных остатков.
Стратегические цели выходили шире текущего проекта и касались уже управления запасами как системы:
- внедрения партионного учета;
- создания единой ИТ-системы товарного учета группы;
- развития инструментов анализа товародвижения;
- сквозного планирования запасов и его автоматизации.
Это разделение было принципиальным. Оно позволило не смешивать быстрые меры по восстановлению управляемости с долгосрочной трансформацией учета и планирования.
Как выстроили подход
Вместо попытки внедрить все сразу проект разбили на четыре последовательные стадии. Такая логика позволила на каждом шаге сначала создать опорный контур, а потом наращивать на него следующие элементы.
Собрать заказы в одной точке
Без этого невозможно ни единое наблюдение, ни корректная аналитика.
Закрепить общую логику статусов
Пока у компании нет общей статусной модели, разные подразделения по-разному понимают одну и ту же стадию заказа.
Перенести взаимодействие в систему
Иначе даже при наличии консолидированных заказов и статусов значимая часть процесса все равно остается непрозрачной.
Создать инструмент резервирования
Который опирается на сводные остатки и встроен в общий процесс исполнения заказа.
Отдельно важно, что работы были организованы короткими итерациями. Перед каждой стадией уточнялись состав работ, результаты и бюджет, а проектом управляли через регулярный контроль сроков и рисков. Для таких процессов это не формальность: когда меняется сквозной контур между несколькими функциями, проект легко может расползтись по границам. Итерационный подход помог удержать рамку и не потерять управляемость самого внедрения.
Решение
В качестве целевой модели разработали «Централизованную систему управления заказами» на базе 1С ERP. По сути это был единый центр управления заказами, в который последовательно переносили ключевые функции клиентского сервиса.
Первый этап: централизация заказов
На первом этапе создали отдельную подсистему «Центр управления заказами» и настроили импорт заказов из нескольких систем группы врежиме, близком к реальному времени. Параллельно синхронизировали нормативно-справочную информацию и состав реквизитов по заказам.
Результат этого этапа был базовым, но принципиальным: компания получила единое место, где собираются все заказы, а задержка обновления не превышает одного часа при нормальной работе каналов связи.
Это изменило саму точку контроля. До проекта руководитель и участники процесса фактически работали с фрагментами картины. После — появился единый контур наблюдения за заказами.
Второй этап: автоматический сбор статусов
Дальше команда разработала управленческую линейку статусов и закрепила ее в политике управления заказами клиентов. Затем систему «научили» автоматически собирать сведения о статусах из систем-источников.
Управленческий смысл этого шага в том, что статус перестал быть условной отметкой или локальным термином подразделения. Он стал единым правилом интерпретации хода заказа для всей группы компаний.
Это важно не только для отчетности. Когда статусная модель общая, компания может разбирать отклонения по единой логике, а не тратить время на согласование того, что именно означает тот или иной этап.
Управленческий смысл этого шага в том, что статус перестал быть условной отметкой или локальным термином подразделения. Он стал единым правилом интерпретации хода заказа для всей группы компаний.
Это важно не только для отчетности. Когда статусная модель общая, компания может разбирать отклонения по единой логике, а не тратить время на согласование того, что именно означает тот или иной этап.
Третий этап: перенос взаимодействия в систему
На третьем этапе создали единый автоматизированный рабочий контур для участников процесса: менеджеров, специалистов по исполнению заказов, логистов и операторов. Внутри него появились задачи, комментарии и коммуникации, привязанные к конкретному заказу, а также инструменты корректировки заказа.
По сути, компания убрала критически важное взаимодействие из разрозненных каналов и встроила его в сам процесс исполнения. Любая передача заказа в работу между подразделениями теперь сопровождается изменением статуса, а сведения о действиях по заказу фиксируются в одной системе.
Это дало две вещи. Во-первых, прозрачность по каждому заказу: что изменилось, кто принял решение, где возникла корректировка. Во-вторых, возможность анализировать не только итог, но и сам ход исполнения.
Четвертый этап: инструменты резервирования
На последнем этапе разработали структуры хранения остатков, механизмы ежедневного импорта данных из систем компании и 3PL-складов, а также инструменты резервирования для специалистов.
До этого значительная часть работы по резервированию велась через Excel. После внедрения резервирование перевели в единый контур управления заказами.
Это важно не само по себе, а потому что резервирование стало опираться на централизованные данные и вошло в сквозной процесс исполнения заказа. То есть компания убрала один из самых уязвимых участков, где ручная работа напрямую влияла на уровень сервиса и потери.
Цель проекта
Если собрать логику проекта в одну формулировку, его цель состояла в создании централизованной системы управления цепочкой поставок в части клиентского сервиса — такой, в которой заказы, статусы, взаимодействие и резервирование работают не как набор разрозненных действий, а как единый управляемый процесс.
Результаты проекта
После реализации решения компания получила возможность:
- В оперативном режиме видеть состояние всех заказов
- Повысить скорость и качество обработки заказов
- Распределить зоны ответственности
- Управлять бизнес-функциями по KPI
-
Снизить потери
-
Повысить качество резервирования
- Анализировать исполнение заказов и реальный уровень сервиса с детализацией до дня в режиме, близком к онлайн
- Снизить транзакционные издержки между подразделениями
- Сократить трудозатраты специалистов за счет автоматизации рутинных операций
Часть результатов зафиксирована как достигнутые изменения процесса: все заказы собраны в едином центре управления, статусы автоматически обновляются, взаимодействие перенесено из внешних каналов в ЦУЗ, резервирование выполняется в одном месте. Часть эффектов в документах описана как бизнес-возможности, которые компания получает благодаря новой модели работы.
Почему это решение сработало
Этот проект показателен тем, что проблема клиентского сервиса редко решается одним модулем или одной интеграцией. Если заказы не консолидированы, статусы не отражают реальность, взаимодействие вынесено в мессенджеры, а резервирование держится на таблицах, компания теряет не только скорость, но и саму возможность управлять сервисом на основе данных.
В ГК «Ренна» задачу решили не через набор функций, а через сборку опорного контура: единый заказ, единая статусная модель, встроенное взаимодействие, централизованное резервирование. Именно это и дало управленческий эффект. Процесс стал прозрачнее, контроль приблизился к точке принятия решения, а зависимость от ручной координации снизилась.
Для руководителей компаний, операционных директоров и тех, кто отвечает за цепочки поставок, в этом кейсе важен простой вывод: клиентский сервис начинает работать устойчиво не тогда, когда у каждой функции есть свой инструмент, а тогда, когда у всей цепочки появляется единая логика исполнения заказа.
Получить материал
Заполните форму и мы вышлем вам PDF
Может быть интересно
Обложка: istockphoto · nanobanana.ai