Как стать автором
Обновить

Комментарии 13

Интересная статья, хочется пожелать только удачи. Только вот вопрос, а self-hosted BI как класс не вымрет ли в ближайшее время, не заменят его облачные движки? Тот же Power BI отлично отдается из облака и идет как стандарт для тех, кто использует Azure и его сервисы. Будет ли облако Visiology? Нужно ли оно рынку? Чем вы тогда лучше Yandex DataLens, например?

Для малого бизнеса облако — отличный вариант, и действительно, многие BI-вендоры активно переходят к SaaS модели (или изначально ее выбирают, как Yandex DataLens). Но крупные компании абсолютно не готовы отдавать свои чувствительные данные в облака. И это характерно не только для России — вот свежий обзор от BARC Research, из которого видно, что по всему миру облачной аналитике сами корпоративные пользователи придают гораздо меньше значения, чем вендоры — http://barc-research.com/research/bi-trend-monitor/. Поскольку наш целевой сегмент — это именно большие компании, то и облачную версию Visiology мы пока делать не планируем, просто нет спроса.


Оговорюсь, что это все касается публичных облачных сервисов, SaaS. Облако в режиме IaaS, конечно, многие применяют. У нас уже сейчас больше половины пилотных проектов живут в Yandex Compute Cloud.

Во всех подобных статьях единственный вопрос — кто оплачивал этот праздник жизни?

Если вопрос про то, на какие средства велась разработка платформы до того, как пошли продажи, то тут никакого секрета нет. В Visiology инвестировала компания Polymedia, из которой мы и вышли изначально.

виртуальный аналитик ViTalk
может лучше сразу Vitalik?

Некоторые так его называют, он, вроде, не обижается. Но кто знает, что там в "голове" у этого искусственного интеллекта :)

Хороший пример «достаточно хорошего» (неидеального) решения, которое совершенствуется по мере взросления. Но были конечно и необязательные грабли))
Было бы интересно послушать, чем не устроил ClickHouse. Он же открытый — бери и дорабатывай.
Мы в рамках разработки highload продукта (не BI) задаемся вопросом, в какой момент надо перестать велосипедить свою аналитику и идти к вам. С одной стороны понимаешь, что дать базовый функционал можешь, тем более у нас востребованы схожие технические компетенции, что и у вас. Но в какой момент остановиться?)

Тут, как мне кажется, есть две составляющие ответа на этот вопрос:


  1. Что выгоднее? Если в вашем продукте просто есть несколько дашбордов, которые редко меняются, обычно лучше сделать их просто вручную in-house. А если объем отчетности значительный, она изменяется еженедельно и, самое главное, надо дать конечным пользователям возможность самим настраивать дашборды и отчеты, то надо серьезно задуматься об использовании стороннего аналитического решения — не обязательно нашего, OEM и White label варианты лицензирования есть почти у всех BI вендоров, а где-то и open-source решений будет достаточно (типа Grafana или Superset). Тут уже надо аккуратно посчитать трудозатраты и "TCO" для всех вариантов.
  2. Риски и контроль. Как я писал в статье, любая внешняя зависимость — это потенциальные риски для проекта. Что будет, если поставщик решит изменить схему лицензирования? Что если его фокус развития продукта разойдется с вашими потребностями? Насколько хорошо вы лично знаете команду продукта и доверяете ей? Тут главное, такой список рисков составить и учитывать его при принятии окончательного решения.

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

влезу со своими 5 копейками, по опыту внедрений BI, скорость внедрения можно увеличить на порядок если:
— оцифровать и загнать в базу все справочники живущие сейчас на бумаге, в экселе, в головах, вообще пока не существующие, но точно нужные для аналитики
— сразу иметь шаблон на самые главные аналитические отчеты и kpi и заранее знать все источники данных для них, причем и внутренние и внешние
— озаботиться заранее доступом ко всем источникам, особенно потери времени характерны на доступах к внешним источникам, аля база бюро кредитных историй и т.п
— можно заранее прикинуть связи разных источников между собой по общим дименшенам (справочникам) например как матчить наименования товаров из внутренней срм, из базы производства, из базы маркетинговых компаний и из внешнего отчета по долям рынка. Тут может оказаться что сперва надо начать с МДМ решения, ну или как минимум придется мини-МДМ городить в рамках BI

ну пока хватит, а то писать долго можно…

Как мне всерьез воспринимать вас, если у вас сайт на тильде.

По восприятию — вам решать, но все наши сайты мы несколько лет назад перевели на тильду и супер довольны результатом. Раньше у нас для сайтов использовался целый ассортимент технологий от ASP.NET до Битрикса, и главная проблема была в том, что для внесения изменений постоянно приходилось отвлекать разработчиков от основных задач (которых у них выше крыши). Сейчас 80% задач по поддержке сайта закрываются маркетологами самостоятельно, а на оставшиеся привлекаем фрилансеров “универсалов”. Конечно, иногда тильда ограничивает полет фантазии, но тут уж ничего не поделать, это плата за простоту поддержки.

Очень было бы интересно почитать про ViQube, как он работает и на чем написан. Спасибо.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий