"Кадры - отдельно, КЭДО - отдельно". Продуманная стратегия или “так получилось”?

На текущем рынке мы с удивлением обнаружили устоявшуюся уже практику, когда “КЭДО” почему-то является отдельным решением, независимым от основной HR/HCM системы. Пытаясь разобраться в причинах “почему так”, мы проделали достаточно большую работу. Большинство собеседников или не смогли ответить на вопрос или “так получилось”, слышали мнения вроде “чем независимее КЭДО от HR-системы, тем ИТ-архитектура надежнее и более управляема”.

Но на практике крупные внедрения HR-систем показывают обратное: независимость продукта КЭДО не должна означать независимость данных КЭДО от всей учетной кадровой системы. Искусственное разделение баз данных (БД) ведёт к образованию коллизий. В кадровой базе одна информация, в системе КЭДО - другая. 

Как только кадровый контур разделяется на несколько систем хранения и несколько источников состояния сотрудника, компания получает не отказоустойчивость, а новый “класс” рисков — рассинхронизацию юридически значимых данных. 

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

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

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

Рассмотрим пример. Все первичные кадровые события юридически и функционально сосредоточены в 1С:ЗУП: здесь ведутся расчеты, хранятся штатные расписания и формируется «цифровой след» каждого сотрудника. В компании используется внешнее КЭДО, синхронизируемое с 1С:ЗУП через очередь событий. 

• В определенный момент кадровая система фиксирует изменение данных по сотруднику — например, отмену отпуска или изменение графика работы. Это событие отправляется в очередь, но доставка в КЭДО происходит с задержкой в несколько секунд \ минут (что является нормой для асинхронной архитектуры).
• В этот момент сотрудник формирует и подписывает заявление на отпуск при отсутствии достаточного остатка дней или в период пересечения с другим отсутствием. 
• Результат: технический сбой превращается в юридическую ловушку для компании. Подписание документа в момент рассинхронизации легализует ошибку работодателя и повышает риск обращения сотрудника в суд.
• Попытка компании скорректировать кадровые и зарплатные данные постфактум неизбежно спровоцирует конфликт, в котором бизнес получает заведомо проигрышную позицию в трудовом споре. 

Мы рассматриваем КЭДО не как отдельный продукт, а как функциональный слой самообслуживания. В архитектуре EmplDocs бизнес-логика строится на бесшовной работе: все данные остаются строго в периметре 1С:ЗУП. Интерфейс КЭДО отражает актуальное состояние информации напрямую из базы 1С. Юридическая точность данных обеспечена самим фактом их существования в одной базе. 

Ниже пример интерфейса  “Личный кабинет сотрудника” в EmplDocs - работает как нативное продолжение 1С:ЗУП и отражает данные прямо из 1С в режиме реального времени.

Что означает на практике, когда КЭДО – функциональный слой:

• единый источник правды (SSOT) с нулевым риском расхождения данных, где ЭЦП является функцией кадровой системы;
• отсутствие точек отказа: не появляется новых векторов атак и объектов для аудита ИБ, так как используется существующая и проверенная инфраструктура 1С;
• поддержка кастомизаций: любые изменения, печатные формы или уникальные бизнес-процессы в 1С:ЗУП доступны сразу в КЭДО без написания дополнительных скриптов обмена;
• снижение TCO (стоимость владения): не платите за внедрение и поддержку систем мониторинга для новой БД, стоимость владения снижается за счет использования компетенций штатной команды 1С.

Выбор в пользу нативной архитектуры — это не просто вопрос удобства вашего ИТ. Это способ гарантировать, что каждый подписанный документ в системе на 100% соответствует данным в 1С:ЗУП, а сотрудник физически не сможет подписать документ на основе устаревших данных. Это ликвидирует ошибки при подписании и дает компании уверенность при проверках ГИТ.