KPI-дашборд в реальном времени
Главный экран — план vs факт по выручке, среднему чеку, оценкам гостей, скорости обслуживания. Данные с POS (iiko / R-Keeper) с задержкой не больше 1–2 минут.
Разработка приложения для управляющего рестораном и бэк-офиса
Мобильное приложение для менеджеров смен, директоров точек и территориальных управляющих сети общепита. KPI-дашборд в реальном времени, цифровые чек-листы, табельный учёт, интеграции с iiko / R-Keeper / 1С:ЗУП. Прямой кейс KFC DSR — менеджеры освободили 10 часов в неделю от рутины.
Что такое DSR-приложение и кому оно нужно
DSR (Director Smart Restaurant) — мобильное приложение для управляющих сети ресторанов. Не «универсальная программа автоматизации» и не «Excel в мобиле», а инструмент конкретной роли: менеджер смены, директор одной точки или территориальный управляющий, отвечающий за 10–30 ресторанов в регионе.
В отличие от полноценной автоматизации ресторанной сети, которая закрывает закупки, бухгалтерию, склад и кадры на уровне веб-системы, DSR-приложение — это mobile-first инструмент ежедневных операций: за смену управляющий открывает его десятки раз, отмечает выполненные пункты чек-листа, смотрит KPI текущего дня, согласовывает расписание следующей недели.
DSR-приложение оправдано, когда:
- В сети 10+ точек, и управляющим физически приходится бегать между залом и кабинетом ради бумажной отчётности.
- Управляющие тратят несколько часов в неделю на ручные операции, которые можно автоматизировать.
- В сети уже есть POS (iiko / R-Keeper / Poster) и базовый бэк-офис, но нет удобного мобильного канала «у управляющего на смартфоне».
- Стандарты сервиса требуют регулярных аттестаций и контроля регламентов — а они сейчас на бумаге.
- Сеть планирует масштабирование: каждый новый управляющий должен сразу включаться в цифровой контур.
Если сеть только проектирует автоматизацию целиком — лучше начать с полной автоматизации QSR или разработки ERP-системы, а DSR-приложение добавить как мобильный канал позже. Если бэк-офис уже работает, но управляющие живут в Excel и почте — DSR-приложение делается отдельным продуктом поверх существующей системы.
3 типа управляющих с разным сценарием
«Управляющий ресторана» — собирательное понятие. В крупной сети это три роли, у каждой свой сценарий и свой набор экранов в DSR.
Менеджер смены
Живёт в зале и на кухне, открывает приложение между задачами на несколько секунд: отметить пункт чек-листа, посмотреть план дня, согласовать перерывы команды. Главные экраны: дашборд текущей смены (выручка vs план, скорость обслуживания, средний чек), чек-листы открытия/закрытия, расписание смены, текущие инциденты, связь с директором.
Директор одной точки
Отвечает за прибыль точки, найм, обучение, выполнение KPI месяца. Открывает приложение реже, но смотрит более глубокие отчёты: KPI-дашборд за день/неделю/месяц, план vs факт (выручка, чек, оценки гостей, текучесть), управление командой (смены, аттестации, бонусы), заказ инвентаря, отчёты для территориального.
Территориальный управляющий
Отвечает за 10–30 ресторанов региона. Главный сценарий — план визитов на неделю и сравнение точек: сводный дашборд по всем точкам, рейтинг лучших и худших по KPI, календарь визитов и чек-листы инспекции, эскалации от директоров, регулярные отчёты вверх.
Эту трёхуровневую модель мы реализовали в кейсе KFC DSR mobile для одной из крупнейших ресторанных сетей мира: для каждой роли свой набор экранов и прав, но единая платформа и единая аналитика.
Чем приложение управляющего не равно полноценному бэк-офису
На старте часто возникает путаница: «мы хотим бэк-офис, но в телефоне». Бэк-офис и DSR-приложение — разные продукты с разной аудиторией и архитектурой.
| Параметр | Полноценный бэк-офис | DSR-приложение |
|---|---|---|
| Главный пользователь | бухгалтерия, закупки, аналитики | менеджер смены, директор, территориальный |
| Главный экран | веб-кабинет на десктопе | мобильный экран на смартфоне |
| Длительность сессии | 30–60 минут | 30 секунд — 5 минут |
| Главная задача | финансовый учёт, закупки, кадры, склад | оперативный контроль точки и команды |
| Объём данных за раз | большой (отчёты, выгрузки) | компактный (KPI, чек-листы) |
| Архитектура | ERP / 1С:ЗУП / WMS | mobile-first приложение поверх бэк-офиса |
| Время разработки MVP | 6–12 месяцев | 3–5 месяцев |
| Стоимость MVP | от 15–20 млн ₽ | от 5 млн ₽ |
В реальной сети эти системы существуют вместе: бэк-офис работает на бухгалтерию и закупки в офисе, DSR-приложение — у управляющих в карманах. Если в сети нет ни одного — обычно начинают с бэк-офиса или автоматизации QSR, а DSR добавляют как мобильный канал через 6–12 месяцев.
[ ФУНКЦИИ ]
8 ключевых функций приложения для управляющего
Минимальный набор, оправдывающий запуск DSR. Можно стартовать с 3–4 функций как MVP, остальные добавлять поэтапно.
KPI-дашборд в реальном времени
Главный экран — план vs факт по выручке, среднему чеку, оценкам гостей, скорости обслуживания. Данные с POS (iiko / R-Keeper) с задержкой не больше 1–2 минут.
Цифровые чек-листы смены
Вместо бумаги — пункты открытия и закрытия точки с фото-подтверждением, временем выполнения и ответственным. Главный pain в кейсе KFC DSR mobile — перевод из бумаги в цифру с проверкой.
Расписание смен и табель
Управляющий составляет расписание, сотрудники подтверждают смены. Табель закрывается автоматически по фактическим сменам (включая учёт через распознавание лиц).
Инцидент-репортинг с фото
Поломка оборудования, жалоба, просрочка — управляющий фиксирует за 30 секунд, прикрепляет фото, эскалирует территориальному. Без этого инциденты теряются в мессенджерах.
Заказ инвентаря и расходников
Сверка остатков с фактом, заявка поставщику в один тап. Интеграция со складом и закупками бэк-офиса.
Отчёты и сравнение точек
Для директора и территориального — сводки за день/неделю/месяц, рейтинги точек, выгрузки в Excel и PDF.
Мини-обучение управляющего
Короткие курсы по новым процедурам, регулярные аттестации, проверка готовности к повышению. Глубокое обучение линейного персонала — отдельный продукт (LMS).
Связь и эскалации
Текстовый чат, голосовые сообщения, файлы между управляющими разных уровней — в одном приложении с операционкой, а не в отдельном мессенджере.
Глубокое обучение и аттестация линейного персонала — отдельный продукт: LMS для линейного персонала ресторана. Учёт смен через распознавание лиц мы внедряли в кейсе KFC.
Архитектура mobile-first DSR
DSR — пример продукта, где архитектура важнее отдельной фичи. Что критично:
- Flutter в одной кодовой базе для iOS и Android. В нашем KFC DSR mobile 95% пользователей на Android (типично для сетей, где смартфоны выдаёт корпорат), но iOS поддерживается без отдельной команды. Подробнее — на странице Flutter-разработки.
- Серверное управление интерфейсом (Backend-Driven UI) для динамических чек-листов. Регламенты меняются раз в 2–4 недели; если каждое изменение требует релиза в стор — это месяц задержки. Сервер отдаёт конфиг экрана, приложение его отрисовывает: менеджмент меняет чек-лист в админке за 5 минут.
- Корпоративный вход (SAML SSO). Управляющие уже есть в Active Directory сети — DSR не создаёт отдельных учёток, а подключается к корпоративному входу.
- Оффлайн-режим. Часть точек в торговых центрах со слабым сигналом — чек-листы и операции работают без интернета и синхронизируются при появлении связи.
- Push с приоритизацией. Критичные инциденты (просрочка, остановка кухни) пробиваются через тихий режим, обычные апдейты дашборда — нет.
- Российские облака под 152-ФЗ. Данные сотрудников и показатели сети хранятся на Yandex Cloud, VK Cloud, Selectel с соответствующим контуром безопасности.
Интеграции для DSR-приложения
От качества интеграций зависит, насколько приложение реально решает задачи управляющего.
| Интеграция | Зачем |
|---|---|
| iiko / R-Keeper / Poster | Чеки, выручка, средний чек, скорость кухни — все KPI берутся из POS |
| 1С:ЗУП | Кадровый учёт, расчёт зарплаты, отпуска и больничные |
| Распознавание лиц / биометрия | Учёт смен, защита от мошенничества (как в кейсе KFC face-recognition ) |
| Агрегаторы заказа (Яндекс.Еда, Купер) | Контроль доставок с агрегаторов, рейтинги точки |
| CRM и программа лояльности | Оценки гостей, частота возвратов, активность лояльности |
| Видеонаблюдение и контроль качества | Снимки с кухни для подтверждения чек-листов, инцидент-видео |
| Active Directory / SSO | Единая авторизация управляющих со всеми системами сети |
| Тайный гость / контроль сервиса | Результаты проверок попадают в DSR с привязкой к точке и смене |
[ ПОЧЕМУ SURF ]
За 14+ лет создали 300+ мобильных и веб-продуктов
300+ реализованных проектов, 100 международных наград, №1 в мобильной разработке, 250 специалистов в команде. Прямой кейс DSR — KFC: 58 фич за год, минус 10 часов рутины в неделю у менеджеров, единая Flutter-кодовая база для мобильных и веб.
В неделю на рутину у менеджеров KFC
Прямой результат кейса KFC DSR
Фич за год развития DSR
Серверное управление интерфейсом
В разработке приложений для крупного бизнеса
Штатных специалистов
Mobile, backend, ML, дизайн, QA, DevOps
В неделю на рутину у менеджеров KFC
Прямой результат кейса KFC DSR
Фич за год развития DSR
Серверное управление интерфейсом
В разработке приложений для крупного бизнеса
Штатных специалистов
Mobile, backend, ML, дизайн, QA, DevOps
[ КЕЙСЫ ]
Кейсы Surf
Мы создаём foodtech-продукты для лидеров рынка — от стартапов до федеральных сетей. Несколько релевантных проектов из портфеля (полный — на странице foodtech-практики):
Юнит-экономика DSR-приложения
DSR должен окупаться. Считаем по четырём направлениям.
- Освобождение времени менеджеров от рутины. В кейсе KFC DSR приложение освободило менеджерам около 10 часов в неделю — 40+ часов в месяц на человека, которые он тратил на бумажные чек-листы, ручное составление расписаний, походы за отчётами. На сети из 100 ресторанов — 4 000+ часов в месяц обратно в операционку.
- Снижение фонда оплаты труда через прогнозирование смен. По нашему опыту автоматизации ресторанных сетей точное прогнозирование нагрузки и автопланирование смен снижают ФОТ на 12–15% за счёт исключения переработок и недозагрузок.
- Снижение списаний и потерь через прозрачные чек-листы. Цифровая фиксация открытия/закрытия с фото-подтверждением снижает потери на 2–5% — главный источник — контроль приёмки сырья, температуры хранения и сроков годности.
- Сокращение онбординга новых управляющих. В цифровом контуре новичок осваивает процессы за 2–3 недели вместо 1–2 месяцев.
На сети из 50+ точек DSR-приложение окупается за 6–12 месяцев.
Кастомный DSR или коробка (iikoChain / R-Keeper)
Два пути — готовое решение в составе POS-платформы или кастомная разработка.
| Параметр | Кастомный DSR | Коробка (iikoChain / R-Keeper) |
|---|---|---|
| Стартовая цена | от 5 млн ₽ | подписка от 30–200 тыс. ₽/мес на сеть |
| Срок запуска | 3–5 месяцев | 1–2 недели на установку и настройку |
| UX | свой, под процессы сети | стандартный, как у конкурентов на той же платформе |
| Кастомные процессы | любые | в рамках возможностей коробки |
| Глубокие интеграции (биометрия, тайный гость, SSO) | под заказ | как доработка платформы (платно) или нет |
| Mobile-first | да, с дня 1 | веб-первый, мобайл — упрощённая версия |
| Динамические чек-листы (серверное управление) | да | как правило, нет |
| Совокупная стоимость владения за 3–5 лет | разовая инвестиция + поддержка | подписка × число месяцев, растёт с числом точек |
Для небольших сетей на iiko коробка iikoChain справится. Для сети уровня BK / KFC / Додо с уникальными процессами и мультиплатформой POS — кастом сразу: миграция с коробки через 2–3 года обходится в стоимость нового проекта.
[ ПРОЦЕСС ]
Процесс разработки DSR
[ 01 ]
Discovery
2–3 недели. Аудит ролей и процессов, карта пути по 3 типам управляющих, выбор приоритетных функций MVP. DSR-план, технические решения.
[ 02 ]
Дизайн + архитектура
3–4 недели. UX-карта экранов под 3 роли, UI, дизайн-система, схема серверного управления интерфейсом, API. Кликабельный прототип.
[ 03 ]
Разработка MVP
10–14 недель. Мобайл, backend, базовые интеграции (POS + 1С + SSO), движок динамических чек-листов. Демо каждые 2 недели.
[ 04 ]
Тестирование и пилот
4–6 недель. QA, пилот на 5–10 точках, корректировки UX.
[ 05 ]
Масштабирование
4–12 недель по размеру сети. Выкатка на всю сеть, обучение управляющих, передача знаний.
Стек технологий
| Слой | Технологии |
|---|---|
| Мобильное приложение | Flutter (iOS + Android в одной кодовой базе) |
| Веб-кабинет (для крупных сетей) | React, TypeScript |
| Backend | Kotlin + Spring Boot или Python (Django / FastAPI) |
| База данных | PostgreSQL + ClickHouse (BI-аналитика) |
| Кэш и очереди | Redis, Kafka — показатели в реальном времени и push |
| Серверное управление интерфейсом | собственный движок (Server-Driven UI) — чек-листы без релиза в стор |
| Авторизация | SAML, OpenID Connect, OAuth 2.0 — корпоративный вход сети |
| POS-интеграции | iiko, R-Keeper, Poster через официальные API |
| 1С-интеграции | 1С:ЗУП |
| Распознавание лиц | Mobile Face SDK или серверные модели |
| Push-уведомления | Firebase + RuStore + Huawei Push |
| Инфраструктура | Docker, Kubernetes, российские облака — данные в РФ по 152-ФЗ |
Команда: продакт, бизнес-аналитик, UX/UI-дизайнер, мобильные разработчики Flutter, backend + инженер интеграций, QA, DevOps, закреплённый тимлид-архитектор.
Стоимость и сроки
| Тип DSR-приложения | Срок MVP | Стоимость «от» |
|---|---|---|
| DSR для одной точки или малой сети (5–15 точек) | 12–14 недель | от 5 млн ₽ |
| Корпоративный DSR для сети 15–50 точек | 4–5 месяцев | от 8 млн ₽ |
| DSR для крупной сети 50–200 точек | 5–7 месяцев | от 12 млн ₽ |
| Уровень федеральной сети с биометрией и AI-прогнозами | 7–10 месяцев | от 25 млн ₽ |
Что влияет на бюджет: количество ролей (1–2 — базовая, 4+ — раздельные UX), глубина интеграций (одна POS или мультистек iiko + R-Keeper + 1С + биометрия + тайный гость), наличие серверного управления чек-листами, оффлайн-режим, веб-кабинет для аналитиков, глубина AI-прогнозирования смен, стек. Полная автоматизация сети с прогнозированием нагрузки и бэк-офисом — отдельный продукт food-automation, DSR работает в связке с ним, но запускается часто раньше. Если нужно проверить узкую гипотезу за 2–3 месяца — рассмотрите MVP foodtech.
[ ОТЗЫВЫ ]
Клиенты о работе с нами
[ FAQ ]
Клиенты часто спрашивают
DSR — узкий мобильный инструмент конкретной роли (менеджер / директор / территориальный), запускается за 3–5 месяцев. Полноценная автоматизация — комплекс веб-системы и аналитики на закупки, бухгалтерию, склад и кадры. На крупной сети они существуют вместе: бэк-офис для офиса, DSR — для управляющих в точке.
Для сети до 5–10 точек на одной POS-платформе — да, разумный выбор. Для сети 15+ точек с уникальными процессами или мультистеком POS (iiko + R-Keeper + Poster) — кастом сразу.
Ориентир — от 8 млн ₽ за MVP с базовыми функциями (KPI-дашборд + чек-листы + расписание смен) и одной POS-интеграцией. Точная вилка зависит от числа ролей, интеграций, наличия биометрии и оффлайн-режима.
Минимум — данные о выручке и чеках через API iiko / R-Keeper / Poster. Для глубокого DSR — также состав чека (для оценок на конкретное блюдо), складские остатки (контроль списаний), смена кассира (табельный учёт).
Опция, не обязательная для MVP. Базовый учёт — ручной тап «начал/закончил». Биометрический модуль (как в кейсе KFC с распознаванием лиц) добавляется через 3–6 месяцев после релиза, +2–4 млн ₽ к смете.
Да, это распространённый сценарий: DSR живёт как один из mini-apps в составе суперапп ресторанной сети. Архитектура заложена так с дня 1 — DSR работает как самостоятельный модуль с собственными правами.
Регламенты сети меняются раз в 2–4 недели. Без него каждое изменение чек-листа требует релиза в стор — месяц задержки. С ним сеть меняет конфиг в админке, и через минуту обновление у всех управляющих. В KFC DSR этот подход обеспечил 58 фич за год.
