что такое ad hoc отчеты
Ad-hoc отчеты в QlikView
Как установить на Ubuntu Apache Superset — VPS Beget
Ad-hoc отчеты в QlikView
Прежде, чем мы рассмотрим создание Ad-hoc отчета, рассмотрим работу функций SubStringCount и GetSelectedCount.
Функция SubStringCount
Синтаксис:
Функция возвращает число раз, которое подстрока встречается в текстовой строке. Результат — целое число. Если совпадения отсутствуют, возвращается 0.
Пример:
SubStringCount ( ‘abcdefgcdxyz’, ‘cd’ ) — возвращает 2
Функция GetSelectedCount
Синтаксис:
Функция возвращает число выбранных значений в поле с именем fieldname. Если для IncludeExcluded установлено true, число будет включать в себя выбранные значения, исключенные выборками в другом поле (т.е. когда в другом поле выбраны элементы измерений, у которых нет ассоциативных связей с нашим измерением).
Примеры:
GetSelectedCount(Customers)
GetSelectedCount(Customers, true)
Создание гибкого отчета “Ad-hoc report”
Код для загрузки данных:
Модель, которая получается после загрузки данных: 
Таблицы [Перечень измерений] и [Перечень метрик] являются Data Island, т.е. таблицами, у которых отсутствуют взаимосвязи с главной таблицей.
Формируем лист “Add-hoc отчет”
Первоначально, нам необходимо создать обычную таблицу типа “Straight table”. На лист документа QlikView добавляем фильтры, с помощью List Box элементов.
Далее добавляем два List Box, в которых будут отображаться поля [Наименование измерения] и [Наименование метрики].
После этого формируем Straight Table, в которой выбираем 3 измерения и формируем 3 формульных выражения (НДС, Продажи, Среднее значение продаж). 
На вкладке Expressions добавляем три выражения:
Label ‘НДС’:
SQL-Ex blog
Новости сайта «Упражнения SQL», статьи и переводы
Что такое ad hoc запрос?
Вот простой пример ad hoc запроса в SQL Server:
SQL Server параметризует этот простой запрос:
Вот пример динамического запроса, который параметризован (подготовлен), поэтому он не является ad hoc:
Однако если параметров нет, запрос останется ad hoc. Вот пример ad hoc запроса, который так же является динамическим:
Чем полезны ad hoc запросы?
Во многих случаях разработчик или DBA может один раз выполнить ad hoc запрос, и больше никогда не использовать его. С другой стороны, один и тот же запрос может выполняться тысячи раз за день из приложения, и при этом, возможно, оставаться ad hoc запросом. В зависимости от запроса может не иметь смысла включать его в хранимую процедуру или параметризовать его.
Ad hoc запросы не являются ни плохими, ни хорошими; как и все остальное, это зависит от того, как они используются. Сошлюсь на интересную статью от Phil Factor, посвященную устранению проблем с некоторыми неэффективными ad hoc операторами.
Что такое ad hoc запрос в базе данных?
Чтобы выяснить, рассматривает ли SQL Server запрос как ad hoc, вы можете проверить тип объекта в кэше плана. Вот запрос из книги «Внутри Microsoft SQL Server 2012» Kalen Delaney и др. Замечу, что вам может потребоваться добавить больше фильтров на [text], если он вернет слишком много строк, чтобы отыскать ваш запрос.
Вы увидите тип объекта Adhoc для ad hoc запроса. Для параметризованных запросов вы также увидите строку с типом объекта Prepared. Вызовы хранимых процедур будут возвращать Proc, и имеется несколько других.
Что такое параметр Optimize for Ad Hoc Workload?
Представим себе систему, на которой каждый из большого числа запросов может выполняться только раз. Чтобы избежать ситуации, когда они занимают место в кэше планов, включите параметр Optimize for Ad Hoc Workload. Тогда при первом выполнении запроса в кэше сохраняется только заглушка плана. Если запрос выполняется снова, SQL Server сохранит весь план.
Заключение
Обратные ссылки
Нет обратных ссылок
Комментарии
Показывать комментарии Как список | Древовидной структурой
Автор не разрешил комментировать эту запись
Как мы автоматизировали выгрузки и другие Ad-hoc задачи аналитика с помощью Zeppelin
На момент написания этой статьи в компании Cardsmobile, которая разрабатывает мобильное приложение «Кошелёк», работает 195 человек: 8 аналитиков и 187 потенциальных заказчиков аналитиков. Мы делаем приложение для конечных пользователей, а также работаем с ритейлом, банками, брендами и другими партнерами. Долгое время работа аналитика в Кошельке состояла не только из исследований поведения пользователя, но и из различных выгрузок, типовых анализов для партнеров и прогнозов для потенциальных клиентов. Конечно, дашборды сильно спасали нам жизнь и позволяли всей компании следить за показателями продукта. Но мы всё ещё тратили время на остальную текучку, и с ростом команды (заказчиков) и бизнеса упёрлись: Ad-hoc задач стало слишком много, а исследования, желание развиваться и светлое будущее простаивали в отсутствие у нас времени.
Так много вокруг классных конференций, интересных статей про различные аналитические исследования, data-science, data-driven, data-счастье. А мы смотрели на всю эту красоту и не знали, где среди всего потока текучки найти время на эксперименты. Многие рассказывают, как сделать классно, но мало кто рассказывает, КАК преодолеть нарастающую текучку и освободить ресурсы для интересных и творческих задач. В этой статье я расскажу про наш опыт выхода в светлое будущее. Дальше будут примеры, как мы автоматизируем Ad-hoc задачи аналитиков в Zeppelin.
Что такое Zeppelin
Zeppelin – это OpenSource Notebook от Apache, который позволяет обращаться к различным БД на разных языках (Python, R, SQL, Spark). Но что делает его особенно кайфовым, так это набор визуальных элементов – dynamic forms.
В одном ноутбуке мы можем извлекать данные по api из Amplitude, быстро считать агрегаты из Clickhouse, дополнять результат данными из MSSQL и обрабатывать все это на Python. А готовые отчеты заворачивать в Excel в удобном заказчику формате и класть в html-ссылку, по которой их можно легко скачать.
Изначально мы начали использовать его просто как notebook, в котором было удобно писать на разных языках. Потом изучили возможности Zeppelin получше, нашли встроенные динамические формы: инбоксы, выпадающие списки и чеклиты – лампочка над головой загорелась! Сразу придумали, сколько всего мы можем автоматизировать. У нас было много типовых задач с готовым кодом, в котором надо было просто менять значения переменных. Мы перенесли весь наш код в Zeppelin, вынесли переменные в динамические формы и дали заказчикам возможность самостоятельно заполнять их и запускать скрипты. Идея понравилась и нам, и всей остальной команде!
Какие динамические формы есть
Input – текстовое поле. Мы используем его, для того чтобы задать временной диапазон для ввода идентификаторов. Другими словами, для всего, вариаций чего бывает много.
Select – выпадающий список. К каждому элементу списка можно прописать сразу готовый кусок кода. Мы предлагаем пользователю выбрать один из нескольких типовых вариантов. Например, одну из метрик для типового отчета.
Checkbox – форма для множественного выбора вариаций. Мы даем его пользователю, чтобы он, к примеру, сам мог выбрать список необходимых полей в выгрузке. Пожалуй, у нас это самый популярный кейс. Или когда мы даем возможность выбрать несколько метрик, сегментов пользователей.
Какие задачи мы автоматизируем в Zeppelin
Выгрузки простые и сложные, с использованием фильтров по дате, партнеру, задавая набор столбцов.
Чаще всего запросы на выгрузки приходят от аккаунт-менеджеров. А еще, с большой вероятностью, они поступают внезапно и срочно. Сами по себе задачи на выгрузку типовые и быстрые в выполнении. Но в действительности они отвлекают от тех самых интересных аналитических исследований, и их число растет по мере роста партнерской сети.
С какими задачами обычно приходят:
Мы создали отчеты для всех частых задач на выгрузки, с которыми к нам обращались. Ускорили процессы наших коллег и высвободили время и внимание для более интересных задач. Теперь только дорабатываем эти отчеты по мере необходимости.
Типовые задачи, в которых надо просто запустить готовый скрипт. Тут тоже применяем фильтры, даём задать значение переменных. Например, пересчет какой-то метрики или отчета, которые используются редко и не хочется ставить их на расписание.
Более изощренный кейс из жизни. Отдел маркетинга совместно с нашими стратегическими партнерами решили провести промо-акцию с определенной механикой. Пользователи нашего приложения должны были совершить цепочку действий, становясь участниками розыгрыша подарков. Раз в неделю мы хотели получать список участников недели, рандомно определять победителей, поздравлять их и отправлять подарки. Аналитик направления создал notebook в Zeppelin, который собирал пользователей, соответствующих условиям участия в розыгрыше за прошедшую календарную неделю. Маркетолог самостоятельно запускал notebook и забирал участников недели.
Подведение итогов А/B-тестов, измерение base-line метрик в тестовой и контрольной группах. Когда мы тестируем новый функционал или триггерную коммуникацию, мы смотрим не только на изменение целевой метрики, но и на то, как в целом меняется поведение пользователя. Мы выделили 4 base-line метрики пользовательского поведения:
Тут Zeppelin дает нам свободу в том, как мы хотим подводить итоги, какие метрики считать, как отрисовывать графики и как объяснять результат тем, кто будет пользоваться этим инструментом.
Собираем базы для коммуникаций и ретаргетинговых кампаний на основе выгружаемой из Amplitude когорты. Когда-то мы отказались от готовых коммуникационных платформ в пользу собственной разработки (возможно, это тема для отдельной статьи, а мы тут не об этом). Наше внутреннее решение было в первую очередь заточено под партнерские рассылки: выбери партнера и отправь сообщение на всю базу. А вот подготовка баз для продуктовых и маркетинговых коммуникаций — то есть собственных коммуникаций Кошелька — легла на плечи аналитиков. Типизировать все запросы от маркетинга и продактов казалось невозможным. Мы все стремились выделить наиболее релевантные сегменты, не ограничивая свои возможности. Например, вымышленный запрос, но запросы аналогичной сложности с нами случались:
Конечно, мы сохраняли код после каждой такой задачи и собирали его в некий монструозный конструктор. Но это все еще было время и внимание аналитика. А ошибка из-за невнимательности могла стоить нам волны негодующих пользователей, которые получили очевидно нерелевантную для них коммуникацию.
И все это так и было, пока один аналитик не обленился достаточно, чтобы не писать код для выборки пользователей в Clickhouse, а собрать когорту в Amplitude и выгрузить ее по api. Что, согласитесь, сильно проще и быстрее. Привычный и уже понятный интерфейс Amplitude, где любой менеджер может самостоятельно собрать когорту со всеми фильтрами из примера выше, проверить ее размер, дополнительно проконтролировать себя и проверить пользователей из когорты, что они попали в нее верно.
Как выглядит механика:
Что происходит в это время:
Я привела пример именно с пуш-рассылками, но у наших коллег быстро возникли идеи, где еще мы можем применять похожий инструмент: любые выгрузки списка пользователей с определенным пользовательским поведением. Сейчас мы используем когорты из Amplitude еще и для запуска ретаргетинговых кампаний. И, думаю, будем использовать и для многих других задач.
Системы мониторинга
Есть еще одна удобная фича, которая правда не относится к динамическим формам и, наверное, не совсем про автоматизацию – запуск по расписанию. Мы используем ее для пересчета дашбордов, запуска разных расчетов. Но самая полезная аналитическая задача, которую мы с ее помощью решаем, это мониторинг. Аномалии в событиях, в поведении метрик, что угодно, за чем должен регулярно следить аналитик, но что тоже хочется автоматизировать. Мы настроили систему алертов в slack и теперь можем вовремя реагировать на изменения, о которых хотим знать:
Success. Победили текучку, освободили время для развития аналитики в компании
Самый приятный абзац этой статьи – наступило светлое будущее! Мы уже автоматизировали большую часть наших Ad-hoc задач. Теперь в спринте их меньше 10%. В освободившееся время мы проводим исследования, выдвигаем и проверяем гипотезы, усложняем наши продукты аналитики и применяем подходы из тех самых статей и выступлений на конференциях. Другими словами, мы наконец занимаемся интересной аналитической работой. А главное, у нас появилось время принимать активное участие в развитии Кошелька.
Совет начинающим автоматизаторам: все частые и типовые куски кода выносите в библиотеки. Это позволит писать быстрее, улучшать качество написания кода всей команды аналитиков и править код в одном месте, а не во всех ноутбуках. И не забывайте, что вы делаете инструмент не для себя, а для своих коллег. А у них разный бэкграунд. Не пугайте их сложными интерфейсами и формулировками, делайте проще и понятнее.
Data-счастье еще впереди, но мы уже сильно воодушевились, ожили и бежим ему навстречу.
Когда пора задуматься о внедерении BI-системы?
В этой статье хочу поделиться личными наблюдениями вот за каким процессом. Как компании проходят путь от пункта «Нам достаточно стандартных отчетов в корпоративной учетной системе » до «Подготовка отчетности требует много времени и ресурсов. Пора все автоматизировать!». Надеюсь, что ниже иложенное поможет кому-то избежать некоторых ошибок и правильно выбрать решение Business Intelligence (BI-платформу).
Стадия первая. Прелюдия.
У руководства компании возникает потребность в регулярной отчетности (продажи, план-факт, финансовое состояние и прочее). Отчетность готовят специалисты соответствующих бизнес-подразделений (финансовый блок, коммерческая служба, логистика и т.д.). В этих подразделениях люди вынуждены совмещать свои основные обязанности (ведение учета, сопровождение договоров и т.п.) и подготовку отчетности. Из инструментов у них типовые отчеты в учетной системе и Excel. Причем с использованием Excel у них обычно не все в порядке.
Стадия вторая. Возбуждение.
Затем у руководителей растут аппетиты (растет компания, растет количество управленцев, приходят руководители с новым взглядом на бизнес и т.д.), и они начинают запрашивать все больше разовых (ad-hoc) отчетов, чтобы взглянуть на бизнес под разными углами. С ростом компании таких отчетов все больше, часть из них переходит в разряд регулярных, и у специалистов от бизнеса возникают проблемы с подготовкой всего этого многообразия в срок. В поисках спасения они начинают требовать от ИТ взять часть работы на себя, а именно, просят различные выгрузки из базы учетной системы (УС) и все чаще обращаются с требованиями разработать в УС новые отчеты.
Стадия третья. Зачатие (Эмбрион).
После всех этих процессов в компании начинает образовываться направление, именуемое бизнесом «аналитики». Так, в компании может появиться SQL-разработчик (с этого я начал путь) и специалист/ты, владеющие Excel и прочими программами из пакета Office. Развитие на этой стадии может проходить по-разному. Я лично видел, что со временем количество аналитиков может стать довольно большим (каждое подразделение обзаводится 1-2 специалистами или же в компании образуется отдельное подразделение). Я, кстати, мог оказаться и в этой роли, но мне повезло, что в университете меня не учили Excel’ю и на первом собеседовании тетенька из отдела HR сказала «ай-ай-ай». Мои уверения её в том, что я быстро (за пару недель) освою сей продукт, скорее всего, породили в ней мысль: «Явно передо мной самоуверенный болван, ибо у нас тут другие тетеньки годами работают на компутере и все еще боятся этого зверя, а этот наглый шкет такое заявляет». Лично мне быстро наскучило создавать разные выгрузки, и я начал интересоваться, а что же есть подходящего на рынке. Но в 2006 году я еще даже не знал термина BI, поэтому поиски были недолгими. Остановился я в результате на технологии OLAP.
Стадия четвертая. Избавление ИТ от ad-hoc или рождение OLAP. Начало проекта BI.
Как мне кажется, OLAP — уже довольно распространенная вещь, и с высокой долей вероятности в компании появляются люди, работавшие с OLAP-кубами как пользователи или разработчики. Они-то и сеят мысль о том, что внедрение кубов станет избавлением от многих проблем и облегчит жизнь большого количества сотрудников. Или же этот человек имел опыт с некой BI-системой. Поскольку сейчас речь скорее не о самых крупных компаниях, то людей, предлагающих что-то из SAP Business Objects, IBM Cognos, Oracle BI перестанут слушать, когда увидят ценник. В крупных же компаниях уже давно что-нибудь да есть, как минимум Microsoft BI (SQL Analysis Services и Reporting Services). «Как минимум» здесь не пренебрежение, просто это довольно распространенные решения, так как поставляются в комплекте в сервером БД, что часто приводит к выбору именно этой платформы.
Поскольку мы все хотим, чтобы наш проект вырос хорошим, добрым, сильным и здоровым, важно не совершить ряд типичных ошибок.
Ошибка первая. Спонтанный выбор системы.
Ошибка вторая. DWH или его отсутствие.
Бывает, что перед внедрением собственно системы подготовки автоматизированной отчетности, никто не озаботился тем, что все-таки было бы неплохо иметь хранилище данных (DWH). В результате, это приводит к тому, что OLAP или отчеты обращаются к большому числу источников данных, различным витринам, которые сформировались на 3-ей стадии. Из этого рождается хаос. Развивать и поддерживать систему после этого становится крайне затруднительно, и может оказаться так, что все придется строить заново.
Выбору системы для DWH тоже нужно уделить отдельное время, но зачастую это та же СУБД, на которой работает учетная система (УС). Такой подход вполне оправдан, так как в компании уже есть специалисты по продукту и может получиться экономия на лицензиях. Конечно, это не относится к случаю, когда в УС копится очень много данных (большое количество транзакций и СУБД выбиралась именно для этого) и лучше поискать другую СУБД, более подходящую для задач аналитики (есть механизмы колоночного хранения, размещение таблиц в оперативной памяти и т.п.).
Еще возможен вариант интеграции учетной системы с неким BI инструментом (видел предложения 1С + QlikView, от некоторых интеграторов), но тут я не совсем в курсе как всё устроено. Буду рад, если кто-то напишет об этом в комментариях или в личку.
Ошибка третья. Игнорирование того факта, что проект уже давно надо было начать.
Часто компании застревают надолго во второй стадии и это приводит к тому, что появляется множество различных витрин данных, кучи Excel-файлов с макросами для обработки данных и, конечно же, никто это никак не систематизирует и не описывает. Начиная в итоге проект BI, вы потратите намного больше времени на систематизацию требований, и придется столкнуться с некоторым сопротивлением со стороны пользователей, которые уже давно привыкли к тому, что есть. Например, они не захотят самостоятельно работать с кубами, потому как Вася из ИТ всегда сам делал им нужные выгрузки, тем самым сильно их избаловав. Все должно быть вовремя!
В общем, будьте готовы к тому, что ответственность за выбор и дальнейшую судьбу проекта будете нести именно Вы — читатели этой статьи, которая, надеюсь, вам хоть как-то поможет.
Зрелость аналитических данных
Что такое отчет и что такое анализ
Отчетность – процесс организации данных в информационные сводки для отслеживания того, как функционируют разные сферы бизнеса.
Анализ – преобразование данных в выводы, на основе которых будут приниматься решения и осуществляться действия с помощью людей, процессов и технологий.
Отчет показывает, что произошло: в четверг в 10:03 на сайте наблюдалось максимальное число посетителей – 63 000 человек. Он дает конкретные цифры.
Анализ показывает, почему это произошло: в 10:01 о компании упомянули в ТВ шоу 60 Minutes, – и рекомендует, что компании следует делать, чтобы оставаться примерно на этом же уровне.
Отчеты ретроспективны, анализ дает рекомендации.
В следующей таблице суммированы отличия между этими понятиями. Теперь должно быть очевидно, почему анализ и управление на основе данных – настолько важный компонент ведения бизнеса. Это факторы, способные дать компании новые направления развития или вывести ее на новый уровень эффективности. 
Гипотетические основные вопросы, на которые отвечает аналитика, по Дэвенпорту. Пункт D представляет собой ценную аналитику, пункты E и F обеспечивают управление на основе данных, если эта информация стимулирует конкретные действия (подробнее об этом ниже). 
В нижнем ряду таблицы отражены действия, приводящие к выводам. Составление отчетов (А) и оповещение (В) – не управление на основе данных: они отмечают, что уже произошло или что необычное или нежелательное происходит сейчас, но при этом не дают объяснений, почему это произошло или происходит, и не дают рекомендаций по улучшению ситуации. Предвестником управления на основе данных служит дальнейшее изучение причинно следственных связей с помощью моделей или экспериментов (D). Только понимая причины произошедшего, можно сформулировать план действий или рекомендации (Е). Пункты E и F обеспечивают управление на основе данных, но только если полученная информация стимулирует конкретные действия.
Пункт С представляет собой опасную зону, поскольку слишком велик соблазн распространить существующий тренд на будущее: в Excel выберите «Диаграмма» (Chart), нажмите «Добавить линию тренда» (Add trendline) – и вот вы уже экстраполировали текущие данные на другие ячейки и делаете необоснованные прогнозы. Даже при обдуманном выборе функциональной формы модели может быть множество причин, почему этот прогноз ошибочен. Для уверенности в прогнозах следует использовать модель учета причинно следственных связей.
Уровни аналитических данных (Зрелость аналитических данных)
В 2009 году Джим Дэвис, старший вице президент и директор по маркетингу SAS Institute, выделил восемь уровней аналитических данных.
Стандартные отчеты
Что произошло? Когда произошло? Например, ежемесячные финансовые отчеты.
Ad hoc отчеты
Как много? Как часто? Например, специальные отчеты.
Детализация по запросу (или интерактивная аналитическая обработка, OLAP)
В чем конкретно проблема? Как найти ответы? Например, исследование данных о типах сотовых телефонов и поведении их пользователей.
Оповещения
Когда нужно действовать? Какие действия нужно предпринять немедленно? Например, загрузка ЦП, о которой говорилось ранее.
Статистический анализ
Почему это происходит? Какие возможности я упускаю? Например, почему все больше клиентов банков перекредитовываются для выплаты ипотеки.
Прогнозирование
Что, если этот тренд продолжится? Какой объем потребуется? Когда он потребуется? Например, компании, работающие в розничной торговле, могут прогнозировать спрос на продукты в зависимости от магазина.
Прогнозное моделирование
Что произойдет дальше? Как это повлияет на бизнес? Например, казино прогнозируют, кто из VIP посетителей будет больше заинтересован в конкретных пакетных предложениях по отдыху.
Оптимизация
Как улучшить наши процессы? Какое решение сложной проблемы будет самым эффективным? Например, каков лучший способ оптимизировать ИТ инфраструктуру с учетом многочисленных конфликтующих ограничений с точки зрения бизнеса и ресурсов?
Представленные идеи формируют график из книги Дэвенпорта и Харриса Competing on Analytics (2006). 
Эти идеи, особенно с большой восходящей стрелой, можно интерпретировать эти уровни как последовательность, своего рода иерархию, где подняться на следующий уровень можно только при условии прохождения предыдущего.
Эту псевдопрогрессию часто называют зрелостью аналитических данных. Если забьете в поисковую строку Google ключевые слова «analytics maturity», то поймете, что я имею в виду. Многочисленные специалисты представляют этот график как набор последовательных шагов для достижения цели, где односторонние стрелки указывают переход на новый уровень.
Аналитическая работа отличается от этого представления: в одно и то же время разные подразделения компании могут проводить анализ разной степени сложности.
Рон Шевлин рационально отмечает:
С точки зрения возможностей нет причин, почему компания не может прогнозировать, например, объем продаж («уровень» 6), не зная, в чем конкретно «проблема» с продажами («уровень» 3)… Но как я, будучи руководителем, должен отвечать на вопрос «Какие действия нужно предпринять немедленно?» без понимания «Что будет, если этот тренд продолжится?» и «Что произойдет дальше?» («уровни» 6 и 7)?
Один из вопросов касался конкурентного положения компании на рынке, и для него были предложены четыре ответа:
Компании, выбравшие первый и четвертый варианты ответов, считались лидерами и аутсайдерами отрасли соответственно. Что интересно, от аутсайдеров компании лидеры отличались следующим:
Несомненно, есть факторы, осложняющие эту методологию. Во первых, так называемая ошибка выжившего. Во вторых, корреляция между успешностью компании и ее размером (насколько известно, выручка компаний, участвовавших в опросе, была в диапазоне от менее 500 млн до более чем 10 млрд долл.). Возможно, только у более крупных и более успешных организаций имелось достаточно ресурсов на создание и обеспечение функций аналитических отделов, способных на разработку моделей для имитационного моделирования цепочки поставок. Тем не менее все пришли к единому мнению, что более качественная и глубокая аналитика повышает ценность бизнеса.
Авторы исследования выделили три уровня аналитических возможностей: желательный, опытный, преобразованный. Их краткие характеристики приведены в таблице.
Таблица «Уровни аналитических возможностей: желательный, опытный, преобразованный» 
От организаций, находящихся на желательном уровне, организации, находящиеся на преобразованном уровне, отличаются тем, что в них:
Конечно, в этом случае также наблюдается сложное взаимодействие между причинами и следствием, но взаимосвязь между конкурентным положением компании на рынке относительно других игроков и уровнем аналитической работы, проводящейся в ней, очевидна.
Так что же тогда мешает компаниям активно применять аналитические инструменты? Два из трех наиболее распространенных ответов на этот вопрос – недостаток понимания, как использовать аналитические данные, и недостаток навыков аналитической работы внутри компании. 
В этих ответах перечислены причины, с которыми может справиться любой специалист аналитик. Например, аналитики могут помочь сотрудникам «прокачать» необходимые навыки, и они сами могут более активно доносить ценность аналитической работы до руководителей. Они могут проводить больше исследований и приводить практические примеры, как другим компаниям удалось справиться с похожими трудностями в бизнесе при помощи аналитики. Руководители специалистов по сбору и обработке данных могут выделить ресурсы на улучшение качества данных, чтобы они ни у кого не вызывали сомнения.
Руководители высшего звена могут стимулировать увеличение обмена данными внутри компании, а также отдельно назначить человека, отвечающего за это направление, например CAO или CDO. В этом процессе каждый играет свою роль.