Websoft

среда, марта 18, 2015

4 основные IT ошибки HR при внедрении Системы Дистанционного обучения (СДО)

В процессе подготовки к конференции в Томске, прошедшей на прошлой неделе, я написал материал про ошибки взаимодействия с ИТ-подразделениями, которые зачастую совершают HRы в процессе внедрения автоматизированных HR систем или СДО. Публикую его здесь.

Нужно ли привлекать ИТ-специалистов при внедрении корпоративной системы дистанционного обучения (СДО)

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

Как же поступить?

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

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

Пример из жизни:

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

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

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

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

Например, HR запланировал запуск курса и поставил в план (и отрапортовал бизнесу) дату запуска обучения. Для запуска красивого мультимедийного курса нужно "всего то" обновить браузер и в плане на это может быть отведена неделя. Но, как только об этом узнает ИТ, то выясняется, что обновление версии может привести к проблемам с совместимостью с другими корпоративными приложениями, потребует обновления другого системного ПО (взаимосвязанного) на что уйдут недели работы и т.п. А ведь этих проблем легко можно было бы избежать.

Выводы

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

2 комментария:

Виктор Мордвинов комментирует...

Алексей, в подтверждение Ваших слов. Когда мы начинали проект в 2003 году еще на старой доброй лотусовой платформе, нам был выделен один IT-специалист. И пока СДО использовалось в виде автономного приложения, этого ресурса хватало. Но когда началась интеграция СДО с другими корпоративными информационными системами, когда нагрузка на СДО возросла в разы, одного айтишника уже не хватало. Сейчас это уже проектная команда от IT-управления и число задействованных (в том или ином качестве) специалистов не менее 6 человек.
Хочу высказать свою мысль по координатору. Безусловно, в айтишной проектной команде такой координатор нужен. Но также необходим общий координатор от Учебного центра, а еще точнее от подразделения СДО. Такой специалист должен четко понимать функциональные возможности СДО, уметь лично администрировать СДО стандартными средствами WT, иметь общее представление об IT-процессах модернизации платформы WT. Фактически он главное связующее звено между заказчиком (Учебный центр), айтишными специалистами своей компании и командой разработчика (проектный менеджер, служба технической поддержки). В этом случае заказ и функциональное сопровождение работ по модернизации СДО будет идти на одном языке и под единым координирующим началом. У нас такой координатор есть. С таким координатором мы даже Китай поставили на прочные рельсы электронного обучения ))

Виктор Мордвинов комментирует...

По поводу планирования требуемых IT-ресурсов. Мы вроде бы просчитали такие возможности, но вследствие полного перевода очного обучения на дистанционный формат произошел многократный рост нагрузки на СДО, и сейчас SQL-база фактически «трещит по швам». С нетерпением жду результатов нагрузочного эксперимента на тестовом стенде, который проведут в ближайшее время наши айтишники и Ваши специалисты. По идее всё это нужно было делать гораздо раньше, но как говорится "лучше поздно, чем никогда" ))