Замена POS на форке за одну ночь: как не потерять гостей, смены и чеки

Замена POS на форке за одну ночь: как не потерять гостей, смены и чеки

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

Сложность в том, что в ресторане «переключение» — это не просто установка нового софта на терминал. Это миграция справочников, меню, складов, скидочных и бонусных программ, истории смен, чеков и аналитики. Это перенастройка интеграций с эквайрингом, ЕГАИС, «Честным Знаком», службами доставки, программами лояльности и PMS, если в заведении есть гостиничный блок. И самое тонкое — это миграция данных о госте: бонусные балансы, карты лояльности, история заказов, предпочтения. Если эти данные потеряются или «поедут», бизнес получит волну негатива в первый же уикенд после перехода.

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

Почему замена POS — это не «поставим и поедем»

Что в реальности стоит за термином «POS»

Когда владелец говорит «у нас POS», он обычно имеет в виду кассовый интерфейс, в котором официант или кассир пробивает заказ. Но за этим экраном стоит связка из десятков подсистем: фронт кассы, сервер приложений, склад и товародвижение, производство и техкарты, управление персоналом и сменами, бонусные и скидочные механики, интеграции с ОФД и ЕГАИС, аналитика, выгрузки в 1С или в управленческий учёт. POS-система — это не программа, это операционная система бизнеса. И именно поэтому замена POS — это проект, а не задача.

Ошибка многих ресторанов в том, что они оценивают только «стоимость лицензии» и «стоимость оборудования», но не оценивают стоимость миграции. А миграция может занимать от двух недель до нескольких месяцев в зависимости от количества точек, количества SKU в меню и количества интеграций. У сетей замена POS — это всегда проект с бюджетом, с проектным менеджером, с датами и контрольными точками.

Чем форк отличается от «просто миграции»

Миграция — это когда мы уходим с платформы A на платформу B, у которой другой вендор, другие интерфейсы, другая серверная логика, другие форматы данных. Форк — это когда мы уходим на ответвление внутри той же экосистемы: например, с iiko на iikoCloud, с одного дистрибутива R-Keeper на другой, с одной редакции на другую, с локальной инсталляции на облачную или наоборот. Технически форк проще миграции между разными продуктами: меньше риск несовместимости справочников, проще перенос данных, легче сохранить привычные сценарии кассиров. Но и у форка есть свои подводные камни — особенно когда речь идёт о лицензировании, о форматах хранения данных и о несовместимости версий.

Где чаще всего «ломается» замена на форке

В практике 2026 года типичные точки сбоя выглядят так: касса открылась, а бонусные карты не читаются; скидка применяется, но итоговая сумма не сходится с чека; официант добавляет позицию, а кухня не видит её на KDS; закрытие смены проходит, но отчёт в бэк-офисе пустой; у гостя сгорает баланс лояльности, которого «не должно было быть»; ЕГАИС не видит акт списания; ОФД не получает чеки вовремя. Все эти сценарии — следствие одной большой причины: недостаточно проработанной карты интеграций и недостаточно протестированного сценария «типичный день».

Что нужно собрать до того, как вы нажмёте «обновить»

Полная карта текущей системы: процессы, справочники, интеграции

Первый шаг — не выбирать новый форк, а зафиксировать, что у вас есть сейчас. Это звучит банально, но именно здесь большинство проектов буксует: владелец не знает точного количества SKU, не помнит, какие скидки активны, не знает, какие интеграции живут «сами по себе». До форка нужна карта системы. Что в неё входит: количество кассовых терминалов и их конфигурация, схема зала и посадочных зон, перечень меню и модификаторов, схема складов и точек производства, перечень скидочных и бонусных механик, список интеграций (эквайринг, ОФД, ЕГАИС, «Честный Знак», доставки, CRM, PMS, BI, бухгалтерия, зарплата), регламенты работы кассиров и официантов.

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

Перечень того, что нельзя потерять ни при каких условиях

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

Команда проекта: кто за что отвечает

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

Как выбрать момент для замены и почему «ночью» — это не магия

Лучшие дни и часы для переключения

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

«Одна ночь» — это маркетинговый термин. По факту на форк нужно закладывать 6–10 часов активной работы плюс 24 часа на проверку. Если вы планируете замену за один календарный день без ночной работы — это нереалистично и почти всегда приводит к сбоям в первую смену.

Что делать, если «идеального окна» нет

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

Данные о госте: что переносить и как не потерять лояльность

Бонусные балансы, карты и статусы

Перенос данных о гостях — самая чувствительная зона проекта. Здесь нельзя «примерно» перенести, нельзя «с округлением», нельзя «потом разберёмся». Каждый гость, у которого есть баланс, статус или история — это конкретный человек, который придёт с вопросом, если его баланс исчез или стал меньше. Что должно быть перенесено идеально: ФИО и контактные данные, баланс бонусов, история начислений и списаний, активные статусы (например, уровень программы лояльности), действующие сертификаты и купоны, история заказов за аналитический период (обычно 6–12 месяцев), предпочтения и теги (аллергии, любимые позиции).

Перед переносом нужно сделать выгрузку из старой системы и сверку с эталонными отчётами. Если у вас 5 000 гостей в базе — нужно получить 5 000 строк с балансами и убедиться, что сумма совпадает с бухгалтерским отчётом. Если 50 000 — то же самое, только в Excel и с автоматической сверкой через контрольные суммы.

Скидки, акции и промокоды

Действующие скидки и промокоды — это частая зона потерь. Владелец думает, что у него «есть 5 видов скидок», а при выгрузке оказывается 47: автоматические скидки по времени, по количеству гостей, по статусу, промокоды от блогеров, акции 2 по цене 1.5, скидки по карте лояльности, скидки от суммы чека, скидки от менеджера, ручные скидки по согласованию. Каждая из них должна быть перенесена и проверена. Если промокод от блогера «перестал работать» после перехода — вы получите публичный скандал и возврат денег.

История заказов и предпочтения

История заказов не влияет на текущий день, но влияет на работу CRM, на сегментацию рассылок, на предложения в приложении. Если вы планируете использовать эти данные для маркетинга после перехода — переносите историю минимум за 12 месяцев. Если история используется только «для галочки» — можно ограничиться 3 месяцами и архивом.

Смены, чеки и склады: что должно сходиться до копейки

Текущая смена и незакрытые заказы

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

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

Складские остатки и инвентаризация

Перед форком нужна инвентаризация. Не выборочная, не «примерная», а полная, по всем складам и точкам производства. Складские остатки — это то, что вы не сможете «прикинуть на глаз», особенно если у вас несколько точек, у каждой свой склад, и кухня закупается по сложной схеме. Инвентаризация должна быть проведена за 1–3 дня до перехода, её результаты зафиксированы актом и использованы как стартовая точка в новой системе.

Если инвентаризация невозможна в принципе (например, вы работаете в режиме 24/7 и у вас нет окна для полного пересчёта) — тогда используйте остатки из старой системы и закладывайте «сверку» в первую неделю после перехода. Это допустимо, но требует ежедневного контроля.

Чеки, ОФД и фискальные данные

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

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

Интеграции: где форк чаще всего «роняет» смежные системы

Эквайринг и платежи

Эквайринговый терминал — это не «приложение», которое просто запускается на новом POS. Это внешнее устройство с собственным ПО, которое должно быть правильно подключено к новой кассе, проверено на тестовых платежах и закрытии смены. Если ваш эквайринг работает через интеграцию с POS (например, Сбербанк, Тинькофф, Альфа) — нужно убедиться, что новая версия POS поддерживает вашу модель терминала, что интеграция активирована, что тестовые платежи прошли и сверка закрылась.

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

ЕГАИС и «Честный Знак»

Алкоголь и маркированные товары — отдельная история. Если у вас в меню есть алкоголь, ЕГАИС должен корректно получать акты списания, остатки должны совпадать, журнал учёта должен вестись без разрывов. Любая ошибка в этом контуре — это потенциальный штраф при первой же проверке. Перед форком нужно: убедиться, что новая система поддерживает актуальную версию УТМ; провести тестовую продажу алкоголя с проверкой в личном кабинете ЕГАИС; проверить остатки и при необходимости провести инвентаризацию в ЕГАИС; убедиться, что у вас нет «зависших» актов.

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

Доставка, агрегаторы и внешние сервисы

Если вы работаете с Delivery Club, Яндекс Еда, СберМаркетом или с собственным сайтом доставки — каждая интеграция должна быть протестирована в новой системе. Типичные проблемы: заказы приходят, но не открываются на KDS; статусы не уходят обратно; цены в агрегаторе расходятся с POS; зоны доставки не совпадают; время приготовления не передаётся. Все эти сценарии нужно проверить на стенде до перехода.

CRM, программы лояльности и маркетинговые сервисы

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

Тестовые смены и «сухой прогон»

Зачем нужны две тестовые смены

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

Что должно быть в сценарии тестовой смены

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

Каждый шаг должен быть отмечен как пройденный или не пройденный. Если хотя бы один шаг не пройден — переход откладывается.

Роль кассиров и официантов в тестовых сменах

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

Ночь перехода: почасовой сценарий

За 2 часа до закрытия

За два часа до закрытия зала нужно прекратить приём новых заказов в режиме «с оплатой позже», проверить, что все столы закрыты или явно переведены в статус «переход», остановить приём броней через онлайн-формы (если они есть). Это не значит закрыть зал — это значит перевести его в режим «только оплата и уход».

За 30 минут до закрытия

За 30 минут до закрытия зала останавливается приём заказов на кухню, останавливается выдача, все гости обслуживаются в режиме «закрытие счёта и уход». Все кассы переводятся в режим X-отчёта, формируются промежуточные отчёты, сверяются остатки.

Закрытие смены и фиксация

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

Миграция данных: что и в каком порядке

Миграция начинается после закрытия смены и продолжается по заранее согласованному сценарию: выгрузка справочников из старой системы; конвертация в формат новой системы; загрузка в новую систему; проверка контрольных сумм; загрузка складских остатков; загрузка бонусных балансов; загрузка истории смен (если требуется); активация интеграций; настройка оборудования.

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

Утренняя проверка перед открытием

За 2–3 часа до открытия зала нужно провести полный сценарий тестовой смены в новой системе. Открыть смену, пробить по одному чеку в каждом сценарии, проверить печать, проверить связь с ОФД, проверить ЕГАИС, проверить эквайринг. Если что-то не работает — это последний шанс откатиться без последствий для бизнеса.

План отката: зачем он нужен, даже если «всё будет хорошо»

Что такое план отката

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

Триггеры отката — это конкретные события: кассы не открываются в течение X минут; ОФД не получает чеки; ЕГАИС не отправляет акты; кассиры не могут авторизоваться; складские остатки не загружены; бонусные балансы не работают. У каждого триггера должно быть пороговое значение: если не открываются 2 из 5 касс — это повод откатываться, если 1 из 5 — можно работать.

Когда откатываться поздно

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

Стоимость замены POS и как её посчитать честно

Прямые и скрытые расходы

Прямые расходы на замену POS — это лицензии, оборудование, работа интегратора, обучение персонала. Скрытые — это время управленческого состава, потеря аналитики в период миграции, скидки и компенсации гостям в случае сбоев, время простоя зала (даже минимальное), стоимость двойного учёта в период параллельной работы. Обычно скрытые расходы составляют от 20 до 50 процентов от прямых, и эту цифру нужно закладывать в бюджет.

Как обосновать стоимость перед владельцем

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

Типичные ошибки ресторанов при замене POS на форке

Ошибка первая: «мигрируем за неделю»

Одна из самых распространённых ошибок — попытка уложить весь проект в неделю. Это технически возможно только для очень маленьких заведений без сложных интеграций. Для сетей и для ресторанов со сложным меню срок должен быть не менее 6–10 недель, из которых 1–2 недели — на тестирование и параллельную работу.

Ошибка вторая: «интеграции доделаем потом»

Интеграции — это не та зона, которую можно доделать после запуска. Каждая интеграция, которая не проверена до перехода, — это потенциальный сбой в первую неделю. Особенно это касается интеграций с ЕГАИС, ОФД, эквайрингом и доставками. Параллельная работа нужна именно для того, чтобы поймать эти сбои до того, как они повлияют на гостей.

Ошибка третья: «обучим кассиров в день перехода»

Обучение кассиров и официантов — это отдельный проект, который должен начинаться за 2–4 недели до перехода. Нельзя обучить кассира работе с новой системе за 30 минут до открытия смены. Если вы так делаете — первая смена будет медленной, с ошибками, с негативом гостей и с очередями на кассе.

Ошибка четвёртая: «гостям ничего не скажем»

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

Ошибка пятая: «сделаем без проектного менеджера»

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

Чек-лист готовности к замене POS

За 8 недель до перехода

• Определён владелец проекта со стороны ресторана
• Выбран форк или новая система, подписаны документы
• Согласованы интеграции с вендором или интегратором
• Составлена карта текущей системы
• Определён список «нельзя потерять»
• Согласован бюджет проекта
• Начато обучение кассиров и официантов на ознакомительном уровне
• Определены даты тестовых смен

За 4 недели до перехода

• Завершена миграция справочников в тестовом контуре
• Проведены первые тестовые смены в лабораторных условиях
• Проверены интеграции на стенде
• Подготовлен сценарий тестовой смены
• Подготовлены материалы для обучения кассиров и официантов
• Начата миграция данных о гостях в тестовом режиме
• Согласован план отката
• Начата инвентаризация складов

За 2 недели до перехода

• Завершена миграция всех данных в тестовом контуре
• Проведена полная тестовая смена в боевых условиях (в минимальной нагрузке)
• Подготовлены инструкции для кассиров и официантов
• Проверены все интеграции на боевых данных
• Согласован график работ на ночь перехода
• Определена команда на ночь перехода
• Согласованы критерии отката
• Начата коммуникация с гостями (при необходимости)

За 1 неделю до перехода

• Завершена инвентаризация складов
• Получены контрольные выгрузки из старой системы
• Подготовлены все необходимые скрипты миграции
• Подготовлено резервное оборудование
• Согласован график поддержки в первую неделю после перехода
• Проведён финальный прогон сценария тестовой смены
• Подтверждены все роли в команде проекта

Ночь перехода

• Закрыта последняя смена в старой системе
• Сделаны все выгрузки и проверены
• Выполнена миграция данных по сценарию
• Проведены все проверки в новой системе
• Получены подтверждения по всем интеграциям
• Сформирован акт приёма-передачи данных
• Проведена утренняя проверка перед открытием
• Принято финальное решение о переходе

Первая неделя после перехода

• Ежедневная проверка ключевых интеграций
• Ежедневный контроль остатков
• Ежедневный контроль бонусных балансов
• Поддержка кассиров и официантов на местах
• Сбор обратной связи от гостей
• Фиксация всех инцидентов
• Подготовка отчёта по итогам первой недели

Как выбрать партнёра для форка

На что смотреть в первую очередь

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

На что смотреть: количество аналогичных проектов у партнёра за последние 12 месяцев; наличие выделенного проектного менеджера; готовность подписать SLA по срокам; наличие тестового контура; готовность к параллельной работе; наличие службы поддержки в первой половине дня после перехода.

Когда экономить на партнёре не нужно

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

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

Архивирование данных старой системы

Данные старой системы нельзя удалять сразу после перехода. Они должны быть заархивированы и храниться минимум 1 год (по требованиям законодательства о фискальных данных — до 5 лет). Архив должен быть доступен, читаем, и при необходимости восстановим. Если вы планируете использовать старую систему как резервную на период адаптации — не отключайте её сразу, оставьте в режиме «только чтение» на 2–4 недели.

Аналитика и история

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

Документация и знания

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

Юридические и договорные вопросы

Что должно быть зафиксировано в договоре

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

Как оформлять акты

Каждый этап проекта должен закрываться актом выполненных работ. Акт должен содержать перечень выполненных работ, перечень переданных данных, перечень подтверждённых интеграций, перечень замечаний и сроки их устранения. Без актов вы не сможете доказать, что проект был выполнен в полном объёме, и не сможете предъявить претензии по качеству.

Когда форк лучше отложить

Признаки того, что время не пришло

Бывают ситуации, когда лучше отложить замену POS, даже если формально всё готово. Признаки «не время»: высокий сезон с пиковой нагрузкой; отсутствие ключевых сотрудников в ближайшие 4–6 недель (отпуска, болезни); незавершённые проекты в других направлениях; текущие проблемы с выручкой или маржинальностью; отсутствие поддержки со стороны владельца или совета директоров. В таких случаях лучше подождать 2–3 месяца и провести форк в спокойное время.

Когда откладывать уже нельзя

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

Минимально жизнеспособный форк

Если времени и ресурсов мало

Бывают ситуации, когда времени и ресурсов мало, а замену нужно провести. В таких случаях работает схема «минимально жизнеспособного форка»: переносим только критичные данные (склады, бонусы, скидки); оставляем старую систему в режиме «только чтение» для архива; откладываем перенос истории аналитики; запускаем новую систему в ограниченном режиме (только основное меню, без сложных акций). Через 2–4 недели, когда система стабилизируется, переносим остальное. Эта схема хуже «идеальной» по качеству данных, но лучше «ничего не делать».

Связанные темы: что ещё стоит пересмотреть при замене POS

Программа лояльности

Замена POS — это хороший повод пересмотреть программу лояльности. Если у вас накопилось много устаревших механик, которые не работают как задумано, — лучше отключить их в новой системе и запустить заново. Гости это воспримут нормально, если вы правильно это объясните. Подобрать сервисы лояльности для нового стека — разумный следующий шаг, когда базовая миграция завершена.

Онлайн-меню и сайт

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

Системы бронирования

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

Доставка

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

Что делать, если форк «пошёл не так»

Первые признаки проблем

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

Как минимизировать ущерб

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

Как восстанавливать доверие гостей

Если сбой случился и гости пострадали (потеряли бонусы, получили дублированные чеки, не смогли оплатить привычным способом) — нужно восстанавливать доверие. Базовый набор действий: публичное объяснение ситуации (на кассе, в соцсетях, в рассылке); компенсации (бонусы, скидки на следующий визит, бесплатные блюда); при необходимости — звонки постоянно пострадавшим гостям. Восстановление доверия — это не «сделаем вид, что ничего не было», это «признали, компенсировали, объяснили».

Итоги: кратко о главном

Замена POS на форке — это управляемый проект, если к нему правильно подготовиться. Главное — не скорость, а качество. Скорость важна только в том смысле, что затянутый проект увеличивает стоимость и риски. Но ускорение за счёт качества — это путь к сбоям.

Ключевые принципы успешного форка: проектный подход с владельцем и планом; карта текущей системы до начала работ; разделение данных на критичные и некритичные; параллельная работа для проверки интеграций; минимум две тестовые смены с реальными кассирами; план отката с критериями и временем; обучение персонала за 2–4 недели; коммуникация с гостями; первая неделя после перехода как режим повышенного контроля.

Если вы только планируете замену POS и пока выбираете направление — начните с сравнения вариантов в каталоге, посмотрите на доступные платформы автоматизации и на партнёров по интеграции iiko или R-Keeper в зависимости от вашего текущего стека. Это не обязывает к выбору, но даёт понимание того, какие варианты есть на рынке в текущем году и какие из них подходят под ваш формат.

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