Подрядчик пропал: как ресторану заранее закрепить в договоре доступ к данным, исходникам и аварийному восстановлению сервиса

Подрядчик пропал: как ресторану заранее закрепить в договоре доступ к данным, исходникам и аварийному восстановлению сервиса

Представьте: ваша сеть из трёх кофеен работает на сайте, который два года назад сделал внешний разработчик. Всё устраивало, пока в один из понедельников сайт не открылся. Вы звоните подрядчику — телефон молчит, в мессенджере «был(а) недавно», но ответа нет. Домен, который вы считали своим, зарегистрирован на него. Хостинг тоже оформлен на его почту. Исходники сайта лежат в его личном репозитории. Через неделю вы узнаёте, что он уехал и больше не планирует работать. Знакомая история? Для ресторанного бизнеса она заканчивается не только потерей сайта, но и остановкой онлайн-заказов, потерей базы гостей и проблемами с контрольно-кассовой техникой.

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

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

Почему ресторан остаётся один на один с проблемой

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

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

Зависимость от одного подрядчика — это операционный риск

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

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

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

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

В-третьих, это сам код: сайт, мобильное приложение, скрипты интеграций. Если исходники не переданы, любой другой разработчик будет вынужден восстанавливать их с нуля. А это месяцы работы и деньги. В-четвёртых, это доступы: домен, хостинг, SSL-сертификаты, аккаунты в сервисах доставки, платёжные шлюзы. Если они оформлены на подрядчика, вы не можете даже перенести сайт на другой хостинг, потому что не имеете доступа к DNS.

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

Какие системы ресторана чаще всего зависят от внешних подрядчиков

Чтобы правильно оценить риски, полезно составить полный список цифровых систем, которые использует ресторан. Обычно в него входят: сайт с меню и онлайн-заказом; мобильное приложение (собственное или на базе конструктора); кассовая программа и POS-система; интеграция с агрегаторами доставки (Яндекс Еда, Delivery Club и другие); CRM-система с базой гостей; программа лояльности; система бронирования столиков; платёжный шлюз для оплаты счёта; сервисы чаевых; система отзывов.

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

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

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

Права на данные и интеллектуальную собственность

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

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

Отдельно — данные. В договоре нужно указать, что все данные о гостях, заказах и операционной деятельности принадлежат заказчику. Подрядчик обрабатывает их только в рамках оказания услуг и не вправе использовать их для своих целей. Также должно быть предусмотрено право заказчика в любой момент запросить выгрузку данных в открытом формате (JSON, CSV, Excel) и обязанность подрядчика передать эту выгрузку в течение определённого срока (например, 5 рабочих дней).

Доступ к инфраструктуре и учётным данным

Даже если права на код и данные зафиксированы, без доступа к инфраструктуре они бесполезны. Представьте, что вы владелец домена, но не можете зайти в настройки DNS, потому что аккаунт на регистраторе оформлен на подрядчика. Формально домен ваш, но фактически управляете не вы. Поэтому в договоре нужно обязать подрядчика предоставлять заказчику доступы ко всем учётным записям, которые используются в рамках проекта: хостинг, регистратор домена, SSL-сертификаты, панель управления сервером, репозиторий кода, аккаунты в сервисах доставки, платёжный шлюз и так далее.

Желательно, чтобы доступы были оформлены на корпоративную почту заказчика, а не на личную почту сотрудника подрядчика. Но даже если это невозможно, в договоре должна быть обязанность подрядчика передать логины и пароли в момент подписания акта или хранить их в защищённом менеджере паролей, доступ к которому есть у заказчика. Также стоит предусмотреть, что подрядчик не вправе менять пароли без уведомления заказчика, а в случае расторжения договора обязан передать актуальные доступы в течение 24–72 часов.

Source code escrow: как работает и когда пригодится

Для ресторанного бизнеса, который использует сложную интеграцию с доставкой или собственную CRM, потеря исходного кода может стать фатальной. Если подрядчик пропал, а исходники не переданы, восстановить систему будет крайне сложно. Один из способов защититься — это депонирование исходного кода (source code escrow). Суть в том, что подрядчик передаёт актуальную версию исходного кода на хранение в нейтральную третью сторону (эскроу-агента). Заказчик получает доступ к этому коду только при наступлении определённых обстоятельств: банкротство подрядчика, прекращение деятельности, неисполнение обязательств, отказ от поддержки.

Для ресторана это выглядит так: вы платите за разработку, подрядчик работает, а код лежит в депозитарии. Если всё хорошо, вы про этот код не вспоминаете. Если подрядчик пропадает — вы обращаетесь к эскроу-агенту, подтверждаете наступление обстоятельств (например, отсутствие связи в течение 10 дней) и получаете доступ к исходникам. Дальше вы можете передать их другому разработчику или компании на поддержку.

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

Передача дел и переходный период

Даже если подрядчик не пропал, а просто вы решили сменить исполнителя, вам нужен механизм передачи дел. В договоре должен быть раздел о переходном периоде, в течение которого подрядчик обязан оказывать содействие новому исполнителю: отвечать на вопросы, передавать документацию, объяснять архитектуру. Обычно это 30–90 дней после расторжения договора. За это время новый подрядчик должен разобраться в коде и запустить проект на своей инфраструктуре.

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

Что должно быть в техническом задании и актах

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

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

Ответственность подрядчика за утрату данных

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

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

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

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

Документация и инструкции, которые должны лежать у вас

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

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

Резервные копии и тесты восстановления

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

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

Назначение ответственных и внешних подрядчиков

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

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

Как провести аудит текущего подрядчика

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

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

Что делать, если подрядчик уже пропал

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

Первые шаги: зафиксировать факт и собрать доказательства

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

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

Технические меры: доступы, хостинг, домены

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

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

Юридические меры и досудебная работа

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

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

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

Кейс: как ресторан потерял доступ к домену

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

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

Чек-лист: проверьте договор до подписания

Чтобы вы могли проверить свой текущий договор или подготовиться к переговорам с новым подрядчиком, вот краткий чек-лист. Отметьте, какие пункты уже есть, а каких не хватает.

• [ ] Исключительные права на код и дизайн переходят к заказчику после полной оплаты.
• [ ] Данные о гостях, заказах и операционной деятельности принадлежат заказчику.
• [ ] Подрядчик обязан предоставить выгрузку данных в открытом формате по первому требованию.
• [ ] Все доступы (домен, хостинг, сервер, репозиторий, сервисы) оформлены на заказчика или передаются ему в течение 24–72 часов.
• [ ] Предусмотрено депонирование исходного кода (source code escrow) с правом доступа при наступлении определённых обстоятельств.
• [ ] Подрядчик обязан передать полную документацию и исходники при расторжении договора.
• [ ] Переходный период для передачи дел составляет не менее 30 дней.
• [ ] Установлена ответственность за просрочку передачи данных или исходников (неустойка).
• [ ] Подрядчик не вправе привлекать субподрядчиков без письменного согласия заказчика.
• [ ] Все изменения в проекте оформляются дополнительными соглашениями.
• [ ] Подрядчик обязан уведомлять о смене реквизитов, адреса электронной почты и других контактных данных.
• [ ] Договор содержит условие о конфиденциальности и защите персональных данных.

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

Вывод

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

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

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