Понятие самообслуживание можно растягивать как угодно. Но если мы говорим о грамотном в бизнес-тематике человеке (не программисте и не ИТ-шнике), то порог вхождения в Qlik значительно ниже, чем в PowerBI. Очевидно, что учиться нужно и тому и другому. Но трудозатраты- совершенно различные

Поэтому вне зависимости от того, как описывать самообслуживание, если мы рассматриваем его как возможность квалифицированно решать задачи любого спектра сложности, то достижимость (понятность) таких решений на Qlik оказывается дешевле

Для задач каждого спектра сложности есть отдельные ну или универсальные (в зависимости от компании) люди...
Не должен каждый в компании разбираться в гвоздях и шурупах...

Ну так в Qlik тоже в базе 2 языка: скрипт и Set Analysis и они разные...

1. Люди привязываются к инструментам - синдром утенка. Пересаживать с PBI на qlik например довольно непростое иногда занятие. Когда человек в одной системе может все а в другой не может (по причине отсуствия опыта) и не до конца принимает подход другой системы ему реально тяжело.
2. Люди всегда продвигают свои решения. Например традиционно делают хранилку в виде аналитической СУБД (ну а вдруг бигдата) + Табло. Даже если проект с 1 млн транзакций в год. То же самое и по другим инструментам - знает питон? Выбирает инструменты где бы он пригодился.

А реально если с нуля запустить человека PBI учить и Qlik я уверен что в Qlik человек гораздо быстрее станет "мидлом" который будет решать задачи.

Имелась в виду такая диаграмма - несколько разных мер для разных продуктов  в динамике по разным временным измерениям

3. Если у человека есть концепция "нам нужно хранилище" опять же его никак не переубедишь что можно без него. Ну хочется иногда 6 колес а не 4 на машине

+1

+1
Главное,  чтобы он понимал - для чего именно ему хранилище. А не просто пихал везде как единственную кажущейся ему известной технологию

да. У людей мания "мы сделаем ЕДИНОЕ хранилище для всего". забудьте сразу про это мой вам совет

никаких ЕДИНЫХ хранилищ не будет, не сможете быстро потоки настраивать. Не важно 2 у вас разработчиков под nifi или 20

Есть категория задач не для Qlik. Например среднедневные остатки считать не удобно. можно, но неудобно. проще в другом месте делать

так же как и в PBI это не удобно и в Tableau

В том-то и фишка,  что синтаксически функции в Qlik практически одинаковы. И на уровне таблиц (скрипт) функции работают в логике SQL и любого другого процедурного языка. Но используя их же на уровне визуализации - можно получить ещё большую степень гибкости. Очевидно, что для этого нужно научиться понимать то, как эти же функции работают на множестве значений. Схожесть синтаксиса позволяет переносить расчёты из слоя скрипта в визуальный слой и наоборот, что лишь расширяет гибкость

+200

Согласен с джедаем, я вообще за low code. И qlik тоже виноват)

Точнее, они могут быть оооочень большими и при этом их даже может быть не одно )))
Но я не видел ни одного заказчика удовлетвореного со стороны бизнеса своим хранилищем - в понимании бизнеса там всегда чего-то не хватает и всегда что-то вовремя не найти )))

Но если выбирать из 2 зол

Да, я не против хранилищ. Qlik решает не все задачи, но есть категория запросов которая по скорости просто не будет решатся хранилищами. Особенно с корпоративностью повышенной - пока ЗНИ (ЧТЗ, ТЗ, спеки) напишут, все согласуют и тп бизнесу уже будет все равно решена задача или нет

А бизнесу реакция нужна мнгновенная - либо сейчас либо затоптали