Эффективность = результативность?

[Elena Lokteva]

Мы часто оперируем понятием эффективности обучения. А мне за последний месяц довелось столкнуться с двумя точками зрения на эту тему.

Мнение 1. Эффективность обучения = результативность обучения.
То есть оценить эффективно или не очень прошло обучение, можно только оценив его результаты. Да и то не сразу ;)

Мнение 2. Эффективность обучения <> результативность обучения.

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

А ваше мнение, коллеги? :)

[Дорн Юрий]

Менеджер проекта - ок. Роль действительно решительно важная.
Но каков наш объект обсуждения?
На кого свалить обязаность считать?
Или все же что именно нужно считать и как? Или что такое эффективность и результативность и как они связаны?

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

[Elena Tikhomirova]

Тут полностью согласна - педдизайнер работает с материалом, с последовательностями, с элементами и прочим. Да, в классике педдизайна - есть анализ потребностей, есть "evaluation", но это не оценка финансовой эффективности, а свод того что сделано с тем, что нужно было сделать. Педдизайнеру результаты анализа потребностей и постановку целей всегда подтверждает бизнес, никогда он сам этого не делает. Он собирает потребности в обучении, понимает их, трансформирует цели обучения в учебные цели и делает курс.

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

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

[Наумов Владимир]

Елена, совершенно согласен с Вами.

Кроме одной мелочи: ТЗ далеко не всегда дают, по моим наблюдениям, на практике чаще их сами педдизайнры если не единолично делают, то исходные черновики готовят, а после резолюций свыше сами и правят.

И еще нюанс: поскольку у нас в компаниях ДО занимаются 2-3 человека обычно, им и приходится кучу ролей исполнять, в том числе и обоснование (а то и обсчет) экономической эффективности сочинять. Се ля ви у нас такая :)

[Elena Tikhomirova]

Это верно.

Я уж прям боюсь что-то писать :)

Я вообще давно не видела нормального ТЗ. Так что коллеги, если будет - дайте хоть одним глазком посмотреть, уж очень соскучилась :)

[Наумов Владимир]

Задумался, а симптомом чего, какой "хвори"-причины является такая практика работы с ТЗ.
На чьей она стороне, эта "хворь", неужели заказчиков?
А, может быть, при создании курсов формат ТЗ (штука вполне стандартизированная и управленческая по природе) не совсем-то и годится по определению?

[Дорн Юрий]

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

[Наумов Владимир]

В моей практике была такая схема: запрос на курс -> его дизайнер готовит идею (в виде предъявления психолого-педагогического механизма и основных приемов, обеспечивающих желательные изменения в обучаемых) -> утверждение идеи - мозг.штурм по идеологии ТЗ -> дизайнер пишет ТЗ "под себя" и передает дальше - > менеджер проекта / заказчик иные специалисты рассматривают и дают свое видение (улучшения/пожелания/ финансовую оптимизацию и просят о последней и дизайнера) и возвращают дизайнеру - > дизайнер курса дописывает ТЗ - > совместное окончательное редактирование ТЗ - > утверждение / неутверждение

[Elena Tikhomirova]

Коллеги!

Почти в таком же составе мы обсуждали уже эту тему.

Если сегодня дойдут до руки до этого, то напишу краткий обзор всех наших мнений.

[Наумов Владимир]

Было бы здорово получить такой обзор.

Надеюсь и похоже он будет не последним. То, что одна тема обсуждается с перерывами и худо-бедно собирает аудиторию - говорит о наболевшем. Да и содержание обсуждений нимало отличаются. Эх, был бы инструмент автоматического написания обзоров по блогам на одну тему в разных местах и в разное время :)

[Elena Lokteva]

Отвечаю на вопросы, которые задал мне Ян Федянин касательно менеджера проекта разработки курса:
"В недавнем обсуждении по результативности и эффективности, Вы функцию "связки" целей учебного курса со стратегическими целями компании, убрали от пед.дизайнера, также "перенеся" ее на "менеджера проекта".
Как, например, Вы, в качестве "менеджера проекта" это сделали бы? Ведь Ваши профильные компетенции (и большинства специалистов по ДО) лежат все-таки больше в "программисткой" сфере? И чем это отличается от ситуации сейчас, когда Вы, как минимум, "два-в-одном": и менеджер проекта, и пед.дизайнер?"

1. Не знаю, как большинство специалистов по ДО, а мои компетенции лежат все-таки не только и не столько в "программистской" сфере. Гораздо увереннее я себя чувствую как менеджер образовательных проектов, нежели как "программист". Создавать и продвигать учебные программы мне гораздо интереснее, нежели "программить".
2. Менеджер проекта, на мой взгляд, -это именно тот человек, который, получив задачу, планирует, какие ему понадобятся ресурсы (человеческие, временные, информационные, технические, финансовые) и как это обеспечит соответствие конечного продукта требованиям Заказчика. Именно он должен потом обосновать то, что напланировал. Именно он в итоге отвечает за то, насколько то, что он получил, отвечает тому, под чем он подписался, т.е. за сдачу работ.
3. Кроме менеджера проекта есть еще такая роль, как менеджер продукта: представитель от Заказчика. Он как раз отвечает за то, чтобы правильно поставить задачу перед менеджером проекта, согласовать предлагаемые менеджером проекта планы. Он в итоге отвечает за приемку работ.
4. На мой взгляд, именно в компетенцию этих двух ролей (менеджера проекта и менеджера продукта) входит умение сводить цели обучения со стратегическими целями Заказчика.
5. В п.п.1-4 я описала ситуацию, которая на мой взгляд, должна иметь место. Но на практике я с подобной ситуацией столкнулась один-единственный раз в жизни, на проекте, в котором мне отводилась роль именно менеджера проекта. И, к большому сожалению, от проекта пришлось отказаться, и принять в нем участие мне довелось лишь на этапе составления и утверждения ТЗ.
6. Что касается моей текущей ситуации, когда специалист оказывается минимум 2 в 1. Да, ему приходится учиться и эффективность считать, и про денежный привес думать, и вести всю проектную документацию и много чего еще делать, не буду перечислять. Вот только как это влияет на эффективность/результативность бизнеса и на его (бизнеса) финансовые показатели, вопрос очень сложный.
На мой взгляд:
Финансовые плюсы: бизнес платит тебе одному и за все виды работ. Экономия на тебе одном заметная: ты обходишься дешевле внешнего разработчика, в разы, если не в десятки раз.
Финансовые минусы: 1) качество учебного материала падает, а это прямая угроза эффективности обучения; 2) если такой "флакон 2 в 1" уходит из компании, то компания теряет сразу все разработчицкие компетенции (на каком бы уровне они не находились), и придется терять время (а то и деньги) на поиск нового "флакона", на его обучение и адаптацию.

На прошлом месте работы я была таким же "флаконом", и когда ушла, на мои задачи/проекты взяли 3 спецов (очень и очень достойных). Двое из них уже сбежали, и заменить их оказалось некем. Итог: мои "флаконичьи" старания/слезы/пот оказались напрасными, а у моих бывших руководителей теперь определенные проблемы, т.е. пострадали обе стороны, и при этом если я хотя бы в зарплате выиграла, то бизнес кучу денег уже упустил.
И вот теперь на нынешнем месте работы ситуация повторяется: я опять "флакон", и опять в случае чего, вся экономия на мне как на "флаконе" вылезет боком в первую очередь бизнесу. Я сама очень напрягаюсь от того, что представляю сейчас собой такой "флакон". И удивляет меня больше всего то, что я напрягаюсь по этому поводу больше, чем бизнес.
Таким образом, я против "флаконства", против того, что педдизайнер (да и любой другой разработчик) ДОЛЖЕН уметь рассчитывать, как его работа повлияет на финансовые показатели бизнеса. Согласна, что он МОЖЕТ уметь это делать. Для общего развития. Или для того, чтобы выживать во "флаконском" состоянии до тех пор, пока в нем находится.

P.S. Ян, теперь я жду Вашей реакции.

[Yan Fedyanin]

Елена, добрый вечер. Видите - даже прошел процедуру регистрации, чего страшно не люблю делать. Спасибо за подробный ответ.Попытаюсь обосновать свою позицию в рамках поста, если не получится - напишу 4-5 страничную статью. Не будете сильно возражать, если она появится на нашем блоге через какое-то время? Точного срока дать не могу, обещаю не откладывать.

Если же кратко по сути. Продукт-менеджер - проект-менеджер хороши в разовых проектах (как у Вас в проекте для Буки). Там все понятно - четко сформулированное "чего хотим" - не менее четкое - "чего можем". В корпоративном обучении все сложнее - Ваш комментарий очередное этому подтверждение.

В идеале тех.задание на обучение той или иной категории сотрудников на основе результатов оценки разрыва в стратегических компетенциях (необходимых для достижения стратегических целей компании) и проведенной аттестации и/или оценки по 360 градусам должны готовить его (сотрудника) непосредственный руководитель плюс HR и уже сформулированную цель обучения (с показателями оценки эффективности) отдавать руководителю учебного центра. Для этого в компании должны быть прописаны ключевые показатели и поведенческие компетенции - мы об этом уже не раз и два писали. Именно они проводят анкетирование и дают заключение чему должен быть обучен сотрудник - каких знаний, навыков и поведенческих компентенций ему не хватает. Если этого нет - все остальные последующие этапы обучения теряют смысл - это обучение формально, для галочки, а не для результата.

Если оцениваются сами топ-менеджеры, то вместо руководителя подразделения (не генеральный же это будет делать! - наместнику Бога на земле до таких ли мелочей!), то привлекают независимых экспертов. Нас так сейчас ОАО "Роствертол" (крупнейший производитель вертолетов в России) привлек для оценки своих топов - помочь отделу кадров подготовить анкеты для оценки и поприсутствовать на их аттестации.

Но, продолжаем с нашим проектом. Как правило, до таких деталей как карты компетенций и результаты аттестаций никто и никогда не доходит. Есть проблема (возьмем пример, приведенный Еленой Тихомировой): "Срочно надо сократить количество претензий к работе операторов службы поддержки в области обработки замечаний по качеству!" СРОЧНО! НАДО! - Кто должен решать КАК это сделать? Все ОЧЕНЬ заняты - руководитель Службы поддержки в разборке с очередным разбушевавшимся клиентом, HR - в судебных спорах по трудовому кодексу (увольнения! увольнения!), руководитель учебного центра остается один на один с проблемой.

Что делать? Наше мнение - наплевать на то, что должен/не должен делать пед.дизайнер - и начать разбираться С ПРОБЛЕМОЙ! Правильно это? Конечно, нет - не учили, не платят, нет в должностных, не поймут, если все получится - припишут себе, если все провалится - запинают... Надо ли связываться? НАДО. Вооружившись двумя орудиями: 1) не ошибается тот, кто ничего не делает, 2) это все равно лучше, чем "склепать" очередной курс, который опять будет просто "для галочки".

Идем в Службу поддержки, и сидим там два-три дня с блокнотом. Наблюдаем и анализируем. Наблюдаем следующую картину - сотрудники действительно отвечают... как-то неправильно отвечают. кто во что горазд. кто с вызовом - "а вы чего хотели?", кто с унижением - "простите, Ради Христа". Первое замечание - нет стандарта работы с недовольным клиентом. Нет навыков работы в конфликтной ситуации. нет навыка "держать удар", когда клиент переходит границы и т.д. На самом деле очень много можно понять, просто внимательно понаблюдав, что происходит.

Может быть все по другому. Знают, как надо себя вести, но сбиваются, путаются, смущаются, уходят в сторону от сути претензии. Значит стандарты есть, вводный тренинг проведен, что делать - знают, но не делают. Значит разрыв между знанием и навыком, значит надо тренировать до автоматизма и подкреплять "страшилками" почему плохо и "хвалилками" почему хорошо.

Может быть и еще по другому. Знают, умеют, но не делают. Это мотивация. Значит нет наказания, если делают плохо, или награды , если делают хорошо. Нет стимула работать по-другому. Но это решается (если будет на то воля и желание высшего руководства!) только через служебную записку генеральному - с приведенной аналитикой по наблюдениям, подтверждающими Ваши выводы. Здесь учебный центр ничего сделать не может или может, но очень мало.

А в первых двух случаях можно побороться. Это как раз настоящий профессиональный вызов для пед.дизайнера. Цепочку целей вы знаете - сокращение рекламаций к работе операторов - повышение лояльности клиентов к компании - повышение вероятности его повторной покупки - деньги, которые он приносит в компанию. Пройдите последовательно по этой цепочке - как измерить на каждом этапе стало "лучше/хуже". Используйте простые знания из жизни, что клиент скорее простит производителю дефект в продукции, чем хамство и грубость по отношению к нему (тем более, если он считает себя незаконно обиженным - подсунули дефектный продукт!) - один рассерженный клиент и сам не вернется и в среднем шести (!) своим друзьям расскажет как его обидели - средний "чек" от одного покупателя тоже известен - считайте! И с этим расчетом идите к HR и руководителю Службы поддержки и им показывайте. И говорите - я подготовлю курс по стандартам обслуживания. Я оттренирую навыки обслуживания. И то, что я сделаю, сэкономит компании примерно столько-то. И сделайте это. И путь потом кто-то скажет, что учебный центр не нужен! - покажите того, у кого язык повернется это сказать. Вряд ли такие появятся. А то, что вы способны сделать классный курс по всем правилам пед.дизайна - так кто ж в этом сомневается! Только это должно быть ОБЯЗАТЕЛЬНО ПОСЛЕ того, как вы предыдущую задачу с эффектом от обучения решили.

Ну вот, если кратко, то так :)

С уважением

[Yan Fedyanin]

Сейчас прочитал пост в блоге WebSoft: http://websoft-elearning.blogspot.com/2009/03/blog-post_4640.html об участии ген.директора Вашем проекте. Мне кажется, что вся проблема - "в масштабе". Все-таки начинать надо было не норм.доков (хотя он, безусловно, очень нужны на определенном этапе), но с доказательства того, что учебный центр МОЖЕТ помогать экономить или зарабатывать деньги. С небольших проектов, показывающих эффективность. Тогда и кредит доверия был бы больше от других руководителей. И от малого идти к большому. Но я, возможно, знаю не все обстоятельства.