Системный и бизнес-анализ

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

Подход Марковица, которому мы сегодня уделим внимание, был удостоен Нобелевской премии 1990 года.

Всем привет! Меня зовут Дмитрий Рейман, я техлид аналитической платформы Avito. Уже третий год мы занимаемся миграцией с Vertica на Trino. Изначально казалось, что это будет просто: перенесём запросы, перепишем коннекторы, чуть подправим пайплайны.

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

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

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

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

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

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

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

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

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

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

Сегодня мы, Павел Ефремов и Мухаммед Пашаев (разработчики аналитических систем в Лемана Тех), поговорим об оптимизации моделей данных в Power BI Desktop — конкретно о движке Tabular. Небольшая вводная: в нашей компании Power BI — основной BI-инструмент (лучшие для лучших😏). Используем локальную версию Power BI Report Server, поэтому вопрос производительности моделей и отчетов стоит особо остро. Мы регулярно проводим ревью моделей (подробнее в нашей прошлой статье), стараясь придерживаться лучших практик — минимальная нужная гранулярность данных, никаких избыточных связей, двунаправленных связей, скрытых автоматических календарей и прочее. Тем не менее отчеты все равно порой залипают и работают медленно. Казалось бы, уже много где поковырялись, все оптимизировали, и все равно фрустрация не уходит. Так, вместе с коллегой мы взялись копать глубже, шерстить интернет и Microsoft-документацию и наткнулись на почти незаметное, но важное свойство табличной модели. Что, если мы скажем, что у Tabular Model есть свойство, благодаря которому можно уменьшить размер модели до 30%, ускорить обновление данных, снизить нагрузку на сервер и при этом не менять ни одной таблицы, связи или строку DAX?

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

🤖 Тысячи копий одного и того же алгоритма от Claude/Grok/ChatGPT торгуют друг против друга. Это создаёт спираль смерти, на которой зарабатывает только биржа через комиссии

Модель Блэка — Шоулза — математическая модель для предсказания динамики финансового рынка, на котором торгуются произвольные инвестиционные инструменты. Модель представляет собой дифференциальное уравнение в частных производных параболического типа. Эта модель дает нам инструменты для теоретической оценки цены европейских опционов.

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

В этой части мы познакомимся с вспомогательными понятиями финансовой математики.

Всем привет! Меня зовут Дмитрий Рейман, я техлид аналитической платформы Авито. Мы строим систему общего назначения, которая одновременно обслуживает ETL, витрины, BI, ad-hoc аналитику и продуктовые платформы.

И в какой-то момент мы столкнулись с неприятным эффектом: объём данных начал расти заметно быстрее, чем органический рост, на который мы ориентировались раньше. Модель классического on-prem DWH перестала масштабироваться линейно: борьба за ресурсы мешала давать гарантии готовности данных; локальные оптимизации давали всё меньший эффект; любой рост требовал масштабирования “по месту” и приводил к длительным простоям аналитики.

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

Чем больше данных в компании, тем критичнее становится понимание того, где именно они хранятся и как изменяются при обновлениях. В «Островке» мы пользуемся дата-каталогами, но в какой-то момент решили пойти чуть дальше: объединили DataHub с генеративным ИИ через Model Context Protocol, чтобы сделать работу с метаданными более интерактивной и быстрой.

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

Под катом делимся опытом внедрения связки DataHub + MCP, рассказываем об архитектуре решения и показываем реальные примеры, как ИИ становится практическим помощником в управлении метаданными.

Оценка знаний и навыков — это тяжелый вопрос и больная тема. Если хочешь увидеть драку, заходи на любую общую встречу с руководителями и вкидывай вопрос про оценку знаний и навыков сотрудников (желательно анонимно) — холивар между сотрудниками, техлидами и руководителями обеспечен. Можно ли сделать этот процесс менее болезненным, более честным и близким к идеалу? Вопрос на миллион.

Меня зовут Бастина Алина. В Альфа-Банке работаю уже более 5 лет, прошла путь от системного аналитика до руководителя группы разработки инструментов для IT-сотрудников. Один из этих инструментов — сервис ассессмента. 

Что будет в статье? Сначала немного формальностей, а далее погрузимся в тему: как ассессмент связан с (другими) процессами развития сотрудника внутри банка, как оценка навыков проводилась раньше, почему пришлось ее менять и как мы дошли до того, что имеем сейчас.

2025 год стал для экосистемы 1С и профессионального ИТ-сообщества насыщенным на события и нововведения. В течение года мы публиковали новости о развитии платформы 1С, изменениях законодательства и отчетности, запуске новых сервисов и масштабных профессиональных событиях.

Имеются разные способы повышения эффективности компаний. Некоторые компании ставят во главу угла только совершенствование операционных процессов путем их оптимизации, применения более современных орудий труда или использования новых технологий для повышения производительности труда. Другие компании не довольствуются повышению эффективности своей деятельности только за счет совершенствования операционных процессов, а стараются совершенствовать также и процессы управления. Одним из таких ярких примеров повышения эффективности деятельности за счет совершенствования процессов управления является компания Тойота, которая в 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 км и был уничтожен атмосферой планеты. Почти двукратное отклонение было обусловлено ошибкой в программном обеспечении: команды по тяге двигателя в программном обеспечении аппарата использовали единицу измерения силы ньютон, в то время как программное обеспечение на Земле, которое создавало эти команды, использовало британскую единицу измерения (фунт-сила).

Салют, Хабр!

Вчера Алексей @Boomburum традиционно подвел итоги уходящего 2025 года на Хабре. Отчёт, как всегда, исчерпывающий и интересный (за что ему отдельный респект!), но лично мне, как человеку-визуалу не хватило наглядности - что называется "многа букав и цифирь". И мне захотелось представить все эти таблички и циферки в наглядной графике. Хоть я и не профи в этом деле, но кое-что у меня получилось, чем и спешу с вами поделиться!

Добрый тёплый вечер, Хабр! Как быстро летит время. На календаре уже двадцатые числа декабря 2025 года, и совсем скоро Новый год. За последние 12 месяцев в мире нашлось большое количество технических инфоповодов и IT-событий, обновлений ПО, случалось появление новых технологий, произошло развитие электроники и масштабный приход ИИ-сервисов в нашу жизнь, включая различные вариации чат-ботов, бум нейросетей и ИИ-агентов. Большую часть этих событий постаралась запечатлеть команда информационной службы Хабра. А вы, как пользователи этого технического ресурса, оценивали и комментировали новости, переводы и лонгриды, а также помогали нам развиваться в этом году, комментируя, критикуя, оценивая публикации и присылая в ЛС сообщения об ошибках или неточностях в материале.

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

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

Хабр привет! Меня зовут Александр Белков, я занимаюсь внедрением и разработкой банковских и страховых систем, а также бизнес и системным анализом.

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