| Создал Alexey Kalmykov 12 февраля 2009 г. в 10:45 в категории «Корпоративное обучение» |
Коллеги, по просьбе хозяйки данного форума инициирую тему (см. subj). Предлагаю подойти к этому вопросу как к кейсу и последовательно обсудить следующие вопросы:
1) Какие действия (групп действий), какие функции должны осуществляться командой по внедрению и поддержанию СДО?
2) Какие из этих действий целесообразно выполнять внутри компании, а что — внешними исполнителями (и в зависимости от каких факторов происходит такое распределение)
3) Как кризис влияет на ответы на вопросы 1 и 2?
Конечно, должна быть некоторая интрига — в данном случае она заключается в том, что для себя (и для конкретной ситуации) я ответ сформулировал, подойдя к данному вопросу через призму ролей в команде СДО (понимаемой широко, как всех активных участников процесса — но, пожалуй, не расширяя до всех stakeholder'ов). У меня получилось около 12 ролей, которые вообще говоря, хорошо коррелируются с набором компетенций. Понятно, что скорее всего эти роли будут исполняться гораздо меньшим количеством людей (в пределе — одним :)).
Я готов поделиться этими своими прикидками — но сначала очень хочется услышать мнение и других практиков, особенно «изнутри» компаний использующих СДО.
Рейтинг 105 | Да, говоря о «кейсе», я имел в виду, что за отправную точку можно взять некую «типичную» компанию, использующую СДО, а разнообразные частности конкретных ситуаций рассматривать как факторы, изменяющие (возможно) набор и распределение ролей.
Типичной компанией, в которой применение СДО является не блажью, а объективной необходимостью бизнеса, в российских условиях, на мой взгляд, является:
- компания, успех бизнеса которой напрямую связан с операционной деятельностью сотрудников
- деятельность значительной части сотрудников, напрямую влияющих на доходы компании, достаточно унифицирована
- географический масштаб и количество сотрудников компании достаточно велико — как минимум филиалы в регионах, аудитория для обучения от 1000 человек
|
---|
Рейтинг 901 | Простите, нельзя ли уточнить, что разумеется под ролью в команде СДО?
Поскольку под нею отчего-то хочется понимать такой список позиций:
Инициатор
Скептик
Энтузиаст
Исполнитель
Эксперт и т.п
Вы подобные роли имели в виду?
Было бы интересно (если не прорывом) увязать подобные роли с компетенциями / функциями всех участинков команды СДО. Еще интереснее — совместить их в наименьшем количестве голов (людей) — вплоть до одной (одного).
|
---|
Рейтинг 105 | Владимир, несомненно, совместную деятельность группы людей (или команды — только давайте возможную дискуссию о разнице между группой и командой вынесем за рамки _данного_ обсуждения) можно рассмотреть с разных сторон и в свете разных теорий. Можно выделить роли в команде по Белбину, или по Хэнди (MTRi), или по Маргерисону и Маккэну, или по Томасу. Можно углубиться в типологии личности и то как это влияет на групповой процесс (Юнг, соционики, теория DISC и т.п.). Но все это — вопросы общего менеджмента.
Я предлагаю скорее исходить более сфокусированно — из практики управления проектами (и в необходимой мере — теорий из этой же области), а где-то — еще более узко — из управления IT проектами. Ни в PMBoKe, ни в RUP, ни в Microsoft Solution Framework (MSF) не даются абсолютно четкие определение термина «роли», они скорее качественные. Например, в RUP — «Роль — область функциональных обязанностей компетенции и ответственности, которые должен иметь человек или группа людей».
Например, по RUP типичные роли — менеджер проекта, аналитик, архитектор, разработчик, тестировщик (каждая из ролей может быть разложена еще на несколько). Это не должности, и не одна функция — но именно сгруппированные в одной роли задачи, компетенции, специфические инструменты и т.п.
В MSF — нечто весьма похожее.
Но за Ваш неожиданный взгляд с точки зрения ролей по Белбину на работу человека, выполняющего работу группы — «а как уживается это все в одной голове?» — спасибо. Все части моего "я" уже активно это обсуждают :)
|
---|
Рейтинг 105 | Кстати, как мне кажется, реализация довольно масштабных проектов корпоративных СДО силами 1-2-3 человек — обычная практика. Явно здесь есть функциональная и ролевая перегрузка. Составив матрицу «функция-роль», можно было бы эту перегрузку увидеть наглядно. А потом уже с учетом всех факторов, включая пресловутый кризис — говорить о количестве людей, о должностях, о структуре управления проектом СДО.
|
---|
Рейтинг 105 | С другой стороны, если есть успешные проекты, реализованные 1-2-3 людьми (и никто из них от истощения не умер) — то перегрузка приемлема?
|
---|
Рейтинг 901 | Алексей, на самом деле «мой» список «социопсихологических» ролей в одной голове — условие креатива. Этакая одна команда в одной голове. Иногда проектная :). Но это лирика.
Касательно предлагаемого Вами кейса: Вы так меня им загрузили, что долго буду думать, прежде чем чего сюда вписать.
|
---|
Рейтинг 105 | Так и я признаюсь в этом «раздвоении личности» (только не на 2, а на N) — действительно, без этого ни о каком креативе и подходе к вопросу с нескольких сторон речи быть не может.
|
---|
Рейтинг 569 | Алексей, попробую представить свою картину мира. Не ту, которая есть на самом деле, а ту, которая должна быть, на мой взгляд, то есть помечтаю :) При этом сразу оговорюсь: буду мечтать с точки зрения руководителя корпоративного УЦ, и даже представляю, чем моя картина мира подойдет (и не подойдет) для академической среды. И еще одна оговорка: в попытке ответить на Ваши вопросы буду представлять себе не СДО, и не LMS, нечто более широкое, что назову учебным порталом (далее — УП).
1. На самом деле многое может зависеть от той концепции, которую для себя примет организация. Например, сейчас я вовсю сражаюсь против концепции ДО, при которой обучаемый получает один большой документ, после которого сдает один большой тест. Для такой концепции достаточно 2 сотрудников:
- того, кто собирает документы, оформляет в соответствии с неким принятым в организации стандартом (а то и просто проверяет, что сам автор это уже сделал), публикует и распределяет доступ (назовем его публикатор),
- и того, кто занимается техподдержкой (назовем его сисадмин).
Ни о каких особых компетенциях здесь речь не идет: знание Word и пары-тройки функций публикаций. Я даже думаю, что на самом деле команды из 1-2-3 потому и имеют место, что руководство свято верит, что внедрение СДО сводится к этому формату.
А вот если подходить к вопросу более вдумчиво, то мне кажется, что потребуются следующие специалисты:
а) сисадмин-технарь — отвечает за то, чтобы все работало :)
б) методист — тот, кто формирует учебные планы, учебные программы, учебные группы (не только группы ДО!), расписание занятий (не только дистанционных!), отслеживает преподавательскую нагрузку;
в) организатор — тот, кто контролирует состояние учебных ресурсов (ТСО, аудиторный фонд, библиотека и т.п.);
формирует команду преподавателей, контролирует их работу; организовывает информационную поддержку учебного процесса;
г) преподаватели — те, кто сопровожают учебный процесс, готовят материалы, консультируют, проводят занятия, проверяют работы, направляют слушателей и т. п.;
д) разработчики — те, кто разрабатывают/дорабатывают/перерабатывают электронные учебные материалы для публикации на УП; состав команды разработчиков может быть разным, но минимальное количество, на мой взгляд, таково: педдизайнер, графический дизайнер, программист и руководитель проекта разработки, итого 4 человека; если сюда добавлять видео и озвучку, а также серьезно относиться к стилистике и грамматике, то может понадобиться еще 2 человека;
е) контент-менеджер — тот, кто отвечает за информационное наполнение УП; УП — ресурс, который поддерживает обучение; следователь, за ним надо следить, его надо развивать, надо продумывать мероприятия, которые помогут сделать его популярным, востребованным, актуальным, живым; причем, замечу, это не означает, что этот человек сам пишет контент;
ж) руководитель проекта внедрения — собственно, тот человек, который управляет всем проектом и всеми, кто на нем работает.
Итого у меня получилась сборная от 10 до 14 человек. Которая на самом деле может разрастаться. Например, если через учебный портал реализуется несколько больших программ, то на каждой такой программе может быть свой методист и свой руководитель.
2. Какие из этих ролей могут быть внутренними и какие внешними, надо решать в каждой конкретной ситуации. Преподаватели и разработчики могут быть и внутренними, и внешними (от многих факторов зависит). Руководители программ — тоже могут быть и свои, и приглашенные. Но лучше, конечно, чтоб были свои. :)
3. Кризис, полагаю, тут ни при чем. Все зависит от руководителя проекта внедрения :) Если он сможет объяснить целесообразность наличия такой команды внедрения, то сможет ее собрать. Если нет, значит, еще не сам до конца понял, почему ему нужна именно такая команда. Это уже не мечты, а собственный опыт. Я вот не смогла объяснить, и пока работаю в 1,5 человека. :) Работаю над этим :)
|
---|
Рейтинг 901 | Елена, а фигура вроде педагогического дизайнера Вами не предксмотрена? Или я ее не сумел разглядеть?
|
---|
Рейтинг 569 | Не сумели :) Пункт 1д :)
|
---|
Рейтинг 105 | Елена, большое спасибо за обстоятельный ответ! Постараюсь на многие мысли из него дать свой отклик, но чуть позже (цейтнот :( )
По одной мысли устоять не могу — относительно того, что «идеальная команда» (а у нас с вами близкие параметры получились — 12-14 человек, причем я у Вас увидел то, о чем забыл, и с другой стороны — у меня есть некоторые другие роли) — не собирается исключительно из-за того, что руководитель внедрения не смог это «пробить».
Субъективный фактор, конечно, важен — но все же, может наше видение «идеала» слишком уж расходится с реальными возможностями или потребностями наших заказчиков?
|
---|
Рейтинг 569 | Алексей, буду с нетерпением ждать и Вашего отклика, и Вашей версии сборной внедренцев :)
Что касается возможностей и потребностей заказчика. Если заказчик только созрел до мысли, что ему нужен такой ресурс, как СДО/LMS/УП, то надо помочь ему понять, действительно ли он ему нужен и какой. На этом этапе должен появиться человек (или команда), который поможет правильно определить потребности и возможности и подобрать под них адекватное решение. И сразу сказать, что для реализации такого решения нужно будет столько-то времени/людей/денег. После чего официально принять решение, начать проект, под который выделить средства, найти людей и т.д.
Проблема в том, что у нас обычно так не делается. Несколько раз сталкивалась с примерами, когда ПО куплено по велению души (или потому что надо закрыть какие-то дырки и что-то подсунуть руководству), но нет четкого понимания, кто им будет заниматься, для чего оно куплено, что с ним надо делать, какой результат хотим получить и как можно понять, что мы его получили. В результате имеем дорогущий набор инструментов Bosch, из которого используем только молоток, и только для чесания спины, и даже иногда думаем, что на самом деле массажер и купили. :)
|
---|
Рейтинг 105 | Рискуя увести обсуждение в сторону — замечу, что действительно чеще всего у нас «так не делается» — но далеко не всегда потому что руководитель проекта так не сделал.
Удивительно — но в моей практике управления проектами (не только СДО) любой «честно» просчитанный проект, учитывающий полные затраты, не проходил!
Казалось бы, заказчик (особенно, когда проект внутренний, а заказчик — собственник), заинтересован в том чтобы без самообмана увидеть полный объем стредств, который ему предлагается инвестировать в некий проект — только так он сможет реально сравнить затраты с ожидаемым результатом (а если результат слабосчитаемый, типа отдачи от обучения — то оценить, на какой масштаб затрат он готов пойти ради достижения качественных целей).
Но если включить в состав полной стоимости вещи неявные — типа стоимости ИТ-инфраструктуры и услуг ИТ отдела, части времения экспертов-практиков и т.п. — цифр чаще всего пугаются, и проект тормозится. И это несмотря на то, что эти затраты четко идентифицированы, как уже совершенные или неизбежные (даже если данный проект реализовываться не будет).
Вот и не включаются в бюджет проекта расходы, «проходящие по другим статьям». Частично это еще и влияние бухгалтеров, которым всякое разнесение затрат по разным статьям аналитик — большая головная боль.
А результат — заниженная стоимость проекта, «размазанные» по другим статьям затраты, нужные Вам в именно этом проекте. Все бы ничего, только при возможных кризисах и просто корректировках бюджета результат для Вашего проекта непредсказуем. Да и деньгам других подразделений Вы не хозяин. Ну и эффективность проекта становится категорически сложно просчитать.
Например, в одной из компаний я долго бился, чтобы доказать, что при внедрении СДО надо, с одной стороны, учитывать рост затрат на интернет-трафик, с другой — снижение командировочных расходов тренеров в регионы или командировки сотрудников из регионов для обучения в Учебном центре (а совокупные затраты на подобные командировки многократно превосходили необходимые затраты собственно на СДО и фонд оплаты труда квалифицированной команды СДО).
Каюсь — за два года так и не смог сломать систему — для финансистов-бухгалтеров эти затраты шли по разным статьям и бюджетам (бюджет СДО — в составе HR бюджета, зарплата преподавателей-очников и команды СДО — в ФОТ соответтвующих подразделений, трафик — IT бюджет, командировки преподавателей — бюджет операционных расходов Центрального офиса, и соответсвенно командировки сотрудников из регионов — бюджеты этих региональных «дочек»). При этом, при корректировке бюджета, требовали снижения затрат по проекту без учета того, что ты экономишь по другим статьям. Или неожиданно можно было узнать, что деньги на СДО есть, а на трафик для него — секвестрированы.
Вот и становится неким порочным стилем вхождения в проект, когда стартуешь проект с минимальным бюджетом, полагаясь на:
а) часть нужных тебе затрат сидит в бюджетах других подразделений
б) показав некий работоспособный результат, сможешь «пробить» увеличение бюджета или сверхбюджетные средства.
И — к теме нашего обсуждения — такой старт и делается минимальной командой в 1-2 человека, в надежде «пробить» рост численности и ФОТ по ходу проекта.
|
---|
Рейтинг 105 | Собственно, описанное выше не дает возможности компании объективно оценить стоимость проекта и при сравнении с предложениями с рынка:
а) руководству кажется, что «мы тут у себя все это силами одного человека делаем и только за его зарплату» — на самом деле, не только его одного, и не только зарплату тратят — но полных затрат не знают
б) незнание собственных затрат приводит к отказу от аутсорсинга — поскольку здесь-то деньги конкретные и кажущиеся большими.
|
---|
Рейтинг 100 | Елена! Приятно прочесть столь вдумчивые высказывания по поводу СДО. Со многими сложно не согласиться!
Целиком и полностью поддерживаю неприятие подхода: тест-курс-тест. Такой подход ничего не даёт. На наш взгляд система СДО — это часть единой системы подготовки и развития персонала, т.е. только один из инструментов для решения стратегических задач компании. Как любой инструмент, он не может быть применим везде и всегда. поэтому актуальность использования СДО для решения задач обучения нужно всегда рассматривать с точки зрения возможности получения нужного результата.
Это во-первых. А во-вторых, от задач зависит технология, от технологии-функционал, а уже от функционала — команда. Понятно, что одну и ту же задачу можно решать разными технологическими решениями, и один и тот же результат получать разной ценой.
Что касается команды, то я бы разделила всё на функциональные группы при организации СДО. По функциям:
Предварительно. Диагностическая ( анализ по заданным параметрам, определение признаков принадлежности группам обучения по заданным параметрам, проведение «входной» диагностики).
1. Организационная ( в глобальном масштабе- руководство проектом (ами), в локальном-комплектация групп по утверждённым признакам, контроль прохождения и результативности ДО.
2. Коммуникационная (контент- команда) (трансляция целей и задач, целевой подбор практического материала для курсов, коммуникации между групппами проекта)
3. Авторы курсов
4. Методологи ( разработка методологии проверок знаний по форме и содержанию — эта функция может выполняться и авторами)
5. Тьюторинг(дистанционное сопровождение курсов-эта функция может выполняться как авторами, так и специалистами, хорошо владеющими данной тематикой и обученными методологии проверок). Мы эту функцию выполняем в «две линии»
6. Тех. обеспечение процесса ( регистрация, доступ, сопровождение, закрытие курса, аналитика, формирование отчетности, «горячая» линия техподдержки).
7. Тренерская ( при смешаной системе обучения)
8. Руководители, которые выставляют SMART задачи(проекты) после обучения.
9. Комиссия приемки (защиты)SMART задач (проектов).
|
---|
Рейтинг 105 | Алла, Вы меня опередили, я по тьюторской привычке «выводил» дискуссию к целесообразности подняться еще на 1 уровень обобщения, и выделить группы ролей (с соответсвующими им функциональными областями).
«Для себя» я выделял следующие такие области:
- Содержательная: наполнение обучения (СДО в увязке с другими формами), методология, педдизайн и собственно обучение
- Технологическая: перевод содержания в формат СДО / blended learning, настройка системы, сервера и т.п.
- Административная — формирование групп, доступ, информирование, техподдержка по поводу работы в СДО, аналитика и отчетность
- Руководство — координация всего процесса и коммуникация с заказчиком (особенно, если он — внутренний, первое лицо компании)!
Фактически, по п.1-7 Вашей классификации, мы с Вами ни в чем особенно не расходимся.
Не могли бы Вы прокомментировать свои пп. 8-9?
|
---|
Рейтинг 901 | Алексей и Елена,
признаюсь в интеллектуальном затыре по поводу команды образованцев в компании и, вообще, смысла LMS или учебного портала.
И вот с чем он связан:
Мне кажется, что коропоративное обучение нужно к чему-то привязать. Объектами для привязки могут выступать:
- кадровая политика компании;
- корпоративная культура;
- HR-менеджемент;
- управление знаниями;
- обеспечение функционирования саморазвивающейся организации;
- внутриорганизационного пиара и, возможно, внутренниго маркетинга;
- простой элементарный ликбез для латания дыр в актуальных здесь и сейчас компетенциях, знаниях (продуктов и процессов, включая новые, к примеру) и навыках (например, сервиса клиентов). По-моему, исходный «кейс», запустивший этот форум, имеет отношение прежде всего к этому пункту. Даже если учебный центр формально завязан на кадровую службу.
Если что упустил, типа обучения коммуникациям, прошу дополнить.
В зависимости от объекта привязки и будет зависеть функциональный и должностной состав учебных центров. Или здесь нужно искать иные, комплексного характера решения.
Боюсь, что последний пункт в предложенном списке наименее удачный, потому, что, на мой взгляд, обучение сугубо производственным процессам, регламентам и стандартам, продуктам и обслуживанию клиентов, осуществяемое вне привязки к какому-нибудь из преречисленных мной объектов а) едва ли будет органичным в компании, б) рано или поздно вступит в противоречие с одним или несколькими перечисленными объектами, в) заведомо обрекает корпоративное обучение на роль замарашки, Золушки или бедного родственника, если не лакейство, г) всегда будет отставать от изменений в компании, всегда опаздывать во всем, где нужно действовать на опережение.
Что-то сдерживает решать Ваш кейс, Алексей, без привязки к чему-то еще, однако решить его очень хочется.
|
---|
Рейтинг 105 | Владимир, конечно, в моем начальном предложении рассматривать СДО как «сферическое тело в вакууме» содержалась доля провокации. Но очень уж хочется увидеть общие черты проблемы, а — уж потом, с пониманием общего, как-то относиться к многообразным частным деталям.
С этой точки зрения, и ваша классификация объектов для привязки СДО (= целям ее создания в компании, я правильно понимаю?) тоже достаточно обща. И вряд ли где-то мы встретим СДО, созданную исключительно под одну из сформулированных Вами целей (по сути, а не по нормативным документам).
Кстати, Владимир, а с учетом того, что Вы можете посмотреть на многие проекты корпоративного СДО извне — для каких целей они создавались, и какие задачи реально решают? Особенно, в свете надоевшего-но-куда-же-от-него-денешься кризиса, наиболее жизнеспособные СДО (т.е. те, которые воспринимаются бизнесом как необходимая часть даже в крайних условиях)? Ведь произошедшие в ряде компаний «замораживания» уже функционировавших СДО — это оценка бизнес-руководством этих механизмов как некритичных для выживания бизнеса.
Я, со своей стороны, видел СДО только изнутри. Из трех внедрений в корпорациях, не называя компании, могу идентифицировать:
- один случай — целеустановка на «обеспечение функционирования саморазвивающейся организации». Очень привлекательная цель, только вот сама такая задача была скорее «игрушкой» переменчивого в своих управленческих приоритетах владельца-менеджера. Включенность и влияние СДО на реальные бизнес-задачи была невелика, и когда игрушка «самообучающаяся организация» наскучила, на столе президента вместо Сенге стали лежать другие книги — заглохла и СДО без особых последствий для бизнеса.
- еще один случай (консалтинговая компания) — все, что Вы назвали, и еще немножко. Во внутренней среде — потребность «сверху» скорее в системе управления знаниями, понимаемой как средство снижения зависимости бизнеса от сотрудников-носителей уникальных знаний (путем «снятия» с них этих знаний и превращения через обучение других — в неуникальные). Конкретная СДО оказалась не очень подходящим инструментом для этого. Второе направление, более успешное — это обучение продуктам через СДО сотрудников компаний-клиентов в рамках комплексных проектов внедрения. Здесь, по сути, СДО становилась частью продаваемой бизнес-услуги, частью бизнеса компании — поэтому и более жизнеспособной.
- и третий кейс (страховая компания) — это, по Вашей классификации — обучение «актуальным здесь и сейчас компетенциям, знаниям (продуктов и процессов, включая новые) и навыкам (например, сервиса клиентов)» в чистом виде. И, несмотря на определенные сложности, я уверен что СДО в этой компании переживет тяжелый период и будет развиваться — пусть, как функция утилитарно-поддерживающая, но необходимая и эффективная.
|
---|
Рейтинг 105 | Прочитал собственный пост и понял, что он может инициировать большое обсуждение на вечную тему - а зачем, собственно, компании нужно СДО?
Поэтому, чтобы все же прийти к результату по теме «Роли, функции, структура команды СДО», предлагаю тему «Зачем компании СДО» пока не развивать либо вынести в отдельную ветку.
|
---|
Рейтинг 901 | Добавлю еще несколько ролей:
- литературный редактор;
- художественный (м-медиа) редактор;
- корректор
А то глюк в контенте многовато случается. Сам горазд их плодить :)
|
---|
Рейтинг 105 | Таким образом, коллеги, как некий промежуточный итог:
1) Мы де-факто договорились о едином понимании «ролей» и применению такого подхода в дальнейшем анализе;
2) К настоящему моменту названы следующие роли:
1. сисадмин
2. методист
3. организатор (бэк-офис центра ДО)
4. преподаватели
5. педдизайнер
6. графический дизайнер
7. программист (кодер учебных материалов)
8. руководитель проекта разработки учебного материала (курса)
9. видео и звукооператоры
10. контент-менеджер учебного портала
11. авторы контента учебного портала
12. литературный редактор;
13. художественный (м-медиа) редактор;
14. корректор
15. руководитель проекта СДО
|
---|
Рейтинг 105 | Со своей стороны (потихоньку доставая припрятанные заначки) добавлю:
к пункту 1.
Сисадминов надо делить — один это сисадмин сервера (скорее всего, человек в IT департаменте, отвечающий за сервер, системное ПО, настройку маршрутизации сети, почты, и т.п.).
Второй — администратор прикладной системы (импорт-экспорт данных, запуск всяких агентов, права доступа и т.п...)
И, похоже, Елена в роль сисадмина вкладывает еще и функции по настройке СДО (настройка меню, самого движка системы, создание и модификация скриптов/шаблонов типовых форм, отчетов и т.п.). Я бы выделил в отдельную роль — программиста по настройке СДО.
К пункту 2.
Хорошо, если преподаватели сами и эксперты, сами и курс напишут, и сами его преподают как очно, так и дистанционнно.
Но с ролевой точки зрения, пожалуй, надо разделить:
- экспертов предметной области (желательно — практики)
- авторов учебных материалов (те, кто знания из экспертов вытянет и в системный вид приведет)
- преподавателей очного обучения
- тьюторов дистанционного обучения (через форумы, чаты, обратную связь по е-мейл)
|
---|
Рейтинг 105 | Еще один функциональный блок — это разработка тестов.
Я исхожу из того, что, независимо от того, являются ли тесты частью учебного курса или отдельным контрольным блоком (я стараюсь объединять эти два подхода):
- качество тестов, подготовленных непосредственно предметными экспертами, крайне низкое
- кaк правило, эксперты-практики используют простейшие форматы тестов — multiple choice или multiple response, игнорируя другие возможности
- другими вопросами (обоснованное количество вопрсов в тесте, установление весов, распределение весов и количества вопросов по разделам в случае большого теста по предмету/продукту в целом, анализом статистики ответов на вопросы) эксперты заниматься также не хотят или не могут
Т.е. нужен «педдизайнер по тестам» .
И (гулять так гулять) — кодер тестов (с требованиями к квалификации, вообще говоря, ниже, чем к кодеру по курсам)
|
---|
Рейтинг 569 | Ох, разошлись, Алексей! :)))
А я вот взяла и на себя примерила все наши разговоры... И поняла, что мне бы хватило человек 5 на все про все. Главное — чтобы они и вправду были командой. Так ведь и такую команду собрать — целая эпопея...
|
---|
Рейтинг 100 | Поддерживаю. Мы сейчас ведем четыре масштабных проекта на аутсорсинге. общая численность — около 500 человек. С авторским составом, конечно, в пять человек не вписываемся. Но остальные функции вполне реализуются именно этим составом.
|
---|
Рейтинг 105 | Мы же пока не о «головах» — о ролях говорим... Что команда в 3-5 человек вполне дееспособна для практически любых проектов — как управленец я вполне ощущаю — но это именно ощущение. А хочется сначала аналитически разложить все роли, функции — а уже потом «упаковать» их в конкретную структуру проектной команды.
|
---|
Рейтинг 105 | Наверное, это тема для отдельной дискуссии в отдельной ветке — но лично у меня есть ощущение (пока просчитанное"в цифрах" только для одной конкретно ситуации одной организации), что аудитория в 100-200 сотрудников для внутрикорпоративного СДО — это путь к угасанию проекта после первого цикла обучения... При такой численности необходимый набор тем обучения, наилучшим образом реализуемого именно eL, достаточно быстро проходится «на раз», а «внутренней емкости рынка» (численности сотрудников компании) с учетом текучести, динамики движения кадрового резрва и т.п. не хватает, чтобы поставлять новых обучаемых в необходимом количестве (или если на это же самое посмотреть не со стороны СДО, а владельца бизнеса — удельные затраты на обучение 1 сотрудника резко вырастают и перестают быть привлекательыми).
Именно поэтому в начальном кейсе я поставил численность 1000 человек (хотя imho это нижний предел).
|
---|
Рейтинг 100 | Могу не согласиться. Все, конечно, зависит от технологии ДО и её стоимости. Но комплексные программы подготовки в 2-3 курса вполне, как показывает опыт, жизнеспособны. комплесные же проеты в режиме СДО могут быть реализованы и на 20 человек.
|
---|
Рейтинг 105 | Елена, так и я редко больше чем 2 людьми располагал в таких проектах, и с очень разным уровнем и набором компетенций — а обычно вообще в одиночку, с ограниченными ресурсами для аутсорсинга... Но считаю это скорее вынужденным компромиссом — со всеми вытекающими как для результатов проекта, так и для себя лично.
|
---|
Рейтинг 100 | Многовато ролей получается....снижается управляемость проектом. Если еще добавить к этому. что функции могут распределяться между провайдером СДО и Заказчиком, то....
|
---|
Рейтинг 105 | Алла, собственно эта дискуссия была инициирована тем, что попытавшись осмыслить собственную работу «СДО-в-одном-лице», я был поражен количеством ролей. Думаю, я не одинок. Распределение функций между внутренней командой СДО и провайдером СДО, или внешними провайдерами отдельных услуг — может быть весьма разнообразным (но, наверное, все же не любым — и это тоже хочется обсудить в уместное время).
Если дотошно не выявить специфические функции (а для их выполнения нередко нужны специфические умения и навыки), а сразу «по понятиям» укрупненно распределить зоны ответсвеннности, то, на мой взгляд, и создается почва для ситуаций, когда СДО «рулит» ИТ-шник, или программисту-кодеру курса поручается сделать и его графический дизайн...
(я, конечно, говорю о примерах скорее ошибок в управлении проектом СДО).
Если же по счастливому стечению обстоятельств у вас есть в одном лице квалифицированный программист, талантливый дизайнер, опытный предметный эксперт и знающий педдизайнер — так грузите его по всем ролям! (но не забывайте о пределах общей нагрузки на 1 человека и лимите в 24 часа в сутки).
Впрочем, в последнем случае таким универсалом приходится счиатать себя и грузить нещадно...
Про управляемость проектом. Управлять-то в любом случае приходится не ролями, а людьми. Управлять, ставя им задачи, сроки и контролируя их исполнение. Чем четче мы знаем, что, кто и когда должен вложить в общий результат — тем проект потенциально управляемее.
Для того, чтобы распределить функции (оставим управление временем проекта за рамками, ок?) — удобно составит таблицу распределения функций (и вот десь у нас уже будут конкретные люди, которых будет горазде меньше, чем ролей :( )
|
---|
Рейтинг 100 | Безусловно за провайдером остаётся конечная приемка курса, его макетирование и размещение на портале при внешней СДО, тех.сопровождение. Хотя тоже могут быть варианты....
Спасибо за тему и обсуждение- очень полезно!
|
---|
Рейтинг 569 | Да, с легкой руки Алексея получилось очень интересное обсуждение! :)
|
---|
Рейтинг 901 | Еще поразгуливаюсь:
одно дело — тесты достижений (тестируется то, что человек изучил и в какой мере),
другое — личностные тесты: мотивов, способностей, направленности, профориентационные, поведения в конфликте и прочих внутриличностных качеств.
Вы дизайнера по каким тестам имели в виду?
В обучении, ИМХО, можно и допустимо тестировать только достижения. На остальное — табу. По крайней мере в рамках тех условий, которые задает ваш кейс
|
---|
Рейтинг 105 | Совершенно согласен, причем именно с этим категорическим условием — тестируем усвоение именно того, что дали в учебном материале.
Я также считаю, что проверка знаний «того, что сотрудник и так обязан знать по должности» (и того, что содержится в куче положений, инструкцтй, приказов и т.п., однажды показанных ему — или даже не показанных) — тоже недопустима, без предварительного перевода их в учебный материал. Или, как некий компромисс с действительностью — без наличия возможности из учебного курса по ссылке обратиться к тексту нормативного документа, знание которого необходимо для ответа на тесты.
|
---|
Рейтинг 901 | Согласен и возьму на себя наглость обобщить:
1. Допустим контроль только в виде тестов достижений.
2. Недопустимы контроль и оценка знаний, если сотрудник не был предварительно обучен или не были созданы условия, чтобы он обучился.
|
---|
Рейтинг 100 | Вообще, на мой взгляд в корпоративном обучении тесты использовать нужно осторожно. Как, например, тестами проверить усвоение принципов клиенториентированности, принятые в компании? Это можно сделать только ситуационными заданиями.
соглашусь, что даже «входное» тестирование должно быть направлено на диагностику знаний только в рамках курса. Это даже больше информация для тьютора — как потом работать со «студентом»
|
---|
Рейтинг 901 | Мда, вопрос с экспертами предметной области, особенно внутренними специалистами-практиками, сразу ставит «философский» вопрос: а они входят в команду СДО?
Перевод экспертных знаний в учебный контент, особенно знаний неформальных, требует от авторов учебных материалов особых знаний и владения особыми процедурами, а именно, извлечения знаний. Затем авторы должны обеспечить формат их структурирования и хранения, а также передачи в таком виде, чтобы эти знания некто мог приобрести.
На мой взгляд, обслуживание функций извлечения, структурирования, передачи и приобретения знаний должен обспечивать особый специалист (особая роль), которого я бы назвал инженер по учебному знанию.
|
---|
Рейтинг 100 | Входят обязательно.Поскольку курсы обязаны работать на корпоративные задачи, кто как не практики способны вдохнуть в эти курсы жизнь, насытив их практическим материалом! Можно привлекать практиков как соавторов и адже тьюторов при определённой подготовке.
|
---|
Рейтинг 105 | Вопрос проведения границ — входят/не входят в команду — предлагаю оставить на завершающую часть анализа, когда мы доберемся до оргструктуры проекта СДО.
Пока же считаю возможным резюмировать, что мы увидели роли «эксперт предметной области» и «эксперт по извлечению знаний из предметных экспертов» :)
|
---|
Рейтинг 100 | Согласна насчет шагов и членства в команде. То, что эта роль должна быть учтена- факт. Остальное- в зависимости от формата реализации.
|
---|
Рейтинг 901 | Отвечу цитатой, скорее относящейся к функциям, чем к ролям. Что надеюсь, поможет нам установить связи между ролями (людьми) и выполняемой ими работой.
«- взаимодействие с ИТ-департаментом
- работа с СДО, размещение материалов
- работа с авторскими средствами
- управление проектами (внедрение ДО, развитие системы, разработка курсов)
- управление работой с экспертами (внутренними и внешними)
- подготовка документации (инструкции для обучаемых и т.п.)
- взаимодействие с контракторами (разработчиками курсов, поставщиками софта)
- оказание технической поддержки клиентам (сотрудникам компании)
- подготовка текстов (новости учебного портала, сообщения для пользователей и т.п.)
- верстка материалов в HTML
- работа с графическими редакторами»
Источник
|
---|
Рейтинг 105 | Владимир, спасибо Вам большое за ссылку, эта ветка на уважаемом мною форуме как-то ускользнулв от моего внимания. Жаль, что она как-то ушла в тему инструментов eL.
Как понимаю, выписанный Вами список — это выписка или компиляция из должностных инструкций типичного «специалиста по СДО» в одном лице. Как список функций — и собственно по четкости формулировок, так и по желанию видеть это обязанностями одного человека — на мой взгляд, весьма уязвим для критики.
Что в русле нашего обсуждения я вынес из указанной Вами ветки обсуждения:
Еще несколько ролей:
1. Оператор-специалист «горячей линии» по поддержке пользователей (а может ли он быть один?)
2. Технический писатель (инструкций и т.п.)
3. «Архитектор обучения» (на мой взгляд, одна из подролей руководителя, но это мое imho)
4. Сценарист
5. Целый набор ролей, связанных с озвучкой (никогда не делал курсов в корпоративном СДО со звуком, так что просто не считаю себя компетентным обсуждать эту часть)
6. Тестер разработанных курсов, портала
|
---|
Рейтинг 901 | Ого, даже без точного подсчета чисо ролей уже со всей очевидостью перевалило за 20.
Согласен касательно «архитектора обучения». Возможно, эту роль может выполнять и руководитель СДО. Однако мне кажется, что эта роль скорее пед.дизайнера, если угодно, архитектора-идеолога обучения. Ничто, впрочем не мешает испольнять эту роль и руководителю, что, возможно, только на пользу СДО пойдет.
Оператор-специалист «горячей линии» по поддержке пользователей? Речь идет о технической поддержке или педагогической? Простите, не понял.
И вообще, если отталкиваться от условий заданного Вами кейса, не совсем понятно, уместна ли в нем роль тьютора или мы все на электроные средства повесим? Предусмотрим ли мы долько e-L, или смешанное обучение реализовывать будем? Какой способ обучения будет доминирующим — электронное или очное — в случае смешанного обучения?
|
---|
Рейтинг 105 | Владимир, может быть из-за того, что по жизни я сначала стал тьютором дистанционного обучения — и только спустя несколько лет оно стало становиться очень понемногу «электронным» — я не то чтобы не представляю «чистого e-L» как общения исключительно человека с программой — я не вижу в этом необходимости, равно как и особых проблем в том, чтобы в обучении в той или иной мере всегда присутствовал живой тьютор.
Если обучаемый после прохождения чисто электронного курса задает содержательные вопросы в форуме, и ему отвечают эксперты в предметной области и тренеры учебного центра — они в этот момент играют роли тьюторов? мы имеем элементы смешанного обучения?
Если нормативную часть продуктового курса обучаемый проходит по электронным курсам, а практические навыки отрабатывает на очном тренинге с тренером — это смешанное обучение?
Для полноты ролей предлагаю тьютора в ролях рассматривать, а уж насколько он будет использовываться в конкретной архитектуре обучения — это конкретика, решаемая каждый раз от задачи, ресурсов, культуры компании в конце концов. Мы же примерно так договорились поступать с группами ролей, связанных с видеосъемкой, игрой актеров, озвучкой, не так ли? — т.к. исключать их во избежание потери полноты картины не стоит, но и «на берегу» ясно, что это роли специфические, которые в значительном (если не подавляющем) количестве корпоративных проектов e-L не возникают (а в большинстве других — реализуются на аутсорсинге).
Что касается «горячей линии». Реальный опыт внедрения одной из хорошо знакомых Вам СДО, с тысячами пользователей по всей стране, с централизованным сервером позволяет говорить о некоторых закономерностях:
1) средний пользователь обычно слабо способен правильно диагностировать свою проблему — то ли это проблемы настроек у него на рабочем месте, то ли со связью, то ли внутри СДО. Поэтому ему надо дать возможность звонить/писать в единую службу техподдержки, в которой проблему диагностируют, и либо дадут ответ, либо перенаправят специалисту.
2) Не считал в процентах, но по моей оценке, запросы делятся примерно в следующей пропорции:
- «Не могу войти на портал» 25% — проблемы настроек компьютера, сети, перебоев в работе сервера, настроек IE, использования неподходящего броузера или опер.системы. Ответ должен даваться IT-специалистами (дело даже не только в том, может ли кто-то другой дать компетентный ответ. Я, без ложной скромности, на большинство этих вопросов компетентно отвечу. НО: многие проблемы в части сервера, настройки маршрутизации сети я не решу — это епархия сисадминов)
- «Забыла пароль» — 25% — решение — установка пароля по умолчанию администратором прикладного уровня (администратором СДО)
- «Назначьте курс/тест» — 30% (и не надо мне про документооборот заявок на обучение — описанный поток идет при том, что у каждого пользователя есть возможность назначить курс/тест себе самостоятельно) — RTFM
- «Не могу найти в системе архива/новостей/форума» 10% — RTFM и голосовая навигация пользователя по меню :)
- и только процентов 10 — по содержательной части курсов/тестов, непоняткам или выявленным ошибкам. Это — в форумы по курсам.
Т.е. нужно:
- «окно приема заявок» — телефон, e-mail
- техническая горячая линия
- горячая линия административной поддержки в СДО
- и содержательно, чаще всего без особых временных рамок — обсуждение возникших учебных проблем в форумах и т.п.
|
---|
Рейтинг 105 | Коллеги, не пора ли нам подвести черту под перечнем ролей? Есть ли еще какая-то функциональная область в реализации проекта СДО, нами не охваченная?
Если в ближайшее время новых ролей не родится, предлагаю пройтись по каждой, и выявить специфические для этой роли:
- задачи
- функции, типовые действия
- требуемые компетенции
- с носителем какой другой роли может быть объединена? Или, проще — на кого ее можно «повесить»? :)
- доводы «за» и «против» аутсорсинга этой функции за пределы команды СДО, и за пределы компании — пользователя корпоративной СДО.
|
---|
Рейтинг 901 | Да, Алексей, пожалуй, пора. Здесь работы, пожалуй, побольше будет :)
|
---|
Рейтинг 569 | ... причем, отдельными ветками!
|
---|
Рейтинг 901 | Алексей, что-то наше вече приумолкло. И, предполагаю, не только потому, что все морщат лбы в поисках неохваченных функциональных областей.
У меня, к примеру, два больших затыра:
1. Если мы одинково не будем понимать задачи, функции/типовые действия, компетенции, то стройной дискуссии может и не выйти.
Не возьмете ли на себя «окаянство» дать их определения? А я готов не выходить за рамки этих определений. На мой взгляд именно разность понимания выделенных жирным штук может увести нас в сторону. Ну, а коль Вы это инициировали, то Вам и карты в руки :).
2. Поскольку ролей мы набрали немало, то не стоит ли обсуждать их «оптом», но каждую по следующим отдельным веткам:
- задачи
- функции, типовые действия
- требуемые компетенции
Аутсорсинг и объединение ролей в одном лице-носителе можно также внутри этих веток обсуждать.
|
---|
Рейтинг 100 | Озвучка- это действительно интересный методологический инструмент, и отдельная тема. (Можно пообсуждать, если появится желание, т.к. опыт как раз есть)
|
---|
Рейтинг 105 | Может, начнете параллельно? Как практик внутрикорпоративного СДО — я против озвучки (а также в большинстве случаев — видео). Как эстет и перфекционист, рад был бы быть переубежденным :)
|
---|
Рейтинг 569 | Алла, а не хотите ли на эту тему веточку на форуме завести? ;)
|
---|
Рейтинг 901 | Присоединяюсь к просьбе Елены. Надо, наконец, разобраться, в чем у нас в СДО звук «виноват» :)
|
---|
Рейтинг 105 | Чем хороша дискуссия с въедливыми профессионалами — тем, что приходится осмысливать и вербализовать почти интуитивные для себя поначалу вещи — и не всегда устоявшиеся и очевидные вроде подходы выдерживают такое испытание :)
Вот и в данном случае — в феврале про свое отрицательное отношение к озвучке я сказал «на автомате», а чтобы понять почему оно такое, и всегда ли это верно — потребовалось время.
Просмотрев не один озвученный курс нескольких производителей (все — несомненно профессиональная работа), выделил для себя несколько моментов:
Вариант №1 — если озвучка — это зачитывание слово в слово того что есть на экране (как мне кажется, именно такой подход чаще всего применяется на практике).
Вариант №2 — если звуковой ряд не совпадает с тем, что написано на экране, а соотносится каким-то другим образом (комментирует, дополняет, оппонирует...).
Вариант №3 — если изображения и текста нет, только звук (т.е. аудиокнига, аудио подкаст и т.п.)
Так вот вариант 1 кажется мне не только неэффективным, но вредным с точки зрения усвоения материала. Если я сижу перед компьютером и вижу экран — то уж в любом случае прочитаю текст быстрее. чем его проговорят. На что-то потрачу больше времени, что-то просмотрю по диагонали, к чему-то вернусь повторно. Идущий фоном в заранее заданном темпе, с смысловыми ударениями не всегда совпадающими с моим пониманием — голос диктора меня только отвлекает. По сути, вместо работы с материалом, вольно или невольно, мне приходится совмещать два потока информации — аудио и визуальный, как-то их синхронизировать... «Процессор» грузится, а результат на выходе — ноль (т.к. информация, оказывается, та же).
Вариант «а не надо смотреть на экран, можно просто слушать» — не рассматриваем, т.к. а) если без потери информации мультимедийный курс можно только слушать — это в чистом виде Вариант №3, б) а если озвучка не рассчитана на только аудио восприятие (например, озвучивается что-нибудь вроде «Посмотрите на этот график...») — то она автономно не работает.
Ну и вообще, самое базовое правило любой живой презентации «со слайдами» — не надо их читать вслух! Думаю, это и к учебным курсам также относится.
Вариант №2 — Звуковой ряд не является повторением того, что и так написано на экране. В принципе, так происходит при аудио/видеозаписи
хорошей лекции, или в тех же вебинарах. Здесь применение звука оправдано, звук несет новую информацию (и, кстати — эмоции! Конечно, и при зачитывании слайда у диктора есть как-то эмоционально озвученная интонация, но в живой речи этого на порядок больше).
Т.е. к применению звука в таком варианте у меня предубеждения нет. Но, полагаю тем не менее, что целевая аудитория курсов и вебинаров по такой технологии будет несколько иной (и совершенно точно более узкой), чем у текстовых. Тут требуется постоянно быть вовлеченным в процесс, ни пропускать ни слова (ведь просто слайд назад не отмотаешь). А для многих потребителей электронного обучения в нем ценна именно его асинхронность и дробность, возможность в удобное для себя время поработать с курсом, при необходимости — прекратить в любой момент и потом в удобное же время вернуться на точку, с которой ушел.
Ну и Вариант №3 — ничего против не имею звукоряда, профессионально сделанного, чтобы его слушать без каких-то других инструментов (курса, книги...). Но это для аудиалов, к которым сам не принадлежу. И, еще раз — это должно быть не зачитывание слайдов или книги, а специально разработанное произведение, предназначенное именно для восприятия «на слух». Иными словами, не звук работающего телевизора, а специально подготовленная радиопередача.
|
---|
Рейтинг 901 | |
---|
Рейтинг 901 | Состав команды по разработке курсов (для вузов, правда) по мнению экспертов ЮНЕСКО, выглядит так:
" — Один или большее число специалистов по предметному содержанию
- Один или большее число учебных проектировщиков (образовательных дизайнеров)
- Режиссёр видео (и, возможно, авторы сценария)
- Режиссёр аудио (и, возможно, авторы сценария)
- Редактор текста
- Программист и Web-дизайнер
- Фотограф, графический дизайнер или художник
- Один или большее число администраторов»
|
---|
Рейтинг 105 | По разработке курсов — похоже на правду. Но изначально мы же говорили о более широком понимании — о команде, реализующей и поддерживающей СДО в компании/ВУЗе, не так ли?
|
---|
Рейтинг 901 | Верно, Алексей.
Спасибо за уточнение
|
---|
Рейтинг 105 | Интересно, что в списке нет руководителя проекта. Или же это входит в состав «один или большее число администраторов»?
Т.к., для описанной команды однозначно нужен руководитель, и я могу представить еще только некого администратора-кооординатора проекта, контролера сроков и т.п. ему в помощь ( а в небольшом проекте это может делать и сам руководитель проекта).
|
---|
|
Всего 0 цитат из темы форума и её обсуждения. |