Дерево решений vs граф работ: как я объединила Data Science и JTBD в одном проекте

Небольшой мысленный эксперимент на стыке машинного обучения и продуктового менеджмента. О том, почему одна и та же задача «определить, что нужно клиенту» может выглядеть по-разному со стороны product’а и data scientist’а. Разбор на примере корпоративного ДМС, где у одного контракта сразу три стейкхолдера с разными работами.

Вводная: почему эта тема вообще возникла

Я много лет работаю начальником управления аналитики в страховой компании, а сейчас прохожу курс Ивана Замесина по Advanced JTBD. В какой-то момент на воркшопе меня зацепила структура, которую он назвал «графом работ» — и я поймала себя на мысли, что она похожа на знакомую мне из Data Science модель. Только с противоположным назначением.

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

Часть 1. Дерево решений — как классифицировать объект

Если вы никогда не сталкивались с этой моделью в ML — объясню на пальцах. Дерево решений (Decision Tree) — это модель машинного обучения для задач классификации и регрессии. Её логика предельно простая: набор признаков → один ответ.

Классический учебный пример — определение фрукта или овоща:
— Красный? → да
— Круглый? → да
— Съедобный? → да
— Растёт в огороде? → да
— Ответ: помидор.

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

Ключевые свойства дерева:

• Каждый объект ведёт к одному ответу.

• Веточки сужаются, пока не останется единственный листок.

• Одна вершина — один путь — один результат.

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

В бизнес-аналитике деревья решений применяют для скоринга заёмщиков, сегментации клиентов, прогноза оттока, классификации страховых случаев. Везде, где нужно объект отнести к одной категории. В нашей компании деревья — рабочая лошадка андеррайтинга: «по признакам X, Y, Z этот клиент относится к группе риска №2 с такой-то вероятностью убытка».

Логика предсказательная: «вот признаки — вот единственный ответ». Задача — классифицировать.

Часть 2. Граф работ — как понять мотивы клиента

Теперь посмотрим с другого угла ринга. В JTBD (Jobs To Be Done) есть базовая идея: клиент нанимает продукт на «работу». Буквально это означает, что ему не нужен продукт сам по себе, у него есть конкретная задача, которую продукт должен решить. Клейтон Кристенсен в своих работах называл это «прогрессом клиента».

Advanced JTBD идёт дальше: все работы клиента не болтаются сами по себе, они выстраиваются в граф. Именно граф, а не дерево, как это выглядит при поиске решения классификатором.

Структура графа работ:

• Вверху — Big Job. Верхнеуровневая жизненная задача клиента. «Быть здоровым», «быть спокойным за семью», «чувствовать контроль над жизнью», «быть успешным в профессии». Это не про продукты. Это про то, кем клиент хочет быть.

• Ниже — Middle Jobs. Работы уровнем пониже: «организовать быт так, чтобы оставалось время на семью», «иметь финансовую подушку», «минимизировать неожиданные траты».

• В самом низу — Small Jobs и микрошаги. Конкретные действия, которые клиент совершает: «забронировать билет», «оплатить ДМС», «найти врача». Именно сюда обычно падают продукты.

Одна small job может быть связана стрелками сразу с несколькими работами верхнего уровня.

Возьмём прошлый пример — решение «съесть помидор». Что оно закрывает?

• Работу «утолить голод» (базовая).

• Работу «получить удовольствие» (если помидоры нравятся).

• Работу «съесть что-то полезное» (если следим за питанием).

• Работу «быть экономным» (если помидор с дачи, а не из премиум-магазина).

Одно решение → четыре стрелки вверх. Это уже не дерево. Это граф.

Логика объяснительная: «вот решение — вот все задачи, которые оно закрывает». Задача — понять мотивы. Увидеть, зачем человек делает то, что делает.

Часть 3. В чём принципиальная разница

Если свести два этих инструмента в одну таблицу:

В ML выигрывает модель с минимумом развилок — чем компактнее дерево, тем лучше прогноз. В продукте выигрывает решение, которое закрывает максимум работ — чем больше стрелок вверх, тем сильнее ценностное предложение.

Это противоположные стратегии оптимизации, хотя разбирают они одно и то же.

Часть 4. Кейс из ДМС (розница): как смена угла зрения меняет продукт

Теперь переведём всё это на язык страхования. Начнём с простого случая — розничного клиента, физического лица.

В страховании мы привыкли измерять себя метриками процесса: убыточность, частота обращений, средний чек, доля отказов. Это всё метрики нашего взгляда на клиента — через оптику дерева решений. Мы классифицируем: клиент высокорисковый или низкорисковый, выгодный или невыгодный, активный или пассивный пользователь.

А граф работ возвращает другой вопрос: клиент не нанимал нас на «снижение убыточности». Он нанимал нас на что-то своё. На что?

Разберём на примере розничного ДМС. Клиент — физическое лицо — купил полис. Что он хочет получить?

Очевидная small job: «быстро попасть к врачу, когда заболел».

Но если построить граф выше — что стоит за этой задачей?

• «Не терять рабочий день» → Big Job «быть продуктивным».

• «Не тратить нервы на организацию» → Big Job «сохранять ресурс на главное».

• «Не бояться неожиданного счёта за лечение» → Big Job «чувствовать финансовый контроль».

• «Получить компетентную помощь» → Big Job «заботиться о семье и о себе».

• «Не объяснять ситуацию каждый раз заново» → Big Job «быть услышанным».

Одна small job — пять Big Jobs. Пять параллельных работ, которые клиент надеется закрыть одной покупкой.

А что делает страховая компания?

Мы оптимизируем одну ветку — «быстро попасть к врачу». Добавляем клиники в сеть, сокращаем время ожидания гарантийного письма, запускаем телемедицину. Это закрывает, условно, первую и отчасти четвёртую работу.

А что с остальными четырьмя?

• «Не тратить нервы на организацию» — клиент сам ищет клинику, сам звонит в колл-центр, сам берёт у врача выписку, сам согласует процедуру. Мы на эту работу не наняты, хотя клиент думает, что наняли.

• «Не бояться неожиданного счёта» — в полисе 50 страниц исключений, клиент никогда не знает, покроется ли конкретная процедура, пока не позвонит.

• «Не объяснять заново» — каждый новый оператор задаёт те же вопросы, что и предыдущий.

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

Но с позиции графа работ — мы провалили три работы из пяти. И конкурируем не с другими страховщиками, а с вариантом клиента «заплатить за приём напрямую и не связываться с ДМС вообще».

Часть 5. А теперь самое интересное: B2B и три графа работ вместо одного

Розничный пример хорош для объяснения концепции. Но он оставляет ощущение, что в жизни всё примерно так и устроено. В реальности же B2B-продукты работают сложнее.

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

Стейкхолдер 1. Компания как экономическая единица.

Big Jobs:

• Удерживать персонал (ДМС — стандартная часть соцпакета в России; без него компания проигрывает в конкуренции за кадры).

• Снижать количество больничных и потерь рабочего времени.

• Соответствовать HR-бренду: «мы — работодатель, который заботится о сотрудниках».

• Оптимизировать налоговую нагрузку (расходы на ДМС в пределах 6% от ФОТ не облагаются налогом на прибыль).

Стейкхолдер 2. ЛПР, который принимает решение о покупке.

Это обычно HR-директор, директор по персоналу, реже финансовый директор или генеральный. У ЛПР — свои личные работы, которые часто не совпадают с работами компании:

• Закрыть задачу быстро и без головной боли (тендер, выбор подрядчика, подписание).

• Выглядеть экспертом перед руководством (принять правильное решение, не ошибиться с выбором).

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

• Показать достижимые KPI (снижение больничных, рост удовлетворённости в опросах).

• Иметь «надёжного партнёра», которому можно позвонить в нерабочее время.

Стейкхолдер 3. Сотрудник как конечный пользователь.

Его Big Jobs я уже разбирала выше, но повторю с уточнением:

• Быстро попасть к врачу, когда заболел.

• Не бояться неожиданного счёта за лечение.

• Не тратить нервы на организацию (звонки, согласования, справки).

• Чувствовать, что работодатель заботится.

• Решать проблемы семьи (если полис расширен на членов семьи).

Когда ЛПР подписывает договор с нашей страховой компанией — это одно решение. Но оно должно закрыть работы во всех трёх графах одновременно:

Если мы закрываем только работы сотрудника («быстро к врачу, хорошие клиники») — ЛПР подпишет договор один раз, а при пролонгации уйдёт к конкуренту, потому что мы не закрыли его личные работы. Если мы закрываем только работы ЛПР («удобный документооборот, отчётность, не мешаем»), но сотрудники жалуются — контракт тоже не пролонгируется, потому что компания не видит HR-результата. Если мы закрываем только работы компании («низкая цена, экономия»), но ЛПР хлебает жалобы и сотрудники ненавидят полис — история повторится.

Выигрывает продукт, который закрывает работы во всех трёх графах параллельно.

Часть 6. Что это меняет в аналитике продукта

Когда я смотрю на наш портфель с позиции jbtd, всплывают вопросы, на которые нет ответов в стандартной отчётности:

Чьи работы мы реально закрываем? Если сервисная метрика «время записи к врачу» — для сотрудника, а скорость ответа на запросы HR в колл-центре — для ЛПР, то как понять, всё ли мы делаем для компании как стейкхолдера? Для неё важна совсем другая метрика — снижение больничных, и мы её почти никогда не измеряем в разрезе портфеля.

Кого именно мы теряем при пролонгации? Отказ от договора всегда подаётся с одной причиной («выбрали другого страховщика», «сократили бюджет»), но за этой причиной почти всегда стоит незакрытая работа одного из трёх стейкхолдеров. Разбор оттока через три графа вместо одного — совсем другая история.

Какой стейкхолдер в нашем клиентском пути самый молчаливый? В российской практике это почти всегда сотрудник. У ЛПР есть канал обратной связи — его менеджер со стороны страховой. У компании есть отчётность. А у сотрудника — только жалоба в HR, которая до страховщика доходит в десятой форме.

Какие работы закрываются «случайно»? Есть продукты, которые изначально делались для одной задачи, а потом выяснилось, что они попутно решают ещё три. Телемедицина в ДМС — пример. Её запустили «для удобства и сокращения очередей», а оказалось, что она мощно работает на удержание в регионах, где дефицит клиник. Это побочный эффект, который никто не планировал, но который теперь один из главных продающих аргументов. Найти такие «скрытые» закрытые работы в своём продукте — отдельное аналитическое упражнение.

Часть 7. Где можно и нужно это использовать

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

Дерево решений применяйте, когда:

• Нужно классифицировать объект по признакам (риск, сегмент, категория).

• Стоит задача предсказания (отток, вероятность дефолта, частота обращений).

• Процесс хорошо формализован и поддаётся декомпозиции на бинарные решения.

• Нужна интерпретируемость: руководство хочет видеть, на основе каких признаков модель принимает решение.

Граф работ применяйте, когда:

• Проектируете или пересматриваете продукт.

• Разбираетесь в причинах оттока или низкой конверсии.

• Формулируете коммуникацию для нового сегмента.

• Нужно понять, что ещё клиент получит от вашего продукта, помимо очевидного.

• Работаете в B2B, где у одной покупки несколько стейкхолдеров.

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

В ДМС это выглядит так: мы можем выиграть тендер ценой, мы можем выиграть его сервисом для сотрудников, мы можем выиграть удобством для HR. Но пролонгацию скорее выиграет тот продукт, который делает всё это одновременно.

P.S.

Если тема зашла, у меня есть Telegram-канал Data Driven Management — пишу про корпоративную аналитику, применение JTBD в B2B, метрики и их токсичные формы. Без хайпа, на реальных кейсах из страхования и банкинга.