понедельник, 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...

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

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

Настраиваемое обучение. Адаптивное обучение. Или - Крылья, ноги... главное - хвост! (с).

Сейчас только и разговоров - о геймификации и адаптивном обучении. Где-то они даже пересекаются. А я тем временем сталкиваюсь с новыми и неожиданными откровениями на практике.
О чем это я? В знаете, что инерциальных систем нет? Т.е. замкнутых и статичных? Ну, то, что все движется, вы, конечно, знаете (кто там сказал из древних про вхождение в одну реку?). А то, что нет замкнутостей в природе и в жизни, периодически забывается.
Вот, и я искренне считала ранее, что можно ограничить круг действия электронного курса границами самого курса. Т.е. если курс сделан методически грамотно и изящно, то можно расслабиться (конечно, предварительно, "доведя обучаемого до обучения и он тут же станет обучающимся!). Ведь, и техники заложены верные, и мотивация продумана.
Три раза "ха!". Оказывается, какой-бы вы путь не избрали - игровой ли, адаптивный ли... Но результат курса (его качество) зависит далеко не только от вас, и самого обучаемого! Все зависит от того, кто и как этот курс запускает и использует в обучении!
Например, я столкнулась с тем, что курсы, проработанные и хорошо работающие вне системы обучения, включенные в общую программу обучения (очное + дистанционное) оказались неэффективными, и даже вредными. Причина - неверно отведенные сроки обучения и пропорции объемов обучения, полное игнорирование методических рекомендаций разработчиков. В итоге - очное обучение "хорошее", так как веселое и не слишком напряженное (конечно, тренеры попляшут, расскажут, развлекут, не беда, что знаний в остатке сухом немного - главное, голова не болит и чем-то занят законным вместо работы), а дистанционное  -просто "ужасное" (конечно, если на обучение 5-ти полноценных разноплановых курсов со сложными тематиками выделили добрые "очники" аж 8 часов рабочего непрерывного времени (ну, разве, на обед можно сбегать) - не, ну а что?! "мы пробовали, листали - можно изучить 100 интерактивных экранов за 8 часов, а что тут такого?". И ведь, составителей учебных программ даже не вспомнят, это дистанционное же обучение неудобное, некомфортное и неэффективное... А e-learning-цам самим жить с подпорченной (не ими) репутацией.
Вот, и получается, что просто создать продукт для заказчика мало - нужно участвовать и в процессе применения продуктов ДО и контролировать правильность использования методики.
Более того, не все типы электронных курсов хороши везде и со всеми. Я могу выделить 3 типа методов использования курсов:
1. Обязательное (директивное) обучение. Можете возражать, что это прошлый век, что нельзя людей заставлять учиться. В некоторых случаях - это единственно верное решение, например вводное обучение в организациях, где дают знания об особенностях организации новым сотрудникам. Даже если они профи и гуру с многолетним опытом, внутренность нового места работы им неизвестна. Знать ее обязательно!
2. Альтернативное и выборочное. Данное обучение нацелено на пробелы в знаниях, основывается на оценках директивных. Т.е. Если уровень знаний у человека неизвестен, но однозначно известно, что что-то он точно знает. Поэтому давать нужно только те знания, которых не хватает. Но опять же они точно нужны для работы.
3. Добровольное. Здесь мотивация обучения лежит целиком и полностью на обучаемом - что ему нужно, то он и берет, в зависимости от личного желания или необходимости в знаниях при выполнении той или иной задачи. В любом случае, работают внешние мотиваторы, а человек самостоятельно решает, как и когда учиться.
И для всех трех типов создать один уникальный тип курсов нереально. Это зависит от имеющейся среды "обитания" обучаемого. От того, как использовать сами курсы, зависит будет ли работать заложенная методика или механика, или нет. Можно создать курс настраиваемый, но ограничить по времени, и вот, он уже теряет свое назначение и смысл, и уже не является адаптивным. Человек думает не о том, чтобы найти что-то полезное для себя, а отказаться от обучения, как бесполезной трате времени, так как за отведенное время все равно толком поучиться не получится.
Все упирается в цель использования и грамотности внедрения курсов в обучение. Они не живут сами по себе, к счастью, или к сожалению. Они встраиваются в определенную среду. Поэтому, кроме того, как задумываться о внутреннем содержании курсов (контенте или методе подачи), и даже целевой аудитории, но о том, кто будет пользоваться и как. Все-таки главный заказчик - конечный пользователь. Наша задача, чтобы они достигали своих личных целей. Если не хотите получать на выходе гневные отзывы (не по вашу душу, но по вам), следите за продолжением вашей работы на сколько это возможно. Наверное, поэтому в инструкциях и прописывают о корректном применении продуктов, дабы избежать критики из-за ошибок самих пользователей (в нашем случае, заказчиков, обучающих своих подопечных вашими руками).
Жду ваших комментариев!

суббота, 1 ноября 2014 г.

О проекте автоматизации HR-процессов. Сквозные процессы. Part 10.4

Прежде чем, ответить на вопрос, является ли процесс сквозным или нет, я еще раз изучила имеющиеся материалы в разных источниках. Существует несколько определений сквозных процессов. Во всех определениях сходятся на одном основном критерии - процесс должен пересекать границы нескольких структурных подразделений. Однако, это обязательный, но недостаточный показатель.
Я привожу здесь другие критерии, взятые из книги Владимира Репина "Бизнес-процессы. Моделирование, внедрение, управление", 2013г, М., "Манн, Иванов и Фербер":
Процесс можно считать сквозным, если:
-участники процесса являются сотрудниками различных структурных подразделений;
-деятельность в рамках процесса рассматривается на уровне отделов или сотрудников (операционный уровень);
-существует возможность организации контроля оперативной деятельности по процессу и полученных результатов одним руководителем;
-результат процесса важен с точки зрения достижения целей организации в целом (или существенной ее части) либо удовлетворения потребностей внешнего потребителя;
- существует возможность значительного улучшения деятельности (усиления эффектов синергии) за счет оптимизации межфункционального взаимодействия в рамках процесса.
Безусловно, сквозные процессы определяются на уровне операций конкретными сотрудниками. Данные критерии указывают на обязательность таких характеристик сквозного процесса, как целостность и завершенность, а также полезность и направленность результата процесса в рамках организации как для внутреннего клиента, так и внешнего.
Целостность процесса обеспечивает стабильный контроль процесса за счет наличия ответственного за процесс в целом (руководителя), не смотря на свою межфункциональность. И это правильно. Если ответственных много - как минимум по одному на каждый участок, то в случае сбоя найти источник неисправности практически невозможно - каждый будет стараться возложить ответственность "на соседа". Что мы на практике нередко и наблюдаем.

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

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

To be continued...

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

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

О проекте автоматизации HR-процессов. Сквозные процессы. Регламенты. Part 10.3

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

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

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

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

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

To be continued...

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

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

Всероссийская научно-практическая конференция «Завещание И.И. Бецкого" - г. Санкт-Петербург, 4 октября 2014. Подробный отчет: заметки, впечатления и выводы.

4 октября 2014 посетила "Всероссийскую научно-практическую конференцию "Завещание И.И. Бецкого" в г. Санкт-Петербург. Сегодня расскажу подробно - с чего началось, и что в итоге произошло.

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

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

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

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

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

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

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

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

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

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

Более того, регистрация, оказывается, началась в 10.00 вместо 10.30, а далее по программе шла экскурсия. А сама программа была только у организаторов - вот это сюрприз. Но об этом я узнала позже. Для начала оказалось, что в списках пропусков мое имя не значилось, не смотря на то, что на частных основаниях я все оплатила и предоставила заранее - за 3 недели. Пропуск мне оформили на месте, даже не объяснив этого - просто пригласив в какую то коморку, сфотографировав молча, молча же выдав карточку и указав на дверь...

Я догадалась вернуться к вертушке, где О! Чудо! меня пропустили в святое святых. Далее я прошла в гардероб, где, как я была уверена, у меня есть 10 минут запаса для регистрации, меня ждали две недовольных "тетушки", которые спросили меня, не на экскурсию ли я пришла, на что я совершено откровенно и честно ответила, что нет, я на конференцию... "Тетушки" недовольно на меня поглядывая, шептались, что им что же придется ждать меня?! (да кто же знал то, что я заставляю кого-то ждать).

Экскурсия, надо сказать, была любопытной - не каждый день ты оказываешься в Президентской библиотеке. Но если бы о ней знать заранее, я наверное, не опоздала бы.

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

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

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

Два часа ушло на доклады 4-х человек. Хотя регламент заявлен был строго - по 10 минут на каждого. Я слушала очень внимательно, и старалась не уснуть. Соседка моя даже успела вздремнуть и немного всхрапнуть, благо кресла там очень комфортны и удобны, а также еще несколько человек в зале. В какой-то момент в разгар чьего-то выступления ко мне подошла организатор и шепотом поинтересовалась, действительно ли я такая-то и такая. Получив утвердительный ответ, мне задали самый удивительный вопрос: "буду ли я выступать" - это при том, что я заплатила за доклад и прислала все необходимые документы. На мой утвердительный ответ, я получила еще более удивительный комментарий: "А я думала, вы не приедете!". Уже тогда надо было мне понять, что "песенка моя спета".

Тем не менее, я выслушала все доклады и дождалась своего выхода. И тут еще один сюрприз - оказывается, что для "своих" 10 минут - это минут 30-35, для меня же - 10 минут - это менее 7-ми. Ну да ладно, я смогла бы уложиться. Пока я представлялась, выводилась на экран моя презентация - заранее собрать их организаторам было недосуг. Каково же было мое удивление, когда предыдущих участников презентации загружались без проблем, моя же зависла и показывалась только краешком слева.

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

Честно говоря, мне не очень комфортно беседовать с аудиторией, не видя ее. Тем не менее я рассказала, представив, что веду вебинар. Единственное отличие - это ощущение окружающего настроения. В какой-то момент, ближе к середине доклада, я почувствовала взгляд, недобрый взгляд - подняла глаза и увидела злые-презлые глаза организатора, которые, буквально кричали и приказывали остановиться! Кивком же мне показали, что пора закругляться. быстро протараторив, мне удалось дойти до последнего слайда, но прокомментировать его мне уже не дали. Грубо прервав и задав "самый главный вопрос конференции": "А какое отношение имеет ваш доклад к И.И. Бецкому" - я почему-то вспомнила про свою защиту диплома, когда всех студентов спрашивали: "А где тут САПР?! И какое отношение имеет к строительству?" и от этих ответов зависила судьба оценки дипломной работы. Хотелось сказать, что я давно не студентка, дяденьки и тетеньки, я могу паспорт показать... Но мне дали понять, что мне пора идти "гулять". Нет, конечно, мне предложили продолжить доклад в другом месте - в "Герценке" (где это, я конечно, не знаю, так как я из Москвы и знать все ВУЗы С.-Петербурга, в принципе не могу), но таким тоном, что мне стало ясно, что точно меня там уже не ждут...

Но! Зато аудиторию я точно разбудила. Даже не дорассказав доклад, преподаватели наперебой просили мою визитку. Ну, и на этом спасибо! Результат есть.

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

Вы думаете, передо мной извинились? Нет, конечно). Рассеяно кивнули и дальше занялись своими делами. О сертификате участника я даже не заикнулась - зачем? И я не удивлюсь, если обещанный сборник статей участников мне забудут прислать...

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

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

воскресенье, 28 сентября 2014 г.

Делюсь впечатлениями о прошедшей конференции ICDE.

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

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

Более подробно о конференции (ее истории, философии и предназначении) вы сможете прочитать на официальном сайте ICDE- 2014: http://www.mesi.ru/icde2014/

Сюда я хотела попасть уже с начала этого года. Когда еще она будет проводится в России, в Москве, буквально под боком?!

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

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

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

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

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

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

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

А теперь об наблюдениях. Русских на конференции было немного. Не знаю, хорошо это или плохо. Но! Это действительно, международная конференция, где приняли участие преподаватели и специалисты в открытом и дистанционном образовании из разных стран: США, ЮАР, Испания, Италия, Китай, Корея, Индия, Малайзия, Россия, Украина, Канада, Великобритания, Германия, Франция и другие (боюсь, всех не упомню). Из России были представители разных городов.

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

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

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

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

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

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

Это то, что касается полученного опыта.

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

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

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

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

воскресенье, 21 сентября 2014 г.

О проекте автоматизации HR-процессов. Сквозные процессы. Границы влияния и действия функций. Part 10.2

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

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

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

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

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

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

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

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

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

To be continued...

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

среда, 17 сентября 2014 г.

О проекте автоматизации HR-процессов. Сквозные процессы. Разграничение обязанностей. Part 10.1

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

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

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

Поэтому, здесь есть несколько сложностей:

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

Рассмотрим каждый пункт отдельно.

Четкое разграничение обязанностей

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

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

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

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

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

Во всем должен быть порядок. Иначе получится, как в известной сказке Корнея Чуковского "Путаница", где все звери поменялись своими природными обязанностями.

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

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

To be continued...

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


четверг, 31 июля 2014 г.

О проекте автоматизации HR-процессов. Как проверить правильность моделируемого процесса? Part 9

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

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

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

Какие же маяки помогают не сбиться с пути?

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

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

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

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

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

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

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

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

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

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

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

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

To be continued...

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

пятница, 11 июля 2014 г.

О проекте автоматизации HR-процессов: описание бизнес-процесса на едином языке. Как найти общий язык? Part 8

Как часто бывает, что заказчик не может четко сформулировать запрос программистам на разработку? Довольно часто, если не почти всегда. Тем не менее они являются единственными клиентами разработчиков - иначе для кого они работают?

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

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

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

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

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

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

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

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

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

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

To be continued...


Всегда ваша
Денисова Елена,
https://www.facebook.com/profile.php?id=100004487832154
@EDDenisova

суббота, 28 июня 2014 г.

О проекте автоматизации HR-процессов. Выбор нотации описания бизнес-процесса. Part 7

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

Во время обучения в ВУЗе (Московском Государственном Строительном Университете, специальность "САПР в строительстве" ) я научилась алгоритмизации - навыку построения алгоритмов для написания программ. Этот навык обязателен в любом программировании. Поэтому, когда я непосредственно столкнулась с задачей моделирования, а потом и описания, бизнес-процесса, то использовала прежде всего схемы алгоритмов. Особых затруднений у меня не вызвала эта операция.

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

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

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

1. обучать корректно персонал - единой системе, без искажений пересказа или личного восприятия "Не знаю, как это делают другие, я делаю так! и тебе покажу как...";
2. оптимизировать процесс - описание позволяет увидеть полную картину деятельности и проанализировать, можно ли улучшить и где;
3. автоматизировать процесс - та же оптимизация, но с использованием машинных ресурсов;
4. планировать деятельность организации - на основе схемы бизнес-процесса становится понятным, какие и когда ресурсы используются и в каком количестве;
5. развивать процессы - когда видна полная картина, то и становится понятным, куда двигаться дальше;
6. управлять процессами - расставлять приоритеты, изменять или передвигать ресурсы, планировать, получать отчетность;
и т.д.

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

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

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

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

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

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

To be continued...


Всегда ваша
Денисова Елена,
https://www.facebook.com/profile.php?id=100004487832154
@EDDenisova