Analyst Days 14: Не крась траву — риски данных в BANI-мире

В мае 2022 года я выступил на Analyst Days 14 с докладом «Не крась траву или правда о ценности и рисках данных в BANI мире». Конференция прошла 27–28 мая в Москве.

Это реконструкция доклада в редакции от 21 октября 2026 года, дополненная последующим профессиональным опытом. Дата первоначальной публикации текста не установлена. Примеры обобщены; внутренние показатели и масштаб корпоративных систем я намеренно не раскрываю.

Что значит «красить траву»

Метафора описывает разрыв между отчётом и работающим процессом. Политика data governance может быть согласована, каталог — запущен, а на вопрос о владельце критичного показателя никто не отвечает. Формально активность есть, но риск остался.

Противоположность — не идеальная витрина и не большой набор инструментов. Это несколько практических свойств:

• у критичных данных есть владелец;
• смысл показателя согласован;
• качество измеряется;
• источник и преобразования можно проследить;
• ошибка обнаруживается раньше жалобы пользователя;
• есть понятное действие при нарушении качества.

Если эти свойства работают, оформление документации становится полезным следствием, а не заменой управления.

BANI как способ задавать вопросы

BANI — предложенная Jamais Cascio рамка для разговора о сложной среде, описанная в эссе Facing the Age of Chaos (2020). Я использовал её не как доказательство и не как замену анализу, а как четыре группы вопросов.

Свойство	Вопрос к данным
Brittle — хрупкость	Какая зависимость создаёт каскадный отказ?
Anxious — тревожность	Каких данных не хватает для уверенного решения?
Non-linear — нелинейность	Где небольшая ошибка заметно меняет итог?
Incomprehensible — непостижимость	Можем ли мы объяснить происхождение результата?

Модель полезна, пока приводит к конкретной проверке. Фраза «мир стал BANI» сама по себе ничего не исправляет.

Иллюстративная цепочка ошибки

Представим организацию, где сотрудники фиксируют визиты к клиентам, а эти записи используются для прогноза спроса.

Если система принимает некорректную геолокацию или повторный отчёт без проверки, ошибка движется дальше: активность завышается, прогноз меняется, закупочный план опирается на искажённую картину. Ни один шаг не обязан выглядеть аварией. Каждый компонент может успешно выполнить неверный сценарий.

Это составной учебный пример, а не утверждение о конкретной компании или числе сотрудников. Его смысл — показать цепочку GIGO: Garbage In, Garbage Out становится управленческой проблемой, когда ошибка усиливается последующими решениями.

Контроли нужны в нескольких местах: валидация события, проверка повторов, сравнение распределений, владелец бизнес-правила и обратная связь от фактического результата.

Банковский контекст и Mirion

В 2021–2023 годах я работал с графовой платформой Mirion и направлением прикладных сервисов Big Data. Один из классов задач — сопоставление сущностей по совокупности признаков и развитие концепции «золотой записи».

Проблема знакома многим большим организациям: один клиент или контрагент представлен в разных системах с отличающимися названиями, адресами и идентификаторами. Сопоставление только по точному совпадению строки может оставить записи одного субъекта несвязанными, а слишком свободное правило может ошибочно объединить разных субъектов.

Графовая модель и набор признаков помогают исследовать связи, но не отменяют управленческих решений:

• кто определяет критерий совпадения;
• какая система считается источником каждого атрибута;
• как разбираются спорные пары;
• как измеряются ложные объединения и пропуски;
• кто принимает изменение правила в промышленную эксплуатацию.

Этот кейс относится к Mirion и data-направлению того периода. Он не является описанием раннего real-time продукта или нового Decision Engine.

DAMA и ISO: рамки, а не готовый процесс

DAMA-DMBOK помогает увидеть области управления данными: governance, архитектуру, моделирование, качество, master data, metadata, интеграцию, хранение и безопасность. Организации не обязаны внедрять всё одновременно. Полезнее определить критичные данные и начать с риска, который уже влияет на решения.

Семейство ISO/IEC 27000 относится к системе управления информационной безопасностью. Оно помогает выстроить работу с конфиденциальностью, целостностью, доступностью, доступами и рисками. Но стандарт безопасности не заменяет data governance и не объясняет бизнес-смысл показателя.

Я использую такие рамки как карту вопросов, а не как доказательство зрелости. Наличие политики или сертификата ещё не показывает, что конкретная цифра в отчёте прослеживается до источника.

Минимальная проверка управления данными

1. Критичные объекты и владельцы

Какие данные влияют на клиента, деньги, обязательную отчётность или ключевое решение? Кто отвечает за определение, качество и изменение правила?

2. Измеримое качество

Для каждого критичного набора нужны подходящие характеристики: полнота, актуальность, точность, согласованность, уникальность. Не все метрики нужны везде; важно связать каждую с риском использования.

3. Происхождение и преобразования

Можно ли пройти от показателя обратно к источнику, увидеть формулу, фильтры, соединения и время обновления? Если lineage отсутствует, начать можно с нескольких наиболее важных отчётов.

4. Наблюдаемость потока

Успех технической задачи не равен качеству данных. Нужны проверки объёма, распределений, задержки и доли значений по умолчанию.

5. Управление изменениями

Кто узнает об изменении схемы или правила? Как проверяется влияние на потребителей? Можно ли повторить расчёт и сравнить результат до поставки?

6. Реакция на нарушение

У метрики должен быть не только порог, но и действие: остановить публикацию, пометить данные, переключить источник, пересчитать период или уведомить владельца решения.

С чего начинать

Для первого практического шага не обязательно ждать завершения многолетней программы. Выберите один показатель, который действительно влияет на решение, и проведите его по цепочке:

1. согласуйте определение;
2. назовите владельца;
3. найдите источники и преобразования;
4. определите проверку качества;
5. настройте реакцию на отклонение;
6. зафиксируйте результат так, чтобы его можно было поддерживать.

Так метафора «не красить траву» превращается в работу. Data governance начинается не с количества документов, а с способности объяснить, кому принадлежит конкретное решение о данных и как команда узнаёт, что оно перестало работать.

---

По мотивам доклада о ценности и рисках данных, Analyst Days 14, май 2022. Редакция от 21 октября 2026 года; текст не является стенограммой. Карточка организатора с записью выступления.

Ваш ДПУПП