Служба безопасности видела 90% отказов. На деле реальных решений было около 3 тысяч — остальное дефолт в системе. Реальный проект, который я делал лично: группа компаний спецтехники, три отдела — безопасность, финансы и логистика. Каждый вёл свою правду в своей системе, и никто не видел общей картины. Служба безопасности знала, кому нельзя отгружать. Финансовая служба знала, кто не платит. Логистика знала, где стоит техника. Проблема в том, что эти три знания жили раздельно — риск был виден только когда деньги уже потеряны. Что нашли при разборе Когда я поднял процессные регистры и стал разбирать, что стоит за отметкой «запретить», оказалось: 90% этих отметок — не решение человека, а значение по умолчанию в системе. Реальных, осознанных решений за этим стояло около 3 000. То есть отдел безопасности выглядел так, будто блокирует почти всё подряд, хотя фактически принимал точечные решения. Это была ошибка учёта, а не описание работы департамента — и на её основе руководство могло бы сделать неверные выводы о качестве работы отдела. Что сделал Я построил витрины данных из процессных регистров всех трёх служб, разработал методику разбора решений — как отличать реальный отказ от технического дефолта — и собрал дашборд из четырёх листов со светофором просрочки проверок. • Было: доля «запретов» 90% — стало: очищено до ~3 000 реальных решений • Было: скорость проверки не измерялась — стало: 95% за 1–2 дня, 97% за 3 дня • Было: исполнение блокировок — предположение — стало: подтверждено фактом Раньше руководитель мог сделать вывод, что отдел безопасности парализует отгрузки. После разбора выяснилось обратное: отдел работал точечно, просто данные врали.