Итоги 2013 года. Задачи и результаты e-learning и автоматизации. Чем уходящий год порадовал?

Сегодня 26 декабря, преддверие Нового 2014 года. Думаю, пора подвести итоги профессиональной деятельности в 2013 году.

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

В начале года я ставила перед собой несколько задач в двух направлениях: 

1. Завершение построения структуры "интеллектуального банка" организации на базе e-learning в текущей организации, где я работаю;
2. Автоматизации HR-процессов: в 2013 году, это процесс обучения, основанного на автоматизированном планировании как электронного, так и очного обучения, с дальнейшим автоматическим назначением всех типов обучения с учетом региональных, ресурсных и временных ограничений.

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

Сам механизм - это результат моей диссертационной кандидатской работы. В ход шли научные исследования в области системотехники, управления знаниями, педагогики, информационных технологии, методологии док. И.Адизеса, "Спиральной динамики" докт. Грейвза, MBTI, опыта японских организаций, а также педагогики; разработки и научные изыскания в области e-learning по созданию и развитию систем дистанционного обучения и разработке электронных курсов. Кроме механизма трансформации знаний (спираль развития организационного знания), основной акцент делается на качество электронных курсов прежде всего в части методологии и содержимого курсов, где информация напрямую берется от носителей знаний.

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

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

Сейчас я могу сказать, что с этими задачами я справилась успешно. Подобный опыт я теперь смогу реализовать снова при необходимости. Это чувство самоудовлетворения полученными результатами.

В дальнейшем планировалось развитие двух систем - выход на "новый виток спирали развития". Для "интеллектуального банка" - это переход от базового уровня (знания для линейного персонала) к управленческому (руководители среднего звена); для системы автоматизации - новый модули системы "Адаптация сотрудников", "Обучение после оценки" и т.д. (бизнес-процесс по адаптации уже написан, по обучению - на 80% написан).

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

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

Вот и сейчас, глядя на 2014 год, я не знаю, чего ждать - развития или разрушения... Прошло почти 4 года. А специалисты говорят, что нужно менять место работы каждые пять лет :). Может, это сигнал паковать чемоданы, доставать "зонтик Мэри Попинс" и ловить "ветер перемен"?! 

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

С наступающим Новым годом!

Пишите предложения! Возможно, нам есть о чем пообщаться :).

Blended learning. Или взаимодействие очного и электронного обучения. Как это работает?

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

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

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

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

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

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

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

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

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

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

Только тогда оба инструмента сработают эффективно.

С уважением,

Денисова Елена

https://www.facebook.com/profile.php?id=100004487832154

Обучение или мучение? Обязательное обучение в организации.

Когда в организации вводят обучение, это всегда здорово и хорошо.

Но так ли это на самом деле? Когда развитие сотрудников, новых сотрудников только-только внедряется, то происходит накопление опыта и за счет этого, знания поступают небольшими порциями по мере возникновения: все нужно для оптимизации работы!

Со временем, знаний становится больше и они автоматически добавляются в обязательный список обучения сотрудников. Какое-то время, это оказывает поразительный эффект - улучшает качество выполнения функций сотрудников и компании в целом. И вопроса, чему нужно обучать, а чему нет - не возникает даже в мыслях. Зачем? информации итак немного - все поможет!

Но наступает пора, когда знаний слишком много. А срок усваивания для новых сотрудников все также ограничен, например, испытательным сроком. При этом "бизнес" требует еще и сокращения срока ввода сотрудника в работу. Что же в этом случае происходит? Уменьшается объем обучения? Нет, конечно! Сокращается время на обучение, уплотняется график обучения, рассчитывается физическое возможность человека присутствовать на тренинге, прочитать инструкции, изучить (пролистать) электронные курсы.

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

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

Кажется, тупиковый вариант. Знания нужны, нужны все, но как же их "вложить" в голову сотрудников?

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

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

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

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

Поделитесь, пожалуйста, вашими соображениями по этому поводу в поле комментариев.

С уважением,

Денисова Елена.

Снова о разработке электронного курса: вовлеките в процесс авторов!

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

Полезла посмотреть, оказалось, что текст написан не мной, а автором, но под моим чутким руководством и направлением.

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

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

1. Получают Запрос без материалов

2. Получают Запрос с материалами

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

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

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

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

Этот процесс во многом похож процесс продажи (эту аналогию я проводила ранее, о 5 этапах продаж).

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

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

Практически, все (по опыту 3,5 лет работы) становятся нашими "повторными клиентами". И никого, при этом заставлять или дополнительно мотивировать не приходится.

Вовлекайте в процесс разработки курсов авторов! Это залог успеха любого курса!

PS Буду рада любой обратной связи. Пишите в комментариях - обязательно отвечу.

С уважением,

Денисова Елена

https://www.facebook.com/profile.php?id=100004487832154

Какими навыками должен обладать специалист по автоматизации? Интересно?

Сегодня мне пришлось задаться этим вопросом.

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

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

Вот, что у меня получилось.

В любой автоматизации есть несколько ролей: крайне редко бывает так, что один человек совмещает несколько из них или даже все. Это роль:

• заказчика
• системного аналитика
• программиста

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

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

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

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

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

Все было бы хорошо, если считать, что заказчик:

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

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

Какими же навыками и знаниями, на мой взгляд, обладает данный специалист?

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

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

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

Автоматизация процесса, это не только работа с аналитиком и программистом...

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

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

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

Резюмирую. Успех автоматизации во многом зависит не только от занятых специалистов по автоматизации, но и во взаимоотношениях с внутренним заказчиком. Если он подчиняется правилам методологии разработки, все хорошо. Если нет - скорее всего ничего не получится. Если только не найдется лидер, способный "перепрыгнуть" через руководителя и достучаться до руководства компании и вопреки всему таки автоматизировать процесс.

Какие то грустные мысли занимают меня в последние дни. Хорошо только, что в моем случае надежда пока есть и разработка по ТЗ уже началась. Нужно только продержаться...

Как поставить цель? Поговорим о принципах целеполагания

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

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

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

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

 С уважением,

Денисова Елена.

О начале разработке электронного курса. С чего начать?

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

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

Вот, и сейчас, вертятся две мысли - какую ухватить и формализовать, я до сих пор не решила!

Ну, вот, кажется, поймала!

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

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

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

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

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

Спасибо за внимание. Буду рада вашей обратной связи.

С уважением,

Денисова Елена

https://www.facebook.com/profile.php?id=100004487832154

Конец проекта. Система построена. И что дальше?

Бежит дорога все вперед,

Куда она зовет?

Какой готовит поворот?

Какой узор совьет?

Вперед по тысяче дорог

Теперь другим шагать,

А мне б - свернуть на огонек 

Да чуточку поспать.

Бильбо (Властелин колец, Дж.Р.Р.Толкин)

Знаете, что самое сложное, когда система уже выстроена, и процесс запущен? Когда часовой механизм собран, все колесики идеально подогнаны и нужно только запустить их ход?

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

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

Способов борьбы с апатией я знаю несколько. Все их можно объединить в три группы:

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

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

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

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

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

А значит, пора браться за карандаш и выстраивать новую стратегию!

С уважением,

Денисова Елена

https://www.facebook.com/profile.php?id=100004487832154

Отчет по посещению саммита разработчиков elearning - Four Elements 2013 в Москве.

Наконец то нашлось время для того, чтобы привести в порядок, структурировать и зафиксировать в блоге впечатления о посещении одной из немногих (и потому важных) конференций, посвященных elearning - Four Element's 2013 (саммит разработчиков), организатором которой является компания "Живое обучение" (CEO Тихомирова Елена).

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

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

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

Мои впечатления в целом:

Большая часть докладов была интересной и инновационной для конференции e-learning. Что сильно бросается в глаза, что многие наконец-то пришли к выводу, что технологии в нашем деле не главное! Главное - люди и методология. Что нужно понимать, для кого работаем, с какой целью и только после этого - как! Правда, видно, что озарение пришло, но полного осознания еще нет. Но радует, что после стольких лет восхваления инструментов, приходим к способам их использования. Что мотивация обучаемых заключается в концепции "Что нужно обучаемым?", а не в привычном "Как замотивировать зиучить то, что сделано?".

Пожалуй, это главный позитивный вывод, который я сделала для себя. Еще, конечно, встретила множество знакомых, пообщалась. Но и завела новые знакомства! А значит, два дня потрачены не зря, вдали от рабочего места и рабочих задач ;).

Теперь буду ждать и продолжения :).

Данный пост - всего лишь мое субъективное мнение и является отчетом моего посещения.

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

С уважением,
Денисова Елена
https://www.facebook.com/profile.php?id=100004487832154

Хочу поделиться своим достижением! Проект-"стартап" построения Интеллектуального банка завершен!

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

Система включает в себя несколько взаимосвязанных элементов - процессов, обеспечивающих полный цикл трансформации знаний:

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

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

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

Решить эту проблему можно следующим образом:

1. Разработать и настроить систему получения обратной связи от конечных пользователей;
2. Построить систему администрирования базы электронных курсов, включающая в себя:

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

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

Думаете, не получится?

 

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

 

С уважением,

Денисова Елена

 

https://www.facebook.com/profile.php?id=100004487832154

Интеллектуальный банк компании. Описание и наработки.

Готовилась к конференции и собирала материал по теме системы управления знаниями организации. Теория писалась по итогам практического опыта и теоретического анализа работы в сфере разработки электронных курсов на протяжении 3-х лет.

Пишу, чтобы сохранить наработки, чтобы не потерялись в папках компьютера. Может, кому и будет интересно :).

Интеллектуальный банк компании – это автоматизированная система создания, сохранения, развития и распространения организационного знания в компании.

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

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

Но даже, если формализованная база знаний поддерживается в актуальном состоянии, только 40% знаний можно формализовать в виде корпоративных электронных документов. И где же находится большая часть организационного знания? В умных головах сотрудников компании в виде индивидуального опыта – успешного и не очень. Источником знаний является, прежде всего, индивидуум, и он является главным активом любой современной организации. И стоит вопрос как эти 60% знаний сохранить в компании в случае смены персонала.

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

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

1. Социализация знания – Из неформализованного в неформализованное знание передается путем передачи опыта от мастера ученику, например на стажировке.

2. Формализация знания – Из неформализованного в формализованное знание переходит путем документирования, например рисование схем, написание регламентов и инструкций, описание процессов в текстовом виде

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

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

А для чего существует электронное обучение в вашей компании?

Только ли для трансляции информации?

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

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

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