• - несмотря на то, что компании "плавают" в океане данных, большинство из них не может их применить
  • - чаще всего решения принимаются интуитивно, при этом измеряются отнюдь не самые важные метрики, еще и неправильно
  • - самый частый аналитический инструмент - обычная экселевская табличка с устаревшими или некачественными данными
  • - решения принимаются в условиях ограниченных ресурсов, причем самый ценный ресурс - время
  • - BI - процесс сбора и анализа любой информации, помогающей принятию бизнес-решений
  • - вкратце: технологии и инструменты для поддержания процесса принятия решений
  • - нет какого-то общего технологического ядра, процесс постоянно эволюционирует и отличается от компании к компании
  • - основная функция BI - создание своевременной, точной, ценной и полезной для немедленных действий информации
  • - синонимами BI в прошлом часто были DSS (Decision Support System), EIS (Executive Information System), MIS (Marketing Information System)
  • - причина появления разнообразных подобных синонимов - желание поставщиков решений "огородить" себе участок, выделить себя среди конкурентов, хотя по сути все занимаются одним и тем же
  • - самым ярким определением цели запуска BI-проекта будет insight, озарение - процесс появления реально ценных идей по итогам анализа данных, той информации, которая раньше была недоступна или казалась не важной
  • - в целом, расшифровка BI не как Business Intelligence, а как Business Insights лучше определяет суть вопроса
  • - чтобы можно было считать BI успешным, он должен удовлетворять всем 4-м следующим принципам:
  • - 1. точные ответы - адекватное отражение объективной реальность
  • - GIGO - Garbage In, Garbage Out - если BI дает неточную информацию, ее ценность отрицательная
  • - чтобы BI реально использовался, ее потенциальные пользователи должны ей верить
  • - что интересно, некорректные данные на выходе BI-отделов - одна из самых частых проблем на практике
  • - стоит учитывать, что часто BI дает необычную, контринтуитивную, иногда даже пугающую информацию, поэтому ей приходится всеми силами доказывать ее валидность
  • - может быть давление со стороны менеджмента в сторону сокрытия или искажения неудобных для них выводов
  • - если менеджменту не нравятся выводы системы, он будет использовать любые, даже самые мелкие неточности в предоставляемых данных, чтобы подвергнуть сомнению саму необходимость существования системы
  • - то есть одной из основных целей создателей BI-системы является даже не сколько предоставление точной информации, сколько убеждение скептиков в том, что именно эта информация является корректной
  • - даже маленькая ошибка может разрушить будущее доверие к системе
  • - 2. ценная информация - дающая ощутимую прибыль или экономию
  • - даже самые точные выводы бессмысленны, если их невозможно применить на практике, либо если их применение дает незначительный эффект
  • - часто самые лучшие озарения контринтуитивны, но чрезвычайно эффективны экономически
  • - очевидные факты и взаимоотношения не требуют BI-системы, достаточно просто умных и наблюдательных людей в компании, прорыв от ее использования чаще всего будет именно в неочевидных вещах
  • - 3. своевременность - предоставление информации именно тогда, когда она ценнее всего
  • - каждый шаг на пути сбора и анализа информации требует времени, стоит стараться добиться такой скорости, чтобы информация на выходе не теряла своей ценности
  • - лучшие BI-системы - реалтаймовые
  • - 4. actionable-выводы - информация, которую можно немедленно применить на практике
  • - частой проблемой оказывается проблема "сов-теоретиков", когда выводы системы вроде и правильные, но нереалистичные, не учитывают реального положения дел в компании и на рынке
  • - чем короче путь от вывода до конкретного действия - тем лучше
  • - в идеале на выходе системы должен быть конкретный пошаговый план, состоящий из простых и реальных действий
  • - BI связывает информацию и действия
  • - основная ценность BI - не в том, что она дает какую-то новую информацию, а в том, что она приучает принимать осознанные решения, основанные на конкретных фактах и их анализе
  • - цикл работы BI системы можно представить как:
  • - 1. сбор данных
  • - 2. принятие решений на основе анализа данных и конкретные немедленные действия
  • - 3. оценка эффективность принятых решений и выполненных действий на основании предопределенных метрик
  • - 4. учет полученных уроков на следующей итерации
  • - при непрерывной работе в этом цикле организация в целом привыкает к подобному стилю, что благотворно отражается на качестве ее работы в целом
  • - за всем этими пунктами не стоит забывать о главном - конкретных, измеримых и значимых финансовых результатах
  • - результаты оценки эффективности каждого цикла расширяют информационную базу, на которую опираются следующие итерации, что в итоге ощутимо повышает качество принимаемых решений
  • - можно начинать с малого, с какого-нибудь небольшого отдела и постепенно расширять его влияние на работу организации в целом
  • - современное BI стало возможным благодаря развитию технологий, но в целом его принципы не изменились с тех пор, когда технологий еще не было
  • - BI, по факту, уже тысячи лет, еще со времен каменных табличек с учетом хранения зерна в сараях
  • - транзакционные базы хороши для POS-систем, но для анализа данных подобная организация информации не подходит
  • - изначально BI был игрушкой айти-департаментов, лишь со временем менеджмент понял его настоящую ценность и он получил управление сверху
  • - процесс занесения данных в общий DW в современных системах может быть излишним - можно "натравить" умную систему на любой существующий источник, чтобы она самостоятельно высосала и подготовила данные для анализа
  • - BI требует не только технической инфраструктуры, но и соответствующей корпоративной культуры и мотивации
  • - сама по себе установка и настройка системы проблем не решит, нужны еще те самые менеджеры, которые бы использовали предоставляемую системой информацию в своей ежедневной работе
  • - для успешного внедрения системы менеджеры должны быть готовы работать в рациональном, основанном на измеримых результатах, режиме
  • - менеджеры должны быть готовы не только использовать то, что предоставляется системой, но и задавать правильные вопросы, ведущие к ее развитию
  • - BI - нечто среднее между наукой и искусством, поскольку требуется найти баланс между живыми людьми с их проблемами и задачами и "сухими" технологиями
  • - нет какой-то общепринятой формулы или готового рецепта разработки и внедрения подобных систем, для определения необходимых и полезных отчетов или аналитики
  • - нет ни одной книги, которая бы описывала все возможные сценарии и рецепты использования подобных систем
  • - BI опирается в первую очередь на корпоративную культуру принятия осознанных решений и работу на измеримый результат, для ее успеха этот процесс должен поддерживаться во всех сферах деятельности компании
  • - будет ли прибыльным внедрение системы в той или иной компании - большой вопрос, но вот переход от интуитивного принятия решений к основанному на фактах и анализе, несомненно, принесет свои плоды
  • - есть несколько признаков того, что внедрение системы может реально помочь:
  • - можете ли вы посмотреть на ваши данные о продажах с нескольких точек зрения? допустим, не просто по месяцам, но и по менеджерам, по отдельным продуктам и так далее?
  • - нет ли у вас данных, по которым вы не можете построить подробные отчеты просто потому, что данные хранятся в транзакционной системе?
  • - когда вы принимаете стратегические решения, чему вы больше доверяете - своей интуиции или анализу данных?
  • - пытались ли вы рассчитать корелляцию между вашими решениями и их последствиями?
  • - знаете ли вы, какой именно продукт ваши клиенты покупают больше всего? а с чем его чаще всего покупают?
  • - что ваша компания делает лучше всего? на чем основано это убеждение? есть ли у вас факты, подтверждающие это?
  • - технологии, лежащие в основе современного BI, не появились самостоятельно, а развивались именно как результат потребностей в них BI
  • - изобретение DW было прорывным моментом в BI
  • - цель создания DW - получить все данные, нужные для BI, в одном месте в едином формате для последующего их анализа
  • - DW - единое логическое (но не обязательно физическое) хранилище данных
  • - DW сам по себе не создает данные, он является всего лишь копией уже существующих в компании данных
  • - любая компания генерит тонны данных в разнообразных форматах, цель DW - привести весь этот зоопарк к единому знаменателю
  • - DW используются лишь с двумя целями: создавать конкретные отчеты по разнообразным аспектам работы компании и дать возможность формировать запросы, дающие более подробную информацию по тому или иному аспекту
  • - все операции над DW выполняются в режиме чтения
  • - в DW в принципе не предусмотрена операция удаления, оно лишь накапливает данные
  • - может быть несколько DW, каждый из которых сфокусирован на какой-нибудь предметной области
  • - одна из основных операций при наполнении DW - ETL - преобразование форматов, приведение всех данных к единому формату хранения
  • - одна из проблем при трансформации данных - некоторые из полей могут иметь разное форматирование в разных источниках, допустим те же имена, адреса и так далее, операция по приведению имен и адресов к единому виду также относится к трансформации данных
  • - в реальном мире данные могут быть некорректными, битыми, да и просто потерянными
  • - работа по трансформации состоит из трех шагов: приведение к единому формату, удаление и исправление ошибок, перевод сырых данных на язык знаний
  • - не стоит, да и невозможно пытаться модифицировать существующие транзакционные системы так, чтобы они стали частью DW - они были спроектированы, чтобы выполнять конкретную узкую функцию, и, как правило, выполняют ее хорошо - лучше не трогать
  • - DW решает проблему не только форматов, но и географических и организационных барьеров - без него менеджеры не могли бы, допустим, получить из других отделов, зданий или даже стран
  • - на уровне отделов также нет задачи выдавать данные наверх, этим должен заниматься менеджер DW
  • - BI невозможен без DW - именно наличие данных в одном месте в одном формате позволяет строить по ним отчеты
  • - правильно работающая компания непрерывно накапливает данные в цифровом формате, доступном для последующего занесения в DW
  • - для успешного построения DW не должно быть барьеров, препятствующих перетоку данных
  • - нельзя сказать, что без DW невозможно обойтись - некоторые виды систем строят его "на лету" под конкретные задачи, но суть остается прежней
  • - самого по себе сбора данных в DW недостаточно, это всего лишь первый шаг перед построением взаимосвязей между ними и последующего анализа
  • - ERP - попытка объединить прежде разнородные системы в единое целое: допустим, бухгалтерию, POS-системы и прочее
  • - SAP появилась в 1971-м году как пионер в клиент-серверных системах реального времени, предоставив единый доступ к данным всем подразделениям компаний
  • - бум на ERP-рынке наступил в 1999-м году из-за распиаренного "бага 2000 года"
  • - первые версии ERP-систем работали в основном с транзакционными базами, поэтому с отчетами были проблемы - требовались армии программистов, пишущих хранимки под построение отчетов
  • - понимание этих проблем привело к постепенному развитию и стандартизации DW и средств построения отчетов над ними
  • - первыми с подобным решением вышел SAP в 1997 году, это было большим успехом, и остальные подтянулись чуть позже
  • - первые CRM-ки были транзакционными рабочими местами сейлзов, там практически не было аналитики
  • - постепенно, по мере роста необходимости в аналитике, CRM-ки стали обрастать BI-модулями
  • - развитие аналитики в CRM-ках привело и к развитию маркетинга в целом: стали доступными отчеты, ранее невозможные, стал возможен апселл, раннее предупреждение проблем, удержание клиентов и так далее
  • - Siebel - пионер в качественных CRM-ках, был куплен Oracle за 5.8 миллиардов долларов
  • - первые CRM-ки и ERP-системы были кастомными, поэтому до нормального репортинга, как правило, руки просто не доходили
  • - Amazon - первая, по сути, компания, нормально применившая CRM в ритейле на основании анализа всех имеющихся у них данных
  • - изначально они применяли анализ лишь для обработки заказов, доставки и склада, но постепенно внедрили тот же подход во всей компании
  • - современные BI-системы не просто строят отчеты для менеджмента, они подстраивают поведение сайтов и магазинов под поведение и ожидание клиентов в реальном времени
  • - со временем влияние BI-систем распространилось и на бухгалтерию, что позволило тестировать разнообразные сценарии и вообще улучшить общую эффективность бюджетирования
  • - каждый менеджер хочет получать красивые и полезные отчеты, в реальной жизни же внедрение подобных систем сталкивается с кучей проблем как технического, так и политического характера
  • - первый и самый главный вопрос: что именно ты хочешь получить, что ты ожидаешь от своей BI-системы?
  • - если ты начинаешь разработку и внедрение BI-системы без анализа потенциальных рисков, у тебя мало шансов на успех
  • - очень часто провал в разработке и внедрении происходит потому, что эта задача передается целиком и полностью IT-департаменту
  • - софт и железо - не самая сложная и ответственная часть системы, самое сложное - понять, что же бизнесу действительно нужно?
  • - некоторые важные вопросы со старта:
  • - какие данные доступны для анализа?
  • - что мы можем мониторить для определения успешности ведения бизнеса?
  • - когда нам нужны ответы? нужны ли они все сразу, или можно по очереди?
  • - как мы будем действовать в случае, если система даст такой сигнал?
  • - готова ли компания к немедленным действиям, если мы получим искомые ответы?
  • - ответы на эти и другие подобные вопросы способны сэкономить сотни тысяч долларов и месяцы времени
  • - если у тебя есть на руках готовое BI-решение без заранее сформулированных проблем, скорее всего оно окажется бесполезным
  • - BI может съесть неограниченный бюджет, поскольку всегда можно написать еще кода, докупить еще серверов, построить еще отчетов, собрать еще данных и так далее
  • - одно из опасных состояний - ожидание внедрения BI, когда в надежде на скорое решение всех проблем сотрудники перестают выполнять свою обычную работу
  • - если ты занимаешься разработкой и внедрением BI, ты не занимаешься чем-то еще
  • - скептицизм - самоисполняющееся пророчество, борьба со скептиками будет отнимать значительные силы, если они встанут на твоем пути
  • - худший сценарий - рекомендации BI-системы прямо противоположны тем, которые дали бы наибольший позитивный эффект
  • - обычно BI-проекты проваливаются не потому, что софт сломался или девелоперы попались плохие, а потому, что плохо проведена подготовительная работа, в компании, скорее всего, просто не понимают, чего им ожидать от системы и что им по-настоящему нужно
  • - успешность BI-системы определяется отнюдь не ее масштабом, а лишь ответами на заданные ей конкретные вопросы: она может работать как на уровне отдельного маленького отдела, так и на уровне компании в целом
  • - иногда выгоднее сузить масштаб проекта до того уровня, где он принесет максимальный эффект
  • - нет одинаковых компаний, в каждой компании BI будет выглядеть и работать по-разному
  • - одна из важнейших характеристик успешного проекта: "вовремя!"
  • - лучше всего начинать с малого - уровня отдела, и переходить к следующим уровням лишь в случае успеха
  • - чем уже ты выбираешь себе нишу со старта, тем быстрее ты получишь ценный опыт, поймешь, что именно работает, какие проблемы и так далее
  • - попытка сделать "все-для-всех" заведомо обречена на провал
  • - если есть разногласия между топ-менеджерами, не важно по какой причине, твой проект столкнется с серьезными проблемами, поскольку его успешная реализация требует полной кооперации между отделами и департаментами
  • - что самое неприятное для менеджеров: BI-проект требует отдать все их данные на сторону, не каждому это по душе
  • - конфликты между менеджерами могут быть и скрытыми, ты можешь узнать о них уже постфактум, в момент внедрения системы
  • - система уровня компании поддерживает принятие стратегических решений, на уровне департамента - текущую ежедневную деятельность, значит и будет использоваться чаще и активнее
  • - часто BI-проекты начинаются на уровне департамента с мечтами о том, что когда-нибудь они вырастут до уровня компании, хотя в реальности они остаются на том же уровне, от этого они не становятся менее ценными
  • - даже если проект оказался не столь амбициозным, как казалось изначально, в нем все равно может быть огромная польза для компании в целом, даже если он и работает на уровне отдельного департамента
  • - если от тебя ожидают систему уровня компании, а ты выкатываешь им систему уровня отдела, люди будут разочарованы: стоит управлять ожиданиями со старта
  • - умные организации пытаются создать масштабируемые решения, к которым можно подключать все больше, и больше источников данных по мере того, как система доказывает свою эффективность на новых уровнях
  • - не стоит забывать, что отделы, как правило, живут своей достаточно ограниченной жизнью, а тебе придется сводить данные воедино с нескольких разнородных отделов, поэтому невозможно приучить людей с ходу к системе, где есть чуждые им данные и принципы
  • - в этом случае стоит сделать план постепенного приучения пользователей к этому и плавно его исполнять
  • - еще одна большая проблема: стратегические решения топ-менеджмента должны быть выражены в терминах, понятных сотрудникам конкретного отдела, поскольку они, как правило, говорят на разных языках
  • - одна из важных задач при построении BI-систем: сделать так, чтобы каждый отдел получал данные и аналитику в привычных для них терминах и форматах
  • - если ты работаешь на уровне отдела со стратегическими целями - жди проблем
  • - стратегический BI работает с долгосрочными целями, тактический - решает текущие, каждодневные задачи
  • - стратегические решения, как правило, не влияют непосредственно на работу компании, их последствия видны лишь в долгосрочной перспективе
  • - тактические решения, как правило, принимаются на уровне отдела, причем могут меняться со временем вместе с изменением обстановки
  • - тактические решения очень сложно автоматизировать, хотя можно облегчить работу принимающему решения, предоставив ему удобные инструменты
  • - решения, принятые в тактическом BI, немедленно отражаются на работе компании, как правило на достаточно низком уровне, уровне отдельных транзакций
  • - как правило, они имеют небольшое влияние на организацию в целом
  • - решения уровня компании не обязательно являются стратегическими, так же как и решения уровня департамента - тактическими, эти два вида идут рядом, но не взаимозаменяемы
  • - учитывая, что времени всегда не хватает, для анализа стоит выбирать поиск ответа на наиболее актуальный вопрос
  • - изначально BI развивалось как инструмент квалифицированного технического эксперта, движение в сторону юзабилити началось достаточно недавно
  • - проблема в поиске комбинации удобства и мощности - в том, что сложные запросы все равно требуют программирования в той или иной мере, отнюдь не все системы могут строить сложные запросы
  • - чтобы оценить, подходит ли вам та или иная система, стоит сравнить запросы, задаваемые конкретными пользователями и их технический уровень: иногда бывает, что наиболее "заковыристые" запросы идут от наименее квалифицированного персонала, причем ему эти ответы действительно нужнее всего
  • - даже простейшие BI-системы, по факту, являются сложными
  • - это тебе кажется простым перетаскивать столбцы, формируя отчеты, для большинства же пользователей и эта операция будет слишком сложна и непонятна
  • - вместо того, чтобы увлеченно кодировать фичи в интерфейсе, лучше сразу проверить - будут ли ими пользоваться реальные пользователи?
  • - определение требований к системе не выглядит как опросник вида "да/нет", это больше похоже на свободное общение и поисковое исследование будущих ее пользователей
  • - больше половины BI-проектов проваливаются
  • - типичные ловушки:
  • - надеяться, что правильный выбор технологий сам по себе решит все проблемы: по факту успех больше зависит от команды, от сотрудничества внутри компании
  • - надеяться, что люди справятся сами по себе, без бюджета: по факту гораздо проще купить что-нибудь уже готовое, нежели заставлять людей писать это с нуля
  • - недостаточное внимание к качеству поступающих в систему данных
  • - в DW все равно находится копия данных, а не оригинал, поэтому не стоит бояться ее править, менять форматы, удалять, и так далее
  • - путать причиннно-следственные связи с простым совпадением - необученные люди не должны делать выводы
  • - рынок BI непрерывно меняется, поэтому будь готов к тому, что какой-нибудь внешне цельный продукт на самом деле - лоскутное одеяло из купленных этой компанией конкурирующих продуктов в прошлом
  • - запросы и отчеты - разные по сути: запросы - получение "снимка" данных в определенном разрезе, отчеты же больше ориентированы на их визуализацию
  • - в современных системах разница между запросами и отчетами стирается
  • - запрос - электронное обращение за данными, выполняется конкретным пользователем через специализированное приложение, этот запрос уходит в DW и должен быть выполнен быстро
  • - запрос - базовый уровень связи между пользователем и данными, при этом правильная формулировка запроса уже содержит в себе половину ответа
  • - инструменты построения запросов должны быть достаточно простыми, объясняющими не только как строить запрос, но и показывающими доступные данные, метаданные, связи между данными и примеры возможных запросов
  • - желательно графические, с драг/дропом
  • - инструменты построения отчетов содержат в себе также функции суммирования или построения статистики по полученным данным с их графической визуализацией и средством формирования и распространения отчетов
  • - ETL: Extract, Transform, Load - процесс переноса данных из операционных баз в DW
  • - важный нюанс: данные заносятся в DW в уже подготовленном и очищенном виде, то есть DW должен быть всегда в рабочем состоянии
  • - инструменты построения запросов и отчетов служат уровнем абстракции между реально сложными алгоритмами извлечения и преобразования данных и простым интерфейсом конечного пользователя
  • - инструменты построения запросов и отчетов, как правило, универсальны, это обеспечивается тщательной подготовкой разнородных данных и приведением их к единообразию
  • - более того, интерфейсы для всех типов пользователей также однообразны и однородны
  • - процесс доступа к данным можно представить так: разнородные операционные данные - ETL - DW - единообразные инструменты построения запросов и отчетов
  • - процесс построения запросов или отчетов не должен требовать работы программиста, он целиком и полностью выполняется в пользовательском инструменте
  • - по большому счету, развитие BI завязано на развитие пользовательских инструментов построения запросов и отчетов
  • - пионерами в этом были Cognos Impromptu и Crystal Reports
  • - внешне устаревшие приложения для доступа к базам данных выглядят так же, как и BI-инструменты, но кардинальная разница - в возможности унифицированной работы с разнородными данными
  • - основные характеристики BI-инструментов:
  • - простота использования: встроенная справка, интуитивный и простой интерфейс, принятие стандартных решений за пользователя (дефолтные поля и настройки)
  • - тут, правда, всегда есть компромисс между простотой использования и предоставляемыми возможностями
  • - веб-интерфейс: хотя он и накладывает некоторые ограничения, но в целом все равно гораздо удобнее и выгоднее десктопного
  • - скорость: в целом зависит от архитектуры DW, но и конкретные реализации инструментов также могут быть проблемными
  • - общие форматы: система должна принимать популярные форматы не только на входе, но и выдавать их на выходе, обеспечивая взаимодействие с другими системами
  • - возможность углубляться в данные: пользователи не ограничены только уровнем запроса или отчета, они всегда могут быстро копнуть вглубь или посмотреть данные в другом представлении
  • - удобная коммуникация: пользователи должны иметь возможность обмениваться запросами, отчетами, создавать и использовать шаблоны, алерты и прочее
  • - классификация пользователей ведется по двум критериям: общности (создает некий базовый уровень, доступный для всех) и отличия (определяет точки, где разные группы пользователей нуждаются в разном уровне сервиса)
  • - три класса пользователей BI-систем:
  • - потребители информации - большей частью используют уже готовые отчеты, никогда не создавая своих запросов или отчетов, ограничиваются базовым функционалом системы
  • - средний класс - пользуются простейшими графическими инструментами для создания новых запросов и отчетов, но не могут запрограммировать или изменить чужой код, ограничиваются простейшим фунционалом дизайнеров запросов и отчетов
  • - администраторы и программисты - могут создавать любые новые отчеты, определяют номенклатуру доступных другим пользователям данных, отчетов и запросов
  • - эта иерархия не имеет никакого отношения к организационной структуре, чаще всего она выглядит ровно наоборот
  • - наиболее активными пользователями подобных систем являются менеджеры среднего звена и ниже
  • - в основном BI-системы используют SQL, он достаточно стабилен и показал свою эффективность за годы
  • - правильно настроенная BI-система в принципе не требует IT-департамента, всю работу с ней могут выполнять обычные пользователи
  • - фичи современных BI-инструментов:
  • - построение запросов и отчетов без SQL, драг-дропом
  • - базовый функционал анализа данных: суммирование, статистика и так далее
  • - построение графиков
  • - публикация, экспорт и шаринг информации
  • - календари и шедулер для создания отчетов и запросов по расписанию
  • - безопасность для защиты ценных данных
  • - построение отчетов уже достаточно развито, не нужно изобретать велосипеды
  • - хорошая система позволяет строить отчеты на любых данных из любых источников, вплоть до других отчетов
  • - обычно процесс построения запроса начинается с выбора необходимых полей из доступных источников и условий их фильтрации, часто в виде визарда
  • - обычно существует слой абстракции между пользователем и реальными данными, но многие системы позволяют обходить его, вводя SQL-запросы вручную
  • - когда запрос выполнен, пользователь начинает улучшать отчет, по другому располагая столбцы, добавляя графику и так далее - но это всего лишь другое представление тех же данных, полученных с помощью первоначального запроса
  • - современные системы автоматически подбирают шрифты, цвета и размеры исходя из полученных данных так, чтобы отчеты выглядели эстетичнее
  • - для шаринга данных, как правило, используется встроенный в систему функцонал безопасности
  • - отчет может быть статичным, либо автоматически обновляться вместе с обновлением данных в DW
  • - современные системы используют в основном веб-публикацию и шаринг запросов и отчетов
  • - управляемые отчеты - нечто среднее между простым потреблением информации и созданием отчетов: пользователям предоставляется предопределенный набор запросов и отчетов, в рамках которого они имеют полную свободу работы с данными, но не больше
  • - используется для ограничения доступа к данным по отделам, плюс большинству пользователей сложный и продвинутый функционал просто не нужен
  • - подобный подход требует сотрудников, отвечающих за создание подобных отчетов, контроль за их использованием и помощь пользователям при необходимости создания или изменения отчетов
  • - не стоит заблуждаться: даже самые простые шаблонные отчеты все равно потребуют обучения пользователей
  • - интерактивные запросы отличаются от обычных тем, что интерактивные непрерывно уточняются и изменяются по мере того, как пользователь "докапывается" до нужных ему данных
  • - для обеспечения доступности базы существуют query govenors, отсекающие или ограничивающие "жадные" запросы, требующие много ресурсов или времени
  • - pull - пользователи самостоятельно формируют запросы к базе, push - отчеты приходят пользователям по определенному расписанию или наступлению событий
  • - первый подход чреват тем, что пользователь может пропустить важную информацию или получить ее слишком поздно
  • - в push-подходе продвинутый пользователь собирает данные до кучи и решает, какие из них являются важными и стоит ли немедленно уведомлять других пользователей, и каких именно
  • - подобный подход требует в том числе и некой базы прав доступа, чтобы администратор четко знал, какую именно информацию можно отсылать тому или иному человеку, вплоть до разного представления одного и того же отчета
  • - алерты - сравнительно молодая фича, служит обычно для уведомления о появлении новых данных, обновлении отчетов или наступлении важного события
  • - есть готовые сервисы доставки алертов, работающие по любым каналам
  • - очень часто компании недооценивают сложность и ресурсоемкость организации push-систем
  • - OLAP - способ организации данных в готовой к построению отчетов форме, дает возможность пользователю браузить по ним и получать срезы и новые представления обычным драг/дропом
  • - основное достоинство OLAP - он не требует вмешательства технического специалиста для построения по-настоящему сложных отчетов, при этом позволяет реал-таймовый "браузинг" по всем доступным данным
  • - буква "O" в аббревиатуре означает Online, то есть немедленный доступ к данным, без предварительной подготовки запроса
  • - OLAP работает не с реляционными данными, а с измерениями, категориями
  • - OLAP-системы заточены под работу с числовыми данными, поэтому столь популярны в бухгалтерии, финансах, ритейле, банковском деле
  • - сами по себе цифры бессмысленны, они обретают значение лишь с описанием и квалификаторами, а в случае с таблицами описанием является заголовок колонки
  • - одно измерение - допустим, продажи по регионам или по отдельным продуктам
  • - два измерения - разбивка данных по продажам одновременно по регионам и отдельным продуктам: столбцы - регионы, колонки - продукты, допустим
  • - три измерения: добавление группировки в ту же таблицу по годам, допустим: количество строк увеличивается в N раз, где N-количество лет
  • - собственно, именно с третьего измерения и дальше заметна разница между обычными таблицами и OLAP
  • - подобная разбивка дает информацию, недоступную для обычных табличных методов анализа, этим OLAP и ценен
  • - под "много измерений" обычно подразумевается "три и больше"
  • - в теории количество измерений не ограничено, на практике ограничения существуют как технологические (экспоненциальный рост ресурсоемкости расчетов при увеличении количества измерений), так и когнитивные (пользователю сложно понять объемные структуры данных)
  • - в ходе интерактивной сессии обычно работают с одним или двумя измерениями, изредка создавая больше измерений, по итогам формируются результаты в табличной форме
  • - многоразмерные данные обычно имеют четкую логическую иерархию
  • - наилучшие результаты получаются тогда, когда пользователь строит иерархию в соответствии со своими конкретными задачами
  • - хорошие системы позволяют простую и быструю навигацию по иерархии, давая более-менее детальные данные на каждой итерации
  • - OLAP-кубы обычно строятся на основе данных из DW и существуют параллельно с ним
  • - кубы - общее название структуры хранения любого количества измерений
  • - основная цель использования OLAP-инструментов - быстро "покрутить" данные из кубов так, чтобы найти подходящий уровень детализации для поиска ответов на вопросы
  • - OLAP-инструмент должен позволять углубляться в детали без потери общего глобального контекста
  • - основной показатель качества OLAP-системы - простота и интуитивность ее использования даже на сложных структурах данных
  • - OLAP-система должна позволять быстрое и простое построение графики, чтобы визуально анализировать полученные данные на любой итерации
  • - обязательна возможность строить тренды или даже экстраполяции
  • - в любой точке ты можешь кликнуть на любое число и увидеть исходные данные - допустим, конкретные продажи, из которых это число было рассчитано
  • - атрибут - описательная деталь, позволяющая построить измерение по исходным данным - допустим, дата, регион, название продукта и так далее, могут объединяться в иерархии (год-месяц-день или категория-продукт-версия)
  • - ячейка - отдельное число в массиве данных
  • - "замер" или "факт" - заголовок таблицы, подробно описывающий ее содержимое (допустим, "продажи по регионам")
  • - член - отдельный элемент внутри измерения, допустим название продукта
  • - навигация по данным происходит обычным кликом по числам: допустим, кликнув по сумме продаж определенного продукта, ты можешь посмотреть продажи этого продукта по месяцам, и так далее
  • - MOLAP - OLAP во многих измерениях, избыточное представление данных в угоду скорости, требует технической экспертизы для организации работы
  • - ROLAP - попытка натянуть модель кубов на существующие реляционные базы путем создания слоя абстракции, позволяет обойтись без отдельного построения кубов, имеет право на жизнь из-за выросшей производительности серверов баз данных
  • - HOLAP - гибридная структура, предоставляется современными субд, обеспечивает прозрачный доступ к данным, строя части кубов по необходимости на лету и обеспечивая их синхронизацию с изменяющимися данными
  • - начавшись как попытка обеспечить топ-менеджмент краткой сводкой информации о состоянии компании, EIS стали быстро востребованы на всех ее уровнях, поскольку менеджерам среднего и низшего звена захотелось увидеть те же цифры, по которым топ-менеджмент оценивает их работу
  • - собственно, с этого момента пошла унификация KPI
  • - дешбоарды прижились хорошо, но обнаружили одну большую проблему: статичность - пользователь не мог добавить новые данные или индикаторы на лету, не мог настроить новые алерты и так далее
  • - KPI должен быть достаточно детальным для того, чтобы понять источник проблем и достаточно общим, чтобы не зарываться в мелкие детали
  • - хороший пример KPI - годовые оценки в школе
  • - KPI можно вводить на любом уровне ведения бизнеса и они оказывают по-настоящему позитивное воздействие, если сформулированы правильно
  • - нет универсальных KPI, поскольку даже компании на одном рынке имеют свои сильные и слабые стороны
  • - дешбоарды эффективнее всего даже не на уровне топ-менеджмента, а на уровне отдельных конкретных операций
  • - общие характеристики дешбоардов:
  • - навигация - дешбоард дает доступ к гораздо большему объему информации, чем может вместить один экран
  • - графическое представление информации, выделяющее потенциальные проблемы или возможности
  • - интерактивность - можно кликнуть по любому индикатору дешбоарда и увидеть более подробные данные или даже попасть в систему управления этими данными
  • - настраиваемый интерфейс: пользователь должен иметь возможность подстроить внешний вид дешбоарда под свои текущие задачи
  • - встраиваемый контент: нужно позволить пользователю добавлять внешние источники данных, удобные в его работе
  • - отображение в браузере - так просто удобнее и использовать, и обновлять
  • - в дешбоарде лучше делать упор на графику, а не на текст, ведь основная его цель - дать быстрый обзор ситуации
  • - тактический дешбоард - показывает метрики конкретного узкого процесса, допустим работы сайта, плюс дает возможность быстро находить узкие места и источники проблем в случае их возникновения, обычно применяется на уровне отдельного сотрудника
  • - операционный дешбоард - показывает краткосрочные и среднесрочные бизнес-метрики вроде удовлетворенности клиентов, позволяет принимать текущие решения, обычно применяется на уровне команды или отдела
  • - стратегический дешбоард - уровня топ-менеджмента, обычно имеет собственную команду, ответственную за его мониторинг и реакцию на события
  • - дешбоард может служить ранним индикатором проблем или возможностей, но он не может заменить собой полноценные процессы анализа, исследований и принятия решений
  • - два основных вопроса перед созданием дешбоарда: какой уровень данных будет охвачен и какие именно данные нуждаются в отображении?
  • - дешбоард начинается с KPI, а KPI - с определения целей бизнеса
  • - часто проблема - отнюдь не в дешбоарде, а в отсутствии необходимых для него данных
  • - не нужно перегружать дешбоард информацией, в голове всегда должна быть цель его создания
  • - особое внимание - юзабилити, поскольку пользователь будет обращаться к дешбоарду много раз в течение дня
  • - briefing book - настраиваемый дешбоард, в котором элементы появляются только при выполнении определенных критериев: допустим, возникновении ошибки
  • - scorecards - отображение прогресса выполнения определенного плана
  • - scorecards чрезвычайно эффективны как инструмент мотивации, поскольку каждый сотрудник видит свой конкретный вклад в общее дело, как он помогает или мешает его исполнению
  • - BI не сильно отличается от научных исследований: развивается методология, создаются новые подходы и инструменты, появляются готовые решения и так далее
  • - области, в которых в последнее время наблюдается значительный прогресс:
  • - визуализация данных
  • - ориентированная на действия аналитика, дающая на выходе конкретные инструкции
  • - data mining
  • - инструменты работы с неструктурированными данными
  • - реализация обычно сильно отстает от идей, редкая компания согласится взять на себя риск стать первопроходцем
  • - самые популярные и привычные фичи обычно появляются как личная инициатива какой-нибудь отдельной команды или девелопера, и только после завоевания внимания рынка становятся де-факто стандартом
  • - визуализация - не просто прихоть, а способ визуально определить важные точки или тренды гораздо эффективнее, нежели используя табличные данные
  • - даже самый простой график разрушает когнитивный барьер между данными и их значением
  • - чем объемнее данные, тем больше пользы от визуализации
  • - навороченность графики может стать препятствием к ее восприятию, разрушая основную свою цель - упростить анализ информации
  • - с другой стороны, мы привыкаем к хорошему, и красивые графические интерфейсы все равно побеждают более аскетичные, но более юзабельные
  • - чтобы информация была воспринята, требуется в первую очередь обратить на нее внимание, поэтому красота интерфейса несет не только эстетическую функцию
  • - точности данных самих по себе недостаточно для того, чтобы донести их до пользователя
  • - программисты не могут предусмотреть все, поэтому современные системы идут с API, позволяющими создание своих отчетов и виджетов
  • - продвинутые инструменты визуализации хороши лишь в руках эксперта, новичок лишь усложнит восприятие информации
  • - аналитик должен уметь не только анализировать данные, но и разбираться в их визуализации
  • - визуализация только кажется простой только на первый взгляд, при этом в ее основе лежит большой опыт в анализе данных и психологии восприятия
  • - визуализация часто остается единственным эффективным способом представления объемных данных
  • - если ты дошел до точки, когда визуализация по-настоящему необходима, скорее всего у тебя уже реально большие объемы информации
  • - одна из больших проблем аналитики - слишком много потенциальных возможностей, нужно приучать себя выбирать наиболее важные на текущий момент
  • - управляемая аналитика - когда система сама подсказывает, какие запросы или визуализацию стоит сделать следующими на основании уже полученных данных
  • - ее можно сравнить с экспертом, сидящим рядом с тобой и направляющим твои действия
  • - хорошее применение управляемой аналитики - разбиение сложного процесса на более простые последовательные шаги
  • - работа с BI-системой обычно выглядит следующим образом: пользователь отправляет запрос, либо подписывается на получение какой-либо информации, затем анализирует полученную информацию, что подразумевает не просто ее просмотр, но и создание дополнительных запросов, вплоть до полной замены исходного набора
  • - развитие технологий позволяет объединить в одном флаконе выполнение транзакционных и аналитических задач
  • - управляемая аналитика обычно выглядит как подсказки, визарды, алерты, встроенная контекстная справка и прочее
  • - система может даже самостоятельно делать выборки, которые потенциально понадобятся пользователю, и предоставлять к ним контекстный доступ
  • - система также может накапливать историю того, что пользователь уже посмотрел и хранить тудушку по дальнейшим шагам
  • - желательно также показывать общий прогресс исследования
  • - data mining живет и развивается из-за надежды на то, что накопленные массивы данных могут оказаться полезными в будущем, аналогично работе биржевого трейдера
  • - первые попытки создать искусственный интеллект были основаны на идее самообучающихся систем, но там возникали практические проблемы качества их реализации и качества подаваемых на вход этих систем данных
  • - современный подход для решения тех же проблем - Data Mining
  • - Data Mining - описательное название всех методов превращение сырых исходных данных в значимую информацию
  • - есть много подходов к реализации DM: поиск шаблонов, статистический анализ, математические модели, эвристика и так далее
  • - обычно все упирается в три вопроса: что произошло в прошлом? почему? какое влияние это окажет на будущее?
  • - одно из самых больших заблуждений DM-экспертов: искать причинно-следственные факторы там, где их нет, где все можно объяснить случайностью
  • - DM реально применяется и дает хороший измеримый эффект в случае правильной реализации
  • - чем дальше, тем больше DM применяется не только в финансовой сфере, но и в других областях бизнеса
  • - DM требует высокого уровня экспертизы, очень часто неопытный сотрудник лишь создает новые проблемы из-за неправильной интерпретации статистических данных
  • - DM можно считать критической частью BI, которая может дать ощутимое конкурентное преимущество с накоплением опыта
  • - современные "модные" идеи BI:
  • - BI - для всех и каждого, от рядового сотрудника до топ-менеджера
  • - извлечение ценных знаний из неструктурированных данных
  • - нет универсального BI-решения, в принципе не стоит торопиться с выбором поставщика - гораздо важнее выполнить подготовительную работу внутри компании
  • - когда выбираешь BI-решение, стоит думать не только о бюджете, но и о затратах времени, и о том, почему ты сейчас будешь делать BI-систему, а не заниматься чем-либо еще?
  • - перед началом проекта стоит четко определить его охват и установить себе дедлайн по реализации
  • - все выглядит очень просто на бумаге, но ожидай серьезных трудностей на каждом этапе, отставаний по срокам и бюджетам, неожиданных проблем и препятствий
  • - лучшие BI-системы отнюдь не выглядят цельными, чаще всего это "солянка" из наиболее интересных идей, методологий и инструментов разных вендоров
  • - качество инструмента определяется в первую очередь тем, насколько хорошо он подходит под решение конкретно твоих задач
  • - можно выбрать и одного вендора, если охват проекта не слишком большой - хорошие результаты получаются в случае применения специализированных готовых решений (для HR или бухгалтерии, допустим)
  • - под словом "методология" обычно подразумевается способ, которым ты создаешь и внедряешь BI-систему, его синонимом может быть "стратегия" или "подход"
  • - когда ты выбираешь решение для узкой проблемы и решился остановиться на конкретном продукте определенного вендора, лучше не пытаться кастомизировать его - это лишь усложнит задачу
  • - в этом случае лучше всего дословно следовать инструкциям и методологии, предоставляемой вендором
  • - признаки того, что готовое решение не подходит:
  • - в процессе реализации оно начинает захватывать не только изначально запланированный департамент, но и другие
  • - начинает не хватать статичных отчетов или простого OLAP
  • - использует ресурсы из других систем
  • - не стоит путать план проекта и методологию: первое концентрируется на конкретных технических шагах, второе охватывает в том числе и мотивацию и стратегию
  • - плана проекта, как правило, недостаточно - стратегия и мотивация имеют огромное значение в случае с BI-проектами
  • - начинать стоит с анализа того, что компания УЖЕ делает в этом направлении
  • - в идеале BI-проект начинается с нуля, в реальности же он вынужден подстраиваться под уже существующие внутри компании системы аналитики, даже если они называются по другому
  • - допустим, ежемесячные отчеты руководителей отделов - тоже часть BI, хотя они об этом и не задумываются
  • - стоит учитывать сложившиеся правила, процедуры и людей, ответственных за их реализацию
  • - для начала стоит сделать полный список методов BI, уже существующих в компании, причем достаточно подробный
  • - затем - спланировать, как эти методы будут интегрированы или заменены новой системой
  • - потом - самое важное: стоит ли вообще их трогать, и достойны ли они того, чтобы их сохранить в принципе?
  • - если технология устаревшая - не означает, что она автоматически становится "плохой"
  • - вообще не стоит ломать то, что уже работает, особенно не посоветовавшись с пользователями
  • - когда оцениваешь текущее состояние BI, стоит у каждого пункта выставлять свою оценку состояния: "убого, хорошо, достойно" в сравнении с тем, как оно возможно будет выглядеть в новой системе
  • - потом нужно создать список источников данных и оценить их качество и доступность
  • - потом - оценить уже существующие методы и системы построения отчетов
  • - ну и только потом переходить к планированию разработки отчетов, каждый раз задавая следующие вопросы:
  • - кто будет ими пользоваться?
  • - зачем?
  • - что они надеются получить?
  • - немедленный переход после предварительного анализа к выбору вендора опасен тем, что ты ограничиваешь свое мышление и спектр возможностей
  • - соблазн сделать это особенно велик потому, что это превращает вроде как скучное и бездеятельное планирование в "реальную работу"
  • - архитектуру стоит начинать планировать тогда, когда есть полный список того, какую именно информацию и в каком формате будут использовать сотрудники
  • - архитектура должна быть задокументирована в наборе документов, описывающих структуру системы, потоки данных с описанием их текущего и желаемого состояния, ETL-процедуры, архитектуру DW, требования к инструментам построения запросов и отчетов
  • - желательно иметь разделы об ответственности, управлении, администрировании и безопасности
  • - описание архитектуры обычно текстовое, с минимумом графики
  • - архитектура описывает не только отдельные части системы, но и их взаимодействие
  • - выбор различных аспектов архитектуры обычно означает определение приемлемого (не обязательно лучшего) варианта, поскольку все альтернативы более-менее похожи
  • - то есть не нужно париться по поводу того, что какие-то вещи не оптимальны: достаточно самого факта выбора из нескольких альтернатив, чтобы обеспечить достаточное приближение к оптимуму
  • - когда стоимость ошибки велика, лучше спросить чужого совета, но не обязательно эксперта или вендора: существует огромное количество онлайновых коммьюнити
  • - дизайн интерфейса и юзабилити - ключевой фактор успешности BI-системы, этому стоит уделить особое внимание и применять проверенные принципы его разработки
  • - на этапе реализации следует следить за тем, чтобы девелоперы не уходили слишком далеко в виртуальный мир технологий, чтобы они сохраняли связь с реальными данными и живыми пользователями
  • - чем ближе к завершению проект, тем больше будет соблазн устроить фальстарт, выкатив сырой непротестированный продукт, тебя будут торопить со всех сторон - этого нужно избежать
  • - основное на этапе девелопмента - придерживаться изначального плана, не позволяя в том числе и его изменений прямо перед релизом. Вот релизнем - и можно что-то менять, не раньше
  • - в плане также есть пункт и про обучение пользователей: это такой же важный пункт, как и другие, без него система может оставить негативное первое впечатление
  • - стоит устроить праздник по поводу релиза и пригласить на него как можно больше людей - это официально переведет проект из разряда "девелопмент" в разряд "развитие и поддержка"
  • - обычно команда внедрения BI-проекта состоит из следующих ключевых сотрудников:
  • - менеджера проекта, отвечающего за коммуникации внутри и снаружи команды, следование плану и его изменение в случае необходимости
  • - бизнес-аналитиков, отвечающих за коммуникацию с будущими пользователями системы, сбор их требований (в том числе негласных) и описание этих требований в понятной всем участникам процесса форме
  • - датабазеры, с упором на не-транзакционные и нереляционные базы данных
  • - аналитики по качеству данных, обязательны для реализации ETL-алгоритмов
  • - при общении с пользователями их стоит делить на обычных и экспертов в своей области - от вторых можно получить наиболее ценную информацию
  • - чтобы обеспечить выживание системы, стоит сделать что-то вроде хранилища знаний по ее организации, чтобы потеря ключевых сотрудников не оказалась фатальной
  • - стоимость разработки и запуска системы меркнет перед стоимостью ее поддержки за несколько лет
  • - желательно создать что-то вроде координационного центра, который бы управлял использованием, поддержкой и развитием системы
  • - этот центр должен состоять из парт-тайм сотрудников с другими основными ролями, чтобы не терять связи с реальностью
  • - развитие Excel привело к тому, что сотрудники выполняют достаточно сложные расчеты и хранение ценной инфоомации у себя на компьютерах, эту информацию невозможно собрать в центральное хранилище, и отказ от подобных методов может вызвать протесты у людей, обрекая систему на провал
  • - проблема на этапе сбора требований - аналитик должен получить правдивую картину того, как по-настоящему работает тот или иной бизнес в условиях, когда каждый отдельный менеджер будет рассказывать свое видение
  • - если возникают конфликты на каком-либо из уровней, за решением стоит идти на уровень выше
  • - не стоит относиться к подобным конфликтам как к проблеме - наоборот, BI-система будет наиболее полезна именно в этих случаях
  • - иногда плохой инструмент выполняет правильную задачу, и наоборот - нужно всегда разделять софт и процессы, которые он обслуживает
  • - не стоит ломать старое, чаще всего выгоднее интегрировать уже существующий софт и процессы в свою систему
  • - сотрудники часто настолько замучаны и привыкли к устоявшемуся порядку вещей, что им сложно взглянуть на себя и свою работу со стороны, представить что-нибудь получше
  • - в любой организации есть священные коровы - жутко неэффективные решения или даже целые отделы, которые существуют исключительно по политическим мотивам, и не твоя задача с ними бороться, с этим придется просто смириться
  • - в первую очередь стоит использовать те решения, которые уже есть в компании, пусть даже и в ограниченном контексте: допустим, дешбоарды у главного бухгалтера вполне можно распространить на всю компанию, поскольку для айти-отдела это уже знакомая вещь
  • - тебе нравится то, что ты делаешь, но не стоит превращаться из евангелиста в фанатика: привычные твоим пользователям простые решения вроде экселя часто гораздо удобнее и эффективнее лично для них и их задач, соответственно не надо пугать людей перспективой отказа от привычных для них решений или с пеной у рта доказывать свою правоту
  • - часто еще до твоей системы какие-то процессы выполнялись вручную, они стали привычными, и их автоматизация просто не даст достаточно преимуществ, чтобы убедить людей перейти на новое
  • - самый лучший план - не всегда самый реалистичный: кажущиеся очевидными решения не всегда оказываются таковыми на практике
  • - после сбора всей необходимой информации стоит немного помечтать, убрав все ограничения в виде бюджета, времени и политики, ну а потом приводить этот идеальный план к реальности
  • - подобный подход показывает тебе долгосрочную картину и цель всего процесса, он сам по себе может служить сильным мотиватором
  • - не стоит пропускать этот шаг - он позволяет задуматься не только над тем, что хотелось бы сделать, но и почему, посмотреть на вещи более глобально и стратегически
  • - после этапа идеального плана стоит начать искать преграды на пути к его реализации - это обозначит и границы проекта, и риски
  • - не стоит надеяться, что ты автоматически получишь идеальный план - на практике приходится думать и сомневаться над каждым пунктом
  • - не надейся, что компания изменится к лучшему, всегда планируй будущее, исходя из сегодняшнего ее состояния
  • - если какой-то из пунктов твоего плана подразумевает изменение компании, сужай фокус
  • - после того, как из плана выкинуты нереализуемые пункты, стоит оценить риски оставшихся - это позволит не только лучше подготовиться на случай их реализации, но и минимизировать их последствия
  • - затем - оценка прибыльности каждого из пунктов, заодно выкинуть те, которые не подходят под основные характеристики BI-методологии: вовремя, точные, ценные и деятельные
  • - прибыльность не всегда можно измерить: есть некоторые категории решений, дающие ощутимый моральный эффект, но напрямую не отражающиеся на балансе: допустим, избавление от старой неудобной технологии, или большая удовлетворенность клиентов
  • - если какое-то решение кажется заведомо правильным со старта, не торопись: сначала изучи все альтернативы, а уже потом принимай осознанное решение
  • - если у тебя есть два варианта, между которыми сложно сделать выбор, просто проиграй в голове сценарии - от реализации, до использования и поддержки
  • - если и тогда разницы нет, просто выбери случайный из них, отложив окончательное решение на будущее
  • - мало самому принять решение, нужно еще получить одобрение у заинтересованных лиц, поскольку BI - не просто технология, она является частью бизнеса и отражается на всех его участниках
  • - стоит регулярно устраивать встречи со всеми заинтересованными лицами, чем выше уровнем - тем лучше
  • - цель каждого такого собрания - получить одобрение ключевых моментов для продолжения работы
  • - стоит понимать, что все в мире изменяется, поэтому ты всегда делаешь лишь первую версию системы, даже если она называется финальной
  • - наилучший подход - микрорелизы, чтобы на каждой итерации было что-то реально работающее и приносящее пользу компании
  • - планы, может, и будут выкинуты в мусорку, но вот процесс планирования ценен сам по себе
  • - всей полноты информации не будет никогда, это не должно останавливать
  • - выбор между централизованной и децентрализованной системой не так прост: каждый из вариантов имеет свои плюсы и минусы, особенно в ситуации разнообразия требований к системе в разных частях организации
  • - часто этот выбор естественным образом проистекает из стиля управления: автократичный менеджмент выберет централизованную систему
  • - выбор архитектуры обычно опирается на 3 фактора: железо, управление данными и пользовательские инструменты
  • - стоит начинать с пользовательских инструментов, а не с данных
  • - выбор между вариантами стоит делать осознанно, уделяя каждому из них равное внимание, поскольку в реальности мы будем склонны просто пропускать мимо детального рассмотрения непривычные нам сценарии
  • - самое дорогое решение редко является лучшим, утверждение плана топ-менеджментом не дает тебе безлимитный бюджет
  • - стоит избегать первых версий любых чужих продуктов
  • - стоит начинать не с первого шага, а с первой фазы - выбрав наиболее перспективный и наименее затратный модуль, который немедленно принесет пользу
  • - на первой фазе стоит избегать технически сложных решений
  • - всегда лучше улучшать существующее, а не создавать новое с нуля
  • - BI-системы отнюдь не статичны, они непрерывно экволюционируют и подстраиваются под изменения окружающего мира
  • - стоит выделять квартал раз в два года на то, чтобы "зафиксировать" код, позволив поработать над железом и юзабилити интерфейсов
  • - стоит ввести KPI и для самой системы: аптайм, удовлетворенность пользователей, баги и так далее
  • - план проекта не должен быть столь детальным, чтобы это значительно откладывало начало работы: всегда будут белые пятна, но реализация все-таки важнее планирования
  • - когда распределяешь людей по ролям, начинай с ролей и ищи подходящих людей, а не наоборот - не пытайся навесить на людей то, к чему они не склонны
  • - роли не означают людей - один и тот же человек может играть несколько ролей
  • - не стоит заранее планировать конкретные даты майлстоунов - гораздо адекватнее рассчитывать их исходя из текущего прогресса
  • - менеджер проекта должен гораздо больше внимания уделять проекту, а не плану
  • - сбор требований к проекту должен дать на выходе документ со следующими разделами:
  • - предположения и допущения: что - в нашей власти, а что - нет
  • - фичи будущего проекта
  • - требования: детальная спецификация того, что будет на выходе
  • - процессы и потоки: взаимодействие пользователей с системой и частей системы между собой
  • - приоритет требований: субъективная оценка важности тех или иных требований
  • - источники требований и изменений: позволяют при необходимости уточнять и проверять требования
  • - прототипы, скриншоты и заглушки пользовательского интерфейса
  • - сценарии использования
  • - в отличие от других частей проекта, список требований должен быть более-менее статичным после определенной даты
  • - объем описания той или иной части или процесса должен соответствовать ее важности и объему в итоговом приложении
  • - на этапе сбора требований основные его участники - будущие пользователи и заказчики, а не айтишники
  • - даже если у вас есть опытные BI-сотрудники, а требования вроде как очевидны, все равно стоит идти и собирать требования напрямую у пользователей
  • - на совещании стоит спрашивать мнения всех участников, чтобы получить идеи даже от самых молчаливых
  • - идеальный формат общения - лицом к лицу, пусть даже и в скайпе, е-мейл использовать только в крайнем случае
  • - достаточно легко собрать уже существующие в компании отчеты, гораздо тяжелее - вытянуть с людей информацию о том, какие отчеты им на самом деле нужны
  • - нет ничего хуже айтишника, навязывающего свое решение там, где сотрудникам достаточно того, что уже есть
  • - на ETL стоит отправлять лучших из лучших - это самая ответственная и сложная часть работы
  • - метаданные - описание того, что, в каком формате и с какими связями хранится в базе данных - самой структуры бд, как правило, недостаточно
  • - основной критерий эффективности форматирования отчета: его содержимое должно быть понятно с первого взгляда, без дополнительной помощи со стороны
  • - специалист по построению отчетов необходим хотя бы на первом этапе, когда создаются первые отчеты, которые потом послужат примерами и шаблонами для последующих
  • - как правило, в компании уже есть какие-либо формы отчетности, поэтому основная ценность BI-системы будет не в самих отчетах, а в их новизне, если получится предоставить новый взгляд на вещи
  • - будет соблазн скопировать существующие формы отчетов в новую систему, но стоит быть осторожным: они могут опираться на недоступные данные или неформализуемые процедуры, да и просто быть устаревшими или вообще ненужными
  • - посмотреть Microsoft Report Builder
  • - аналитические продукты хороши ровно настолько, насколько хороши данные, которые они обрабатывают
  • - большинство BI-проектов не оправдывают возложенных на них надежд
  • - BI - не проект, а процесс, который приносит свои плоды постепенно и изменяет организацию изнутри
  • - BI = непрерывное улучшение
  • - использование BI-систем открывает новые возможности, которые, в свою очередь, требуют непрервной эволюции тех самых систем
  • - большинство пользователей, по факту, сами не понимают, что им было нужно от системы до тех пор, пока не начнут ее использовать
  • - результаты внедрения системы невозможно замерить сразу после ее запуска, поскольку пользователи еще будут к ней привыкать и встраивать в свою работу
  • - DW - хранилище копии операционных данных, оптимизированное под запросы и построение отчетов
  • - DW - не обязательно одна большая база, это может быть набор баз в разных местах
  • - отличие warehouse от repository: первое хранит исторические данные, полную историю изменений, второе - текущие данные, максимум - последние изменения
  • - основные проблемы с данными возникают из-за того, что они могут лежать в разных форматах в разных базах, часто дублированные, битые или даже просто утерянные
  • - еще одна проблема - сопротивление владельцев данных, которые опасаются утери контроля над ними, для этого нужна помощь руководства
  • - каждое поле в DW должно иметь следующие характеристики:
  • - название - короткое уникальное название на латинице, используется для доступа
  • - описание - "человеческое" краткое описание того, что представляет из себя это поле
  • - тип - тип значений, хранимых полем, используется программистами
  • - правила валидации - ограничения на возможные значения
  • - владелец - кому исходно принадлежат эти данные, больше политический вопрос
  • - источник - полная информация о том, откуда берется информация в этом поле: отдел, база, таблица, колонка и так далее
  • - отношения между таблицами - реляционные связи
  • - бизнес-правила - определяют, что можно делать с этими данными
  • - ETL требует 100%-го понимания предметной области, часто можно понять правила обработки данных лишь зная историю их появления в той или иной базе
  • - DW должен с самого начала организовывать структуру данных так, чтобы она была интуитивно понятна обычному пользователю
  • - если у тебя слишком жесткие правила проверки данных перед включением в DW, операторы будут "жульничать", занося в обязательные поля разную чепуху, лишь бы выполнить план
  • - DW может быть, да и должен быть избыточен, его основная цель - обеспечить быстрый и удобный доступ к данным и построение отчетов
  • - стоит изначально разбивать данные по измерениям, поскольку тогда данные становятся более интуитивными не только для пользователей, но и для разработчиков
  • - разбивка по измерениям резко упрощает соединение и фильтрацию данных
  • - измерения позволяют добавлять новые факты без перестройки базы
  • - звездная схема - центральная таблица фактов (допустим, продаж) и связанные с ней таблицы измерений (допустим, время, модели продуктов, клиенты, менеджеры и так далее), в таблице фактов хранятся лишь идентификаторы таблиц измерений
  • - звездная схема - самая популярная, она достаточно проста для понимания как программистами, так и пользователями
  • - схема снежинки - похожа на звездную, только вместо концов звезды в виде отдельных таблиц идет их нормализованная иерархия, такая структура сложнее для понимания и управления
  • - гибридные модели - реляционное хранилище для одних данных и кубы - для других, используется в зависимости от типов данных
  • - Data Mart - подмножество DW, заточенное под определенный узкий набор данных и под конкретную операцию
  • - хороши в первую очередь тем, что не перегружают пользователя и оборудование лишними полями и связями
  • - при создании DM есть риск того, что ты в итоге создашь несколько отлично работающих DM в отдельных областях, но при этом потеряешь связь между этими областями, которую тебе дал бы DW
  • - Operational Data Storage - то же, что и DW, только без накопления исторических данных, хранит лишь текущее состояние
  • - часто ODS используется как буфер для DW, из которого по таймеру вытаскиваются данные для занесения в DW
  • - на этом рынке мелкие компании обычно специализируются на чем-то, затем становятся лидерами в какой-то узкой области, затем покупаются более крупными игроками
  • - позиция Oracle: интеграция - головная боль, поэтому купите лучше наше комплексное дорогое решение
  • - позиция Microsoft: куча разных инструментов, от мелких (Excel) до крупных (MS SQL Server), достаточно качественных, MS можно считать лидером на этом рынке
  • - независимые поставщики тоже живут хорошо, если предоставляют нишевые решения
  • - готовые сервера продаются плохо
  • - MySQL - серьезный игрок на этом рынке
  • - посмотреть Jaspersoft - вроде как опенсорсный репортинг
  • - в последнее время популярность приобретают комбинации опенсорсных решений
  • - если есть свои девелоперы, лучше писать свой ETL
  • - MS Office вполне достаточно для организации BI-системы небольшого размера
  • - обычно продавцы BI-продукта дают что-то простое и недорогое, "подсаживающее" и показывающее быстрые первые результаты, однако основные расходы будут потом - на модули и аддоны
  • - если какие-то этапы требуют большого времени (допустим, согласование бюджета на закупку оборудования или найм специалистов), лучше начинать это делать сразу
  • - не стоит экономить на тестировании
  • - радикальное отличие финального плана от первого наброска - вполне нормально, оно всего лишь отражает сложность и непредсказуемость реального мира
  • - бессмысленно писать ETL на основании спецификаций, реальные данные всегда сложнее
  • - отладка на тестовых данных, по факту, имеет мало смысла: реальные данные все-таки гораздо сложнее, поэтому не стоит откладывать подключение реальных данных к интерфейсам
  • - приоритет - данным, а не интерфейсам: в первую очередь нужно отладить ETL и работу с данными, а потом уже - создание запросов и отчетов
  • - поддержка BI-системы - в первую очередь контроль качества данных
  • - не изобретать велосипед: пытаться использовать уже готовые решения до тех пор, пока ты на 100% не убедишься, что лично тебе они не подходят
  • - стоит вести базу знаний по BI-проекту, чтобы новые сотрудники проще входили в работу, да и старые со временем будут все забывать
  • - BI система требует постоянного контроля, поддержки, баг-фиксов и ручного труда
  • - само по себе использование системы будет непрерывно генерировать идеи по ее расширению и улучшению, стоит на это закладываться с самого начала
  • - если после запуска системы люди продолжают пользоваться своими старыми методами, стоит разбираться в причинах.
  • - если ты не получаешь запросов на поддержку и баг репортов, опять же нужно разбираться: либо люди не пользуются системой, либо не знают, к кому обращаться в случае проблем
  • - вне зависимости от того, насколько хороша система, у пользователей все равно будет синдром утери привычных вещей, это со временем пройдет