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

Проблема в другом: как из тысяч показателей понять, где действительно требуется внимание руководителя и что конкретно нужно сделать?
Одна из крупных российских торговых сетей вместе со «Спутником» запустила проект ЦУП — Центр управления процессами. Задача была не добавить еще один слой отчетности, а автоматически выявлять существенные отклонения в работе магазинов, оценивать их значимость и формировать конкретные задачи. Под «отклонением» здесь понимается ситуация, когда показатель или процесс заметно выходит за ожидаемый для сопоставимых магазинов диапазон и требует управленческого действия.

За несколько лет проект прошел путь от пилота на нескольких десятках магазинов до системы, работающей в ежедневном режиме на всей сети. После масштабирования ЦУП контролировал более 20 видов отклонений в работе магазинов.

При этом проект оказался значительно шире внедрения ИТ-системы. Чтобы новая модель заработала, внутри компании одновременно развивались работа с данными, модель работы супервайзеров — руководителей групп магазинов — и программа обучения руководителей. 

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

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

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

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

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

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

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

Так система формирует не просто список дел, а замкнутый управленческий цикл: данные → проблема → приоритет → задача → действие → проверка результата → устранение проблемы или передача выше.

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

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

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

Чтобы алгоритмы могли участвовать в реальном управлении, данные должны поступать регулярно, вовремя и в согласованной структуре. Поэтому параллельно с развитием логики ЦУП шла большая работа внутри ИТ-команды клиента.

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

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

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

После масштабирования ЦУП работал на всей сети и контролировал более 20 видов отклонений в работе магазинов. Среди наиболее значимых были задачи, связанные с товаром и кассовыми процессами.

По мере развития системы менялся и вопрос, на который она отвечала. Сначала: «Где есть проблема?». Затем: «Какой проблемой руководителю заняться первой?». Рабочее время ограничено, поэтому ЦУП стал не только находить отклонения, но и расставлять приоритеты внимания.
По оценке команды проекта, использование ЦУП примерно на 30% сокращало время руководителей на анализ отчетности и поиск проблемных магазинов. Высвободившееся время можно было направить туда, где участие человека действительно необходимо: на работу с магазином, командой и причинами проблемы.

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

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

«Спутник» отвечал за методологию ЦУП, проектирование алгоритмов, программную реализацию и развитие решения.
Со стороны клиента проект координировал руководитель, который связывал операции, аналитику и ИТ: формулировал требования, проверял результаты системы и помогал повышать качество задач для операционных руководителей. 

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

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

Чтобы это заработало, компания организовала потоки данных, перевела опыт операционных руководителей в однозначные правила для системы, изменила модель работы супервайзеров и обучила команду. Поэтому ЦУП — не только ИТ-инструмент, а часть технологии управления.