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

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

Посмотрим, как можно эффективно управлять ролями. Для начала разберем, какие типовые роли могут быть в компании, опишем верхний уровень ролей. Он может создаваться исходя из принципа 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 года в рубрике «Творчество без купюр». Реанонсирована в контентном блоке в рамках специального проекта редакции

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

Расскажите коллегам:
Комментарии
Адм. директор, Москва
Борис Зверев пишет: Лучше бы сказать ''система стимулирования'' - потому что ''система мотивации'' суть не совсем корректное выражение Грешен, раньше тоже так выражался, пока умные люди не поправили
Одинаково, аналогично и подобно... Системное представление массива стимулов (факторов ''внешнего'' воздействия принудительного свойства) и мотивов (факторов ''внутреннего'' воздействия ''манящего'' характера) может выстраиваться как единой ''конструкцией'' так и, при различных способах систематизации - двумя (и более), различающимися, а потому и не коммуницирующими. Представляя стимулы и мотивы в качестве факторов управления активностью ''исполнителей'' и образуя их в качестве инструменария субъекта ОРУ-деятельности надо ли при этом производить ролевые ''сортировки'' ?
Генеральный директор, Москва

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

Генеральный директор, Бийск
Сергей Норкин пишет: Представляя стимулы и мотивы в качестве факторов управления активностью ''исполнителей'' и образуя их в качестве инструменария субъекта ОРУ-деятельности надо ли при этом производить ролевые ''сортировки'' ?
Вопрос то, что ли риторический? Образование чего-нибудь в качестве инструментария, подразумевает не ''одинаковость, аналогичность и подобность...'', а как раз наоборот их совокупность. Как эту совокупность образовать без ''сортировки''? В статье, к стати, присутствует эта ''сортировка''. Мотивация статусностью + стимулирование зарплатой.
Генеральный директор, Владивосток
Ну конечно можно в очередной, две тысячи сто восемнадцатый раз придумывать свои роли, опираясь исключительно на авторский опыт. А можно использовать уже готовое решение, социоматрицу из 16 типов Мне она почему нравится - она создана вне бизнеса и гораздо универсальнее всех других решений, сиречь ролей.
Нач. отдела, зам. руководителя, Москва

Матрица не понравилась (

Нач. отдела, зам. руководителя, Москва
Автор пишет в статье:
В дальнейшем используя семантические связи, мы создадим иерархии, благодаря которым существенные признаки ролей более высоких уровней смогут наследоваться ролями уровней ниже. Например, система мотивации, обучения и т.д.
Мне представляется здесь, в построении иерархии, есть аналогия с тем, что используется в языках программирования - типа объектно ориентированного подхода в части наследования. А семантические связи - не слишком ли это сложно? Вместо иерархии c наследованием можно использовать простые концептуальные структуры, и тогда значительно проще выглядит подход типа управления правами доступа в информационных системах. В этом случае каждый участник просто входит в определённую группу (типа получает роль), и не потребуется ''наследование'' - Используя отношение один ко многим (1:М) - даем возможность участнику входить в несколько групп, при этом автоматически будет добавляться то, что называете ''признаки ролей''. При таком подходе этом можно легко ввести нового члена группы, дать временные полномочия на время отпуска другому участнику, удалить из группы или перевести в другую, и т.п.. И такой подход легко ''наложить'' на информационную систему. Понятно, что если убрать какие-то детали, например, владельца процесса,. этот подход можно использоваться и при функциональном управлении.
. . . . Директор по развитию, Москва
Борис Яровой пишет: Ну конечно можно в очередной, две тысячи сто восемнадцатый раз придумывать свои роли, опираясь исключительно на авторский опыт. А можно использовать уже готовое решение, социоматрицу из 16 типов Мне она почему нравится - она создана вне бизнеса и гораздо универсальнее всех других решений, сиречь ролей.
Уважаемый Борис! Я в описании ролей опираюсь не на авторский опыт, а на методику PDCA. Каждая роль соответствует с одной стороны одному из этапов PDCA , с другой стороны она уточнена спецификой процесса. То есть роль несет в себе функциональное предназначение. А Вы предлагаете использовать семантику психотипов. Это не относится к функционалу. Однако я подумал, что основываясь на приведенной Вами классификации можно построить модель основанную на поведенческих предпочтениях... Возможно это была бы интересная методика позволяющая построить модель (в арис кстати тоже) коллектива в основе которого лежат не компетенции, а психотипы. Использовать ее можно было бы при наборе экипажей межгаллактических звездолетов.
. . . . Директор по развитию, Москва
Сергей Лаптев пишет: Матрица не понравилась (
Уважаемый Сергей! Обоснуйте.
. . . . Директор по развитию, Москва
Александр Соловьев пишет: Мне представляется здесь, в построении иерархии, есть аналогия с тем, что используется в языках программирования - типа объектно ориентированного подхода в части наследования. А семантические связи - не слишком ли это сложно? Вместо иерархии c наследованием можно использовать простые концептуальные структуры, и тогда значительно проще выглядит подход типа управления правами доступа в информационных системах.
Уважаемый Александр! Вы правильно уловили суть. Но семантическое наследование это самое простое, что может быть. Помимо простоты есть еще одна важная задача построения модели таким способом. Я считаю, что при исполнении своего функционала сотрудники забывают в каком амплуа они представлены (постановщик задачи, исполнитель, контролер, аналитик) отсюда и множество коллизий в процессе. Семантический подход должен сформировать эту наследственную память. Да и управлять легче такими ''родственными'' объектами.
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
За год стереотипов в отношении женщин на рынке труда стало меньше

В 81% компаний сообщили, что семейное положение женщины не влияет на решение о ее работе.

Сервис аренды самокатов Whoosh выйдет на IPO

Ожидается, что это произойдет 14 декабря 2022 года.

«МегаФон» продал долю в «Связном»

Оператор «МегаФон» владел 25% акций сети магазинов «Связной».

Россияне назвали размер пенсии мечты

Среди жителей мегаполисов наиболее высокий уровень запросов в Москве и Санкт-Петербурге.