← До блогу

Команда вже перевірила дані в CRM — а payroll усе одно перенабирає їх вручну

Команда перевіряла дані співробітників у CRM. Payroll вводив їх знову. Як validation-міст прибрав щомісячне копіювання між CRM і payroll SQL Server.

CASE STUDY - HR & PAYROLLCRMverified dataValidation bridgecheck before importPayrollSQL ServerWhen data is verified twiceVerified once in CRM - validated again before payroll

Команда вже перевірила дані в CRM — а payroll усе одно перенабирає їх вручну

Щомісяця той самий ритуал. Відкрити CRM. Відкрити payroll. Скопіювати перший договір — PESEL, суми, дати, страхові прапорці. Потім наступний. Потім ще кілька сотень.

Найбільше дратує не те, що дані неправильні чи відсутні. Команда вже перевірила їх у CRM — спільно, уважно, як і мають перевірятися хороші дані. Проблема в тому, що відбувається після цього: ті самі перевірені записи вручну перенабираються в другу систему, яка ніколи не була створена слухати першу.

Ця прогалина — не дані, прогалина — там і живуть години та помилки.

Дві системи, один ручний шов

Польська HR і payroll-компанія працювала з двома паралельними світами:

  • CRM — договори, білінг і записи співробітників. Увесь колектив підтримував систему, тому дані всередині були надійними.
  • Payroll-движок (SQL Server) — декларації ZUS, PIT і виплати зарплат. Його вели бухгалтери, і нічого туди не потрапляло випадково.

Між ними — нічого. Готовий конектор не дістає до legacy польської payroll-бази. Zapier і Make ввічливо зупиняються на API. Міст між «перевірено в CRM» і «живе в payroll» — людина, клавіатура та сотні цивільно-правових договорів, перенабираються щомісяця.

При такому обсязі це не ризик друкарської помилки, яким можна керувати. Це повна зарплата за перенесення даних, які вже існували.

Що ми побудували

Ми не замінювали CRM. Ми не замінювали payroll. Ми побудували бракуючий шов між ними — вузький міст, який робить одну річ винятково добре:

CRM → validation → payroll. Перевірено один раз, потрапило правильно — щоразу.

Забирає. Міст отримує дані місяця напряму з CRM через REST API — сім пов'язаних таблиць, з пагінацією та врахуванням tenant'ів, щоб multi-entity компанії залишалися чисто розділеними. Якщо API недоступний, перемикається на захищене підключення до бази. Бухгалтер про це не думає.

Перетворює. Записи CRM рідко збігаються зі схемою payroll поле в поле. Міст бере на себе негламурну реальність: legacy-формати дат, домовленості щодо номерів договорів, повний розбір ZUS, маршрутизацію кожного запису в потрібну юрособу. Мапінг, який люди робили в голові, тепер відбувається однаково щоразу.

Перевіряє перед записом — і це серце рішення. Доки хоча б один рядок не пройшов перевірку, у payroll нічого не потрапляє. Міст незалежно перераховує кожну суму за актуальними польськими податковими правилами — ZUS, PIT, zdrowotne — і порівнює результат із CRM:

  • до 0,05 PLN → чисто
  • до 1,05 PLN → позначено як відоме округлення між системами
  • більше → зупинено та зафіксовано з діагностованою ймовірною причиною

У payroll-базу нічого не потрапляє, доки перевірка не пройдена. Помилки, які раніше спливали при відхиленні ZUS, тепер спливають до запису — коли виправити їх дешево.

Імпортує безпечно. Перевірені записи записуються одним контрольованим проходом у таблиці співробітників, договорів і обов'язкового страхування. Кожен запуск починається з dry-run. Якщо щось не так, вся партія відкочується чисто — без напівготового місяця, який треба розплутувати.

Лагодить. Коли значення потрібно виправити після імпорту, міст синхронізує окремі записи за номером договору — суми, імена — без повторного імпорту місяця. Обслуговування залишається точковим, а не руйнівним.

«А хіба Excel не вирішить?»

Роками вирішував. Excel був проміжним кроком — і саме там народжувалися помилки. Число, скопійоване в таблицю і звідти назад, має два шанси помилитися, перш ніж потрапити в payroll.

Міст повністю прибирає людину з копіювання: перевірені дані CRM проходять validation і потрапляють прямо в payroll. Excel досі потрібен — як audit export, запис того, що сталося — але більше не pipeline. Це чек.

Що реально змінилося

  • До: сотні договорів перенабиралися вручну щомісяця → Після: один контрольований імпорт після перевірки командою в CRM
  • До: помилки виявлялися при поданні ZUS → Після: ловляться на validation, до будь-якого запису
  • До: приблизно повна зарплата на ручне введення → Після: pipeline місяця працює за хвилини

Головна цифра — близько $30 000 на рік поверненої праці — з внутрішнього time tracking компанії. Ми позначаємо її як виміряну, а не прогнозну: вона відображає години, які зникли з реального щомісячного процесу.

Патерн під поверхнею

Це був payroll-проєкт, але форма проблеми зустрічається всюди. Коли перевірена інформація живе в одній системі, а операційна робота — в іншій, хтось тихо з'єднує їх вручну і платить за це годинами та помилками.

Рішення майже ніколи не «купити платформу побільше». Це вузький, добре побудований міст із validation на межі — ПЗ, яке поважає системи, яким ви вже довіряєте, і просто змушує їх говорити.

Якщо команда веде дані в одному місці й щомісяця перенабирає їх в іншому — це не процес. Це витік. І про нього варто поговорити.