Лобанов-логист
Лобанов-логист
Личный кабинетВходРегистрация
Например: Логистика

Судьбец по имени KPI Крутицкая Елена Александровна

Судьбец по имени KPI

Крутицкая Елена Александровна 
Автор инструментального решения

Kpi\'s - Key Performance Indicators - ключевые показатели эффективности


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


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


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


Для остроты ощущений выберем именно проект по разработке системы мотивации персонала на основе kpi\'s, а точнее - системы оценки результативности персонала на базе показателей оценки деятельности, укомплектованных в карты оценки деятельности.


\"В чем острота ощущений?\" -  спросите Вы. Так в том, что...


Разработка системы оценки результатов деятельности персонала - это проект про распределение денег


Его результатов ждут с нетерпением все труженики компании.


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


Перед нашим Героем стоит задача разработать-таки систему оценки персонала на основе правильно спроектированных и сформулированных kpi\'s.


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


Понимая скрытую скандальность проекта (проект про деньги каждого сотрудника компании!) он, для начала, постарается защитить свои позиции, и определить/сформировать круг тех, кто поможет ему отстоять проектные решения. Особенно это важно, если в постановке задачи в явную указано, что разработанные карты оценки деятельности необходимо согласовать с теми, кому они будут переданы в исполнение. Без хорошей поддержки это условие можно выполнить только одним способом: пропустить все правильные этапы проектирования системы и сразу начать договариваться с сотрудниками о наборе kpi\'s, ответственность за исполнение которых они готовы на себя взять.


Но, пусть ему повезло, и ему предстоит пройти...


Полный цикл «правильностей» процесса разработки системы оценки результативности персонала на основе kpi\'s


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


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


Вот несколько десятков/сотен бонусных карт, как мы их посчитаем?


А точнее: чем/в чем/где мы их будем вести и рассчитывать? Он будет всем объяснять, что это важно выяснить на старте, чтобы при проектировании сразу учесть все нюансы последующей эксплуатации.


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


Будут перечислены все IT-системы, эксплуатируемые в компании, кто-то наверняка попытается всех убедить, что нужно уйти от этой мультисистемности и внедрить одну Большую Умную систему. Наш Герой опытен и понимает, что от эту мысль нужно как можно быстрее оставить за бортом проекта. Он будет терпеливо объяснять, что каждая система имеет свое назначение и профессиональную направленность, что задача проекта разработать систему оценки персонала. Да, это будет масштабное решение, но все-равно оно не имеет никакого отношения к многолетнему многомиллионному проекту внедрения Большой Умной автоматизированной системы.


Оценивать персонал нужно уже сейчас и нет возможности ждать несколько лет, пока будет реализован предлагаемый IT-проект


Наш Герой попытается привести всех к мысли, что нужно специализированное IT-решение, позволяющее проектировать  системы показателей. Ему будут возражать, что это еще одна капля в мультисистемную IT-бессистемность, что лучше выстроить систему оценки на базе существующей учетной системы.


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


Герой сдерживает себя из последних сил, чтобы не озвучить основной аргумент:

«Нельзя автоматизировать то, что будет разработано в этом проекте! Никакой фундаментальной автоматизации быть не должно!

Мы обязательно ошибемся и эти ошибки потребуется быстро исправить.

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

Но этого говорить нельзя, так как велика вероятность того, что эти слова будут восприняты как доказательство бессмысленности проекта. 


Поэтому Герой устало радуется принятию «никакого решения», а именно:


Сначала разработать систему оценки, а потом уже выбирать программный продукт для автоматизации

По крайней мере он обозначил проблему и отвел беду в виде тотальной реавтоматизации. Проект не быстрый и у него есть время пролоббировать правильно решение.


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




Оценив участников проекта на предмет ожидания каждого, Герой выбирает путь, по которому он должен провести команду. Все результаты проекта должны быть подкреплены какими-то материалами, под которыми подпишутся все, кто принял участие в разработке определенного набора показателей. При этом необходимо выяснить проблемные зоны или зоны неопределенности, в которых живут сотрудники, занимающиеся «чем-то». Для этого Герой инициирует один из двух возможных процессов:


Проектирование дерева целей или описание бизнес-процессов


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


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


Как только показатели проявляются явно, в группах начинаются споры


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


Ближе к концу второго месяца проекта команда разглядывает рабочие материалы, больше похожие на рулоны обоев. Мозг отказывается единовременно держать в голове всю модель (дерево или бизнес-процесс). На четвертом/пятом уровне декомпозиции у всех начинается легкое головокружение при попытке «осознать» и «сопоставить».


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


Наступает переломный момент, когда показатели начинают плодиться как фантомные сущности


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


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


Спустя четыре месяца после начала проекта все участники хотят только одного - чтобы он завершился

Дерево целей (или модель бизнес-процессов) уже никого не интересует, показатели разрабатываются и  формируются в карты голосованием.


«Пусть так! Потом откорректируем», - устало думает Герой и начинает готовить материалы к финальной сдаче.

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

«А какое это имеет отношение к экономике бизнеса? Кто-то проверил, что если эти показатели будут выполнены на 100% , у нас будет тот финансовый результат, который позволит выплатить бонусы?»

Герой понимает справедливость этого вопроса, так же как и то, что

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

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


После утверждения результатов проекта в течение 3х-4х недель рабочая группа в обновленном составе примет...


Решение об автоматизации системы оценки персонала на базе учетной системы


Будет проведен тендер, выберут подрядчика, который подпишется под тем, что в течение 2-3 месяцев его специалисты разработают все, что требуется на том, на чем нужно.


Герой будет занят согласованием технического задания. Его будет мутить от россыпи формул в вале показателей. В итоге, увесистый том, подписанный с двух сторон, будет передан подрядчику в исполнение. С этого момента начнется отсчет 2-3 месяцев автоматизации, которые растянутся до полугода.


Ну вот, наконец, наступит...


Момент начала эксплуатации системы


Еще несколько вечеров для тестирования алгоритмов, и тут нашему Герою, возможно от усталости, начнут приходить видения. Он поймет, как все это будет «заваливаться на брюхо».


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


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


Год профессиональной жизни прошел, худо-бедно...


Система начала эксплуатироваться


Но через несколько месяцев придут первые запросы на то, что «надо бы кое-что поправить». Кое-что из того, что еще в проекте было не разработано, а принято «как сделка с совестью».


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


Сколько компания заплатила за отсутствие результата


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

Немного времени наш Герой потратит на то, чтобы напомнить, как принимались решения и что советовал он, но это уже будет неважно, так как аббревиатура «Kpi\'s» уже становится раздражающим фактором для всех сотрудников компании.


Однажды вечером наш Герой откорректирует свое резюме, чтобы разместить его на hh.ru...



Грустно? Или все происходит не так, как здесь описано? Или проведем анализ, где и кто ошибся?

Наш Герой действительно обладал достаточными знаниями, чтобы реализовать этот проект. Почему же ему не позволили это сделать?


Почему специалистам, которые не отвечали за результаты проекта, позволили влиять на ход процесса?


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


Проекты разработки систем управления на основе Kpi\'s пробуксовывают именно из-за нерешенности технических вопросов


Показателей много, архитектура взаимосвязей между ними напоминает замысловатую паутину, а проектная команда просто не видит всей картины. Решения принимаются на основе того, кто какой «кусок» модели помнит.

Да еще необходимость прописания математики в разработанных показателях, хотя бы для того чтобы протестировать их на работоспособность и возможность собрать данные.


Профессиональные приложения позволяют сразу создавать модели показателей, быстро вносить в структуру показателей и их взаимосвязи необходимые коррективы и видеть результат


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


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


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


А вот предоставить Финансовому департаменту инструмент, который облегчит жизнь его сотрудникам - это почетное право и обязанность IT-департамента.

Стоимость любого специализированного профессионального приложения в разы ниже затрат на реализацию необходимого функционала в непрофильной системе

Кто-то скажет, что таких профессиональных продуктов, позволяющих проектировать системы показателей, нет? Отнюдь! Уже есть и ими можно пользоваться.


Здесь вопрос выбора:

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

  • есть приложения, которые позволяют проектировать динамические системы показателей - вот это уже интереснее. Именно из них и следует выбирать, опираясь на то, сколько потребуется сил на проектирование: одного показателя, системы показателей.


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




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


Мы долго искали и, наконец, сделали свой выбор:

  • 2-3 минуты на создание нового показателя

  • 10-15 минут на создание новой системы показателей

  • динамически перепрописывающиеся алгоритмы расчета

  • преднастроенные графические виды

  • удобный модуль интеграции данных

  • и много других приятных технических мелочей


Выглядит это примерно так:


Новый kpi


Длительность ролика: 5 минут


Новая система kpi\'s


Длительность ролика: 15 минут


Это то, чем пользуемся мы и рекомендуем своим клиентам. Более подробная информация здесь


Не пожалейте времени, найдите инструмент, удобный для Вас. И Ваш проект по разработке системы управления по kpi\'s будет успешным.


Удачи Вам!


И процветания Вашему бизнесу!

Крутицкая Елена Александровна


https://www.lobanov-logist.ru/library/352/59302/

https://ekspertov.ru/

дата: 00.00.0000 00:00:00    просмотров: 2085

рейтинг: 
(Нет голосов)



Рекламный блок

Как ИТ-решения помогают складу наладить работу с перевозчиками Подстроились под рынок: что драйвит рынок логистики Почему управленческий кризис неизбежен при росте компании Юрист о сложных вопросах в контрактах по ВЭД поставок в логистике