🎄 Выгружаем «новогодний чемодан»: 3 data-вопроса к году
Привет, друзья! ☕️
Отзвенели бокалы, доедены мандарины, гирлянды — в коробку. Мы вернулись. Но прежде чем нырять в воронки, графики и планы, давайте сделаем одну полезную вещь.
Любой аналитик знает: прежде чем строить прогноз, нужно разобраться с базой. Давайте применим это к нашему прошедшему году.
Задайте себе три вопроса (можно мысленно, можно в заметках):
1. Какая одна цифра/факт из работы-2025 меня поразила больше всего? (Например: «Оказалось, 80% прибыли приносят всего 3 клиента» или «Я провёл 600 часов на совещаниях»). Просто вытащите это на свет.
2. Какой один неочевидный процесс (или привычка) оказался самым бесполезным? Тот, на который уходила энергия, а отдачи — ноль. Его стоит оставить в прошлом.
3. Кто один человек (коллега, клиент, близкий) дал мне в этом году главный профессиональный инсайт? Поблагодарите его мысленно или письмом.
Сегодня неспешно разбираем личные показатели года и решаем, какие из них берём с собой в 2026, а какие — уже давно «носки с дырками».
Поделитесь в комментариях хотя бы одним своим ответом и решением по нему — вдохновим друг друга на легкий старт💪🏼
А в следующий раз, с чистого листа, вернёмся к нашим данным, процессам и инсайтам. Рада снова вас видеть🩶
Привет, друзья! ☕️
Отзвенели бокалы, доедены мандарины, гирлянды — в коробку. Мы вернулись. Но прежде чем нырять в воронки, графики и планы, давайте сделаем одну полезную вещь.
Любой аналитик знает: прежде чем строить прогноз, нужно разобраться с базой. Давайте применим это к нашему прошедшему году.
Задайте себе три вопроса (можно мысленно, можно в заметках):
1. Какая одна цифра/факт из работы-2025 меня поразила больше всего? (Например: «Оказалось, 80% прибыли приносят всего 3 клиента» или «Я провёл 600 часов на совещаниях»). Просто вытащите это на свет.
2. Какой один неочевидный процесс (или привычка) оказался самым бесполезным? Тот, на который уходила энергия, а отдачи — ноль. Его стоит оставить в прошлом.
3. Кто один человек (коллега, клиент, близкий) дал мне в этом году главный профессиональный инсайт? Поблагодарите его мысленно или письмом.
Сегодня неспешно разбираем личные показатели года и решаем, какие из них берём с собой в 2026, а какие — уже давно «носки с дырками».
Поделитесь в комментариях хотя бы одним своим ответом и решением по нему — вдохновим друг друга на легкий старт💪🏼
А в следующий раз, с чистого листа, вернёмся к нашим данным, процессам и инсайтам. Рада снова вас видеть🩶
👍3❤1
🧠 Почему аналитик важнее данных: слепая выборка vs системный сбой
Привет, друзья! ☕️
«Зачем аналитик, если модель сама найдёт закономерности?». Ответ прост: модель не задаёт данным вопрос «почему», а мы умеем.
Разберём на живом примере из медицинской статистики.
Задача: Проанализировать структуру заболеваемости по сети клиник.
Данные: В поле «Диагноз» заполнено только 50% записей.
Вариант 1: «Слепая» выборка
Допустим, диагнозы заполнили случайные 50% клиник (одни всегда вносят, другие — нет).
Вариант 2: Системный сбой
А если заполнены только диагнозы по ортопедии, а кардиология — нет (потому что справочник маппинга сбоит)?
Казалось бы: заполненность одинаковая. Но от причины пропусков зависит, можно ли вообще что-то считать.
Вариант 1:
Здесь пропуски случайны.
✅ Что можно: Проводить анализ заболеваемости по имеющимся данным. Они для всей сети.
❌ Что нельзя: Сравнивать клиники между собой по заполненности.
Вариант 2:
Здесь пропуски системны.
✅ Что можно: Сравнивать клиники только по доле ортопедических пациентов.
❌ Что нельзя: Делать выводы об общей заболеваемости. Вы увидите «всплеск болезней суставов», которого на самом деле нет.
Вывод для бизнеса:
Цифра «50% заполнено» ничего не значит без понимания контекста. Только человек, погружённый в процесс, может отличить «не заполнили» от «не смогли заполнить».
Не будьте ИИ, всегда анализируйте суть, а не цифры😉
Подписывайтесь, чтобы не пропустить следующую тему — разбор «хвостов» 🩶
Привет, друзья! ☕️
«Зачем аналитик, если модель сама найдёт закономерности?». Ответ прост: модель не задаёт данным вопрос «почему», а мы умеем.
Разберём на живом примере из медицинской статистики.
Задача: Проанализировать структуру заболеваемости по сети клиник.
Данные: В поле «Диагноз» заполнено только 50% записей.
Вариант 1: «Слепая» выборка
Допустим, диагнозы заполнили случайные 50% клиник (одни всегда вносят, другие — нет).
Вариант 2: Системный сбой
А если заполнены только диагнозы по ортопедии, а кардиология — нет (потому что справочник маппинга сбоит)?
Казалось бы: заполненность одинаковая. Но от причины пропусков зависит, можно ли вообще что-то считать.
Вариант 1:
Здесь пропуски случайны.
✅ Что можно: Проводить анализ заболеваемости по имеющимся данным. Они для всей сети.
❌ Что нельзя: Сравнивать клиники между собой по заполненности.
Вариант 2:
Здесь пропуски системны.
✅ Что можно: Сравнивать клиники только по доле ортопедических пациентов.
❌ Что нельзя: Делать выводы об общей заболеваемости. Вы увидите «всплеск болезней суставов», которого на самом деле нет.
Вывод для бизнеса:
Цифра «50% заполнено» ничего не значит без понимания контекста. Только человек, погружённый в процесс, может отличить «не заполнили» от «не смогли заполнить».
Не будьте ИИ, всегда анализируйте суть, а не цифры😉
Подписывайтесь, чтобы не пропустить следующую тему — разбор «хвостов» 🩶
👍3
🦎 Как не отрастить дата-хвост
Привет, друзья!☕️
К посту о data-driven инсайтах пришел комментарий, мимо которого я не могла пройти:
Он идеально иллюстрирует важную проблему: система слепа к аномалиям, пока они не затронут «своих». Это классический пример того, когда «средняя температура по больнице» (среднее время ожидания 5 минут) скрывает реальный «хвост» (10% клиентов ждёт по 40+ минут).
Инструмент борьбы называется: «Управление по перцентилям (P95) вместо средних».
Вот как это внедрить:
1. Перестаньте измерять «среднюю очередь». Ваша новая ключевая метрика — «95-й перцентиль времени ожидания». Это значит, что 95% клиентов ждут меньше, чем X минут.
2. Создайте триггер для ручного вмешательства. Внедрите автоматическое оповещение для руководителя, если в любом отделении формируется очередь с расчётным временем ожидания выше порога (например, 30 минут). Не ждите, пока там окажется чей-то родственник.
3. Время от времени проводите «ретроспективу хвостов». Берите 5-10 самых долгих случаев обслуживания (не только очереди, но и сложные запросы, жалобы) и детально разбирайте: что пошло не так на каждом этапе? Это может дать неочевидные инсайты для оптимизации процессов.
Вывод: Добавив в фокус «хвосты» распределения, вы начинаете видеть и лечить реальные боли, которые губят репутацию и отталкивают клиентов.
Вопрос вам: А какие «средние показатели» в вашем бизнесе, возможно, скрывают такие же «токсичные хвосты»? NPS? Время ответа на заявку? Процент ошибок?
Привет, друзья!☕️
К посту о data-driven инсайтах пришел комментарий, мимо которого я не могла пройти:
«История про инсайт номер 3 из одного банка: о том, что «в среднем небольшие очереди» в отделениях имеют толстые хвосты (клиенты в них попадают редко, но метко и надолго) узнали, когда в такую очередь попал родственник руководителя розничного бизнеса 😏 зато потом активно боролись»
Он идеально иллюстрирует важную проблему: система слепа к аномалиям, пока они не затронут «своих». Это классический пример того, когда «средняя температура по больнице» (среднее время ожидания 5 минут) скрывает реальный «хвост» (10% клиентов ждёт по 40+ минут).
Инструмент борьбы называется: «Управление по перцентилям (P95) вместо средних».
Вот как это внедрить:
1. Перестаньте измерять «среднюю очередь». Ваша новая ключевая метрика — «95-й перцентиль времени ожидания». Это значит, что 95% клиентов ждут меньше, чем X минут.
2. Создайте триггер для ручного вмешательства. Внедрите автоматическое оповещение для руководителя, если в любом отделении формируется очередь с расчётным временем ожидания выше порога (например, 30 минут). Не ждите, пока там окажется чей-то родственник.
3. Время от времени проводите «ретроспективу хвостов». Берите 5-10 самых долгих случаев обслуживания (не только очереди, но и сложные запросы, жалобы) и детально разбирайте: что пошло не так на каждом этапе? Это может дать неочевидные инсайты для оптимизации процессов.
Вывод: Добавив в фокус «хвосты» распределения, вы начинаете видеть и лечить реальные боли, которые губят репутацию и отталкивают клиентов.
Вопрос вам: А какие «средние показатели» в вашем бизнесе, возможно, скрывают такие же «токсичные хвосты»? NPS? Время ответа на заявку? Процент ошибок?
❤5
🤡 Продуктовый подход: новый язык или старые грабли?
Привет, друзья! ☕️
Забавно наблюдать, как старые, добрые принципы управления теперь обязательно нужно называть английскими аббревиатурами, чтобы они зазвучали «инновационно». Давайте проведём вежливый «ретроним-анализ» и переведём модный продуктовый сленг на человеческий язык.
Вот ваш краткий словарь переводчика:
OKR (Objectives and Key Results) → Это просто «Цели и показатели» с приставкой «каждый сотрудник должен их понять». Раньше это висело в отделе на плакате «План на квартал». Теперь для этого есть отдельный дорогой софт.
MVP (Minimum Viable Product) → «Пилотный проект» или «пробный запуск». Раньше тестировали в одном регионе/на одном цехе. Теперь это звучит как стратегия космического масштаба.
CJM (Customer Journey Map) → «Схема работы с клиентом/клиентский путь». Просто раньше её рисовали на флипчарте, а теперь — в Figma.
A/B тест → «Сравнительный эксперимент». Раньше говорили: «Давайте в этом месяце сделаем так, а в следующем — эдак, и посмотрим, где результат лучше». Теперь для этого нужна отдельная платформа и продуктовый аналитик.
Roadmap → «План-график работ» или «дорожная карта». Синоним диаграммы Ганта, которая внезапно стала выглядеть менее солидно.
Metriсs → Они же ранее —«Ключевые показатели эффективности (КПЭ)». Как будто без «метрикс» мы и не измеряли эффективность процессов и внедрений.
Backlog → «План задач» или, как говорили классики, «очередь доработок». Раньше это был список в Excel, теперь — в Jira. «В каком порядке будем делать, когда дойдут руки».
Не дайте новым словам себя запутать. Суть грамотного управления всегда была одна: понять проблему клиента, проверить гипотезу, сделать, измерить результат, поправить.
Если за красивым CJM не стоит реального устранения «боли» клиента, а OKR не связаны с прибылью по итогу — это инфоцыганство. И его можно называть как угодно.
P.S. Какая ваша любимая «новая» аббревиатура, за которой скрывается хорошо забытое старое? Дополняйте список в комментариях.
В следующий раз разберем, что реально полезного можно взять на вооружение из новых подходов. Подписывайтесь, чтобы не пропустить🩶
Привет, друзья! ☕️
Забавно наблюдать, как старые, добрые принципы управления теперь обязательно нужно называть английскими аббревиатурами, чтобы они зазвучали «инновационно». Давайте проведём вежливый «ретроним-анализ» и переведём модный продуктовый сленг на человеческий язык.
Вот ваш краткий словарь переводчика:
OKR (Objectives and Key Results) → Это просто «Цели и показатели» с приставкой «каждый сотрудник должен их понять». Раньше это висело в отделе на плакате «План на квартал». Теперь для этого есть отдельный дорогой софт.
MVP (Minimum Viable Product) → «Пилотный проект» или «пробный запуск». Раньше тестировали в одном регионе/на одном цехе. Теперь это звучит как стратегия космического масштаба.
CJM (Customer Journey Map) → «Схема работы с клиентом/клиентский путь». Просто раньше её рисовали на флипчарте, а теперь — в Figma.
A/B тест → «Сравнительный эксперимент». Раньше говорили: «Давайте в этом месяце сделаем так, а в следующем — эдак, и посмотрим, где результат лучше». Теперь для этого нужна отдельная платформа и продуктовый аналитик.
Roadmap → «План-график работ» или «дорожная карта». Синоним диаграммы Ганта, которая внезапно стала выглядеть менее солидно.
Metriсs → Они же ранее —«Ключевые показатели эффективности (КПЭ)». Как будто без «метрикс» мы и не измеряли эффективность процессов и внедрений.
Backlog → «План задач» или, как говорили классики, «очередь доработок». Раньше это был список в Excel, теперь — в Jira. «В каком порядке будем делать, когда дойдут руки».
Не дайте новым словам себя запутать. Суть грамотного управления всегда была одна: понять проблему клиента, проверить гипотезу, сделать, измерить результат, поправить.
Если за красивым CJM не стоит реального устранения «боли» клиента, а OKR не связаны с прибылью по итогу — это инфоцыганство. И его можно называть как угодно.
P.S. Какая ваша любимая «новая» аббревиатура, за которой скрывается хорошо забытое старое? Дополняйте список в комментариях.
В следующий раз разберем, что реально полезного можно взять на вооружение из новых подходов. Подписывайтесь, чтобы не пропустить🩶
🔥5
🚀 Agile и JTBD: где за модными словами скрывается реальный прорыв
Привет, друзья! ☕️
Среди всего потока переупакованных старых идей есть две, которые, на мой взгляд, стоит выделить — Agile и Jobs To Be Done (JTBD).
1. Agile: легализация изменений
Что было раньше: «Водопад». Жёсткий план на год, ТЗ как библия, изменение требований — ЧП. Результат часто не совпадал с ожиданиями рынка.
В чём прорыв: Agile легализовал неопределённость. Он признал, что в начале пути мы многого не знаем, и дал механизм встроенного обучения: короткие циклы → обратная связь → адаптация.
Ценность: Это не про спринты и доски. Это про культуру, где можно менять курс по ходу движения. Фокус смещается с «следования плану» на достижение результата.
2. JTBD: смена оптики на клиента
Что было раньше: Мы спрашивали: «Каков портрет нашего клиента? (возраст, доход)» или «Какие фичи ему нужны?». Создавали продукты на основе демографии и опросов.
В чём прорыв: JTBD предлагает спросить иначе: «На какую «работу» клиент «нанимает» наш продукт?».
Клиент «нанимает» дрель не чтобы ей владеть, а чтобы сделать отверстие в стене.
Клиент «нанимает» страховой полис не чтобы иметь документ, а чтобы обрести спокойствие за будущее семьи.
Ценность: Это инструмент, чтобы видеть за запросами — скрытые мотивы, а за конкурентами — непохожие решения одной и той же задачи клиента. Это выход за рамки «добавим ещё одну кнопку».
Почему это не просто упаковка:
✔️Agile переносит фокус с плана на результат.
✔️JTBD переносит фокус с продукта/клиента на прогресс клиента.
Что брать на вооружение:
1. Из Agile — принцип «проверяй гипотезы короткими циклами». Не годовой план, а двухнедельный эксперимент.
2. Из JTBD — вопрос «Какую задачу клиент решает по-настоящему?» перед запуском любой новой фичи или продукта.
Если такие разборы полезны — поставьте реакцию. Следующим разберём конкретный кейс применения JTBD в страховании.
Привет, друзья! ☕️
Среди всего потока переупакованных старых идей есть две, которые, на мой взгляд, стоит выделить — Agile и Jobs To Be Done (JTBD).
1. Agile: легализация изменений
Что было раньше: «Водопад». Жёсткий план на год, ТЗ как библия, изменение требований — ЧП. Результат часто не совпадал с ожиданиями рынка.
В чём прорыв: Agile легализовал неопределённость. Он признал, что в начале пути мы многого не знаем, и дал механизм встроенного обучения: короткие циклы → обратная связь → адаптация.
Ценность: Это не про спринты и доски. Это про культуру, где можно менять курс по ходу движения. Фокус смещается с «следования плану» на достижение результата.
2. JTBD: смена оптики на клиента
Что было раньше: Мы спрашивали: «Каков портрет нашего клиента? (возраст, доход)» или «Какие фичи ему нужны?». Создавали продукты на основе демографии и опросов.
В чём прорыв: JTBD предлагает спросить иначе: «На какую «работу» клиент «нанимает» наш продукт?».
Клиент «нанимает» дрель не чтобы ей владеть, а чтобы сделать отверстие в стене.
Клиент «нанимает» страховой полис не чтобы иметь документ, а чтобы обрести спокойствие за будущее семьи.
Ценность: Это инструмент, чтобы видеть за запросами — скрытые мотивы, а за конкурентами — непохожие решения одной и той же задачи клиента. Это выход за рамки «добавим ещё одну кнопку».
Почему это не просто упаковка:
✔️Agile переносит фокус с плана на результат.
✔️JTBD переносит фокус с продукта/клиента на прогресс клиента.
Что брать на вооружение:
1. Из Agile — принцип «проверяй гипотезы короткими циклами». Не годовой план, а двухнедельный эксперимент.
2. Из JTBD — вопрос «Какую задачу клиент решает по-настоящему?» перед запуском любой новой фичи или продукта.
Если такие разборы полезны — поставьте реакцию. Следующим разберём конкретный кейс применения JTBD в страховании.
❤5
🛠️ JTBD в ДМС: почему клиент «увольняет» вашу страховку после первого обращения
Привет, друзья! ☕️
Обещала пример. Мы говорим, что JTBD — это про «работу», на которую клиент нанимает наш продукт.
Ситуация: Клиент (физ.лицо) купил ДМС. Впервые обращается за помощью — нужен МРТ.
Логика клиента: Полис покрывает исследование. Клиника в сети есть.
А вот что происходит на деле:
1. Клиент сам ищет клинику в сети, где есть свободное окно.
2. Он звонит в страховую для подтверждения гарантийного письма.
3. Оператор запрашивает документы от лечащего врача (выписку, направление).
4. Клиент вынужден снова обратиться к врачу, потратить время.
5. Страховая предлагает другую клинику (по своим критериям)
Процесс растягивается на дни. Тревога усиливается..
Провал по JTBD
Какая «работа» не выполнена?
Клиент нанимал страховку как «агента, который берёт на себя организационную и бюрократическую нагрузку в момент стресса». Вместо этого он получил «дополнительный источник задач».
Реальная конкуренция происходит не между страховщиками, а между «купить ДМС» и «заплатить напрямую и решить вопрос за 3 часа». Второй вариант часто выигрывает по «стоимости» нервов, хотя может быть и дороже.
Что меняет JTBD-оптика?
Вы начинаете измерять количество организационных шагов, которые клиент вынужден сделать сам. Ваша цель — свести их к нулю.
Возможное решение:
Внедрить сервис «МРТ в один клик».
Но себестоимость организации такого сервиса выше. А стоимость удержания клиента, который «уволил» вас после первого стресса, — тоже. И вот вы взвешиваете и измеряете, измеряете и взвешиваете.. а поезд проносится мимо..
Привет, друзья! ☕️
Обещала пример. Мы говорим, что JTBD — это про «работу», на которую клиент нанимает наш продукт.
Ситуация: Клиент (физ.лицо) купил ДМС. Впервые обращается за помощью — нужен МРТ.
Логика клиента: Полис покрывает исследование. Клиника в сети есть.
А вот что происходит на деле:
1. Клиент сам ищет клинику в сети, где есть свободное окно.
2. Он звонит в страховую для подтверждения гарантийного письма.
3. Оператор запрашивает документы от лечащего врача (выписку, направление).
4. Клиент вынужден снова обратиться к врачу, потратить время.
5. Страховая предлагает другую клинику (по своим критериям)
Процесс растягивается на дни. Тревога усиливается..
Провал по JTBD
Какая «работа» не выполнена?
Клиент нанимал страховку как «агента, который берёт на себя организационную и бюрократическую нагрузку в момент стресса». Вместо этого он получил «дополнительный источник задач».
Реальная конкуренция происходит не между страховщиками, а между «купить ДМС» и «заплатить напрямую и решить вопрос за 3 часа». Второй вариант часто выигрывает по «стоимости» нервов, хотя может быть и дороже.
Что меняет JTBD-оптика?
Вы начинаете измерять количество организационных шагов, которые клиент вынужден сделать сам. Ваша цель — свести их к нулю.
Возможное решение:
Внедрить сервис «МРТ в один клик».
Но себестоимость организации такого сервиса выше. А стоимость удержания клиента, который «уволил» вас после первого стресса, — тоже. И вот вы взвешиваете и измеряете, измеряете и взвешиваете.. а поезд проносится мимо..
👍3🔥2
🔍 Как читать графики: навык, который не купишь у Power BI
Привет, друзья! ☕️
Вся аналитика держится на одной простой мысли: цифры не врут, но их можно заставить лгать. Давайте учиться смотреть на них с подозрением. Это и есть профессиональный навык.
Тренировка №1: Игра в «А что если?»
Каждый график рассказывает историю. Ваша задача — найти альтернативные сценарии, которые могли бы привести к той же картинке.
Пример:
Вы видите резкий рост продаж в декабре.
Первая мысль: «Отлично поработали!»
Правильная мысля: «Это могло быть вызвано:
1. Новой акцией
2. Падением продаж в ноябре (и декабрь просто компенсация)
3. Технической ошибкой в сборе данных
4. Тем, что конкурент ушёл с рынка
...и ещё 5 вариантов».
Упражнение: Возьмите любой график из ваших отчётов и придумайте 3 разных объяснения одному и тому же движению линии. Это развивает критическое мышление.
Тренировка №2: Искать невидимое
Хороший аналитик смотрит на то, что не показано. Задайте себе контрольные вопросы:
1. Что скрывает масштаб? (Если ось Y начинается не с нуля, рост может быть преувеличен)
2. Где пропали данные? (Разрывы в графике — это часто важнее, чем сами точки)
3. Что находится «за кадром»? («Смотрите, выручка упала!»
А на деле — это октябрь, и мы просто забыли, что в прошлом году в этом месяце был мега-кэшбэк от партнёра, который мы не повторили.)
Лайфхак: Всегда смотрите на абсолютные значения, даже когда вам показывают проценты. Рост на 200% — это от 1 до 3 клиентов или от 1000 до 3000?
Что развивают эти тренировки:
✔️Историческая память: Вести дневник аномалий. «В прошлом году в этот период тоже был скачок — почему?»
✔️Бизнес-грамотность: Понимать, какие внешние факторы влияют на метрики (сезонность, рынок, конкуренты).
✔️Техническая подкованность: Знать, как собираются данные. Возможно, «падение» — это сбой в передаче данных между системами.
Итог:
Умение читать графики — это способность видеть за цифрами — процессы, за процессами — людей, а за людьми — мотивы и ошибки. Пригодится и аналитикам, и продактам, и управленцам 🩶
Привет, друзья! ☕️
Вся аналитика держится на одной простой мысли: цифры не врут, но их можно заставить лгать. Давайте учиться смотреть на них с подозрением. Это и есть профессиональный навык.
Тренировка №1: Игра в «А что если?»
Каждый график рассказывает историю. Ваша задача — найти альтернативные сценарии, которые могли бы привести к той же картинке.
Пример:
Вы видите резкий рост продаж в декабре.
Первая мысль: «Отлично поработали!»
Правильная мысля: «Это могло быть вызвано:
1. Новой акцией
2. Падением продаж в ноябре (и декабрь просто компенсация)
3. Технической ошибкой в сборе данных
4. Тем, что конкурент ушёл с рынка
...и ещё 5 вариантов».
Упражнение: Возьмите любой график из ваших отчётов и придумайте 3 разных объяснения одному и тому же движению линии. Это развивает критическое мышление.
Тренировка №2: Искать невидимое
Хороший аналитик смотрит на то, что не показано. Задайте себе контрольные вопросы:
1. Что скрывает масштаб? (Если ось Y начинается не с нуля, рост может быть преувеличен)
2. Где пропали данные? (Разрывы в графике — это часто важнее, чем сами точки)
3. Что находится «за кадром»? («Смотрите, выручка упала!»
А на деле — это октябрь, и мы просто забыли, что в прошлом году в этом месяце был мега-кэшбэк от партнёра, который мы не повторили.)
Лайфхак: Всегда смотрите на абсолютные значения, даже когда вам показывают проценты. Рост на 200% — это от 1 до 3 клиентов или от 1000 до 3000?
Что развивают эти тренировки:
✔️Историческая память: Вести дневник аномалий. «В прошлом году в этот период тоже был скачок — почему?»
✔️Бизнес-грамотность: Понимать, какие внешние факторы влияют на метрики (сезонность, рынок, конкуренты).
✔️Техническая подкованность: Знать, как собираются данные. Возможно, «падение» — это сбой в передаче данных между системами.
Итог:
Умение читать графики — это способность видеть за цифрами — процессы, за процессами — людей, а за людьми — мотивы и ошибки. Пригодится и аналитикам, и продактам, и управленцам 🩶
❤7👍3🔥2
📊 Инфляция: почему в новостях 6%, а в кошельке — все 15%
Привет, друзья! ☕️
В ДМС мы постоянно считаем инфляцию медицинских услуг. И каждый раз утыкаемся в одно и то же расхождение: официальная статистика и реальные ощущения живут в параллельных вселенных. Давайте разберёмся, почему так происходит и где здесь зарыта аналитическая собака.
Как считают официальную инфляцию
Росстат берёт корзину товаров и услуг, смотрит их цены каждый месяц, а потом считает средневзвешенный рост за год. Ключевое слово — «средневзвешенный» и «календарный».
Пример: Допустим, МРТ подорожало на 12% в декабре 2025-го. Вклад этого подорожания в годовую инфляцию-2025 составит примерно... +1%. Потому что 11 месяцев в году цена была старой, и только один месяц — новой.
Как инфляция бьёт по кошельку
А теперь представьте, что вы делаете МРТ каждый месяц (не дай бог, конечно). С декабря вы платите на 12% больше. И все ваши будущие покупки — тоже на 12% больше. Для вашего личного бюджета инфляция по этой услуге — честные 12%.
Разница в том, что:
▫️Официальная статистика смотрит на изменение за период (усреднённо и с весами)
▫️Ваш кошелек смотрит на точку отсчёта всех будущих трат
Где ещё встречается такой эффект?
В ДМС мы видим это постоянно. Медицинские услуги дорожают неравномерно:
▫️В январе подняли цены на стоматологию
▫️В марте — на лабораторные анализы
▫️В сентябре — те, кто не делал этого с января
Официальная инфляция по медицине за год может показать скромные 5-7%, тк всегда есть учреждения, которые цены не повышали. Но если вы болели в этом году, ваша личная «медицинская инфляция» легко составит 10-15%, потому что вы застали все подорожания по факту их наступления и скорее всего, в 1-2 поликлиниках, которые посещаете.
Почему это важно понимать
✔️Никто не врёт — просто используются разные метрики для разных задач. Росстату нужно сравнивать годы между собой, а вам — планировать бюджет.
✔️В аналитике вообще много таких «двойных» показателей:
· Среднее и медианное
· Моментальное и накопленное
· За период и на конец периода
✔️Вывод: Когда слышите «инфляция 6%», всегда уточняйте — для кого и с какого момента. Для макроэкономики — да. Для вашего кошелька — почти наверняка нет.
Скоро разберём ещё пару коварных метрик.
Подписывайтесь, чтобы не пропустить🩶
DataDrivenManagement
Привет, друзья! ☕️
В ДМС мы постоянно считаем инфляцию медицинских услуг. И каждый раз утыкаемся в одно и то же расхождение: официальная статистика и реальные ощущения живут в параллельных вселенных. Давайте разберёмся, почему так происходит и где здесь зарыта аналитическая собака.
Как считают официальную инфляцию
Росстат берёт корзину товаров и услуг, смотрит их цены каждый месяц, а потом считает средневзвешенный рост за год. Ключевое слово — «средневзвешенный» и «календарный».
Пример: Допустим, МРТ подорожало на 12% в декабре 2025-го. Вклад этого подорожания в годовую инфляцию-2025 составит примерно... +1%. Потому что 11 месяцев в году цена была старой, и только один месяц — новой.
Как инфляция бьёт по кошельку
А теперь представьте, что вы делаете МРТ каждый месяц (не дай бог, конечно). С декабря вы платите на 12% больше. И все ваши будущие покупки — тоже на 12% больше. Для вашего личного бюджета инфляция по этой услуге — честные 12%.
Разница в том, что:
▫️Официальная статистика смотрит на изменение за период (усреднённо и с весами)
▫️Ваш кошелек смотрит на точку отсчёта всех будущих трат
Где ещё встречается такой эффект?
В ДМС мы видим это постоянно. Медицинские услуги дорожают неравномерно:
▫️В январе подняли цены на стоматологию
▫️В марте — на лабораторные анализы
▫️В сентябре — те, кто не делал этого с января
Официальная инфляция по медицине за год может показать скромные 5-7%, тк всегда есть учреждения, которые цены не повышали. Но если вы болели в этом году, ваша личная «медицинская инфляция» легко составит 10-15%, потому что вы застали все подорожания по факту их наступления и скорее всего, в 1-2 поликлиниках, которые посещаете.
Почему это важно понимать
✔️Никто не врёт — просто используются разные метрики для разных задач. Росстату нужно сравнивать годы между собой, а вам — планировать бюджет.
✔️В аналитике вообще много таких «двойных» показателей:
· Среднее и медианное
· Моментальное и накопленное
· За период и на конец периода
✔️Вывод: Когда слышите «инфляция 6%», всегда уточняйте — для кого и с какого момента. Для макроэкономики — да. Для вашего кошелька — почти наверняка нет.
Скоро разберём ещё пару коварных метрик.
Подписывайтесь, чтобы не пропустить🩶
DataDrivenManagement
❤5👍2🔥2❤🔥1🥰1👌1😐1
☢️ Токсичные метрики: как красивые цифры убивают ваш бизнес
Привет, друзья! ☕️
В data-driven культуре есть негласное правило: «что измеряется, то управляется». Но часто мы начинаем управлять не бизнес-результатом, а самой метрикой — и это лучший способ незаметно проехать мимо цели.
Вот 3 признака, что ваша метрика стала токсичной:
1. Она растёт, а бизнес — нет.
Классика: «количество выполненных задач» в тикете у поддержки. Агенты закрывают сотни обращений, но клиенты всё равно недовольны. Потому что метрика поощряет скорость, а не решение. Вы управляете активностью, а не эффективностью.
2. Её можно «накрутить» без реальных изменений.
Пример: NPS (индекс лояльности). Команда начинает массово «просить» клиентов ставить 10 баллов, давит на жалость или даёт бонусы за высокие оценки. Цифра растёт, а качество сервиса — нет. Вы управляете цифрой, а не опытом.
3. Она создаёт конфликт вместо синергии.
Когда отдел продаж бьётся за «объём выручки», а сопровождение — за «снижение дебиторки», они начинают работать друг против друга. Продажи сбивают цены и дают длинные отсрочки «любой ценой». Вы управляете локальными целями, разрывая бизнес-процесс.
Что делать?
Прежде чем внедрить любую новую метрику, спросите:
✔️Достижение какой цели будет мерить эта метрика?
✔️Как именно команда сможет на неё повлиять прямым действием?
✔️Как её рост или падение напрямую повлияют на сборы/выручку/денежный поток через 90 дней?
Инсайт: Настоящая data-культура начинается, когда метрики помогают принимать трудные решения, а не просто отчитываться об их росте. Иногда полезнее отказаться от красивого, но бестолкового показателя.
P.S. Поделитесь в комментариях: а какая «токсичная метрика» в вашей практике создавала больше всего иллюзий? Давайте составим чёрный список.
Подписывайтесь, чтобы не пропустить разбор того, как превратить метрики из инструмента отчётности в инструмент принятия решений.🩶
DataDrivenManagement
Привет, друзья! ☕️
В data-driven культуре есть негласное правило: «что измеряется, то управляется». Но часто мы начинаем управлять не бизнес-результатом, а самой метрикой — и это лучший способ незаметно проехать мимо цели.
Вот 3 признака, что ваша метрика стала токсичной:
1. Она растёт, а бизнес — нет.
Классика: «количество выполненных задач» в тикете у поддержки. Агенты закрывают сотни обращений, но клиенты всё равно недовольны. Потому что метрика поощряет скорость, а не решение. Вы управляете активностью, а не эффективностью.
2. Её можно «накрутить» без реальных изменений.
Пример: NPS (индекс лояльности). Команда начинает массово «просить» клиентов ставить 10 баллов, давит на жалость или даёт бонусы за высокие оценки. Цифра растёт, а качество сервиса — нет. Вы управляете цифрой, а не опытом.
3. Она создаёт конфликт вместо синергии.
Когда отдел продаж бьётся за «объём выручки», а сопровождение — за «снижение дебиторки», они начинают работать друг против друга. Продажи сбивают цены и дают длинные отсрочки «любой ценой». Вы управляете локальными целями, разрывая бизнес-процесс.
Что делать?
Прежде чем внедрить любую новую метрику, спросите:
✔️Достижение какой цели будет мерить эта метрика?
✔️Как именно команда сможет на неё повлиять прямым действием?
✔️Как её рост или падение напрямую повлияют на сборы/выручку/денежный поток через 90 дней?
Инсайт: Настоящая data-культура начинается, когда метрики помогают принимать трудные решения, а не просто отчитываться об их росте. Иногда полезнее отказаться от красивого, но бестолкового показателя.
P.S. Поделитесь в комментариях: а какая «токсичная метрика» в вашей практике создавала больше всего иллюзий? Давайте составим чёрный список.
Подписывайтесь, чтобы не пропустить разбор того, как превратить метрики из инструмента отчётности в инструмент принятия решений.🩶
DataDrivenManagement
❤2🔥2
📦 Big Data в страховании: почему YouTube знает вас лучше, чем ваша страховая
Привет, друзья! ☕️
А чем мы собственно хотим управлять? Что такое эта пресловутая «Big Data» (Большие Данные). Термин заезженный, но то ли это «много данных», то ли что-то «на программистском», поди разбери. А и разберём.
Давайте посмотрим, как работают алгоритмы YouTube или Instagram. Вы только зарегистрировались — платформа уже примерно знает, кто вы: возраст, пол, на какие группы подписаны. Дальше — вы начинаете смотреть видео. Алгоритм фиксирует и записывает в память: досмотрели до конца или закрыли через 10 секунд, поставили лайк, подписались, начали смотреть похожее. Через неделю лента формируется сама, и временами даже откровенно неплохо.
А теперь посмотрим на страховку. Здесь схема сложнее. У нас есть страхователь (кто платит) и застрахованный (кто потребляет услугу). Часто это разные люди: работодатель и сотрудник, родитель и ребёнок. И если мы хотим управлять рисками и убыточностью, нам нужно собирать данные обоих.
Что мы знаем уже сейчас
Стандартный набор страховщика:
· Возраст, пол застрахованного
· Отрасль компании-страхователя
· Кто платит (сам сотрудник или работодатель)
· История обращений
Этого достаточно для базового андеррайтинга. Но это как в YouTube знать только возраст и город пользователя — лента будет так себе.
Что может дать Big Data
Представьте: женщина, 40 лет, двое детей, работает в IT-компании. По стандартной статистике — среднестатистический пользователь поликлиники. Но если копнуть глубже:
· У нее дети — значит, вечером она с ними, на плановые осмотры себя времени почти нет.
· Работа в IT — высокая нагрузка, но и высокий доход, готова платить за комфорт.
· Культура заботы о здоровье — возможно, европейская (чекапы раз в год), а может, советская (только когда припечёт).
· Тревожность — если дети болеют, она вызывает врача на дом или ведёт в поликлинику?
Что мы получаем? Частота обращений в поликлинику зависит не только от реальной заболеваемости, а от наличия времени, уровня тревожности, привычек, дохода. Это всё — прокси-признаки, которые можно собирать:
· Данные из соцсетей
· Геолокация
· Транзакционные данные
· Поведенческие паттерны в вашем приложении
и др.
Зачем это страховщику
• Чтобы точнее предсказывать свои убытки (статистику обращений).
• Чтобы дифференцировать цены на страховку для разных сегментов.
• Чтобы предлагать клиенту персонализированные, нужные именно ему продукты.
Что ждут от аналитиков
Анализировать Big Data — это не про то, чтобы собрать о клиенте «всё подряд». Это про то, чтобы найти, собрать и определить данные, которые отвечают на правильные вопросы:
✔️Какие неочевидные факторы влияют на частоту обращений в нашем портфеле?
✔️Где мы можем достать данные об этих факторах (с согласия клиента, конечно)?
✔️Как объединить разрозненные источники в один портрет?
✔️Какие решения мы примем на основе этого портрета?
Стандартные демографические данные — это лишь вершина айсберга. Под водой — поведение, контекст, привычки. Именно их анализ может превратить страховую из «компании, которая платит по счетам» в «сервис, который заботится». И мы сейчас на пути к этому.. я надеюсь 😬
P.S. Насколько вам подходит формат таких лонгридов? Понятно? Интересно? Ставьте лайк, если все «да» 🩶
DataDrivenManagement
Привет, друзья! ☕️
А чем мы собственно хотим управлять? Что такое эта пресловутая «Big Data» (Большие Данные). Термин заезженный, но то ли это «много данных», то ли что-то «на программистском», поди разбери. А и разберём.
Давайте посмотрим, как работают алгоритмы YouTube или Instagram. Вы только зарегистрировались — платформа уже примерно знает, кто вы: возраст, пол, на какие группы подписаны. Дальше — вы начинаете смотреть видео. Алгоритм фиксирует и записывает в память: досмотрели до конца или закрыли через 10 секунд, поставили лайк, подписались, начали смотреть похожее. Через неделю лента формируется сама, и временами даже откровенно неплохо.
А теперь посмотрим на страховку. Здесь схема сложнее. У нас есть страхователь (кто платит) и застрахованный (кто потребляет услугу). Часто это разные люди: работодатель и сотрудник, родитель и ребёнок. И если мы хотим управлять рисками и убыточностью, нам нужно собирать данные обоих.
Что мы знаем уже сейчас
Стандартный набор страховщика:
· Возраст, пол застрахованного
· Отрасль компании-страхователя
· Кто платит (сам сотрудник или работодатель)
· История обращений
Этого достаточно для базового андеррайтинга. Но это как в YouTube знать только возраст и город пользователя — лента будет так себе.
Что может дать Big Data
Представьте: женщина, 40 лет, двое детей, работает в IT-компании. По стандартной статистике — среднестатистический пользователь поликлиники. Но если копнуть глубже:
· У нее дети — значит, вечером она с ними, на плановые осмотры себя времени почти нет.
· Работа в IT — высокая нагрузка, но и высокий доход, готова платить за комфорт.
· Культура заботы о здоровье — возможно, европейская (чекапы раз в год), а может, советская (только когда припечёт).
· Тревожность — если дети болеют, она вызывает врача на дом или ведёт в поликлинику?
Что мы получаем? Частота обращений в поликлинику зависит не только от реальной заболеваемости, а от наличия времени, уровня тревожности, привычек, дохода. Это всё — прокси-признаки, которые можно собирать:
· Данные из соцсетей
· Геолокация
· Транзакционные данные
· Поведенческие паттерны в вашем приложении
и др.
Зачем это страховщику
• Чтобы точнее предсказывать свои убытки (статистику обращений).
• Чтобы дифференцировать цены на страховку для разных сегментов.
• Чтобы предлагать клиенту персонализированные, нужные именно ему продукты.
Что ждут от аналитиков
Анализировать Big Data — это не про то, чтобы собрать о клиенте «всё подряд». Это про то, чтобы найти, собрать и определить данные, которые отвечают на правильные вопросы:
✔️Какие неочевидные факторы влияют на частоту обращений в нашем портфеле?
✔️Где мы можем достать данные об этих факторах (с согласия клиента, конечно)?
✔️Как объединить разрозненные источники в один портрет?
✔️Какие решения мы примем на основе этого портрета?
Стандартные демографические данные — это лишь вершина айсберга. Под водой — поведение, контекст, привычки. Именно их анализ может превратить страховую из «компании, которая платит по счетам» в «сервис, который заботится». И мы сейчас на пути к этому.. я надеюсь 😬
P.S. Насколько вам подходит формат таких лонгридов? Понятно? Интересно? Ставьте лайк, если все «да» 🩶
DataDrivenManagement
❤5👍3🔥2
📊 Средняя зарплата 160 тысяч, но вы получаете 100? Добро пожаловать в мир статистики
Привет, друзья! ☕️
Знакомая картина: выходит новость «Средняя зарплата в регионе — 160 тысяч», а вы с друзьями в мессенджере переглядываетесь и не понимаете, где эти деньги раздают. Всё дело в том, что среднее арифметическое — это такой товарищ, который любит приврать в компании богатых родственников.
Давайте на простом примере разберёмся, чем отличаются среднее, медиана и мода, и когда на какой показатель смотреть.
Встречаем отдел из 10 человек
Вот их зарплаты:
1 стажёр — 50 000 ₽
7 рядовых сотрудников — по 100 000 ₽
1 ведущий — 150 000 ₽
1 начальник — 700 000 ₽
Считаем:
1. Среднее арифметическое: (50 + 7×100 + 150 + 700) / 10 = 1600 / 10 = 160 000 ₽.
Официально: «средняя зарплата в отделе 160 тысяч».
2. Медиана: сортируем людей по деньгам: 50, 100, 100, 100, 100, 100, 100, 100, 150, 700. Берём середину (пятого и шестого) — оба по 100. Медиана = 100 000 ₽.
Это зарплата «типичного» сотрудника, ровно половина получает меньше, половина — больше.
3. Мода: самое частое значение — 100 000 ₽ (встречается 7 раз).
Что видим: среднее гордо рапортует о 160 тысячах, хотя 9 из 10 получают 150 или меньше, а большинство — вообще 100. Медиана и мода честно говорят: «парни, реальность — это 100».
Зачем это знать в страховании
В наших данных постоянно встречаются такие же «начальники» — крупные убытки, редкие, но дорогие.
✔️Среднее нужно для расчёта общих резервов: если сложить все выплаты и поделить, мы поймём, сколько денег в среднем уходит на один страховой случай.
✔️Медиана покажет типичный размер выплаты: ровно половина клиентов получает меньше этой суммы, половина — больше. Это полезно, когда мы разрабатываем тариф для массового сегмента.
✔️Мода подскажет, какой размер страховой суммы выбирают чаще всего. Именно его стоит ставить в конструктор калькулятора по умолчанию — чтобы клиенту не пришлось листать длинный список.
Правило трёх М (mean, mediane, mode)
M Среднее любит выбросы, но нужно для планирования бюджета.
M Медиана любит правду, её спрашивайте, когда хотите знать «как у всех».
M Мода любит популярность, её используйте в дизайне продуктов.
И главное: когда в следующий раз увидите новость про «среднюю зарплату», вспомните наш отдел. Скорее всего, где-то рядом завалялся большой начальник, который всё испортил.😉
Привет, друзья! ☕️
Знакомая картина: выходит новость «Средняя зарплата в регионе — 160 тысяч», а вы с друзьями в мессенджере переглядываетесь и не понимаете, где эти деньги раздают. Всё дело в том, что среднее арифметическое — это такой товарищ, который любит приврать в компании богатых родственников.
Давайте на простом примере разберёмся, чем отличаются среднее, медиана и мода, и когда на какой показатель смотреть.
Встречаем отдел из 10 человек
Вот их зарплаты:
1 стажёр — 50 000 ₽
7 рядовых сотрудников — по 100 000 ₽
1 ведущий — 150 000 ₽
1 начальник — 700 000 ₽
Считаем:
1. Среднее арифметическое: (50 + 7×100 + 150 + 700) / 10 = 1600 / 10 = 160 000 ₽.
Официально: «средняя зарплата в отделе 160 тысяч».
2. Медиана: сортируем людей по деньгам: 50, 100, 100, 100, 100, 100, 100, 100, 150, 700. Берём середину (пятого и шестого) — оба по 100. Медиана = 100 000 ₽.
Это зарплата «типичного» сотрудника, ровно половина получает меньше, половина — больше.
3. Мода: самое частое значение — 100 000 ₽ (встречается 7 раз).
Что видим: среднее гордо рапортует о 160 тысячах, хотя 9 из 10 получают 150 или меньше, а большинство — вообще 100. Медиана и мода честно говорят: «парни, реальность — это 100».
Зачем это знать в страховании
В наших данных постоянно встречаются такие же «начальники» — крупные убытки, редкие, но дорогие.
✔️Среднее нужно для расчёта общих резервов: если сложить все выплаты и поделить, мы поймём, сколько денег в среднем уходит на один страховой случай.
✔️Медиана покажет типичный размер выплаты: ровно половина клиентов получает меньше этой суммы, половина — больше. Это полезно, когда мы разрабатываем тариф для массового сегмента.
✔️Мода подскажет, какой размер страховой суммы выбирают чаще всего. Именно его стоит ставить в конструктор калькулятора по умолчанию — чтобы клиенту не пришлось листать длинный список.
Правило трёх М (mean, mediane, mode)
M Среднее любит выбросы, но нужно для планирования бюджета.
M Медиана любит правду, её спрашивайте, когда хотите знать «как у всех».
M Мода любит популярность, её используйте в дизайне продуктов.
И главное: когда в следующий раз увидите новость про «среднюю зарплату», вспомните наш отдел. Скорее всего, где-то рядом завалялся большой начальник, который всё испортил.😉
👍4🔥3💯1
👨💻 Product Owner: спаситель процессов или лишняя штатная единица?
Привет, друзья! ☕️
Методологи подготовили регламент, IT настроили интеграцию, продажи обучились, но процесс не взлетел. Пока каждый делал свой кусок, часть ответственных сменилась, стратегию переписали, и никто уже не помнит, зачем все это заказывали.
В больших компаниях это системная боль. И в последние годы появилась роль, которая пытается эту боль лечить — Product Owner (PO).
Когда слышите «продукт», вы думаете о страховом продукте: ДМС, КАСКО, ипотечное страхование. Или о продукте в магазине. А в реальности продукт — это любой процесс, который создаёт ценность. Для внутренних пользователей — тоже.
PO отвечает за то, чтобы процесс (внедрение CRM, новый порядок урегулирования, скоринг-модель) достиг цели и принёс результат. Не за свой кусочек, а за всё целиком.
Почему к PO относятся скептически
В идеале все круто, но в реалиях PO часто становится просто ещё одним согласующим звеном. Было три человека, которые тормозили процесс, стало четыре. PO приходит на встречи, что-то записывает, но ответственность по-прежнему размазана.
Но давайте разберёмся, что это за зверь в идеальном мире.
В чём суть роли
PO не отвечает за этап. Он отвечает за сквозной результат. Его главный вопрос не «сделали ли мы всё по плану?», а «заработало ли это в итоге и дало ли эффект?».
Это как с эстафетой: все бегут свои этапы, палочку передают, но никто не смотрит, прибежал ли последний к финишу. PO — тот, кто стоит на финише и проверяет, что команда вообще туда добежала.
Кейс из страховой практики
Внедряют новый скоринг для андеррайтинга:
· IT сделали интеграцию, отчитались.
· Методологи написали регламенты, разослали.
· Андеррайтеры прошли обучение, расписались.
Проходит месяц. Смотрят данные — скорингом никто не пользуется. Андеррайтеры по старинке считают в Excel. Почему? Потому что в регламенте не прописали, что старую форму надо закрыть, доступы к ней оставили, а в новой интерфейс непривычный — лень.
В традиционной модели каждый сделал свою работу. IT внедрили — да. Методологи описали — да. Обучили — да. А то, что процесс не заработал, — ничья зона.
PO здесь должен был:
1. Ещё на старте сформулировать не «внедрить скоринг», а «добиться, чтобы 80% заявок проходили через новый скоринг через месяц после запуска».
2. Следить за этим показателем ежедневно.
3. Когда увидел, что после обучения цифры не растут, — выяснить причину (доступы неудобные) и продавить решение (убрать старую форму).
4. Довести до финиша, пока метрика не будет достигнута.
При чём тут вообще data-driven
Потому что PO без данных — просто ещё один менеджер с блокнотом. Его главный инструмент — метрики внедрения:
· Сколько пользователей реально используют новый процесс?
· На каком этапе они отваливаются?
· Сколько времени занимает переход между этапами?
· Какая доля заявок прошла по новому пути?
Аналитики нужны PO как воздух, и это не про финансовые метрики, и не про метрики роста продаж, а про метрики успешности внедрения новых процессов. И такие тоже бывают, и про них хорошо бы знать всем аналитикам и продакт оунерам. В идеале. А в жизни пока как получится.
Так что если в вашей большой компании процессы вечно умирают на полпути — возможно, вам не хватает не ресурсов или метрик, а человека, который стоит на финише и проверяет, кто вообще прибежал.
P.S. Признавайтесь, тоже не понимали, зачем на совещание ходят эти бесполезные люди?😉 В следующий раз разберем еще что-нибудь интересненькое. Подписывайтесь, чтобы не пропустить 🩶
DataDrivenManagement
Привет, друзья! ☕️
Методологи подготовили регламент, IT настроили интеграцию, продажи обучились, но процесс не взлетел. Пока каждый делал свой кусок, часть ответственных сменилась, стратегию переписали, и никто уже не помнит, зачем все это заказывали.
В больших компаниях это системная боль. И в последние годы появилась роль, которая пытается эту боль лечить — Product Owner (PO).
Когда слышите «продукт», вы думаете о страховом продукте: ДМС, КАСКО, ипотечное страхование. Или о продукте в магазине. А в реальности продукт — это любой процесс, который создаёт ценность. Для внутренних пользователей — тоже.
PO отвечает за то, чтобы процесс (внедрение CRM, новый порядок урегулирования, скоринг-модель) достиг цели и принёс результат. Не за свой кусочек, а за всё целиком.
Почему к PO относятся скептически
В идеале все круто, но в реалиях PO часто становится просто ещё одним согласующим звеном. Было три человека, которые тормозили процесс, стало четыре. PO приходит на встречи, что-то записывает, но ответственность по-прежнему размазана.
Но давайте разберёмся, что это за зверь в идеальном мире.
В чём суть роли
PO не отвечает за этап. Он отвечает за сквозной результат. Его главный вопрос не «сделали ли мы всё по плану?», а «заработало ли это в итоге и дало ли эффект?».
Это как с эстафетой: все бегут свои этапы, палочку передают, но никто не смотрит, прибежал ли последний к финишу. PO — тот, кто стоит на финише и проверяет, что команда вообще туда добежала.
Кейс из страховой практики
Внедряют новый скоринг для андеррайтинга:
· IT сделали интеграцию, отчитались.
· Методологи написали регламенты, разослали.
· Андеррайтеры прошли обучение, расписались.
Проходит месяц. Смотрят данные — скорингом никто не пользуется. Андеррайтеры по старинке считают в Excel. Почему? Потому что в регламенте не прописали, что старую форму надо закрыть, доступы к ней оставили, а в новой интерфейс непривычный — лень.
В традиционной модели каждый сделал свою работу. IT внедрили — да. Методологи описали — да. Обучили — да. А то, что процесс не заработал, — ничья зона.
PO здесь должен был:
1. Ещё на старте сформулировать не «внедрить скоринг», а «добиться, чтобы 80% заявок проходили через новый скоринг через месяц после запуска».
2. Следить за этим показателем ежедневно.
3. Когда увидел, что после обучения цифры не растут, — выяснить причину (доступы неудобные) и продавить решение (убрать старую форму).
4. Довести до финиша, пока метрика не будет достигнута.
При чём тут вообще data-driven
Потому что PO без данных — просто ещё один менеджер с блокнотом. Его главный инструмент — метрики внедрения:
· Сколько пользователей реально используют новый процесс?
· На каком этапе они отваливаются?
· Сколько времени занимает переход между этапами?
· Какая доля заявок прошла по новому пути?
Аналитики нужны PO как воздух, и это не про финансовые метрики, и не про метрики роста продаж, а про метрики успешности внедрения новых процессов. И такие тоже бывают, и про них хорошо бы знать всем аналитикам и продакт оунерам. В идеале. А в жизни пока как получится.
Так что если в вашей большой компании процессы вечно умирают на полпути — возможно, вам не хватает не ресурсов или метрик, а человека, который стоит на финише и проверяет, кто вообще прибежал.
P.S. Признавайтесь, тоже не понимали, зачем на совещание ходят эти бесполезные люди?😉 В следующий раз разберем еще что-нибудь интересненькое. Подписывайтесь, чтобы не пропустить 🩶
DataDrivenManagement
❤5💯1
🧪 А/В-тесты в страховании, или почему нельзя просто взять и сравнить
Привет, друзья! ☕️
Представьте: вы работаете в страховой компании. Запустили телемедицину в ДМС. Начальство просит оценить эффективность. Логичное решение: берём тех, у кого есть телемедицина, смотрим, сколько они обращаются, сравниваем с теми, у кого её нет. Если у "обладателей" обращений меньше — значит, телемедицина работает, верно?
Верно, но только если вы хотите, чтобы вас вежливо поправили на планерке и больше не доверяли серьёзную аналитику.
Почему это не сработает
Проблема в том, что клиенты с телемедициной и без — это не два одинаковых человека, которые отличаются только наличием услуги. Это, скорее всего, две совершенно разные компании.
Телемедицину чаще применяют:
▫️Современные IT-компании с молодыми сотрудниками, которые и так реже болеют
▫️Или наоборот, производства, где хотят обеспечить медициной работников отдаленных уголков страны
▫️Или вообще банки, где стресс — основной фактор обращений
Вы никогда не поймёте: телемедицина повлияла на обращаемость или просто молодые айтишники реже ходят по врачам. Это как сравнивать пингвинов со слонами и делать выводы о пользе хобота.
Что такое А/В-тест на самом деле
Классический А/В-тест пришёл к нам из науки. Там всё просто: берём случайную выборку, делим на две группы, одной даём волшебную таблетку, другой — пустышку. И смотрим разницу. Никто не знает, кому что досталось, группы одинаковые по всем параметрам, кроме исследуемого.
В бизнесе идеально чисто бывает редко, но принцип тот же: случайность распределения и контроль остальных факторов.
Как это выглядит в страховании
Телемедицина (правильный подход):
Находим крупного клиента с тысячей сотрудников. Делим их случайным образом на две группы (по табельным номерам, например). Одним подключаем телемедицину, другим нет. Через месяц сравниваем количество обращений, больничных, удовлетворённость.
Где подвох
В реальной жизни мы часто идём на компромиссы:
▫️Не всегда можем рандомизировать (этично ли лишать клиента услуги, если она полезна?)
▫️Не хватает трафика (чтобы увидеть разницу, нужно много наблюдений)
▫️Используем "природные эксперименты" — например, запускаем услугу в одних регионах и сравниваем с другими, но тогда приходится учитывать, что регионы и так разные.
Но суть остаётся: хороший аналитик всегда задаст вопрос "А группы точно сопоставимы?", прежде чем делать выводы.
Признавайтесь, кто считал, что быть аналитиком, это — уметь "сравнить две циферки"?
Подписывайтесь, чтобы не пропустить разбор того, как когортный анализ иногда лучше А/В-тестов, особенно когда рандомизация невозможна.🩶
Data Driven Management
Привет, друзья! ☕️
Представьте: вы работаете в страховой компании. Запустили телемедицину в ДМС. Начальство просит оценить эффективность. Логичное решение: берём тех, у кого есть телемедицина, смотрим, сколько они обращаются, сравниваем с теми, у кого её нет. Если у "обладателей" обращений меньше — значит, телемедицина работает, верно?
Верно, но только если вы хотите, чтобы вас вежливо поправили на планерке и больше не доверяли серьёзную аналитику.
Почему это не сработает
Проблема в том, что клиенты с телемедициной и без — это не два одинаковых человека, которые отличаются только наличием услуги. Это, скорее всего, две совершенно разные компании.
Телемедицину чаще применяют:
▫️Современные IT-компании с молодыми сотрудниками, которые и так реже болеют
▫️Или наоборот, производства, где хотят обеспечить медициной работников отдаленных уголков страны
▫️Или вообще банки, где стресс — основной фактор обращений
Вы никогда не поймёте: телемедицина повлияла на обращаемость или просто молодые айтишники реже ходят по врачам. Это как сравнивать пингвинов со слонами и делать выводы о пользе хобота.
Что такое А/В-тест на самом деле
Классический А/В-тест пришёл к нам из науки. Там всё просто: берём случайную выборку, делим на две группы, одной даём волшебную таблетку, другой — пустышку. И смотрим разницу. Никто не знает, кому что досталось, группы одинаковые по всем параметрам, кроме исследуемого.
В бизнесе идеально чисто бывает редко, но принцип тот же: случайность распределения и контроль остальных факторов.
Как это выглядит в страховании
Телемедицина (правильный подход):
Находим крупного клиента с тысячей сотрудников. Делим их случайным образом на две группы (по табельным номерам, например). Одним подключаем телемедицину, другим нет. Через месяц сравниваем количество обращений, больничных, удовлетворённость.
Где подвох
В реальной жизни мы часто идём на компромиссы:
▫️Не всегда можем рандомизировать (этично ли лишать клиента услуги, если она полезна?)
▫️Не хватает трафика (чтобы увидеть разницу, нужно много наблюдений)
▫️Используем "природные эксперименты" — например, запускаем услугу в одних регионах и сравниваем с другими, но тогда приходится учитывать, что регионы и так разные.
Но суть остаётся: хороший аналитик всегда задаст вопрос "А группы точно сопоставимы?", прежде чем делать выводы.
Признавайтесь, кто считал, что быть аналитиком, это — уметь "сравнить две циферки"?
Подписывайтесь, чтобы не пропустить разбор того, как когортный анализ иногда лучше А/В-тестов, особенно когда рандомизация невозможна.🩶
Data Driven Management
❤4
🤖 ИИ-агенты: по следам «обучения»
Привет, друзья! ☕️
Ходила на обучение по ИИ-агентам. Два часа нам старательно показывали, где в интерфейсе какие галочки ставить и как соединять блоки. Про то, зачем это нужно, — в красивой презентации из серии «все обо всем, но ни о чем толком». Понимания появилось примерно ноль.
Если вы тоже наслушались про агентов и не можете уловить, чем они отличаются от обычного ChatGPT, — давайте разбираться вместе.
В чём разница
ChatGPT, DeepSeek, Grok — это языковые модели, в народе «нейронки». Вы спросили — они ответили. Могут написать текст, сгенерировать фото или видео.
ИИ-агент — это цепочка (или граф) узлов вокруг нейронки, каждый из которых что-то делает, и они передают друг другу данные. Он может:
· сам залезть в базу данных и вытащить цифры,
· отправить письмо через корпоративную почту,
· написать и запустить код,
· пройти несколько шагов, запоминая промежуточные итоги
Из чего строится агент
✔️Вход (Trigger или Input)
С чего всё начинается. Это может быть:
· Запрос пользователя в чате
· Сообщение из телеграм-бота
· Файл
· Расписание (каждое утро в 9:00)
✔️Блок обработки (вот тут нейронка, которую вы выбрали + инструкция)
Сюда попадает запрос. Здесь пишут чёткую инструкцию, она же промт: «Ты — помощник страхового агента. Твоя задача — извлечь из сообщения клиента: ФИО, номер полиса, суть обращения». На выходе — структурированные данные.
✔️Блок действий (Tools)
Тут агент начинает что-то делать:
· Проверить статус полиса в базе
· Отправить запрос на расчёт
· Сформировать письмо
· Записать клиента в календарь
✔️Блок принятия решений (Router)
Агент решает: «Если статус полиса активен — иди в блок ответа клиенту. Если не активен — иди в блок запроса недостающих данных».
✔️Блок ответа (Output)
Формирует итоговое сообщение и отправляет клиенту или в систему.
Любые блоки могут повторяться или отсутствовать.
Где таких собирают
Для самостоятельной сборки есть несколько платформ. Самые популярные:
n8n — визуальный конструктор рабочих процессов.
Langflow — open-source фреймворк, тоже с визуальным редактором.
Есть еще другие, но я пока руками щупала только эти.
Ни одного реально работающего ии-агента не собрала, учусь, но уже вижу кучу проблем внедрения в корпоративный мир (привет, бабулька из регистратуры😁).
В штатах взрыв долины сделал OpenClaw (особенно хватят, если к нему прикрутить нейронку Claude Code). Но там все с vpn и ощутимо платно, поэтому чтобы туда лезть, надо точно знать, зачем мне агент вообще😅
Так что для меня пока агенты — это что-то на перспективном. И если обучение сводится к «покрутите блоки в интерфейсе», вряд ли мы скоро стартанем в их массовом внедрении.
P.S. А вы уже пробовали собирать агентов или только приглядываетесь? Если да, на какой платформе?
Продолжение следует.. подписывайтесь, чтобы не пропустить🩶
Data Driven Management
Привет, друзья! ☕️
Ходила на обучение по ИИ-агентам. Два часа нам старательно показывали, где в интерфейсе какие галочки ставить и как соединять блоки. Про то, зачем это нужно, — в красивой презентации из серии «все обо всем, но ни о чем толком». Понимания появилось примерно ноль.
Если вы тоже наслушались про агентов и не можете уловить, чем они отличаются от обычного ChatGPT, — давайте разбираться вместе.
В чём разница
ChatGPT, DeepSeek, Grok — это языковые модели, в народе «нейронки». Вы спросили — они ответили. Могут написать текст, сгенерировать фото или видео.
ИИ-агент — это цепочка (или граф) узлов вокруг нейронки, каждый из которых что-то делает, и они передают друг другу данные. Он может:
· сам залезть в базу данных и вытащить цифры,
· отправить письмо через корпоративную почту,
· написать и запустить код,
· пройти несколько шагов, запоминая промежуточные итоги
Из чего строится агент
✔️Вход (Trigger или Input)
С чего всё начинается. Это может быть:
· Запрос пользователя в чате
· Сообщение из телеграм-бота
· Файл
· Расписание (каждое утро в 9:00)
✔️Блок обработки (вот тут нейронка, которую вы выбрали + инструкция)
Сюда попадает запрос. Здесь пишут чёткую инструкцию, она же промт: «Ты — помощник страхового агента. Твоя задача — извлечь из сообщения клиента: ФИО, номер полиса, суть обращения». На выходе — структурированные данные.
✔️Блок действий (Tools)
Тут агент начинает что-то делать:
· Проверить статус полиса в базе
· Отправить запрос на расчёт
· Сформировать письмо
· Записать клиента в календарь
✔️Блок принятия решений (Router)
Агент решает: «Если статус полиса активен — иди в блок ответа клиенту. Если не активен — иди в блок запроса недостающих данных».
✔️Блок ответа (Output)
Формирует итоговое сообщение и отправляет клиенту или в систему.
Любые блоки могут повторяться или отсутствовать.
Где таких собирают
Для самостоятельной сборки есть несколько платформ. Самые популярные:
n8n — визуальный конструктор рабочих процессов.
Langflow — open-source фреймворк, тоже с визуальным редактором.
Есть еще другие, но я пока руками щупала только эти.
Ни одного реально работающего ии-агента не собрала, учусь, но уже вижу кучу проблем внедрения в корпоративный мир (привет, бабулька из регистратуры😁).
В штатах взрыв долины сделал OpenClaw (особенно хватят, если к нему прикрутить нейронку Claude Code). Но там все с vpn и ощутимо платно, поэтому чтобы туда лезть, надо точно знать, зачем мне агент вообще😅
Так что для меня пока агенты — это что-то на перспективном. И если обучение сводится к «покрутите блоки в интерфейсе», вряд ли мы скоро стартанем в их массовом внедрении.
P.S. А вы уже пробовали собирать агентов или только приглядываетесь? Если да, на какой платформе?
Продолжение следует.. подписывайтесь, чтобы не пропустить🩶
Data Driven Management
❤2👍2
📊 Manus: нейросеть, которая сделает презентацию за вас
Привет, друзья! ☕️
Аналитики много работают с данными. Но рано или поздно наступает момент, когда результаты нужно упаковать в презентацию. И тут выясняется, что красиво оформлять слайды никто не умеет.
Хорошая новость: есть нейросеть (ой, ии-агент🫢), которая решает эту проблему. Плохая: работает она не без танцев с бубном.
Что такое Manus и почему о нём говорят
Manus — это AI-агент, который умеет самостоятельно собирать информацию, анализировать её и на выходе выдавать готовую презентацию. Полноценные слайды с оформлением, структурой и графикой.
1. Заходите на сайт manus.im.
(из России только с vpn)
2. Регистрируетесь через Google-аккаунт.
3. Получаете 1 000 приветственных токенов и по 300 токенов ежедневно — этого хватит на несколько презентаций.
Если пользуетесь часто или нужны масштабные проекты — придётся оформлять платную подписку.
Как ей пользоваться
Самый простой способ — дать прямой промт. Например:
«Создай презентацию на тему развития аналитики в России в 2026 году».
Но если у вас есть конкретный контекст (данные, план выступления, специфическая задача), лучше сделать так:
✔️Идёте в ChatGPT, DeepSeek или любую привычную бесплатную нейронку.
✔️Пишете: «Напиши промт для Manus для создания презентации по следующему контексту: [ваш текст]».
✔️Полученный и проверенный (!) промт закидываете в Manus.
✔️Если промт на английском — уточните в нем: «презентация нужна на русском языке».
✔️Стиль можно доверить нейросети (и поверьте, она в них знает толк) или описать самим.
Готовую презентацию скачиваете в формате PowerPoint или PDF
Важно!
Manus — это публичный AI-агент. Всё, что вы ему отправляете, уходит на обработку во внешнюю систему. Поэтому никаких:
· персональных данных клиентов
· внутренних финансовых показателей
· стратегических планов, которые не для внешних глаз
· неопубликованных отчётностей
Для таких задач — только свои руки и корпоративные инструменты.
Data Driven Management
Привет, друзья! ☕️
Аналитики много работают с данными. Но рано или поздно наступает момент, когда результаты нужно упаковать в презентацию. И тут выясняется, что красиво оформлять слайды никто не умеет.
Хорошая новость: есть нейросеть (ой, ии-агент🫢), которая решает эту проблему. Плохая: работает она не без танцев с бубном.
Что такое Manus и почему о нём говорят
Manus — это AI-агент, который умеет самостоятельно собирать информацию, анализировать её и на выходе выдавать готовую презентацию. Полноценные слайды с оформлением, структурой и графикой.
1. Заходите на сайт manus.im.
(из России только с vpn)
2. Регистрируетесь через Google-аккаунт.
3. Получаете 1 000 приветственных токенов и по 300 токенов ежедневно — этого хватит на несколько презентаций.
Если пользуетесь часто или нужны масштабные проекты — придётся оформлять платную подписку.
Как ей пользоваться
Самый простой способ — дать прямой промт. Например:
«Создай презентацию на тему развития аналитики в России в 2026 году».
Но если у вас есть конкретный контекст (данные, план выступления, специфическая задача), лучше сделать так:
✔️Идёте в ChatGPT, DeepSeek или любую привычную бесплатную нейронку.
✔️Пишете: «Напиши промт для Manus для создания презентации по следующему контексту: [ваш текст]».
✔️Полученный и проверенный (!) промт закидываете в Manus.
✔️Если промт на английском — уточните в нем: «презентация нужна на русском языке».
✔️Стиль можно доверить нейросети (и поверьте, она в них знает толк) или описать самим.
Готовую презентацию скачиваете в формате PowerPoint или PDF
Важно!
Manus — это публичный AI-агент. Всё, что вы ему отправляете, уходит на обработку во внешнюю систему. Поэтому никаких:
· персональных данных клиентов
· внутренних финансовых показателей
· стратегических планов, которые не для внешних глаз
· неопубликованных отчётностей
Для таких задач — только свои руки и корпоративные инструменты.
Data Driven Management
Telegram
Data Driven страхование • Муковозова
Блог Анны Муковозовой:
- ex-начальника Управления ЛС СОГАЗ,ex-начальника андеррайтинга в Ингосстрах
- эксперта Data Science
- автора курсов для страховщиков
datadriven-course.com
Помогаю руководителям и аналитикам принимать решения, основанные на данных
- ex-начальника Управления ЛС СОГАЗ,ex-начальника андеррайтинга в Ингосстрах
- эксперта Data Science
- автора курсов для страховщиков
datadriven-course.com
Помогаю руководителям и аналитикам принимать решения, основанные на данных
👍7
🧠 Почему даже опытный аналитик должен иногда менять очки
Привет, друзья! ☕️
У меня есть один пунктик. Сколько себя помню, я всё время чему-то учусь. Это как зуд: кажется, что если не узнаю, как устроено то, что лежит за горизонтом моей профессии, — мир пройдёт мимо.
Сейчас очередной приступ. Я пошла на курс Вани Замесина по Advanced JTBD.
Курс про продуктовую методологию. Звучит как «не моё», но на деле — чистое расширение сознания. Там и про то, как мозг принимает решения, и про графы работ (это когда ты перестаёшь мыслить «фичами» и начинаешь видеть задачи клиента), и про то, как выбирать наименее затратное решение (спойлер: не всегда то, что кажется дешёвым).
А ещё ABCDX-сегментация, юнит-экономика и даже вайб-кодинг. В общем, набор слов, который на первый взгляд пугает, а на второй — затягивает.
Зачем аналитику это всё
Потому что даже если вы суперпрофи в своей области, смотреть на мир через один и тот же объектив — надёжный способ однажды пропустить что-то важное.
Аналитика — она не про цифры. Она про понимание того, что за цифрами стоит. А за цифрами всегда стоят люди, их задачи, их контекст. И когда ты начинаешь видеть это с другой стороны, твои привычные графики начинают говорить на новом языке.
Почему я про это пишу
Во-первых, чтобы похвастаться, что я снова учусь. А во-вторых (и это серьёзно), чтобы напомнить: даже если вам кажется, что вы уже всё знаете в своей сфере, — это не так. Мир не стоит на месте, и самый ценный навык сейчас — это умение дообучаться.
По мере получения инсайтов буду с вами делиться. Надо? Ставьте реакции, если да)
P.S. Это не реклама. У Вани и без меня 50 тысяч подписчиков. Просто делюсь тем, что зацепило.
https://t.me/zamesin
DataDrivenManagement
Привет, друзья! ☕️
У меня есть один пунктик. Сколько себя помню, я всё время чему-то учусь. Это как зуд: кажется, что если не узнаю, как устроено то, что лежит за горизонтом моей профессии, — мир пройдёт мимо.
Сейчас очередной приступ. Я пошла на курс Вани Замесина по Advanced JTBD.
Курс про продуктовую методологию. Звучит как «не моё», но на деле — чистое расширение сознания. Там и про то, как мозг принимает решения, и про графы работ (это когда ты перестаёшь мыслить «фичами» и начинаешь видеть задачи клиента), и про то, как выбирать наименее затратное решение (спойлер: не всегда то, что кажется дешёвым).
А ещё ABCDX-сегментация, юнит-экономика и даже вайб-кодинг. В общем, набор слов, который на первый взгляд пугает, а на второй — затягивает.
Зачем аналитику это всё
Потому что даже если вы суперпрофи в своей области, смотреть на мир через один и тот же объектив — надёжный способ однажды пропустить что-то важное.
Аналитика — она не про цифры. Она про понимание того, что за цифрами стоит. А за цифрами всегда стоят люди, их задачи, их контекст. И когда ты начинаешь видеть это с другой стороны, твои привычные графики начинают говорить на новом языке.
Почему я про это пишу
Во-первых, чтобы похвастаться, что я снова учусь. А во-вторых (и это серьёзно), чтобы напомнить: даже если вам кажется, что вы уже всё знаете в своей сфере, — это не так. Мир не стоит на месте, и самый ценный навык сейчас — это умение дообучаться.
По мере получения инсайтов буду с вами делиться. Надо? Ставьте реакции, если да)
P.S. Это не реклама. У Вани и без меня 50 тысяч подписчиков. Просто делюсь тем, что зацепило.
https://t.me/zamesin
DataDrivenManagement
🔥6👍3
🏦 Налог на вклады: почему 16% превращаются в 14,5% (и как это влияет на выбор «копить или гасить»)
Привет, друзья! ☕️
Апрель наступил, годовые бонусы выплачены. А значит, снова актуальна извечная дилемма: гасить льготную ипотеку (под 6%) или класть деньги на вклад (под 14%)?
Недавно мы с вами разбирали этот вопрос:
Ипотека vs вклад
Но! Есть важное уточнение. И особенно актуально оно для тех, у кого суммы на руках побольше.
Налог на вклады
Многие слышали: «Налогом облагаются вклады свыше 1 млн», но как это понимать? Налогом облагается не сам вклад, а процентный доход, который превышает определённый лимит.
Этот лимит считается по формуле: 1 млн рублей × максимальная ключевая ставка за год.
На апрель 2026 года максимальная ключевая ставка была 16% (и мы пока не ожидаем, что она вырастет). Соответственно, необлагаемый лимит по доходам за 2026 год составит 160 000 рублей.
Если ваш суммарный процентный доход по всем вкладам за год не превышает 160 000 рублей — налог платить не нужно. Превысили — платите 13% (там есть переход на ставку 15%, но для этого на вкладах должно лежать более 20 млн при текущей ставке).
Как это выглядит на цифрах
Давайте посчитаем реальную доходность после вычета налога для вклада под 16% годовых при условии, что других источников процентного дохода у вас нет (налоговая сама всё суммирует по всем вашим счетам). Во всех примерах ниже я округляю ставку после налога для простоты:
▫️Вклад 1,5 млн рублей: годовой доход — 240 000 ₽. Вычитаем необлагаемые 160 000 ₽ → облагается 80 000 ₽. Налог 13% = 10 400 ₽. Чистый доход = 229 600 ₽. Реальная ставка ≈ 15,3% (разница с заявленными 16% — всего 0,7 п.п.)
▫️Вклад 3 млн рублей: Реальная ставка ≈ 14,6% (разница с заявленными 16% — 1,4 п.п.)
▫️Вклад 5 млн рублей: Реальная ставка ≈ 14,3% (разница — 1,7 п.п.)
Чем крупнее вклад, тем сильнее налог «съедает» доходность, но все это в пределах 2 процентных пунктов.
Что в итоге
Даже после вычета налога вклад под 10-16% выигрывает у ипотеки под 6% с отрывом. Для того, чтобы перестать зарабатывать, вклады должны упасть до 8-9% ставки.
Главное — не забывайте включать налог в свои расчёты, особенно когда речь идёт о суммах выше 1,5-2 млн рублей. И помните, что налоговая сама посчитает и пришлёт уведомление — ничего декларировать не нужно😉
DataDrivenManagement
Привет, друзья! ☕️
Апрель наступил, годовые бонусы выплачены. А значит, снова актуальна извечная дилемма: гасить льготную ипотеку (под 6%) или класть деньги на вклад (под 14%)?
Недавно мы с вами разбирали этот вопрос:
Ипотека vs вклад
Но! Есть важное уточнение. И особенно актуально оно для тех, у кого суммы на руках побольше.
Налог на вклады
Многие слышали: «Налогом облагаются вклады свыше 1 млн», но как это понимать? Налогом облагается не сам вклад, а процентный доход, который превышает определённый лимит.
Этот лимит считается по формуле: 1 млн рублей × максимальная ключевая ставка за год.
На апрель 2026 года максимальная ключевая ставка была 16% (и мы пока не ожидаем, что она вырастет). Соответственно, необлагаемый лимит по доходам за 2026 год составит 160 000 рублей.
Если ваш суммарный процентный доход по всем вкладам за год не превышает 160 000 рублей — налог платить не нужно. Превысили — платите 13% (там есть переход на ставку 15%, но для этого на вкладах должно лежать более 20 млн при текущей ставке).
Как это выглядит на цифрах
Давайте посчитаем реальную доходность после вычета налога для вклада под 16% годовых при условии, что других источников процентного дохода у вас нет (налоговая сама всё суммирует по всем вашим счетам). Во всех примерах ниже я округляю ставку после налога для простоты:
▫️Вклад 1,5 млн рублей: годовой доход — 240 000 ₽. Вычитаем необлагаемые 160 000 ₽ → облагается 80 000 ₽. Налог 13% = 10 400 ₽. Чистый доход = 229 600 ₽. Реальная ставка ≈ 15,3% (разница с заявленными 16% — всего 0,7 п.п.)
▫️Вклад 3 млн рублей: Реальная ставка ≈ 14,6% (разница с заявленными 16% — 1,4 п.п.)
▫️Вклад 5 млн рублей: Реальная ставка ≈ 14,3% (разница — 1,7 п.п.)
Чем крупнее вклад, тем сильнее налог «съедает» доходность, но все это в пределах 2 процентных пунктов.
Что в итоге
Даже после вычета налога вклад под 10-16% выигрывает у ипотеки под 6% с отрывом. Для того, чтобы перестать зарабатывать, вклады должны упасть до 8-9% ставки.
Главное — не забывайте включать налог в свои расчёты, особенно когда речь идёт о суммах выше 1,5-2 млн рублей. И помните, что налоговая сама посчитает и пришлёт уведомление — ничего декларировать не нужно😉
DataDrivenManagement
Telegram
Data Driven страхование • Муковозова
📊 Ипотека vs вклад: как принять решение на данных
Привет, друзья! ☕️
В предновогодней суете работа отходит на второй план, пожалуй, сегодня отклонимся от корпоративной аналитики. Принципы data-driven работают и для личных финансов. У многих из нас есть ипотечные…
Привет, друзья! ☕️
В предновогодней суете работа отходит на второй план, пожалуй, сегодня отклонимся от корпоративной аналитики. Принципы data-driven работают и для личных финансов. У многих из нас есть ипотечные…
👍4🔥2
🤖 Почему ИИ-агенты в больших компаниях — пока еще в стажерах
Привет, друзья! ☕️
Если вас тоже нервируют фразы: заменим целые отделы, автоматизируем всё, агенты будут сами отвечать клиентам, оформлять документы, считать выплаты, — этот пост для вас.
Выдыхаем. В больших компаниях во многом всё по-прежнему. Потому что внедрение упирается в три вещи, которые не лечатся ии-агентом.
Тормоз №1. Безопасность
Агенту нужен доступ к CRM, базам, документам. Дать ему полный доступ — страшно. Ограничить — он не сможет работать.
В итоге компании или используют внешних агентов, но сильно ограниченный доступ, или разворачивают мини-версии агентов во внутреннем контуре с полным доступом, но с мозгами курицы. Функциональность любого варианта сильно ограничена.
Тормоз №2. Ответственность
ИИ-агент отправил клиенту не тот документ. Или неправильно посчитал выплату. Чья вина? Разработчика, который написал промт? Владельца процесса, который дал добро? Самого агента?
Пока этот вопрос не решен даже в юридическом поле, а значит, везде, где поставят работать ии-агентов, между ним и клиентом все равно будет нужен человек.
Тормоз №3. Исходные данные
ИИ-агент, скажем, в аналитике, хорош ровно настолько, насколько хороши данные, к которым его подпустили. Если в CRM клиенты называются «Иванов Иван», «Ivanov», «Иван Иванович (дубль)» — агент будет уверенно их путать, пока человек не напишет в промте/коде, как это обрабатывать.
Если важные данные хранятся в текстовом поле с комментариями «оценка ущерба примерно 10к» — агент не превратит это в столбец с числом. Может, но получив четкую инструкцию. От аналитика. Который никуда не денется, и по-прежнему будет нужен всем, чтобы «хоть кто-то наконец объяснил», что там этот ии-агент насчитал, почему насчитал неправильно и как это чинить.
И вишенка на торте: ии-агенты очень плохо работают с «неизвестно», если у него нет данных, он их может дофантазировать. В любом месте. И поручив ему достаточно комплексную задачу, рискуем на выходе получить неотличимую от правды галлюцинацию.
Зачем я это пишу?
Чтобы вы, читая очередную статью про «внедрили ИИ-агентов и улетели в космос», помнили: в реальной практике применения, а не в инфополе, за кулисами осталось много нерешенных вопросов.
Мир действительно меняется, и игнорировать это глупо. Но и поводов для паники нет. Спокойно и в своем темпе начинаем осваивать новые инструменты, присматриваться к ним, читать обзоры, что-то устанавливать. Не отстанем и не опоздаем, не переживайте! 😉
P.S. Кстати, в маленьких компаниях, возможно, также, если кто есть, откликнитесь в комментариях.
Data Driven Management
Привет, друзья! ☕️
Если вас тоже нервируют фразы: заменим целые отделы, автоматизируем всё, агенты будут сами отвечать клиентам, оформлять документы, считать выплаты, — этот пост для вас.
Выдыхаем. В больших компаниях во многом всё по-прежнему. Потому что внедрение упирается в три вещи, которые не лечатся ии-агентом.
Тормоз №1. Безопасность
Агенту нужен доступ к CRM, базам, документам. Дать ему полный доступ — страшно. Ограничить — он не сможет работать.
В итоге компании или используют внешних агентов, но сильно ограниченный доступ, или разворачивают мини-версии агентов во внутреннем контуре с полным доступом, но с мозгами курицы. Функциональность любого варианта сильно ограничена.
Тормоз №2. Ответственность
ИИ-агент отправил клиенту не тот документ. Или неправильно посчитал выплату. Чья вина? Разработчика, который написал промт? Владельца процесса, который дал добро? Самого агента?
Пока этот вопрос не решен даже в юридическом поле, а значит, везде, где поставят работать ии-агентов, между ним и клиентом все равно будет нужен человек.
Тормоз №3. Исходные данные
ИИ-агент, скажем, в аналитике, хорош ровно настолько, насколько хороши данные, к которым его подпустили. Если в CRM клиенты называются «Иванов Иван», «Ivanov», «Иван Иванович (дубль)» — агент будет уверенно их путать, пока человек не напишет в промте/коде, как это обрабатывать.
Если важные данные хранятся в текстовом поле с комментариями «оценка ущерба примерно 10к» — агент не превратит это в столбец с числом. Может, но получив четкую инструкцию. От аналитика. Который никуда не денется, и по-прежнему будет нужен всем, чтобы «хоть кто-то наконец объяснил», что там этот ии-агент насчитал, почему насчитал неправильно и как это чинить.
И вишенка на торте: ии-агенты очень плохо работают с «неизвестно», если у него нет данных, он их может дофантазировать. В любом месте. И поручив ему достаточно комплексную задачу, рискуем на выходе получить неотличимую от правды галлюцинацию.
Зачем я это пишу?
Чтобы вы, читая очередную статью про «внедрили ИИ-агентов и улетели в космос», помнили: в реальной практике применения, а не в инфополе, за кулисами осталось много нерешенных вопросов.
Мир действительно меняется, и игнорировать это глупо. Но и поводов для паники нет. Спокойно и в своем темпе начинаем осваивать новые инструменты, присматриваться к ним, читать обзоры, что-то устанавливать. Не отстанем и не опоздаем, не переживайте! 😉
P.S. Кстати, в маленьких компаниях, возможно, также, если кто есть, откликнитесь в комментариях.
Data Driven Management
❤6
🌳 ОТ ДЕРЕВА К ГРАФУ: КАК DATA SCIENCE И JTBD ОБЪЯСНЯЮТ ОДНО И ТО ЖЕ С РАЗНЫХ СТОРОН
Привет, друзья!☕️
Данные — это не обязательно таблицы и цифры, любой набор признаков или формализованный учет — это тоже данные, и тоже про data driven. Последние недели я усиленно учусь. А когда учишься, неизбежно формируешь какие-то инсайты в голове. Так вот, я тут переосмыслила одну из самых популярных моделей прогнозирования — дерево решений. Если перевернуть логику от фич к работам, то дерево превращается в граф. Смотрите.
Дерево решений — классика Data Science
Если не сталкивались, на пальцах. Дерево решений — это модель, где набор признаков ведёт к одному-единственному ответу.
Хотим определить, что перед нами за плод? Идём по веткам:
- Красный? → да
- Круглый? → да
- Съедобный? → да
- Растёт на дереве? → нет, в огороде
- Ответ: помидор.
Иногда хватает 5 признаков. Иногда нужно 50 — потому что после 49 у нас всё ещё остаётся выбор между «помидор» и «яблоко». И только признак №50 («растёт в огороде, а не в саду») расщепляет последнюю развилку.
Ключевое: каждый объект ведёт к одному решению. Веточки сужаются, пока не остаётся ровно один ответ. Поэтому это — дерево. Одна вершина, один путь, один листок.
Граф работ — это дерево, которое мутировало в JTBD
На воркшопе по JTBD я увидела конструкцию, которая выглядит почти как дерево, но на самом деле — граф.
Вверху — «большая работа» клиента (Big Job): быть здоровым, быть спокойным за семью, быть успешным. Ниже — работы помельче. В самом низу — конкретные решения, которые клиент «нанимает» на работу.
И вот разница: одно решение может закрывать сразу несколько работ выше уровнем.
Тот же помидор. Решение «съесть помидор» закрывает:
- работу «утолить голод»,
- работу «получить удовольствие» (если люблю помидоры),
- работу «съесть что-то полезное» (если слежу за питанием),
- работу «быть экономным» (если он с дачи, а не из «Азбуки»).
Одно решение → четыре стрелки вверх. Это уже не дерево. Это граф.
Почему это не просто игра терминов
В дереве решений логика предсказательная: «вот признаки — вот единственный ответ». Её задача — классифицировать. Отнести объект к одной категории.
В графе работ логика объяснительная: «вот решение — вот все задачи, которые оно закрывает для клиента». Её задача — понять мотивы. Увидеть, зачем человек делает то, что делает.
И когда смотришь через второе, в голове происходит интересное. Ты начинаешь понимать: клиент редко покупает ваш продукт ради одной задачи. Он покупает его, потому что продукт случайно или намеренно закрывает ему сразу 3–4 верхних работы. И если вы оптимизируете продукт под одну «главную» работу, игнорируя остальные ветки графа — вы сами режете себе ценность.
Инсайт, который я забрала
В личном страховании мы классифицируем клиентов по признакам: количество работников, отрасль, регион основной локации. И пытаемся от этого строить решение, которое им нужно. То же самое и в рознице — фичизм повсюду.
Но клиент живёт не на дереве, а в графе. И у московского коллектива в 500 человек потребность в страховке может закрывать разные "работы": от личных работ менеджера по закупкам до глобальных работ-поручений акционеров. И им нужен разный продукт.
P.S. А вы у себя в работе с кем чаще — с деревом или с графом? Где ваши клиенты и продукты? Интересно собрать срез по разным отраслям.
Data Driven Management
Привет, друзья!☕️
Данные — это не обязательно таблицы и цифры, любой набор признаков или формализованный учет — это тоже данные, и тоже про data driven. Последние недели я усиленно учусь. А когда учишься, неизбежно формируешь какие-то инсайты в голове. Так вот, я тут переосмыслила одну из самых популярных моделей прогнозирования — дерево решений. Если перевернуть логику от фич к работам, то дерево превращается в граф. Смотрите.
Дерево решений — классика Data Science
Если не сталкивались, на пальцах. Дерево решений — это модель, где набор признаков ведёт к одному-единственному ответу.
Хотим определить, что перед нами за плод? Идём по веткам:
- Красный? → да
- Круглый? → да
- Съедобный? → да
- Растёт на дереве? → нет, в огороде
- Ответ: помидор.
Иногда хватает 5 признаков. Иногда нужно 50 — потому что после 49 у нас всё ещё остаётся выбор между «помидор» и «яблоко». И только признак №50 («растёт в огороде, а не в саду») расщепляет последнюю развилку.
Ключевое: каждый объект ведёт к одному решению. Веточки сужаются, пока не остаётся ровно один ответ. Поэтому это — дерево. Одна вершина, один путь, один листок.
Граф работ — это дерево, которое мутировало в JTBD
На воркшопе по JTBD я увидела конструкцию, которая выглядит почти как дерево, но на самом деле — граф.
Вверху — «большая работа» клиента (Big Job): быть здоровым, быть спокойным за семью, быть успешным. Ниже — работы помельче. В самом низу — конкретные решения, которые клиент «нанимает» на работу.
И вот разница: одно решение может закрывать сразу несколько работ выше уровнем.
Тот же помидор. Решение «съесть помидор» закрывает:
- работу «утолить голод»,
- работу «получить удовольствие» (если люблю помидоры),
- работу «съесть что-то полезное» (если слежу за питанием),
- работу «быть экономным» (если он с дачи, а не из «Азбуки»).
Одно решение → четыре стрелки вверх. Это уже не дерево. Это граф.
Почему это не просто игра терминов
В дереве решений логика предсказательная: «вот признаки — вот единственный ответ». Её задача — классифицировать. Отнести объект к одной категории.
В графе работ логика объяснительная: «вот решение — вот все задачи, которые оно закрывает для клиента». Её задача — понять мотивы. Увидеть, зачем человек делает то, что делает.
И когда смотришь через второе, в голове происходит интересное. Ты начинаешь понимать: клиент редко покупает ваш продукт ради одной задачи. Он покупает его, потому что продукт случайно или намеренно закрывает ему сразу 3–4 верхних работы. И если вы оптимизируете продукт под одну «главную» работу, игнорируя остальные ветки графа — вы сами режете себе ценность.
Инсайт, который я забрала
В личном страховании мы классифицируем клиентов по признакам: количество работников, отрасль, регион основной локации. И пытаемся от этого строить решение, которое им нужно. То же самое и в рознице — фичизм повсюду.
Но клиент живёт не на дереве, а в графе. И у московского коллектива в 500 человек потребность в страховке может закрывать разные "работы": от личных работ менеджера по закупкам до глобальных работ-поручений акционеров. И им нужен разный продукт.
P.S. А вы у себя в работе с кем чаще — с деревом или с графом? Где ваши клиенты и продукты? Интересно собрать срез по разным отраслям.
Data Driven Management
❤5👍2