У клиента уже работали и 1С:ЗУП, и Битрикс24. На бумаге все выглядело аккуратно, но уволенный сотрудник еще 4 дня оставался руководителем отдела в портале, получал согласования и видел то, чего видеть уже не должен был. Системно это выглядит просто: кадровое событие произошло в одной системе, а рабочая жизнь компании продолжилась в другой, как будто ничего не случилось.
Если у вас та же связка, вопрос не в том, можно ли их соединить. Соединить можно. Вопрос в другом: какой обмен действительно убирает потери в первые недели, а какой только увеличивает бюджет и объем поддержки.
Где расхождение уже бьет по процессам
Обычно 1С:ЗУП хранит кадровую правду, а Битрикс24 - оргструктуру, задачи, согласования и доступы. Пока изменения кто-то переносит руками, компания живет сразу в двух версиях данных.
У нас был проект в сервисной компании на 180 сотрудников. Оргструктуру обновляли раз в 2-3 недели, потому что изменений вроде бы немного. На практике после переводов и увольнений 12-15% согласований уходили старым руководителям и возвращались обратно. Формально портал работал, но по факту люди обходили систему вручную.
1С:ЗУП - что это и почему она обычно главная? Это кадрово-зарплатная система на платформе 1С 8.3, где фиксируются приемы, увольнения, переводы, отпуска и статусы занятости. Если в компании один кадровый источник, остальные системы должны читать его, а не спорить с ним.
Если сотрудник уволен в 1С, но активен в Битрикс24, это уже не вопрос удобства. Это доступы, маршруты и чужие решения от имени человека, которого в компании уже нет.
Первая очередь почти всегда меньше, чем кажется
Частая ошибка - пытаться обменивать все сразу: отпуска, документы, расчетные листки, каждое поле карточки. Мы шли этим путем на одном проекте и через месяц сами сократили состав интеграции. Я бы назвал это полезной ошибкой: поддержка стала тяжелее пользы, и это быстро проявилось.
Быстрый эффект обычно дает базовый контур:
- сотрудники и их внутренний ID
- подразделения, должности, руководители
- дата приема, увольнения и статус активности
- отсутствия: отпуск, больничный, командировка
У компании на 90 сотрудников этого хватило, чтобы убрать 8-10 часов ручной работы HR в месяц. Документы сознательно оставили на потом: они добавляли сложность, но почти не меняли ежедневные процессы.
До/после
| Что было | Что стало после запуска |
|---|---|
| Структуру правили вручную | Обновление 4 раза в день |
| Дубли сотрудников в портале | Ошибки снизились до менее 1% |
| Увольнения зависали на несколько дней | Доступ закрывался в дату события |
Сначала правила обмена, потом API
Технически связать системы несложно. Сложнее договориться о логике: кто считается активным сотрудником, как вести совместителей, ГПХ, декрет, временный перевод, внешнего подрядчика.
У одного клиента было 3 типа пользователей: штатные, ГПХ и внешние консультанты. Пока мы не разделили их правилами, Битрикс24 создавал лишние учетные записи, а лицензии расходовались впустую. Интеграция при этом считалась рабочей, хотя бизнесу от этого легче не становилось.
Минимальный mapping я обычно фиксирую заранее:
1С:ЗУП поле -> Битрикс24 поле -> правило
Сотрудник.ID -> XML_ID -> не менять после создания
Подразделение -> UF_DEPARTMENT -> обновлять по расписанию
Руководитель -> UF_HEAD -> пересчитывать при переводе
Дата увольнения -> ACTIVE/N -> выключать в день события
Тип занятости -> пользовательское поле -> по правилам компании
Если упростить, здесь одна мысль: интеграция ломается не на REST API, а на неоговоренных исключениях.
Готовый модуль, кастом или гибрид
Для типового обмена по сотрудникам и структуре обычно хватает готового модуля. Если данные в ЗУП и портале более-менее чистые, запуск занимает 2-3 недели. Для малого бизнеса и части среднего этого хватает на годы.
Кастом через REST API Битрикс24, вебхуки и сервисы 1С нужен, когда появляются несколько юрлиц, матричная структура или особые права доступа. Один такой проект у нас занял 8 недель: человек мог состоять сразу в двух контурах управления, и типовой коннектор там упирался в свою базовую модель.
Когда точно не стоит идти в кастом сразу? Когда у вас обычная оргструктура и главная боль - увольнения, переводы и руководители. Логичнее сначала закрыть это модулем и проверить, что процессы вообще выровнялись.
А если у вас 1С:ЗУП Фреш? Ограничения облака лучше проверить в самом начале. В прошлом году мы потеряли почти неделю на способе публикации сервисов. Неприятно, но на этапе обследования это можно было предотвратить.
Запуск - это половина работы
Рабочая схема выглядит скучно, но именно поэтому и работает: аудит данных, правила ручных правок, тестовый контур, пилот на одном подразделении, потом расписание. На одном внедрении мы нашли 14% дублей карточек сотрудников, потому что людей сначала заводили руками в Битрикс24, а потом подтягивали из ЗУП с другим написанием ФИО.
После запуска нужны логи обмена, ответственный за разбор ошибок и простое правило: кто вообще имеет право менять кадровые записи в портале. Иначе даже хорошая связка через пару месяцев снова начинает расходиться.
Проверьте один сценарий уже сегодня: что произойдет, если вечером уволить руководителя отдела. Если ответ звучит как «утром кто-нибудь поправит руками», у вас пока нет интеграции - у вас есть надежда на внимательность людей. Кто у вас отвечает за нее в пятницу в 19:40?
