Так как сфера HR аналитики у нас сейчас на ранней стадии развития, то очень часто сталкиваюсь с тем что не сходятся HR цифры в исходных системах и на дашбордах. Сделал отчёт, показал цифры, договорился о выводах, на следующей неделе уже приходят с вопросом: “Слушай, а почему у нас за прошлый месяц теперь другие значения?” И пошло-поехало: сомнения в качестве данных, сомнение в метриках, сомнение в аналитике вообще.
Довольно сложно иногда объяснять, что аналитические данные почти никогда не ведут себя как камень. Они достаточно живые, если так можно сказать. В них догружаются события, переписываются статусы, обновляются справочники, меняются правила расчёта, исправляются ручные ошибки. И это в целом нормально. На мой взгляд, проблема тут начинается не с ретро-изменений, а с того, что мы делаем вид, будто их не существует, и не договариваемся, какая версия данных считается окончательной и когда.
Я регулярно разбираю такие темы в своём Telegram-канале, если вам интересно глубже понимать аналитику и работать с данными, там регулярно выходят короткие заметки и практические примеры.
Почему ретро-изменения вообще происходят
Самая частая причина ретро-изменений очень проста: события приходят с задержкой. В HR это частая история: кандидат вышел на работу, но факт выхода подтверждается позже или вакансию закрыли, но статус в системе обновили через пару дней или увольнение оформлено, но данные прошли через несколько контуров согласования и попали в витрину не сразу и т.д. и т.п.
Вторая причина - ретро-правки и исправления. Люди ошибаются, процессы меняются, системы обновляются. Где-то исправили дату, где-то поменяли причину отказа, где-то объединили статусы, а где-то наконец-то удалили дубли. И эти правки часто отражаются задним числом, потому что они исправляют уже фактические события.
Третья причина - изменение правил расчёта или справочников. Например, пересобрали мэппинг ролей, изменили правила отнесения к подразделениям, уточнили определение закрытой вакансии”, добавили новый фильтр в расчет с исключением резервистов и т.д. и т.п. Данные то сами остались такими же, но но способ его измерять изменился, и цифры закономерно полетели.
И есть ещё одна причина, которую часто упускают: несколько источников данных. Одни данные живут в ATS, другие в HRIS, третьи в финансовой системе, четвёртые в ручных таблицах. Каждый контур обновляется в своём темпе, и истина, если ее так можно названить, в разные дни выглядит по-разному в том числе из-за того, в какую систему мы смотрим и какой приоритет работы этих систем.
Фактор неожиданности
Если цифры меняются, но это предсказуемо и объяснимо, люди это нормально воспринимают. Когда же они меняются внезапно и никто не понимает почему, то вот тут появляется ощущение хаоса, поэтому управленческая задача аналитика тут не в том, чтобы навсегда устранить ретро-изменения (обычно это попросту невозможно), а в том, чтобы сделать их управляемыми и прозрачными.
Как с этим работать
Я предлагаю следующее:
Первое - окна догрузки. Вы заранее договариваетесь у себя в компании, что допустим за последние, например, 7 или 5 дней данные могут меняться, потому что события доезжают и статусы уточняются. Это снимает половину вопросов, потому что появляется ожидаемость.
Второе - заморозка периода. Это уже более сурово, тут вы говорите что-то вроде: "Период закрыт, фиксируем все цифры". Конечно, не обязательно замораживать навсегда, но хотя бы на некоторое время. В финансах это закрытие месяца, в HR аналитике часто это тоже работает: например, месяц закрываем на 5-й рабочий день следующего месяца, потому что большинство событий успевает догрузиться.
Третье - корректная версия. На практике это может быть просто: вы храните дату обновления витрины и версию расчёта метрики. И, соответственно, когда любой отчёт становится воспроизводимым: можно сказать, что вот цифры на дату Х по версии правил Y. Это нормальная гигиена работы с данными, которая защищает аналитика и снижает количество всевозможных выяснений причин расхождений.
Вывод
Ретро-изменения в данных - это не признак плохой аналитики, а естественное свойство живых процессов, где события доезжают с задержкой, статусы уточняются, а правила расчета метрик со временем становятся точнее. Неприятности обычно начинаются тогда, когда это происходит неожиданно и без объяснения.
Поэтому задача аналитика здесь сделать изменения управляемыми: окно догрузки, заморозка периода, версия расчёта и прозрачное объяснение причин. Когда это есть, доверие к цифрам возвращается, а отчёты перестают быть источником споров и снова становятся инструментом решений.