Антон Дегтярёвбитрикс24 для холдинга: один портал или несколько
Поле «головная компания» в карточке контрагента настраивается за двадцать минут и закрывает примерно 5% задачи. Остальные 95% — это модель доступа. В группе на шесть юрлиц вопрос «кто видит сделки соседнего направления» переписывался у меня три раза, и каждый раз это была неделя переделок в правах, отчётах и роботах. Ниже — три развилки холдингового внедрения по порядку, с деньгами и сроками.
что в холдинге ломается первым
Холдинговое внедрение отличается от обычного не размером, а тем, что у вас несколько центров принятия решений. Директор дистрибуции хочет свою воронку и не хочет, чтобы её видел директор сервиса. Финансовый директор хочет одну цифру по группе. ИТ хочет одну систему, чтобы не администрировать пять. Эти три желания конфликтуют, и внедрение — это не настройка CRM, а протокол разрешения конфликта.
Технически же ломается всегда одно и то же место — справочник компаний. В Битрикс24 он плоский: список контрагентов без иерархии. Как только у клиента появляется «группа компаний Ромашка» с пятью юрлицами, встаёт вопрос, как показать в одной карточке сделки всех дочерних. Штатно это не показывается.
Дальше по нарастающей: оргструктура на несколько юрлиц, права доступа между направлениями, разные воронки, разные наборы обязательных полей, разные базы 1С и сводный отчёт, который должен собраться из всего этого. Разбираю по порядку, но начну с развилки, которая определяет всё остальное.
развилка 1: один портал на группу или по порталу на юрлицо
Это первое решение, и переигрывать его дорого. Один общий портал даёт единую базу контрагентов, сквозные задачи между компаниями, общий диск, одну оргструктуру и — главное — возможность собрать сводную аналитику штатными средствами. Минус один, но существенный: любое изменение настроек затрагивает всех, а согласовать общие обязательные поля в CRM у пяти директоров сложнее, чем их настроить.
Отдельные порталы дают автономию: каждая компания живёт своими воронками и правилами, никто никому не мешает. Цена автономии — данные не сходятся. Сводка по группе собирается только выгрузками наружу, общего справочника клиентов нет, и один и тот же контрагент заводится в трёх местах по-разному.
Мой критерий такой. Если у компаний группы общие клиенты или общие сотрудники — только единый портал, иначе вы получите три версии правды об одном клиенте. Если компании группы не пересекаются ни клиентами, ни людьми (условно, завод и сеть кофеен у одного собственника) — отдельные порталы честнее и дешевле в поддержке, а сводку собирайте в BI поверх выгрузок.
Промежуточный вариант — единый портал плюс отдельный для одной компании с принципиально другим процессом. Так делаю, когда одно из направлений работает с гостайной, персданными особой категории или просто по другому законодательству.
как связать компании между собой в CRM
Справочник компаний одноуровневый, поэтому иерархию делают пользовательским полем. Заводится поле типа «Привязка к CRM» с ограничением на сущность «Компания» — обычно называют «Головная компания», одиночный выбор. Обратное поле «Дочерние компании» с множественным выбором добавляют, если нужно видеть детей прямо в карточке родителя.
Дальше начинается предел штатного решения: поле показывает связь, но не собирает сделки. Открыв карточку управляющей компании, вы не увидите сделки всех дочерних — Битрикс24 так не умеет из коробки. Обходов три. Первый — смарт-процесс «Группа компаний» как отдельная сущность, к которой привязываются и компании, и сводные показатели. Второй — готовый модуль иерархии с Маркетплейса, их несколько. Третий — отчёт или дашборд с фильтром по полю «Головная компания», если задача только посмотреть цифры, а не работать в карточке.
Что я делаю на практике: сначала спрашиваю, зачем нужна иерархия. В половине случаев ответ — «чтобы РОП видел общий оборот по группе клиента», и тогда достаточно поля плюс фильтра в отчёте, без модулей и разработки. Ставить модуль имеет смысл, когда менеджеры реально работают в разрезе холдинга клиента каждый день.
развилка 2: кто кого видит
Самая дорогая часть проекта. В обычной компании модель доступа рисуется за час: менеджер видит своё, РОП — отдел, директор — всё. В группе появляется второе измерение — юрлицо или направление, и матрица становится двумерной.
Рабочая схема, к которой я прихожу чаще всего: доступ выдаётся по отделу оргструктуры, а не по юрлицу, при этом отделы совпадают с направлениями бизнеса. Менеджер видит сделки своего отдела. Руководитель направления видит своё направление целиком, включая все юрлица внутри него. Управляющая компания получает роль с доступом на чтение по всем направлениям и без права правки. Общий справочник контактов открыт всем, потому что закрытые контакты порождают дубли — а дубли в холдинге дороже, чем чужие глаза в карточке.
Отдельно решается вопрос закрытых сделок между компаниями группы: внутригрупповые продажи часто нельзя показывать линейным менеджерам. Их выносят в отдельную воронку с ограниченным доступом. Общая механика прав, роли и уровни разобраны в статье про права доступа в Битрикс24 — здесь я специально не повторяю базу, а говорю только про холдинговую специфику.
Практический совет: до настройки соберите матрицу в таблице — строки это роли, столбцы направления, в клетках «чтение / правка / нет». Подпишите её у собственника. Настройка занимает два-три дня, а согласование матрицы у меня занимало от недели до полутора месяцев, и это нормально.
оргструктура, когда юрлиц несколько
Оргструктура в Битрикс24 одна на портал, и в неё нужно уложить всю группу. Два рабочих подхода. Первый — верхний уровень по юрлицам, внутри отделы: подходит, когда компании автономны и сотрудники не пересекаются. Второй — верхний уровень по направлениям бизнеса, а юрлицо хранится отдельным полем в карточке сотрудника: подходит, когда один человек работает на два юрлица, а это в холдингах обычное дело.
Второй подход я выбираю чаще, потому что права в Битрикс24 наследуются по дереву отделов, и если дерево построено по юрлицам, то человек «на двух стульях» ломает всю модель. Юрлицо тогда становится не структурой, а атрибутом — полем в сделке и в счёте, по которому потом фильтруются отчёты.
Сотрудник может состоять в нескольких отделах, и этим тоже пользуются, но аккуратно: чем больше людей в двух-трёх отделах сразу, тем сложнее потом объяснить, почему кто-то видит лишнее. Базовая настройка сотрудников и подразделений — в статье про сотрудников и оргструктуру.
воронки, стадии и обязательные поля
Соблазн запустить группу на одной общей воронке огромный: так проще считать. У меня был холдинг на шесть юрлиц и 90 пользователей, где мы стартовали именно так — одна воронка на всех. Через месяц откатились к пяти воронкам по направлениям, потому что стадии у дистрибуции и у сервиса не совпадают физически: там, где у одних «отгрузка», у других «выезд инженера», и общая стадийность превращалась в набор пустых этапов, которые все проскакивали.
Работающее правило: воронка на бизнес-процесс, а не на юрлицо. Если два юрлица продают одинаково — одна воронка и поле «юрлицо» в сделке. Если процессы разные — разные воронки, даже внутри одного юрлица.
А вот что действительно должно быть общим — три поля во всех воронках: направление, юрлицо и источник лида. Это тот минимум, на котором потом собирается сводка. Договориться об этих трёх полях всегда дольше, чем их настроить: у каждого директора свой список источников, и приведение к общему справочнику — отдельная переговорная работа на неделю-две.
развилка 3: сводная аналитика по группе
Запрос собственника группы почти всегда звучит одинаково: «хочу одну цифру по всей группе». Штатные отчёты Битрикс24 это дают, но при одном условии — одинаково заполненных полях, о которых выше. Если направление и юрлицо проставлены во всех сделках, сводка по группе, по направлению и по юрлицу строится в CRM-аналитике без выгрузок и без BI.
Что делаю по шагам. Сначала сводный дашборд по группе: выручка, сделки в работе, конверсия, средний чек — с фильтром по направлению. Потом отдельные дашборды под каждое направление, копией. И только потом, если собственнику нужны срезы с данными из 1С (себестоимость, маржа, дебиторка), поднимаем выгрузку в BI — DataLens или PowerBI. Механика штатных отчётов разобрана в статье про аналитику продаж в Битрикс24.
Честная оговорка: маржинальность по группе в CRM не считается. CRM знает выручку и не знает себестоимость — она в 1С. Если собственнику нужна именно маржа по направлениям, закладывайте связку с учётной системой и BI поверх, это отдельный бюджет и отдельный проект.
тарифы и лицензии на группу компаний
Считается по числу пользователей на портале, а не по числу юрлиц. Наши цены на облако: Базовый — 2 490 ₽/мес до 5 пользователей, Стандартный — 6 990 ₽/мес до 50, Профессиональный — 13 990 ₽/мес до 100, Энтерпрайз — 33 990 ₽/мес до 250. При оплате за год скидка 35%: Профессиональный выходит около 9 093 ₽/мес, Энтерпрайз — около 22 093 ₽/мес.
Для группы на 60–90 человек это обычно Профессиональный, для 150–250 — Энтерпрайз. Отдельно у вендора есть тариф «Энтерпрайз Холдинг» со ступенями от 1 000 до 10 000 пользователей, рассчитанный ровно на сценарий «сотрудники нескольких юрлиц в одном Битрикс24»; цену по нему вендор публично не публикует, она считается под конкретную группу — не верьте цифрам из чужих статей, запрашивайте расчёт.
Арифметика в пользу единого портала: пять отдельных порталов по 50 человек — это пять Стандартных, около 34 950 ₽/мес. Один портал на 250 человек — Энтерпрайз, 33 990 ₽/мес, и при этом с общей базой и сводной аналитикой. Отдельные порталы почти никогда не выигрывают по деньгам.
Если группе нужна коробка — из-за требований к размещению данных или собственных доработок — это отдельное решение со своей экономикой; развилку разбираю в статье облако или коробка.
интеграция с 1С, когда баз несколько
Типовая ситуация: у каждого юрлица своя база 1С, иногда разных конфигураций. Хорошая новость — Битрикс24 умеет обмениваться с несколькими базами одновременно. Плохая — правила сопоставления придётся писать для каждой отдельно, и стоимость интеграции растёт почти линейно от числа баз.
Главный вопрос на старте — что считать источником истины по контрагенту. Если в трёх базах 1С один и тот же клиент заведён с разными ИНН-написаниями и разными наименованиями, при выгрузке в общий портал вы получите три карточки. Поэтому первым делом договариваются о ключе сопоставления — обычно ИНН плюс КПП — и прогоняют базы через дедупликацию до, а не после запуска.
По деньгам на моих проектах: обмен с одной базой — от 80 тыс. ₽, каждая следующая база той же конфигурации — плюс 40–60 тыс. ₽, база другой конфигурации — считается как новая. Сценарии и глубина обмена разобраны в статье про интеграцию Битрикс24 и 1С.
порядок внедрения — с какой компании начинать
Запускать всю группу одним днём — плохая идея: цена ошибки умножается на число компаний. Работающая последовательность — пилот на одном направлении, потом тиражирование.
Пилотом берут не самое крупное направление, а самое типовое и с самым лояльным руководителем. На нём отлаживают воронку, поля, права и отчёты за четыре-шесть недель. Дальше каждая следующая компания подключается копированием настроек с локальными правками — это уже две-три недели на компанию, а не полтора месяца.
Управляющую компанию подключают последней, когда есть что сводить. Обратный порядок — сначала сводные дашборды, потом данные — даёт пустые отчёты и потерю доверия собственника к системе на старте. Общая последовательность этапов расписана в статье про этапы внедрения Битрикс24.
типовые ошибки холдинговых проектов
Первая — начать с прав. Пока нет воронок и полей, матрица доступа рисуется в вакууме и переписывается трижды. Сначала процесс, потом права.
Вторая — общая воронка ради красивой сводки. Разные процессы в одной воронке дают мёртвые стадии и мусорную конверсию, а сводка всё равно собирается по полю «направление», а не по стадиям.
Третья — свои справочники источников у каждой компании. Через полгода в сводном отчёте вы увидите «Сайт», «сайт», «Сайт (форма)» и «Заявка с сайта» как четыре разных источника.
Четвёртая — тиражировать настройки без локальных владельцев. В каждой компании группы нужен свой ответственный за CRM, иначе после ухода интегратора система начинает расходиться: где-то завели пять новых стадий, где-то отключили обязательные поля.
Пятая — экономия на дедупликации перед выгрузкой из нескольких баз 1С. Разбирать дубли в общей базе на 40 тысяч контрагентов на порядок дороже, чем почистить их до старта.
сроки и бюджет, на что закладываться
По моим проектам холдинговое внедрение на 4–6 юрлиц и 60–120 пользователей укладывается в 3–5 месяцев. Разбивка: обследование и матрица доступа — 3–4 недели, пилот на одном направлении — 4–6 недель, тиражирование — по 2–3 недели на компанию, интеграция с 1С — параллельно 4–8 недель, сводная аналитика и обучение — 2–3 недели в конце.
По деньгам вилка шире, чем в обычном проекте, потому что всё зависит от числа баз 1С и глубины доработок. Ориентир: настройка портала и пилот — 250–450 тыс. ₽, тиражирование — 60–120 тыс. ₽ на компанию, интеграция с 1С — от 80 тыс. ₽ за базу, обучение по группам — 40–80 тыс. ₽. Плюс лицензии по тарифу и сопровождение после запуска.
Что экономит деньги реально: согласованная матрица доступа до начала настройки, единый справочник источников и направлений, дедупликация контрагентов до выгрузки. Что не экономит — попытка обойтись без пилота и настроить всю группу сразу «по аналогии».