Битрикс24 в облаке: white-label и разграничение прав для партнёров

Контекст: почему клиент пришёл к нам

Клиент ранее работал с подрядчиком-фрилансером с платформы kwork. За время работы подрядчик реализовал несколько десятков задач “как понял”. По ходу развития бизнеса и необходимости в новых процессах подрядчик расширял, адаптировал свои ранние работы для заказчика. И всё было неплохо, но со временем процесс от постановки до реализации стал занимать критично много времени, например в момент когда мы были приглашены, запрос был не реализован в течении месяца. В общем, клиент “закончил” работать с ним и предложил начать с нами.

Задача: white-label Битрикс24 для партнёров

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

По этой причине было необходимо предоставить битрикс24 как бы в аренду или же по формату White-label. Нюансов было много, начиная с того, что очень сложная система прав должна была регулировать и отделять данные между партнёрами. Автоматизации для одних, не должны были быть у других и в целом они должны были быть разными и отрабатывать идеально. И это всё с учетом постоянного роста требований, возникновения новых, иногда прямо противоположных предыдущим задачам, а иногда и “ломающая” прежнюю выработанную логику работы, т.к компания масштабировалась семимильными шагами, штат разросся с некогда десятка сотрудников до 50-ти, которые работают в разных физических офисах.

Клиент не рассматривал переход на энтерпрайз тариф облачного битрикс24,, где уже “коробочно” поддерживается возможность нескольких филиалов в виду высокой стоимости и недостаточного колличества потребностей под энтерпрайз.

Итогом, стала задача по подготовке “цифровых рабочих мест” для компаний-партнёров. Такое рабочее место должно было сохранить прежнюю структуру и одобренный пул данных для такой компании. Пул довольно большой, поэтому для кейса, вкратце - данные были в разрезе полей, определенных контактов, компаний, определенных сделок, задач.

Решение: проектирование архитектуры

Заказчик признался, что не обладает навыками, необходимыми для составления ТЗ, просил сделать на это скидку (не в плане стоимости). Мы же сразу успокоили клиента и заверили, что всё будет достаточно интерактивно, чтобы даже, если вы ни разу не занимались подобным, вам было легко и просто корректировать нас.

До нас подрядчик успел немного подготовить почву, которую пришлось вспахать заново. Мы начали с проектирования системы. Мы начали формировать основные роли и понятия для такой задачи, маленький брейншторм и облако сущностей для задачи (часть бизнес-информации скрыта).

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

Цифровые рабочие места и наследование данных

После брейншторма мы определили коробочный функционал битрикс24 (облачного тарифа) как основным, вокруг которого мы всё и построим. Цифровые рабочие места - идеальный функционал для этих целей.

Он позволяет работать как отдельно от сделок, так и сообща с ними предоставляя прямую связь. Было создано несколько рабочих мест, которые сначала стали фундаментом для компании-владельца бизнеса, а в последующем в них мы присоединили и партнёров.

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

Автоматизации и синхронизация данных

Большое колличество автоматизаций на разных стадиях каждого из элементов (сделка, ОД, Логистика и Финансы), которые осуществляют слежку за правильным заполнением полей, соблюдение сроков поставки, логикой сверки прибыли и маржинальной стоимости товаров по ходу всего времени жизни сделки. Важно, что ранее сделка была лишь в 1 интерпретации и одновременно содержала все стадии (а их более 20 шт). Так, что даже широкоформатный монитор всё равно не отображал их полностью и приходилось горизонтально скролить для просмотра, к тому же, само название стадии всё равно оставалось невидимым, т.к не влезло и приходилось наводиться для просмотра

В каждом рабочем месте есть свои автоматизации, часть из них направлена на автоматическую синхронизацию данных по каждому месту. Внесение изменений, например по ходу жизни сделки наследуются в каждую из сущности: в сделку, в рабочие места “Финансы” и так далее. Например: по ходу сделки финансисты произвели необходимые расчёты и заполнили соответствующие поля, делали они это на довольно позднем этапе, соответственно сейчас они делают это 1 раз и эти значения проставляются в каждом месте, таким образом открыв эту же сделку в виде разных сущностей мы видим одинаковые данные, причем каждая сущность самостоятельная и может работать отдельно при необходимости. По ходу развития проекта такая архитектура часто спасало ситуацию, сильно облегчив работу с сущностями как отдельные, а не как 1 сделка.

Заказчик не дал разрешение на публикацию некоторых бизнес-процессов, но их структурный вид мы приведем на примере 1 автоматизации:

Этот пример прекрасно показывает, как в рамках всего лишь 1 автоматизации существует огромное количество условий.

Контроль оплат и подсветка нужных карточек

Бизнес заказчика состоит в работе с партнерами из КНР, он производил оплаты при достижении условий по сделке. Ранее эти условия были довольно просты и это приводило иногда к моментам, когда оплата не требовалась или требовалось в другом размере, как следствие - холд средств для бизнеса в ожидании возврата или правильной транзакции.

Впоследствии мы усилили проверку таких элементов на оплату. Дополнительным вызовом стала потребность заказчика в “подсветке” нужных карточек по определенной логике. В рамках старой логики, когда это были сделки было очень сложно без “провалиться в конкретную карточку”. С новой логикой стало проще, но не сильно легче, да, карточки консолидировались в рамках “1 воронки”, но их так много, что всё равно требуется провалиться в каждую, чтобы найти нужную.

Заказчик объяснил свой "идеальный мир", как "было бы здорово, если бы она была другим цветом" - мы это услушали. Для читателей, кто подумал про поиск - к сожанию, обычный поиск не поможет, поскольку значение для поиска содержалось буквально в каждой карточке, а нам нужно было фильтровать по условиям, чего фильтр в поиске битрикс24 не может.

Однако для нас такие задачи - вызов и мотивация реализовать с минимальными усилиями. На маркетплейсе готовых решений мы нашли всего 2 похожих модуля, однако они почти предоставляли необходимое, но не до конца, поэтому для заказчика мы реализовали новое расширение в его браузере для работы с карточками. Результат на скриншоте ниже:

Карточки с определенными условиями стали подсвечиваться. Да, это работает только для того, у кого установлено расширение, это не какой-то продукт, который можно продавать, однако и цели у нас были иные - закрыть потребность в явной идентификации карточки на объеме. Если потребуется другому сотруднику это видеть - установка в 1 клик и всё работает. Заказчик остался доволен.

Результаты: было → стало