Comments 15

Доброго дня. Честно больше похоже на рекламу. Если же предметно:


  1. Спрос на коробочные bi решения ни куда не снижается, а скорее наоборот растет. А так же обычные диаграммы, бублики так же востребованы. Скажу так, что нужно «уметь готовить» в решениях мастодонтов bi. Очевидный минус это не много компаний могут себе позволить комплексное решение от вендора.
  2. Разработав свою систему bi и начав ее продавать вы лишь добавляете новый продукт в линейке со своими архитектурными ограничениями. А так же с ограничениями в разработке визуализаций.
  3. Реализовать универсальный инструмент bi который из коробки удовлетворит все потребности заказчика без участия разработчиков и напильника это утопия. Всегда найдется кейс графика под который у вас нет или он не подходит по каким либо причинам.
  4. Для меня лично сформировалось виденье, что не нужно стремится строить всеобъемлющий универсальный инструмент включающий в себя все и вся, как не смотри это будет коробка ограниченная виденьем архитектора, а так же писать каждый раз реализацию с нуля трудозатратно, дорого. Ключевой направление это все же работа с данными без привязки к системам визуализации, универсальное, понятное хранилище и легко поддерживаемый транспорт. А от инструментов бизнеса требуется легкость интеграции с этим данными. А так же предопределенный набор шаблонов. То есть в хранилище должны быть данные без всяких крутых инструментов понятные бизнесу, пусть хоть в экселе смотрят если нужно. Новые источники данных легко добавляются. А инструменты визуализации так же легко «насаживаются» на эти данные и несколькими кликами мы получаем например аналитические панели. Или график загрузки цехов.
    Итого, нужно как всегда подготовить данные, а дальше подготовить библиотеку кейсов с шаблонами и каждый уважаемый себя бизнес мог легко выбрать из библиотеки свою панель для анализа.:)
Борис, спасибо за обстоятельный комментарий, со многими пунктами согласен, правда, с некоторыми оговорками.
«Спрос на коробочные bi решения ни куда не снижается, а скорее наоборот растет.»

Разумеется растет, как и в целом растет рынок. Я ни коим образом не умаляю востребованность вендорских решений. Для многих компаний и задач их будет более чем достаточно. Однако когда речь идет о комплексном решении, где вдобавок порой нужно еще реализовать то, что никто из BI-вендоров для лишь одного заказчика добавлять не будет, возникают проблемы. Главная — ничего с этим не поделаешь, ибо если мы отбрасываем opensource, то свободного пространства для кастомизации у заказчика (и даже, к сожалению, у внедренца) практически нет. Если же opensource нас больше не пугает, то с высокой вероятностью на первом же повороте врезаемся в риск под леденящим душу названием «поддержка».

«А так же обычные диаграммы, бублики так же востребованы.»

Не совсем… Вернее, если смотреть на это лишь как на инструмент визуализации, а не анализа, то вы правы. Даже приведенный мной в статье дэшборд это иллюстрирует, там чистая классика. Однако суть была не в этом. Есть инструменты визуализации, которые позволяют гораздо быстрее понять, что не так (или, наоборот, что все идет как надо). Они интерактивные, интуитивные, и, главное (тут можно смахнуть скупую слезу) — кастомные. Их нет в «коробке», и чтобы их добавить, недостаточно знать, как устроена коробка. Вендор имеет свой «roadmap» и в большинстве случаев один заказчик с каким-то (по мнению вендора) экзотическим требованием) в расчет не берется. И не только мы, как внедренцы, сталкиваемся с этой проблемой, уверен, вы тоже, с высокой долей вероятности, «упирались» в ограничения платформенных решений.

«Разработав свою систему bi и начав ее продавать, вы лишь добавляете новый продукт в линейке со своими архитектурными ограничениями. А так же с ограничениями в разработке визуализаций.»

Не согласен. Архитектурные ограничения — это всегда хорошо, иначе все рано или поздно развалится. Я планирую описать архитектуру в следующем посте здесь же на хабре, там уже будет удобно поговорить по «конкретике», пока предлагаю поставить этот вопрос «на паузу».

«Реализовать универсальный инструмент bi, который из коробки удовлетворит все потребности заказчика без участия разработчиков и напильника это утопия. Всегда найдется кейс графика под который у вас нет или он не подходит по каким либо причинам.»

А здесь согласен. Однако, мы — системный интегратор и автоматизируем бизнес-процессы, у нас много «напильников», но мы, с одной стороны, не хотим их коллекционировать, а, с другой, обязаны довести проект до успешного завершения. А бывают проекты, как говорится, «типовые». У нас так и получилось — фреймворк, куда можно добавлять новые функции. Для типовых задач — типовые инструменты, для нетиповых — добавление новых модулей.

«Для меня лично сформировалось виденье, что не нужно стремится строить всеобъемлющий универсальный инструмент, включающий в себя все и вся, как не смотри — это будет коробка, ограниченная виденьем архитектора».

Мы, собственно, и не пытаемся сделать монолит, я бы сказал, напротив, все дополнительные компоненты имеют архитектурно слабую связанность и легко подключаются и отключаются, как детали в конструкторе. Однако после подключения легко настроить потоки данных от них к BI-ядру. Часть этих потоков доступна из коробки, часть конфигурируется под конкретные задачи в рамках создания отчетов либо контрольных панелей. Хранилище — тоже не «черный ящик» (в отличие от некоторых BI-систем, на которые я не буду показывать пальцем), а вполне стандартная OLAP-схема с понятной структурой, к которой, разумеется, можно подключить тот же excel. Я вообще в целом по 4-му пункту не вижу никаких архитектурных противоречий, если уточните, при прочтении какой части статьи у вас оно возникло, дайте знать. Хорошего дня :)

Wrike задачник всемогущий с возможностью интеграции с чем угодно по рест апи, и визуально делает хоть кан бан хоть гант, общий тайм лайн и так далее. И в BI как я понимаю нужна только статистика по проектам занятых часов/всего часов. Он же и показывает загрузку

Доброго времени суток. У нас задачи бывают не только автоматизировать совместную работу и управление проектами, они несколько шире. И в BI нужно не только статистику по проектам, это может быть все, что угодно, от разного рода верхнеуровневых KPI, финансовых и производственных показателей, до статистических, вычисляемых и спрогнозированных показателей по совершенно различным областям деятельности организации.

На мой взгляд вы почему-то решили, что ситуационный центр и мониторинг можно назвать BI системой.
Ещё интересно посмотреть на ваше дерево с Гантом — из описания мало что понятно.
Интересно чего вам не хватило в функционале лидеров BI рынка для написания кастомного визуала?

Добрый день. Не совсем так. BI-модуль (в классическом его понимании) у нас в проектах ситуационных центров с точки зрения целевого пользователя — одна из подсистем. Если Вы в теме СЦ, то, наверняка, понимаете специфику. Касаемо Ганта, спасибо за идею, попробуем добавить пару скринов в статью. А вот последний вопрос тянет на отдельную статью — если вкратце — много чего не хватило, как с точки зрения функциональных возможностей, так и в плане внешнего вида. В статье про архитектуру постараюсь коснуться и этого вопроса тоже.

Спасибо за ответ. Интересно будеть почитать о функциональных ограничениях и внешнем виде. Если будет возможность, то хотелось бы увидеть сравнение с Tableau Extensions и Power BI Custom Visuals (или с аналогичными решениями от qlik, yellowfin и т.п.)

А чем был плох Apache Superset в качестве базы для дальнейших разработок? Вообще анализа существующих решений не приведено, нет информации об используемом стеке технологий. Есть лишь «Мы — Ух! Три месяца и в продакшн! При наличии денег у заказчика любая фирма будет согласна писать для них что угодно, включая BI.
Все верно, это лишь первая часть, больше общая информация, без погружения в технические детали. Про архитектуру и технологии — чуть позже. Там уже предлагаю обсуждать детально технические аспекты и архитектурные решения. Если интересно — добавляйте в закладки, чтобы не пропустить. :)
И да, касаемо Superset добавлю — мы его рассматривали и действительно детально изучали. Это интересно и, вероятно, имеет некий потенциал, но, на наш взгляд — на сегодня это довольно рискованно, полагаю, не нужно объяснять — почему. Надо подождать пару лет, дальше посмотрим.

А можете чуть подробнее описать риски superset? К сожалению, мне недостаточно очевидно =(

Основные причины — проекту чуть более 3-х лет, он до сих пор в инкубаторе Apache и еще не одобрен ASF, он при тестировании показался нам сыроватым, плюс заметно отсутствие, скажем так, целостности решения. Даже если взглянуть на код фронтэнда — половина на ts, половина на js (причем без аннотаций типов). Как что-то добавить не форкая проект — непонятно, фиксить что-то есс-но только через пулл реквесты, что долго. Всегда есть риск, что при обновлении версии что-то упадет, что добавляет нашим тестировщикам работы, а ПМ-ам и архитекторам — сложности в планировании проектов. Какой-то четкой дорожной карты у них я не нашел, когда и что они решат добавить или изменить — неясно. И все бы ничего, если бы это был набор небольших библиотек, но superset позиционируется как «fully fledged web BI applicaton». В общем, нам показалось, что его в качестве платформы использовать не получится. Только если брать и использовать «как есть», для довольно узкого круга задач.
Цена сильно зависит от масштаба предприятия, набора задач, специфики процессов. Напишите на почту, расскажите, что вам нужно, и мы сделаем прогноз: bi_jet@jet.su
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
1991
Location
Россия
Website
jet.su
Employees
1,001–5,000 employees
Registered