|
|
|||
|
Инсайд - аутсайд? Или зачем «внутренним»
разработчикам e-learning нужны «внешние» разработчики |
|||
|
|
|||
|
Последнее время на нескольких
ресурсах e-learning’вого сообщества одновременно идет обсуждение
преимуществ и недостатков привлечения в компанию внешних разработчиков
электронных курсов. Не вступая в развернувшуюся бурную дискуссию, в данной
небольшой заметке мы хотим представить наше мнение по этому вопросу – в чем,
на наш взгляд, состоят преимущества и недостатки привлечения в компанию
сторонних разработчиков. |
|||
|
Преимущество
«внутренних» разработчиков |
|||
|
Мы не понаслышке, а
из своего непосредственно опыта знаем, что профессиональные разработчики
курсов могут закрывать, и закрывают многие вопросы, связанные с обучением
внутри компании. Естественно мы говорим о тех случаях, когда они,
разрабатывая курсы, исходят из
того, что главная цель корпоративного
обучения – это, прежде всего, решение проблем, связанных с недостающими
знаниями и компетенциями, а не просто «переложение» учебников или нормативных
документов в слайды или электронные книги с гиперссылками, и с некоторым иллюстрированием текста
картинками. При этом решение проблем и достижение целей обучения
является безусловно доказательным, то
есть измеримым – «до» и «после». При
этом измеряется и оценивается и сам подготовленный электронный контент: 1.
как с точки зрения простоты и доступности для понимания
передаваемых знаний, 2.
так и с точки зрения наглядности представленных
примеров, дающих возможность понять, почему необходимо на практике применять
передаваемые знания и как именно это сделать. Самое важное
преимущество внутренних разработчиков заключается в том, что: никогда ни один
консультант не сможет узнать компанию, и идущие в ней процессы и
взаимоотношения, так же хорошо, как работающий в ней специалист. Или это
потребует у внешнего консультанта и разработчика слишком много времени и сил,
которые всегда можно потратить, куда с большей пользой. А иногда «отрыв»
внешних разработчиков от существующей в компании ситуации и вовсе приводит к
досадным казусам. В иллюстрацию этого положения можно привести массу
известных анекдотов о консультантах, но я воспользуюсь примером из
собственной практики. Это не является нарушением коммерческой или какой-либо
другой тайны компании, поэтому я спокойно рассказываю этот случай. Информация
незакрытая. |
|||
|
Что случается при
отсутствии доступа к инсайдерской информации |
|||
|
Сейчас уже к
пятилетию подходит срок нашего сотрудничества с одной известной компанией, но
было время, когда мы только-только начинали проводить на этом предприятии
учебные программы. Предприятие выпускает арамидные нити – полимерные
материалы, то есть материалы, формируемые из жидких химикатов, которые в
готовом виде по своим физико-химическим характеристикам превосходят стальную
проволоку. Японцы сейчас такими нитями
армируют бетонные каркасы своих мостов. Технология, пожалуй, у нас в стране
только на этом предприятии и сохранилась.
Другие аналогичные организации, которые умудрились выжить на
постсоветском пространстве, быстренько
купила компания DuPont и тут же позакрывала, чтобы не иметь конкурентов. Кроме
исключительной прочности эти арамидные нити имеют еще одно качество – очень
высокую огнеупорность. Поэтому из них «ткут» специальные ткани и используют
эту ткань при производстве бронежилетов и одежды для пожарных. Так вот.
Проводим мы как-то стратегическую сессию на этом предприятии и, как
полагается, дошло дело до миссии. Предлагаются разные варианты, готов и наш
вариант: «Мы даем людям шанс выжить!» (при этом подразумеваем, естественно,
что одежда, сделанная из арамидных нитей, защищает военных, пожарных,
милиционеров и т.д.). Нам кажется, что мы придумали классный вариант – яркий,
емкий, подчеркивающий ценность
человеческой жизни. Только в аудитории после нашего предложения
повисла напряженная тишина. Через некоторое время как-то постепенно от этого
варианта перешли к другим и про наш вариант забыли. В общем, в окончательный
вариант миссии наше предложение не попало. Неловкость момента
объяснилась существенно позже. После активной работы по нескольким
консалтинговым проектам и взаимного узнавания друг друга, руководство
компании предложило мне стать независимым членом Наблюдательного Совета
предприятия и возглавить в нем Комитет по аудиту. Несмотря на то, что эти
функции мне пришлось бы исполнять исключительно «на общественных началах», я
с радостью приняла предложение, и вот уже три года как являюсь независимым
директором на этом предприятии. И вот как-то вскоре после моего утверждения
«в должности» на одном из заседаний, выясняется, что бронежилеты – это лишь
один из возможных способов использования арамидных тканей. Но гораздо в
большем объеме арамидные ткани применяются для защиты ракетных боеголовок –
чтобы они не перегревались, когда ракета летит к цели. В этот момент я и поняла насколько глупым и
неуместным был наш вариант миссии. «Мы даем людям шанс выжить!» звучало,
мягко говоря, совсем «не в тему» - безопасность страны диктует свои
требования. |
|||
|
Так зачем же
«внутренним» разработчикам – «внешние»? |
|||
|
Вот такой пример
недостатка инсайдерской информации. Поэтому повторюсь: при прочих равных, внутренние специалисты
для компании всегда лучше (подразумевая, что профессионализм и у внешнего, и
у внутреннего разработчика – на одном уровне). Но все-таки в работе
внутренних разработчиков, как правило, существует три существенных ограничения:
1.
часто встречаемое у высшего руководства компании
представление, что «нет пророка в своем отечестве», 2.
у них в руках, как правило, отсутствуют рычаги «давления» на другие
подразделения и службы, 3.
у них ограничены возможности для визуализации. Как раз «закрытии»
этих вопросов и заключается выгода привлечения «внешних» разработчиков. В чем
«внешние» разработчики могут поддержать «внутренних» специалистов ДО? 1.
«Эксперт – это
всегда человек со стороны». Не поспоришь с тем фактом, что специалист
ДО получает зарплату от своего руководства и принцип «1. босс всегда прав, 2.
если босс не прав, см.п.1» еще никто не отменял. А «извне» легче задавать
«неудобные» вопросы менеджменту компании про декомпозицию стратегических
целей, профили компетенций, не прописанные бизнес-процессы, неформализованные
цели обучения и т.д. Кроме того, нельзя забывать, что независимые
разработчики, работающие с различными заказчиками, имеют «незамыленный»
взгляд на все, что происходит в компании и то, как аналогичные проблемы решаются
в других отраслях. 2.
Не все проблемы в
компании решаются обучением. Можно «заучить» всех и вся, а проблема
решена не будет, потому что ее истоки – это НЕ нехватка каких-то знаний или
компетенций. Чаще всего «рвет» в местах межфункциональных контактов. Но чтобы
«латать» возникающие разрывы в коммуникациях, надо говорить с каждым
специалистом на его специализированном «птичьем» языке. А специалист ДО не может и должен быть «полиглотом» –
это не входит в его обязанности. Вот как раз помочь специалисту по ДО
разобраться с тем где «рвет» и определить, решается ли проблема
соответствующим обучением или нет, а
при необходимости помочь «заштопать» места конфликтов, и может опять-таки
внешний разработчик. 3.
И, наконец,
визуализация.
В большинстве случаев, внешний разработчик
визуализирует все-таки лучше, так как имеет возможность привлечь
профессиональных дизайнеров, операторов, аниматоров, актеров для озвучивания
и т.д. Поэтому привлечение внешних разработчиков может помочь сделать учебные
программы интересными и запоминающимися. |
|||
|
«Используй
чужую силу в свою пользу» |
|||
|
Кроме того, нельзя
все-таки стопроцентно исключать и возможный непрофессионализм сотрудника,
который может очень хорошо знать, как программировать и администрировать ДО,
но совсем не понимать того, как работает бизнес. Привлекая в этом случае
внешних разработчиков, руководству не
придется несколько месяцев тратить время и деньги компании на зарплату
сотруднику, который занят:
Самый простой и
эффективный тест для оценки профессионализма «внутреннего» разработчика
заключается в рассмотрении подготовленного им тех.задания. Если специалист ясно
представляет, что он хочет получить «на выходе» от внешнего разработчика, он
четко и недвусмысленно это ему формулирует. Во всех остальных случаях
начинается просто «детский лепет»: «Этих посмотрели – нет, не то; этих
посмотрели – нет, не то». А все тех.задание сводится к «иди туда – не знаю
куда, принеси то – не знаю что». К сожалению, практически полное отсутствие
четких тендерных требований на разработку учебных программ, как раз и
демонстрирует наглядно факт того, насколько слабы «в постановке правильных
вопросов» «внутренние» специалисты некоторых компаний. Тем не менее, имея
в своем портфеле успешный опыт работы с «внутренними специалистами» различных
компаний, и опираясь на него в своей сегодняшней деятельности, мы понимаем,
что внешних консультантов и разработчиков боятся только откровенно слабые
внутренние специалисты. Это сотрудники, которые опасаются, что
непосредственное общение руководителя компании или подразделения с этими
людьми может выявить их собственную некомпетентность. Уверенные же в себе профессионалы,
наоборот, используют внешних разработчиков как рычаг для усиления своей
позиции в компании, продвижения и решения тех вопросов, которые они, в силу
своего нахождения «внутри» компании решить не могут. Привлеченные по
инициативе внутреннего специалиста компетентные «внешние» помощники очевидно
и существенно поднимают в глазах руководства и мнение о профессионализме
собственного сотрудника, и о ценности того, что он делает для компании. В итоге выигрывают все – и
компания, и ее руководство, и внутренние специалисты, и внешние разработчики. |
|||
|
Что
дороже? |
|||
|
Часто можно
встретить и замечания, что «внешние» разработчики стоят «безумных» денег и
обходятся компании существенно дороже «внутренних. Однако на наш взгляд в этом
случае речь идет или о том, что: 1.
неправильно считаются затраты на «внутренних»
специалистов (не считаются, например, текущие накладные расходы, расходы на
командировки на всевозможные семинары и тренинги, на которых учатся
«внутренние» специалисты, амортизация используемого оборудования и ПО,
интернет-трафик, альтернативные доходы, которые могли бы приносить «носители
контента» - сотрудники функциональных подразделений, пока они заняты
разработкой курса и т.д.), или 2.
сравниваются между собой «не приведенные к одному
основанию» проекты, которые «не уравняв», сравнивать между собой некорректно.
Нас, например,
размер команды, которая считается «нормой» для СДО в компании – 12-15 человек
- пугает значительно больше. Даже для компании, которая имеет 1000
сотрудников (а таких все-таки не так уж и много) – это больше 1% людей,
которые не заняты непосредственно в «печении корпоративного пирога», а
занимаются исключительно его «проеданием»! При этом самые активные из них, как
правило, не прочь еще и как-нибудь подзаработать «на стороне» в оплачиваемое
компанией время! Нет, все «пугалки»
о дороговизне «внешних» разработчиков опять-таки говорят только об уровне
подготовки таких горе-«экспертов» и никакой другой информации к размышлению
не содержат. Совет таким «экспертам» один: если хотите работать с бизнесом (в
бизнесе) - учите управленческий
учет! Но это уже совсем
другая тема. |
|||
|
Автор: Ирина Деточка |
|||
|
|
|
|
|
|
|
Тел. +7-928-187-77-55,
8-863 -256-58-07 | E-mail: pochta@premiumconsult.ru
| Web: http://www.premiumconsult.ru |
||
|
|
©«Премиум
Консалтинг» (ООО), 2009. Все права защищены. |
||
