Проектирование модели компетенций

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

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

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

- переместить в другую, более подходящую компетенцию

- убрать совсем из-за туманности и очевидной бесполезности

- упростить, потому что они переусложнены

- обобщить, потому что они слишком специфичны

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

При пересмотре и перестановке примеров важно сохранить коды, присвоенные им первоначально.

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

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

Такой подход верен и применим для деятельности, которая реально усложняется от позиции к позиции; при этом соответственно, возрастают уровни необходимых компетенций. Этот способ пригоден для структур, в которых грейды деятельности остаются неизменными. Если грейды работ не меняются, кодирование информации, проведенное в процессе ее сбора, может использоваться непосредственно для компетенций, которые "автоматически" устанавливают различия между уровнями работы. Например: очевидно, что составленная непосредственно на основе закодированной информации компетенция «Работа в команде» относится к персоналу Ступени 2 и отличается от компетенции, необходимой персоналу .

- Второй способ: уровни компетенций «выводятся» непосредственно из содержания информации о работе.

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

Например: в кластере «Принятие решений» некоторые стандарты поведения могут относиться к принятию ежедневных решений, а другие - к принятию стратегических решений. Это разные уровни компетенций. Разделение компетенций по уровням распространяется на все ранги сотрудников. Использование такого подхода создает очевидную картину: одни компетенции разделяются на один или два уровня, другие - на несколько уровней.

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

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

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

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