📊 SQL ДЛЯ АНАЛИТИКА: ОКОННЫЕ ФУНКЦИИ — СЛЕДУЮЩИЙ УРОВЕНЬ

Привет, коллеги! 👋 Вы уже знаете SELECT, JOIN и GROUP BY. Но есть вещь, которая выводит анализ на новый уровень — оконные функции. Они позволяют считать скользящие средние, приросты, доли и ранги без сложных подзапросов. Сегодня разберём на реальных задачах. Поехали! 🚀

📌 Кейс 1: Сравнение продаж с прошлым месяцем (LAG)

Менеджер просит: «Покажи помесячную динамику и прирост к прошлому месяцу». Без оконных функций пришлось бы делать self-join или подзапрос. А так:

SELECT 
    DATE_TRUNC('month', order_date) as month,
    SUM(amount) as revenue,
    LAG(SUM(amount)) OVER (ORDER BY DATE_TRUNC('month', order_date)) as prev_revenue,
    (SUM(amount) - LAG(SUM(amount)) OVER (ORDER BY DATE_TRUNC('month', order_date))) / 
        LAG(SUM(amount)) OVER (ORDER BY DATE_TRUNC('month', order_date)) * 100 as growth_percent
FROM orders
GROUP BY month
ORDER BY month;

Что получим: месячная выручка, прошлая выручка и процент роста. Всё одним запросом! 🔥

📌 Кейс 2: Топ-3 товара в каждой категории (ROW_NUMBER)

Нужно для каждой категории выделить три самых продаваемых товара. Раньше — муть с подзапросами. Теперь:

WITH ranked_products AS (
    SELECT 
        category_id,
        product_id,
        SUM(quantity) as total_sold,
        ROW_NUMBER() OVER (PARTITION BY category_id ORDER BY SUM(quantity) DESC) as rn
    FROM order_items
    GROUP BY category_id, product_id
)
SELECT category_id, product_id, total_sold
FROM ranked_products
WHERE rn <= 3;

Результат: аккуратный топ по каждой категории. А если нужны все товары с повторами (если продажи одинаковые) — используйте RANK() или DENSE_RANK(). 🏆

📌 Кейс 3: Скользящее среднее за 7 дней (AVG OVER)

Для отчёта по трендам нужно сгладить дневные скачки. Скользящее среднее — идеально:

SELECT 
    date,
    revenue,
    AVG(revenue) OVER (ORDER BY date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) as avg_7d
FROM daily_revenue
ORDER BY date;

Теперь видно тенденцию без шума. Маркетологи будут благодарны! 📈

📌 Кейс 4: Доля товара в общей выручке (SUM OVER)

ABC-анализ: надо понять, какие товары дают 80% выручки. Считаем долю накопленным итогом:

WITH product_revenue AS (
    SELECT 
        product_id,
        SUM(amount) as revenue,
        SUM(SUM(amount)) OVER () as total_revenue
    FROM sales
    GROUP BY product_id
)
SELECT 
    product_id,
    revenue,
    revenue / total_revenue * 100 as percent,
    SUM(revenue / total_revenue * 100) OVER (ORDER BY revenue DESC) as cumulative_percent
FROM product_revenue
ORDER BY revenue DESC;

Видим, где граница 80%. Классика для категорийных менеджеров. 📦

🎯 ПОЧЕМУ ЭТО ВАЖНО ДЛЯ АНАЛИТИКА?

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

Освойте оконные функции — и бизнес будет носить вас на руках за быстрые и точные ответы. 💪

#SQL

Экспертиза тех специалиста IT

Когда решил помочь коллегам, но вовремя осознал, на кого повесят задачу

📊 BPMN: НЕ ПРОСТО КАРТИНКИ, А ИНСТРУМЕНТ АНАЛИЗА

Привет, коллеги! 👋 Многие думают, что BPMN нужен только чтобы «нарисовать процесс для заказчика». На самом деле, это мощный инструмент анализа, который помогает находить узкие места, избыточность и скрытые проблемы. Сегодня покажу на реальных кейсах, как BPMN спасает проекты. 🚀

📌 Кейс 1: «Согласование договора за 2 недели»

Компания жаловалась, что согласование договора занимает 14 дней. Аналитик нарисовал процесс в BPMN и сразу увидел проблему:

Дорожка юриста: проверка договора → отправка финансисту.
Дорожка финансиста: проверка бюджета → возврат юристу с правками.
Дорожка руководителя: финальное утверждение.

Что обнаружилось? В BPMN стало видно, что документ ходит по кругу между юристом и финансистом по 3–4 раза, потому что нет чёткого порядка правок. Каждый раз после изменений одного отдела другой снова проверял всё заново.

Решение: Внедрили шлюз (XOR) — теперь после правок документ идёт только тому, кто их запросил, а не всем подряд. Срок сократился до 3 дней. 📉

📌 Кейс 2: «Потерянные заявки»

В службу поддержки поступали жалобы: заявки клиентов «исчезают». Аналитик построил BPMN-модель обработки заявок и нашёл «чёрную дыру»:

[Клиент отправляет заявку] → [Менеджер берёт в работу] → [Запрос доп. информации] → (ожидание ответа)

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

Решение: Добавили пограничное событие-таймер на 3 дня. Если ответа нет — заявка автоматически закрывается с уведомлением клиента. Исчезновения прекратились. ✅

📌 Как BPMN связан с кодом?

Хорошая BPMN-модель — это основа для:

Написания user stories: Каждый шаг процесса — потенциальная задача в Jira.
Тест-кейсов: Можно автоматически генерировать сценарии для каждого пути.

Симуляции: Инструменты вроде Camuda позволяют «прогонять» модель и собирать метрики.
Пример симуляции на Python (упрощённо):

# Имитация процесса согласования
def simulate_approval(legal_ok, finance_ok):
    if not legal_ok:
        return "rejected"
    if not finance_ok:
        return "rework"
    return "approved"

# Прогоняем 1000 сценариев
results = [simulate_approval(random.choice([True, False]), random.choice([True, False])) for _ in range(1000)]
print(Counter(results))  # Сколько раз утвердили, отправили на доработку, отклонили

Такая симуляция помогает оценить нагрузку на отделы ещё до внедрения. 📊

📌 Кейс 3: «Автоматизация по BPMN»

Банк решил автоматизировать процесс выдачи кредитов. Аналитик описал процесс в BPMN, выделив:

Автоматические шаги (проверка кредитной истории)
Ручные шаги (звонок клиенту)
Шлюзы (если скоринг < 300 → отказ)
BPMN-модель стала техническим заданием для разработчиков. Они реализовали workflow-движок (Camunda), который выполняет процесс строго по диаграмме. Любое изменение процесса теперь делается аналитиком (меняется BPMN), а не кодом. 🏗

🎯 ЧТО ДАЁТ BPMN АНАЛИТИКУ?

Наглядность — заказчик видит процесс и утверждает его.
Выявление узких мест — петли, лишние согласования, таймауты.
Основу для автоматизации — workflow-движки понимают BPMN.
Документирование — процесс не в тексте, а в исполняемой модели.

Совет: Не ограничивайтесь рисованием. Прогоняйте модель, считайте метрики, ищите аномалии. BPMN — это язык, на котором вы разговариваете с бизнесом и разработкой. 📈

#BPMN

ИИ меняет всё. Кто разбирается в трендах, тот управляет будущим.

Я собрал папку с экспертами. Здесь настоящие практики, инсайты и кейсы — всё в одном месте.

Добавляйте себе папку и оставайтесь на шаг впереди 💪🏻

Джун & Синьор