Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 14
На счет маркетологов, отчасти согласен. Еще и самые хитрые задачи, обычно, исходят с их стороны.
Получается, что сами придумали сложные задачи и, в последствии, продовать дорогое ПО для их решения.
Но это наше с вами мнение. А вообще, так про многие вещи можно сказать, что они никому не нужны и все это от маркетологов.
Про Access. Вы забываете, что он тоже не бесплатный и в стандартном наборе Office его нет. Но он, действительно, позволит решать многие задачи, до определенного времени. Про это я как-то и забыл. Простите.
Про замену OLAP-мути представлениями и кастомными функциями. Специалист, который сделает это хорошо, скорее всего, обойдется заметно дороже среднего BI-разработчика. Я не так много знаю таких, но в Москве ЗП тех, кому бы я все это доверил может быть на 1,5тыс.$ больше. За год, с налогами, это больше 20тыс., за такие деньги можно много чего купить, плюс, как раз — внятная поддержка. Opensource-ный же OLAP может быть лишен таких приятных вещей, как write-back через Excel-евский «Анализ „что если“», с помощью которого легко создается система планирования. В общем, такая экономия в итоге может привести к сопостовимым затратам.
Получается, что сами придумали сложные задачи и, в последствии, продовать дорогое ПО для их решения.
Но это наше с вами мнение. А вообще, так про многие вещи можно сказать, что они никому не нужны и все это от маркетологов.
Про Access. Вы забываете, что он тоже не бесплатный и в стандартном наборе Office его нет. Но он, действительно, позволит решать многие задачи, до определенного времени. Про это я как-то и забыл. Простите.
Про замену OLAP-мути представлениями и кастомными функциями. Специалист, который сделает это хорошо, скорее всего, обойдется заметно дороже среднего BI-разработчика. Я не так много знаю таких, но в Москве ЗП тех, кому бы я все это доверил может быть на 1,5тыс.$ больше. За год, с налогами, это больше 20тыс., за такие деньги можно много чего купить, плюс, как раз — внятная поддержка. Opensource-ный же OLAP может быть лишен таких приятных вещей, как write-back через Excel-евский «Анализ „что если“», с помощью которого легко создается система планирования. В общем, такая экономия в итоге может привести к сопостовимым затратам.
> XML-RPC over FTP в поделках умников некоторых умельцев 1С
Вспомнил CSV-RPC over Floppy Disk для обмена с 1С, брр.
Вспомнил CSV-RPC over Floppy Disk для обмена с 1С, брр.
Какие olap системы в качестве серверов и клиентов порекомендуете?
Стандартный набор — MS SSAS + Excel 2010+ идеальный начальный вариант.
Согласно гартнеру, лучшей BI платвормой является Табло. По личномы опыту общения и сотрудничества с Кимбалл Групп — для OLAP Табло таки лучшее. Но, все равно, решение выбора нужно принимать под каждую задачу.
Согласно гартнеру, лучшей BI платвормой является Табло. По личномы опыту общения и сотрудничества с Кимбалл Групп — для OLAP Табло таки лучшее. Но, все равно, решение выбора нужно принимать под каждую задачу.
Некое общее замечание, в контексте статьи лучше бы разделить системы на следующие отдельные части:
1. Источники данных — как правило это учетные системы (1C, Axapta, OEBS, SAP etc), которые уже существуют.
2. ETL средства, с помощью которых данные из источников перегружаются в…
3. Хранилище (в узком смысле слова). Которым может быть как обычная реляционная БД, так и настоящая многомерка типа essbase (прошу прощения у поклонников olap options etc) и которое предоставляет данные…
4. ПО «генерации отчетов» (звучит не красиво, не нашел другого перевода reporting software), для получения отчетов конечными пользователями.
Смешивать п.3 и 4 ошибочно, например вы можете иметь хранилище на SAP BW, но получать из него отчеты средствами Oracle BI EE. Или получать данные из Oracle Hyperion Essbase с помощью Microsoft Excel.
Иногда п. 2-3 можно пропустить и забирать данные например с помощью Excel или BOBJ сразу из учетной системы. Но у такого подхода есть несколько минусов:
— При большом объеме данных в учетной системе и\или большом числе отчетов, отчеты могут «убить» учетную систему создав слишком большую нагрузку.
— Если данные лежат в нескольких источниках (1С, CRM, HR), то объединение данных «на лету» без хранилища или технологически\организационно сложно, или опять же может быть ресурсоемко (читай дорого по железу, или медленно по времени генерации отчетов). Но, повторюсь, чисто теоретически строить отчеты прямо на учетной системе можно.
Исходя из этого замечания, а также потребностей (количество пользователей, их подготовки, потребности в отчетах) а также возможностей компании (финансовых) выбирают пункты 2-4.
Поэтому ad-hoc, это прямая противоположность регламентным отчетам, которые имеют заранее установленную форму и не меняются.
Собственно ad-hoc отчеты можно делать прямо на OLAP источниках (если под OLAP автор понимает многомерные источники-«кубы»).
По поводу ценников: цена складывается не только из цен на лицензии, но и включает, например, и стоимость дальнейшей поддержки решения. Да, лицензии на Oracle BI действительно дороги в редакции EE, но для малых предприятий есть Standard Edition One с более умеренным ценником. А вот если сравнить количество резюме специалистов на hh.ru по QlikView и Oracle BI, то выяснится, что спецов по последнему в разы больше, чем по QlikView.
В заключении хотелось бы сказать, что если у заказчика нет собственной сильной команды, то лучше таки потратить время на встречи с интеграторами, чем внедрить «не то и не так». Если говорить о крупных (ТОП-5) интеграторах, то от запроса до контракта может пройти месяц, но очень редко год (не повезло). Длительность внедрения зависит от масштабов проекта и уже мало зависит от размера внедренца.
Отвечая на заголовок:
тогда, когда владельцы хотят иметь отчетность быстро, с прозрачными и проверяемыми цифрами и готовы за это платить. Все остальное — выбор софта, внедренцев и прочее, это уже детали, главное понять, что иногда ручками в excel долго, неточно, и в конечном счете «дорого» за счет не верно принятых на основе таких отчетов, решений.
1. Источники данных — как правило это учетные системы (1C, Axapta, OEBS, SAP etc), которые уже существуют.
2. ETL средства, с помощью которых данные из источников перегружаются в…
3. Хранилище (в узком смысле слова). Которым может быть как обычная реляционная БД, так и настоящая многомерка типа essbase (прошу прощения у поклонников olap options etc) и которое предоставляет данные…
4. ПО «генерации отчетов» (звучит не красиво, не нашел другого перевода reporting software), для получения отчетов конечными пользователями.
Смешивать п.3 и 4 ошибочно, например вы можете иметь хранилище на SAP BW, но получать из него отчеты средствами Oracle BI EE. Или получать данные из Oracle Hyperion Essbase с помощью Microsoft Excel.
Иногда п. 2-3 можно пропустить и забирать данные например с помощью Excel или BOBJ сразу из учетной системы. Но у такого подхода есть несколько минусов:
— При большом объеме данных в учетной системе и\или большом числе отчетов, отчеты могут «убить» учетную систему создав слишком большую нагрузку.
— Если данные лежат в нескольких источниках (1С, CRM, HR), то объединение данных «на лету» без хранилища или технологически\организационно сложно, или опять же может быть ресурсоемко (читай дорого по железу, или медленно по времени генерации отчетов). Но, повторюсь, чисто теоретически строить отчеты прямо на учетной системе можно.
Исходя из этого замечания, а также потребностей (количество пользователей, их подготовки, потребности в отчетах) а также возможностей компании (финансовых) выбирают пункты 2-4.
Избавление ИТ от ad-hoc или рождение OLAP. Начало проекта BI.Противопоставлять ad-hoc и OLAP по меньшей мере странно, это понятия из разных областей: ad-hoc это, упрощенно, отчет который является ответом на вопрос, который (вопрос) родился здесь и сейчас.
Поэтому ad-hoc, это прямая противоположность регламентным отчетам, которые имеют заранее установленную форму и не меняются.
Собственно ad-hoc отчеты можно делать прямо на OLAP источниках (если под OLAP автор понимает многомерные источники-«кубы»).
По поводу ценников: цена складывается не только из цен на лицензии, но и включает, например, и стоимость дальнейшей поддержки решения. Да, лицензии на Oracle BI действительно дороги в редакции EE, но для малых предприятий есть Standard Edition One с более умеренным ценником. А вот если сравнить количество резюме специалистов на hh.ru по QlikView и Oracle BI, то выяснится, что спецов по последнему в разы больше, чем по QlikView.
В заключении хотелось бы сказать, что если у заказчика нет собственной сильной команды, то лучше таки потратить время на встречи с интеграторами, чем внедрить «не то и не так». Если говорить о крупных (ТОП-5) интеграторах, то от запроса до контракта может пройти месяц, но очень редко год (не повезло). Длительность внедрения зависит от масштабов проекта и уже мало зависит от размера внедренца.
Отвечая на заголовок:
Когда пора задуматься о внедерении BI-системы?
тогда, когда владельцы хотят иметь отчетность быстро, с прозрачными и проверяемыми цифрами и готовы за это платить. Все остальное — выбор софта, внедренцев и прочее, это уже детали, главное понять, что иногда ручками в excel долго, неточно, и в конечном счете «дорого» за счет не верно принятых на основе таких отчетов, решений.
Спасибо за интересные замечания.
Соглашусь с вашим ответом на заголовок. Кратко и в точку.
А OLAP и ad-hoc я, собственно, и не хотел противопоставить. Скорее, неверно выразился, имея в виду, что избавляем ИТ от написания каждый раз запросов для получения ответов, а даем в руки аналитиков (пользователей) удобное средство для самостоятельного извлечения необходимых данных — OLAP-кубы.
Соглашусь с вашим ответом на заголовок. Кратко и в точку.
А OLAP и ad-hoc я, собственно, и не хотел противопоставить. Скорее, неверно выразился, имея в виду, что избавляем ИТ от написания каждый раз запросов для получения ответов, а даем в руки аналитиков (пользователей) удобное средство для самостоятельного извлечения необходимых данных — OLAP-кубы.
Пришёл в тему по поиску «Tableau», ибо заинтересовался, что же люди про него пишут. Столкнулся с ним вынужденно, ибо в компании, куда я пришёл работать, на этом продукте основана система хранения данных и BI, а мои задачи плотно с BI пересекаются (я психолог-исследователь — массовые опросы, user research и всё такое).
Удивился, что продукт, имеющий индекс версии 8.2 выглядит настолько сырым. Я сперва думал, что идеология продукта плохо усваивается мной, ибо я мыслю в духе IBM SPSS и других статистических пакетов (где строка — это случай и т.п.). Но оказалось, что разработчики баз данных тоже имеют с этой таблой какие-то сложности. Идиотизм, например, в том. что чтобы сделать разбивку между группами столбиков, приходится скриншот из Tableau нарезать в офисной программе на кусочки и раздвигать вручную.
Есть ли у кого-то опыт с QlikView? Там тоже всё плохо?
Удивился, что продукт, имеющий индекс версии 8.2 выглядит настолько сырым. Я сперва думал, что идеология продукта плохо усваивается мной, ибо я мыслю в духе IBM SPSS и других статистических пакетов (где строка — это случай и т.п.). Но оказалось, что разработчики баз данных тоже имеют с этой таблой какие-то сложности. Идиотизм, например, в том. что чтобы сделать разбивку между группами столбиков, приходится скриншот из Tableau нарезать в офисной программе на кусочки и раздвигать вручную.
Есть ли у кого-то опыт с QlikView? Там тоже всё плохо?
C QlikView, в плане оформления отчетов и вообще визуализации, все очень даже хорошо. Есть другие недостатки, например, цена. Еще, я вот привык к разработке в MS Visiual Studio, и после этого сложно перестроиться на QlikView, где все надо прописывать вручную, а не мышкой «набрасывать» элементы. Это, конечно, касается только разработки самой модели данных и механизмов ETL, создавать отчеты ничуть не сложнее, чем в других системах
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Когда пора задуматься о внедерении BI-системы?