Как оценить данные в деньгах и не обмануть себя

Любой BI-архитектор рано или поздно ловит этот вопрос. «Сколько стоит то, что вы строите?» Полезно, чтобы ответ был в голове - не пафосный, а с цифрами.

Сложность в том, что данные - не акции. С акцией просто: купил за 100, продал за 120, разница - ценность. С данными даже затраты на получение посчитать непросто.

В DMBOK (2-я редакция) есть целый раздел про это. Авторы предлагают начинать не с одной цифры, а с набора категорий затрат и выгод:

▫️ Затраты на получение и хранение - compute, storage, лицензии, ФОТ команды
▫️ Затраты на восстановление после утери - тест: если завтра потеряете половину DWH, сколько стоит собрать всё обратно?
▫️ Потери из-за отсутствия нужных данных - аналитик не нашёл витрину, написал запрос на сыром слое полдня, менеджмент ждёт. Это деньги.
▫️ Затраты на повышение качества - чистка, data contracts, DQ-чекеры
▫️ И ещё пять категорий: риски, выгоды от качества, цена для конкурентов, стоимость при продаже, доходы от инновационного использования

Главная оговорка: ценность данных зависит от контекста. Одни и те же данные в одной организации стоят миллионы, в другой - ноль.

Ещё один объективный ценник подкинула жизнь - WannaCry в 2017 захватил 100 000 организаций в 150 странах и требовал выкуп за расшифровку файлов. Мрачновато, но это и есть готовность бизнеса платить за свои данные, в рублях за гигабайт.

На моей практике в одном проекте подход был такой:

Задача - обосновать экономику консолидированного слоя витрин (центральный core-слой, снимающий нагрузку с сырого). Мы считали не одну цифру, а три блока:

1️⃣ Высвобожденное время аналитиков
Берём реальное время, которое аналитики тратят на поиск витрин и написание запросов - по логам, без опросов. Переводим в деньги через ставку.

2️⃣ Compute
Интеграл по Cumulative RAM - сколько ресурсов съедают запросы, которые могли бы обслуживаться из core-слоя, а сейчас обслуживаются из сырого.

3️⃣ Storage
Размер дублирующих витрин, которые схлопнутся в одну. С учётом репликации на три ДЦ.
Парадокс - экономия не в сокращении текущего размера, а в подавлении будущего роста.

Но:

▪️ Время аналитиков считается как юнион интервалов, когда кто-то что-то делал - это календарный интервал, а не сумма человеко-часов. Два параллельных поиска по полтора часа в юнионе дадут полтора часа, а в человеко-часах - три. Реальная экономия может быть заметно больше, чем мы показываем.

▪️ Не все оценки равны. Compute и storage - настоящие деньги, счета от ЦОДа. Время аналитиков - предсказанная экономия, её ещё нужно доказать. Если смешать всё в одну цифру, сильные оценки тянутся вниз за счёт слабых. Лучше держать их раздельно: «доказуемо / предсказано».

▪️ Compute экономится не от существования core-слоя, а от того, что в него уходят именно тяжёлые запросы. Если в core уйдут самые лёгкие по RAM и CPU, а тяжёлые останутся в сыром слое - оценка схлопнется. Стратегию имеет смысл заранее нацеливать на тяжёлые паттерны.

▪️ Storage - честнее доказать экономию на будущем росте, чем на текущем размере. «Вот как растёт хранилище, вот как core-слой снизит рост, вот за сколько стоят сервера». Это сильнее, чем «мы схлопнули X дублей».

Вывод

Смысл не в красивой цифре на слайде. Смысл - чтобы сама процедура навешивания ценников на данные вошла в привычку. Без этого вы управляете активом, которому ни разу не смотрели в лицо.

«Навешивание ценников - первый шаг на пути к оценке реального экономического эффекта». Ключевое - «первый шаг», не финальный ответ.

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