Владимир, пора пожалуй оформлять эти тезисы как некое «кредо», вокруг которого можно было сплачиваться иленинговцам, его разделяющим. А то с одной стороны, традиционные вузовские подходы подсовывают, с другой — продвигают виртуальную реальность с теми же педагогическими приемами XVIII (если не раньше) века, только на новой технологической базе. Ладно, когда у тебя есть приличный практический опыт, позволяющий судить о том, что эффективно, а что нет, что уже вчерашний день, а что — пока слишком ранняя для реального внедрения инновация. Но многие заказчики, и входящие в нашу профессию новички рискуют быть полностью дезориентированными.

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

Легитимность не получают, ее берут:). Других организованных экспертов, кроме этого сообщества, и сообщества eLearning PRO (на очень большой процент совпадающих между собой), особо и нет. Вопрос, какой целевой аудитории важна будет экспертность, доказываемая опытом — ну а кому «шашечки».


Как минимум — тема возможной аналитической работы интересна самому e-learning сообществу. Можно подумать, как сделать ее интересной HR-директорам. По поводу ВУЗов — не знаю, интерес на низовом уровне явно есть, а вот с ЛПР?

И, солидаризуясь с Валерием Павловичем (Veselejka) — чтобы был конкретный результат, просто общения в форуме недостаточно. Нужны другие формы, четкая постановка задачи, управление процессом.

Очень здравая мысль! Очень хочется чтобы она не «растворилась» в разговорах, как это бывает в форумах. Тем более — с учетом перезда сообщества с NING и неизбежных переходных процессов.
Может быть, стоит после переезда инициировать отдельную дискуссию по этому поводу — да с видением конкретной цели и результата, хотя бы написания совместной аналитической статьи несколькими экспертами сообщества.
Сам с удовольствием поучаствовал бы в такой работе, используя свой опыт со стороны бизнеса (директор по персоналу в крупных компаниях в авиации, энергетике и др.отраслях). Неплохо знаю среду бизнес-школ (и сам тьютор), соприкосновение с ВУЗами вводит в ступор:). Правда, могу говорить о продукте, выпускаемом ВУЗами, только в инженерном сегменте и «менеджеров». Совсем не представляю, что происходит с естественнонаучными специальностями и гуманитарными (но готовящими не «менеджеров»).

Ян, хорошее описание практической работы консультанта по оргразвитию — только зачем его пед.дизайнером-то при этом называть?
Это шутка, поясняю на всякий случай. Если серьезно, то я сторонник баланса анализа и синтеза:
1) Выделить специфичные роли и функции, специфические компетенции
2) Постараться соединить их в конкретной должности

И тогда — говоря о том, должен ли педдизайнер думать о том, увеличатся ли объемы продаж после прохождения разработанного им курса — я прежде всего спрошу — а мы о роли или позиции говорим? Если о роли — то, на мой взгляд, пед.дизайнер обязан обеспечить достижение целей учебного процесса, а не всего бизнеса в целом. А если в должность педдизайнера включены функции и менеджера проектов, и тьютора, и HRa — вполне может быть, можно и за продажи с него спросить до кучи. Но — опять же, осмысленно это произошле или случайно, или просто потому что больше никого и нет («все в одном флаконе»)?
Каюсь, не довел до логического конца обсуждение ролей в команде проекта ДО — обязуюсь исправиться:)

-

Ссылка на запись вебинара «Обзор современных LMS» неверна — содержит ссылку другой вебинар

А что именно интересует?
- Мотивация сотрудников на обучение?
- Технологии корпоративного обучения?
- Выявление неформализованных знаний организации и передача их другим сотрудникам?
Наверное, еще много возможных «проблем» можно выявить. Ну и при минимальном желании найти интересные материалы в Интернете и книгах (в большинстве своем также доступным в Инете).

У меня у двоих при попытке зарегистрировать их в группу творилось странное — мне приходила заявка, я ее подтверждал. Но в списке группы человек не появлялся, и войти не мог. Более того, он исчезал из общего списка пользователей сайта, но при попытке зарегистрироваться сайт снова говорил, что пользователь с таким е-мейлом уже есть:(
Я не мог долго экспериментировать над живыми слушателями бизнес-школы, и после двух-трех сбоев у каждого пошел по пути наименьшего сопротивления — через общий форум.

Очень своевременная и правильная тема. Я для пробы для одной группы курса «Стратегия» в Международной академии бизнеса сделал полное сопровождение на kalmykov.ning.com. Публиковалось:
- расписание,
- материалы и задания к предстоящим занятиям,
- презентации, раздаточный материал и копии плакатов и файлов, наработанных на каждом занятии (где-то с половины курса студенты прекратили работать с плакатами и whiteboard — настояли на том, чтобы все делать сразу на компьютере)
- цитаты из первоисточников (так что к концу курса получилась вполне достойная христоматия)
- видео — записи вебинаров этой группы на WIZIQ
- само собой, форум
- мой блог как тьютора (более эмоционально-открытый и философский, чем функционально-ориентированные записи в форуме)
- фото с занятий и т.п.

В целом функциональность ning меня устроила. Маленькая ложка дегтя — как-то неустойчиво и «неисправимо» работала возможность организации закрытых форумов по группам. В результате пришлось все общение пперенести в общий форум. А это, в свою очередь, привело к необходимости:
- запаролить весь сайт целиком
- думать, что делать после завершения работы с этой группой и начала работы со следующей. Хочется сохранить все наработанное, иметь возможность давать не сразу, а по ходу обучения доступ студентам к общим ресурсам (Хрестоматии), но не открывать им форум предшествующей группы — пусть задают свои вопросы и думают самостоятельно. Возможность создания закрытых групп теоретически как раз это и решает — но на практике слишком много багов.

Ning вполне тянет на PLE — я как тьютор бизнес-школы его так и использую. И как раз функционала нормальной LMS чуть-чуть и не хватает:
- посмотреть активность конкретного студента не только на блоге, но и в учебных курсах, тестах
- получить сводную статистику (впрочем, т.к. с меня ее никто не спрашивает, это не так и важно).

Поставленные вопросы совершенно уместны. Но, имхо, в контексте приведенного мной «кейса» первое ветвление дерева решений — это хочет ли компания добиться изменения в поведении сотрудников — или чего-то другого (в частности, информирования). А приведенные Вами вопросы (кроме, пожалуй, первого — куды ж без целей) — это уже дальнейшее ветвление.

Как идут дела с исследованием? Сможем ли увидеть какие-то результаты?

Не знаю, смешно ли это, но вот недавний разговор с Заказчиком — компанией, которая и меня знает, и я ее внутренние бизнес-процессы знаю хорошо. Нужен «продуктовый» курс. Предлагаю сделать «квест» — т.е. чтобы обучающийся за «героя» последовательно прошел основные процессы связанные с этим продуктом. Интерактив — в выборе правильных действий или ответов в ключевых точках (иначе сюжет слегка ветвится, но в итоге есть только один правильный путь выполнения процедур). никакой излишней «мультяшности», скорее — постепенно развивающийся кейс Цель — научить людей правильно действовать и закрепить «правильную картину».
7 (!) часов переговоров, показа примеров аналогов и т.д... Результат — заказчик согласен только на своей формулировке цели: «сотрудник должен быть информирован о характеристиках продукта». Курс должен быть простым, линейным, скучным (!!!), без игровых элементов. Цена — та же, что и в первом варианте.
Смешно?

Интересно, что в списке нет руководителя проекта. Или же это входит в состав «один или большее число администраторов»?
Т.к., для описанной команды однозначно нужен руководитель, и я могу представить еще только некого администратора-кооординатора проекта, контролера сроков и т.п. ему в помощь ( а в небольшом проекте это может делать и сам руководитель проекта).

По разработке курсов — похоже на правду. Но изначально мы же говорили о более широком понимании — о команде, реализующей и поддерживающей СДО в компании/ВУЗе, не так ли?

Чем хороша дискуссия с въедливыми профессионалами — тем, что приходится осмысливать и вербализовать почти интуитивные для себя поначалу вещи — и не всегда устоявшиеся и очевидные вроде подходы выдерживают такое испытание:)

Вот и в данном случае — в феврале про свое отрицательное отношение к озвучке я сказал «на автомате», а чтобы понять почему оно такое, и всегда ли это верно — потребовалось время.

Просмотрев не один озвученный курс нескольких производителей (все — несомненно профессиональная работа), выделил для себя несколько моментов:

Вариант №1 — если озвучка — это зачитывание слово в слово того что есть на экране (как мне кажется, именно такой подход чаще всего применяется на практике).

Вариант №2 — если звуковой ряд не совпадает с тем, что написано на экране, а соотносится каким-то другим образом (комментирует, дополняет, оппонирует...).

Вариант №3 — если изображения и текста нет, только звук (т.е. аудиокнига, аудио подкаст и т.п.)


Так вот вариант 1 кажется мне не только неэффективным, но вредным с точки зрения усвоения материала. Если я сижу перед компьютером и вижу экран — то уж в любом случае прочитаю текст быстрее. чем его проговорят. На что-то потрачу больше времени, что-то просмотрю по диагонали, к чему-то вернусь повторно. Идущий фоном в заранее заданном темпе, с смысловыми ударениями не всегда совпадающими с моим пониманием — голос диктора меня только отвлекает. По сути, вместо работы с материалом, вольно или невольно, мне приходится совмещать два потока информации — аудио и визуальный, как-то их синхронизировать... «Процессор» грузится, а результат на выходе — ноль (т.к. информация, оказывается, та же).
Вариант «а не надо смотреть на экран, можно просто слушать» — не рассматриваем, т.к. а) если без потери информации мультимедийный курс можно только слушать — это в чистом виде Вариант №3, б) а если озвучка не рассчитана на только аудио восприятие (например, озвучивается что-нибудь вроде «Посмотрите на этот график...») — то она автономно не работает.
Ну и вообще, самое базовое правило любой живой презентации «со слайдами» — не надо их читать вслух! Думаю, это и к учебным курсам также относится.

Вариант №2 — Звуковой ряд не является повторением того, что и так написано на экране. В принципе, так происходит при аудио/видеозаписи
хорошей лекции, или в тех же вебинарах. Здесь применение звука оправдано, звук несет новую информацию (и, кстати — эмоции! Конечно, и при зачитывании слайда у диктора есть как-то эмоционально озвученная интонация, но в живой речи этого на порядок больше).
Т.е. к применению звука в таком варианте у меня предубеждения нет. Но, полагаю тем не менее, что целевая аудитория курсов и вебинаров по такой технологии будет несколько иной (и совершенно точно более узкой), чем у текстовых. Тут требуется постоянно быть вовлеченным в процесс, ни пропускать ни слова (ведь просто слайд назад не отмотаешь). А для многих потребителей электронного обучения в нем ценна именно его асинхронность и дробность, возможность в удобное для себя время поработать с курсом, при необходимости — прекратить в любой момент и потом в удобное же время вернуться на точку, с которой ушел.

Ну и Вариант №3 — ничего против не имею звукоряда, профессионально сделанного, чтобы его слушать без каких-то других инструментов (курса, книги...). Но это для аудиалов, к которым сам не принадлежу. И, еще раз — это должно быть не зачитывание слайдов или книги, а специально разработанное произведение, предназначенное именно для восприятия «на слух». Иными словами, не звук работающего телевизора, а специально подготовленная радиопередача.

Коллеги, не пора ли нам подвести черту под перечнем ролей? Есть ли еще какая-то функциональная область в реализации проекта СДО, нами не охваченная?

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

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

Может, начнете параллельно? Как практик внутрикорпоративного СДО — я против озвучки (а также в большинстве случаев — видео). Как эстет и перфекционист, рад был бы быть переубежденным:)

Владимир, может быть из-за того, что по жизни я сначала стал тьютором дистанционного обучения — и только спустя несколько лет оно стало становиться очень понемногу «электронным» — я не то чтобы не представляю «чистого e-L» как общения исключительно человека с программой — я не вижу в этом необходимости, равно как и особых проблем в том, чтобы в обучении в той или иной мере всегда присутствовал живой тьютор.
Если обучаемый после прохождения чисто электронного курса задает содержательные вопросы в форуме, и ему отвечают эксперты в предметной области и тренеры учебного центра — они в этот момент играют роли тьюторов? мы имеем элементы смешанного обучения?
Если нормативную часть продуктового курса обучаемый проходит по электронным курсам, а практические навыки отрабатывает на очном тренинге с тренером — это смешанное обучение?

Для полноты ролей предлагаю тьютора в ролях рассматривать, а уж насколько он будет использовываться в конкретной архитектуре обучения — это конкретика, решаемая каждый раз от задачи, ресурсов, культуры компании в конце концов. Мы же примерно так договорились поступать с группами ролей, связанных с видеосъемкой, игрой актеров, озвучкой, не так ли? — т.к. исключать их во избежание потери полноты картины не стоит, но и «на берегу» ясно, что это роли специфические, которые в значительном (если не подавляющем) количестве корпоративных проектов e-L не возникают (а в большинстве других — реализуются на аутсорсинге).

Что касается «горячей линии». Реальный опыт внедрения одной из хорошо знакомых Вам СДО, с тысячами пользователей по всей стране, с централизованным сервером позволяет говорить о некоторых закономерностях:
1) средний пользователь обычно слабо способен правильно диагностировать свою проблему — то ли это проблемы настроек у него на рабочем месте, то ли со связью, то ли внутри СДО. Поэтому ему надо дать возможность звонить/писать в единую службу техподдержки, в которой проблему диагностируют, и либо дадут ответ, либо перенаправят специалисту.
2) Не считал в процентах, но по моей оценке, запросы делятся примерно в следующей пропорции:
- «Не могу войти на портал» 25% — проблемы настроек компьютера, сети, перебоев в работе сервера, настроек IE, использования неподходящего броузера или опер.системы. Ответ должен даваться IT-специалистами (дело даже не только в том, может ли кто-то другой дать компетентный ответ. Я, без ложной скромности, на большинство этих вопросов компетентно отвечу. НО: многие проблемы в части сервера, настройки маршрутизации сети я не решу — это епархия сисадминов)
- «Забыла пароль» — 25% — решение — установка пароля по умолчанию администратором прикладного уровня (администратором СДО)
- «Назначьте курс/тест» — 30% (и не надо мне про документооборот заявок на обучение — описанный поток идет при том, что у каждого пользователя есть возможность назначить курс/тест себе самостоятельно) — RTFM
- «Не могу найти в системе архива/новостей/форума» 10% — RTFM и голосовая навигация пользователя по меню:)
- и только процентов 10 — по содержательной части курсов/тестов, непоняткам или выявленным ошибкам. Это — в форумы по курсам.

Т.е. нужно:
- «окно приема заявок» — телефон, e-mail
- техническая горячая линия
- горячая линия административной поддержки в СДО
- и содержательно, чаще всего без особых временных рамок — обсуждение возникших учебных проблем в форумах и т.п.

Владимир, спасибо Вам большое за ссылку, эта ветка на уважаемом мною форуме как-то ускользнулв от моего внимания. Жаль, что она как-то ушла в тему инструментов eL.

Как понимаю, выписанный Вами список — это выписка или компиляция из должностных инструкций типичного «специалиста по СДО» в одном лице. Как список функций — и собственно по четкости формулировок, так и по желанию видеть это обязанностями одного человека — на мой взгляд, весьма уязвим для критики.

Что в русле нашего обсуждения я вынес из указанной Вами ветки обсуждения:
Еще несколько ролей:
1. Оператор-специалист «горячей линии» по поддержке пользователей (а может ли он быть один?)
2. Технический писатель (инструкций и т.п.)
3. «Архитектор обучения» (на мой взгляд, одна из подролей руководителя, но это мое imho)
4. Сценарист
5. Целый набор ролей, связанных с озвучкой (никогда не делал курсов в корпоративном СДО со звуком, так что просто не считаю себя компетентным обсуждать эту часть)
6. Тестер разработанных курсов, портала

Совершенно согласен, причем именно с этим категорическим условием — тестируем усвоение именно того, что дали в учебном материале.
Я также считаю, что проверка знаний «того, что сотрудник и так обязан знать по должности» (и того, что содержится в куче положений, инструкцтй, приказов и т.п., однажды показанных ему — или даже не показанных) — тоже недопустима, без предварительного перевода их в учебный материал. Или, как некий компромисс с действительностью — без наличия возможности из учебного курса по ссылке обратиться к тексту нормативного документа, знание которого необходимо для ответа на тесты.

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

Алла, собственно эта дискуссия была инициирована тем, что попытавшись осмыслить собственную работу «СДО-в-одном-лице», я был поражен количеством ролей. Думаю, я не одинок. Распределение функций между внутренней командой СДО и провайдером СДО, или внешними провайдерами отдельных услуг — может быть весьма разнообразным (но, наверное, все же не любым — и это тоже хочется обсудить в уместное время).
Если дотошно не выявить специфические функции (а для их выполнения нередко нужны специфические умения и навыки), а сразу «по понятиям» укрупненно распределить зоны ответсвеннности, то, на мой взгляд, и создается почва для ситуаций, когда СДО «рулит» ИТ-шник, или программисту-кодеру курса поручается сделать и его графический дизайн...
(я, конечно, говорю о примерах скорее ошибок в управлении проектом СДО).
Если же по счастливому стечению обстоятельств у вас есть в одном лице квалифицированный программист, талантливый дизайнер, опытный предметный эксперт и знающий педдизайнер — так грузите его по всем ролям! (но не забывайте о пределах общей нагрузки на 1 человека и лимите в 24 часа в сутки).
Впрочем, в последнем случае таким универсалом приходится счиатать себя и грузить нещадно...

Про управляемость проектом. Управлять-то в любом случае приходится не ролями, а людьми. Управлять, ставя им задачи, сроки и контролируя их исполнение. Чем четче мы знаем, что, кто и когда должен вложить в общий результат — тем проект потенциально управляемее.

Для того, чтобы распределить функции (оставим управление временем проекта за рамками, ок?) — удобно составит таблицу распределения функций (и вот десь у нас уже будут конкретные люди, которых будет горазде меньше, чем ролей:( )

Вопрос проведения границ — входят/не входят в команду — предлагаю оставить на завершающую часть анализа, когда мы доберемся до оргструктуры проекта СДО.
Пока же считаю возможным резюмировать, что мы увидели роли «эксперт предметной области» и «эксперт по извлечению знаний из предметных экспертов» :)

Наверное, это тема для отдельной дискуссии в отдельной ветке — но лично у меня есть ощущение (пока просчитанное"в цифрах" только для одной конкретно ситуации одной организации), что аудитория в 100-200 сотрудников для внутрикорпоративного СДО — это путь к угасанию проекта после первого цикла обучения... При такой численности необходимый набор тем обучения, наилучшим образом реализуемого именно eL, достаточно быстро проходится «на раз», а «внутренней емкости рынка» (численности сотрудников компании) с учетом текучести, динамики движения кадрового резрва и т.п. не хватает, чтобы поставлять новых обучаемых в необходимом количестве (или если на это же самое посмотреть не со стороны СДО, а владельца бизнеса — удельные затраты на обучение 1 сотрудника резко вырастают и перестают быть привлекательыми).
Именно поэтому в начальном кейсе я поставил численность 1000 человек (хотя imho это нижний предел).

Алла, Вы меня опередили, я по тьюторской привычке «выводил» дискуссию к целесообразности подняться еще на 1 уровень обобщения, и выделить группы ролей (с соответсвующими им функциональными областями).

«Для себя» я выделял следующие такие области:
- Содержательная: наполнение обучения (СДО в увязке с другими формами), методология, педдизайн и собственно обучение
- Технологическая: перевод содержания в формат СДО / blended learning, настройка системы, сервера и т.п.
- Административная — формирование групп, доступ, информирование, техподдержка по поводу работы в СДО, аналитика и отчетность
- Руководство — координация всего процесса и коммуникация с заказчиком (особенно, если он — внутренний, первое лицо компании)!

Фактически, по п.1-7 Вашей классификации, мы с Вами ни в чем особенно не расходимся.

Не могли бы Вы прокомментировать свои пп. 8-9?

Мы же пока не о «головах» — о ролях говорим... Что команда в 3-5 человек вполне дееспособна для практически любых проектов — как управленец я вполне ощущаю — но это именно ощущение. А хочется сначала аналитически разложить все роли, функции — а уже потом «упаковать» их в конкретную структуру проектной команды.

С другой стороны, если есть успешные проекты, реализованные 1-2-3 людьми (и никто из них от истощения не умер) — то перегрузка приемлема?

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

- качество тестов, подготовленных непосредственно предметными экспертами, крайне низкое
- кaк правило, эксперты-практики используют простейшие форматы тестов — multiple choice или multiple response, игнорируя другие возможности
- другими вопросами (обоснованное количество вопрсов в тесте, установление весов, распределение весов и количества вопросов по разделам в случае большого теста по предмету/продукту в целом, анализом статистики ответов на вопросы) эксперты заниматься также не хотят или не могут

Т.е. нужен «педдизайнер по тестам» .

И (гулять так гулять) — кодер тестов (с требованиями к квалификации, вообще говоря, ниже, чем к кодеру по курсам)

Собственно, описанное выше не дает возможности компании объективно оценить стоимость проекта и при сравнении с предложениями с рынка:
а) руководству кажется, что «мы тут у себя все это силами одного человека делаем и только за его зарплату» — на самом деле, не только его одного, и не только зарплату тратят — но полных затрат не знают
б) незнание собственных затрат приводит к отказу от аутсорсинга — поскольку здесь-то деньги конкретные и кажущиеся большими.

Рискуя увести обсуждение в сторону — замечу, что действительно чеще всего у нас «так не делается» — но далеко не всегда потому что руководитель проекта так не сделал.

Удивительно — но в моей практике управления проектами (не только СДО) любой «честно» просчитанный проект, учитывающий полные затраты, не проходил!

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

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

Вот и не включаются в бюджет проекта расходы, «проходящие по другим статьям». Частично это еще и влияние бухгалтеров, которым всякое разнесение затрат по разным статьям аналитик — большая головная боль.

А результат — заниженная стоимость проекта, «размазанные» по другим статьям затраты, нужные Вам в именно этом проекте. Все бы ничего, только при возможных кризисах и просто корректировках бюджета результат для Вашего проекта непредсказуем. Да и деньгам других подразделений Вы не хозяин. Ну и эффективность проекта становится категорически сложно просчитать.

Например, в одной из компаний я долго бился, чтобы доказать, что при внедрении СДО надо, с одной стороны, учитывать рост затрат на интернет-трафик, с другой — снижение командировочных расходов тренеров в регионы или командировки сотрудников из регионов для обучения в Учебном центре (а совокупные затраты на подобные командировки многократно превосходили необходимые затраты собственно на СДО и фонд оплаты труда квалифицированной команды СДО).
Каюсь — за два года так и не смог сломать систему — для финансистов-бухгалтеров эти затраты шли по разным статьям и бюджетам (бюджет СДО — в составе HR бюджета, зарплата преподавателей-очников и команды СДО — в ФОТ соответтвующих подразделений, трафик — IT бюджет, командировки преподавателей — бюджет операционных расходов Центрального офиса, и соответсвенно командировки сотрудников из регионов — бюджеты этих региональных «дочек»). При этом, при корректировке бюджета, требовали снижения затрат по проекту без учета того, что ты экономишь по другим статьям. Или неожиданно можно было узнать, что деньги на СДО есть, а на трафик для него — секвестрированы.

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

И — к теме нашего обсуждения — такой старт и делается минимальной командой в 1-2 человека, в надежде «пробить» рост численности и ФОТ по ходу проекта.

Прочитал собственный пост и понял, что он может инициировать большое обсуждение на вечную тему - а зачем, собственно, компании нужно СДО?

Поэтому, чтобы все же прийти к результату по теме «Роли, функции, структура команды СДО», предлагаю тему «Зачем компании СДО» пока не развивать либо вынести в отдельную ветку.

Со своей стороны (потихоньку доставая припрятанные заначки) добавлю:

к пункту 1.
Сисадминов надо делить — один это сисадмин сервера (скорее всего, человек в IT департаменте, отвечающий за сервер, системное ПО, настройку маршрутизации сети, почты, и т.п.).
Второй — администратор прикладной системы (импорт-экспорт данных, запуск всяких агентов, права доступа и т.п...)

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

Таким образом, коллеги, как некий промежуточный итог:
1) Мы де-факто договорились о едином понимании «ролей» и применению такого подхода в дальнейшем анализе;
2) К настоящему моменту названы следующие роли:

1. сисадмин
2. методист
3. организатор (бэк-офис центра ДО)
4. преподаватели
5. педдизайнер
6. графический дизайнер
7. программист (кодер учебных материалов)
8. руководитель проекта разработки учебного материала (курса)
9. видео и звукооператоры
10. контент-менеджер учебного портала
11. авторы контента учебного портала
12. литературный редактор;
13. художественный (м-медиа) редактор;
14. корректор
15. руководитель проекта СДО

Владимир, конечно, в моем начальном предложении рассматривать СДО как «сферическое тело в вакууме» содержалась доля провокации. Но очень уж хочется увидеть общие черты проблемы, а — уж потом, с пониманием общего, как-то относиться к многообразным частным деталям.

С этой точки зрения, и ваша классификация объектов для привязки СДО (= целям ее создания в компании, я правильно понимаю?) тоже достаточно обща. И вряд ли где-то мы встретим СДО, созданную исключительно под одну из сформулированных Вами целей (по сути, а не по нормативным документам).

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

Я, со своей стороны, видел СДО только изнутри. Из трех внедрений в корпорациях, не называя компании, могу идентифицировать:

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

- еще один случай (консалтинговая компания) — все, что Вы назвали, и еще немножко. Во внутренней среде — потребность «сверху» скорее в системе управления знаниями, понимаемой как средство снижения зависимости бизнеса от сотрудников-носителей уникальных знаний (путем «снятия» с них этих знаний и превращения через обучение других — в неуникальные). Конкретная СДО оказалась не очень подходящим инструментом для этого. Второе направление, более успешное — это обучение продуктам через СДО сотрудников компаний-клиентов в рамках комплексных проектов внедрения. Здесь, по сути, СДО становилась частью продаваемой бизнес-услуги, частью бизнеса компании — поэтому и более жизнеспособной.

- и третий кейс (страховая компания) — это, по Вашей классификации — обучение «актуальным здесь и сейчас компетенциям, знаниям (продуктов и процессов, включая новые) и навыкам (например, сервиса клиентов)» в чистом виде. И, несмотря на определенные сложности, я уверен что СДО в этой компании переживет тяжелый период и будет развиваться — пусть, как функция утилитарно-поддерживающая, но необходимая и эффективная.

Так и я признаюсь в этом «раздвоении личности» (только не на 2, а на N) — действительно, без этого ни о каком креативе и подходе к вопросу с нескольких сторон речи быть не может.

Елена, большое спасибо за обстоятельный ответ! Постараюсь на многие мысли из него дать свой отклик, но чуть позже (цейтнот:( )
По одной мысли устоять не могу — относительно того, что «идеальная команда» (а у нас с вами близкие параметры получились — 12-14 человек, причем я у Вас увидел то, о чем забыл, и с другой стороны — у меня есть некоторые другие роли) — не собирается исключительно из-за того, что руководитель внедрения не смог это «пробить».
Субъективный фактор, конечно, важен — но все же, может наше видение «идеала» слишком уж расходится с реальными возможностями или потребностями наших заказчиков?

Кстати, как мне кажется, реализация довольно масштабных проектов корпоративных СДО силами 1-2-3 человек — обычная практика. Явно здесь есть функциональная и ролевая перегрузка. Составив матрицу «функция-роль», можно было бы эту перегрузку увидеть наглядно. А потом уже с учетом всех факторов, включая пресловутый кризис — говорить о количестве людей, о должностях, о структуре управления проектом СДО.

Владимир, несомненно, совместную деятельность группы людей (или команды — только давайте возможную дискуссию о разнице между группой и командой вынесем за рамки _данного_ обсуждения) можно рассмотреть с разных сторон и в свете разных теорий. Можно выделить роли в команде по Белбину, или по Хэнди (MTRi), или по Маргерисону и Маккэну, или по Томасу. Можно углубиться в типологии личности и то как это влияет на групповой процесс (Юнг, соционики, теория DISC и т.п.). Но все это — вопросы общего менеджмента.

Я предлагаю скорее исходить более сфокусированно — из практики управления проектами (и в необходимой мере — теорий из этой же области), а где-то — еще более узко — из управления IT проектами. Ни в PMBoKe, ни в RUP, ни в Microsoft Solution Framework (MSF) не даются абсолютно четкие определение термина «роли», они скорее качественные. Например, в RUP — «Роль — область функциональных обязанностей компетенции и ответственности, которые должен иметь человек или группа людей».
Например, по RUP типичные роли — менеджер проекта, аналитик, архитектор, разработчик, тестировщик (каждая из ролей может быть разложена еще на несколько). Это не должности, и не одна функция — но именно сгруппированные в одной роли задачи, компетенции, специфические инструменты и т.п.
В MSF — нечто весьма похожее.

Но за Ваш неожиданный взгляд с точки зрения ролей по Белбину на работу человека, выполняющего работу группы — «а как уживается это все в одной голове?» — спасибо. Все части моего "я" уже активно это обсуждают:)

Да, говоря о «кейсе», я имел в виду, что за отправную точку можно взять некую «типичную» компанию, использующую СДО, а разнообразные частности конкретных ситуаций рассматривать как факторы, изменяющие (возможно) набор и распределение ролей.
Типичной компанией, в которой применение СДО является не блажью, а объективной необходимостью бизнеса, в российских условиях, на мой взгляд, является:
- компания, успех бизнеса которой напрямую связан с операционной деятельностью сотрудников
- деятельность значительной части сотрудников, напрямую влияющих на доходы компании, достаточно унифицирована
- географический масштаб и количество сотрудников компании достаточно велико — как минимум филиалы в регионах, аудитория для обучения от 1000 человек