Подводные камни внедрения глобальной HRMS-системы

Несколько лет назад в одном крупном российском банке, в котором на тот момент было больше 50 офисов по всей стране, возникла задача внедрения глобальной HRMS-системы на базе Oracle e-Business Suite (далее OeBS).

Примечание: в OeBS входит больше 200 модулей. Кроме HRMS есть ешё финансы, логистика и др. Но в данном случае OeBS мы использовали только как HRMS.

В качестве пилота была внедрена OeBS-система в штаб-квартире московского офиса. Затем нужно было подключить 50+ филиалов в данную HMRS-систему, т.е. загрузить кадровые данные из всех филиалов в OeBS.

С чем мы столкнулись на старте?

Во-первых, во всех офисах были разные HRMS-системы (в основном 1С). Но были и другие, включая экзотические (Амба, в переводе «Медведь»), самописные и даже Excel-файлы.

Дело в том, что в разных HRMS-системах разный подход к организации данных. Например, в OeBS все данные разбиты по маленьким объектам (Контракт, Назначение, Оклад, Надбавки и т.д.). А в 1С есть одна форма «Сотрудники», где используется информация по всем Контрактам, Назначениям, Окладам, Надбавкам и пр.

Таким образом, нам надо было либо выгружать данные из всех 50+ систем «as is» и затем конвертировать их в формат OeBS, либо сразу просить данные из филиалов в нужном формате.

Заранее скажу, был выбран 2-ой вариант.

В некоторых офисах данные велись либо сразу в 2-3 системах, либо в одной системе и нескольких файлах. Несмотря на уверение, что все данные между этими источниками согласованы, это оказалось неправдой (в 100% случаях). Таким образом, требовалось ввести дополнительные скрипты контроля бизнес-данных.

Итак, решение

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

Полученные данные (полученный xls-файл сохранялся как csv) загружали в БД Oracle во временные таблицы. Тут использовалась встроенная функциональность клиента БД для загрузки данных из csv-формата. Проводился первый цикл проверки «dummy check» посредством набора SQL-запросов (40+ запросов). Использовались средства именно БД, а не Excel, т.к. по богатству функционала для сравнения и анализа данных БД на порядок превосходит как Excel, так и любые другие средства.

Если такие примеры находились (в 100% случаев такое существовало), то данные отсылались в филиал с просьбой исправить несоответствия и выслать обновлённый файл. Также проводилась техническая подготовка: чтобы исправить особенности Excel и csv, например, убирали двойные пробелы, пробелы в начале и конце строки, заменяли служебные символы на другие.

В системе OeBS запрещено загружать данные напрямую в таблицы БД. Это можно делать только через специальный OeBS API: поскольку при загрузки данных в любой объект (Физ.лицо, Назначение и др.) проводится много проверок и данные записываются сразу в десятки (иногда сотни) таблиц. При нарушении данного правила теряется поддержка.

Когда бизнес-пользователь OeBS вводит данные руками в форме и сохраняет их, система сохраняет введённые данные с помощью этих API, которые сразу включают в себя множество проверок. Если проверка не проходит, система просто не даёт сохранить данные. Пользователь должен их исправить в форме вручную и сохранить.

При автоматической миграции (загрузки) данных разработчик OeBS обязан использовать те же самые API, только в скрипте. Т.е. по качеству данных не будет никакой разницы между данными, введёнными руками, или данными, загруженными скриптом. И те и другие будут одинаково вводиться и проверяться системой, отличается время.

После этого данные начинали грузиться из временных таблиц в OeBS с помощью данных API. В идеале загрузка объектов должна была проводиться подряд. Т.е. сначала загружаются Адреса, затем Подразделения, на которых при загрузке через API нужно было указать ID созданного Адреса, затем Штатные единицы, на которых при загрузке через API нужно указать ID созданного Адреса и Организации, и т.д.

Но в реальной жизни сначала пытались загрузить первый объект в очереди (Адреса). Если были ошибки, сначала просили филиалы их исправить, т.е. дальнейшая загрузка была бессмысленна. После того, как нам присылали все данные, выгруженные заново, начиналось всё сначала. После успешной загрузки Адреса пытались загрузить Организации. Если были ошибки, просили филиалы их исправить.

В среднем уходило 2 месяца на работу с каждым филиалом. Одновременно обрабатывали данные примерно 6-10 филиалов. Работа заняла примерно 1 год и 3 месяца. Это была вторая проверка, т.к. API проводили свою валидацию данных.

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

Вот такая история

Есть вопрос? Напишите в комментариях!