ERP Platform Docs

vision-pos-platform

время чтения ~10 мин.

Видение: собственная POS-платформа + Paykeeper как «умный фискальный модуль»

Куда мы хотим прийти и насколько это хорошая идея.

В одной фразе

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

Текущая картина vs целевая

flowchart LR
    subgraph NOW ["СЕЙЧАС — гибрид"]
        direction TB
        CU1["Клиент"]
        PKT1["mPOS Paykeeper<br/>(плоский каталог, карта, ФН)"]
        ADM1["Наш ERP<br/>(учёт, склад, сотрудники)"]

        CU1 -->|"оплата"| PKT1
        PKT1 -.->|"webhook"| ADM1

        note1[/"Кассир либо через mPOS, либо через<br/>наш тонкий POS BFF. Терминал сам по себе<br/>не может собрать сложный заказ."/]
    end

    subgraph FUTURE ["ЦЕЛЬ — R-keeper-модель"]
        direction TB
        CU2["Клиент"]
        OURPOS["НАШ POS-софт<br/>(планшет/моноблок/ПК)<br/>• меню с модификаторами<br/>• стоп-листы, прейскуранты<br/>• статусы заказа, KDS<br/>• скидки, лояльность"]
        PKTERM["Терминал Paykeeper<br/>ТОЛЬКО:<br/>• принять карту/SBP/кэш<br/>• пробить чек в ФН<br/>• отправить webhook"]
        ERP2["Наш ERP-облако<br/>(аналитика, склад, франшиза)"]

        CU2 -->|"заказ"| OURPOS
        OURPOS -->|"сумма + состав чека"| PKTERM
        PKTERM -->|"OK + фискальный ключ"| OURPOS
        OURPOS <-->|"синхронизация"| ERP2

        note2[/"POS-софт — сердце. Paykeeper —<br/>ровно то же, чем сейчас являются<br/>Ingenico или АТОЛ Ф для iiko:<br/>умная железка без своего интеллекта."/]
    end

    style NOW fill:#2a1a2e,stroke:#e94560,color:#fff
    style FUTURE fill:#0f3460,stroke:#40916c,color:#fff
    style PKT1 fill:#533483,stroke:#e94560,color:#fff
    style PKTERM fill:#533483,stroke:#40916c,color:#fff
    style OURPOS fill:#16213e,stroke:#40916c,color:#fff

Что именно становится «нашим»

СлойФункцияСейчасЦелевое
POS-софтЭкран приёма заказа с модификаторамиПланшет Paykeeper с плоским каталогомНаш софт на любом устройстве
Каталог на кассеМеню, категории-дерево, стоп-листы, прейскурантыКопия нашего каталога в Paykeeper (урезанная)Наш каталог напрямую, без копирования
МодификаторыКапучино + сироп + шотЗашиваем в cart deep link строкойНастоящий UX выбора на кассе
Статусы заказаНовый → готовится → готов → закрытТолько «оплачен» в PaykeeperПолный цикл у нас
Кухонный дисплей (KDS)Экран для бариста/повараНетНаш экран, свой софт
Скидки и лояльностьПрограмма лояльности, купоныНет (PK не знает)У нас, считается до передачи суммы в терминал
СменаОткрытие/закрытие кассового дняВ PaykeeperУ нас (с синхронизацией с ФН)
ОтчётыX-отчёт, Z-отчёт, сводкиИз выгрузки PKУ нас с обогащением (выручка + модификаторы + сотрудники + себестоимость)
Офлайн-работаПродолжение работы при отсутствии интернетаНет (PK требует сеть)У нас с локальной БД + синк

Что остаётся за Paykeeper

  1. Эквайринг — приём карты/SBP/Apple Pay/MirPay. Банковская лицензия, PCI DSS.
  2. Фискальный накопитель (ФН) — подпись чека для ФНС по 54-ФЗ.
  3. ОФД-интеграция — отправка чеков в налоговую.
  4. Ссылка на чек клиенту — облачная страница чека.
  5. (Опционально) Выплаты физлицам — если будет нужно платить курьерам/сборщикам сырья.

Это именно та часть, где не хочется лезть самим — юридически, сертификационно и операционно это сложно и бесполезно для нашего профиля.

Почему это хорошая идея

1. Рыночно — есть куда расти

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

2. Технологически — мы почти готовы

Уже реализовано или в плане:

  • Каталог с модификаторами, прейскурантами, стоп-листами
  • Склад с техкартами и FIFO
  • Ролевая модель с гибкими permissions
  • Многотенантность (франшизы, юрлица, ТТ)
  • Kafka-события между сервисами
  • Admin BFF + POS BFF + Customer BFF (разделение по клиентам)

Это уже 60-70% того, что есть в iiko по функциональности. Осталось достроить POS-клиент и обвязку.

3. Для франчайзи — одна точка входа

Сегодня у франчайзи:

  • iiko (касса)
  • 1С или другая система учёта
  • Excel для ручного сведения
  • Отдельные отчёты от эквайера

У нас в целевой картине:

  • Одна админка с учётом, меню, персоналом, отчётами, интеграциями
  • Одна мобильная приложенька для клиента
  • Касса на любом железе
  • Оплата через проверенного эквайера (Paykeeper)

4. Экономическая модель повторяется

iiko продаёт подписку (SaaS). Мы можем делать то же. Плюс маржа с эквайринга (Paykeeper будет делиться комиссией если сами приведём им ТСП).

5. Развитие идёт «естественно»

Каждый MVP-шаг для нашей франшизы одновременно двигает нас к R-keeper-модели:

  • Делаем POS BFF → получаем фундамент кассового софта
  • Делаем KDS для своих кухонь → готовый модуль для продажи другим
  • Делаем офлайн-кэш каталога → превращаем мобильную кассу в автономную

Каждая фича для одного клиента — это фича для рынка.

Риски и что может пойти не так

1. Полноценный POS — это не «ещё одна фича»

Это самостоятельный продукт с десятками модулей:

  • KDS с маршрутизацией заказов по принтерам
  • Офлайн-режим с надёжным синком
  • Сценарии «отменить одну позицию из закрытого заказа»
  • Чеки коррекции по предписанию ФНС
  • Банкетное обслуживание / pre-order / резервирование столов
  • Интеграции с весами, сканерами, дисплеями для клиента
  • Долгие смены, перекрытие смен, передача смены

Оценка честно: чтобы полностью заменить iiko в среднем ресторане — от 1 до 2 лет разработки после текущего MVP.

2. Интеграции с железом — это боль

  • Весы: Штрих-Принт, CAS, Ohaus — у каждого свой протокол.
  • Сканеры штрихкодов: Honeywell, Zebra, Datalogic — USB-HID проще, но Bluetooth-модели со своими причудами.
  • Чековые принтеры (если хотим отдельно от ФН): Star, Epson — ESC/POS спасает, но тонкости есть.
  • Денежные ящики: открываются по импульсу от принтера, но бывают нюансы.
  • Дисплеи для клиента (второй экран с ценой): протоколы CD 5220.

Каждая интеграция — 1-2 недели QA на реальном железе. Это постоянная работа.

3. 24/7 SLA

Если в общепите касса падает в обеденный пик — клиент теряет по 10-50 тыс/час. Значит:

  • Мониторинг уровня «Sentry на панели у дежурного»
  • Дежурная смена инженеров (как минимум на быстрые инциденты)
  • Чёткий SLA в договоре с франчайзи: время реакции, время восстановления
  • Runbook’и для типовых проблем

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

4. Конкуренция с матёрыми игроками

iiko — 12+ лет на рынке, огромная база клиентов, партнёрская сеть внедренцев. R-keeper — даже больше, сильные позиции в fine dining. Frontol — бюджетный сегмент.

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

5. Привязка к Paykeeper

Если делаем ставку на одного эквайера — попадаем в зависимость:

  • Поднимут комиссию — нам некуда деваться.
  • Лягут на сутки — все франчайзи без оплаты.
  • Сменят API — мы переписываем адаптер.

Митигация: с самого начала проектировать адаптер как anti-corruption layer (что мы и делаем). Если Paykeeper перестанет устраивать — меняем адаптер, остальное не трогается. В идеале позже поддержать 2-3 эквайеров на выбор.

6. Риск «застрять в середине»

Опасный сценарий: начали делать POS, но не дотянули до уровня iiko. Получается продукт «слабее iiko + своя франшиза». Клиенты спрашивают «а зачем мне вы вместо iiko?» — нечего ответить.

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

Фазовый план развития

Каждая фаза — самоценная. В конце каждой мы остаёмся с жизнеспособным продуктом, даже если следующую фазу отложим.

Фаза 0 · MVP для своей франшизы (сейчас)

Цель: запустить собственные ТТ на нашей инфраструктуре + Paykeeper.

Что строим:

  • Бэкенд (5 сервисов): Auth, User, Store, Catalog, Warehouse — уже в работе
  • Admin BFF для бэк-офиса — уже работает
  • Paykeeper-адаптер — в плане, после этой презентации
  • POS BFF + первая версия POS-приложения (пока простой экран «принять оплату»)
  • Интеграция с mPOS Paykeeper через deep link

Что не делаем: KDS, офлайн-режим, работа без интернета, интеграции с весами, клиентский дисплей.

Срок: 2-3 месяца от точки «адаптер готов».

Результат: наши ТТ работают, собираем обратную связь, готовим материалы для франчайзи.

Фаза 1 · POS-клиент на любом железе (R-keeper-модель минимум)

Цель: выйти из зависимости от экрана mPOS Paykeeper — наш кассовый софт на моноблоке/планшете/ПК.

Что строим:

  • POS-приложение на Android (планшеты) и Windows (моноблоки)
  • Полноэкранный UX: сетка товаров с категориями, модификаторы, быстрые клавиши, поиск
  • Работа с «тонким» пин-падом Paykeeper как периферией (а не хост-устройством)
  • Подключение чекового принтера ESC/POS (если клиент хочет бумажный чек помимо ссылки)
  • Денежный ящик (открытие по сигналу от принтера)
  • Простейший KDS — один экран на кухне с активными заказами

Ещё не делаем: сложный KDS с маршрутизацией, весы, сканеры, офлайн.

Срок: 3-4 месяца после Фазы 0.

Результат: классическая схема как у iiko, но «фаршированная» нашей логикой.

Фаза 2 · Операционная зрелость

Цель: можем продавать продукт сторонним ресторанам.

Что строим:

  • KDS с маршрутизацией заказов по кухонным станциям (холодный цех, горячий цех, бар)
  • Резервирование столов, работа с залами
  • Сложная смена: передача смены, перекрытие, x-отчёты/z-отчёты с фискальной частью
  • Интеграции: весы (Штрих/CAS), сканеры штрихкодов, дисплеи клиента
  • Офлайн-режим на кассе (локальная БД + отложенная синхронизация)
  • Чеки коррекции, возвраты из закрытого заказа, частичные возвраты
  • Программа лояльности: бонусы, купоны, скидочные карты

Срок: 6-9 месяцев после Фазы 1.

Результат: функциональный паритет с iiko в базовом ресторанном сценарии.

Фаза 3 · Масштабирование и экосистема

Цель: продукт для рынка.

Что строим:

  • Мультиэквайер: помимо Paykeeper — Сбер, Тинькофф, Альфа
  • Интеграции с агрегаторами (Яндекс.Еда, Delivery Club) как поставщик заказов
  • Маркетплейс приложений: сторонние разработчики делают плагины под нас
  • Публичный API для франчайзеров и сторонних интеграторов
  • Собственное мобильное приложение под брендом франшизы (white-label)

Срок: 12+ месяцев после Фазы 2.

Результат: платформа уровня iiko по покрытию, но с более современной архитектурой и франшизным уклоном.

Что нужно от Paykeeper для нашего видения

Именно в этой конфигурации («мы — кассовый мозг, они — эквайер+ФН») от Paykeeper нужен минимум из списка gap-анализа:

Обязательно (P0 из gap-analysis):

  • Webhook’и про возвраты/отмены/корректировки — без этого учёт рассыпается
  • API для reconciliation (список платежей за период) — гарантия что ничего не пропустили
  • Тестовое окружение — подключение разработки и CI
  • ФН/ФД/ФП/номер смены в webhook — для нашего реестра
  • API управления сменой ФН (статус + принудительное закрытие + предупреждения)

Можно отложить (P0 из gap-analysis):

  • Модификаторы на их стороне — не нужны, модификаторы полностью на нашем экране
  • Иерархия категорий — не нужна, категории у нас на нашем экране
  • Per-store прейскуранты — не нужны, передаём финальную цену в каждый платёжный запрос
  • Стоп-листы per-store — не нужны, фильтрация у нас до показа кассиру
  • Ролевая модель LK — частично не нужна, большинство сотрудников с PK не работает вообще

В итоге — требований к Paykeeper становится сильно меньше. Они могут сосредоточиться на том, что умеют хорошо (приём платежа + фискализация), и не тратить ресурсы на моделирование ресторанного каталога. Это хорошо и им, и нам.

Оценка: хорошая ли идея

Короткий ответ

Да, но с несколькими «если».

Длинный ответ

Идея стратегически здоровая:

  1. Естественно вытекает из того, что мы уже строим для собственной франшизы.
  2. Рынок не маленький и не закрытый.
  3. Каждая фаза самоценна — если на полпути поймём, что полноценный POS — не наш путь, останемся с отличным ERP для собственной сети.
  4. Правильно разводит ответственность: мы не лезем в эквайринг и фискализацию, Paykeeper не лезет в ресторанный софт.
  5. Упрощает диалог с Paykeeper: требований меньше, их внедрять проще, есть шанс что они дойдут до P0 из нашего списка.

«Если» следующие:

  1. Если мы готовы к 1-2 годам работы до продукта, сопоставимого с iiko. Не за квартал.
  2. Если мы готовы к операционной нагрузке 24/7 поддержки реальных ТТ с живыми деньгами.
  3. Если мы удерживаем фокус и не уходим в сторону «давайте встроим в ERP ещё 10 функций вместо того чтобы добивать POS».
  4. Если бизнес-модель выстрелит — SaaS-подписка + процент с эквайринга. Сейчас это гипотеза, её нужно проверить на первых сторонних клиентах (после своей франшизы).

Альтернативы на полке

Если вдруг видение «стать R-keeper» окажется дороже, чем мы думали, есть другие пути:

  • Стать специализированным ERP для франшиз, оставаясь поверх iiko (интеграция с iiko-облаком). Узкая ниша, но меньше работы.
  • Позиционироваться как SaaS-учёт для мобильного общепита (coffee-to-go, фуд-корты) где mPOS и так работает — модификаторы не критичны, главное цена и скорость.
  • Слиться / партнёриться с существующим POS-разработчиком (Poster, Frontol) — они дают кассу, мы даём франшизную надстройку.

Но все эти варианты — план Б. План А — делать свою платформу — даёт самый большой потенциал.

Краткое резюме для разговора с Paykeeper

«Мы строим полноценную кассовую платформу — планируем, что наш софт будет работать на любых планшетах и моноблоках, как iiko или R-keeper.

В этой модели Paykeeper для нас — это специализированный партнёр по двум вещам: эквайринг и фискализация. Это те части, которые мы не хотим делать сами — они требуют банковской лицензии, сертификации PCI и 54-ФЗ, а у вас это уже есть.

Из наших P0-требований вам в такой конфигурации нужно закрыть только: webhook’и возвратов, API для сверки, тестовое окружение, фискальные реквизиты в уведомлении и управление сменой ФН. Всё остальное (модификаторы, иерархия, стоп-листы, прейскуранты, роли) мы делаем у себя — вы экономите ресурсы.

Для вас это означает устойчивый клиент: чем больше растёт наша сеть франчайзи, тем больше ТСП приводим вам. Для нас — вы надёжная фискальная часть стека. Win-win при условии что закроем минимальный список разрывов.»

Ссылки

  • Бизнесовое сравнение разрывов: business-summary.md
  • Технический gap-анализ: gap-analysis.md
  • Презентация архитектуры интеграции: _assets/paykeeper/presentation.html
  • Наш текущий стек: System Overview
  • Наш Catalog Service: Overview
  • Наша ролевая модель: Roles

Вид графа

Обратные ссылки