Смена подрядчика битрикс24 начинается не с портала, а с описи
Когда компания решает поменять интегратора, первым делом обычно просят «отдать доступы». Просьба звучит логично, но она почти всегда неполная. Доступы — это логин и пароль, а работающий портал состоит из десятков связей, часть которых не видна в интерфейсе и не описана нигде, кроме головы человека, который их настраивал. На этих невидимых связях миграция и спотыкается: доступы передали за час, а через неделю выяснилось, что перестали приходить заявки с сайта, потому что вебхук был создан от учётки уволившегося сотрудника подрядчика.
Поэтому передача портала другому интегратору — это в первую очередь инвентаризация, и только потом смена паролей. Ниже тот порядок действий, по которому мы принимаем чужие порталы на сопровождение, с указанием, где Битрикс24 помогает выгрузить настройку кнопкой, а где придётся описывать руками.
Что реально передаётся при смене подрядчика
Портал удобно разложить на слои, каждый из которых передаётся по-своему.
Первый слой — права и учётные записи: кто главный администратор, у кого ещё есть права администратора, какие сотрудники подрядчика заведены как пользователи портала и что с ними делать после расставания.
Второй — интеграции: вебхуки, локальные приложения, решения из Маркета. У каждого есть автор, набор прав и сценарий, ради которого он создан.
Третий — автоматизация: роботы и триггеры в воронках, шаблоны бизнес-процессов, правила смарт-процессов. Часть выгружается файлом, часть только скриншотами и описанием.
Четвёртый — данные: сделки, контакты, компании, товары, документы. Их никто никуда не передаёт, они остаются в портале, но выгрузка перед началом работ нужна как страховка.
Пятый — инфраструктура. Для облака это почтовые ящики, домен, телефония. Для коробки сервер, лицензионный ключ, доступ к обновлениям, бэкапы.
Шестой слой самый неудобный: знание. Почему воронка устроена именно так, что означает поле «Статус согласования 2», какие сделки нельзя закрывать вручную. Это не выгружается ничем.
Если новый подрядчик берётся за портал, не пройдя все шесть слоёв, работа быстро превращается в археологию за ваш счёт: каждая вторая задача начинается со слов «нам нужно разобраться, как это было настроено».
Права администратора: с чего начинают и что не отдают никогда
Роль главного администратора портала стоит особняком, и вокруг неё чаще всего возникает путаница. Главный администратор в Битрикс24 один. На коммерческих тарифах эту роль можно передать другому пользователю: другой администратор заходит в профиль текущего главного администратора, нажимает «Администратор» → «Забрать права администратора» и подтверждает действие кнопкой «Да, отправить». Текущему главному администратору приходит сообщение от Админ-бота, где он нажимает «Передать права», вводит в поле подтверждения слово «Передать» и нажимает «Подтвердить». Без этого подтверждения роль не перейдёт.
Если главный администратор недоступен, уволился, потерял доступ к почте или просто не выходит на связь, сценарий усложняется. На коммерческих тарифах, кроме Базового, текущий главный администратор должен сначала назначить нового администратора. На Базовом права другому сотруднику выдаются вручную. Практический вывод простой: если роль главного администратора висит на сотруднике подрядчика, вы зависите от его доброй воли ровно в тот момент, когда отношения уже испортились.
Из этого следует правило, которое мы просим соблюдать всех клиентов: главный администратор должен быть сотрудником заказчика. Директор, руководитель ИТ, финансовый директор, кто угодно из штата. Подрядчику достаточно обычных прав администратора, их хватает на любые настройки, и снимаются они в один клик, без переписки с Админ-ботом.
Если сейчас главный администратор — представитель прежнего подрядчика, передачу роли ставьте первым пунктом плана. Всё остальное можно доделать позже, а вот эту операцию невозможно провести без второй стороны.
Инвентаризация интеграций: раздел «Разработчикам»
Дальше идём в раздел «Приложения» → «Разработчикам». Там три вкладки: «Готовые сценарии», «Интеграции» и «Статистика».
Главная для нас «Интеграции». Это единый список созданных вебхуков и приложений, где видно название, автора, права доступа, события и виджеты. По сути, карта всех внешних связей портала: сайт, 1С, сервис звонков, мессенджеры, самописные скрипты.
Здесь же кроется грабля, из-за которой миграции проваливаются молча. Секретные коды чужих вебхуков недоступны даже администратору портала. Вы видите, что вебхук существует, видите его права, но прочитать ключ не можете. Если администратор попробует отредактировать чужой вебхук, секретный код сбрасывается, а владение переходит к нему. Все внешние системы, которые обращались по старому ключу, перестают работать в ту же секунду.
Порядок действий из этого вытекает сам. Сначала выписываем весь список интеграций с правами и авторами. Затем по каждой выясняем, что на другом конце: какой сайт, какой скрипт, какой сервис. И только потом, уже зная, куда прописан ключ, переоформляем вебхук и сразу же меняем ключ в системе-потребителе. Не наоборот.
Проверка после каждого переключения должна быть предметной, а не «вроде работает». Для формы на сайте это тестовая заявка, которая доехала до нужной воронки с правильным источником. Для телефонии входящий и исходящий звонок с записью, привязанной к карточке. Для мессенджеров сообщение в оба конца, включая ответ из портала клиенту. Для обмена с учётной системой один документ, проведённый целиком, а не просто отсутствие ошибки в логе. Отсутствие ошибки часто означает, что вызов вообще не дошёл.
Вкладка «Статистика» помогает отделить живое от мёртвого: там видны данные о ежедневных REST-запросах и метрики по отдельным вебхукам. Интеграция, которая не выполнила ни одного запроса за месяц, скорее всего, давно не используется. Выключать её всё равно стоит после разговора с бизнесом, а не по одному графику.
Удалять интеграции может администратор портала или создатель интеграции, причём удаление полное: вместе с интеграцией уходят все её компоненты. Поэтому чистку оставляют на конец миграции, когда уже понятно, что чем занималось.
Автоматизация: что выгружается файлом, а что описывается руками
Шаблоны бизнес-процессов Битрикс24 умеет выгружать и загружать: в дизайнере бизнес-процессов есть кнопки «Экспорт» и «Импорт», файл сохраняется в формате .bpt. Ограничения тоже надо знать заранее. Переносить можно только шаблоны одного типа, шаблон бизнес-процесса CRM не встанет в бизнес-процессы ленты. При импорте создаются все поля сущности, из которой делали экспорт, независимо от того, участвуют они в самом процессе или нет. На чужом портале это оборачивается десятками лишних полей, так что импорт «на всякий случай» лучше не делать.
Экспорт шаблонов нужен не столько для переезда, сколько для архива. Даже если вы никуда не переносите портал, сохранённые .bpt-файлы страхуют вас на случай, когда кто-то поправит рабочий процесс и сломает его.
А вот роботы и триггеры в воронках CRM кнопкой «выгрузить всё» не отдаются. Их придётся описывать: стадия, событие, действие, условия. Мы обычно делаем это таблицей: воронка, стадия, робот, что делает, кому уходит результат. Занудно, но именно эта таблица потом экономит недели, когда бизнес приходит с вопросом «почему клиенту ушло два письма подряд».
Отдельно фиксируйте всё, что завязано на конкретных людей: ответственные по умолчанию, получатели уведомлений, согласующие в бизнес-процессах. При смене подрядчика часть этих ссылок указывает на учётки, которые вы вот-вот отключите. Если не пройтись по ним заранее, процессы начнут падать не в момент отключения, а через несколько дней, когда очередная сделка дойдёт до нужной стадии.
Данные: экспорт как страховка, а не как способ переезда
Одно уточнение снимает половину тревоги: при смене подрядчика данные никуда не едут. Портал остаётся тот же, сделки и контакты на месте, вы меняете только людей, которые его обслуживают. Экспорт нужен по другой причине, как точка отката перед тем, как новая команда начнёт что-то менять.
Выгрузка делается штатно. Открываете нужный раздел CRM, лиды, сделки, контакты или компании, переключаетесь в вид «Список», при необходимости применяете фильтр, чтобы выгрузить только нужные элементы, через настройки выбираете поля для экспорта и формат. XLS удобен для анализа и построения диаграмм, CSV представляет собой простой текстовый файл со значениями через запятую, который открывается чем угодно. У контактов есть отдельная опция «Участвует в экспорте»: выгружаются только те, у кого она включена, и переключать её можно как в карточке, так и групповым действием.
Сделайте такую выгрузку по всем основным сущностям в день начала работ и положите в отдельную папку с датой. Это пять минут работы, и это единственный способ через месяц доказать, что поле «Источник» раньше заполнялось, а теперь нет.
Коробочный Битрикс24: сервер важнее портала
С коробкой список передаваемого шире, потому что к порталу добавляется инфраструктура. Нужны доступы к серверу: SSH, панель управления, база данных. Нужен доступ к домену и сертификату. Нужно понимать, где лежат бэкапы, кто и как их снимает и проверялось ли хоть раз восстановление из них.
Отдельный пункт касается лицензии. Статус лицензии и доступность обновлений проверяются в административной части через «Marketplace» → «Обновление платформы». Лицензия на коробочный Битрикс24 действует 12 месяцев и затем продлевается на следующий год. Когда срок действия ключа заканчивается, вы теряете обновление продукта в административном интерфейсе, получение новых дистрибутивов по лицензионному ключу и работу с Маркетплейс. Сам портал при этом продолжает работать, поэтому проблему часто замечают поздно, в момент, когда срочно понадобилось поставить обновление безопасности.
При приёмке коробки мы всегда смотрим на дату окончания лицензии и на то, как давно ставились обновления. Если ключ истёк полгода назад, а платформа не обновлялась год, объём первых работ будет заметно больше, чем предполагал клиент. Узнать об этом лучше до подписания договора.
Ещё один вопрос стоит задать вслух: на чьё юридическое лицо оформлена лицензия и на чью почту приходят письма от вендора. Если и то и другое оформлено на подрядчика, техническая передача пройдёт гладко, а административная превратится в переписку.
График передачи: почему две недели параллельной работы лучше одного дня
Самый частый сценарий простоя выглядит так: в пятницу отключили старого подрядчика, в понедельник вышел новый. За выходные ничего не случилось, а во вторник встал обмен с 1С, и три дня никто не понимал, куда смотреть.
Нормальный график устроен иначе. Первая неделя уходит на приёмку без изменений: новая команда получает права администратора, но ничего не трогает. Проходит по всем шести слоям, составляет опись, задаёт вопросы прежнему подрядчику, пока тот ещё отвечает. На этом этапе выясняются почти все сюрпризы.
На второй неделе переоформляют ключи и учётки, по одной интеграции за раз, с проверкой сразу после каждой. Сначала те, что критичны для продаж: заявки с сайта, телефония, мессенджеры. Обмен с учётной системой в последнюю очередь и обязательно вне пиковых часов.
И только после этого снимаются права прежней команды, деактивируются учётки, удаляются мёртвые интеграции.
Ключевое условие тут в доступности людей. Переоформление вебхука занимает минуту, а вот последствия проявляются через часы, и разбирать их надо сразу. Поэтому на период миграции техподдержка битрикс24 должна работать в режиме 24/7, а не «с 9 до 18 по будням»: обмен с 1С падает ночью, заявки с сайта перестают доходить в субботу, и ожидание до понедельника обходится в деньги.
Иллюстративный пример: дистрибьютор оборудования, 40 пользователей
Ниже собирательный пример. Детали здесь иллюстративные, но набор проблем взят из практики приёмки чужих порталов.
Компания-дистрибьютор, облачный Битрикс24, около 40 пользователей, две воронки продаж, обмен с 1С, сайт на WordPress с формами, WhatsApp через коннектор. Прежний подрядчик перестал отвечать на задачи, решили менять.
Опись показала одиннадцать интеграций в разделе «Разработчикам». Пять оказались живыми по статистике REST-запросов, четыре не делали запросов больше двух месяцев, две не сделали ни одного. Из пяти живых три были созданы от учётной записи сотрудника прежнего подрядчика, то есть их секретные коды нам были недоступны.
Дальше начались находки. Один из «мёртвых» вебхуков оказался вовсе не мёртвым: он использовался раз в квартал, для выгрузки отчётности. Удали его по формальному признаку, и обнаружилось бы это только в конце квартала. Вторым сюрпризом оказался робот в воронке, отправлявший уведомление на личную почту сотрудника прежнего подрядчика. Про это уведомление не знал никто из компании.
Переоформление растянули на восемь рабочих дней, по одной-две интеграции в день. Обмен с 1С трогали последним, в субботу утром, заранее предупредив бухгалтерию. Простоя не было ни разу, и не потому, что всё прошло идеально, а потому, что каждую замену проверяли в течение получаса после переключения.
Если вы сейчас в похожей ситуации, начинать имеет смысл с описи. Заказать техподдержку Битрикс24 24/7 можно и на этапе приёмки: первые недели как раз и состоят из инвентаризации и точечных исправлений.
Что должно остаться у вас на руках
После передачи у заказчика должен быть комплект, не зависящий ни от старого подрядчика, ни от нового. Роль главного администратора на сотруднике компании. Список администраторов портала с указанием, кто и зачем. Таблица интеграций: название, назначение, права, где прописан ключ, кто отвечает. Таблица роботов и триггеров по воронкам. Архив .bpt-файлов бизнес-процессов. Свежая выгрузка CRM в XLS или CSV. Для коробки дополнительно доступы к серверу и домену, данные о лицензии и схема бэкапов.
Хранить это лучше не в переписке, а в отдельном разделе на самом портале, чтобы через год комплект нашёлся без раскопок в почте. Тогда следующая передача портала другому интегратору, если она вообще понадобится, займёт не месяц, а несколько дней.
Роль техподдержки при смене команды
Слово «техподдержка» многие руководители понимают узко: кто-то, кому пишут, когда не грузится страница. При смене подрядчика техническая поддержка битрикс24 работает иначе, она принимает на себя ответственность за систему целиком, включая ту часть, которую настраивала не она.
На практике это означает вот что. Реакция без оглядки на календарь: интеграции ломаются не по расписанию, и наша поддержка отвечает 24/7, включая выходные и ночь, потому что именно ночью идут обмены с учётными системами. Фиксация каждого изменения: что сделали, зачем, что было до. И объяснимость: на вопрос «почему сделка не перешла на следующую стадию» должен приходить ответ по существу, а не «посмотрим».
Мы, B2BPRO.KZ, принимаем чужие порталы на сопровождение регулярно, и по опыту первые две-три недели после смены подрядчика оказываются самыми нагруженными: всплывают связи, о которых не знал никто, включая самого клиента. Если в этот период поддержка доступна ограниченно, миграция растягивается и обрастает мелкими потерями, каждая из которых по отдельности выглядит несерьёзно. Поэтому режим 24/7 на период приёмки для нас рабочая необходимость. Оставить заявку на техподдержку имеет смысл до отключения прежней команды, а не после.
Частые вопросы
Нужно ли переносить портал на новый аккаунт при смене подрядчика?
Нет. Портал принадлежит вашей компании, меняются только люди, которые его обслуживают. Перенос данных в новый Битрикс24 представляет собой отдельную и куда более тяжёлую операцию, и при обычной смене интегратора она не нужна.
Что делать, если прежний подрядчик не выходит на связь?
Большинство задач решаются силами администратора портала со стороны заказчика: права, роботы, экспорт данных. Сложность возникает с двумя вещами: с ролью главного администратора, если она была на подрядчике, и с секретными кодами созданных им вебхуков, которых не видит даже администратор. Вебхуки в этом случае переоформляются заново, с одновременной заменой ключа в системе-потребителе.
Сколько времени занимает передача портала другому интегратору?
Для облака с типовым набором интеграций обычно две-три недели, из которых первая уходит на опись без изменений. Коробка занимает больше из-за инфраструктуры и лицензии. Точный срок зависит от количества живых интеграций и от того, насколько прежний подрядчик готов отвечать на вопросы.
Можно ли обойтись без простоя вообще?
Да, если переключать интеграции по одной и проверять результат сразу, а не менять всё за один вечер. Критичные обмены переносят на нерабочие часы. Простой возникает от попытки сделать смену подрядчика одним движением, а не от самой смены.
Обязательно ли отключать учётные записи прежнего подрядчика?
Права администратора снимаются сразу после завершения переоформления. Сами учётки лучше не удалять, а деактивировать: на них могут ссылаться бизнес-процессы, и удаление создаст висящие ссылки. Деактивированный пользователь теряет доступ, но история его действий и связи в системе сохраняются.