Жизненно Опасные Проекты Аналитики

Работая с такой BI-системой как Qlik, постоянно испытываешь соблазн начать применять ее «творчески». А почему бы и нет? Данные скриптом загрузки можно трансформировать как угодно. Можно обеспечить запись данных обратно в базу. Это же значит, что можно создавать любые продукты на основе данных! И все на стандартном функционале (почти).

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

Проекты со сложным write-back

Проект подразумевает сложный и объемный сценарий ввода данных. Не просто крутить несколько параметров, а выполнять многострочный ввод с разными сценариями. Т.е. пользователь хочет не только видеть данные в аналитике, но и менять их на ходу, и задействовать в сложных вычислениях. Примеры: ценообразование, автозаказы.

• В чем опасность: Изменение требований на ходу. Если это разработка для только зарождающего бизнес процесса, то вы можете получить требования, которые приведут к необходимости переделки уже разработанной логики. Черный ящик для пользователя — важные элементы логики могут быть недоступны для самостоятельного изменения пользователем. Замедленная реакция на ввод данных — для вычисления по внесенным данным может потребоваться перезагрузка скрипта, этот процесс может быть не моментальным.
• Что делать: проверить, существуют ли готовые продукты, решающие данную задачу. Предложить клиенту подготовить специалистов разработки Qlik на его стороне, чтобы они самостоятельно вели такие проекты в рабочем порядке. Либо обеспечить пользователям выгрузку базовых данных, чтобы они самостоятельно реализовывали свои механики в подручном Excel. Такие проекты могут быть неплохим подспорьем для прототипирования механик, но всегда нужно мониторить готовые специализированные решения, которые уже учли грабли, по которым вам только предстоит пройти.

Генерация данных для базовой фин. отчетности

Если по какой-то причине возникает идея высчитывать показатель типа валовой прибыли (FIFO, LIFO) на стороне аналитики, лучше отказаться. Конечно, в случаях когда это вычисления на уровне Выручка минус Себестоимость, проблем никаких нет.

• В чем опасность: Логика расчета таких показателей может быть плохо совместима с методами обработки данных в BI (например в транзакционных системах эти данные расчитываются для каждой операции в момент ее ввода, а в BI для этого придется буквально моделировать последовательность операций и состояние данных после каждой операции). Бонус: однажды клиент сделает расчет этого показателя на своей стороне, и он не сойдется с вашим 🙂
• Что делать: предложить клиенту доработать систему учета, чтобы забирать готовый показатель из источника.

Пилотный проект без инноваций

Часто в рамках пилота просят реализовать часть существующей отчетности в BI. Но по факту пилот будет успешен только в случае, если компания получит новые возможности, недоступные ей ранее (и очень желательно, чтобы эти возможности было нельзя воспроизвести старыми инструментами). Например: рост эффективности из-за более оперативной отчетности (раньше мониторили раз в месяц, стали мониторить раз в неделю/в день, потому что процесс подготовки данных не отнимает время). Или новые подходы к процессам благодаря сложно считаемым аналитическим признакам, которые есть в BI и которые нельзя вывести в текущих инструментах.

• В чем опасность: вы дадите пользователям инструмент, который делает то же что и сейчас, но надо переучиваться. Потом, они введут свой эксель 5 новых колонок, и ваше решение потеряет актуальность.
• Что делать: всегда на этапе пилота прорабатывать вопрос, что нового сможет делать компания чего не может делать сейчас но очень хочет. Старые формы отчетности можно будет подтянуть позже, после пилота, когда BI завоюет авторитет как полезный инструмент.

Сквозная аналитика интернет-рекламы

Оценка окупаемости рекламы — очень популярный сценарий анализа. Часто у заказчика возникает мысль: зачем пользоваться сторонними сервисами сквозной аналитики, когда можно тянуть данные из Google-аналитики и Яндекс.Метрики, расходы из рекламных систем, и создать свое решение, без абонентской платы, с единоразовой оплатой за проект (ха-ха). Что может пойти не так?

• В чем опасность: в этом сценарии анализа есть два критических аспекта, которые не решит BI. Это сбор данных, и разметка трафика. Сюрприз, но данные, собираемые в GA и ЯМ обычно очень далеки от реальности. Сервисы сквозной аналитики используют собственные счетчики, поэтому у них с этим вопросом дела обстоят лучше. Дальше, если вы не уделяли внимание правильной разметке трафика (UTM-метки и т.д.), то на любой платформе ваша аналитика превратится в тыкву. Это не говоря про сценарии мультиканальной аналитики, онлайн-управлением объявлениями и прочих поведенческих отчетов, которые вы в BI не воспроизведете.
• Что делать: используйте специализированные сервисы и инструменты для решения этой задачи. Если очень нужно, выгружайте в BI готовые данные из этих систем для визуализации основных моментов. Смиритесь с фактом, что вы не будете вести глубокую web-аналитику в BI общего назначения (например, OWOX BI изначально заточен под эти сценарии).