Руководство по выбору подрядчика для отрасли «Рестораны и общепит»

Для кого: Руководителям, которые выбирают команду разработки или интегратора и хотят снизить риски. · Формат: PDF, 18 страниц, опросник для встреч и чек-лист договора

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

Третий — готовность обсуждать ограничения. Подрядчик, который на первой встрече называет риски и допущения, обычно надёжнее того, кто обещает всё сразу.

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

Ответы полезно фиксировать письменно: они становятся основой договора и помогают избежать расхождений в ожиданиях.

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

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

Материал адаптирован под отрасль «Рестораны и общепит»: ниже — задачи, которые мы учитываем и на которые опираемся при разборе.

• Стоп-лист узнают в зале, а не на сайте — Блюдо закончилось, но сайт, приложение и агрегаторы продолжают принимать заказы — гость ждёт звонка с извинениями.
• Меню живёт в пяти местах сразу — Цены и состав правят отдельно на сайте, в агрегаторах, в кассе и в соцсетях, поэтому расхождения копятся и путают гостей.
• Заказы из агрегаторов вводят руками — Кассир переносит заказ с планшета в кассу, ошибается в адресе и модификаторах, а время приготовления растёт.
• Брони и посадка ведутся в тетради — Хостес не видит загрузку зала на вечер, а двойные брони и неявки обнаруживаются уже в час пик.
• Лояльность не переживает смену системы — Бонусы и карты гостей остаются в старой кассе, поэтому запустить акцию без потери базы не получается.