Ранее в своей практике мне не доводилось разрабатывать ни KPI, ни способы его привязки к премированию сотрудников. Заполнять листы-шаблоны на подчиненных, попутно ворча на бестолковость и/или субъективность этого действа — было. Анализировать положения о премировании на предприятии, выявлять противоречивости в документах, явные ошибки и несоответствия — было. Но вот что бы кардинально менять или создавать заново систему премирования — такого в моем послужном списке еще не было.
Но все когда-то бывает в первый раз. Теперь это мой шанс дать другим повод поворчать и покритиковать. Под катом – мои попытки объяснить, почему депремирование мне нравится больше, чем премирование.
Собственно задача:
Разработать систему премирования для двух отделов IT-направленности на небольшом предприятии реального сектора.
Отдел 1 — условно вторая линия техподдержки. Предприятие имеет приличный зоопарк систем и сотрудники достаточно уникальны. Т.е. в большинстве случаев сотрудник А не может выполнить работу сотрудника Б и наоборот.
Отдел 2 — проектный офис. Создается с нуля. Предполагает наличие универсальных РП под внедрение IT проектов. Само внедрение должно проводиться силами консалтинговых компаний.
Попытка обратиться к помощи друзей результатов особых не дала. Все разговоры за чашкой кофе оканчивались, как правило, двумя выводами:
а) большинство известных параметров оценки либо бессмысленны, либо субъективны, либо трудноизмеримы, либо имеют возможность для манипуляции со стороны оцениваемого или оценщика;
б) действительно выдающиеся (чаще всего разовые) результаты конкретного сотрудника зачастую невозможно «впихнуть» в рамки имеющегося на предприятии KPI, т.к. нет подходящих критериев. И тогда руководителю приходится выбивать «премию сверх премии» для таких сотрудников. И это только в том случае, если руководство обладает обостренным чувством справедливости и не ленится тратить свое время на организацию вознаграждения не для себя любимого.
На своем трудовом пути в IT я еще не встречала системы KPI, про которую я могла бы сказать, что она не субъективна. Видимо в качестве компенсации за это, мое непосредственное руководство всегда без предубеждении решало задачу вознаграждения. Не буду говорить за моих коллег, но я точно не в претензии. Но, подозреваю, не всем так везет. Поэтому хотелось бы разработать что-то, что не будет тестом на моральную устойчивость для руководителя, а будет как можно более объективно оценивать работу сотрудника.
Увы, в контексте поставленной задачи я не смогла придумать вообще ни одного подходящего параметра, который можно было бы использовать в KPI:
Поэтому я предлагаю посмотреть на этот вопрос совершенно с противоположного ракурса. В этом случае вопрос «за что премировать сотрудника?» превращается в «за что наказать сотрудника?».
Вот небольшой список неприятных ситуаций, достойных денежного наказания, которые были в моей практике и в практике коллег:
По моему представлению депремирование в рамках ТК можно организовать следующим образом:
Какие плюсы такого подхода по сравнению с KPI-темой вижу я:
Помимо этого, у меня есть какая-то личная нелюбовь к KPI для направлений, где должно превалировать качество. Изначально посыл у этой системы получается не совсем правильный. Система премирования, завязанная на KPI, для меня выглядит как следующий посыл от работодателей к наемному работнику:
Мы предполагаем, что ты свою работу выполняешь посредственно. С помощью KPI у тебя есть возможность доказать, что это не так и ты делаешь свою работу качественно. Доказывай!
В случае, если премиальная часть по умолчанию начисляется в полном объеме и уже затем минусуется, при тех же входных смысл немного меняется:
Мы предполагаем, что ты свою работу выполняешь качественно. Тем не менее, мы проверяем тебя, будь к этому готов. Не подведи!
Получается такой вот вопрос презумпции невиновности.
А как бы вы отнеслись к такой теме, коснись она непосредственно вас?
Но все когда-то бывает в первый раз. Теперь это мой шанс дать другим повод поворчать и покритиковать. Под катом – мои попытки объяснить, почему депремирование мне нравится больше, чем премирование.
Собственно задача:
Разработать систему премирования для двух отделов IT-направленности на небольшом предприятии реального сектора.
Отдел 1 — условно вторая линия техподдержки. Предприятие имеет приличный зоопарк систем и сотрудники достаточно уникальны. Т.е. в большинстве случаев сотрудник А не может выполнить работу сотрудника Б и наоборот.
Отдел 2 — проектный офис. Создается с нуля. Предполагает наличие универсальных РП под внедрение IT проектов. Само внедрение должно проводиться силами консалтинговых компаний.
Попытка обратиться к помощи друзей результатов особых не дала. Все разговоры за чашкой кофе оканчивались, как правило, двумя выводами:
а) большинство известных параметров оценки либо бессмысленны, либо субъективны, либо трудноизмеримы, либо имеют возможность для манипуляции со стороны оцениваемого или оценщика;
б) действительно выдающиеся (чаще всего разовые) результаты конкретного сотрудника зачастую невозможно «впихнуть» в рамки имеющегося на предприятии KPI, т.к. нет подходящих критериев. И тогда руководителю приходится выбивать «премию сверх премии» для таких сотрудников. И это только в том случае, если руководство обладает обостренным чувством справедливости и не ленится тратить свое время на организацию вознаграждения не для себя любимого.
На своем трудовом пути в IT я еще не встречала системы KPI, про которую я могла бы сказать, что она не субъективна. Видимо в качестве компенсации за это, мое непосредственное руководство всегда без предубеждении решало задачу вознаграждения. Не буду говорить за моих коллег, но я точно не в претензии. Но, подозреваю, не всем так везет. Поэтому хотелось бы разработать что-то, что не будет тестом на моральную устойчивость для руководителя, а будет как можно более объективно оценивать работу сотрудника.
Увы, в контексте поставленной задачи я не смогла придумать вообще ни одного подходящего параметра, который можно было бы использовать в KPI:
- Количество закрытых задач? По моему опыту для организации такого характера количество запросов то густо, то пусто. В добавок, когда IT специалист имеет прямой контакт с пользователем, то есть риск манипуляции этим параметром.
- Сроки выполнения задач? Сам по себе параметр достаточно субъективный, а в условиях большой доли уникальных специалистов эта субъективность увеличивается.
- Удовлетворенность пользователей? В небольших компаниях это часто вопрос личных взаимоотношений и только.
Поэтому я предлагаю посмотреть на этот вопрос совершенно с противоположного ракурса. В этом случае вопрос «за что премировать сотрудника?» превращается в «за что наказать сотрудника?».
Вот небольшой список неприятных ситуаций, достойных денежного наказания, которые были в моей практике и в практике коллег:
- Грубые архитектурные ошибки (н-р, разработка сервисов для бизнеса, выполняемых не на серверах, а на локальных машинах; разработка решений без согласования со специалистами по смежным системам);
- Сокрытие информации и желание стать незаменимым на предприятии (н-р, использование своих пользовательских паролей в исполняемых модулях; документация ненадлежащего качества);
- Невыполнение скучной рутинной работы (н-р, составление протоколов, инструкций и документирования в целом; выполнение регламентных работ);
- Косяки с бекапированием и потерей данных;
- Самовольная выкладка в продуктив без должного тестирования, выкладка без согласования с пользователями.
- Не информирование пользователей о принятых решениях и вообще вопросы коммуникаций.
По моему представлению депремирование в рамках ТК можно организовать следующим образом:
- По трудовому договору вознаграждение сотрудника состоит из 2-х частей: окладной и премиальной;
- Заранее составляется перечень возможных «прогрешений» и их «стоимость»;
- По умолчанию работнику начисляется премия в размере 100%;
- Если в оцениваемый период сотрудник допустил какие-либо ошибки, то соответствующим образом уменьшается величина премиальной части.
Какие плюсы такого подхода по сравнению с KPI-темой вижу я:
- Не требует больших временных затрат на разработку — нет необходимости заниматься балансировкой параметров. Можно, по примеру нашего правосудия, использовать принцип поглощения и сложения в рамках месячного размера премиальной части. Особо кровожадные, конечно, могут использовать американский подход с полным сложением и «размазыванием» получившейся суммы на более длительный период.
- Более гибкая система, легко адаптируемая под изменение ситуации. Перечень для депремирования можно расширять по мере выявления новых проблем. Если в отчетном периоде сотрудник сделал что-то, что отсутствует в списке с «ценой» — считаем, что ему повезло и не накладываем штраф. При этом актуализируем список дополнением нового пункта. Задача — не лишить человека денег, а постараться избежать этой же ошибки в будущем. Возможно применить дифференцированную шкалу – при повторе «цена» ошибки увеличивается.
- При желании в эту схему можно вписать все параметры, используемые в KPI, «вывернув их наизнанку»: премирование за процент закрытых задач не менее Х –> депремирование в случае, если процент не закрытых задач более 100-Х и т.д.
- Возможность применять для оценки параметры, измерение которых очень трудоемко, используя для этого выборочные проверки. Например, соответствие кода техническому регламенту. Строить KPI на выборочных проверках как-то не справедливо, а вот депремирование — в некоторых случаях приемлемо.
- Смещение фокуса руководителя подразделения на проблемные зоны. Если в подразделении раз за разом возникают однотипные ошибки – это повод подумать на тему эффективности организации процесса.
Помимо этого, у меня есть какая-то личная нелюбовь к KPI для направлений, где должно превалировать качество. Изначально посыл у этой системы получается не совсем правильный. Система премирования, завязанная на KPI, для меня выглядит как следующий посыл от работодателей к наемному работнику:
Мы предполагаем, что ты свою работу выполняешь посредственно. С помощью KPI у тебя есть возможность доказать, что это не так и ты делаешь свою работу качественно. Доказывай!
В случае, если премиальная часть по умолчанию начисляется в полном объеме и уже затем минусуется, при тех же входных смысл немного меняется:
Мы предполагаем, что ты свою работу выполняешь качественно. Тем не менее, мы проверяем тебя, будь к этому готов. Не подведи!
Получается такой вот вопрос презумпции невиновности.
А как бы вы отнеслись к такой теме, коснись она непосредственно вас?