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

Вебинар «BI + ETL + КХД за 1,5 млн: как Modus закрывает весь стек корпоративной аналитики»

21 апреля в 12 по МСК приглашаем на вебинар, на котором эксперты ИТ-интегратора «Белый код» расскажут, как малому и среднему бизнесу внедрить BI-систему за 1,5 миллиона рублей.

Одна из задач, с которой к интегратору приходит малый и средний бизнес, — внедрение BI в рамках ограниченного бюджета. При этом есть жесткие требования, например, единая экосистема BI + ETL, без «зоопарка» инструментов, а также нативная работа с 1С как основным источником данных. 

На вебинаре специалисты поделятся практикой внедрения в сегменте МСБ, а также ответят на вопросы. 

Вы узнаете:

• Почему BI сам по себе не решает проблему разночтений в данных

• Какие организационные изменения нужны, чтобы аналитика начала работать

• Modus ETL: как устроена загрузка и обработка данных

• Modus BI: аналитический портал без лишней сложности

• Структура проекта за 1,5 млн рублей: стоимость лицензий, этапы проекта и результат

Спикеры вебинара

• Андрей Рыжик, product owner BI-направления компании «Белый код»

• Наталья Лобанова, коммерческий директор компании «Белый код»

📌Дата и время: 21 апреля 12:00 МСК (онлайн)

Участие бесплатное, требуется предварительная регистрация.

Принять участие

Почему “лучший курс” часто оказывается самой дорогой ошибкой

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

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

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

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

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

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

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

С точки зрения интерфейса всё выглядит честно: цифра показана. Но с точки зрения пользователя это часто превращается в когнитивную ловушку. Он уже увидел «выгоднее» и перестал смотреть на остальное.

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

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

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

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

Данные есть – чуда нет...

Приходите на онлайн-конференцию GlowByte и FanRuan разбираться, куда делось чудо

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

22 апреля в 15:00 (МСК) приглашаем вас на Fine Day Online 2026 – ежегодную онлайн-конференцию от GlowByte и FanRuan, где мы разберем, как этот разрыв закрыть.

Что в программе:

●     От данных к ИИ-инсайтам – как превращать сырые данные в умные решения, а не просто красивые графики (Вилл Ченг, ведущий эксперт по отраслевым решениям, руководитель направлений пресейл и внедрение CIS, FanRuan);

●     Интеграция FanRuan + DataHub – реальный опыт построения связной экосистемы данных (Дмитрий Конюхов, ведущий инженер отдела управления данными, “Галамарт”);

●     1 500 дашбордов для 2 500 пользователей – как сделать BI удобным и востребованным в масштабе (Семён Юников, главный эксперт Дирекции BI, Уралсиб);

●     Shadow DWH – тёмная сторона self-service аналитики и как с ней справляться (Пётр Гордиенко, Lead BI, ОТП);

●     Миграция FineBI с 6.0 на 7.0 – практический опыт и подводные камни (Евгений Иванов, DevOps BI-платформы, ОТП).

Для кого:

Руководители и специалисты в области BI, Data & Analytics, CDO, продуктовые и бизнес-аналитики – все, кто хочет, чтобы данные наконец работали на результат.

Формат:

Онлайн, бесплатно, ~3 часа концентрированной пользы. Нужна только регистрация. 

Почему KYC воспринимается как препятствие, а не как защита

KYC это одна из самых раздражающих частей любого финтех- или криптосервиса.

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

С точки зрения пользователя это выглядит просто: «Я хочу сделать операцию, почему вы тормозите процесс?»

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

И в какой-то момент вопрос уже не в удобстве. Вопрос в выживании.

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

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

Отсюда и главный конфликт: сервис считает, что защищает процесс, а пользователь считает, что его просто остановили на финише.

На практике раздражает не только сам факт проверки, а четыре вещи.

Первая – внезапность. Если KYC появляется слишком поздно, это почти всегда вызывает негатив.

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

Третья – ощущение недоверия. Особенно если интерфейс подаёт проверку сухо, без нормального объяснения.

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

Именно поэтому один и тот же KYC может восприниматься по-разному в разных сервисах. Где-то пользователь проходит его спокойно, а где-то уходит с раздражением ещё до завершения.

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

Если же проверка возникает внезапно, без контекста и без понятных сроков, она воспринимается как ловушка. Даже если с точки зрения комплаенса всё сделано правильно.

Поэтому KYC сегодня – это уже не только юридическая или антифрод-задача. Это ещё и продуктовая задача. Сервису недостаточно просто «включить проверку». Ему нужно встроить её так, чтобы она не ломала доверие быстрее, чем защищала бы бизнес.

На практике пользователей раздражает не сам факт проверки, а то, как и в какой момент она появляется. Поэтому KYC давно перестал быть только задачей безопасности: теперь это ещё и вопрос интерфейса, коммуникации и доверия.

7 вещей, которые нужно проверить перед любым крипто-переводом

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

Первое — сеть. Один и тот же актив может существовать в нескольких сетях. Например, USDT можно отправить через ERC-20, TRC-20, BEP-20 и другие варианты. На экране это выглядит как тот же токен, но по факту это разные маршруты. Ошибка здесь — одна из самых дорогих.

Второе — адрес. Недостаточно просто скопировать его и вставить. Стоит хотя бы сверить первые и последние символы. Ошибки в буфере, невнимательность или банальная спешка — классика.

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

Четвёртое — комиссия и итоговая сумма. Особенно если перевод идёт “впритык”. Иногда пользователь уверен, что отправляет нужную сумму, а после комиссии оказывается ниже минимального порога.

Пятое — минимальная сумма зачисления. Во многих сервисах слишком маленький перевод может прийти в сеть, но не зачислиться автоматически. И человек просто сидит и ждёт, не понимая, что произошло.

Шестое — memo, tag или дополнительный идентификатор, если он нужен. Для некоторых активов одного адреса недостаточно. Если забыть это поле, перевод может пройти, но деньги не будут привязаны к аккаунту без ручной поддержки.

Седьмое — тестовый перевод. Самый скучный совет, но самый дешёвый способ не потерять крупную сумму. Если сервис новый, сеть новая или сумма чувствительная — сначала лучше отправить небольшую часть.

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

Очередные HR-*******чебурашки из NEWHR провели якобы «исследование» рынка аналитиков в России

В исследовании заявлены даже:
— финансовые аналитики
— маркетинговые аналитики

Но никаких деталей по финансовым аналитикам вы в исследовании найдёте.

Также непонятно, почему в «исследование» не попали:
— антифрод-аналитики
— SOC-аналитики
— фармтех-аналитики
— аналитики-химики
— аналитики логистики и т.д. — ну вы поняли.

По тематике бизнес- и системного анализа всё как мы любим:
— аналитики бизнес-процессов не отделены от тех, кто делает требования
— разница между бизнес-аналитиками и BI-аналитиками не объяснена (а её часто нет)
— в зарплатах СА есть грейд Principal, но нет ведущих, а только тимлиды — это никак не объяснено
— в зарплатах БА 0 данных по Principal (лидов тоже нет)
— это никак не объяснено — в топе блогов, которые читают БА-СА — 20 экспертов по ДА, ну-ну

В общем не давайте количественникам проводить исследования без надзора
качественников, а то получается как в анекдоте:

— Штурман, приборы!
— Сто пятьдесят!
— Что сто пятьдесят?
— А что приборы?

Найти профильных лидов по БА-СА для консультаций не составляет никакого труда в наше время.

https://newhr.org/data/research-analysts-2025

Функции сортировки

Функция SORT (СОРТ) позволяет упорядочить исходную таблицу и вставить результат в другое место. По умолчанию таблица сортируется по первому столбцу в порядке возрастания:

• Sheets: =SORT(A:C)

• Excel: =СОРТ(A:C)

Для сортировки по другому столбцу можно передать его номер и направление сортировки: по возрастанию или по убыванию. В Google Sheets это TRUE и FALSE, в Excel — 1 и -1. Следующая формула сортирует таблицу по второму столбцу в порядке убывания:

• Sheets: =SORT(A:C;2;FALSE)

• Excel: =СОРТ(A:C;2;-1)

Недостаток такого подхода: при добавлении/удалении столбцов формула может сломаться, придётся вручную обновлять номер столбца. Поэтому гораздо удобнее передавать не номер, а сам столбец для сортировки. В Google Sheets для этого используется та же функция SORT, в Excel — отдельная функция СОРТПО:

• Sheets: =SORT(A:C;B:B;FALSE)

• Excel: =СОРТПО(A:C;B:B;-1)

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

• Sheets: =SORT(A:C;B:B;FALSE;C:C;TRUE)

• Excel: =СОРТПО(A:C;B:B;-1;C:C;1)

Наконец, лайфхак, про который не рассказывают в документации. Если нужно упорядочить данные по разнице столбцов B и C (пример: доходы минус расходы или цена минус себестоимость), то можно использовать формулу массива. В Google Sheets понадобится ARRAYFORMULA или MAP, в Excel всё работает и без них:

• Sheets: =SORT(A:C;ARRAYFORMULA(B:B-C:C);TRUE)

• Excel: =СОРТПО(A:C;B:B-C:C;1)

Анализ истории сделок на предмет перекоса шортистов/лонгистов

Ссылка на GitHub

В backtest-kit модуль volume-anomaly используется как источник в графе сигналов - параллельно с GARCH. Если GARCH отвечает на вопрос «достаточно ли ожидаемое движение», то volume-anomaly отвечает на вопрос «является ли прямо сейчас статистически необычным моментом в микроструктуре рынка».

Пример кода

import { sourceNode, outputNode } from '@backtest-kit/graph';
import { predict } from 'volume-anomaly';
import { getCandles } from 'backtest-kit';

const ANOMALY_CONFIDENCE = 0.75;
const N_TRAIN  = 1200; // обучающее окно — должно быть без аномалий
const N_DETECT = 200;  // окно детекции

const reversalSource = sourceNode(
  async (symbol) => {
    // Важно: recent не должен пересекаться с historical
    const all        = await getAggregatedTrades(symbol, N_TRAIN + N_DETECT);
    const historical = all.slice(0, N_TRAIN);  // старые сделки — baseline
    const recent     = all.slice(N_TRAIN);     // новые — без overlap

    return predict(historical, recent, ANOMALY_CONFIDENCE);
    // {
    //   anomaly:    true,
    //   confidence: 0.81,
    //   direction:  'long' | 'short' | 'neutral',
    //   imbalance:  0.61,
    // }
 },
);

const entrySignal = outputNode(
  async ([reversal, ...]) => {
    if (!reversal.anomaly) return null;
    if (reversal.direction === 'neutral') return null;

    const position = reversal.direction; // 'long' | 'short'

    return {
      id: randomString(),
      position,
      priceTakeProfit: ...
      priceStopLoss: ...
      minuteEstimatedTime: 60,
    };
  },
  reversalSource,
  ...
);

Ключевые детали

• Hawkes Process - кластеризация ордеров

• CUSUM- сдвиг buy/sell дисбаланса относительно исторической нормы

• BOCPD- смена режима: момент когда распределение дисбаланса само меняется

Как использовать

Классическая проблема DCA - ты усредняешься в падающий нож. Цена идёт против, ты докупаешь, а она продолжает падать. volume-anomaly заточен именно под это: докупать не по расписанию или по сетке уровней, а только когда ордерфлоу показывает разворот агрессии.

О прогнозе нейтрального тренда актива

Ссылка на GitHub

В backtest-kit GARCH используется как один из источников в графе сигналов. Идея: вход открывается только если GARCH-канал достаточно широк, чтобы TP и SL уместились с запасом над комиссиями.

Например, этим можно законтрить боковик, который был на BTCUSDT в Феврале 2024

• 5–10 февраля, 73% нейтральных баров

• 11–16 февраля, 63% нейтральных баров

• 19–24 февраля, 75% нейтральных баров

• 26–29 февраля, 69% нейтральных баров

Пример кода

import { sourceNode, outputNode } from '@backtest-kit/graph';
import { predict } from 'garch';
import { getCandles } from 'backtest-kit';

const CANDLES_FOR_GARCH = 300;
const GARCH_CONFIDENCE = 0.6827; // ±1σ

const garchSource = sourceNode(
  Cache.fn(
    async (symbol) => {
      const candles = await getCandles(symbol, '8h', CANDLES_FOR_GARCH);
      return predict(candles, '8h', null, GARCH_CONFIDENCE);
    },
    { interval: '8h', key: ([symbol]) => symbol },
  ),
);

const entrySignal = outputNode(
  async ([trend, volume]) => {
    // Пропускаем если модель не сошлась
    if (!volume.reliable) return null;

    // Проверяем что до границ канала достаточно места
    const upperDiff = percentDiff(trend.close, volume.upperPrice);
    const lowerDiff = percentDiff(trend.close, volume.lowerPrice);

    if (upperDiff < TAKE_PROFIT_PERCENT) return null;
    if (lowerDiff < STOP_LOSS_PERCENT) return null;

    // TP и SL по границам GARCH-канала
    const tp = trend.position === 'long' ? volume.upperPrice : volume.lowerPrice;
    const sl = trend.position === 'long' ? volume.lowerPrice : volume.upperPrice;

    return { position, priceOpen: trend.close, priceTakeProfit: tp, priceStopLoss: sl };
  },
  trendSource,
  garchSource,
);

GARCH здесь не генерирует направление. Он отвечает только на вопрос «достаточно ли ожидаемое движение». Направление приходит от другого источника (это может быть Pine Script через @backtest-kit/pinets или LLM через @backtest-kit/ollama)

Ключевые детали

• Parkinson estimator для per-candle RV: (1/4ln2) · ln(H/L)² — в ~5× эффективнее squared returns

• Log-normal bands: P·exp(±z·σ) — не линейное приближение, правильное маппирование в ценовое пространство

• reliable: true когда: оптимизатор сошёлся + persistence < 0.999 + Ljung-Box p ≥ 0.05

• Оптимизация: multi-start Nelder-Mead, GARCH — 4 рестарта, NoVaS — 7 (11-мерная задача)

• 932 теста, включая ground-truth тест с синтетическими данными известной волатильности

Конец микросервисного угара: как Amazon, Uber и Netflix внедряли монолиты

Весной 2023 года Prime Video (Amazon) выкатил кейс, который для многих стал страшным сном: они слили красивую микросервисную оркестрацию и снизили стоимость инфраструктуры более чем на 90%.

Что они сделали? Перестали гонять данные через S3 между десятком серверлесс-функций ради банальной обработки видео. Они собрали те же самые компоненты (медиаконвертер, детекторы) в один контейнер. Вызов функции в памяти оказался быстрее и на порядок дешевле, чем "облачная магия".

Шок-контент? Только для тех, кто перечитал умных книг. Остальные просто кивнули.

Скрытый налог, о котором не пишут в книжках

Мы все прочитали «Чистую архитектуру» и умеем рисовать квадратики. Мы научились резать монолиты вдоль и поперек. Но в лучших практиках почему-то обходят главный вопрос: во что это реально обходится бизнесу?

Распределенные системы — это не бесплатный апгрейд. Это класс расходов, которого физически нет в монолите.

Вы платите за:

1. Пересылку данных по сети вместо вызова method() в памяти.

2. Отладку ада, когда для исследования бага нужно поднять логи 7 разных сервисов.

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

В итоге мы получаем внешне технически совершенную систему, которую никто не может окупить. Бывает, что переход в микросервисы — это не инженерное решение, а следование вере.

Опыт Uber

У тебя 5 сервисов — ты держишь их в голове. У тебя 500 сервисов — ты не инженер, ты -- смотритель в зоопарке.

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

Решение Uber (DOMA) для многих стало интересным: они не стали переписывать код в монолит. Они сгруппировали этот зоопарк по реальным доменам и прикрыли их общими шлюзами.

Монолит 2.0: как было в Netflix

В 2012-м Netflix тушил каскадные отказы через Hystrix. Но для длинных бизнес-процессов (прием контента, кодирование, раскатка по CDN) это было как пластырь на переломе. Инженеры собирали логи руками.

В 2016-м они выкатили решение Conductor — оркестратор. По сути, это монолитный движок с UI для визуализации потоков своих микросервисов. В Netflix не побороли сложность, а переупаковали её. Теперь им нужна отдельная команда, чтобы поддерживать монолит который оркестрирует микросервисы.

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

• Может ли одна команда выкатить фичу без согласования с пятью другими? Если для баг-фикса нужна координация 10+ команд — границы проведены неверно. Вы строите самый худший в мире архитектурный паттерн: распределенный монолит. Вы получите все минусы микросервисов и все минусы монолита одновременно.

• Какая доля бюджета уходит на бизнес-логику, а какая — на то, чтобы сервисы могли просто "договориться"? Готовы ли вы содержать сложный слой оркестрации (как Prime Video) только ради того, чтобы система технически работала?

• Есть ли у вас цифры, по которым вы поймете, что архитектура перестала окупаться? Prime Video начали с серверлесса и слепили всё в один процесс под реальной нагрузкой.

Выводов не будет, вы сделаете их сами.
Послушать расширенную версию статьи как сказку на ночь без донатов и рекламы можно на Яндекс.Музыке, Звуке и Apple Podcasts.

tg https://t.me/i_am_analyst

Сравнение локальных embedding-моделей

Провел тесты, чтобы узнать, что лучше всего использовать в контексте PKM.

Кратко:

⦿ Топ модель

     ⦾ snowflake-arctic-embed2

⦿ Баланс

     ⦾ embeddinggemma

⦿ Бюджет

     ⦾ multilingual-e5-small

     ⦾ база для гибридного поиска

Plugin: Obsidian Hybrid Search

В дополнение к гибридному поиску я сделал плагин для Obsidian. Он закрывает сценарии встроенного поиска, быстрого переключателя, OmniSearch, Recent Files, Similar Notes (или любого другого плагина, который ищет по эмбеддингам).

Интересная библиотека символьной регрессии PhySO. Оптимизатор берет на вход набор данных из многомерных аргументов X и одномерных значений функции Y в предположении, что это некие физические измерения. Пользователь добавляет информацию о единицах измерения компонент аргумента и целевого значения функции в виде наборов степеней [L, T, M] для каждой. Например, [ 1, -2, 0 ] соответствует ускорению, м/с^2. Также можно добавить свободных констант с указанием их физических размерностей в том же виде.

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

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

Пример в доках - здесь.

Это просто красиво. Разработчики хвалятся наилучшими показателями в бенчмарке подобных библиотек - особенно на высоких уровнях специально добавленного шума, до 10% от значений. Тренировали модель на большом количестве физических функций с экспериментальными данными, в том числе и на т.н. коллекции Фейнмана.

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

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

Программа:

• Почему старые подходы к выбору больше не работают. Основные ловушки при выборе.

• Обзор актуального ландшафта BI-инструментов. Западные вендоры, российские платформы, Open Source, облачные и on-premise решения.

• Работа с чек-листом выбора BI: экономика, инфраструктура, требования к команде, функциональность, безопасность и compliance, риски.

Спикер ответит на ваши вопросы в прямом эфире.

🕓 Когда: 24 марта, 16:00–17:00 (Мск)

👨‍🎓 Спикер: Дробинская Мария — эксперт в области внедрения BI-систем и цифровизации.

➡️ Записаться

Стать системным аналитиком в YADRO — дело трех дней

До 29 марта открыта программа быстрого найма для системных аналитиков. Таких специалистов ищут сразу две команды:

— Телеком. С нуля создают телекоммуникационные решения для беспроводных мобильных сетей и сопутствующих услуг. Разрабатывает первые российские базовые станции стандартов GSM/LTE.

— BIOS/BMC. Инженеры занимаются разработкой и сопровождением собственных программных реализаций ПО UEFI/BIOS и BMC, используемых в различных продуктах YADRO.

Подать заявку → 

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

Направления, где нужны аналитики:

• OAM (Operations, administration and maintenance). Специалисты тут работают с системой, обеспечивающей эксплуатационную управляемость и устойчивость операторского уровня. Отвечают за сквозные сценарии эксплуатации — от конфигурирования и мониторинга до инцидентов, SLA и масштабирования.

• GSM. Здесь разрабатывают GSM Controller (BSC) и компоненты базовой станции (BTS) стандарта GSM с поддержкой GPRS и основного функционала для операторов большой тройки.

• LTE. Инженеры здесь создают базовую станцию LTE (4G), реализуя полный стек телекоммуникационных протоколов «с нуля».

• BIOS/BMC. Как уже писали выше, здесь занимаются разработкой и поддержкой UEFI/BIOS для продуктов компании, кода BMC для мониторинга и управления серверами, а также прошивками для MCU- и FPGA-модулей серверов (материнские платы, экспандеры и так далее).

Подробнее об ожиданиях к кандидатам — на лендинге SPRINT OFFER. Успейте оставить заявку до 29 марта.

Системный аналитик: какой у тебя уровень? Пройди бесплатный пробный тест и разберись в своих сильных сторонах и точках роста

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

Чтобы осознанно расти в профессии, важно понимать:

• какие технические навыки уже прокачаны;

• где есть пробелы в проектировании и анализе;

• какие инструменты и методологии стоит изучить подробнее;

• насколько уверенно ты ориентируешься в архитектуре систем.

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

За 20 минут ты получишь:

• оценку текущего уровня;

• карту компетенций — наглядную схему всех навыков, необходимых для развития в профессии;

• подборку материалов для самостоятельного изучения.

Пройти тест

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

Какой ты гриб бизнес-аналитик? Пройди бесплатный пробный тест, чтобы определить свой уровень

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

Чтобы расти в профессии и осознанно выстраивать карьеру, важно понимать:

• какие компетенции у тебя уже прокачаны;

• где есть пробелы;

• что именно стоит подтянуть в первую очередь.

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

За 20 минут ты получишь:

• оценку текущего уровня бизнес‑анализа — от базовых понятий до продвинутых техник;

• карту компетенций — наглядную схему всех навыков, необходимых для развития в профессии;

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

Пройти тест

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

Успейте подать свою работу на конкурс BI-дашбордов Data Challenge

Партнер GlowByte компания FanRuan продолжает принимать заявки на первый открытый конкурс BI-дашбордов и визуальной аналитики FineGallery Insight Challenge. Срок подачи - до 31 марта.

Подробнее рассказывали о конкурсе в новости. 

FineGallery Insight Challenge – это конкурс для аналитиков, BI-разработчиков и команд, которые работают с данными и создают дашборды.

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

Как участвовать

1. Создайте аналитическую работу в FineBI или FineReport.

2. Заполните форму подачи, включив:

• дашборд,

• описание работы по структуре (описана на сайте конкурса),

• информацию об авторе.

3. Дождитесь подтверждения участия и ждите результатов.

Призовой фонд

• Лучшая бизнес-аналитика – 100 000 руб.

• Лучший UX (пользовательский опыт) и визуальный дизайн – 70 000 руб.

• Приз зрительских симпатий – 30000 руб.

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

Obsidian Hybrid Search | GitHub

Разработал MCP-сервер и CLI для гибридного поиска по хранилищу в Obsidian.

Как перестать тратить полдня на один вопрос в чате

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

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

В распределенных командах работают два формата общения:

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

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

Если сообщения составлены грамотно, асинхронный формат помогает сократить количество уточнений и экономит время команды.

Формат общения лучше выбирать под задачу. Я ориентируюсь на простое правило:

• Асинхронно — если есть время подумать и нет горящего дедлайна. Например, аналитик разбирается с SQL-запросом в начале спринта.

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

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

Чтобы переписка не превращалась в длинную цепочку уточнений, сообщение должно отвечать на три вопроса:

1. Что происходит?

2. В чем проблема?

3. Что нужно от собеседника?

Например:

Делаю импорт отчета клиента. Вот ссылка.
 Получаю ошибку Invalid format.
 Можешь посмотреть формат файла?

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

Почему чаты постоянно отвлекают

Частая ситуация: работаем над задачей → приходит уведомление → открываем чат → через 30 минут читаем какой-нибудь спор, который вообще нас не касается. Чтобы не распыляться, я выделяю отдельные блоки времени, когда разбираю все сообщения — «окна хаоса».

Однако «окна хаоса» не будут работать, если уведомления приходят каждую минуту. Поэтому важно настроить каналы:

• критичные чаты — уведомления включены

• обсуждения без срочности — выключены

Почему важна культура обратной связи

Когда сообщение прочитано, но в ответ тишина — это создает тревогу. Вполне очевидно, что собеседник будет приходить с вопросами дополнительно.

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