Как появился JTBD и почему он изменил рынок
В начале 1990-х годов Энтони Ульвик, инженер и предприниматель, сформулировал ключевое наблюдение: люди не покупают продукты — они нанимают их, чтобы выполнить работу.
Клиенту не нужна дрель — ему нужно отверстие.
Не нужен CRM — нужно управлять продажами.
Не нужны курсы — нужно повысить квалификацию.
Это наблюдение легло в основу подхода Outcome-Driven Innovation (ODI), который дал бизнесу:
- язык для описания потребностей через желаемые результаты (Desired Outcomes)
- структурирование работ через Job Map
- разделение на функциональные, эмоциональные и социальные работы
JTBD сделал главное: перевёл разговор с «что мы продаём» на «что клиент пытается сделать».
Это позволило компаниям:
- снижать неопределённость в инновациях
- находить неудовлетворённые потребности
- системно искать точки роста
Но JTBD решает одну часть задачи — понимание рынка. Он почти не отвечает на другой вопрос: как превратить это понимание в предсказуемое выполнение внутри компании?
Главное ограничение JTBD: разрыв между пониманием и исполнением
JTBD отлично работает на уровне:
- стратегии
- продуктовых решений
- customer insight
Но в большинстве компаний он обрывается перед операционной системой.
Типичный сценарий:
- Компания понимает работу клиента
- Формулирует Desired Outcomes
- Передаёт это в продукт/операции
- Дальше начинается интерпретация
На этом этапе возникают проблемы:
- каждый департамент понимает «быстрее», «дешевле», «качественнее» по-своему
- невозможно автоматически проверить достижение результата
- нельзя просчитать альтернативные сценарии
- нет связи с ресурсами и ограничениями
Причина проста: JTBD описывает мир на естественном языке, а операционная система компании работает на формальных моделях.
Пример: «Минимизировать вероятность искажения звука при высокой громкости».
Для человека — это точное требование. Для системы — это неиспользуемый текст, потому что отсутствуют:
- числовое значение
- единица измерения
- контекст применения
- срок
- ограничения
В результате возникает разрыв: рынок понимаем, а выполнять предсказуемо не можем.
Следующий шаг: формализация работы как системы преобразования ресурсов
Чтобы закрыть этот разрыв, нужно перейти от «описания потребности» к «модели выполнения».
Ключевой переход: любая работа — это преобразование ресурсов во времени.
Примеры:
- доставка: товар → перемещение → товар у клиента
- производство: сырьё → обработка → продукт
- IT: требования → разработка → функциональность
- маркетинг: трафик → конверсия → лиды
Это позволяет связать JTBD с операционной реальностью через универсальную модель: Работа = функция преобразования ресурсов.
Тогда:
- Desired Outcome (потребности) становится спецификацией выходного ресурса
- Job Map становится цепочкой преобразований
- Исполнение становится графом работ и ресурсов
Что меняется, когда JTBD становится формальной моделью
В JTBD формулировка Desired Outcome выглядит так: «Снизить время на получение заказа».
Мы предлагаем доработать формулировку потребности и превратить её в требование: «Доставить заказ менее, чем за 2 часа, со стоимостью не более X рублей, по адресу получателя Y».
Теперь система может:
- проверить достижение
- сравнить альтернативы
- оптимизировать
- автоматизировать выбор исполнителя
Архитектура цифровой модели
Чтобы это заработало, вводятся чёткие сущности:
1. Практика (тип работы)
Шаблон выполнения: входные ресурсы, выходные ресурсы, правила преобразования. Аналог: process template / capability.
2. Работа (экземпляр)
Конкретный запуск практики: срок, объём, ограничения. Аналог: process instance / заказ.
3. Производящая система
Любой исполнитель: команда, подрядчик, станок, IT-сервис, AI-агент. Критерий: способность выполнять практику.
4. Ресурсы
Универсальный язык системы: материальные (товар, сырьё), финансовые, информационные, временные, мощности.
5. Контракт
Формализованное соглашение: что должно быть произведено, с какими метриками, в какие сроки. Это аналог SLA, но применённый ко всем работам.
Генеративный дизайн работ
Когда модель формализована, появляется следующий уровень — генеративный выбор решений.
Система получает цель: «Произвести 100 единиц продукта с качеством X к дате Y при стоимости ≤ Z».
И дальше:
- Находит подходящие практики
- Подбирает доступные производящие системы
- Строит граф работ
- Проверяет ограничения
- Генерирует альтернативные сценарии
- Выбирает оптимальный
Это и есть генеративный дизайн работ — автоматический подбор способа достижения цели в заданных ограничениях.
Реальная ценность для бизнеса
Это не про «ещё одну модель». Это про конкретные эффекты:
- Скорость решений — минуты вместо недель
- Предсказуемость — результат считается, а не обсуждается
- Масштаб — управление тысячами работ одновременно
- Адаптивность — перестройка при сбое в реальном времени
- Экономика — оптимизация ресурсов, а не только процессов
Стоимость и риски: что важно понимать CEO
Это не бесплатная трансформация. Основные барьеры:
- необходимость формализации данных
- сопротивление организации
- качество исходных метрик
- сложность модели
Где начинать безопасно:
- один контур (например: доставка / производство / IT-разработка)
- ограниченный набор практик
- пилот с измеримым эффектом
С чего начать
- Формализовать 5–10 ключевых потребностей (Desired Outcomes) в виде требований. Не текстом, а в формате: метрика, единица, диапазон, срок.
- Выделить 5–10 практик — что вы реально делаете регулярно, какие ресурсы преобразуются.
- Описать ресурсы — входы, выходы, ограничения.
- Запустить пилотную модель — Excel / Python / простая система, один сценарий, сравнение вариантов.
- Проверить экономический эффект — время, стоимость, загрузка ресурсов.
Заключение
JTBD изменил то, как мы узнаём потребности клиентов. Следующий этап — изменить то, как мы исполняем работу внутри компании.
Переход от:
- инсайтов к моделям
- гипотез к расчёту
- управления к проектированию
Компании, которые сделают этот шаг, получают не просто преимущество. Они получают способность проектировать результат так же, как инженеры проектируют системы — через расчёт, ограничения и оптимизацию. И именно это становится новым полем конкурентной борьбы.