Визуализация данных *

1 Операционная надежность (надежность операций, процессов, функций)

Регулятор (ЦентоБанк) уже несколько лет ведет «крестовый поход» под знаменем «Операционная надёжность»: выпускает «одноименные» Положения (850-П / 787-П, 779-П), Стандарты Банка России (СТО БР БФБО-1.5-2023), ГОСТы (ГОСТ 57580.3 / 57580.4, с его участием), а также методические рекомендации (18-МР) и формы обязательной отчетности по «Операционной надёжности» (operational resilience).

Под знаменем «Операционная надёжность» - делается попытка «скрестить» (где-то «ежа с ужом», но сама идея достойная) бизнес-архитектуру (архитектуру процессов, как технологических, так и бизнес – хотя разделение их не понятное), EA (enterprise architecture) / ИТ-архитектуру, ITSM (CMDB, управление инцидентами, в том числе, инцидентами операционной надежности), информационную безопасность (вкл. ГОСТ 57580.1 / 57580.2), надежность / отказоустойчивость / ОНиВД, риск-менеджмент (опер-риски, 716-П), импортозамещение (ФТК). Подобный «единый узел» - это проекции «одного и того же» на разные плоскости (EA, BPM, GRC, ИБ, ITIL и др.) с разными словарями / концепциями, поэтому формализовать его видимо равносильно притчи / сценарию «Вавилонская башня». Однако «язык графа» сближает такое восприятие и снижает барьер сложности.

Далее будем говорить только о Форме 0409072 (далее ф072) — «Сведения о показателях операционной надёжности кредитной организации и применяемых ею информационных технологиях при осуществлении банковской деятельности и деятельности в сфере финансовых рынков», точнее о ее части – шифре \ шифровке архитектуры предприятия. «Операционная надёжность» - это всего лишь контекст. 

Начало тут

По своей сути, каждая новая экселька это отдельный мирок. Я бы даже выразился "некая от отдельная приложуха"! И чтобы она была живой, понятной не только тебе и действительно стала полезным инструментом ты должен понять, а на какой вопрос она отвечает?

Это не совсем ТЗ. Тех.задание (пусть и самому себе) ты будешь продумывать в голове на следующем шаге. А это чуть более глубокий вопрос: какую именно потребность ты закроешь в самом конце, проделав кучу работы, всё собрав, подсчитав и отформатировав?

Это заключительная часть серии «23 фичи Luxms BI, которыми мы гордимся». В первой мы говорили о платформенности и архитектуре, о фундаменте системы. Во второй – о классическом BI-функционале. В третьей – о возможностях, выходящих за рамки привычной бизнес-аналитики.

А сегодня расскажем о том, что принципиально отличает Luxms BI от аналогов, о фичах, которых нет в других BI-системах. Эти особенности – прямое следствие нашей экспертизы и особенных подходов к архитектуре, и они часто становятся решающим аргументом для тех, кто выбирает платформу для серьезных, долгосрочных проектов.

Привет, Хабр!  Меня зовут Юлианна Валиуллина и я главный эксперт по развитию BI в банке Уралсиб.

Для начала немного о нас: мы практикуем self-service подход, в банке более 200 разработчиков, из них 150 имеют опубликованные дашборды, остальные делают аналитику для себя. Более 1200 опубликованных дашбордов, MAU около 1500. Большая часть дашбордов в нашем банке работает в spider(extract) режиме, доля direct 15-20%.

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

Люди добрые, не ругайте вы меня почем зря за предположение, что ваши Эксель таблички ненормальные, статью до конца не дочитав... Но, к сожалению и с вероятностью 90%, они действительно таковы.

Эта статья всего лишь крик души специалиста, который устал. Дико устал. Чудовищно устал от того, что ему каждый день приходится смотреть на десятки ужасных таблиц в его любимейшем Экселе (ну и Гугл доксе заодно). Ещё больше его удручает, что даже на курсах по повышению грамотности экселя об элементарных вещах сказать забывают. Как результат – текущие от боли глаза. Ну почему?! Почему такие простые вещи никто нигде не рассказывает?!

Добрый человек, не поленись. Дочитай. И твои таблицы станут на порядок лучше и понятнее не только для тебя, но и для всех окружающих!

ИИ-ассистенты внедряются в привычные таблицы вроде Google Sheets и Excel. Многие скажут, что такие «игрушки» никому не нужны. Но это приближает электронные таблицы к инструментам бизнес-аналитики, BI-платформам.

Типовые сценарии на базе StarRocks + DeepSeek. DeepSeek: генерация качественных эмбеддингов и ответов, StarRocks: высокоэффективный векторный поиск и хранение.Вместе они образуют основу для точных и масштабируемых AI‑решений.

Имеются разные способы повышения эффективности компаний. Некоторые компании ставят во главу угла только совершенствование операционных процессов путем их оптимизации, применения более современных орудий труда или использования новых технологий для повышения производительности труда. Другие компании не довольствуются повышению эффективности своей деятельности только за счет совершенствования операционных процессов, а стараются совершенствовать также и процессы управления. Одним из таких ярких примеров повышения эффективности деятельности за счет совершенствования процессов управления является компания Тойота, которая в 50-е годы ХХ века начала применять методику Канбан и получила от этого большие преимущества и значительно повысила свою конкурентоспособность.

В статье «Система канбан в бережливом производстве: принципы и внедрение», см. сайт: https://sky.pro/wiki/management/sistema-kanban-v-berezhlivom-proizvodstve-printsipy-i-vnedrenie/, так описывается методика Канбан:

«Когда инженер Toyota Тайити Оно посетил американские супермаркеты и был впечатлен их системой пополнения запасов. Он заметил, что товары пополняются только после того, как покупатели забирают их с полок — это было противоположностью традиционному "выталкивающему" производству. Вернувшись в Toyota, Оно адаптировал эту концепцию для производственной среды.

К 1970-м годам система канбан стала неотъемлемой частью Toyota Production System (TPS), которая впоследствии трансформировалась в известную миру философию бережливого производства (Lean Manufacturing). В отличие от традиционного прогнозного планирования, канбан основывается на реальном потреблении, что позволяет значительно сократить запасы и минимизировать перепроизводство».

В 1998 году NASA потеряла свой космический аппарат Mars Climate Orbiter, стоимостью 328 млн долларов из-за несогласованности команд, работавших над его созданием. Летательный аппарат прошел над поверхностью Марса на высоте всего 57 км вместо расчетных 110 км и был уничтожен атмосферой планеты. Почти двукратное отклонение было обусловлено ошибкой в программном обеспечении: команды по тяге двигателя в программном обеспечении аппарата использовали единицу измерения силы ньютон, в то время как программное обеспечение на Земле, которое создавало эти команды, использовало британскую единицу измерения (фунт-сила).

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

В статье расскажу, как превратить разрозненные компоненты в систему мониторинга, и как она помогла нам сохранить работоспособность моделей.

За десять лет практики в аналитике я часто сталкивался с ситуацией, когда аналитическая функция не даёт измеримого бизнес-результата. При этом от неё обычно ждут инсайтов, которые дают иксы прироста — иногда даже сами по себе, без внедрения.

Проблема неприятная и распространённая. Она решается не просто и не быстро, но для построения устойчивого бизнеса в конкурентной среде решить её всё-таки придётся.

Цель этой статьи — показать, в какой плоскости начинается результативность аналитики. Она будет полезна руководителям, которые задаются вопросом из заголовка, и аналитикам, которые много работают, но не видят измеримого эффекта.

В чём, на мой взгляд, лежит корень этой проблемы?

Основной барьер для получения дивидендов от аналитической функции — это не просто культура принятия решений на данных (которую все пытаются описать модным и часто спекулятивным термином data-driven culture). Ключевая проблема — в системе взаимодействия, обратной связи и ответственности за результат, принятой в компании.

Аналитика, как и любая функция в компании, — это инструмент. А любой инструмент даёт результат только при определённых условиях. Чтобы понять, какие условия необходимы именно вам, нужно честно ответить на три вопроса.

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

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

Предлагаю вместе проговорить границы применимости воронок и рассмотреть методологию, которая может эффективно дополнить уже существубщие у вас инструменты анализа пользовательского поведения.

Многие команды сейчас меняют проприетарное ПО на открытые аналоги. Под «открытостью» мы понимаем не только миграцию с платного софта на бесплатный, но и новый подход к построению data-платформ, где каждый продукт развивает свой сегмент платформы с помощью релевантного стека технологий. 

Полноценных open-source-альтернатив, которые закрыли бы все наши потребности, не нашлось. Поэтому мы решили создать свой «мультитул» — low-code-фреймворк для генерации гетерогенных Airflow DAG с незамысловатым названием dag_generator.

Цель этой статьи — поделиться опытом внедрения подобного инструмента. Генерация выполняется по старинке, так что про ИИ здесь пока ничего не найдете.

Обычный трейдер смотрит на свечной график, но свеча — это уже тень прошлого, постфактум. Между тем настоящая динамика рождается в глубине торгового стакана — Limit Order Book, где борьба заявок определяет будущий импульс.

Проблема в том, что историю стакана почти нигде не увидеть: розничные терминалы для частных клиентов дают лишь текущую таблицу DOM ( Depth of Market ) и это статичный срез без прошлого.

Чтобы увидеть то, на что обычный трейдер не обращает внимание я собрал инструмент, который превращает исторические данные L2 Order Book (стакан заданной глубиной) и Trades Stream (обезличенные сделки) в тепловые карты и позволяет изучать эволюцию заявок на Московской бирже через браузер с Deep Zoom — плавно, как в Google Maps.

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

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

Power BI и язык DAX являются удобными инструментами аналитиков. В DAX важно учитывать гранулярность — уровень детализации, который зависит от текущего контекста фильтров и группировки.

Мы привыкли работать с гранулярностью, и если в транзакционной системе проблемы с гранулярностью могут быть относительно незаметны, то в BI системах проблемы гранулярности сразу влияют на дашборды. Это усугубляется поведением движков BI систем, в которых гранулярность таблицы считается динамически в зависимости от выражения — как в Power BI.

При использовании некоторых функций, например, REMOVEFILTERS, снижение гранулярности может приводить к интуитивно непонятным результатам и считаться плохой практикой. Интересующимся особенностями снижения гранулярности на примере REMOVEFILTERS — добро пожаловать под кат :)

Давай поговорим о North Star Metric (NSM). Меня, если честно, иногда бесит, когда её преподносят как какую-то магию, которая сама по себе выведет бизнес в лидеры. Это не так.

За свою карьеру я видел разное: компании, которые отлично росли и без формально прописанной NSM, просто потому что у всех в голове и так была общая цель. И видел провалы, когда команды слепо поклонялись одной цифре, вырванной из контекста, и в итоге «оптимизировали» бизнес прямиком в тупик.

Вся суть не в том, чтобы найти «идеальную метрику». Суть в том, чтобы заставить все отделы говорить на одном языке. И здесь как раз помогает метрика Полярной Звезды.

Все мы видели круговые диаграммы. Их любят рисовать во всяких отчётах и презентациях. А ещё их очень любят авторы рекламных материалов и стоковых картинок: довольный «эффективный менеджер» с лучезарной улыбкой держит в руках распечатку графиков своего головокружительного успеха.

На первый взгляд может показаться, что круговая диаграмма — это отличный способ визуализации данных. Наглядно, красиво, высокохудожественно, современно. Однако у круговых диаграмм есть ряд проблем... При должном усилии их можно превратить в инструмент искажения данных. Но мы ведь хотим донести до наших читателей объективную информацию и не хотим её скрыть или исказить. Ведь правда?

Привет, Хабр! Меня зовут Денис Мишкин, я - Product Manager одного из инструментов отчетности компании «Форсайт». Весной этого года мы выпустили новый продукт «Форсайт. Умные таблицы», который призван ускорить импортозамещение табличных редакторов, а-ля MS Excel, и BI-систем. Хочу рассказать вам о новом классе продукта, который сделает процесс создания аналитических отчетов максимально удобным и комфортным для пользователя, обогащая их опыт новыми уникальными возможностями.

Место нового продукта в экосистеме продуктов «Форсайт»

«Форсайт. Аналитическая платформа» – это универсальное и гибкое решение класса Enterprise BI, для реализации задач любой сложности. Оно дает не только возможности создания многомерной кубовой модели данных средствами загрузки этих данных (ETL), но и средствами доставки этих данных конечному потребителю в виде отчетности. Инструменты отчетности можно разделить на 2 крупных блока:

• информационные панели (дашборды) + Ad hoc, позволяющие легко и наглядно визуализировать данные;

• Pixel Perfect + табличная отчетность, которая призвана подготавливать регламентированную отчетность в строгой структуре и оформлении (регламентные отчеты).

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

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

Быть детективами нам понравилось, но вкладывать столько усилий в каждый подобный случай не хочется. Мы поняли, что нужно научиться контролировать работу модели так, чтобы своевременно находить проблему и чинить ее, используя минимальное количество ресурсов. В серии из двух статей расскажу, как мы построили систему мониторинга ML‑моделей силами одного человека за несколько месяцев.