Корпоративный портал Битрикс24: какие его части приживаются в компании, где продажи уже в CRM

Что ищут под словами «корпоративный портал»

Под этим запросом ищут две разные вещи, и полезно сразу их развести.

Первая — редакция коробочной версии «1С-Битрикс24: Корпоративный портал». Коробка устанавливается на сервер компании, редакция определяет состав и число пользователей: в справке Битрикс24 указаны пакеты на 50, 100, 250 и 500 пользователей. Выбор между облаком и коробкой — отдельный разговор про инфраструктуру, доработки и интеграции, в этой статье я его не касаюсь.

Вторая — сам портал как набор инструментов для сотрудников. Он есть и в облачном Битрикс24, и в коробке. О нём дальше и пойдёт речь.

Структура компании: с неё начинается всё остальное

Если на портале криво заведена структура компании, криво работает всё, что от неё зависит, а зависит от неё почти всё.

Справка Битрикс24 перечисляет связи прямо. Права доступа выдаются целым отделам: отделу продаж роль «Менеджер» в CRM, и каждый менеджер видит свои сделки. Рабочие отчёты сотрудника автоматически уходят руководителю отдела, а если руководитель не назначен, то руководителю вышестоящего отдела. В разделе «Руковожу» руководитель видит задачи подчинённых. Отдел целиком добавляется в чат, канал или проект, и новые сотрудники подключаются к ним сами, а при уходе из отдела теряют доступ. Бизнес-процессы, например заявление на отпуск, уходят на утверждение руководителю отдела.

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

Руками структуру поддерживают неделю после внедрения. Поэтому в компаниях, где кадровый учёт ведётся в 1С, я синхронизирую структуру портала с кадровой системой через REST API: отделы, подчинение, руководители и перевод сотрудников. Кадровик оформляет перевод в своей системе, и к утру у сотрудника другой отдел, другие чаты и права, а у его нового руководителя появились его задачи. Отдельно в этой синхронизации нужен шаг, про который легко забыть: после смены отдела старые элементы CRM сотрудника нужно пересохранить, иначе новые права к ним не применятся.

Задачи, которые ставит CRM

В компании, где продажи уже в CRM, задачи портала первыми приживаются там, где они продолжают сделку.

Менеджер договорился об отгрузке. Если задачу складу он ставит голосом или в личном сообщении, через неделю уже не найти, кто и что обещал. Если задачу ставит робот на стадии сделки, у склада появляется задача со ссылкой на сделку, со сроком и ответственным, а в таймлайне сделки видно, выполнена ли она.

Внутри самих задач тоже есть роботы и триггеры. Роботы срабатывают, когда задача переходит на стадию: отправляют уведомление, ставят следующую задачу, добавляют участников. Триггеры отслеживают изменения, например приближение крайнего срока или смену статуса, и передвигают задачу на нужную стадию. Настраиваются они для «Моего плана» конкретного сотрудника или для проекта целиком.

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

Контроль руководителя без еженедельной сверки

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

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

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

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

Лента и процессы в ней

Лента новостей в Битрикс24 показывает посты коллег, обновления групп и проектов, события, отчёты и запущенные процессы. Если использовать её как внутреннюю соцсеть, она быстро превращается в поздравления с днём рождения, которые пролистывают не глядя.

Живой частью ленты у меня становятся две вещи.

Первая — важные сообщения. Этот вид поста выделяется фоном, показывает отметку о прочтении и висит в правом меню, пока сотрудник его не прочитал. Для изменений цен, условий доставки или графика это работает лучше общего чата: видно, кто прочитал, и сказать «не видел» уже не получится.

Вторая — бизнес-процессы в ленте. Они находятся в разделе Автоматизация → Бизнес-процессы → Процессы в ленте новостей. По умолчанию там пять процессов: счёт на оплату, заявление на отпуск, заявление на командировку, исходящие документы и выдача наличных. Каждый можно отредактировать или создать свой: поля, которые сотрудник заполняет перед запуском, права доступа и сам шаблон процесса, последовательный или со статусами.

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

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

Кадровый документооборот

Если в компании много сотрудников и много кадровых документов, на портале обычно появляется КЭДО: заявления, приказы, ознакомления с подписью сотрудника. Модуль включается быстро, но сам по себе он не решает основную задачу. Документы должны формироваться из кадровой системы, сотрудники должны получить электронную подпись, а согласования должны идти по актуальной структуре компании. Подробно, что нужно кроме самого модуля, я разбирал в статье про КЭДО в Битрикс24.

База знаний и диск

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

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

С чего я начинаю портал в компании, где CRM уже работает

Порядок у меня почти всегда один.

Сначала структура компании и её синхронизация с кадровым учётом, потому что от неё зависят права, согласования и чаты. Затем задачи, которые ставит CRM, потому что там польза видна в первую же неделю и её видит собственник. Потом процессы в ленте, которые сейчас идут через почту: счета на оплату и заявления. КЭДО и база знаний идут последними, когда первые три слоя уже работают.

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

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

Корпоративный портал я запускаю в рамках внедрения Битрикс24, вместе с CRM или вторым этапом после неё.