О разработке методологии проекта внедрения: методики, системы и подсистемы

Что общего у всех процессов изменений в организации? 

Есть цель и ее нужно достичь, получить результат.

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

Я подхожу с точки зрения построения системы.

При чем, в эту систему входит кроме "тела проекта" или "ядра проекта" еще и "оплетка", "сопровождение" и "поддержка".

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

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

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

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

1. Определить цель

2. Определить задачи достижения цели:

 - как достигать, 

- что для этого нужно,

- какие условия необходимо выполнить

- какие инструменты использовать

- какие ресурсы привлечь и т.д.

3. Определить элементы системы

4. Под каждую систему разработать методику внедрения

5. Все методики подсистем собрать в единую методологию

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

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

А теперь кейс.

Из внедренных мною проектов это:

- Запуск и настройка процесса электронного обучения в организации, включая разработку с нуля, само обучение и внутреннюю сертификацию. Компания насчитывала 8 000 персонала, из ресурсов - 2 человека: методолог + системный администратор

- Создание и интеграция автоматизированной системы управления знаниями в производственный процесс организации на базе e-learning

- Создание и внедрение в производственный процесс оценки профессиональных знаний всех функциональных подразделений организации

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

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

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

Входные данные:

Более 20 функций ИТ организации

Более 700 ИТ систем поддержки

Более 9 000 персонала

Срок внедрения - календарный год

Требуется:

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

Сроки внедрения - не больше года

Требования к внедренной системе:

1. Масштабируемость

2. Тиражируемость

3. Самоактуализация

4. Саморегуляция

Результат проекта:

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

Тело проекта внедрения:

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

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

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

Элементы системы:

- Модель профессиональных компетенций

- База тестовых вопросов

- Система тестирования

- База профессиональных знаний (рабочая документация)

- База способов развития (инструменты обучения и развития)

- Производственные процессы

- Перечень должностей и функциональных ролей

- Работники функциональных подразделений

- Руководители организации

Для внедрения проекта потребовалось разработать несколько методик, объединенных в общую методологию ведения проекта:

1. Методика вовлечения участников проекта, включающая в себя три уровня вовлечения: ТОП, Руководители подразделений, Эксперты или специалисты подразделений. 

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

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

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

3. Методика проведения функционального анализа

4. Методика проведения внутреннего аудита производственных процессов

5. Методика оценки по профессиональным компетенциям - описание компетенций, индикаторов, проведение профилирования

6. Методика создания профессиональных тестов

7. Методика внедрения моделей профессиональных компетенций в производство

8. Методика применения моделей профессиональных компетенций для развития персонала

9. Методика актуализации модели профессиональных компетенций

10. Методика актуализации базы тестов

11. Методика работы с источниками знаний

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

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

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

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

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

Резюме

1. Любое внедрение или изменение будет работать только тогда, когда выстроена общая методология для создания общей системы, где взаимосвязаны все элементы системы. 
2.  Сама система должна быть нацелена на задачи и стратегические цели и включать в себя в качестве элементов все заинтересованные управленческие уровни - под каждый уровень должна быть разработана и применена своя методика вовлечения.
3. Состав и количество элементов системы зависит от поставленной задачи, а также внутренних особенностей самой организации - точных копий не бывает.
4. Обучение должно быть не над системой, а встроена внутри на всем протяжении проекта, обеспечивая как обучающую функцию, так и сопровождающую.

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

С уважением,

Денисова Елена

https://www.facebook.com/profile.php?id=100004487832154

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

Знаете, все познается в сравнении. И дело даже не в профессиональном росте (хотя, конечно, куда без него).

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

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

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

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

Оказывается, чтобы что-то внедрить нужно пройти алгоритм не один раз, а 20... или больше... А еще научиться говорить со всей Россией.. одновременно.. вместо имен: "Москва, Питер, Самара, Воронеж и т.д. до Хабаровска... а то и дальше"))) Научиться одновременно говорить "Доброе утро!" "Добрый день!" а кому-то "Извините, коллеги за задержку... Доброго вечера!".

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

Какие же полезные выводы сделаны?

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

2. Отработать методологию на пилотном проекте - собрать все шишки, отработать все возражения, прописать методологию, которую можно фиксировать.

3. Методология становится типовой после 3-х внедрений.

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

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

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

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

8. Главное не останавливаться и давать новые проекты для реализации (см. пункт 1).

Из особенностей внедрения моделей профессиональных компетенций:

Да. Это касается всех, так как это требования к каждой функции организации.

Да. Участвуют все - и сотрудники, и руководители.

Да. Стратегическая задача - создать целевую модель и внедрить ее на практике.

НО!

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

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

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

Методологам же это упрощает задачу, так как не нужно спорить и "влезать" в чужие функции - только вести по методологии и помогать интерпретировать получаемые результаты. Сами руководители и сотрудники в итоге заинтересованы в результате.

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

Под впечатлением,

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

https://www.facebook.com/profile.php?id=100004487832154

О проекте автоматизации HR-процессов. Этап 2. Подготовка проектной документации. Part 12

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

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

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

Поэтому, прежде чем приступать к техническому документу, который оформлен и написан так, чтобы его понял программист-разработчик (или команда программистов), следует описать схему словами в виде требований к предполагаемой системе. Проще говоря, зафиксировать пожелания и ожидания заказчика в виде словесного описания уже разработанных бизнес-схем. Описание должно быть очень подробным и содержать требования: "Система должна позволять... , В программе должно быть то  и то, так и так... На экране в такой то момент времени при выполнении такого то условия или при нажатии такой-то кнопки должен появится определенный результат...". Этот описательный документ носит название Бизнес требования к автоматизации. (Он может носить и другое название, принятое в организации, но суть его остается прежней. Я же буду пользоваться этим обозначением, а именно сокращенным БТА.) И на основе БТА уже создается техническое задание, где словесное описание "переводится" на технический язык программистов.

Если ваша программа более сложная, чем прямая последовательность действий в 3-5 шагов, то чаще всего довольно скоро становится понятно, что самостоятельно описать собственные требования и желания крайне сложно. В этом вам может помочь системный аналитик, специалист, который грамотно и дотошно снимет с вас, как с заказчика, потребность в разрабатываемой программе, структурирует полученные данные, подготовит БТА, которое с вами согласует и напишет грамотное ТЗ для программиста. При этом, в последствии поможет вам наладить контакт с программистом, когда у него появятся вопросы (а они обязательно появятся) по разработке, а также проконтролировать правильность написания готового программного обеспечения с запланированным результатом. Более того, на этапе реализации аналитик поможет вам скорректировать техническое задание с учетом выявившихся новых ваших пожеланий (Как бы вы не старались продумать все до мельчайших подробностей и условностей с помощью аналитика, абсолютно все предугадать и предусмотреть невозможно - множество корректировок придется вносить уже в процессе реализации. И тогда нужно будет оперативно дописывать или корректировать уже имеющееся ТЗ, что крайне проблематично сделать самостоятельно без аналитика).

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

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

Принципы описания БТА и ТЗ приводить не буду, если вы не аналитик, то это вам все равно не поможет, а если аналитик, то это вы и без меня это хорошо знаете!

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

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

To be continued...

Всегда ваша

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

https://www.facebook.com/profile.php?id=100004487832154