Решение сменить подрядчика обычно созревает долго, а исполняется за неделю. Договор со старой командой закрыт, новая ждёт доступы, и все торопятся. В этой спешке компания получает портал, о котором знает меньше, чем думает: кто-то из бывших исполнителей до сих пор администратор, робот в воронке ставит задачи уволенному менеджеру, а вебхук, созданный три года назад, продолжает отдавать клиентскую базу во внешний сервис, о котором никто не помнит.
Аудит портала Битрикс24 перед сменой подрядчика нужен ровно для того, чтобы увидеть систему в её фактическом состоянии, до того как ответственность перейдёт к новой команде. Ниже порядок проверки, который мы используем в техподдержке Битрикс24, и объяснение, почему именно такой.
Зачем проверять портал, если старый подрядчик и так всё передаст
Подрядчик передаёт то, что помнит и что считает важным. И это далеко не всё, что на портале на самом деле работает. За несколько лет сопровождения накапливаются временные решения, тестовые роботы, приложения, поставленные «на попробовать», учётные записи стажёров. Большая часть этого не попадает ни в какую документацию.
Вторая причина менее приятная. Если отношения с подрядчиком заканчиваются конфликтом, полноты передачи ждать не приходится. Аудит, проведённый вашей стороной или новой командой, не зависит от доброй воли уходящего исполнителя.
Третья причина практическая. Новый подрядчик берёт на себя ответственность за систему. Без зафиксированного исходного состояния любая поломка через месяц превращается в спор, кто её допустил. Отчёт аудита снимает этот спор заранее.
Процесс самой передачи дел, от описи до графика параллельной работы, мы подробно описали в статье о миграции Битрикс24 к новому подрядчику. Здесь речь о другом: что именно проверить на портале и в каком порядке, чтобы не пропустить главное.
Порядок проверки: сначала доступы, потом всё остальное
Проверять стоит от того, что может навредить быстрее всего, к тому, что просто мешает работать. Доступы и интеграции идут первыми, потому что через них можно потерять данные или контроль над системой за один день. Автоматизация и качество данных идут следом: там ущерб накапливается медленно, но стоит дорого.
Для облачного портала список выглядит так: главный администратор, остальные администраторы и уволенные сотрудники, интеграции, журнал событий и двухфакторная аутентификация, права в CRM, роботы и бизнес-процессы, дубли и заполненность карточек, лицензия и платные приложения. Для коробочной версии к нему добавляется сервер.
Что запросить у подрядчика до начала аудита
Аудит идёт вдвое быстрее, если часть информации получить заранее. До расторжения договора попросите уходящую команду передать письменно список всех учётных записей, которыми она пользовалась, перечень интеграций с кратким назначением каждой, описание нестандартных доработок и контакты сервисов, подключённых от их имени.
Не ждите от этого списка полноты, он нужен для сверки. Расхождения между тем, что подрядчик описал, и тем, что обнаружится на портале, как раз и составят самую ценную часть отчёта.
Кто главный администратор портала
Первый вопрос аудита звучит просто, но ответ на него часто неприятно удивляет. Главный администратор Битрикс24 — это сотрудник, который создал портал. На его электронную почту приходят уведомления о продлении тарифа. Если портал когда-то заводил подрядчик на свой адрес, фактическим хозяином системы остаётся он.
Сменить главного администратора можно только на коммерческом тарифе. Порядок такой: другой администратор открывает профиль главного и нажимает «Администратор» → «Забрать права администратора», затем подтверждает «Да, отправить». Текущий главный администратор должен сам подтвердить передачу: нажать «Передать права», ввести в поле слово «Передать» и нажать «Подтвердить». Никто другой за него это сделать не может, и служба поддержки Битрикс24 права администратора сотрудникам не выдаёт.
Отсюда главное правило: передачу прав главного администратора нужно провести до расторжения договора, пока с подрядчиком есть рабочий контакт. Если момент упущен и исполнитель перестал выходить на связь, порядок действий описан в материале о том, как вернуть контроль над порталом, если интегратор пропал.
Администраторы, подрядчики и уволенные сотрудники
Дальше посмотрите полный список пользователей с правами администратора. На порталах, которые сопровождались несколько лет, их почти всегда больше, чем нужно: руководитель, два-три сотрудника подрядчика, бывший IT-специалист, однажды получивший права «на время настройки телефонии».
Для каждой учётной записи ответьте на два вопроса: кто это и зачем ему права администратора сейчас. Учётки сотрудников старого подрядчика после передачи дел должны быть уволены. Снять с них права администратора недостаточно. Уволенный сотрудник теряет доступ к Битрикс24, при этом его задачи, переписка и файлы сохраняются. В списке пользователей он остаётся с пометкой «Уволен», и при необходимости его можно снова принять.
Отдельно проверьте, за кем числятся сделки, задачи и файлы уже уволенных людей. Нового ответственного можно назначить и после увольнения, но если этого не сделать, клиенты висят на человеке, которого нет. Особенно внимательно смотрите на файлы общего диска: права на рабочие документы нужно переназначить уполномоченным сотрудникам.
Интеграции: вебхуки и приложения
Это самый недооценённый пункт аудита. Вебхук работает как ключ, который открывает внешней системе доступ к данным портала. Ключ может выдать администратор, подрядчик или сотрудник, настраивавший интеграцию с сайтом. Внешне на портале это никак не проявляется.
Все созданные вебхуки и локальные приложения собраны в разделе «Разработчикам» на вкладке «Интеграции». Там видно название, вызываемые события, права доступа к инструментам и пользователя, который интеграцию создал. Администратор видит все интеграции портала, обычный пользователь только свои. Редактировать или удалять их можно через «Меню (≡)» напротив нужной строки. Дополнительно администратор может ограничить права на интеграции в разделе «Безопасность», в блоке «Интеграции Битрикс24».
Составьте таблицу: каждая интеграция, кто создал, к каким данным есть доступ, что сломается, если её отключить. Удалять что-то на этом шаге не спешите. Вебхук, созданный сотрудником подрядчика, может обслуживать форму заявок на сайте, и его удаление остановит поток лидов. Сначала выясните назначение, потом решайте.
Отдельный красный флаг: интеграция с широкими правами (CRM, пользователи, задачи сразу) и без понятного назначения. Такие ключи стоит закрывать в первую очередь, согласовав это с новой командой.
Журнал событий и двухфакторная аутентификация
Журнал событий открывается через «Настройки» → «Безопасность» → «Журнал событий». Доступ к нему есть только у администратора. Журнал показывает, кто, когда и с каких IP-адресов входил в Битрикс24. Работает он не на всех тарифах, а часть событий, например запросы на смену пароля, доступна только на тарифе Энтерпрайз и хранится семь дней.
Для аудита журнал полезен в двух случаях. Первый: убедиться, что учётными записями старого подрядчика никто не пользовался после завершения работ. Второй: заметить входы с неожиданных адресов, которые могут говорить о переданных кому-то паролях.
Сразу после аудита доступов имеет смысл включить обязательную двухфакторную аутентификацию. Администратор может сделать её обязательной для всей компании, и тогда сотрудники должны включить её в установленный срок. Смена подрядчика подходит для этого лучше любого другого момента: пароли всё равно придётся менять, и ещё одно требование безопасности сотрудники воспримут спокойнее.
Права доступа в CRM
Права в CRM настраиваются в разделе «CRM» → «Ещё» → «Настройки» → «Права доступа к CRM». По умолчанию там две роли: «Администратор» с полным доступом ко всем элементам, включая управление правами, и «Менеджер», который видит, создаёт и меняет только свои элементы. Всё, что сверх этого, придумано и настроено кем-то вручную.
При аудите смотрите не только на список ролей, но и на то, кому они назначены. Роль может быть выдана отделу, команде, группе пользователей или конкретному сотруднику. Уровни доступа тоже различаются: свои элементы, элементы своего отдела, подотделов, команд, открытые элементы, все.
Типовые находки выглядят так. Менеджеры по продажам видят всю клиентскую базу компании, хотя по регламенту должны видеть только свою. Бывший руководитель отдела до сих пор числится в роли с полным доступом. Роль, созданная подрядчиком для «тестов», назначена целому отделу.
Помните про приоритет: детальные права важнее унаследованных. Если у сотрудника детальные права запрещают доступ к сделкам, а унаследованные разрешают, доступ будет закрыт. Поэтому жалоба «не вижу сделки», поступившая после смены подрядчика, чаще всего означает конфликт настроек. Сломанного там обычно ничего нет.
Роботы, триггеры и бизнес-процессы
Роботы настраиваются в CRM на вкладке «Роботы» выбранной воронки, на странице «Автоматизация продаж». Там же есть поиск по названию робота или триггера, что сильно ускоряет проверку большой воронки.
Проходите воронку за воронкой и ищите четыре вещи.
Роботы, завязанные на конкретных людей. Задача, уведомление или смена ответственного, где получателем указан уволенный сотрудник или сотрудник подрядчика. Такой робот продолжает срабатывать, но результат уходит в пустоту.
Дублирующая автоматизация. Два робота на одной стадии делают одно и то же, потому что второго добавили, не заметив первого. Клиент получает два одинаковых письма, менеджер две одинаковые задачи.
Автоматизация без хозяина. Бизнес-процесс, назначение которого никто в компании объяснить не может. Отключать такой процесс вслепую нельзя, но и оставлять без описания тоже.
Связи с внешними системами. Роботы и процессы, которые отправляют данные наружу или получают их из вебхуков. Их нужно сопоставить с таблицей интеграций из предыдущего шага.
Результат этого шага — карта автоматизации: воронка, стадия, что происходит, кто отвечает. Новый подрядчик получит её в первый же день, и это сэкономит ему неделю раскопок.
Качество данных: дубли и пустые карточки
Данные подрядчик не портит напрямую, но от того, как была настроена система, зависит, насколько грязной стала база. Форма на сайте, создающая новый контакт при каждой заявке, за год превращает одного клиента в пятнадцать карточек.
В разделах «Компании», «Контакты» и «Лиды» есть инструмент «Контроль дубликатов». Он показывает найденные совпадения. При объединении вы выбираете основную карточку, она остаётся в CRM, а остальные удаляются. Объединять дубликаты могут администратор и сотрудники с правами на изменение и удаление элементов CRM.
На этапе аудита массово ничего не объединяйте. Задача другая: оценить масштаб проблемы и найти её источник. Если дубли плодит конкретная интеграция, чистка без исправления интеграции даст результат на пару месяцев.
Второй показатель качества данных — заполненность ключевых полей. Возьмите выборку из сотни последних сделок и посмотрите, у скольких указан источник, сумма, контакт, причина проигрыша. Если источник пуст у половины сделок, аналитика рекламных каналов на этом портале не работает, какой бы красивой ни была сквозная отчётность.
Лицензия, оплата и платные приложения
Этот блок редко попадает в технические чек-листы, хотя проблемы в нём всплывают в самый неудобный момент. Уведомления о продлении тарифа приходят на почту главного администратора. Если это адрес сотрудника подрядчика, о скором окончании лицензии компания может узнать последней.
Выясните, на какое юридическое лицо оформлена лицензия, кто и через кого её оплачивал и когда заканчивается текущий период. Отдельно соберите список платных приложений и подписок, которые подключались к порталу. Часть из них могла оплачиваться подрядчиком и перевыставляться вам в общем счёте за сопровождение. После расторжения договора такие оплаты прекращаются, и приложение перестаёт работать без предупреждения.
Хорошая практика: сделать так, чтобы все платежи за портал шли напрямую от компании или через партнёра, с которым у вас действующий договор, а контактная почта для уведомлений была корпоративной и не привязанной к конкретному человеку.
Если у вас коробочная версия
Для коробочного Битрикс24 список проверок дополняется сервером, и этот блок по важности не уступает доступам. Кто владеет сервером или договором с хостингом. У кого есть доступ по SSH и к панели управления. Где лежат резервные копии, когда была сделана последняя и проверялось ли когда-нибудь восстановление из неё.
Отдельно выясните, какие доработки вносились в код и где они описаны. Правки, сделанные в обход штатных механизмов, при обновлении платформы могут перестать работать, и новый подрядчик должен узнать о них до первого обновления.
Что должно получиться на выходе
Результаты аудита записываются в документ. Устного пересказа на созвоне хватает ровно до первой спорной ситуации. В документе три части.
Первая — исходное состояние: список администраторов, таблица интеграций, карта автоматизации, роли в CRM, оценка качества данных. Это снимок системы на дату передачи.
Вторая — найденные проблемы с приоритетами. Критичные закрываются в первые дни: чужой главный администратор, интеграции с широкими правами без назначения, активные учётки бывших исполнителей. Важные идут в план первого месяца: конфликты прав, роботы на уволенных, источник дублей. Остальное ставится в общий план развития портала.
Третья — список вопросов к уходящему подрядчику. Всё, что не удалось понять по порталу, нужно спросить, пока с ним есть контакт.
Иллюстративный пример
Опишем типовую ситуацию в обобщённом виде, как она обычно выглядит у торговой компании с тридцатью пользователями и тремя годами сопровождения у одного подрядчика.
Аудит занимает два-три рабочих дня. Главным администратором оказывается сотрудник подрядчика, который завёл портал на рабочую почту агентства. Администраторов семь, из них в компании работают двое. В разделе интеграций находится около десятка вебхуков, назначение половины из них подрядчик вспоминает только после наводящих вопросов, а два не может объяснить вовсе. В воронке продаж несколько роботов ставят задачи сотрудникам, уволенным полтора года назад.
Ни одна из этих находок не выглядит катастрофой по отдельности. Вместе они означают, что компания не контролировала собственную CRM. После аудита права главного администратора передаются собственнику, лишние учётки увольняются, необъяснимые вебхуки закрываются после двух недель наблюдения, а новый подрядчик получает документ, с которого можно начинать работу.
Техническая поддержка Битрикс24 после аудита
Аудит фиксирует состояние на конкретную дату. Через полгода портал снова обрастёт новыми ролями, роботами и интеграциями, и без регулярного присмотра картина повторится. Поэтому разумно сразу договориться, кто будет вести систему дальше и как быстро он реагирует на сбои.
Смена подрядчика — самый уязвимый период: старая команда уже не отвечает, новая ещё не знает систему. В эти недели полезнее всего поддержка, которая работает 24/7 и не ждёт понедельника, если в пятницу вечером перестали приходить заявки с сайта. Техподдержка Битрикс24 24/7 от B2BPRO.KZ берёт на себя и сам аудит, и сопровождение после передачи дел.
Частые вопросы
Сколько времени занимает аудит портала Битрикс24?
Для облачного портала на несколько десятков пользователей обычно хватает двух-трёх рабочих дней. Коробочная версия с доработками в коде и собственным сервером требует больше времени, срок зависит от объёма доработок.
Можно ли провести аудит своими силами?
Проверку администраторов, уволенных сотрудников и списка интеграций вполне можно сделать самостоятельно, если у вас есть права администратора. Оценка автоматизации и прав в CRM требует опыта: без него легко принять рабочую настройку за мусор и отключить что-то нужное.
Что делать, если старый подрядчик отказывается передавать права главного администратора?
Главный администратор должен лично подтвердить передачу, и служба поддержки Битрикс24 права за него не выдаёт. Поэтому этот вопрос нужно решать до расторжения договора и фиксировать в акте передачи.
Нужно ли сразу удалять все вебхуки старого подрядчика?
Нет. Сначала выясните назначение каждого. Вебхук может обслуживать форму на сайте или телефонию, и его удаление остановит работающий процесс. Интеграции без понятного назначения и с широкими правами закрывайте в первую очередь, но осознанно.
Чем техподдержка Битрикс24 24/7 помогает при смене подрядчика?
В переходный период старая команда уже не отвечает за систему, а новая ещё её не знает. Круглосуточная поддержка закрывает этот разрыв: сбой в интеграции или автоматизации разбирают сразу, без ожидания понедельника.
Хороший признак того, что аудит сделан правильно: через месяц после смены подрядчика у руководителя нет ощущения, что система живёт своей жизнью. Он знает, кто на портале администратор, какие внешние сервисы видят данные и что происходит со сделкой на каждой стадии.