и то что фильтр накладывается на всю модель и все листы, тоже

Это да )

Кстати, есть очень интересная тема - проводить обучение до того как задание техническое написано или до того как работы сделаны. Не демонстрацию а прямо обучение. Плюсы такие - во-первых разработчику понятно становится какие люди будут в организации а это может скорректировать задание. Например нет пользователей которые не занимаются data discovery и на обучении понятно что этот подход не зайдет нет смысла делать сложные приложения где пользователь должен понимать как связаны объекты между собой и к каким последствиям приводит например установка фильтра

+1. Кстати, да.

Ну это логично. Сначала научиться водить, а потом уже выбирать машину )

Оччень спорно )))

Чаще наоборот бывает

Ну да, согласен, формулировку не очень подобрал. Имеется в виду не правила выучить и навыки, а понимание сформировать, как именно ты будешь ездить )

Есть какой нибудь интегратор "зеленый ку" например. У него есть допустим 3 решения "коробочных" для розницы типа Продажи, Склад и CRM. Он их продает сначала и внедряет - быстро и дешево

потом обучение)

И машину проще поменять )))

А потом несколько лет допиливает под конкретного заказчика.

Профит )

ну так тоже плюс - есть чем заняться

У меня есть такое наблюдение: внедрение BI обязательно надо начинать с пилотного проекта, чтобы завоевать доверие к системе. Пилотный проект ограничивается узким перечнем задач для одного отдела. Т.к. в компании уже существует своя аналитика на 1С/Excel/Педальной тяге, которая складывалась годами и имеет миллион нюансов - нет смысла стараться сразу ее забустить с помощью BI. Закопаешься в нюансах, и потом все равно скажут "мне в экселе удобнее".

Вообще на первое время стоит рассматривать BI как дополнение к существующей аналитике, а не ее замену. Что делать в пилотном проекте? То, что не получается делать текущим инструментом аналитики. Лучше всего - автоматизировать поиск точек роста в бизнесе, причем на уровне "Нажал кнопку - увидел точки". Переделывать отчеты, которые сейчас собираются руками - в пилоте часто это не нужно. Вот плачет начальник отдела, каждый месяц тратит день на создание отчета пред акционерами - лютой сводной таблички с прибабахами. Казалось бы, насущная потребность! Но если мы ее будем закрывать, то угрохаем n десятков часов работы, результатом которого станет что у руководителя отдела освободилось 8 рабочих часов в месяц. Какой рост эффективности это даст? Даст ли вообще?

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

Дальше, заказчик начинает пользоваться нашей фичей в добавок к имеющейся аналитике, начинает доверять нам и Qlik, и дальше мы перетягиваем его все сильнее в BI-сети)

Анна, спасибо за информацию!)

И тут мы приходим к тому, что зачастую для поиска точек роста достаточно просто отсортировать существующую таблицу )

Ну, в наших проектах такого не попадалось) Часто нужно логику с доп.расчетами в скрипте сделать

Я к тому, что опять получается не проект по внедрению инструмента, а по выводу на новый уровень мышления. А если нет, то нужная табличка наверняка уже есть ) Хотя конечно бывает, что существуют объективные технические (ресурсные) ограничения, которые не позволяют реализовать некоторые задумки без нового инструмента.

Точки роста для средних и больших компаний - это больше про управленческий и стратегический консалтинг. BI там беспомощны. А вот в мелких компаниях это играет роль.