Управлять ролями персонала или должностями?

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

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

Итак, типовые роли:

«Стратег». Его задачи – формирование плана развития и целей, к которым стремится компания или отдельное ее подразделение. На каждом уровне иерархии в компании должны быть свои «Стратеги». Также задача «Стратега» – формирование и оптимизация рабочих процессов, обеспечение их ресурсами.
«Исполнитель». Выполняет, используя существующие процессы, те задачи, которые запланировал «Стратег». Основной его критерий – производительность.
«Контролер». Фиксирует текущие показатели исполнения бизнес-процессов. Данные, которые он получает, являются фактом.
«Аналитик». Производит сравнение плановых и текущих фактических показателей, формирует аналитическую отчетность.
«Принимающий решение». На основании аналитической отчетности принимает в отношении исполнителей или системы одно из четырех управленческих решений: наградить, наказать, переучить, изменить начальные условия.

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

PDCA	Роли	Ответственность
Планирование	Стратег продаж	Отвечает за планирование показателей процесса продаж
Исполнение	Ответственный за развитие	Отвечает за развитие клиентской базы
Контроль	Контролер заявок	Контролирует поступающие заявки
Анализ	Аналитик продуктов	Анализирует продажи
Принятие решения	Владелец процесса продаж	Принимает решения в рамках своего бизнес-процесса

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

Таблица 2. Статусы бизнес-ролей.

№	Воздействие на систему	Администратор	Исполнитель	Агент
1	Изучение бизнес-процессов	3	2	1
2	Изучение товаров\услуг	3	2	1
3	Аттестация	3	2	1
4	Штраф за невыполнение	3	1	0
5	Распорядок рабочего дня	3	2	0
6	Создание обучающих видеороликов	3	0	0
7	Создание концепции развития	3	0	0
8	Экспертиза бизнес-процессов	3	1	0
9	Оптимизация бизнес-процессов	3	1	0
10	Редактирование бизнес-процессов	2	1	0

Степени воздействия определены следующим образом:

0 – не участвует.

1 – участвует по желанию.

2 – участвует по назначению.

3 – обязательное участие

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

Общая формула дохода (Д) для всех статусов должна выглядеть так:

Д = Б*(Н-Ш) + К,

Где: Б – базовый оклад, Н – надбавка к базовому окладу, Ш – штраф за невыполнение задания, К – процент комиссии.

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

Таблица 3. Таблица коэффициентов для статусов.

	Базовый оклад, Б	Надбавка, Н	Штраф, Ш	% Комиссии, К
Администратор	1	1,5	1	1
Исполнитель	1	0	0	1
Агент	0	0	0	1

Цифры в таблице – условные, они отображают масштаб значений коэффициентов. Так, исходя из таблицы, «Администратор» получает базовый оклад в полном объеме, надбавка к базовому окладу равна 150%, штраф может достигать 100% от базового оклада, комиссионные он получает в соответствии с политикой поощрений.

Возникает вопрос – кто и когда присваивает статус исполнителю? Лучше всего, если создана такая система, в которой исполнитель сам стремится повысить свой статус – добровольно! При этом осознав, что вместе с правом получать более высокую зарплату, он получает дополнительные обязанности. Новичок, получив статус «Администратор», рискует не справиться и тем самым остаться без вознаграждений. Если же сотрудник намеревается строить карьеру постепенно на долговременной основе, то ему лучше начинать с «Агента». Осваивая новые компетенции, он будет легче адаптироваться к новым обязанностям, которые добавят ему дополнительные права.

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

Впервые статья была опубликована на Executive.ru 18 августа 2011 года в рубрике «Творчество без купюр». Реанонсирована в контентном блоке в рамках специального проекта редакции

Источник изображений: Фотобанк Фотодженика

+707 Александр Соловьев Нач. отдела, зам. руководителя, Москва 17 июня 2015, 23:58

Автор пишет в статье:

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

Мне представляется здесь, в построении иерархии, есть аналогия с тем, что используется в языках программирования - типа объектно ориентированного подхода в части наследования. А семантические связи - не слишком ли это сложно? Вместо иерархии c наследованием можно использовать простые концептуальные структуры, и тогда значительно проще выглядит подход типа управления правами доступа в информационных системах. В этом случае каждый участник просто входит в определённую группу (типа получает роль), и не потребуется ''наследование'' - Используя отношение один ко многим (1:М) - даем возможность участнику входить в несколько групп, при этом автоматически будет добавляться то, что называете ''признаки ролей''. При таком подходе этом можно легко ввести нового члена группы, дать временные полномочия на время отпуска другому участнику, удалить из группы или перевести в другую, и т.п.. И такой подход легко ''наложить'' на информационную систему. Понятно, что если убрать какие-то детали, например, владельца процесса,. этот подход можно использоваться и при функциональном управлении.