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

Многие команды сейчас меняют проприетарное ПО на открытые аналоги. Под «открытостью» мы понимаем не только миграцию с платного софта на бесплатный, но и новый подход к построению 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‑моделей силами одного человека за несколько месяцев. 

Часто в работе возникает потребность жестко выдерживать тайминг при заслушивании серии докладов: при защите проектов, программ развития, дипломных работ и прочее. Если в повестке дня какого-либо мероприятия 10+ докладчиков, то без строгого соблюдения регламента невозможно не выбиться из графика. Как правило, это приводит к тому, что запланированное время мероприятия увеличивается кратно. А докладчикам, выступающим последними, фактически не достаётся должного внимания.

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

Сеть кофеен — это текучка, гибкие графики, подмены, совместители и десятки локаций. А если считать зарплату вручную, это еще и боль. Особенно когда всё построено на Excel: где-то не проставили смену, забыли штраф, не учли роль. На связи Анна Астахова, директор по развитию ИТ-интегратора «Белый код». Рассказываю, как мы автоматизировали расчёт зарплаты в сети кофеен, в которой более 150 сотрудников и нестандартизованной системой мотивации.

Привет!

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

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

Одновременно усилились и глобальные вызовы: рост объёмов данных, переход бизнеса к моделям прогнозной аналитики и управлению на основе данных. ETL-системы в этой экосистеме занимают фундаментальное место — именно они превращают разрозненные источники в согласованный поток информации, на котором строятся аналитика, модели машинного обучения и управленческие решения.

Иногда один документ скрывает в себе гораздо больше структуры, чем видно на первый взгляд. Со временем я заметил, что если разобрать его онтологически, он перестаёт быть текстом и превращается в сеть смыслов. Для меня это уже давно не эксперимент, а обычный рабочий процесс: беру документ, запускаю OntoLex — и провожу свой семантический ритуал. Презентация раскладывается на страницы, страницы — на термины, термины — на связи, и в итоге документ растворяется в графе, оставляя после себя живую модель знаний.

Сколько я пользуюсь SQL, столько же он меня бесит. Сегодня хочу рассказать про свой прототип языка для создания больших и сложных аналитических запросов, который компилируется в SQL. Он будет опираться на структуру конкретной БД, и даже больше — он будет опираться на логику данных.

Привет. Меня зовут Евгений, и я продуктовый менеджер направления отчетности и визуализации данных в компании «Форсайт».

Хотя корпоративная «Форсайт. Аналитической платформа» (далее просто Платформа) имеет в своем арсенале большое число различного инструментария, на мой взгляд, именно инструменты отчетности фактически являются ключевым блоком и «лицом» Платформы и BI-приложений, реализованных на ее основе. Ведь это первое, c чем сталкивается конечный пользователь и на что обращает внимание при работе: наличие необходимых функций, удобство построения пользовательского интерфейса, скорость работы — все это пользователи часто записывают именно на счет компонентов отчетности.

Хочу поделиться с вами нашей «вендорской» историей от том, как развивался инструментарий отчетности в составе нашей Платформы, какие интересные компоненты появились у нас относительно недавно, и над чем новым «Форсайт» работает прямо сейчас. Итак, начинаем!

Всем привет!

Меня зовут Владимир Павлов, я продакт‑менеджер. Недавно я проходил кейс‑интервью и получил отказ со следующим комментарием:

«Правильно выбираешь ключевые метрики, но не хватает измеримости, структуры, прокси‑ и контр‑метрик.»

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

Оплатив платный доступ к GPT, приступил к Vibe Coding.

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

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

Мой путь от простых телефонных заметок к системе персонального знания начался с боли: потеря данных при смене устройств, неудобная синхронизация, отсутствие контроля. Прорыв случился с Obsidian — приложением, которое, как и VS Code, строится вокруг открытого формата (Markdown), локального хранения и расширяемости через плагины. Именно этот принцип «я управляю инструментом, а не наоборот» стал ключевым: Obsidian — не блокнот, а операционная система для мышления.

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

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

Но почему важно иметь точное понимание, что такое операционный процесс и что такое процесс управления?

На основании имеющихся знаний руководители и специалисты проводят моделирование, анализ и совершенствование бизнес-процессов, имеющихся в компании. А если знания не полные или недостаточные и не позволяют видеть всю картину деятельности сотрудников компании? Какая модель может быть разработана и какой результат может быть получен, основываясь на неполном знании и представлении и как это на самом деле осуществляется деятельность компании?

В этой публикации мы хотим детально познакомить вас с мажорным обновлением нашего продукта -- «Форсайт. Бюджетирование и консолидация», которое, на наш взгляд, заслуживает вашего внимания и времени на узнавание. Изменения настолько значительны, что мы даже обновили название продукта в связи с добавлением большого пула новых функциональных возможностей и технологических инструментов. Мы расскажем, каким образом осуществляется переход на новую версию, и раскроем детали того, какие подходы и технологии мы обсуждали и брали за основу продукта.

Продукт «Форсайт. Бюджетирование» уже имеет свою историю успеха: он был выпущен в 2018 году, в следующем 2019 году включен в Реестр российского ПО и за прошедшее время было выполнено значительное количество его внедрений. Из наиболее крупных можно выделить проекты в «Росэнергоатоме», «РусГидро», VK, Иркутской нефтяной компании, «Газпром нефть», Ikon Tyres (Айкон Тайерс), «Лайм-Займ».

При разработке этого продукта (как и других отраслевых решений нашей компании) использовался подход, когда в основе лежит наша флагманская разработка – «Форсайт. Аналитическая платформа», а в продукте разрабатывается дополнительная специализированная функциональность, позволяющая более эффективно автоматизировать процессы, на которые нацелен продукт. При этом уникальность такого подхода на рынке в том, что базовая для продукта платформа «Форсайт. Аналитическая платформа» сама является полноценным продуктом enterprise уровня с широким набором инструментов и сервисов. Разрабатываемые отраслевые продукты на базе платформы получают всю функциональность базовой платформы и высокий уровень защиты и безопасности (платформа сертифицирована ФСТЭК на соответствие 4 уровню доверия). Также отраслевые продукты, как «заказчики функциональности», влияют на развитие самой платформы. Функциональность «Форсайт. Бюджетирование», например, примерно на 80% состояла из функциональности платформы. Важным результатом применяемого подхода является получаемый синергетический эффект: в совместном развитии и функциональных возможностей продуктов, и инструментов базовой платформы.

Топ-менеджеры юрфирмы по банкроству физлиц тратили несколько часов в день на подготовку к еженедельной планёрке. Например, руководитель колл-центра делал кучу выгрузок в amoCRM, открывал каждую сделку вручную, копировал и вставлял её в Excel.

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

Маркетинг утверждал: «Мы привели лиды, а вы просто не умеете продавать». Продажи отвечали: «Ваши лиды — говно».

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