Analyst Days 14 / Импульс 2022: Не крась траву — риски и ценность данных в BANI мире

5000 продавцов, которые никуда не ходили

Крупная FMCG-компания, B2B-сегмент. Несколько тысяч торговых представителей. CRM, аналитические дашборды, прогнозирование спроса — полный набор. Руководство смотрит на графики покрытия территории и видит красивую картину: визиты к клиентам растут, активность на максимуме.

Одна проблема: часть визитов никогда не происходила.

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

Фиктивный визит ──> Ложный прогноз ──> Лишние закупки ──> Перепроизводство
   продавца           продаж              сырья            ──> Убытки
                                                               в фин.плане
     GARBAGE IN ─────────────────────────────────────────> GARBAGE OUT

Четыре шага от вранья в CRM до дыры в финансовом плане. GIGO — Garbage In, Garbage Out. Принцип, который знают все и игнорируют большинство.

Этот кейс я привёл на Analyst Days 14, Импульс 2022 и ЛАФ 2022. И каждый раз после доклада ко мне подходили люди и говорили: «У нас то же самое, только в другой обёртке».

Не крась траву

Есть старый армейский анекдот. Командир говорит: «Завтра приезжает генерал, территория должна быть зелёной». И солдаты красят траву зелёной краской. Формально — требование выполнено. По сути — идиотизм.

С данными в корпорациях — то же самое. Можно написать политику управления данными, повесить на стену, отчитаться. Это и есть — красить траву. А можно выстроить процесс: назначить ответственных, внедрить контроль качества, автоматизировать проверки, обучить людей. Посадить газон.

Разница видна не сразу. Крашеная трава выглядит прилично на фотографии. Но после первого дождя краска смывается. А газон — растёт.

Эта метафора будет красной нитью через всю статью. Каждый раз, когда увидишь решение, которое выглядит красиво на слайде, но не работает в реальности — ты знаешь, что это. Краска на траве.

BANI: мир, в котором мы работаем

VUCA устарел. Добро пожаловать в BANI — более точную модель текущей реальности.

BANI	Значение	Что это значит для данных
Brittle (хрупкий)	Системы ломаются внезапно и каскадно	Один сбой в источнике обрушивает всю цепочку отчётности
Anxious (тревожный)	Неопределённость парализует решения	Без качественных данных менеджеры решают на страхе и интуиции
Non-linear (нелинейный)	Малое на входе = огромное на выходе	Ошибка в справочнике = миллионы в некорректных отчётах
Incomprehensible (непостижимый)	Мы не понимаем, почему так	Сложность систем превышает способность человека их отследить

Это не модный акроним для презентаций. В BANI-мире качество данных — вопрос выживания бизнеса. Не «было бы неплохо», а «без этого ты слепой».

Нелинейность — самое опасное свойство. В FMCG-кейсе ошибка одного продавца — мелочь. Ошибка тысячи продавцов, усиленная через прогнозную модель — катастрофа. Система не деградирует плавно. Она работает нормально, нормально, нормально — а потом ломается вся сразу.

Кейс из банковского мира: когда справочник убивает отчётность

FMCG — чужая территория. Расскажу про свою.

В банковском проекте мы столкнулись с классикой жанра: расхождение справочников между системами. Один и тот же клиент в CRM — «ООО Ромашка», в АБС — «Ромашка ООО», в аналитическом хранилище — два разных клиента. Потому что ETL-процесс матчил по точному совпадению названия.

Масштаб проблемы стал виден, когда бизнес попросил отчёт по кросс-продажам. Сколько клиентов, которые взяли кредит, также имеют расчётный счёт? Ответ по данным: 40%. Ответ по реальности: 65%. Разница — четверть клиентской базы, которую система не смогла склеить.

На основе этих 40% строились прогнозы, планировались маркетинговые кампании, выделялись бюджеты. Крашеная трава. Красивые цифры на дашборде, за которыми — мусор.

Мы починили это через граф-платформу: построили систему, которая матчит сущности не по точному совпадению, а по совокупности признаков — ИНН, адрес, телефон, паттерны транзакций. (Подробнее о том, как мы строили data-intensive платформу в банке.) Но это заняло месяцы. А ущерб от кривых отчётов накапливался годами.

Фреймворк: как не красить траву

Классификация данных и ISO 27000

Первый шаг — понять, какие данные у тебя есть и насколько они критичны. Публичные, внутренние, конфиденциальные, секретные. Звучит бюрократично, но без этого невозможно расставить приоритеты.

ISO 27000 даёт рамку: какие данные храним, кто имеет доступ, что произойдёт при утечке, какие регуляторные требования соблюдаем. Не обязательно сертифицироваться — достаточно использовать как чеклист.

DAMA: десять областей управления данными

DAMA International систематизировала управление данными в десять областей. Не теоретическая конструкция — практический каркас. Вот он в сжатом виде:

Область	Суть	Красный флаг (ты красишь траву, если…)
Data Governance	Роли, ответственности, политики	…политика есть, но никто не знает, кто data owner
Data Architecture	Где какие данные живут	…архитектура нарисована год назад и не обновлялась
Data Security	Защита от несанкционированного доступа	…у всех аналитиков доступ ко всем таблицам «для удобства»
Data Modeling	Концептуальные, логические, физические модели	…модель данных живёт в голове одного человека
Data Storage	Хранение, ретенция, архивирование	…никто не знает, сколько данных хранится и зачем
Master Data	Эталонные данные без дублей	…один клиент живёт в пяти системах как пять разных записей
Data Integration	Потоки между системами	…ETL написан 5 лет назад, автор уволился
Data Quality	Полнота, точность, актуальность	…нет ни одной метрики качества данных
Metadata	Данные о данных, lineage	…поле flag_3 в таблице temp_data_final_v2
DWH и BI	Аналитика и визуализация	…дашборд есть, но никто не верит его цифрам

Ни одна компания не покрывает все десять идеально. Но знать, где ты находишься на каждой шкале — уже половина решения. А если в колонке «красный флаг» ты узнал свою компанию три и более раз — у тебя не проблема с данными. У тебя бомба замедленного действия.

Экспоненциальный рост: почему завтра будет хуже

Объём данных растёт экспоненциально. Каждый год — больше, чем за все предыдущие. Компании генерируют данные быстрее, чем успевают их обработать. Про управление качеством — молчу.

Типичная картина в enterprise: десятки источников данных, каждый со своим форматом. Справочники дублируются между системами и расходятся через месяц после синхронизации. Мастер-данные живут в Excel на рабочем столе менеджера. ETL-процессы написаны пять лет назад и автор давно уволился.

Конкретный пример из банковского контекста: за два года работы над data-платформой объём данных в аналитическом хранилище вырос с 8 до 47 терабайт. Не потому что бизнес вырос в шесть раз — а потому что подключали новые источники, добавляли историчность, хранили промежуточные расчёты. При этом количество людей, отвечающих за качество этих данных, осталось прежним: полтора аналитика и DBA, у которого это было пятой приоритетной задачей. Данные росли экспоненциально, а ресурсы на управление ими — линейно, в лучшем случае.

Проблема не в технологиях. Технологии для управления данными существуют давно. Проблема в организации: нет ответственных, нет политик, нет процессов. Данные — ничьи. А то, что ничьё — то и не нужно никому. Пока не взорвётся.

Чеклист: газон вместо краски

Если после прочтения хочешь проверить, красишь ли ты траву — вот минимум.

1. Ты знаешь, какие данные у тебя есть и кто за них отвечает? Если нет — начни с инвентаризации. Не нужна идеальная каталогизация — нужен хотя бы список критичных источников с именами ответственных.

2. Есть ли у тебя data quality метрики? Полнота, актуальность, консистентность. Если нет — ты не знаешь, насколько можно доверять отчётам. Ты принимаешь решения на вере, а не на данных.

3. Мастер-данные живут в одном месте или в пяти Excel-файлах? Если второе — ты красишь траву. У тебя нет единого источника правды, а значит, у каждого подразделения — своя правда.

4. Кто последний раз проверял ETL-процессы? Если «никто не помнит» — у тебя бомба замедленного действия. ETL, который никто не мониторит, рано или поздно начинает молча терять или искажать данные.

5. Что происходит, когда источник данных падает? Если ответ «узнаём, когда бизнес жалуется на отчёт» — ты реактивен. А в BANI-мире реактивность = потери.

6. Твои аналитики умеют работать с данными руками? Если нет — перечитай мою статью про путь данных. У тебя не аналитики, а рисовальщики дашбордов.

7. Есть ли у тебя data lineage — хотя бы на салфетке? Можешь ли ты за пять минут ответить, откуда берётся цифра в конкретной ячейке отчёта? Через какие системы прошла, какие трансформации пережила, когда обновлялась в последний раз? Если нет — ты не знаешь, чему верить. Я видел ситуацию, когда два отчёта для одного и того же бизнес-заказчика показывали разные цифры по одной метрике — просто потому, что один брал данные из реплики с задержкой в сутки, а другой из оперативной базы. Оба были «правильные». Оба врали.

Не крась траву. Посади газон.

В BANI-мире данные — единственная опора для принятия решений. Если опора гнилая — рухнет всё, что на ней стоит. И рухнет не плавно, а сразу. Потому что BANI.

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

Газон — это скучно. Газон — это data governance, метрики качества, ответственные за данные, мониторинг ETL, master data management. Это не блестит на слайдах. Это не впечатляет на совещании. Но после первого дождя — а он будет — газон стоит. А краска смывается.

---

По мотивам доклада на Analyst Days 14 / Импульс 2022.

Ваш ДПУПП