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

Мне кажется, у каждого управленца есть любимый дашборд. Лично мой внешне совсем не похож на “красивую BI-аналитику”.

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

— аварии в очереди;
— юридические лица в очереди;
— заявки, по которым не было звонка клиенту;
— незаполненные слоты на 9:00;
— количество техников, загруженных менее чем на 80% сегодня;
— количество техников, загруженных менее чем на 80% завтра.

Это дашборд по координации заявок, в котором можно увидеть актуальную картину по процессу прямо сейчас. Например, сегодня в одном из наших филиалов утром можно было увидеть: 12 аварии в очереди, 151 заявок без звонка, 28 незаполненных слотов на 9:00 и 9 техников, загруженных менее чем на 80% на сегодня. 

С точки зрения “красивого BI” это выглядит очень просто. С точки зрения управления — это один из самых полезных инструментов.

Или: как embedded-разработчик случайно написал визуализатор временных рядов

Это моя первая статья и сразу на тему в которой я разбираюсь примерно никак. Ее можно воспринимать как условный "дневник разработчика".

Статья написана не без помощи LLM, от нее по большей части редактура. Прошу камнями не кидаться

Приятного чтения!

С чего всё началось

В миру я позиционирую себя как Embedded-разработчик, а как принято во многих местах в России разработчик встраиваемых систем - это инженер-разнорабочий. Написать firmware, развести не сложную PCB, поколдовать над ядром Linux,  провести исследования датчиков с китайского завода, напаять концевиков, собрать тестовый стенд, а если еще и осталось время - по возможности спроектировать корпус для устройства и произвести его прототип.

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

Но иногда появляется потребность в визуализации. Пока речь идет о низкочастотных датчиках и малом количестве данных - все довольно просто, но как только данных становится больше, а частоты выше - всплывает множество нюансов. При 70 кГц через 10 секунд работы датчика у меня уже 700 000 точек. Через минуту – 4.2 миллиона. А пользователь при этом хочет масштабировать/панорамировать оси, выделять области, нажимать кнопки – и всё это должно отзываться мгновенно. Стандартный подход «передать всё в библиотеку» ломается очень быстро.

Когда бизнес обсуждает внедрение ИИ-бота, разговор часто быстро уходит в технологии.

Какая модель? Голос или текст? RAG или сценарий?
Как отреагирует потребитель? Сколько будет стоить разработка?
Насколько похожим на человека будет бот, или все догадаются сразу?

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

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

Звучит очевидно, но при внедрении большинство теряют главный вопрос:

Где именно в техподдержке прячется экономический эффект от ИИ-бота?

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

У большинства контакт-центров уже есть базовая отчетность.

На что обычно смотрят руководители?

— количество обращений;
— время ответа оператора;
— среднее время обработки обращения;
— время ожидания на линии;
— количество потерянных звонков;
— SLA;
— загрузку операторов;
— количество обращений по каналам.

Эти метрики действительно показывают, справляется ли команда с текущей нагрузкой. Но есть нюанс. Какой вывод делает руководитель, работая с таким дашбордом?

Например, мы видим, что:

— количество обращений растет;
— время ожидания увеличивается;
— SLA проседает;
— часть клиентов не дожидается ответа;
— операторы работают в перегрузе;
— в пиковые часы поддержка не справляется.

В девелоперском проекте технико-экономические показатели — это не просто таблица с площадями. Это данные, на которые завязано множество подразделений и управленческих решений внутри компании.

В этой статье я поделюсь опытом работы с ТЭП на основе BIM-моделей и расскажу о разработке инструмента «ТЭП Контроль».

В менеджерской среде есть изречение: «Управлять можно только тем, что можно измерить». Рискнем его дополнить — данных сейчас генерируется так много, что одного измерения уже мало: «…а эффективно управлять — лишь когда результаты измерений представлены наглядно». В предыдущих статьях про адаптивное администрирование Sigla Vision мы описывали, как собирать данные об изменении объектов BI-системы. Теперь покажем, как представить эти данные наглядно, и приведем примеры наших дашбордов — мы назвали их «системными», чтобы отличать от пользовательских.

Статья пригодится BI-разработчикам и ИТ-специалистам, которые развивают или сопровождают Sigla Vision и другие BI-системы.

Здесь мы разбираем, как системные дашборды помогают решать задачи администрирования Sigla Vision, и прикладываем код для PostgreSQL, который готовит таблицы-источники датасетов для комплексного дашборда «Состояние системы». В нем можно отслеживать, как меняются во времени количественные показатели по объектам: дашбордам, подключениям, ролям, пользователям, рабочим книгам, элементам корзины и т. д.

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

Каждый раз, когда вы выбираете, что поставить первой карточкой на дашборде, размер и цвет шрифта, как сформулировать заголовок или описание той или иной цифры, как и когда презентовать отчет, осознанно или нет, вы влияете на решения заказчика.

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

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

Готового мониторинга для SSRS и Power BI Report Server в сети нет - одни обзоры «SQL Server» с CPU и памятью. Собрал свой на Grafana: трейс упавших рассылок, тяжёлые отчёты, ночная нагрузка pbix и грабли с часовым поясом. Сборку отдаю целиком.

Всем привет!

Меня зовут Никита, я CEO компании VSL BI. Мы занимаемся внедрением BI-аналитики и автоматизацией отчетности для бизнеса.

Недавно к нам обратилась спортивная школа для детей.

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

Поэтому основной целью проекта стало создание единой системы аналитики, в которой данные из Alfa CRM автоматически собираются, обрабатываются и отображаются в виде дашбордов для руководства.

Помните, как в детстве казалось, что будущее - это летающие скейтборды из «Назад в будущее 2» и роботы-помощники? Ховерборд, может, еще и не появился, но с роботами-помощниками мы точно не ошиблись - пришло время Искусственного интеллекта.

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

Введение

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

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

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

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

Тем не менее, детские установки «правильного» или «хорошего» поведения имеют колоссальное значение в жизни каждого взрослого.

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

Ролик «Le petit frere» («Младший брат»)

Посмотреть видео (рис. 1) с двуязычными субтитрами можно в https://my.mail.ru/mail/emmerald/video/_myvideo/2.html :

Черта между гениальностью и безумием ученого лежит в доказательстве его теорий. И порой от формирования теории ее автором до формирования полноценного доказательства проходят долгие годы. В XIX веке математик Бернхард Риман предположил, что перцептивные цветовые пространства не плоские и не прямые, а изогнутые. В 1920-х годах Шрёдингер развил эту идею, определив оттенок, насыщенность и яркость в рамках римановой модели восприятия цвета, используя метрику, описывающую то, как люди воспринимают различия в цвете. И вот в наши дни ученые из Лос-Аламосской национальной лаборатории (Лос-Аламос, Нью-Мексико, США) провели колоссальную работу, в результате которой им удалось формализовать модель цвета Шрёдингера. Какие аспекты входят в данную модель, какие гипотезы стали ее фундаментом, и как это модель описывает наше цветовое восприятие? Ответы на эти вопросы мы найдем в докладе ученых.

Привет! Это вторая статья из цикла о 6 базовых понятиях бизнес-анализа по BABOK.

В прошлой статье мы разобрали первое базовое понятие BABOK — Заинтересованные стороны (ЗСт) Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» / Хабр. Мы выяснили, что каждый проект начинается с вопроса «кто в игре?». Но как только мы собрали нужных людей в рабочую группу проекта, перед нами встает следующий, не менее критичный вызов: что на самом деле нужно бизнесу?

По данным исследований PMI (Pulse of the Profession, 2023), около 37% проектов терпят неудачу именно из-за неточно сформулированных требований, в основе которых лежит непонимание истинной потребности бизнеса. Иными словами, проблема системная и дорогостоящая.

Бизнес-аналитик может идеально собрать требования, разработчик написать код, а тестировщик протестировать его, но в итоге получится решение, которое не удовлетворяет ни одну из потребностей бизнеса. Чтобы не наступить на эти грабли, разберем второе базовое понятие BABOK в этой статье — Потребность (Need).

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

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

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

Формально BI появился. Но способ управления почти не изменился.

Я не пишу это как претензию к бизнесу или к конкретным BI-инструментам. Обычно причина не в одном неудачном решении, а в том, что техническая часть проекта и управленческая часть проекта существуют отдельно друг от друга. DataLens, Power BI, Tableau, Metabase или самописный фронт могут быть вообще ни при чём. Отчёт может быть быстрым, аккуратным и полезным для просмотра, но при этом так и не стать частью процесса, в котором принимаются решения.

Кажется, проблема часто появляется раньше, чем аналитик открывает редактор дашборда.

Что делать ученому с Эльбрусом? Краткий обзор ПО, которое мне удалось собрать и протестировать на Эльбрусе - средства для симуляции в ядерной физике, обработки и визуализации данных, верстки научных статей.

Личный кейс из телекома: как мы сопоставляли биллинг, 1С, адреса, услуги и партнерскую платформу, чтобы найти, где нарушается синхронизация.

Когда говорят про DWH, чаще всего обсуждают управленческую отчетность, BI-дашборды, витрины данных и красивые графики для руководителей.

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

MacBook M3, 16 ГБ, никакого облака. Поставил свежую Gemma 4, написал инструмент: кидаешь картинку с графиком или таблицей — получаешь CSV. Три кейса из семи — идеально. На остальных модель начала врать, причём аккуратнее, чем говорила правду: вместо рваных реальных чисел подсовывала гладкие выдуманные. Разобрал по шагам — сетап на маке, грабли с llama.cpp, сам инструмент — и собрал карту, где локальному зрению можно верить, а где оно тихо галлюцинирует

Полгода назад я узнал о крутом инструменте — Apps Script. Это расширение Google для их приложений, например, Таблицы, Документы, Презентации и т. д. Сначала при помощи этого инструмента я автоматизировал выгрузку данных из CRM в Google таблицу для спортивной школы и настроил удобное отображение этих данных, а потом, когда распробовал инструмент на вкус, сделал личного Telegram-бота. Об этом и пойдет дальше речь.

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

Сегодняшнее поколение зуммеров такой продукт никогда не купит - в нем больше одной кнопки.

Всем привет. Я сделал бесплатную обучающую платформу shlyk.tech с упором на визуализацию идей и структур. Графы, системы счисления, логику, комбинаторику, индукцию здесь можно потрогать, покрутить, прошагать и понять, почему оно так работает.

Это вторая часть разбора того, как мы выстраивали SLA и инцидент-менеджмент в большом продукте.

В этой части речь пойдёт о следующем этапе — масштабировании и удешевлении. О том, что происходит, когда SLA считается корректно, цифрам уже доверяют, но компания продолжает развиваться. У неё кратно растёт количество разработчиков, архитектура усложняется и количество сбоев тоже растёт. Инциденты и сбои это наши обиходные синонимы и по ITIL это не одно и тоже, уж простите. С ростом ограничением становится не математика и перегибы полиномов высоких порядков, а люди, ручной труд, коммуникации и скорость реакции. О том, что со всем этим делать и поговорим.