Модные словечки, востребованная терминология, не совсем понятные определения и совершенно незнакомые лексические единицы. Все вышеуказанное можно применить как к понятию «business intelligence», так и к словосочетанию «data science». Попробуем не только преодолеть трудности перевода, но и разобраться в том, чем разнятся «наука о данных» и «бизнес интеллект».
Business Intelligence: интеллект, разведка, осмысление, аналитика
Многие уверены, что термин «business intelligence» впервые появился на свет в 80-х гг. прошлого столетия, но это не совсем так. Дело в том, что первым этот термин использовал Ханс Питер Лун, исследователь из компании IBM, в далеком 1958 году. А в 1989-ом Говард Дреснер, который позже стал аналитиком в Gartner, дал определение «business intelligence» как тому, что описывает «концепции и методы для улучшения принятия бизнес-решений с использованием систем на основе бизнес-данных».
Давайте прислушаемся к другим экспертам. Так, Джонатан Ву, менеджер компании Netgear, определяет BI как процесс сбора многоаспектной информации о предмете, который исследуется. А вот какую трактовку предложил Институт хранилищ данных (The Data Warehousing Institute): Business intelligence – это процесс превращения данных в знания, а знаний в бизнес-действия для получения выгоды.
BI можно рассматривать не только как процесс, но и как результат процесса получения знаний. Однако если компилировать все определения, которые «дрейфуют» на рынке, можно утверждать, что business intelligence в самом широком смысле этого понятия – это процесс превращения полученных данных в знания о бизнесе, которые используются для принятия улучшенных решений. Кроме того, это еще и информационные технологии сбора данных и их консолидации. И, наконец, BI представляет собой знания о бизнесе, которые добываются путем проведения углубленного анализа данных. Если говорить коротко, то business intelligence – это технологии, анализ и знания.
Data Science: наука о хаосе, приведенном в порядок
С недавних пор наука о данных рассматривается не только как академическая дисциплина, но и как практическая межотраслевая сфера деятельности. Сам термин был предложен Уильямом Кливлендом, профессором университета Пердью, который считается одним из самых больших авторитетов в области статистики, машинного обучения и визуализации данных.
Согласно определению международного совета CODATA (International Council for Science: Committee on Data for Science and Technology), наука о данных представляет собой дисциплину, которая объединяет различные направления статистики, data mining и машинное обучение. Однако наиболее популярное определение дано в статье «Что такое Data Science?» Майка Лукидиса, редактора O"Reilly Media и автора книг об операционных системах, компьютерной архитектуре и программировании. Стоит отметить, что данная трактовка на сегодняшний день является основополагающей. – это обобщенное название технологий, которые предназначены для производства данных как продукта. Если сравнивать науку о данных с традиционной статистикой, то на первый взгляд может показаться, что между ними нет никаких отличий. Однако Data Science характеризуется комплексным подходом, а data-ученые не изучают данные, а используют их.
Таким образом, мы приходим к выводу, что Data Science изучает проблемы анализа, обработки и использования данных. Это такое фантастическое «ассорти», от которого голова идет кругом: здесь вам и статистика, и интеллектуальный анализ данных, и искусственный интеллект, обрабатывающий большие объемы data, и методы проектирования баз данных, и многое другое.
Ничто не ново под… data-небосводом
Облачные вычисления и другие технические достижения заставили компании сосредоточиться больше на будущем, а не анализировать отчеты на основании данных прошлого. Чтобы получить конкурентные преимущества, компании начали объединять и преобразовывать данные, которые являются частью реальной науки о данных.
В то же время они практикуют Business Intelligence, создавая графики, отчеты и таблицы на базе полученных данных. И хотя между Data Science и Business Intelligence есть большие различия, они в равной степени важны и дополняют друг друга.
Для того чтобы практиковать BI и Data Science, многие компании нанимают специалистов, которые совмещают сразу две должности – BI-аналитиков и дата-сайентистов. Тем не менее, именно здесь и возникает путаница из-за непонимания того, что эти роли требуют различных экспертных знаний.
Несправедливо ожидать, что BI-аналитик может сделать точные бизнес-прогнозы. А это может стать причиной катастрофических последствий для любой компании. Однако, изучив главные различия между BI и наукой о данных, можно научиться подбирать подходящих кандидатов для выполнения определенных задач, которые намерен решить ваш бизнес.
Сфера интересов
С одной стороны, традиционный подход Business Intelligence подразумевает создание инструментальных панелей для отображения исторических данных в соответствии с фиксированным набором ключевых показателей эффективности. Отсюда делаем вывод, что BI больше полагается на отчеты, современные тренды и ключевые показатели эффективности (KPI).
С другой стороны, наука о данных больше фокусируется на предсказании того, что в конечном итоге может случиться в будущем. Таким образом, дата-сайентисты больше сосредоточены на изучении закономерностей и различных моделей, а также на нахождении корреляций для бизнес-прогнозов.
Например, компаниям, занимающимся , нужно предсказывать растущую потребность в новых видах обучения, основываясь на существующих шаблонах и требованиях корпоративных компаний.
Анализ и качество данных
BI требует от аналитиков умения сосредотачиваться не только на настоящем и будущем, но и заглядывать в прошлое – то есть активно использовать исторические данные. Поэтому анализ BI-аналитиков является в большей степени ретроспективным. Фокус Business Intelligence – это абсолютно точные данные, основанные на том, что на самом деле произошло в прошлом.
Например, ежеквартальные результаты компании формируются из реальных данных о ведении бизнеса на протяжении последних трех месяцев. Ошибки в этом случае попросту невозможны, потому что отчетность носит описательный характер и не может быть субъективной.
Что касается науки о данных, то дата-сайентисты должны использовать предиктивную и директивную аналитику. Они обязаны довольно точно предсказывать то, что должно произойти в будущем, используя вероятности и уровни уверенности.
То, как компания будет выполнять необходимые действия на основе предиктивного анализа и прогнозов на будущее, не может базироваться на простых догадках. Конечно, наука о данных не может быть точной на 100%, но она должна быть «достаточно хороша» для бизнеса, чтобы принимать своевременные решения и действия, а также обеспечивать необходимые результаты.
Идеальный пример науки о данных в действии – оценка прибыли компании в следующем квартале.
Источники и преобразование данных
Business Intelligence – это заблаговременное планирование и подготовка к использованию правильной комбинации источников данных для их преобразования. Чтобы получить соответствующие инсайты о клиентах, деловых операциях и продуктах, Data Science в состоянии на лету преобразовывать данные, используя те источники информации, которые доступны по требованию.
Потребность в смягчении
BI-аналитики не должны смягчать любые неопределенности, окружающие исторические данные, так как они основаны на реальных ситуациях. Такие данные точны и не предполагают каких-либо вероятностей.
Главная часть BI-инструментов делится на корпоративные BI-наборы и BI-платформы. Средства генерации запросов и отчетов в большой степени поглощаются и замещаются корпоративными BI-наборами. Многомерные OLAP-механизмы или серверы, а также реляционные OLAP-механизмы являются BI-инструментами и инфраструктурой для BI-платформ.
Большинство BI-инструментов применяются конечными пользователями для доступа, анализа и генерации отчетов по данным, которые чаще всего располагаются в хранилище, витринах данных или оперативных складах данных. Разработчики приложений используют BI-платформы для создания и внедрения BI-приложений, которые не рассматриваются как BI-инструменты. Примером BI-приложения является информационная система руководителя EIS.
Инструменты генерации запросов и отчетов
Генераторы запросов и отчетов - типично «настольные» инструменты, предоставляющие пользователям доступ к базам данных, выполняющие некоторый анализ и формирующие отчеты. Запросы могут быть как незапланированными (ad hoc), так и иметь регламентный характер. Имеются системы генерации отчетов (как правило, серверные), которые поддерживают регламентные запросы и отчеты. Настольные генераторы запросов и отчетов расширены также некоторыми облегченными возможностями OLAP. Развитые инструменты этой категории объединяют в себе возможности пакетной генерации регламентных отчетов и настольных генераторов запросов, рассылки отчетов и их оперативного обновления, образуя так называемую корпоративную отчетность (corporate reporting). В ее арсенал входят сервер отчетов, средства рассылки, публикации отчетов на Web, механизм извещения о событиях или отклонениях (alerts). Характерные представители - Crystal Reports, Cognos Impromptu и Actuate e.Reporting Suite.
OLAP или развитые аналитические инструменты
Инструменты OLAP являются аналитическими инструментами, которые первоначально были основаны на многомерных базах данных (МБД) .МБД - это базы данных, сконструированные специально для поддержки анализа количественных данных с множеством измерений, содержат данные в «чисто» многомерной форме. Большинство приложений включают измерение времени, другие измерения могут касаться географии, организационных единиц, клиентов, продуктов и др. OLAP позволяет организовать измерения в виде иерархии. Данные представлены в виде гиперкубов (кубов) - логических и физических моделей показателей, коллективно использующих измерения, а также иерархии в этих измерениях. Некоторые данные предварительно агрегированы в БД, другие рассчитываются «на лету».
Средства OLAP позволяют исследовать данные по различным измерениям. Пользователи могут выбрать, какие показатели анализировать, какие измерения и как отображать в кросс-таблице, обменять строки и столбцы «pivoting», затем сделать срезы и вырезки («slice&dice»), чтобы сконцентрироваться на определенной комбинации размерностей. Можно изменять детальность данных, двигаясь по уровням с помощью детализации и укрупнения «drill down/ roll up», а также кросс-детализации «drill across» через другие измерения.
Для поддержки МБД используются OLAP-серверы, оптимизированные для многомерного анализа и поставляемые с аналитическими возможностями. Они обеспечивают хорошую производительность, но обычно требуют много времени для загрузки и расширения МБД. Поставляются с возможностью «reach-through», позволяя перейти от агрегатов к деталям в реляционных БД. Классический OLAP-сервер - Hyperion Essbase Server.
Сегодня реляционные СУБД применяются для эмуляции МБД и поддерживают многомерный анализ. OLAP для реляционных БД (ROLAP) имеет преимущество по масштабируемости и гибкости, но проигрывает по производительности многомерному OLAP (MOLAP), хотя существуют методы повышения производительности, наподобие схемы «звезда». Несмотря на то что МБД являются по-прежнему наиболее подходящими для оперативной аналитической обработки, сейчас эту возможность встраивают в реляционные СУБД или расширяют их (например, MS Analysis Services или Oracle OLAP Services - это не то же самое, что ROLAP).
Также существует гибридная оперативная аналитическая обработка данных (HOLAP) для гибридных продуктов, которые могут хранить многомерные данные естественным образом, а также в реляционном представлении. Доступ к МБД осуществляется с помощью API для генерации многомерных запросов, тогда как к реляционным БД доступ производится посредством запросов на SQL. Примером ROLAP-сервера является Microstrategy7i Server.
Настольные OLAP-инструменты (например, BusinessObjects Explorer, Cognos PowerPlay, MS Data Analyzer), встроенные сейчас в EBIS, облегчают конечным пользователям просмотр и манипулирование многомерными данными, которые могут поступать из серверных ресурсов данных ROLAP или MOLAP. Некоторые из этих продуктов имеют возможность загружать кубы, так что они могут работать автономно. Как часть EBIS эти настольные инструменты оснащены возможностями серверной обработки, которые выходят за пределы их традиционных возможностей, но не конкурируют с MOLAP-инструментами. Настольные инструменты по сравнению с MOLAP-средствами имеют небольшую производительность и аналитическую мощь. Нередко обеспечивается интерфейс через Excel, например, MS Eхcel2000/OLAP PTS, BusinessQuery for Excel. Практически все OLAP-инструменты имеют Web-расширения (Business Objects WebIntelligence к примеру), для некоторых они являются базовыми.
Корпоративные BI-наборы
EBIS - естественный путь для предоставления BI-инструментов, которые ранее поставлялись в виде разрозненных продуктов. Эти наборы интегрируются в наборы инструментов генерации запросов, отчетов и OLAP. Корпоративные BI-наборы должны иметь масштабируемость и распространяться не только на внутренних пользователей, но и на ключевых заказчиков, поставщиков и др. Продукты BI-наборов должны помогать администраторам при внедрении и управлении BI без добавления новых ресурсов. Из-за тесного родства Web и корпоративных BI-наборов некоторые поставщики описывают свои BI-наборы как BI-порталы. Эти портальные предложения обеспечивают подмножество возможностей EBIS с помощью Web-браузера, однако поставщики постоянно увеличивают их функциональность, приближая ее к возможностям инструментов для «толстых» клиентов. Типичные EBIS поставляют Business Objects и Cognos.
BI-платформы
BI-платформы предлагают наборы инструментов для создания, внедрения, поддержки и сопровождения BI-приложений. Имеются насыщенные данными приложения с «заказными» интерфейсами конечного пользователя, организованные вокруг специфических бизнес-проблем, с целевым анализом и моделями. BI-платформы, хотя и не так быстро растут и широко используются как EBIS, являются важным сегментом благодаря ожидаемому и уже происходящему росту BI-приложений. Стараниями поставщиков реляционных СУБД, создающих OLAP-расширения своих СУБД, многие поставщики платформ, которые предоставили многомерные СУБД для OLAP, чтобы выжить были вынуждены мигрировать в область BI-приложений. Семейства продуктов СУБД, обеспечивающие возможности BI, действительно подталкивают рост рынка BI-платформ. Отчасти это происходит благодаря большей активности ряда поставщиков СУБД.
Рассматривая различные инструменты, видим, что EBIS являются высоко функциональными средствами, но они не имеют такого большого значения, как BI-платформы или заказные BI-приложения. Зато BI-платформы обычно не так функционально полны, как корпоративные BI-наборы. При выборе BI-платформ нужно учитывать следующие характеристики: модульность, распределенную архитектуру, поддержку стандартов XML, OLE DB for OLAP, LDAP, CORBA, COM/DCOM и обеспечение работы в Web. Они должны также обеспечивать функциональность, специфическую для бизнес-интеллекта, а именно: доступ к БД (SQL), манипулирование многомерными данными, функции моделирования, статистический анализ и деловую графику. Эту категорию продуктов представляют фирмы Microsoft, SAS Institute, Oracle, SAP и другие.
BI-приложения
В приложения бизнес-интеллекта часто встроены BI-инструменты (OLAP, генераторы запросов и отчетов, средства моделирования, статистического анализа, визуализации и data mining). Многие BI-приложения извлекают данные из ERP-приложений. BI-приложения обычно ориентированы на конкретную функцию организации или задачу, такие как анализ и прогноз продаж, финансовое бюджетирование, прогнозирование, анализ рисков, анализ тенденций, «churn analysis» в телекоммуникациях и т.п. Они могут применяться и более широко как в случае приложений управления эффективностью предприятия (enterprise perfomance management) или системы сбалансированных показателей (balanced scorecard).
Разведка данных
Разведка данных (data mining) представляет собой процесс обнаружения корреляции, тенденций, шаблонов, связей и категорий. Она выполняется путем тщательного исследования данных с использованием технологий распознавания шаблонов, а также статистических и математических методов. При разведке данных многократно выполняются различные операции и преобразования над сырыми данными (отбор признаков, стратификация, кластеризация, визуализация и регрессия), которые предназначены:
1) для нахождения представлений, которые являются интуитивно понятными для людей, которые, в свою очередь, лучше понимают бизнес-процессы, лежащие в основе их деятельности;
2) для нахождения моделей, которые могут предсказать результат или значение определенных ситуаций, используя исторические или субъективные данные.
В отличие от использования OLAP разведка данных в значительно меньшей степени направляется пользователем, вместо этого полагается на специализированные алгоритмы, которые устанавливают соотношение информации и помогают распознать важные (и ранее неизвестные) тенденции, свободные от предвзятости и предположений пользователя.
Другие методы и средства BI
Кроме перечисленных инструментов, в состав BI могут входить следующие средства анализа: пакеты статистического анализа и анализ временных рядов и оценки рисков; средства моделирования; пакеты для нейронных сетей; средства нечеткой логики и экспертные системы. Дополнительно нужно отметить средства для графического оформления результатов: средства деловой и научно-технической графики; «приборные доски», средства аналитической картографии и топологических карт; средства визуализации многомерных данных.
Что такое BI-система, и как она работает
Чтобы построить высотку, директор строительной компании должен знать о проекте все до последнего шурупа: количество этажей, объем необходимых материалов, проверенный макет здания. А еще нужно адаптироваться к сокращающимся графикам постройки, позаботиться о сдаче площадей, уладить множество вопросов с государственными органами.
Этап №2. Организация данных
Тут тоже можно пойти двумя путями: от общих бизнес-требований или от нужд каждого подразделения. В первом случае нужно сначала проанализировать все бизнес-требования, затем проработать нужды каждого департамента. Второй подход итеративный – мы разбиваем весь объем работ на отдельные области, и в деталях описываем, как будут выглядеть аналитика и отчеты для отдела маркетинга, затем для финансов, HR и дальше идем итерациями по всем отделам.
Если хотите быстрее получить результат в виде первых отчетов, то второй вариант подойдет больше – при работе итерациями, пока следующая модель проектируется, первая уже работает. При общем подходе вы быстрее получите конечный результат, то есть общую аналитику по всем отделам.
Этап №3. Выбор стека технологий
Тема безграничная. Кратко опишем, что важно сделать на этом этапе: определить источники данных и уточнить, есть ли в них необходимая информация и показатели. Очень часто приходится дорабатывать учетные системы, чтобы показатели заводились. Когда пул источников собран, можно переходить к учетным системам, веб-ресурсам и внутренним системам компании, чтобы покомпонентно спроектировать архитектуру и прописать роль источников для трансформации данных. Любые сведения в BI-систему поступают в сыром виде, и на этом этапе только от нас зависит, насколько точные и удобные для восприятия данные менеджеры получат на выходе.
Этап №4. Проектирование интерфейсов
Сотрудники, которые пользуются системой, ценят удобный и приятный глазу интерфейс возможно так же глубоко, как и возможности, которые решение дает. Поэтому на проектах часто вводится этап прототипирования, когда мы отрисовываем формы интерфейса. Причем, если внедряем систему SAP, то UX и UI стараемся делать в интерфейсе этой системы, если Qlik, то рисуем в интерфейсе этой платформы. Благодаря такому этапу клиент понимает, какие графики лучше использовать для визуализации тех или иных показателей, какие цвета подобрать, как удобнее расположить фильтр и т.д. После этапа трансформации данных этот прототип достаточно будет наполнить. В остальном он полностью соответствует ожиданиям бизнес-пользователей.
Этап №5. Тестирование системы
Если вы меняете существующую BI-систему, то убедить пользователей в точности данных и дополнительно проконтролировать расчеты, будет несложно. Нужно взять отчет из одной системы бизнес-аналитики, взять разработанный ответ в новой, и, если все цифры совпадают, то программой можно пользоваться - данные верные. Сложнее, когда разрабатываются новые отчеты или внедряется первая система бизнес-анализа, потому что сравнивать данные не с чем.
В этом случае нужно разработать сценарии тестирования. Возьмите выгрузки по одному из направлений за заданный период и точность сведений на этом же срезе данных из той же учетной системы. Например, вы взяли из системы отчет по остаткам с 1 по 15 февраля, и он был равен 1000 единиц. На этом же срезе данных в учетной системе остаток тоже 1000 единиц. Значит, системе можно верить – данные корректные. По-другому найти эту точку сходимости, на мой взгляд, невозможно.
Отдельная тема – внедрение системы на динамически меняющийся источник данных, или когда мы внедряем решение на данных Excel, но этап загрузки данных необходимо перенести на вновь внедренный источник, в котором могло поменяться все от структуры хранилища до самих сведений. Здесь внедрение и тестирование будет идти по иным правилам.
Этап №6. Обучение команды
На проектах мы стараемся обеспечить максимальный результат от использования системы. Для этого проводим обучение финансистов, маркетологов, IT-специалистов и управленцев: знакомим с платформой, возможностями доработки и управления нашим решением, учим менеджеров максимально использовать все возможности программы. В помощь администраторам и пользователям разрабатывается сопроводительная документация: классические «Руководство администратора» и «Руководство пользователя», а часто и обучающие видеоролики. Самый детальный и сложный, но полезный материал – тот, что обычно называется «Техпроект» или «Спецификация отчетов». Он описывает весь процесс движения данных от источников до конечных отчетных форм. Не пренебрегайте этим документом. С его помощью любой новичок в команде сможет разобраться, как данные попадают в первый слой загрузки, и где они находятся в выходных отчетных формах. С помощью этого материала любое изменение или просьба по доработке системы займут минимальное количество времени.
Частые ошибки при внедрении
Как мы уже говорили, популярная ошибка при построении дерева решений - это движение от потребностей низших уровней к верхним. Но есть еще несколько критичных моментов, на которых чаще всего «прокалываются» неопытные внедренцы.
- Не разбираться в типах платформ. Существуют системы класса in-memory, которым не нужны системные хранилища данных; и платформы, которые требуют двухкомпонентную архитектуру, то есть отдельное хранилище и отдельный BI-инструмент для визуализации.
- Работать крупными мазками. Этапы загрузки, трансформации и последующей загрузки данных в приложение всегда стоит максимально детализировать и разбивать на более короткие отрезки. Многие в одном скрипте загружают, трансформируют данные, и делают последующую выгрузку. С гигантскими кусками кода не справится ни подрядчик, ни клиент. Но если код разбит на маленькие кусочки, определить, что вышло из строя, будет легко. Это сэкономит время и деньги на последующую поддержку.
- Сразу автоматизировать . Нельзя сразу отдавать в разработку отчеты от бизнес-пользователей. Возможно, они не видели других, более удобных форматов. Может быть, раньше они сталкивались с техническими ограничениями и не могли представить анализ по-другому. Простая разработка не решает задач бизнеса – нужно глубже погружаться в отрасль и процессы в компании, выяснять, в чем заключаются проблемы и целенаправленно с ними работать.
Сколько это стоит и от чего зависит
Стоимость готовой системы начинается с маленьких проектов до миллиона рублей и заканчиваются крупными внедрениями под сотню миллионов. Цифры привязаны к объемам работ - количеству отделов и количеству необходимых отчетов. Случается, что клиент хочет очень компактный по времени проект. Такая срочность тоже повлияет на общую стоимость, потому что увеличит затраты на команду и оптимизацию ресурсов.
Чем помогут консультанты
Часто консультанты самостоятельно выполняют весь объем работ и минимально привлекают сотрудников клиента. Но случается, что объем работ собственных сотрудников соизмерим с объемом работ интегратора. В зависимости от задач и финансовых возможностей клиента, компания-консультант может участвовать в проекте в нескольких форматах.
Платформа не справляется с задачей. Неоправданно долгая загрузка, технические ограничения на ввод данных, инструменты визуализации не позволяют давать нужный результат – такие сложности решаются с помощью аудита систем. Консультант знает, как подобные проблемы решаются в других компаниях, много работал с разными платформами. Он разберется в корне проблем и предложит наиболее удачное решение.
Недостаток ресурсов. Чтобы проворно систематизировать требования и не менее стремительно построить на их основе систему, могут потребоваться дополнительные ресурсы, поскольку новые запросы появляются постоянно. Часто для анализа в компании используют один инструмент, для финансовой аналитики – другой, а маркетинговую эффективность считает третий. Целый штат IT-специалистов содержать бессмысленно и неэкономно. Здесь поможет подрядчик, который уже вырастил квалифицированные кадры и умеет оптимизировать затраты на подобные задачи.
Новая задача. Если внедрением IT-решений раньше вы не занимались и не очень четко понимаете, с какого конца начать, стоит хотя бы проконсультироваться со специалистом. Риск потери возможной прибыли и времени абсолютно точно окупит затраты на эту консультацию.
Выводы
Создать любую информационную систему непросто. Проектирование аналитических решений затрудняется капризным и сложным в работе элементом – данными. Команда с опытом решит эту задачу быстрее и без приключений. Независимо от того, предпочитаете ли вы одиночные спуски по порогам Амазонки или контролируемые инструктором, уделите наибольшее внимание действиям с данными. Тогда технические и методологические сложности будут представлять меньшую угрозу, а будущая система сможет решать сложные аналитические задачи без ошибок.
BI-разработчик – это уникальная профессия, которая включает себя множество интересных видов деятельности. BI - расшифровывается как Business Intelligence - лучше не пытаться перевести это дословно. Если кратко, Business Intelligence - это предоставление необходимой для бизнеса информации в удобном и понятном виде, - что позволяет получить ответ на бизнес-вопрос или принять правильное стратегическое решение.
Данная профессия подразумевает, что вам придется одновременно погружаться в бизнес-процессы различных департаментов: финансы, риски, маркетинг, логистику, закупки и информационные технологии. Например, если вы будете работать в банке, то прежде всего необходимо понимать финансы, если в ритейле, то нужно понимать, как работает торговая индустрия. Но в требованиях к вакансии это - «дополнительные знания», если вы чего-то не знаете, всегда можно спросить коллег из соответствующего бизнес-подразделения. В любом случае, вам очень понадобятся коммуникативные навыки - чтобы сделать простой отчет, например, по продажам, вам будет необходимо выяснять множество подробностей. «Какой период учитывать, сумма с налогом или без, в каком виде нужен отчет, как часто нужна данная информация» и т.п.
Что касается технологий для BI, то существует много разных решений, которые можно разделить на три крупных блока:
1. Решения для хранения данных
2. Решения для трансформации и загрузки данных
3. Решения для создания отчетности и визуализации данных
Само собой, для BI-разработчика главным инструментом является аналитическое приложение. На рынке существует множество решений, каждое из которых имеет свои недостатки и преимущества, но в целом все они базируются на одной концепции семантического слоя, такой слой трансформирует всю «техническую информацию» в бизнес объекты, с которыми пользователю удобно работать. Другими словами, аналитическое решение облегчает работу бизнеса по получению необходимых данных для ответа на бизнес-вопросы. Также аналитическое решение позволяет автоматизировать корпоративную отчетность, управлять безопасностью и создавать на лету отчеты в интуитивно понятном интерфейсе.
Так как BI-разработчик постоянно работает с данными, а данные хранятся, как правило, в реляционных базах данных, то необходимо знать язык SQL для управления данными, ознакомиться с понятием корпоративного хранилища данных, моделями данных, ETL, OLAP и многим другим. С этими знаниями можно расти от-BI разработчика до BI-архитектора.
Также можно развиваться в сторону предиктивной аналитики (predictive analytics) или больших данных (Big Data), так как классических методов уже не хватает для принятия правильных решений, и поэтому бизнесу необходимо правильно прогнозировать свои процессы, обрабатывая при это огромные массивы данных.
Если вы не боитесь трудностей и хотите решать крутые бизнес-задачи с помощью информационных технологий, то добро пожаловать в Business Intelligence!
P.S. Уровень зарплат (для Москвы)
Junior BI Developer (знание SQL и одного инструмента BI) - 70000 рублей.
BI Developer (понимание концепции хранилища данных и ETL) - 90000 рублей.
BI Developer с опытом работы 1-2 года - 120000 рублей.
Senior BI developer (опыт работы 3 года) - 150000 рублей.
BI Architect - 165000-200000 рублей.
Ролик об основах Business Intelligence, сделанный для компании Lamoda и посвященный BI в ритейле
Существует огромное количество терминов: аналитика, data mining, анализ данных, business intelligence и разница между ними не всегда столь очевидна даже для людей, которые с этим связаны. Сегодня мы расскажем о том, что же такое Business Intelligence (BI) доступным и понятным языком. Тема безусловна огромна и её не покрыть лишь одной короткой статьей, но наша задача - помочь сделать первый шаг и заинтересовать читателя темой. Заинтересованный же читатель также найдет исчерпывающий список для дальнейших шагов.
Структура статьи
Зачем всё это нужно: из жизни аналитика
(кликабельно)Представим, нами (неким аналитиком Петровичем у поставщика Цветочек) стоит задача оценить продажи ряда магазинов (куда мы поставляем товар) и каждый магазин ведет свой учет проданных товаров. Реальность такова, что формы учета будут заполнены не пойми как и не пойми кем, то есть у них будет разная структура и разный формат хранения (некоторая форма таблиц). Схематично эта задача изображена на схеме выше.
Казалось бы задача несложная и поэтому рассмотрим лобовое решение: пусть у нас есть N таблиц и нам нужно их собрать вместе в одну таблицу, тогда напишем N скриптов, которые преобразуют эти таблицы и один сборщик, который собирает их вместе.
Минусы такого подхода:
- необходимо поддерживать N скриптов одновременно (где N в порядках тысяч);
- при изменении структуры отчетов магазинов во времени (например, в магазине появился новый сотрудник) необходимо искать и переписывать отдельные скрипты;
- при появлении нового магазина, необходимо писать новый скрипт;
- при изменении нашей отчетности (поставщика Цветочек), необходимо вносить изменения во все скрипты;
- сложная отладка и поддержка, так как магазины не уведомляют об изменении структуры и не следуют никаким спецификациям.
Если мы поднимемся на уровень целой организации, то увидим, что проблем даже больше.
В чем задача: проблема на уровне компании
(кликабельно)
Производитель Цветочек на самом деле работает не напрямую с магазинами, а через некоторых посредников. Посредники посещают магазины и непосредственно своими действиями пытаются стимулировать продажи. Соответственно, они являются материально заинтересованными лицами и информацию, которую они выдают, приходится перепроверять.
Принципиально, задача выглядит схожим образом: пусть у нас есть N магазинов и K дистрибьюторов, можем ли агрегировать данные магазинов и сравнить их с результатами дистрибьюторов? (У всех данные имеют разную структуру и формат.)
Здесь помимо таблиц, мы уже можем столкнуться с целым зоопарком форматов, к которым добавляются отчеты дистрибьюторов. Как правило задача характеризуется очень низким качеством данных, в том числе дублированием, несогласованностью и ошибками. На основе полученных результатов и сравнения данных, отдел по закупкам принимает решения о том сколько, кому и почем чего отгружать. То есть решение этой задачи непосредственно влияет на финансовые показатели компании, что безусловно важно.
Рассмотрим несколько вариантов решения на уровне компании:
- самописное решение: компании производителю будет необходимо нанять специалиста не по профилю компании и критичное ПО будет зависеть от данного специалиста. Если он уйдет, то компания будет вынуждена срочно искать замену, которая сможет поддерживать ПО и качество будет напрямую зависеть от нанятого специалиста;
- закупить ПО у третьей стороны, тут три ключевых фактора: цена, качество и время интеграции. Как правило цена и время интеграции слишком высоки для среднего производителя, и в том числе требует существенных временных затрат сотрудников. Выбор поставщика также не тривиален;
- SaaS решения: методология еще нова для рынка и многие компании скептически относятся к подобным сервисам.
В целом если мы говорим о небольшом или среднем производителе, то с точки зрения времени интеграции, цены и качества решения сервис выглядит оптимальным вариантом, так как ценообразование динамическое и интеграция минимальна через веб. Как правило плюсом корпоративного ПО является настраиваемость и касмтомизированность (каждый бизнес считает себя уникальным), но описанная задача достаточно типична и стандартна для достаточно широкого круга компаний. Безусловно, нет единого решения для всех, но для каждого в отдельности его можно найти.
Сам процесс на уровне компании выглядит схожим образом: консолидируется данные, определенным образом трансформируются (агрегируются) и загружаются в систему для анализа.
(кликабельно)
Обобщаем задачу: всё это звенья одной цепи
(кликабельно)
В чём же разница между аналитикой, data mining и business intelligence (BI)? Первые включают в себя комплекс методов для анализа уже чистых данных, а на практике очистка и преобразование данных в удобный для анализа формат - важный и неотъемлемый процесс. Так же помимо работы с преобразованием и консолидацией данных, основная задача BI - это принятие решений для бизнеса.