Часть 1. Составление профиля (матрицы) компетенций

Всем привет!

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

Давайте знакомиться – меня зовут Алексей, и я руковожу командой бизнес-аналитиков в СМ Лаб. В этой статье я расскажу вам о том, какой путь я прошел при построении системы работы с профессиональными компетенциями своих сотрудников, которая включает в себя профилирование, оценку и планы развития. С чего начинал, что пробовал, как ошибался, на какие подводные камни натыкался, как работал с полученными данными и какие решения принимал.

Начинать имеет смысл с базовых вопросов – надо понять, зачем мы вообще начинаем заниматься всем этим? Возможно, ответ будет довольно простым и очевидным, возможно – нет. Тем не менее, ответ на вопрос «чтобы что?» это то, с чего всегда надо начинать. Для себя на вопрос «Зачем мне заниматься развитием компетенций аналитиков своей команды?» я ответил так:

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

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

Таким образом, отвечая на вопрос «чтобы что?» мы определяем связь этого проекта с бизнес-целями команды. Если скрыть всю цепочку рассуждений, то получится примерно так: «Зачем заниматься развитием компетенций команды?» - «Чтобы эффективнее решать задачи». Просто? Очень! Очевидно для всех? Увы, не всегда.

Первые шаги – разбираемся в том, что мы делаем

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

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

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

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

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

4. После того, как мы выбрали решение, с которым будем работать, стоит прикинуть, сходится ли экономика этого решения – будет ли потенциальный эффект покрывать потенциальные затраты. Для этого нам может потребоваться понимание процесса в целевом состоянии (TO BE), влияние изменений на смежные области, метрики.

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

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

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

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

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

• связанные с управлением процессами;

• связанные с управлением изменениями;

• связанные с информационными системами;

• коммуникативные;

• лидерские;

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

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

Шаг второй – определяем уровни и ожидания от них

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

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

0 – отсутствие навыка;

1 – владение теорией на базовом уровне;

2 – применение теории на практике;

3 – решение кейсов с консультацией экспертов;

4 – самостоятельное решение сложных кейсов;

5 – владеет как боженька, сам может выступать экспертом / консультантом;

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

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

О том как применить этот профиль для построения программ развития сотрудников – в следующей статье, а пока – делитесь своим опытом построения профилей компетенций для сотрудников.