Показаны сообщения с ярлыком внедрение изменений. Показать все сообщения
Показаны сообщения с ярлыком внедрение изменений. Показать все сообщения

понедельник, 5 июня 2017 г.

#ТехнологииОбучения #МетодологияВнедрения Ошибки - двигатель прогресса?

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

Поиски виноватого не решают вопрос исправления ошибок - это всего лишь фиксация прошлого без отработки полученного опыта.

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

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

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

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

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

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

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

С уважением,
Денисова Елена... об ошибках и опыте ;)

вторник, 30 мая 2017 г.

#МетодологияВнедрения Готова ли организация к изменениям? Основные преграды и трудности на пути к развитию.

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

1. Жесткая иерархическая структура с бюрократической системой
2. Отсутствие коммуникаций внутри организации
3. Отсутствие культуры сотрудничества
4. Непрозрачность процессов и конкуренция подразделений
5. Застой и ложное ощущение комфорта: "мы так привыкли"

Я могу продолжать список. 

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

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

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

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

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

В размышлениях,
Денисова Елена

воскресенье, 5 марта 2017 г.

#МетодологияВнедерния Об изменениях в устоявшейся системе организации

Можно ли внедрять изменения внутри организации?

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

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

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

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

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

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

воскресенье, 29 января 2017 г.

#МетодологияВнедрения И снова здравствуйте! Одно и тоже предложение разным людям в разных сферах? Легко!

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

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

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

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

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

Кто-то говорит на языке прибыли, кто-то - безопасности, кто-то соблюдении правил, кто-то на любви к людям, детям, животным и т.д. У каждого своя мотивация!

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

Почему HR так сложно порой продвигать свои проекты?

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

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

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

С уважением,
Денисова Елена

воскресенье, 20 ноября 2016 г.

#МетодологияВнедрения Конфликты интересов как внутренняя балансировка распределенной команды по городам и часовым поясам

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

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

Может, стоит поднажать и пригрозить? Мол, если не подружитесь, все останетесь без премии! Как считаете?

Расскажу о собственном личном, а поэтому субъективном опыте.

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

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

Я тогда ответила вопросом: "А может этот человек просто оказался на своем месте?" - не особо поверил, все равно твердил, что я к тому же требовательный руководитель.

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

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

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

Что было сделано?

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

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

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

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

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

Если грамотно управлять конфликтами, то можно эффективно настроить организацию процесса. И в распределенных командах, как мне показалось, это сделать даже проще...

А как думаете вы?

С уважением,
Денисова Елена

среда, 16 ноября 2016 г.

#ТехнологииОбучения "ДНК- обучение" внедрения - здесь и сейчас

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

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

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

Я считаю, что внедрять и обучать нужно одновременно. Вернее любое внедрение проводить через обучение! Что это означает? 

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

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

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

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

Почему это требуется выполнять сразу, не откладывая на "после внедрения"?

Чтобы тут же получить обратную связь! Увидеть затруднения, снять возражения, увидеть связку с существующими процессами. 

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

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

Таким образом отработать весь процесс обучающего внедрения.

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

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

А как считаете вы?

С уважением,
Денисова Елена

вторник, 15 ноября 2016 г.

#МетодологияВнедрения. С чего начинать любое внедрение?

Скорее всего я не скажу ничего нового. Инструменты и методики давно известны. Чаще всего мы применяем их под разными названиями и обозначе6ниями в всевозможных комбинациях и сочетаниях.

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

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

Для сравнения и понимания, что я имею в виду, приведу следующую метафору-сравнение: вывод летательного аппарата на орбиту. Есть сам продукт, который выводят в космос - летательный аппарат, и есть ракетоноситель, который и вывод его на орбиту. 

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

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

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

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

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

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

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

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

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

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

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

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

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

7. Само внедрение - здесь описывать не буду, классическое обучение использованию продукта

8. Заложить контроль с механизмом обратной связи

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

Интересно, кто-то так делает на постоянной основе и осознано?

С уважением,
Денисова Елена

воскресенье, 6 ноября 2016 г.

#МетодологияВнедрения. Как запустить изменение в организации? Обычные препятствия и преграды

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

Вам знакома такая ситуация? Что вы думали и делали?

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

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

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

Как думаете?

С уважением,
Денисова Елена

вторник, 27 сентября 2016 г.

Личностный рост: Долгосрочные отношения или краткосрочный результат. Еще несколько слов о качестве и эффективности

В этом году мы много обсуждали вопросы качества и эффективности обучения. Кажется, это любимая тема, которая и интересная, и сложная одновременно.

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

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

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

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

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

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

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

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

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

Тоже самое касается любого HR-процесса, как мне думается.

С уважением,
Денисова Елена,
мысли вслух.

суббота, 11 июня 2016 г.

#МетодологияВнедрения Изменение культуры подобно вирусной технологии

Сегодняшний пост выбивается из уже имеющихся в моем блоге.

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

Сегодня поделюсь некоторыми соображениями, наблюдениями и выводами.

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

Но при этом, культуру поменять можно. Трудно. Хлопотно. Долго. Но можно.

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

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

Как это работает?

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

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

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

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

С уважением,
Денисова Елена,