Разработанный десять дет назад современный стек данных не был построен неправильно. Он был создан для решения проблемы, существовавшей в то время, пишет на портале BigDataWire Сохам Мазумдар, соучредитель и генеральный директор WisdomAI.

Недавно я был на встрече с вице-президентом по данным в компании среднего размера, и то, что она сказала, заставило меня задуматься. Мы обсуждали квартальный план ее команды, и она сделала паузу и сказала, почти про себя: «У нас конвейеры обработки данных работают быстрее, чем когда-либо, но почему-то на принятие решений все равно уходит неделя». Она не была расстроена своей командой. Она просто размышляла вслух о том, что не совсем сходилось.

Я часто веду подобные разговоры. Инфраструктура данных улучшилась. Скорость принятия решений — нет. И чем больше времени я провожу на предприятиях, тем очевиднее становится причина. Современный стек никогда не предназначался для поддержки принятия решений. Он был разработан для хранения и перемещения данных, но в какой-то момент все предположили, что остальное уладится само собой.

Этого не произошло.

Та архитектура имела смысл. Пока это не изменилось.

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

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

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

Разрастание SaaS-сервисов усугубило ситуацию

Один операционный директор прямо описал проблему: «У нас 14 систем, каждая из которых имеет немного разное определение дохода. И мои аналитики тратят половину своего времени на то, чтобы выяснить, какой из них можно доверять, прежде чем они смогут ответить на какой-либо вопрос». Это не проблема качества данных. Это проблема архитектуры. Современное предприятие работает с CRM-системами, биллинговыми платформами, конвейерами телеметрии продуктов, системами обработки заявок и бухгалтерскими системами, каждая из которых по-своему определяет одни и те же бизнес-концепции. Инструменты ETL централизовали данные. Но они не решили проблему семантических различий. Они переместили их вниз по потоку, в хранилище данных, где они стали проблемой аналитика.

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

Во сколько на самом деле обходятся медленные решения

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

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

Это не проблема конвейера данных. Это проблема инфраструктуры принятия решений.

Предположение, которое необходимо изменить

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

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

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

Измерение не того, что нужно

Организации, с которыми я работаю, оценивают свою инфраструктуру данных с помощью технических метрик, надежности конвейеров данных, производительности хранилища данных, задержки запросов. Это полезно для инженеров. Но это не те показатели, которые важны для бизнеса.

Для него важно, сколько проходит времени между появлением сигнала и реакцией на него. Именно этот интервал определяет, насколько быстро организация реагирует на проблему клиента, операционный сбой или временное окно, которое не будет открытым долгое время.

Большинство компаний вложили значительные средства в сокращение задержки в конвейерах данных. Очень немногие коснулись задержки принятия решений. Вице-президент, озадаченная тем, почему принятие решений по-прежнему занимает неделю, несмотря на самые быстрые конвейеры данных, которые у нее когда-либо были, получила инструменты, оптимизированные не для того, что нужно. Те, кто это осознал, теперь имеют время что-то с этим сделать. Те, кто будет ждать, потратят следующие несколько лет на строительство более быстрых дорог к той же самой пробке.