Коротко: что это вообще такое и почему HR пора перестать делать вид, что «курс пройден» значит «навык появился»

Таксономия Блума – это модель, которая помогает понять, какого мышления мы ждём от сотрудника после обучения. Не просто «пусть изучит тему», «пусть повысит осознанность» или «пусть станет клиентоориентированнее», потому что от таких формулировок у методиста начинает дёргаться глаз, а у бизнеса – бюджет. Смысл модели в другом: перевести обучение в наблюдаемое действие. Что человек должен сделать на работе: вспомнить правило, объяснить ситуацию, применить инструкцию, разобрать кейс, оценить решение или создать новый рабочий продукт.

Для корпоративного обучения это особенно полезно, потому что HR, L&D, методист и внутренний заказчик часто спорят не о курсе, а о разных ожиданиях. Заказчик говорит: «Нужно, чтобы менеджеры лучше работали с клиентами». Методист слышит: «Сделаем модуль, тест и сертификат». Руководитель потом смотрит на реальные звонки и понимает, что сертификат есть, а чуда нет. Неловко, но жизненно.

Таксономия целей Блума помогает договориться на берегу: какое рабочее поведение нужно получить, в каких условиях сотрудник должен действовать, насколько самостоятельно и как мы поймём, что результат действительно достигнут. Это особенно актуально сейчас, когда компании всё чаще говорят не о дипломах и стаже, а о конкретных навыках. По данным исследования hh.ru, 93% работодателей в разной степени испытывают нехватку навыков, а 68% компаний уже используют навыкоцентричный подход хотя бы частично hh.ru, исследование «Будущее навыкоцентричности».

Но важная ремарка: таксономия Блума не гарантирует мотивацию, перенос навыка в работу и рост бизнес-показателей сама по себе. Она не магический артефакт из шкафа L&D. Она помогает связать цель, практику, критерии и оценку. А дальше уже начинается взрослая работа: нормальная методика, адекватные задания, руководитель, обратная связь и проверка результата в реальности.

Главная ошибка корпоративного обучения: список тем вместо рабочего результата

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

Можно собрать курс из тем: «Продукт», «Целевая аудитория», «Скрипт звонка», «Работа с возражениями», «CRM». На вид всё прилично, солидно, даже слегка пахнет согласованной презентацией. Но список тем не отвечает на главный вопрос: что сотрудник должен уметь делать после обучения?

Он должен помнить преимущества продукта? Понимать, кому он подходит? Применять скрипт? Анализировать заявку? Оценивать качество диалога? Создавать индивидуальный план следующего касания? Это разные уровни таксономии Блума, и под каждый нужны разные задания, тренировка и оценка.

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

Не пирамида успеха, а рабочая карта: как устроена современная таксономия Блума

Классическая таксономия Блума появилась в 1956 году. В ней были уровни: знание, понимание, применение, анализ, синтез и оценка. Но для корпоративного обучения удобнее использовать пересмотренную модель 2001 года Андерсона и Кратвола. В ней процессы названы глаголами: помнить, понимать, применять, анализировать, оценивать и создавать. Также отдельно выделены четыре типа знаний: фактическое, концептуальное, процедурное и метакогнитивное.

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

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

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

Поэтому глагол сам по себе не спасает. «Разобрать заявку» может означать и простое заполнение полей, и глубокий анализ бизнес-контекста. Магия не в слове, а в объекте, условиях, самостоятельности и критериях. Глаголы красивые, но HR-методика всё-таки не конкурс по украшению формулировок.

Один и тот же звонок, шесть разных уровней: где сотрудники реально «плывут»

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

На уровне «понимать» менеджер уже объясняет, зачем эти параметры нужны. Например, почему «у нас 300 сотрудников» ещё не значит «клиент подходит», а фраза «мы просто смотрим рынок» не всегда означает холодный интерес. Здесь сотрудник начинает видеть логику процесса, а не просто читает чек-лист как заклинание.

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

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

Как выбрать нужный уровень и не заставлять всех «создавать стратегию»

Начинать нужно не с вопроса «какой уровень выглядит солиднее», а с рабочего поведения. Что сотрудник должен делать на работе? Что будет, если он ошибётся? Насколько ситуация типовая? Есть ли инструкция, чек-лист или подсказка в системе? Должен ли он действовать самостоятельно? Нужно ли ему объяснять решение другому человеку? Можно ли проверить результат сразу или только через рабочие данные?

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

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

Формулировка цели: место, где обучение либо рождается, либо тихо умирает

Плохая цель звучит так: «После курса сотрудник будет понимать квалификацию B2B-заявок». Почему плохо? Потому что «понимать» здесь ничего не доказывает. Человек может понимать идею, но всё равно плохо проводить звонок, забывать уточняющие вопросы и писать в CRM бессмертное «клиент думает».

Хорошая цель звучит иначе: «После курса менеджер квалифицирует входящую B2B-заявку по пяти критериям, фиксирует данные в CRM и обосновывает решение о следующем шаге». Здесь уже видны действие, объект, условия и результат. Это можно тренировать, оценивать и обсуждать с руководителем без шаманства.

Главная проверка простая: требуемое действие, тренировочное действие и оцениваемое действие должны совпадать. Если цель – анализировать заявку, практика не может состоять только из лекции, а оценка – только из теста на термины. Это будет не обучение анализу, а театральная постановка «Мы сделали курс». Костюмы красивые, пользы мало.

Рабочая цепочка такая: сначала определяем рабочий результат, затем тип знания, потом когнитивный процесс, затем практику, критерии и способ оценки. Например, результат – квалифицированная заявка и решение о следующем шаге. Тип знания – процедурное и концептуальное. Процесс – анализировать и оценивать. Практика – разбор диалогов, симуляция звонка, заполнение CRM. Критерии – полнота данных, точность вывода, качество решения. Оценка – кейс, симуляция, экспертная проверка или наблюдение на работе.

Как связать цель обучения с рабочим результатом

ЭтапЧто нужно определитьПример для квалификации B2B-заявки
Рабочий результат Что сотрудник должен сделать после обучения Квалифицировать входящую заявку и выбрать следующий шаг 
Тип знания Какие знания нужны для действия Процедурное: как вести квалификацию. Концептуальное: как связаны боль клиента, бюджет, ЛПР и срочность 
Когнитивный процесс Что происходит в голове сотрудника Анализировать заявку и оценивать её качество 
Практика На чём сотрудник тренируется Разбор диалогов, симуляция звонка, заполнение CRM 
Критерии По каким признакам видно, что задача выполнена хорошо Полнота данных, точность вывода, логика следующего шага 
Оценка Как проверяем результат Кейс, симуляция, экспертная проверка или наблюдение на работе 

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

Рубрика: спасение от оценки в стиле «ну, как-то не очень»

Сложный навык нельзя оценивать по принципу «нравится / не нравится». Нужны критерии. Иначе экспертная оценка превращается в гадание по интонации: «Что-то он неубедительно квалифицировал». Спасибо, очень измеримо, почти наука.

Для сценария с квалификацией заявки критерии могут быть такими: полнота данных, точность вывода, логика решения, качество следующего шага и коммуникация. Полнота показывает, собрал ли менеджер ключевую информацию. Точность – отделил ли явные слова клиента от реальных признаков потребности. Логика – связал ли проблему клиента с возможностями продукта. Решение – выбрал ли следующий шаг и объяснил почему. Коммуникация – задал ли уточняющие вопросы нормально, а не устроил клиенту допрос под лампой.

Сильный результат выглядит так: менеджер видит, что клиент пока не назвал бюджет, но обозначил срочный срок, внутреннюю проблему и роль руководителя в решении. Он не отправляет заявку в мусор, а назначает уточняющий звонок с вопросами про процесс выбора и участников решения. Пограничный результат – основные данные собраны, но менеджер не заметил противоречие: клиент говорит «мы просто изучаем», хотя дальше описывает срочную боль. Недостаточный результат – в CRM появляется запись «интересуются продуктом», без роли собеседника, сроков, задачи и следующего шага. То есть корпоративная версия записки «кто-то звонил, кажется, важное».

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

Онлайн-тест не виноват, что его заставляют проверять всё подряд

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

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

Для нашего сценария логика может быть такой. На старте – короткий тест на знание критериев. В практике – симуляция звонка и разбор кейса. В итоговой оценке – квалификация сложной заявки по рубрике. После обучения – выборочная проверка реальных CRM-карточек и обратная связь руководителя.

Так мы не подменяем рабочий результат баллом за тест. В пересмотренной таксономии Блума оценка должна быть связана с целями и обучением: авторы модели подчёркивали важность согласования целей, учебных действий и assessment.

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

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

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

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

Важно не приписывать улучшение только курсу или таксономии Блума. На результат влияют скрипты, мотивация, нагрузка, качество лидов, CRM, руководитель, сезонность и ещё половина офисной вселенной. Таксономия помогает спроектировать обучение, но не отменяет организационный контекст.

Где здесь LMS: платформа не делает магию, но отлично собирает доказательства

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

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

Но LMS не доказывает перенос сама по себе. Она хранит следы обучения и помогает управлять процессом. Рабочее поведение всё равно нужно проверять через реальные данные: CRM, наблюдение, качество заявок, действия руководителя. Это важное ограничение, потому что на рынке любят продавать платформу как ответ на всё. А потом выясняется, что платформа прекрасная, но цель обучения была сформулирована как «повысить эффективность сотрудников». То есть никак.

В отчёте hh.ru о навыкоцентричности отдельно отмечается, что развитие подхода требует таксономий навыков и автоматизированных систем оценки результатов работы hh.ru, исследование «Будущее навыкоцентричности». Но система не заменяет методическое решение. Она его поддерживает. И это хорошая новость: сначала думаем, потом автоматизируем. Хотя, конечно, купить платформу быстрее, чем договориться о критериях.

Что LMS помогает зафиксировать

  1. Прохождение обучения: кто начал курс, кто завершил, где завис и сколько попыток сделал.
  2. Результаты тестов: как сотрудник усвоил факты, термины, правила и базовые требования.
  3. Практические задания: кейсы, файлы, заполненные шаблоны, письменные разборы и ответы.
  4. Оценку по критериям: баллы, комментарии эксперта, рубрику и причины итогового решения.
  5. Повторные попытки: первую версию работы, обратную связь, исправления и итоговый результат.
  6. Слабые места: темы, задания и критерии, где чаще всего возникают ошибки.
  7. Динамику по группам: различия между командами, ролями, потоками обучения или филиалами.
  8. Сигналы для руководителя: кому нужна практика, кому обратная связь, а кому уже пора применять навык в работе.
  9. Следы для аналитики: данные, которые можно сопоставить с CRM, качеством заявок, продажами или другими рабочими показателями.

Бизнес-вывод: LMS не создаёт навык сама по себе. Она помогает увидеть, где сотрудник учился, что сделал, как был оценён и какие следы результата можно связать с реальной работой.

ИИ в обучении: полезный помощник или новый способ красиво списывать?

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

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

Быстрый шаблон: как собрать обучение по таксономии Блума без методического шаманства

Чтобы применить таксономию Блума в корпоративном обучении, не нужно начинать с огромной матрицы на 47 строк. Достаточно пройти несколько вопросов по одной роли и одной рабочей задаче.

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

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

Для нашего сценария это может выглядеть так: бизнес-задача – повысить качество квалификации входящих B2B-заявок. Роль – менеджер по продажам. Рабочее поведение – квалифицирует заявку, фиксирует данные в CRM и выбирает следующий шаг. Тип знания – процедурное и концептуальное. Когнитивный процесс – для новичка применять, для опытного менеджера анализировать и оценивать. Практика – симуляция звонка, разбор диалога, заполнение карточки. Оценка – кейс и экспертная проверка по рубрике. Перенос – выборочная проверка CRM-карточек через 2-4 недели.

Итог: таксономия Блума нужна не для красивого ТЗ, а для честного разговора с бизнесом

Таксономия Блума в корпоративном обучении помогает задать неприятный, но полезный вопрос: что именно человек должен уметь делать после курса? Не «пройти модуль», не «ознакомиться», не «повысить осведомлённость», а выполнить рабочее действие в конкретных условиях и показать результат, который можно проверить.

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

Хорошее корпоративное обучение начинается не с LMS и не с дизайна слайдов. Оно начинается с честной формулировки результата. А дальше уже можно спорить о методах, заданиях, платформе, аналитике и красивой кнопке «завершить курс». Желательно за кофе. Там HR-истина почему-то усваивается быстрее.