Франшиза без IT-хаоса: где жёсткая унификация спасёт маржу, а где можно отклониться

Франшиза без IT-хаоса: где жёсткая унификация спасёт маржу, а где можно отклониться

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

Материал построен вокруг конкретной управленческой развилки: что именно в IT-инфраструктуре франшизы ресторанов должно быть жёстко унифицировано (тип кассы, складской учёт, чеки, отчётность, бухгалтерия, базовая доставка), а что допустимо отдать на откуп конкретной точке или региону (локальные интеграции, формат онлайн-меню, часть маркетинга, нестандартное оборудование). Внутри — практические ориентиры, чек-листы и типовые ошибки, которые регулярно всплывают у сетей из 5–50 точек.

Что на самом деле ломается, когда сеть растёт без IT-стандарта

Когда сеть маленькая, кажется, что унификация — это «проблема будущего». На пяти точках собственник успевает обойти всех, посмотреть отчёты, договориться с поставщиками лично. Но к десяти–пятнадцати точкам начинают накапливаться эффекты, которые не бьют по одной конкретной кофейне — они бьют по сети в целом.

Где у сетей начинается «каша» из IT-решений

Первая зона риска — кассовый софт и склад. Если на трёх точках iiko, на двух R-keeper, а на двух самописная система, то в конце месяца вы физически не сводите остатки. У каждой системы своя методология списания, свои справочники ингредиентов, разный подход к ФИФО. В результате управляющая компания получает отчёт, в котором «средний чек» и «себестоимость блюда» посчитаны по разным правилам. Сравнивать такие цифры между точками — всё равно что сравнивать температуру в градусах Цельсия и Фаренгейта без перевода.

Вторая зона — доставка и агрегаторы. Один франчайзи сам подключился к Яндекс Еде, другой работает через Delivery Club, третий договорился с локальным агрегатором в Казани, четвёртый вывел собственную доставку на конструкторе, который «нашёл подешевле». С точки зрения гостя — нормально, у него три канала заказа. С точки зрения сети — у каждого партнёра свой пул курьеров, свои правила приёма заказов, своя комиссия, своя интеграция с кухней. Когда сеть хочет централизованно управлять меню для агрегаторов, оказывается, что у разных точек разные форматы выгрузки, разные категории и даже разные фото блюд.

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

Четвёртая зона — данные о госте. Где-то стоит CRM, где-то — нет, где-то вместо CRM используется Excel-таблица менеджера зала, где-то — программа лояльности, привязанная к конкретному агрегатору. В итоге сеть не знает своего гостя: сколько раз он приходил, какие блюда заказывал, какие акции на него сработали. Каждый контакт с гостем разорван по кускам.

Почему «договоримся с франчайзи» не работает как стратегия

В начале роста многие сети решают, что унификация — это «просто договорённость»: подписали с партнёром соглашение, в котором написано «использовать iiko», и всё. Через год выясняется, что iiko у партнёра стоит, но не обновляется; интеграции с агрегаторами — самописные; модуль складского учёта не подключен, потому что «нам проще в Excel». Договорённость без контроля, методики и поддержки — это не стандарт, это пожелание.

Вторая ошибка — считать, что франчайзи сам заинтересован в стандартизации так же, как сеть. Это не так. У него локальная мотивация: «чтобы у меня работало» и «чтобы я зарабатывал». Если стандарт усложняет его жизнь и не даёт прямого дохода, он будет обходить стандарт всеми доступными способами — от «неофициального» POS до «временной» интеграции, которая стала постоянной. Поэтому унификация — это не пункт в договоре, это отдельный управленческий процесс с владельцем изменений, бюджетом и метриками.

Что обязано быть единым у всех партнёров франшизы

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

Кассовое ПО и складской учёт

Кассовое ПО — это фундамент, на котором стоит вся операционная отчётность сети. Не имеет смысла выбирать «красивое» или «дешёвое» — имеет смысл выбирать то решение, которое даст единую методологию учёта, единый справочник, единый формат выгрузки. В ресторанном сегменте России это, как правило, решения уровня iiko и R-keeper — не потому что они «лучшие во всём», а потому что они позволяют построить управляемый сетевой контур: центральный офис, центральный склад (если есть), единая нормативно-справочная информация, единые отчёты.

Почему это нельзя отдавать на откуп:

• Сравнимость данных. Только при одинаковой методологии вы можете сравнивать себестоимость, food cost, средний чек, выручку между точками. Без этого вы управляете «вслепую».
• Скорость закрытия периода. Если у вас 20 точек на разных системах, месяц закрывается не 3–5 дней, а 3–4 недели. Это не бухгалтерская проблема — это управленческая: вы принимаете решения по устаревшим данным.
• Аудит и контроль. Управляющая компания должна в любой момент открыть «карточку точки» и увидеть реальную картину: остатки, выручку, списания, инвентаризации. На самописных решениях и «зоопарке» POS это невозможно без выезда.
• Масштабирование. Если завтра к сети захотят присоединиться ещё 15 точек, единый кассовый контур позволит подключить их за дни, а не за месяцы.

Сквозная интеграция с агрегаторами доставки и собственной доставкой

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

Что обязано быть унифицировано:

• Способ интеграции с агрегаторами (через iiko/Kit или аналогичные модули, а не через «ручные» выгрузки и перенастройки).
• Стоп-лист и остатки — они должны меняться автоматически, а не по звонку партнёра.
• Меню для агрегаторов — единая структура, единые описания, единые фото. Это бренд, а не «локальная вольность».
• Правила ценообразования — даже если есть локальные акции, базовая логика «как формируется цена для доставки» должна быть единой, иначе у одних точек наценка 20%, у других 35%, гость это видит и уходит.

Что можно отдать партнёру: конкретный набор агрегаторов, с которыми он работает, локальные промо, формат упаковки (хотя и здесь стандарт желателен). Но сам «контур» — централизованный.

Базовый набор отчётности и её формат

Управляющая компания должна получать каждый день (или хотя бы через день) сопоставимые цифры. Это не десять разных отчётов, а компактный набор ключевых метрик: выручка, средний чек, количество чеков, food cost, остатки по критичным группам товаров, количество отмен, время обслуживания. Формат и состав этих отчётов — это то, что обязано быть единым.

Что обязательно в унификации отчётности:

• Один и тот же набор метрик во всех точках.
• Один и тот же формат выгрузки (например, выгрузка из iiko/R-keeper в определённой структуре, а не «каждый отправляет, как может»).
• Один и тот же график (например, до 10 утра следующего дня).
• Один и тот же способ доставки отчёта (общая папка, общий чат-бот, общая почта — что угодно, но одно).

Это звучит банально, но именно эта «банальность» ломается первой, когда сеть переходит от 5 точек к 15–20.

Что разумно оставить на усмотрение партнёра

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

Локальные маркетинговые инструменты и продвижение

Региональный маркетинг — это зона, где общая стратегия не должна мешать локальной тактике. Управляющая компания задаёт:

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

А вот конкретные инструменты, через которые партнёр достигает локальных целей, — на его усмотрение:

• выбор подрядчика по контекстной рекламе;
• выбор конкретной нетипичной механики (например, локальные коллаборации с городскими мероприятиями);
• формат листовок, баннеров в районе, локальных мероприятий;
• контент-план для соцсетей (если сеть не ведёт их централизованно).

Отдельные модули и точечные интеграции

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

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

Локальные каналы продаж и экспериментальные форматы

Если партнёр нашёл локальную нишу — например, кейтеринг для офисов в деловом квартале, корпоративные обеды для завода, обслуживание мероприятий в городе — это зона его ответственности и его прибыли. Сеть здесь задаёт только:

• Брендовые ограничения (нельзя выходить под чужим брендом, нельзя использовать рецептуры за пределами стандарта, нельзя портить имидж).
• Требования к качеству (если партнёр под брендом сети — стандарт сырья и подачи сохраняется).
• Отчётность по выручке (если это влияет на роялти или паушальный взнос — фиксируется в договоре).

Конкретные CRM-системы для кейтеринга, модули автоматизации, формы приёма заявок, локальные лендинги — всё это партнёр выбирает сам, если сеть не предоставляет готового решения.

Граница между «обязательно» и «можно отдать»

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

Эта таблица — не догма. Для сегмента dark kitchen, например, соотношение будет другим: там жёсткая унификация нужна по упаковке, остаткам и слоям доставки, а всё, что касается «зала», вообще не применимо. Для сегмента «кофейня-остров» — наоборот: минимум склада, минимум агрегаторов, максимум локальной свободы в выборе локации и формата обслуживания. Поэтому принцип важнее списка.

Как продать унификацию франчайзи

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

Покажите экономику, а не приказ

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

Что важно показать франчайзи:

• Сколько он переплачивает за агрегаторов из-за неоптимальных остатков и штрафов.
• Сколько он теряет на food cost из-за расхождений в складском учёте.
• Сколько времени у него забирает ручная отчётность (и что это время — не бесплатно).
• Какие акции и общие механики сети приносят ему дополнительную выручку (например, программа лояльности увеличивает повторные визиты на X%).

Когда партнёр видит, что стандарт — это не «наказание за инакомыслие», а источник его собственной маржи, сопротивление резко снижается.

Дайте готовую «коробку», а не список требований

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

Работает противоположное: «коробка» партнёра — настроенный, протестированный, документированный набор решений, который партнёр получает в день открытия. В коробку входят:

• POS с уже загруженной нормативно-справочной информацией сети (меню, рецептуры, склад).
• Настроенные интеграции с агрегаторами, подключённые каналы.
• Шаблон отчётности (готовые выгрузки).
• Настроенная программа лояльности (если она есть на уровне сети).
• Подключённый модуль работы с отзывами.
• Готовый сайт точки (или лендинг на общем домене сети).
• Инструкция по запуску и контакты поддержки.

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

Не превращайте стандарт в бюрократию

Жёсткая унификация — это не значит «каждое изменение в меню согласовывается три месяца». Это значит, что есть один понятный процесс изменения, и он работает. Партнёр подаёт заявку → управляющая компания за 3–5 дней согласует (или отклоняет с объяснением) → изменение уходит в сеть. Если процесс согласования медленнее, чем скорость рынка, партнёр будет действовать в обход, и будет прав.

Что обязательно в процессе:

• Прозрачные сроки согласования.
• Понятные критерии отказа.
• Единое окно подачи заявок (не «звоните Маше, а если её нет — Сергею»).
• Регулярный пересмотр стандарта — минимум раз в год, чтобы он не устаревал.

Что происходит, когда сеть «отпускает» IT-контур

Ниже — типовые сценарии, которые приводят к реальным потерям. Не абстрактные, а из управленческой практики сетей 10–50 точек.

Сценарий 1: «У нас 5 разных POS, и все работают»

Собственник сети из 18 точек через 2 года роста понял, что у него «зоопарк» кассовых систем. Формально — все работают, выручка идёт. Управленчески — катастрофа: остатки сравнивать нельзя, food cost считается по-разному, отчётность собирается вручную. Реальные последствия:

• Потеря 4–6% маржи только из-за невозможности централизованно управлять закупками и видеть перекосы по остаткам.
• Внезапные остановки в работе нескольких точек из-за проблем с интеграциями (например, выгрузки в бухгалтерию ломаются).
• Удлинённый месячный цикл — 25–30 дней вместо 5.
• Невозможность привлечь инвестора или продать бизнес — никто не купит сеть, в которой данные не сводятся.

Сценарий 2: «Каждая точка сама выбирает агрегаторов»

Сеть из 12 кофеен в трёх регионах. Управляющая компания разрешила партнёрам самим выбирать агрегаторов и подключаться. Через год выяснилось:

• Шесть разных интеграций, каждая — отдельный договор, отдельная поддержка, отдельный модуль.
• Меню в агрегаторах разное — где-то 30 позиций, где-то 18, где-то названия отличаются, гость путается.
• Штрафы за расхождения в остатках и время отклика: до 200 000 ₽ в месяц по сети.
• Невозможность запустить общую акцию сети в доставке, потому что у каждой точки свой стек.

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

Сценарий 3: «Программа лояльности — у каждого своя»

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

• Гость, который переехал из Москвы в Самару, не может воспользоваться накопленными баллами в новом городе.
• Сеть не знает реального LTV своего гостя — у одних это 8 000 ₽, у других 35 000 ₽, и сравнивать нельзя.
• Маркетинг тратит в 2 раза больше на привлечение нового гостя, чем мог бы — потому что возвратность «размазана» по локальным механикам.
• Франчайзи конкурируют между собой за одного и того же гостя разными акциями, что снижает маржу каждого.

Где локальные IT-решения действительно нужны

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

Городская специфика: доставка и локальные сервисы

В каждом крупном городе есть свой пул локальных сервисов: доставка еды от местных агрегаторов, локальные службы такси с услугой доставки, локальные CRM для ресторанов с учётом городской специфики (например, с интеграцией с системой пропускного режима в центре). В небольших городах, наоборот, федеральных сервисов может вообще не быть — там локальный партнёр по доставке может быть единственным выходом.

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

Нестандартные форматы точек

В сети могут быть стандартные рестораны, dark kitchen, кофейни-острова, фудтраки, точки в аэропортах, корпоративные столовые. У каждого формата — своя специфика оборудования и свои особенности учёта. Например:

• Фудтрак — нужна мобильная касса с офлайн-режимом, GPS-учёт перемещений, специфический модуль работы с ограниченным ассортиментом.
• Точка в аэропорту — особые требования к фискализации, специфическая программа лояльности аэропорта, ограниченный склад.
• Dark kitchen — нет зала, акцент на доставке, другие требования к складскому учёту, нужна интеграция с «кухонными» планшетами для сбора заказов.

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

Локальный найм и HR-учёт

В разных регионах — разные условия рынка труда, разные зарплатные ожидания, разные локальные HR-сервисы. Сеть может иметь единый стандарт по базовым вещам (тип договора, обязательные модули, требования к обучению), но выбор конкретного сервиса автоматизации HR-процессов — на усмотрение партнёра. Здесь нет критичной связи с операционным контуром, поэтому жёсткая унификация не нужна.

Чек-лист для управляющей компании: что проверить, прежде чем говорить «у нас стандарт»

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

Блок 1. Кассовый контур

• У всех ли точек одно и то же кассовое ПО?
• Обновляется ли оно централизованно и по расписанию?
• Есть ли у всех точек одинаковый набор модулей (склад, производство, доставка)?
• Сводятся ли остатки в единую базу?
• Считается ли food cost одинаково во всех точках?
• Есть ли единый регламент инвентаризации?

Блок 2. Доставка и агрегаторы

• У всех ли точек интеграция с агрегаторами через единый модуль?
• Меню в агрегаторах — одинаковое по структуре и описаниям?
• Цены в агрегаторах — управляются централизованно?
• Стоп-листы — обновляются автоматически?
• Есть ли единая политика по комиссиям и условиям работы с агрегаторами?
• Подключены ли все точки к программе лояльности сети (если она есть)?

Блок 3. Отчётность и данные

• Управляющая компания получает одинаковый набор отчётов со всех точек?
• Отчёты приходят в одном формате и по одному расписанию?
• Есть ли у управляющей компании прямой доступ к дашбордам точек?
• Сколько времени уходит на закрытие месяца? (Хорошо — 3–5 дней, плохо — больше 10.)
• Есть ли единая методология расчёта ключевых метрик?

Блок 4. Гость и лояльность

• Программа лояльности — единая для всей сети?
• Гость может использовать бонусы в любой точке?
• CRM ведёт единую историю взаимодействия с гостем?
• Отзывы агрегируются в одном месте (управляющая компания видит все отзывы сети)?

Блок 5. Маркетинг и бренд

• Брендбук — есть и соблюдается всеми партнёрами?
• Сайт — единый (с локальными подразделами для точек) или у каждого свой?
• Каналы привлечения — определены ли минимальные обязательные?
• Локальные акции — проходят ли согласование?

Блок 6. Процессы и поддержка

• Есть ли у управляющей компании владелец IT-стандарта?
• Есть ли регламент согласования изменений в IT-контуре?
• Есть ли бюджет на поддержку и развитие стандарта?
• Есть ли обучение для франчайзи по работе с стандартом?
• Есть ли метрики эффективности стандарта (food cost, скорость закрытия, NPS)?

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

Как технически построить единый IT-контур франшизы

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

Уровень 1. Центральный офис и центральный склад (если есть)

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

Уровень 2. Точки франчайзи

• Кассовое ПО с настроенными интеграциями.
• Локальный склад (если есть), работающий по правилам центрального контура.
• Оборудование: фискальный регистратор, принтеры, терминалы оплаты — стандартизированный набор.
• Локальная сеть и интернет с резервированием (для непрерывности работы).

Уровень 3. Каналы взаимодействия с гостем

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

Уровень 4. Поддержка и развитие

• Единое окно поддержки партнёров.
• Регламент обновлений и изменений.
• Регулярные аудиты контура (раз в квартал).
• Метрики эффективности и их регулярный пересмотр.

Звучит сложно, но по факту это один раз настроенный контур, который затем масштабируется на новые точки почти линейно. Главная ошибка — пытаться строить уровни в обратном порядке: сначала «коробка для партнёра», а центральный контур «когда-нибудь потом». В такой модели сеть упирается в потолок в 10–15 точек и дальше либо ломается, либо вынуждена перестраиваться с большими потерями.

Частые возражения партнёров и что на них отвечать

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

«У меня уже всё работает, зачем менять»

Работает — в каком смысле? Точка генерирует выручку, но не факт, что генерирует маржу. Часто «работает» означает «приносит деньги, но я не знаю, сколько именно». Здесь работает аргумент «покажите food cost и сравните с другими точками сети — мы вместе посмотрим, где вы теряете».

«Это дорого, я не потяну»

Часто под «дорого» подразумевается не стоимость софта, а стоимость времени на миграцию и обучение. Здесь важно показать, что в «коробке» партнёра уже всё настроено, а миграция занимает 3–5 дней, и эти дни оплачиваются управляющей компанией (или компенсируются из общего бюджета сети). Также работает аргумент «сколько вы теряете сейчас без стандарта — посчитали?». Обычно цифра потерь превышает стоимость внедрения за 2–3 месяца.

«Мои поставщики не впишутся в ваш контур»

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

«У нас маленькая точка, нам это не нужно»

Размер точки не освобождает от стандарта — он его требует ещё больше. У маленькой точки каждый процент маржи критичен, и без точного учёта она «съедается» незаметно. Стандарт для маленькой точки — это, по сути, страховка от потерь, которые она не замечает.

Где стандарт должен меняться

Жёсткая унификация — не значит «один раз выбрали и забыли». Рынок меняется, появляются новые решения, меняются привычки гостей. Сеть, которая в 2026 году использует стек пятилетней давности, проиграет более гибким конкурентам. Поэтому стандарт — это живой документ.

Цикл пересмотра

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

Что обычно меняется

• Каналы доставки: агрегаторы приходят и уходят, появляются новые форматы (например, доставка через соцсети, через мессенджеры).
• Способы оплаты: новые платёжные сервисы, СБП, биометрия.
• Формат работы с отзывами: новые площадки, новые требования по скорости ответа.
• Интеграции с госсервисами: меняются требования по фискализации, маркировке, передаче данных в системы типа «Честный знак».
• Локальные модули: что-то из «локального» становится «общим», потому что работает и тиражируется.

Итог: где проходит граница

Унификация — это не цель, а инструмент. Цель — управляемость сети и маржа. Где инструмент работает — применяем. Где мешает — отпускаем.

Жёстко унифицировать стоит всё, что формирует сквозной контур сети: кассовое ПО, складской учёт, доставку и интеграции с агрегаторами, базовую отчётность, программу лояльности, работу с отзывами, базовый сайт, фискализацию и способы оплаты. Это «нервная система» сети — если она разъезжается, сеть теряет управление и деньги.

Отдать на откуп партнёру стоит всё, что относится к локальной тактике: выбор подрядчиков по локальному маркетингу, дополнительные модули автоматизации, нестандартные интеграции, локальный HR, локальные каналы продаж (кейтеринг, корпоративные обеды), дополнительное оборудование. Здесь партнёр зарабатывает, и его свобода — это его мотивация.

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

Главный критерий простой: если унификация напрямую влияет на данные сети, маржу или бренд — она обязательна. Если она влияет только на комфорт работы партнёра — это его зона.

Сеть, которая выстраивает IT-контур по этому принципу, через 3–5 лет получает управляемый бизнес, в котором данные сходятся, маржу видно, бренд работает, а партнёры не чувствуют себя «операторами на зарплате». Сеть, которая игнорирует этот принцип, к этому же сроку получает зоопарк систем, разъехавшуюся отчётность, невозможность масштабирования и постоянные конфликты с франчайзи на почве «у нас всё по-разному».

Если прямо сейчас посмотреть на свою сеть честным взглядом и пройтись по чек-листу из этого материала, то, скорее всего, окажется, что 2–3 блока уже «поехали», ещё 1–2 на грани, и нужно 2–3 месяца работы, чтобы вернуть их в контур. Это нормально — главное, чтобы это решение было принято до того, как разъезд станет необратимым. А дальше — поддерживать стандарт, регулярно его пересматривать и не забывать, что унификация — это про деньги и управляемость, а не про бюрократию ради бюрократии.