Котятки🐱,
я как и многие, подписана на Junk Charts (https://junkcharts.typepad.com/).
Люблю всякие истории, когда аналитика "не справилась" - плохие диаграммы, ошибочные интерпретации, кул стори из серии "как аналитика налажала".
Есть в этом своего рода guilty pleasure.
Сегодня я на больничном, развлекаю себя всратыми иcториями и визуализациями:
1) Интерпретация данных в стиле "ошибка выжившего"
https://datavizblog.com/2023/07/02/historical-dataviz-survivorship-bias-and-getting-the-data-wrong/
2) Тред на реддите про ужасные визуализации: https://www.reddit.com/r/dataisugly/ - это пушка бомба, давно в него не заходила, но оторваться сегодня смогла только часа через 2
3) Книжечка Карен Фелан "Простите, я разрушил вашу компанию. Почему бизнес-консультанты – это проблема, а не решение" - прямо мой личный сорт героина. Я начала читать ее вчера, дошла до главы "Показатели-это средства, а не цели" и прямо залипла.
Она старенькая, есть на литрес, а обзор вот тут https://demakhin.livejournal.com/153565.html

Котятки🐱,
я по-прежнему на больничном, но вот уже-уже почти кажется вижу свет в конце этого коридора.
В общем, болеть летом не круто)
Из интересного, что сейчас почитываю - это всякие BCP и DRP - планы по непрерывности работы и восстановлению хранилищ.
В прошлом месяце я была увлечена всякими интересностями типа a-ля "резервная сборка" и гибридной стратегии с облачным восстановлением,
но опять вернулась к классике.
Базовый материальчик:
https://www.numberanalytics.com/blog/ultimate-guide-to-data-warehouse-disaster-recovery

​​Энтузиаст замедлил PostgreSQL в 42 000 раз с помощью 32 параметров — и ни одной строчки кода

"Один энтузиаст решил выяснить не как ускорить, а как максимально замедлить PostgreSQL.

И ему это удалось: производительность упала с 7082 транзакций в секунду до 0,016 TPS, то есть более чем в 42 000 раз.

Причем он не трогал железо, не удалял индексы и не вмешивался в код — все только через postgresql.conf."

Читать статью

Котятки, однажды я была на встрече, где прозвучало ‘почему вы даете рекомендации по конфигу БД, а не сделаете один универсальный конфиг на все БД у всех клиентов и во всех проектах сразу’🤦‍♀️ И как бы то, что подбор конфига зависит от того, как мы эксплуатируем эту БД в проекте, т.е. характер операций (а он был разный)- пришлось объяснять. После я поумнела и стала кидаться в скептиков не просто рекомендациями по конфигу, но и что почитать на Хабре. Теперь буду еще вот этой статьей кидаться👆, понравилось😊

Котятки🐱,
Сегодня к нам для легкого чтения забежал достаточно симпатичный материал, который раскрывает такую штуку, как Span of control. Грубо говоря, как примерно прикинуть, сколько report-интерфейсов приходится на одного менеджера, куда он должен смотреть и как взять процесс под контроль так, чтобы наш бедный менеджер в итоге не оказался похороненным под сотней дашиков.
Подход не новый, это часть проектирования отчетности, которая позволяет в итоге осознать, должен ли отчет быть в операционной системе, в BI или же уведомительно по почте расссылаться.
Линк:
https://theorgchart.com/span-of-control-calculation/

Котятки🐱,
В стеке Microsoft Dynamics есть приблуда, помогающая вести контроль и версионирование формул. Некий чекинг методологии расчета. Концепт и предлагаемая методология мне очень симпатичны, особенно если помозговать и применить их для BI-процессов.
При этом почти во всех BI-системах, в которых я работала, такой опции не предполагалось, и мы выстраивали свой процессинг управления методологией расчетов, «вынесенный за скобки».
Суповой набор был прост:
🏸Стратегия покрытия: все метрики подвергаются версионированию и контролю, или избранный пул, важный для предприятия. Это знаковый момент, который определяет, насколько контроль будет проникать своими щупальцами в безбрежный океан self-service, где пользователи сами себе ваяют дашборды
👽Data-стратегия: определяется, что является сутью процесса - только формулы (и мы в области около каталога данных) или формулы+поставляемые эталонные витрины к ним (и мы уже в datasets-on-demand)
🤖Раскрываем составляющие самих формул. В самом лайтовом случае объектом контроля - формула, в хардовом - мы ее на составляющие раскладывали, - по принципу, как это SAP хранит (операнды, операции, шаблоны функций, фильтры и настроенные данные)
🫂Процессы согласования /изменения формул: оч важно было сформулировать источники изменений и их авторизовать, будь то человек или законодательство. Тут уже, если достаточно усложнить подход, вываливается процесс, напоминающий data governance
🧠Ну и главное - где хранить артефакты. Конфлюэнс и всякие wiki были базой, затем пришли каталоги данных, а вот хранить methodology as a code мы учились, когда в наш домен притащилась концепция семантического слоя и всякие dbt . Были и странные варианты, - например, спец ПО для ведения формул. Оно применяется вообще для хранения формул продуктов, и лишь раз я видела, как туда еще и просто метрики запихнули.
🫀Автопересчет: максимально дорогая штука, которая сравнивает вариант расчета по старой формуле и по новой. Видела ее в одном банке, и до сих пор не могу понять, зачем, ведь покрытие и применимость по факту ограничены.
Что почитать:
-обзорка-микс про управление изменениями в BI, много референсных ссылок, каждый термин и процесс раскрываются: https://datacalculus.com/ru/хаб-знаний/бизнес-аналитика/стратегия-bi-и-управление/управление-изменениями-в-би-стратегии
-немного про классический formula management как процесс и ПО, относится в основном к производственным рецептам, но составляющие концепта объяснены https://www.tayanasolutions.com/formula-recipe-management/

Котятки🐱
На больничном в голову приходят странные мысли. Сегодня я поймала себя на том, что размышляю, насколько мои опыт как BI developer более болезненный, чем опыт BI-аналитиков.
Из главных факторов грусти могу выделить - лицензионную бытовуху, дописку всяких кастомных модулей (во всяких BI, которые я упорно называю ‘JS на ножках’) и мониторинг. Дописывание модулей и кастомный дата виз меня гнетет сильнее всего, ибо целиком занести нормальные практики разработки , с функциональной архитектурой, TDD, разработкой , тестированием, а также всякие арх контроли и надзоры, управление релизами и пр - не всегда получается.
Вы мне наваренное вернете, что я путаю, и BI developer не этим занимается, а вот so depends от размера организации и команды.
Почитать:
Старенькая статья, раскрывающая разницу в скиллах https://www.future-processing.com/blog/know-the-difference-between-a-bi-dev-and-a-bi-specialist-before-you-start-building-your-team/

Ну и с чего начались мои мысли: материал по BI experience для разных ролей. Я оч хочу такой же кастомный и по Qlikview: https://www.bibb.pro/post/improving-the-user-experience-of-a-bi-platform-in-a-corporate-environment

Котятки🐱,
Я сейчас пристально изучаю кейс ikea, чтобы понять, наследуют ли они сами в self-service BI самое главное когнитивное искажение, которое является краеугольным камнем их бизнеса - «люди придают больше ценности вещам, в создании которых они сами принимали участие».
Копаясь в теме, нахожу занятные смежные материалы.
Вот тут концепт дашборда для очень интересной ЦА - Self Serve Furniture Area management:
https://stephanietaniguchi.com/ikea-dashboard
Шаги проектирования и макетирования (=часть бизнес-анализа) разобраны очень подробно. Это прямо прекрасный паттерн-калька, как создавать отчетность для менеджмента, который занимается контроллингом и трансформацией на всяких смежных участках бизнес-процессов.

Котятки🐱,
Сегодня при подготовке к одному из демо, ко мне попал занятный материал про кросс-культурные особенности в анализе и датавизе, делюсь:
https://datacalculus.com/en/knowledge-hub/data-analytics/data-visualization/cross-cultural-considerations-in-visualization
Про цвета, направление текстов и время я обычно помню, а вот всякие культурно-когнитивные особенности я часто забываю))

Котятки🐱
Когда я как-то изучала иранскую практику построения дашбордов, меня поразило отсутствие тултипов и очень странный сторителлинг - он строился не на очевидной навигации, а по каким-то неявным правилам взаимосвязей.
Я была юна и неопытна, и списала это на то, что это были неудачные примеры. Вчера , читая материал про кросс-культурные особенности я прямо начала понимать, как работать с картой культурных различий.
Что посмотреть и почитать:
-Карта культурных различий - https://vividmaps.com/cultural-differences/ - было в сохраненках, из канала Рациональные числа
-Арабские особенности при работе с BI - вчера вчитывалась: https://www.bilytica.com/blog/business-intelligence/impact-of-cultural-factors-on-business-intelligence-analyst-in-saudi-arabia/
В целом у меня пока следующие выводы по секции BI:
-это тот случай, когда BI-инструмент навязывает бизнес-процесс, а не обратное.
-культурные особенности отражаются в основном на процессах за пределами инструмента, почти не влияют на характер работы с самим инструментом(логично)
-попытки создать ‘BI для <культура>’ я нашла пока только в виде рудиментов неудачных стартапов, пощупать не удалось.

Котятки,
Я люблю Qlik, но больше Sense, чем view.
Сейчас слежу за новыми обновлениями MCP -сервера от ChernovDev , пробую тихонько. Он основан на API Qlik Sense, и меня настиг флешбэк.
В общем, однажды я столкнулась с задачей обратного инжиниринга Qlikview,— в классическом кейсе, когда дашборды есть, а документации к ним нет. И надо вытянуть начинку —скрипты, объекты и пр, а также сразу обработать и обернуть в формат некой спецификации.
Попытки простучать QlikView Management Service API не дали ничего из-за авторизации, а менять уже сложившийся паттерн и протокол не хотелось. Ну и честно, я с SOAP мало работала.
Путем перебора мой выбор пал на Qlikview COM API, вызываемый из python:
-это медленно, однопоточно и однонаправленно, никакого параллелизма
-я не сразу привыкла к фишке с правами: при использовании COM-интерфейса система открывает приложение с дефолтными правами юзера, а мне нужны были админские. Пришлось шаманить с подхватыванием текущей сессии.
-это полностью закрывает задачу
-и это дешево, так как задача по сути одноразовая (один раз прошелся по текущим аппликам по списку, сделал и живи себе)
-благодаря питону можно наваять систему, которая учитывает двухуровневую загрузку данных при разработке спеки (помните, когда мы загрузчиком высасываем данные и кладем в qvd, а потом их уже подсовываем под основной аппликейшн). Ну и сам COM-интерфейс может чуть больше, чем задекларировано, надо его только чуть поковырять.
Что хочу сказать?
Доки просто не очевидны, они тут: https://help.qlik.com/en-US/qlikview-developer/May2024/Content/QV_HelpSites/APIsAndSDKs.htm
и спасибо AI , который как раз послужил тем мостиком, который объяснил буквально на пальцах, что с этим делать и как пользоваться.

Котятки🐱,
Неделю назад при работе с датасетом в AI меня поставила в тупик достаточно нетривиальная проблема: он читал и пытался делать аналитику на ‘мусорных’ столбцах -guid, нумерация строк, аудиторский след, технические отметки времени, суррогатные ключи. И поле row_number, которое у меня вылезло из оконной функции.
Я была сильно удивлена - ибо заранее скормила ему набор метаданных (‘сущность’ в копилот) и объяснила, как с ним работать на уровне вшитых промтов - то есть, я полагала, что AI-агент держит контекст на каждое значимое поле. Почему ему вдруг понравились другие поля хз, я была озадачена. В итоге в ТЗ на витрину все незначимые столбцы убраны.
Ну и сегодня Гугл навел меня на старенькую статью про графические датасеты:
https://www.aiweirdness.com/when-data-is-messy-20-07-03/
Проводя параллели, если в обучении модели, которая под капотом моего агента, был фактор ‘равенства’ всех столбцов в датасете, то поведение становится очевидным, как бы я не задавала доп контекст значимым полям. Поможет или их исключение совсем, или доп контекст с ограничением на использование.
P.S.
Будем честны, с людьми такой проблемы не возникает. Ни одному BI-разработчику на моей памяти использовать мусор в датасете в голову не приходило, это некая очевидная вещь, гигиенический минимум профессионализма в нашей профессии. И она же сделала меня ‘небрежной’ в датасете. Расслабилась, короче;)
Всем хороших выходных!

Котятки🐱,
Вчера у меня была интересная дискуссия по моей традиционной теме - self-service BI.
Я готовилась, почитала хорошую статейку- в ней разобраны 2 метода развития BI с традиционным внедрением и через self-service, разобраны факторы влияния, приведена казуальная петля (зависимость факторов друг от друга) и введена модель ‘организационного принятия’.
В общем, занимательное чтиво, но не в стиле ‘развлеки себя на 5 минут’, надо прямо вчитываться:
https://www.sciencedirect.com/science/article/pii/S2772503023000300
P.S. Завтра будет пост-размышление на тему создания self-service BI-комьюнити : почему одни умирают, другие выживают, и какие факторы играют роль, а какие ‘мы думаем, что играют роль ‘, - а на самом деле пшик.

Котятки,
я обещала пост-размышление по self-service BI, и вот он.
Что на него повлияло:
-знакомство со связкой Power BI + Copilot – теперь Copilot может сам строить дашборды, с помощью ТЗ, которое мы формулируем на естественном языке.
-Qlik Sence MCP сервер – новая находка.
-статья с архетипами внедрения Self service BI
Читать
Для лиги лени: в связи с неминуемым встраиванием AI-агентов в BI могут меняться и факторы успеха Self-service BI, и архетипы/сценарии SSBI. Может измениться не только «стоимость» успеха, но и что считать «успехом».

Котятки,
Я уже не первый раз сотрудничаю с нишевой школой аналитики Changellenge >> Education. Настало время рассказать про их флагманский курс "Аналитик данных":

- программа составлена аналитиками-практиками и охватывает все ключевые компетенции, которые нужны аналитикам в бизнесе
- обучение проходит в формате реальных групповых кейсов от компаний уровня Т-Банк, РЖД и Ozon, что поможет вам освоить работу с данными с нуля
- курс подойдет для специалистов разных направлений, которые хотят развить свои навыки, получить повышение и успешнее продвигать свои идеи руководителям
-курс в целом очертит границы работы аналитика и современный инструментарий, поможет легко войти в self-service BI, если он в вашей компании уже есть, а также осознать, как ставить ТЗ команде IT для поставки датасетов.

Про сложности в начале новой карьеры оговорюсь: за счет опыта работы над реальными кейсами компаний-партнеров - вы будете презентабельно выглядеть на рынке, даже если у вас не будет релевантных строчек в резюме.

Остальные преимущества школы можно почитать тут, а по промокоду “ДАШБОРДЕЦ” до 22 августа будет действовать скидка 25 000р

Котятки😻,
Наверное, некоторые вспомнят это видео - демку агента AI в Power BI?
https://youtu.be/wr__6tM5U6I?si=Jn5VkX9STmVB0cfd
Это выглядело как магия вне хогвартса.
Сейчас Copilot в PBI подкачался, хоть и не позволяет нам поменять модель под капотом:
-может полностью обеспечить тебе data discovery в режиме диалога (как это)
-создаст тебе готовый дашборд и объяснит твои данные
-склонирует тебе, что ты пожелаешь (но сначала ответит, что не может, но если правильно попросить, то может)
-он даст наконец-то расширенную диагностику.
Из минусов я себе выделила: ограниченный набор визуализаций (как в API), невозможность кастомизировать оформление по команде, и, наверное, главный — это своя отдельная область подготовки модели для использования в ИИ. То есть вместо привычных в Copilot Тем и сущностей, здесь все еще предлагаются ‘Проверенные ответы’ и добавление инструкций.
Оч надеюсь, что это отомрет, и просто добавят функцию ‘Спросить агента’, как уже сделано в Power Point.

Собственно, мои размышления о self-service и артефактах к нему пока концентрируются на уровне 1 и 2 из вот этого видео про уровни Self-service, кои гипотетически реализуемы в Power BI, которым я и заканчиваю этот вечер:
https://youtu.be/BdG0a6tQ96M?si=2UZD6ZTABCpKUjuX
Всех с пятничкой 😍

Котятки🐱,
В субботу у меня был интересный разговор, и мы с одним инженером затронули тему, какие прикладные задачи в сфере BI можно поручить AI, с учетом их ограничений (неидемпотентность, косяки в распознавании намерений, галлюцинации, проблемы проброса данных в исполняемую среду и пр)?
Что ж, вот общая статья с вариантами, что поручить AI в сфере BI:
https://hackernoon.com/the-role-of-business-intelligence-in-ai

Кроме data discovery и генерации дашбордов, об артефактах к которым я уже писала подробно, с табличкой, нравится: тема с персонализацией, которая постепенно идет на смену ‘единой версии правды’(последнее всё больше топится на уровень датасетов)
Что не нравится: трансформация Data prep в ‘AI data prep’. Щупала уже продукты, которые пытаются себя так позиционировать, пока степень вовлечения человека в них очень высокая, нельзя сказать, что мы это делегируем агенту.