Как подготовить бизнес-систему к работе нового филиала, чтобы не размножить процессы?

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

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

Сначала определить, что именно филиал будет делать

Слово «филиал» слишком широкое. Один офис принимает заявки, другой продаёт со склада, третий только оказывает услугу, четвёртый ведёт часть производства. Для каждого набора работ нужны свои роли, документы, статусы и контрольные точки.

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

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

Не копировать справочники руками

Самая частая ловушка — завести в новой точке собственные товары, клиентов, причины возврата и должности «на всякий случай». Через пару недель один и тот же товар называется по-разному, цена обновилась не везде, а общий отчёт начинает складывать несопоставимые цифры.

Полезнее заранее разделить данные на три группы:

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

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

Доступ — это не список фамилий

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

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

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

Провести короткий пилот до открытия

Пилот — не имитация жизни в презентации. Он должен включать реальные, но безопасные сценарии: один обычный заказ, одно исключение, один возврат или исправление, одну передачу информации в центральный офис. Хорошо, если в нём участвует будущий сотрудник филиала, а не только проектная команда.

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

Не открывать новый маршрут молча

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

Поэтому перед открытием нужны короткие, доступные инструкции по критичным шагам и один понятный канал поддержки. Не чат «на все случаи», а маршрут: что сотрудник решает сам, что передаёт руководителю, когда подключают центральную команду. Хорошее уведомление не создаёт шум, а ведёт к следующему действию; тот же принцип полезен и здесь. Его можно сверить с разбором уведомлений без шума.

Чек-лист первого дня

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

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

Частые ошибки при запуске филиала

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

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

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

Связанные вопросы

• Какие данные филиал должен видеть, а какие лучше оставить на уровне центрального офиса?
• Кто вправе менять общий справочник и как филиалу предложить изменение?
• Как запустить пилот, если открытие нельзя переносить?
• Что считать достаточной готовностью сотрудников к первому рабочему дню?

Нужно ли сразу переносить в систему всю историю филиала?

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

Можно ли сначала работать в таблице, а потом загрузить всё в систему?

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

Когда считать запуск завершённым?

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