Билл Фрэнкс - Революция в аналитике. Как в эпоху Big Data улучшить ваш бизнес с помощью операционной аналитики

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

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

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

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

Одна из самых распространенных ошибок, которую я видел в организациях, пытающихся внедрить большие данные в свои аналитические процессы, состоит в подходе к большим данным как совершенно отдельной и самостоятельной проблеме. Многие компании даже создают специальные подразделения, занимающиеся только большими данными {19}. А некоторые доходят вплоть до того, что открывают в Кремниевой долине офисы, призванные заниматься реализацией проектов в области больших данных. Однако такой подход может встретиться с трудностями, поскольку большие данные всего лишь один из аспектов общей корпоративной стратегии управления данными и аналитикой. Необходима единая согласованная стратегия, охватывающая все данные, большие и малые, как это проиллюстрировано на рис. 2.5 и 2.6.

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

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

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

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

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

Если же организация внедрит отдельные системы и процессы для больших данных, не подумав о необходимости интеграции, ей будет гораздо труднее добиться в итоге искомой оптимизации. Компании должны стремиться создать единое аналитическое окружение, которое позволяет его пользователям осуществлять любой тип анализа с использованием любого типа и объема данных в любой момент времени. Далее в книге мы подробнее рассмотрим, как создать такое окружение. Читателям, желающим больше узнать о том, как получить максимальную отдачу от использования больших данных в маркетинге, я рекомендую прочитать книгу моей коллеги Лайзы Артур «Маркетинг на основе больших данных: как эффективнее привлечь потребителей и извлечь ценности» (Big Data Marketing: Engage Your Customers More Effectively and Drive Value) {20}.

Одна из шумно разрекламированных концепций касательно больших данных связана с якобы новым миром, создаваемым набором нереляционных инструментов, которые не опираются на реляционные базы данных и не используют SQL в качестве первичного интерфейса. Аббревиатура SQL расшифровывается как «язык структурированных запросов», и на протяжении многих лет его называли «языком бизнеса». Нереляционнные наборы инструментов не используют SQL эксклюзивно либо вообще его не используют. Приверженцы нереляционного подхода считают, что возникла потребность в дополнительных языках, поскольку SQL во многих компаниях был практически единственным языком бизнеса. В конце концов почему бизнес не может быть многоязычным? Он и должен быть таковым. Более того, он должен был быть таковым с самого начала.