Что вы отдаёте вместе с поддержкой коробки
Компания живёт с коробочным Битрикс24 три-четыре года. Сначала портал вёл штатный системный администратор, потом он ушёл, часть работ подхватил приходящий подрядчик, потом подрядчик сменился. К моменту, когда руководитель решает окончательно передать поддержку коробки на аутсорс, никто внутри компании уже не может ответить на простые вопросы. Где лежат бэкапы. Кто оплачивает продление лицензии. Какие доработки писались под нас и есть ли на них исходники.
Аутсорс битрикс24 в такой ситуации выглядит спасением, и часто им и является. Но передача поддержки коробки устроена иначе, чем передача облака. В облаке инфраструктура и данные остаются у вендора, подрядчик получает доступ к порталу и на этом его влияние заканчивается. В коробке к подрядчику уходит сервер, база данных, файловая система, лицензионный ключ и весь код ваших доработок. Отдать это можно за один разговор. Вернуть получается не всегда.
Дальше по пунктам то, что мы проверяем, когда берём чужую коробку на сопровождение, и то же самое советуем проверять клиентам, когда они передают систему кому-то ещё.
Из чего состоит коробка, кроме портала
Руководителю кажется, что система это то, что видно в браузере: сделки, задачи, чаты, отчёты. Технически коробочный Битрикс24 состоит из нескольких слоёв, и контроль теряется по каждому отдельно.
Первый слой, сервер и системное окружение. Чаще всего это BitrixVM, сборка с преднастроенными веб-сервером, PHP и базой данных. Обновление окружения идёт отдельно от обновления самого продукта, это разные работы. Доступ к серверу даёт доступ вообще ко всему: к файлам, к базе, к почтовым настройкам, к архивам копий.
Второй, файлы продукта и пользовательские данные. Загруженные документы, вложения в задачах, файлы Диска физически лежат на вашем сервере. У большого портала это сотни гигабайт.
Третий, база данных. Клиенты, сделки, история переписки, счета. Копия базы это копия коммерческой информации компании, со всеми контактами и суммами.
Четвёртый, лицензионный ключ. Он привязан к юрлицу-покупателю, и от него зависит право на обновления и работа заметной части функций.
Пятый, кастомные доработки. Свои модули, обработчики событий, шаблоны, интеграции с 1С и внешними сервисами. Именно этот слой обычно и оказывается тем чёрным ящиком, из-за которого потом невозможно спокойно сменить подрядчика.
Передавая поддержку, вы отдаёте доступ ко всем пяти слоям сразу. Значит и фиксировать состояние надо по всем пяти.
Пять мест, где контроль утекает незаметно
Учётные записи оформлены на подрядчика. Хостинг куплен с корпоративной карты интегратора, домен зарегистрирован на его сотрудника, доступ к панели управления сервером есть только у него. Юридически инфраструктура вашей CRM принадлежит другой компании. Пока отношения ровные, это никак не мешает. При конфликте вы теряете не портал, а возможность вообще к нему подойти.
Бэкапы делает подрядчик и хранит их у себя. Схема работает ровно до дня, когда подрядчик пропадает. В коробочном Битрикс24 регулярное резервное копирование по умолчанию выключено, его настраивают руками, и настраивает обычно тот, кто ведёт систему. Проверить, что копии реально создаются и разворачиваются, заказчику в голову приходит редко.
Доработки живут без документации. Код лежит на сервере, но никто не знает, какой файл за что отвечает и почему полгода назад сделали именно так. Формально исходники у вас есть. Фактически новый подрядчик будет разбираться в них за ваши деньги и ваше время.
Лицензия продлевается через подрядчика, и вы не видите документов. Ключ куплен и продлевается на его юрлицо, счёт вам выставляется общей строкой. В момент разрыва отношений выясняется, что переоформление ключа это отдельная процедура со своими сроками, а не строчка в акте.
Вся коммуникация в мессенджере. Задачи ставятся голосом и сообщениями, ничего не фиксируется. Через год никто не помнит, что просили сделать, что сделали и что обещали, но не сделали. Без письменной истории вы не можете ни оценить качество работы, ни предъявить претензию.
Инвентаризация перед передачей
Перед тем как подписывать договор с новым подрядчиком, соберите паспорт системы. Это документ на две-три страницы, который живёт у вас, а не у исполнителя.
В нём должно быть:
- Где физически размещён портал: провайдер, тарифный план, на кого оформлен договор, кто платит.
- Редакция и количество пользователей по лицензии, дата окончания периода активности ключа, на какое юрлицо оформлена покупка.
- Версия продукта и версия окружения на текущий момент.
- Схема резервного копирования: что копируется, куда, как часто, сколько хранится, когда последний раз проверяли восстановление.
- Список интеграций: 1С, телефония, мессенджеры, сайт, банки. Для каждой указано, кто её делал и где живут ключи доступа.
- Перечень доработок с коротким описанием бизнес-задачи каждой. Не техническое описание, а зачем это вообще было нужно.
- Список людей с административными правами в портале и на сервере.
На сбор такого паспорта уходит от нескольких часов до недели, если систему вели небрежно. Это дешевле, чем восстанавливать картину в момент аварии, когда портал лежит и все нервничают.
Доступы: дать возможность работать, не отдавая всё
Главная ошибка при передаче: отдать один общий администраторский аккаунт и забыть о нём. Разумнее разделить.
Именные учётные записи вместо общих. Каждый сотрудник подрядчика заходит под своим логином. Тогда в журналах видно, кто и что менял, а при смене человека в команде исполнителя вы отключаете одну запись, а не меняете общий пароль по всей инфраструктуре.
Владение остаётся у вас. Договор с хостингом, домен, аккаунт в личном кабинете 1С-Битрикс оформлены на вашу компанию, оплата идёт с ваших счетов. Подрядчику вы даёте доступ, но не собственность. Если исполнитель настаивает, что так удобнее, стоит уточнить, кому именно удобнее.
Разграничение прав внутри портала. Административные права в Битрикс24 нужны для настройки, но не нужны для ежедневных мелких правок. Часть работ спокойно делается с ограниченными правами. Чем меньше людей с полным доступом, тем понятнее, кто отвечает за изменения.
Один администраторский доступ остаётся внутри компании. У вас должен быть человек, пусть не технический, пусть это финансовый директор или помощник руководителя, у которого есть свой административный вход и который знает, где лежит паспорт системы. Это страховка от ситуации «подрядчик не отвечает третий день».
И отдельно про людей, которые уже ушли. При смене подрядчика почти всегда обнаруживаются живые доступы прежней команды и бывших сотрудников: активные учётки в портале, ключи на сервере, сохранённые пароли к хостингу. Никто их не отзывал просто потому, что этим никто не занимался. Ревизия списка тех, кто может зайти в систему, стоит один вечер работы и делается в момент передачи, пока предыдущий исполнитель ещё на связи и может подсказать, чей это доступ и зачем он создавался.
Мы в B2BPRO.KZ при приёме чужой коробки на сопровождение первым делом просим завести нам именные доступы и оставить владельческие учётки клиенту. Это снимает половину будущих споров о том, кто что сделал с системой.
Лицензия и обновления: делегировать можно, не глядя нельзя
Лицензия коробочного Битрикс24 действует 12 месяцев, после чего её нужно продлевать на следующий период. Льготное продление доступно не ранее чем за 90 дней до окончания периода активности и в течение 15 дней после. Окно ограничено, и пропустить его вполне реально, если за датой никто не следит.
Что происходит, если ключ всё-таки истёк. Портал продолжает работать, данные никуда не деваются, но отваливается заметная часть функций. Становится недоступно обновление продукта в административном интерфейсе и получение новых дистрибутивов. Перестаёт работать Маркетплейс: ни поставить модуль, ни обновить установленный. Отключается облачная телефония, публикация сайтов и CRM-форм, открытые линии кроме онлайн-чата, чат-боты, облачный бэкап. REST-методы и события перестают отрабатывать, за исключением входящих вебхуков. Техническая поддержка вендора оказывается только при активном ключе.
Для компании, у которой на портале висит телефония и поток заявок с сайта, это означает остановку продаж на несколько дней, пока идёт оплата и активация. Поэтому дату окончания лицензии держите в собственном календаре, а не только в почте подрядчика. Напоминание за 90 дней это минимум.
Отдельный разговор про обновления самого продукта и окружения. Обновление ядра на живой системе с доработками рутиной не бывает: сначала бэкап, потом обновление на копии, проверка кастомного кода, только затем боевой сервер. Если подрядчик обновляет вас на лету в рабочее время, это говорит об отсутствии процесса. Обратная крайность не лучше. Подрядчик, который годами не обновляет систему, чтобы ничего не сломать, загоняет вас в угол: разрыв между вашей версией и текущей растёт, и однажды обновление превращается в проект на месяц.
Регламент: что должно приходить вам каждый месяц
Контроль над системой держится не на техническом понимании руководителя, а на регулярной отчётности, которую можно прочитать без специальных знаний.
Минимальный набор, который стоит прописать в договоре:
- Единая точка приёма заявок. Не личный мессенджер конкретного специалиста, а канал, где заявка регистрируется и получает номер. Тогда видно и количество обращений, и скорость реакции.
- Время реакции и решения по типам обращений. Портал не открывается, это одно время. «Хочу новое поле в сделке», совсем другое. Одинаковый срок для всего означает, что сроков нет.
- Ежемесячный отчёт о работах: список выполненных задач человеческим языком, потраченные часы, планы на следующий месяц.
- Отчёт о состоянии инфраструктуры: свободное место на диске, дата последнего успешного бэкапа, дата последней проверки восстановления, текущая версия продукта и окружения, дата окончания лицензии.
- Журнал изменений системы. Любая правка кода или настройки, влияющая на работу портала, фиксируется: что менялось, зачем, кто согласовал.
Отдельный пункт про проверку восстановления. Резервная копия, которую ни разу не разворачивали, остаётся предположением до первой попытки её использовать. Раз в квартал бэкап должен разворачиваться на тестовом окружении, и факт проверки должен попадать в отчёт. Другого способа заранее узнать, что схема рабочая, просто нет.
Первые тридцать дней с новым подрядчиком
Период приёмки показателен сам по себе. Команда, которая берёт систему на сопровождение всерьёз, в первый месяц занимается разбором того, что ей досталось. Если вам с ходу предлагают доработки и автоматизацию, а про состояние сервера не спрашивают, это плохой знак.
Что разумно ожидать в течение первого месяца:
- Аудит инфраструктуры и портала в виде письменного документа: где размещена система, какие версии, сколько места, состояние копий, срок лицензии, найденные проблемы с приоритетами.
- Независимая резервная копия до любых изменений, лежащая отдельно от боевого сервера, с подтверждённым разворачиванием.
- Карта кастомного кода хотя бы поверхностная: какие модули есть, что они делают, что может сломаться при обновлении.
- Наведение порядка в доступах: именные учётки, отключение записей людей, которые давно не работают, проверка, кто из сотрудников имеет административные права и почему.
- Согласованный план на квартал: что чинится в первую очередь, что откладывается, какие работы требуют окна и простоя.
Дальше приёмка переходит в обычный ритм: заявки, плановые работы, ежемесячный отчёт. Но то, с чего подрядчик начал, о его подходе говорит больше, чем портфолио.
Как это выглядит на практике
Пример ниже собран из типичных ситуаций и не описывает конкретного клиента.
Производственная компания, около 120 сотрудников, коробочный Битрикс24 с интеграцией с 1С и телефонией. Систему семь лет вёл штатный админ, потом уволился, полгода портал жил сам по себе. Руководитель решает передать поддержку внешней команде.
На этапе аудита выясняется, что сервер оформлен на личный аккаунт уволившегося сотрудника, а оплата уходила с корпоративной карты и продолжает уходить. Регулярное резервное копирование включено, но копии складываются на тот же диск, что и сам портал, так что при отказе диска теряется и система, и архив. Версия продукта отстаёт на два с лишним года. Интеграция с 1С написана как собственный модуль, документации нет, комментариев в коде почти нет. Лицензия истекает через пять недель, письма о продлении приходили на почту уволившегося сотрудника.
Порядок действий здесь почти всегда одинаковый. Сначала продление лицензии, потому что через пять недель встанут телефония и заявки с сайта, а это самый дорогой риск. Параллельно переоформление хостинга на компанию и создание внешней копии данных, чтобы появилась хоть одна точка отката. Затем разбор интеграции с 1С и описание её на бумаге: что откуда берётся, что куда пишется, при каких условиях ломается. И только после этого обновление продукта, поэтапно, с прогоном на копии.
Такой заход занимает шесть-восемь недель и выглядит скучно, потому что бизнес в это время не получает новых функций. Зато к концу периода у компании впервые за годы есть понятная картина собственной системы: где она лежит, кто ею владеет, как её восстановить.
Если нужен разбор текущего состояния портала перед сменой подрядчика, это стандартная часть работы, с которой начинается наше внедрение и настройка Битрикс24 и сопровождение уже работающих систем.
План выхода пишут в начале, а не в конце
Пункт, который заказчики пропускают чаще всего. Договор подробно описывает, как подрядчик начинает работать, и молчит о том, как он заканчивает.
Стоит прописать заранее:
- Срок передачи дел. Сколько дней после уведомления исполнитель обязан отвечать на вопросы преемника.
- Состав передаваемого: исходники всех доработок, описание архитектуры интеграций, актуальные доступы, схема бэкапов, обновлённый паспорт системы.
- Отзыв доступов. Кто и в какой срок отключает учётные записи подрядчика после завершения работ. Забытая активная учётка бывшего исполнителя это типовая дыра.
- Принадлежность результата. Права на код, написанный по вашему заказу и за ваши деньги, должны быть у вас. Формулировка «исполнитель предоставляет право использования» означает совсем другое, и разница вылезет ровно в тот момент, когда вы захотите отдать код другой команде.
Хороший исполнитель на такие пункты соглашается спокойно: они защищают и его тоже, потому что убирают почву для претензий после расставания. Сопротивление на этом этапе само по себе многое говорит.
Передача коробочного Битрикс24 на аутсорс перестаёт быть риском в тот момент, когда вы понимаете, чем именно владеете, и можете это забрать. Выбор команды и рабочий регламент поправимы почти всегда. Утраченные доступы к собственному серверу поправимы далеко не всегда.
Частые вопросы
Чем аутсорс поддержки коробки отличается от поддержки облачного Битрикс24?
Объёмом ответственности. В облаке вендор отвечает за инфраструктуру, обновления и доступность сервиса, подрядчик занимается настройкой портала. В коробке сервер, база, бэкапы, обновления продукта и окружения находятся в зоне исполнителя. Соответственно и требования к нему выше, и риск при плохой передаче дел больше.
Можно ли передать поддержку, если предыдущий подрядчик не выходит на связь?
Да, если у вас остались владельческие доступы к хостингу, домену и личному кабинету, где числится лицензия. Тогда новая команда заходит на сервер и разбирается с системой. Если доступов нет вообще, начинается восстановление прав через провайдера и регистратора, и это уже юридическая история на недели.
Нужно ли держать своего администратора, если поддержка на аутсорсе?
Технического специалиста держать не обязательно. А вот ответственный за систему со стороны компании нужен. Это человек, который принимает работы, хранит паспорт системы, следит за датой лицензии и имеет собственный административный доступ. Роль тут управленческая, а глубоко разбираться в технике ему не требуется.
Как понять, что подрядчик реально делает бэкапы?
Попросить развернуть копию на тестовом окружении и показать результат. Не отчёт о том, что копия создана, а работающий портал из этой копии. Раз в квартал такой проверки достаточно, и она должна быть прописана в регламенте.
Что делать, если лицензия уже истекла?
Продлевать. Данные и портал при истечении ключа сохраняются, но обновления, Маркетплейс, облачная телефония, публикация форм и сайтов, часть REST-функций и поддержка вендора становятся недоступны. Чем дольше система живёт без ключа, тем больше накапливается разрыв в версиях и тем дороже обходится последующее обновление.