понедельник, 22 декабря 2014 г.

Вы не любите универсалов? "Да, вы их просто не умеете готовить!" (с)

Итак, как и обещала, вторая часть выводов на предмет универсальности специалистов e-learning. (Сообщение: Читайте об этом здесь и здесь.)
Кроме физических ограничений развития самого человека, как разнопланового специалиста, есть ограничения временные и... снова "человеческий фактор", но уже несколько в другом смысле.
Все по порядку.
Существует утверждение, что "чем меньше команда, тем больше универсальность". Спорить с ним трудно, особенно, если смотреть на него чисто теоретически. Но можно. Если уходить в дебри "философии", то стоит разобраться для начала, что есть "команда"?
Очевидно, что командой зовут сообщество людей, работающих (или действующих) сообща ради достижения единой цели, в количестве не менее 2-х человек. Таким образом, уже опровергается сам факт "единого" универсала. Но это опять же лирика. Более подробно о работе соло, читайте Здесь и оставляйте комментарии.
А теперь поговорим о времени.
Когда человек выполняет весь процесс самостоятельно, то можно выделить и плюсы, и минусы такого способа выполнения работы.
Из плюсов лично я выделаю тот факт, что процесс находится под контролем целиком и полностью у одного человека: нет разрывов, состыковок и проблем с коммуникациями (ну, если, конечно, человек адекватный и "дружит с головой").
Также плюсом является экономия рабочего пространства и фонд заработной платы (хотя, это может быть спорно).
Минус - преимущественно поступательно последовательный принцип работы и указанные мною выше минусы, связанные с работой человеческого мозга.
Но указать плюсы и минусы - мало, так как в разных ситуациях и организациях они по разноу проявляются или не проявляются. Сказать, что работа одного универсала или работа команды - хорошо или плохо - нельзя. Все на столько субъективно и зависит от многих факторов и обстоятельств.
Попробуем же разобраться.
На самом деле, в организации может работать и один специалист на все функции дистанционного обучения (как многие и работали, и даже работают до сих пор). Вопрос на самом деле в целях самого ДО.
Давно не секрет, что численность сотрудников ДО в организации редко зависит от количества сотрудников организации. Исключение составляет необходимость широкой техпоодержки (но это, если система полуручная, и администрирование проводится также вручную, а "автоматизация обучения" заключается в электронном прохождении обучения).
Я же хочу уделить внимание другим функциям ДО. Количество команды напрямую зависит:
- от потребности организации,
- качества выполнения задач,
- их срочности и
- их одновременности выполнения.
Если требуется интенсивное развитие обучающей оболочки (программирование), оъемная разработка электронных курсов (не презентаций), и, например, администрирование (постоянно назначение, поддержка пользователей, ведение форумов и т.д.), и сроки все сжатые, то либо приходится расставлять приоритеты, либо разделять труд. Так как одновременно, работая с языками программирования и писать сценарий, делая зарисовки в блокноте, проблематично - нужно делить рабочее время на определенные пропорции.
Если же время терпит, и организации не требуются высокие темпы развития, а сама оболочка используется только для назначения электронных курсов без каких-либо сложных и необходимых изысков и доработок, и достаточно разработки полноценных курсов в количестве 1-2 в год (или вовсе не требуются - используется импорт презентаций), то и команда разработчиков здесь будет лишней. Да, и компетенции универсала в этом случае не требуются глубокими по "всем фронтам" e-learning.
Вот два основных полюса, собственно, вопроса "быть или не быть" команде или одному "универсалу".
Практически, в любом направлении ДО можно стоять перед этим выбором - один или несколько. И если несколько, то сколько?
На мой взгляд, однозначного ответа для всех и каждого, не существует - все зависит (да, да, как обычно!) - от целей ДО и стратегических целей организации. Не вижу смысла советовать, не разобравшись во внутренних процессах, сколько должно быть специалистов e-learning, какого уровня, с какими обязательными компетенциями. Так можно попасть впросак, как если бы вы советовали очки с диоптриями -2 абсолютно всем плохо видящим людям, так как "очки - это хорошо".
На практическом примере расскажу, как рассчитывать количество членов команды разработчиков. Надеюсь, это поможет прояснить картину, почему так важно изначально правильно все рассчитать, чтобы "часики работали бесперебойно и не спешили, и не отставали - работали точно вовремя".
Чаще всего e-learning используют для быстрой передачи информации большим массам людей на расстоянии с большой разницей времени и для большей части организации. Т.е. для тех, кто приносит основную ценность компании. И как правило, целевая аудитория более или менее однородная изначально (продажи, кладовщики, операционисты и другие специалисты "фронта" и "края"). Поэтому и курсы создаются в принципе в одной предметной области. Специалист ДО становится специалистом этой предметной области.
В этом случае, он даже может разрабатывать несколько курсов "одновременно", чередуя их по мере готовности материала или экспертов (у кого как построен процесс разработки). И численность специалистов напрямую зависит от выработки специалистом курсов в единицу времени, и потребности организации. Действуют законы арифметической прогрессии. Чем больше сотрудников, тем больше курсов, более или менее одинаковых по сложности контента.
Если же в организации охватываются все сотрудники всевозможных направленностей и функций, часто диаметрально противоположных, а документация либо отсутствует, либо успевает устареть к моменту своего выпуска (это более вероятно), и большая часть знаний "хранится" в головах экспертов (более 60%), то возникает вопрос - как один человек сможет параллельно разрабатывать электронные курсы, скажем, для юристов, которые ходят на судебные разбирательства, для специалистов управления рисками с их математической статистикой и матанализом и для (куда же без них) продавцов с их мотивацией и гиперактивностью?
И для каждой функции требуется не один электронный курс, а целая программа, состоящая из 5-10 направлений? А чтобы сделать хороший и эффективный курс, специалист по e-learning должен разобраться в каждой теме.
И тогда с одним направлением специалист будет работать год, а то и два, а до других дело так и не дойдет. А там ведь еще и актуализировать нужно уже созданное... Как вам такая задачка?
Все не так страшно. Рассчитывается опять же математическим путем.
 Только алгоритм расчета усложняется мультипроцессностью. Это задача с параметрами (вспоминаем школьный курс :)).
Нужно ответить на следующие вопросы и определить список параметров:
1. Сколько направлений одновременно должно обслуживаться, чтобы "покрыть" всю потребность в разработке электронных курсов организации (обеспечить актуальной базой знаний все функции организации),
2. Какого качества должны быть электронные курсы (если импорт презентаций, то дальше можно не смотреть - здесь команда не нужна, нужны только эксперты)
3. в какой срок достичь максимума покрытия знаниями,
4. когда и в каком объеме (геометрическая прогрессия, скорее всего) потребуется актуализация базы знаний
5. когда актуализация базы знаний станет большей потребностью, чем новая разработка
Исходя из этих данных и рассчитывается точное количество сотрудников. Список параметров можно дополнять и другими функциями ДО - автоматизация, развитие СДО, администрирование и т.п. (Список не исчерпывающий, дополните сами!).
При чем, указанные показатели могут равняться и нулю (т.е. не требоваться), тогда и задача упрощается, соответственно. Что-то, можно совместить (если это в смежных отраслях, и не страдает срочность выполнения задач) - это опять же решается исходя из потребностях и возможностях организации.
И напоследок резюмирую свое размышление на эту тему, что труд универсала нелегкий, и использовать его нужно с умом. Часто проще отдать рутину и "конвейер" менее профессиональным специалистам (это, кстати, может оказаться хорошим способом развития молодых сотрудников), высвободив время и ресурсы для более интересных и перспективных задач.
Всегда Ваша,
Денисова Елена
https://www.facebook.com/profile.php?id=100004487832154

четверг, 18 декабря 2014 г.

#ТехнологииОбучения Понятие универсальности в e-learning. Игрушка для специалистов. Поиграем?

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

В сети, где размещены ссылки сообщения появились интересные комментарии. Огромное за них спасибо! Есть обратная связь, а значит, есть и интерес к теме. Мнения разделились на два полюса: "Универсал - хорошо" и "Универсал - плохо".

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

Видимо, это моя ошибка, и я не смогла достаточно ясно это выразить.

Поэтому я решила по двум основным факторам (понятие универсальности и работа в команде или в одиночку) вынести в отдельные посты, расширенные.

Вначале разберемся с универсальностью.

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

Но весьма неожиданно я нашла таки (на мой взгляд) удачное сравнение! Онлайн игра Ragnarok.

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

В идеальном состоянии эти качества равно распределены (но это, конечно, чисто теоретически). Вот, например, вот так:



Пример взят из известной онлайн игры. Где для персонажа предлагается в начале распределить начальные данные, на каждый из которых приходится по 5 пунктов.

У нашего специалиста, примерно также все. Только, когда он приходит в компанию, не все так ровно:

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

Итак. Есть вот такой специалист с таким набором компетенций или навыков. Количество пунктов ограничено человеческой природой (а именно, человеческого мозга, о чем даже есть исследования и подтверждения наукой, например работы Савельева С.В. или Бехтеревой Натальи). Конечно, можно пытаться найти среднее значение и развивать все по немногу.Что-то подтягивая, а что-то, увы, притормаживая.. В результате вы получите универсала, но который никогда не покажет высоких результатов ни в одной области e-learning - только средне-минимальное.

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


Надеюсь, теперь мысль понятна :). Универсалы нужны, но не абсолютные - вы их просто не найдете!

А вот, чтобы рассчитать СВОЕГО универсала предлагаю вам ПОИГРАТЬ, коллеги!! Да-да! Не все нам e-learningцам создавать игры для других :).

Предлагаю вам графический калькулятор:

И условия игры:)

Подготовка:
1. Напишите список компетенций вашего подразделения ДО. Важно - не совмещайте несколько компетенций в одну или несколько групп. Играйте честно :).

2. Нарисуйте на миллиметровке (или как у меня на тетрадном листке в клетку) человечка, который будет началом координат. Нарисуйте столько осей, сколько у вас получилось в списке.

3. Нарисуйте шкалу.

4. А теперь исходные данные:

У вас есть по 5 пунктов на каждую компетенцию (т.е., если их у вас 8, то 8 умножаем на 5, получаем 40)

Ежегодно добавляются 10 поинтов

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

5. Играем! Рисуем подобных человечков еще в количестве 10 штук и отмечаем пункты "ежегодно"..

Итак! вы сможете смоделировать сами, кто вам нужен и когда :).

Конечно, в жизни все не совсем так, не всегда человек развивается, или так ритмично развивается.. Но! Правда одна - все развить по максимуму нельзя!

Напишите, что у вас получилось!

И ответьте после этого на вопрос? Вам действительно хватит одного универсала под ваши задачи? или лучше все-таки команда?

PS Да, Программисты!!! если запрограммируете этот калькулятор, уверена, он многим придется по душе! Если возьметесь, то прошу только поделиться первой версией со мной ;).

Играйте, Господа! Играйте!))))

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

понедельник, 8 декабря 2014 г.

О проекте автоматизации HR-процессов. Этап 2. Реализация.

Первый этап по проектированию и описанию бизнес-процесса под автоматизацию завершен. Чтобы еще раз напомнить о пройденном, размещаю ссылки на все сообщения по порядку:

О проекте автоматизации HR-процессов. Как все было и есть. Part 1
О проекте автоматизации HR-процессов. Установка границ процесса или начало работы с заказчиком. Part 2
О проекте автоматизации HR-процессов. Кто главный в проекте автоматизации? Part 3
О проекте автоматизации HR-процессов. Почему важно увидеть процесс целиком и как это сделать. Part 4
О проекте автоматизации HR-процессов. Общая структура процесса - верхний уровень. Part 5.1
О проекте автоматизации HR-процессов. Написание бизнес-процесса под автоматизацию. Part 5.2
О проекте автоматизации HR-процессов: есть ли границы автоматизации ручной работы? Part 6
О проекте автоматизации HR-процессов. Выбор нотации описания бизнес-процесса. Part 7
О проекте автоматизации HR-процессов: описание бизнес-процесса на едином языке. Как найти общий язык? Part 8
О проекте автоматизации HR-процессов. Как проверить правильность моделируемого процесса? Part 9
О проекте автоматизации HR-процессов. Сквозные процессы. Разграничение обязанностей. Part 10.1
О проекте автоматизации HR-процессов. Сквозные процессы. Границы влияния и действия функций. Part 10.2
О проекте автоматизации HR-процессов. Сквозные процессы. Регламенты. Part 10.3
О проекте автоматизации HR-процессов. Сквозные процессы. Part 10.4
О проекте автоматизации HR-процессов. Целостность процесса. Part 10.5


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

На втором этапе необходимо было выполнить следующие работы:

  1. Полученные схемы бизнес-процесса, формализованного в нотации "Visio" или "Бизнес-студио", необходимо описать словами в виде бизнес-требований.
  2. Составить техническое задание на основе бизнес-требований.
  3. Разработать программное обеспечение (написать программу).
  4. Протестировать разработанное ПО, внести коррективы, возможно что-то изменить.
  5. Подготовить документацию для пользователей для обучения работе с созданным ПО.
  6. Сдать в эксплуатацию.
  7. Наладить поддержку ПО.
Об этом в следующих сообщениях будет описано подробно.

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

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

To be continued...

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

вторник, 2 декабря 2014 г.

Универсальный менеджер - всегда ли это оправдано? Поговорим о разделении труда в дистанционном обучении!

В сфере дистанционного обучения все чаще говорят о том, каким должен быть специалист по дистанционному обучению, что он должен знать, уметь, какие функции выполнять. Не секрет, что хочется "все и сразу" - чтобы и "на все руки (и голову) мастер".
Я же смотрю на этот вопрос несколько иначе. Более того, для любителей аналитики подкидываю практический кейс по оптимизации e-learning в организации. В конце поста расскажу о реальном опыте оптимизации, и что из этого вышло.
Почему, не стоит все же искать чудо-спецов за немалое вознаграждение, а лучше грамотно разграничить обязанности и нанять несколько просто хороших специалистов?
Есть несколько причин:
1. Универсал, как бы хорошо он не был, вынужден работать все-таки линейно.
Выполняя в один момент времени что-то одно: либо общается с заказчиком, выясняя потребности или собирает информацию для курса, либо занимается обработкой полученного материала, или разрабатывает дизайн, или вовсе занимается развитие учебного портала, а может, и программированием. В любом случае, универсал вынужден расставлять ежедневно приоритеты, жертвуя временем для той или иной задачи.
2. Универсал не может быть в силу физиологических особенностей достичь лучших результатов во всех областях e-learning. Давно известно, что гении - они гении в чем-то конкретном, а если развивать все сразу, то в лучшем случае получите средний результат, в худшем - не достигнет высот ни в одном направлении. В каждой из областей e-learning необходимо практиковаться постоянно, в противном случае, навыки, знания теряют скорость, качество и пр. Опять же это вопрос ограниченности во времени, и жизненных ресурсов самого "универсала".
3. Когда универсал работает один, теряется и качество конечного продукта. Да, конечно, когда проект ведет от и до один человек, то и рисков по взаимодействию нет. Но, есть и обратная сторона - когда человек ограничен по времени, то и при "постановке задачи на разработку самому себе", он выбирает более простые решения, чтобы быстрее и проще выполнить, а не придумывает креативные вещи, которые мог бы с легкостью сделать его коллега "по цеху", но "заточенный специально под такие задачи".
4. Универсалы всегда ценятся выше "узких" специалистов. Но они не могут собой заменить команду. Сумма специалистов не равна сумме производимых продуктов. Один универсал делает в разы меньше, чем если бы работал в команде с четким разделением функционала и выстроенной структурой взаимодействия.
Универсалы нужны, но не "звезды во всем", они должны иметь четкие сильные стороны и направленности (в зависимости от требований бизнеса и направления сферы действия), а все остальное - на уровне "знания" для взаимодействия с другими специалистами e-learning.
Ну, а теперь, кейс.
Предыстория:
Год назад в одной компании в нескольких подразделениях прошла волна "оптимизации". Директору по персоналу была поставлена задача сократить ФОТ на 10%. Кто "пойдет под нож" не имело значение. В отделе дистанционного обучения функционировала следующая система разработки электронных курсов - две функции - универсалы-методологи и верстальщики, работающие в тесной связке.
Методологи вели проекты полностью с нуля, начиная с работы с экспертами и авторами, сбора информации и обработки ее, до написания технического задания под верстку и дальнейшего контроля верстки, проведения апробации и сдачи в эксплуатацию.
При этом, надо понимать, что сами они не верстали (хотя знали как это делать, и даже имели в самом начале работы в компании личный обязательный опыт). Верстальщики же работали только с программным обеспечением, программированием и воплощали в жизнь задумки методологов, постоянно совершенствуясь и развиваясь, но в технических навыках.
Итак, данные за 2011-2013гг.:
Разработка электронных курсов (методически проработанных, и технически сложных, с различными симуляциями, тренажерами, и методическими сложными приемами) составляла в год 25 (+1\-1), что составляло 65-75 модулей (каждый модуль как небольшой курс на 15-20 минут изучения).
Каждый методолог в месяц (22 рабочих дня) выпускал 3-4 технических задания под разработку (по ТЗ на модуль).
Каждый верстальщик в месяц осуществлял верстку 3-4 модулей.
Всего в команде разработчиков работало три пары - методолог+верстальщик (периодически кто-то уходил в отпуск, но никогда одна функция полностью не отсутствовала).
Более того, осуществлялась процедура обновления имеющихся электронных курсов - 20-25 курсов (некоторые по несколько раз в году).
В январе 2014 года произошло сокращение отдела. Оставили только универсальных сотрудников, которые могли бы выполнять полностью процесс разработки курсов самостоятельно. То есть - 3 методолога.
Данные за 2014год:
Разработка электронных курсов - 8 курсов, в сумме составляющие всего 13 модулей (т.е. большинство это небольшие курсики по 1-му модулю).
Из запланированных на обновление электронных курсов образовался дефицит в виде 8 курсов, обновление которых перенеслось на следующий год, где уже есть запланированные 25 курсов. Таким образом, становится ясным, что в 2015 году дефицит только увеличиться и база еще больше устареет.
Вывод:
Как видите, сокращение отдела в 2 раза ведет к сокращению производительности более, чем в 2 раза. Связано это с выше перечисленными причинами. На деле, универсал тратит примерно 1 рабочий месяц на полный цикл разработки 1-го модуля, даже не курса! Разработка же курса в 3 стандартных модуля по 20-25 слайдов с не самым сложным техническим воплощением, растягивается на 3-4 месяца, с учетом сбора информации и дальнейшей апробации и внесения корректировок. И не нужно забывать, что 1 месяц каждый из них тратит на отпуск и фактически работает только 11 месяцев в году (и это еще без учета государственных праздников).
А теперь вопрос. Вы действительно верите в миф о оптимальном результате только при использовании труда универсалов?
Конечно, в разграничении функций и обязанностей нужно руководствоваться здравым смыслом и целями, стоящими перед подразделением, а не впадать в крайность и делить на мелкие-мелкие работы и задачки, выделяя под каждую отдельного человека.
Всегда ваша
Денисова Елена,

понедельник, 1 декабря 2014 г.

О проекте автоматизации HR-процессов. Целостность процесса. Part 10.5

Когда я училась в университете, курсе на 4-м наш преподаватель Вячеслав Федорович Яковлев говорил о системах. О том, чтобы исследовать полностью любую систему, необходимо изучить ее как внутри, так и снаружи. И тогда, и только тогда в ней не остается загадок, и все становится ясным и понятным. Вот, почему человек наверное никогда не сможет разгадать все тайны жизни.
Какое отношение это имеет к автоматизации бизнес-процессов? Самое прямое! Дело в том, что заказчик автоматизации чаще всего находится внутри системы и не в состоянии выйти из нее и оценить всю целиком посторонним взглядом. Отсюда и ограниченность взглядов и ошибочность целей и приоритетов. Ошибки описания процессов рождаются именно из-за непонимания природы всей системы. Мы говорим, что "варимся в собственном котле", и не видим перспективы в этом случае. И это, действительно, серьезная проблема, для решения которой нередко приглашают сторонних специалистов, способных "новым" взглядом взглянуть на ситуацию и найти выход.
В идеале, конечно, руководство Организации должно хорошо знать собственные процессы и системы. Но это завидная редкость. В небольшой компании все "видно как на ладони", и часто процессы на этой стадии не считается целесообразным описывать. А в крупных организациях, руководство уже не знает всех деталей существующих функций за счет декомпозиции задач. Ведь не может (и не должен) знать абсолютно все Президент Компании и в производственном отделе, и в финансовом, и в маркетинге, например.
Получается, процессы и внутри часто запутаны и интуитивны. Что же говорить о всей картине?
В случае автоматизации сузим задачу. Нам необходимо знать целиком конкретно выбранный процесс, имеющий четкие границы (о чем говорилось ранее).
Важно, чтобы эта информация была доступна к комплексному изучению, т.е. целиком как "внутри, так и снаружи", имела входы и выходы, описаны все ресурсы и ограничения. Процесс должен иметь законченный  и достаточный вид. И владеть данной информацией в полном объеме должен "хозяин" процесса. Это необходимо для дальнейших манипуляций и работы с процессом по его развитию, оптимизации (в т. ч. автоматизации).
Что касается нашего HR-процесса, то он должен быть целостным относительно выбранного критерия, например, цикла жизни сотрудника в компании. Конечно, этот процесс в свою очередь является только "небольшим кусочком" общей бизнес-системы организации и должен иметь свое место в ней. Но мы не имея возможности охватить "необъятное" вынуждены дробить большое на малое и использовать метод индукции для изучения общего от частного.
Возможно, когда основные функции компании будут определены и описаны с помощью процессного подхода, общая система определится и ее уже можно будет исследовать системно всю целиком, заполняя и выявляя имеющиеся пробелы, как путешественники и мореплаватели в эпоху Великих открытий.

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

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

To be continued...

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