Audit trail KPIsKPI истории действий
A large event count does not mean important changes can be explained. An action-history dashboard should answer different questions: which expected events are available, what information is missing and how many reviews remain unresolved. Its purpose is to show evidence quality and the review queue. Individual employees’ event counts are not a measure of productivity.Большое число записей в журнале не означает, что важные изменения можно объяснить. Панель истории действий должна отвечать на другие вопросы: какие ожидаемые события доступны, какие сведения отсутствуют и сколько разборов остаётся без решения. Её задача — показывать качество доказательств и очереди проверки. Количество действий отдельных сотрудников не служит мерой их производительности.
Define the expected event populationОпределите ожидаемые события
List the changes that need a history, such as revisions to an agreed price, stock adjustments and permission changes. Specify an independent source of expected operations for each category. Measure coverage as the share of those operations with a corresponding history entry. The log cannot provide its own reliable denominator: missing events will not appear there.Составьте список изменений, для которых нужна история: например, изменение согласованной цены, корректировка остатка и смена прав. Для каждой категории укажите независимый источник ожидаемых операций. Покрытие рассчитывайте как долю таких операций, которым найдена соответствующая запись истории. Нельзя получить честный знаменатель из самого журнала: пропущенные события в нём не появятся.
Match operations through a stable identifier and a defined event type. If no independent source exists, mark coverage as unknown and show the size of the checked sample. Do not replace an unknown value with zero missing events. List categories that are outside the current review scope separately.Сопоставляйте операции по устойчивому идентификатору и заранее определённому типу события. Если независимый источник отсутствует, обозначьте покрытие как неизвестное и показывайте объём проверенной выборки. Не заменяйте неизвестное значение нулём пропусков. Отдельно перечислите категории, которые вообще не входят в текущую проверку.
Check required informationПроверяйте обязательные сведения
Completeness depends on the event. A value change may need the object, previous and new values, actor and time; an approval request may need the requester, time and linked object; a decision entry needs the outcome, approver and linked request. Measure the share of records containing every field required for their category. Fields that do not apply must not count as defects.Полнота записи зависит от события. Для изменения значения могут быть нужны объект, прежнее и новое значения, исполнитель и время; для запроса согласования — запросивший, время и связанный объект; для решения — результат, согласовавший и ссылка на запрос. Считайте долю записей, в которых заполнен весь обязательный для их категории набор. Неприменимые поля не должны ухудшать показатель.
Text being present does not make a reason useful. Review a sample to see whether the reason explains the decision or merely repeats “corrected.” Track unreadable values, unknown actors and broken links separately. For automated changes, check process identity; demanding a human name on every entry would create false defects.Наличие текста ещё не делает причину полезной. В выборке проверьте, объясняет ли она основание решения или состоит из повторяющегося «исправлено». Отдельно отмечайте нечитаемые значения, неизвестных исполнителей и потерянные связи. Для автоматизированных изменений проверяйте идентификацию процесса; требование человеческого имени к каждой записи даст ложные ошибки.
Separate delay from event orderРазделите задержку и порядок событий
When operation time and recording time are both available, delay is the difference between them. Show the delay distribution and observation count, using a consistent time zone for comparison. Keep delayed imports in a separate group. A single timestamp cannot establish event-delivery delay.Если доступны время операции и время её регистрации, задержка равна разности этих отметок. Показывайте распределение задержек и число наблюдений, сохраняя один часовой пояс для сравнения. События из отложенного импорта выделяйте в отдельную группу. По одной отметке времени нельзя вычислить задержку доставки события.
A negative difference calls for checking clocks and field meanings. A late entry may describe an earlier operation, so row order is not always action order. Include a source-freshness indicator: yesterday’s complete export does not establish coverage of today’s changes. Assign the data-source owner to resolve recording delays.Отрицательная разность требует проверки часов и смысла полей. Поздняя запись может относиться к более ранней операции, поэтому порядок строк не всегда равен порядку действий. В панели нужен индикатор свежести источника: вчерашняя полная выгрузка не подтверждает полноту сегодняшних изменений. За устранение задержки назначьте владельца источника данных.
Show unresolved review casesПокажите незакрытые разборы
A review-queue snapshot should include the oldest case age, next action and responsible person. A case is a question about a particular operation, not every row in a log. Several entries may belong to one review and must not inflate the incident count.Снимок очереди разборов должен включать возраст самого старого случая, следующий шаг и ответственного. Случай — это вопрос о конкретной операции, а не каждая строка журнала. Несколько записей могут относиться к одному разбору; их количество не должно увеличивать число инцидентов.
Measure duration for cases completed in the chosen period and display open cases alongside them. A quick closure without an established answer is not a quality resolution. Distinguish outcomes: cause established, record corrected, insufficient evidence or issue escalated. A reopened case should retain its connection to the original review.Длительность закрытых разборов считайте по случаям, завершённым в выбранный период, и показывайте рядом открытые. Быстрое закрытие без подтверждённого ответа не равно качественному решению. Разделите исходы: причина подтверждена, запись исправлена, данных недостаточно, вопрос передан дальше. Повторно открытый случай сохраняет связь с первоначальным разбором.
- Dashboard check: every overdue case identifies the obstacle and the person able to remove it.Проверка панели: у каждого просроченного случая видны препятствие и человек, который может его устранить.
Reconcile metrics to source recordsПроверьте цифры на исходных записях
Select different event types and manually reproduce the coverage and completeness calculations. Then check a missing entry, repeated delivery and late import. Establish how corrections affect the report: whether a previous period is recalculated or an adjustment is shown separately. Use the same rule across the periods being compared.Выберите события разных типов и вручную воспроизведите расчёт покрытия и полноты. Затем проверьте пропущенную запись, повторную доставку и запоздалый импорт. Установите, как обновляется отчёт после исправления: пересчитывается ли прошлый период или показывается отдельная корректировка. Одинаковое правило должно действовать во всех сравниваемых периодах.
Set response thresholds from the workflow’s needs and available data quality. No universal completeness percentage establishes reliability for every business. First verify the events and fields available in the selected SABSUS configuration, then document report definitions and responses to exceptions. A metric without an available source remains a requirement rather than a working capability.Порог для реакции задавайте из потребностей процесса и качества доступных данных. Универсального процента полноты, который доказывает надёжность любого бизнеса, нет. Сначала подтвердите, какие события и поля предоставляет выбранная конфигурация SABSUS, затем закрепите определения отчёта и действия при отклонении. Метрика без доступного источника остаётся требованием, а не готовой возможностью.
Quick answersКороткие ответы
Why not measure coverage from the log itself?Почему нельзя считать полноту по самому журналу?
It only contains entries that arrived. Missing-event coverage needs an independent list of expected operations or a clearly described checked sample. Otherwise the metric hides its own gaps.В нём видны только полученные записи. Для оценки пропусков нужен независимый список ожидаемых операций или явно описанная проверенная выборка. Иначе показатель скрывает собственные пробелы.
Does a high correction count mean poor performance?Большое число исправлений означает плохую работу?
It may reflect changing workload, recording rules or timely error discovery. Compare operation types, reasons and consequences; an event count without context does not assess a person.Оно может означать изменение нагрузки, правил регистрации или своевременное обнаружение ошибок. Сопоставляйте виды операций, причины и последствия; число событий без контекста не оценивает человека.
What should appear when a source is unavailable?Что показывать при недоступном источнике?
Mark the source unavailable and retain its last successful update time. Do not display a healthy status or zero missing events using stale data; assign someone to restore the check.Отметьте источник как недоступный и сохраните время последнего успешного обновления. Не выводите зелёный статус или нулевые пропуски по старым данным; назначьте ответственного за восстановление проверки.