Кейс: как мы внедрили корпоративный портал Битрикс24 в холдинг

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

Для холдингов у Битрикс24 есть отдельная лицензия — «Энтерпрайз. Холдинг». В этом проекте заказчик выбрал другой подход. Портал внедряли на базе лицензии «Корпоративный портал», и этот кейс — о том, как такое решение было реализовано.

АО «МРТС» — холдинг из отрасли строительства инженерных коммуникаций, подводных переходов и гидротехнических сооружений. В компании работает более 1 500 человек, но портал на старте планировали не для всего штата, а примерно для 500 пользователей из управленческого состава.

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

Если структурировать задачи из ТЗ, проект включал в себя:

От лицензии «Холдинг» отказались сразу, потому что заказчик не хотел переплачивать за более дорогую версию и ставил задачу реализовать нужную логику на более младшей лицензии.

Портал нужно было встроить в существующую ИТ-инфраструктуру компании: связать с Active Directory, 1С:Документооборотом и 1С:ERP.

Active Directory закрывал авторизацию: пользователь входил на портал с корпоративной учётной записью.

С 1С:Документооборотом требовалось настроить интеграцию по двум направлениям:

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

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

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

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

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

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

Мы выделили несколько логических сценариев:

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

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

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

Проблема в том, что в Битрикс24 нет сущности «справочник должностей» — нет возможности привязаться к должности как к самостоятельному объекту. Поэтому пришлось реализовать комплексную доработку:

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

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

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

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

Отдельно переработали сам принцип подачи информации на главной странице. Штатная логика Битрикс24 предполагает, что все ключевые сообщения — новости, важные объявления, системные уведомления — публикуются в живой ленте. Однако практика показала, что этот инструмент не очень хорошо работает в больших организациях: информация тонет в потоке, важные сообщения пропускаются, а контроль доставки отсутствует.

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

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

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

Одним из требований заказчика было наличие двух независимых справочников.

Первый — справочник сотрудников, куда попадают только активные пользователи, которые реально работают на портале.

Второй — телефонный справочник, который должен содержать полный список всех сотрудников организации — порядка 750 человек, включая тех, кто не имеет доступа в Битрикс24.

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

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

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

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

Обычно такие задачи закрывают через отдельные сервисы, но здесь их реализовали прямо внутри портала. Для реализации тикет-системы мы использовали модуль CRM, а точнее — Smart-процессы. Каждый тикет был представлен как отдельный Smart-процесс, по сути, сделка в Битрикс24.

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

Для администратора разработали функционал конструктора форм тикетов: пользователь заполнял форму в публичной части портала, а для исполнителя на стороне CRM создавался элемент Smart-процесса, то есть сделка, со своим процессом выполнения. Для сотрудника разработали список тикетов, чтобы он мог посмотреть статус обращения и связаться с исполнителем.

Доска объявлений по задумке заказчика должна была стать своего рода мини-«Авито». Сотрудники часто что-то отдают или продают друг другу, и такой функционал оказался востребованным. Мы реализовали доску объявлений как отдельный самостоятельный модуль с каталогом объявлений, поиском, функционалом модерации объявлений и возможностью связи между сторонами.

Требования информационной безопасности повлияли на проект как полноценный архитектурный фактор.

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

В стандартном Битрикс24 переписка устроена по закрытой модели. Даже администратор, если он не состоит в чате, не может увидеть переписку. У отдела ИБ было прямое требование: уполномоченные сотрудники должны иметь возможность контролировать переписку и действия пользователей внутри всех чатов и групп.

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

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

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

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

На старте казалось, что можно доработать стандартное приложение Битрикс24. Логика была простой: портал уже есть, мобильное приложение у платформы тоже есть, значит, отдельной большой работы здесь быть не должно.

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

Вариант с отдельной нативной разработкой означал бы уже новый большой проект: собственный API, мобильный фронт, отдельную поддержку, дополнительные сроки и бюджет, что заказчика категорически не устраивало.

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

Поэтому основной объём работы в мобильной части был связан с переработкой штатного функционала Битрикс24 под мобильный формат. Фактически нам пришлось переверстать меню, формы, списки и весь штатный функционал Битрикс24 под мобильные устройства.

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

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

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