Смена интегратора: что проверить в чужом портале

Ситуация встречается чаще, чем принято обсуждать: система работает, настраивал её кто-то другой, объяснить устройство некому. Ниже — порядок, по которому такой портал принимают.

Кому принадлежит портал и учётные записи

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

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

Второй вариант встречается и лечится переоформлением, но делать это нужно до расставания, а не после. Пока отношения рабочие, вопрос решается за день; в конфликте — через вендора и с потерей времени.

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

Где живут интеграции и на чём они держатся

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

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

Отдельно проверьте, есть ли уведомление об ошибках обмена и кому оно приходит. Если приходит бывшему подрядчику, расхождения будут копиться незаметно. Общий разбор устройства таких связок — интеграция Битрикс24 с 1С.

Что автоматизировано и чем именно

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

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

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

В каком состоянии база

Четвёртый пункт. Проверяется тремя вопросами.

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

Сколько «мёртвых» сделок: записи, которые стоят на промежуточных этапах месяцами. Большое их число означает, что воронка не описывает реальную работу и люди перестали двигать сделки.

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

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

Отдельно стоит выгрузить базу и сохранить копию до начала любых изменений. Это занимает несколько минут и снимает главный риск приёмки: правку, после которой что-то пропало, а восстановить неоткуда.

Есть ли описание процессов

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

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

Это же документ, по которому потом принимаются решения об изменениях. Без него каждая правка обсуждается заново, и разговор начинается с восстановления контекста.

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

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

В каком порядке всё это делать

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

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

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