суббота, 28 февраля 2015 г.

eLearning на этапе адаптации. Осторожно - подводные камни!

Адаптацией принято считать период, когда человек осваивается на новом месте или в новой для себя роли. Этот период может занимать различное время, в зависимости от того, к чему адаптируется человек.

Чтобы говорить предметно, для рассуждения выбран следующий способ определения периода адаптации: в ТК РФ определен максимальный срок испытательного срока при приеме на работу нового сотрудника в 3 календарных месяца. Большинство организаций связывает период адаптации с этими 3-мя месяцами. Поэтому речь идет, фактически, об обучении (в том числе elearning) на испытательном сроке.

Как организовывают обучение на адаптации, какие приоритеты расставляют, какие цели ставят и как контролируют процесс обучения - сегодня об этом.

Адаптационное обучение еще называют "входным" или "вводным". Различают общекорпоративное и  профессиональное (или обучение по проф. компетенциям) обучение.

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

Как правило, высокий приоритет обучения отводится новым сотрудникам, создающим основную ценность бизнесу (например, производство, если это производственная компания; продажи, если это продажи продукта или услуги.). И основные ресурсы и инструменты используются для обучения этой приоритетной группы сотрудников. При таком подходе есть свои особенности.

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

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

Когда появляется elearning, обучение знаниям может увеличиваться с геометрической прогрессией (особенно, если наладить наполнение и обновление базы) и появляется желание формализовать все-все знания и навыки. И все, кажется, замечательно!

Но, рано или поздно, наступает момент, когда базы знаний наполнены на столько, что на ее изучение остается все меньше времени: если изначально новый сотрудник за 3 месяца испытательного срока проходил от силы 2 электронных курса и посещал 1-2 тренинга по 8 часов, а остальное время находился на стажировке, то по мере наполнения базы знаний, количество программ (очень важных на взгляд руководства) увеличивается, а сроки изучения сокращаются, так как период испытательного срока остается прежним.

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

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

Как же тогда быть? Если обучать надо? Полезных знаний и навыков много, и все хочется дать?

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

Всегда ваша
Денисова Елена,

понедельник, 23 февраля 2015 г.

О проекте автоматизации HR-процессов. Этап 2. Внутренняя или внешняя разработка. Part 13

Если вы уже приняли решение в проекте автоматизации обратиться за помощью к внешним специалистам и разработчикам, то это сообщение можно не читать! Данный текст посвящен тем смельчакам-"пионерам", кто выбрал тернистый путь самостоятельной разработки.

Я бы памятник воздвигла тем, кто смог реализовать все свои технические мечты и задумки, будучи не профильной IT организацией, в том виде, как задумывалось в проекте, и при этом уложившись более или менее (в приделах 15%) в бюджет и сроки.

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

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

Что может быть проще - передать готовый пакет документации на разработку и спокойно ждать результата? Если бы так было возможно в действительности, это было бы сказкой, а не жизнью!

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

Поэтому, прежде чем приступать к разработке необходимо договориться о правилах взаимодействия:

1. Приемка и согласование промежуточных результатов
2. Фиксирование всех возникающих багов и хроники их исправления с итогами
3. Подача, приемка и отработка заявок заказчика на дополнительные доработки или внесение изменений, не учтенных в ТЗ
4. Правила апробации
5. Условия передачи системы в эксплуатацию
6. Распределение зон ответственности за результат
7. Правила и условия предоставления отчетности по разработке
8. Механизмы контроля за качеством разрабатываемой программы
9. Другое

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

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

1. Расстановка приоритетов при разработке. Чтобы добиться автоматизации ваших процессов нужно доказать, что это важно и срочно, и имеет более высокий приоритет, чем у ваших коллег из других подразделений. Но даже если вам это удалось, не стоит расслабляться, приоритет нужно будет поддерживать на всем протяжении проекта - в любой момент может оказаться, что "ресурсов нет" и "есть более приоритетные задачи". В большей степени это касается сопровождающих функций, которые напрямую не обеспечивают прибыль компании, но тем не менее важны для общей работы организации, и которые не в меньшей мере трудоемки и рутины.

2. Внутреннее качество разработки сложно контролируемо. При оценке результатов и скорости выполнения работ вы не можете опираться на договор, только на ТЗ. Если при работе с внешним разработчиком, вы можете воспользоваться системой штрафов, неустоек или просто оплаты труда, то с коллегами все намного сложней, особенно если они получают зарплату, а проекты могут выбирать - что-то проще и быстрее, а что-то можно и подольше делать, так как з-п все равно платят.

3. Внутренняя клиентоориентированность ниже, чем внешних разработчиков. Это и понятно. Если у внешних организаций высокая конкуренция за клиентов (могут и отказаться и уйти к конкурентам), то от внутренних разработчиков никто не уходит - здесь всегда есть очередь и работа. Зачем договариваться с внутренним клиентом, если все равно придет к нему и будет просить повысить приоритет и выполнить задачу?

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

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

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

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

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


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

Также буду благодарна вашей обратной связи и вопросам. Пишите и я отвечу!

To be continued...

Всегда ваша
Денисова Елена,

суббота, 21 февраля 2015 г.

Управление знаниями через создание электронных курсов. С чего начинаете вы?

Когда у вас уже сложился определенный механизм или алгоритм действий, или у вас есть решение сложной задачи, то в какой то момент все это перестает восприниматься как нечто уникальное или неординарное - есть и есть.

На днях я прочитала интересный комментарий, что оказывается, elearning никакого отношения не имеет к созданию знания или его формализации. Якобы, система дистанционного обучения способна только принять уже готовый контент: "Создание контента подразувает наличие уже формализованного знания и СДО или система ЭО на этапе формализации совершенно ни при чем.".

Для меня эта фраза означала культурный шок. Но потом, я подумала, и поняла. что наверное, для меня столь очевидное, для кого-то не является таковым.

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

Другими словами, основой любого электронного курса являются знания индивидуума, а имеющиеся формализованные документы (если таковые есть) являются дополнением к общей картине.

Каким же образом elearning "формализует" знания? 

Небольшое отступление в сторону теории управления знаниями. 

В своих диссертационных исследованиях и практических работах я опиралась прежде всего на теорию создания организационного знания И. Нонака и Х. Такеучи ("Компания - создатель знания", Оксфорд Юниверсити Пресс 1995), а именно модель "Спираль создания организационного знания". Суть модели заключается в спирали трансформации знаний из неформализованного состояния в формализованное и обратно. Различают 4 стадии трансформации знаний:

1. Из неформализованное в неформализованное знание (социализация) - передача знаний от индивидуума к индивидууму по средством рассказа или показа (стажировка).
2. Из неформализованного в формализованное знание (экстернализация) - на основе слов, опыта и пр. создаются документы на любых носителях (регламенты, инструкции, видео, и пр.).
3. Из формализованного в формализованное знание (комбинация) - на основе имеющихся формальных знаний (данные, тексты, графики, рисунки, др. документы на различных носителях) создаются другие документы.
4. Из формализованного в неформализованного знания (интернализация) - потребление индивидуумом формализованных знаний и применение в своей деятельности после личного осмысления, осознания и трактовки, создавая новое неформализованное знание.

Сама по себе организация не может создавать знания, так как знания не могут существовать без индивидуума. Только, обеспечивая полный непрерывный цикл трансформации знания можно создать и развивать организационное знание. Что, примечательно, при обеспечении данного цикла, спираль знания охватывает не только сотрудников организации, но со временем и охватывая окружение организации (ее клиентов, партнеров и даже конкурентов).

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

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

Поэтому организации, кроме создания культуры обмена знаний, используют различные инструменты IT. eLearning как никогда лучше всего подходит по тем причинам, что система дистанционного обучения содержит в себе как механизм создания, хранения и обновления формальных документов (обучающих электронных курсов), так и средства коммуникации в процессе создания учебных материалов и в процессе обучения (фактически, этап интернализации). Таким образом, СДО отлично подходит для реализации всех 4 видов трансформации в циклическом виде:

1. При создании электронных учебных материалов необходимо искать истоки знаний прежде не в документах, а у экспертов, обеспечивая 1-ый вид трансформации знаний. Специалисты elearning выслушивают и получают опыт в личном общении с экспертами и изучая непосредственно на практике их опыт.
2. Полученную информацию от экспертов структурируют и облекают в форму, создавая документы (например, интервью, видеозапись, звуковые записи и т.д.)
3. На основе регламентов и других документов + информация полученная и обработанная со слов экспертов осуществляется 2-ой вид трансформации знаний - из документов создаются электронные обучающие курсы с применением к ним всех известных методических инструментов (педдизайн, геймификация, сторителлинг и др.).
4. И на последнем этапе СДО предоставляет доступ к учебным материалам, по которым люди учатся, делают собственные выводы и пробуют на личной практике. В результате получают новые знания, а также делятся обратной связью, которая в свою очередь является толчком к новой формализации уже новых неформальных знаний и, соответственно, новому витку цикла создания организационного знания.

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

А теперь немного подробней о первых двух этапах трансформации знаний.

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

В действительности же, я не уверена, что все специалисты e-learning работают также. 

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

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

Подошли к самому важному вопросу! Для чего используется elearning? Мы используем его для решения управленческих задач - предоставляем доступ к знаниям сотрудникам, когда им нужно решить их рабочие проблемы и задачи - исправить или скорректировать ошибочные действия, или размножить успешный опыт... В любом случае, формальных документов для этого явно недостаточно! 

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

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

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

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

А как работаете вы? Буду весьма признательна вашим ответам!

Всегда ваша
Денисова Елена,


понедельник, 16 февраля 2015 г.

О проекте автоматизации HR-процессов. Этап 2. Подготовка проектной документации. Part 12

Выбор команды проекта очень важен. И я уверена, что вы подходите к этому вопросу со всей серьезностью. Если уже принято решение о самостоятельной разработке или передаче проекта внешним разработчикам, то необходимо также определить, кто напишет техническое задание на основе разработанных бизнес-схем и ваших требований к разрабатываемой системе (БТА).

Чтобы ответить на него, необходимо разобраться, о какой документации идет речь и в чем суть задачи. Давайте еще раз взглянем на процесс автоматизации. Чтобы поставить задачу программисту на разработку программного обеспечения (или доработку), необходимо составить техническое задание, где указаны все алгоритмы программы, условия выполнения, входные и выходные данные, интерфейсы, экранные формы, описания ролей пользователей и прочее и прочее. Все, что необходимо знать до мельчайших деталей и описаний кнопочек, чтобы разработчик смог в точности воспроизвести задумки (мыслимые и немыслимые) заказчика.

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

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



Если ваша программа более сложная, чем прямая последовательность действий в 3-5 шагов, то чаще всего довольно скоро становится понятно, что самостоятельно описать собственные требования и желания крайне сложно. В этом вам может помочь системный аналитик, специалист, который грамотно и дотошно снимет с вас, как с заказчика, потребность в разрабатываемой программе, структурирует полученные данные, подготовит БТА, которое с вами согласует и напишет грамотное ТЗ для программиста. При этом, в последствии поможет вам наладить контакт с программистом, когда у него появятся вопросы (а они обязательно появятся) по разработке, а также проконтролировать правильность написания готового программного обеспечения с запланированным результатом. Более того, на этапе реализации аналитик поможет вам скорректировать техническое задание с учетом выявившихся новых ваших пожеланий (Как бы вы не старались продумать все до мельчайших подробностей и условностей с помощью аналитика, абсолютно все предугадать и предусмотреть невозможно - множество корректировок придется вносить уже в процессе реализации. И тогда нужно будет оперативно дописывать или корректировать уже имеющееся ТЗ, что крайне проблематично сделать самостоятельно без аналитика).

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

1. Получить на выходе не то, что ожидали
2. Потерять возможность контролировать процесс автоматизации в части реализации
3. Потерять возможность корректировать в процессе реализации без понимания системы в целом
4. Получить споры и конфликты с программистами из-за отсутствия взаимного понимания
5. Потратить впустую ресурсы
и еще множества других неприятных сюрпризов.

Принципы описания БТА и ТЗ приводить не буду, если вы не аналитик, то это вам все равно не поможет, а если аналитик, то это вы и без меня это хорошо знаете!

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

Также буду благодарна вашей обратной связи и вопросам. Пишите и я отвечу!

To be continued...

Всегда ваша
Денисова Елена,

четверг, 12 февраля 2015 г.

Система очного обучения + e-learmimg больше, чем сумма слагаемых? О взаимодействии и взаимоотношениях.

Когда я меня спрашивают, где я работаю и чем занимаюсь, я отвечаю, что работаю в сфере дистанционного обучения. Чаще всего за этим следует вопрос: "А чему учите?".

Реже, но, к сожалению, бывает и другой вопрос-утверждение, когда взаимодействуешь с представителем "очного" обучения, который о e-learning (я так подозреваю, иначе какое тут оправдание) знает "понаслышке": "А вам какое дело до того, как выглядят учебные материалы? Вы же не методист! Ваше дело разместить курс!" Или вот другая интерпретация коллеги (услышала буквально на днях) - "У вас методистов нет! Ваше дело то, собственно, набрать номер телефона, обеспечить связь на вебинаре.. и все!".

Честно скажу, в первом случае (если время позволяет), то отвечаю уже заготовленной "мини-лекцией вводного курса в e-learning" - обычно, это "прокатывает" на тусовке с бокалом чего-нибудь, или в ожидании чего-то с кем-то...

А вот второй вопрос часто вызывает спазм воздуха и жаркую волну гнева. По, правда, вопрошающий этого не видит. Что ж возьмешь с невежды? Ответить грубостью, что "Ваше то дело еще того проще - вышел на публику, поболтал и ушел"? Нет, конечно, если переходишь на грубость, то становишься на одну планку с ним. Просто улыбаюсь, и говорю, что на этот счет у меня другое мнение.

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

Поэтому сразу предупреждаю читающих это сообщение. В этот раз оно может оказаться длинным, так как я хочу разобраться с обоими вопросами! Для тех, кто в танке, и знать не знает о смежном направлении, для тех, кто в закрытом танке, кто думает, что e-learning только и существует, чтобы обеспечивать техническими средствами (своего рода IT для обучения). В любом случае, буду признательна за обратную связь тем, кто осилит весь текст!

"Чему обучаете?"

На это можно ответить кратко: "Всему!" и заработать ожидаемый изумленный взгляд. Но если есть время и желание по-обсуждать любимую работу, то можно рассказать следующее:

Да, e-learning позволяет учиться в любое время в любой точки планеты, практически, всему, если говорить от теоретических знаниях. Но как же можно учить "всему", и не обладая знаниями, накопленными веками, всей человеческой цивилизации?

А в этом и заключается основная загадка и особенность elearning.

Дело в том, что elearning ничему не учит! Это технология, позволяющая формализовать знания в электронный вид (в виде электронных курсов), применяя множество методов трансформации (в настоящее время наибольшее распространение и признание получила так называемая геймификация) вне зависимости от типа и сферы знаний. В то время, как в сообществах очного обучения обсуждают (и наверняка спорят) о преимуществах или недостатках методик проведения тренингов или других типов обучения, в сообществе elearning свои "сражения" и "победы". Удивительно, правда? В чем же отличие? 

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

Теперь вопрос подготовки учебных материалов для дистанционного обучения.

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

Дело в том, что в кажущейся идентичности разработки "очных" курсов и "электронных" курсов скрываются весьма ощутимые различия!

Начнем с того, что сами формы обучения очное (или онлайн) и электронное (самостоятельное изучение в оффлайн режиме) обучение в корне имеют различия, и материалы, которые готовятся для них тоже часто кардинально отличаются!

Предлагаю рассмотреть причины отличий.
Для проведения очного обучения (лекции или тренинга) необходимо подготовить информационный материал. В процессе проведения очного обучения учебный материал неотделим от презентатора или преподавателя. Чаще всего, имеющиеся записи или презентации являются подсказками и направляющими для обучающего. Если даже есть неточности, или отсутствие структуры в последовательности слайдов, личность презентатора (или умение тренера) сглаживает "несовершенство" подаваемого материала. И это нормально! Успех тренера зависит в большей степени от него самого - от его умения "чувствовать" аудиторию, "подлаживаться" под нее, давать нужные именно этой аудитории разъяснения. Таким образом, один и тот же материал может подаваться по разному! Более того, в разном порядке - что-то пустить вперед, что-то пропустить, что-то повторить несколько раз - все зависит от того, какая обратная связь поступает в конкретный момент времени тренинга или курса. Преподаватель управляет учебным процессом в реальном времени.

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

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

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

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

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

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

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

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

Да, есть конференции, где встречаются все HR-специалисты. Но даже там, "обученцы" работают врознь. А как бы было здорово, если бы у нас образовалось общее сообщество! 

Я мечтатель? Вы так думаете?
Всегда ваша
Денисова Елена,

среда, 11 февраля 2015 г.

О проекте автоматизации HR-процессов. Этап 2. Реализация. Проектная и командная работа. Part 11.2

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

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

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

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

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

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

Итак, прежде чем собрать команду специалистов, определитесь с вопросом - кто, где и как будет разрабатывать вашу систему! 

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

Также буду благодарна вашей обратной связи и вопросам. Пишите и я отвечу!

To be continued...

Всегда ваша
Денисова Елена,