Публикация

Статья посвящена отдельным проблемам управления процессом.
Тезис: Управление процессом возможно при осуществлении связи контроля и коррекции.
Проблема: Технологичный контроль (и как следствие коррекция) в некоторых случаях затруднителен.
Решение:

  1. Перенос функций контроля на участников процесса (взаимный контроль)
  2. Нормализуется не задача, а результат, к которому она приводит.
  3. Мотивация привязвается к результатам работы

Регуляция процесса и задачи контроля

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

Проще всего контролировать сущности, которые сами по себе являются индикаторами:
• Итоговые результаты работы (объем продаж, трудозатраты),
• Показатели хода процесса (количество встреч, звонков)
• Факты наступления событий (поступление платежа, выполнение задачи).

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

Ограничение механизмов контроля.

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

Проблема уникальности задачи.

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

Проблема изменчивости критериев.

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

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

Анализируя возникающие в работе кейсы можно увидеть, что на самом деле есть две проблемы:

  1. Заинтересованность в результате
  2. Необъективность контроля

Проблема заинтересованности

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

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

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

Проблема контроля и ответственности

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

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

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

Риски и решения:

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

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

Единственным ограничением, может стать отсутствие технической возможности для реализации такого подхода. Однако если предприятие использует Terrasoft CRM, реализация не составит ни каких проблем.

Поделиться

6 комментариев

Саша!
Мне кажется, нужно больше структурировать материал. Может даже стоит разбить его на несколько глав.
Мне, например, твой текст трудно читать, а из-за этого возникают трудности с пониманием.
Я думаю, что ты согласишься, что хорошая подача материала - залог успеха. Поработай над формой:)

Согласен с Инной. Не хватает тезисов и разбивки статьи на части. Статья интересная, но "ниасилил".

Спасибо. Я пока только разбираюсь с тем как писать посты. То что вы видите - черновик. Обязательно подправлю.

Хочу сделать дополнение к теме индикаторов контроля.

Часто все KPI и критерии оценки разрабатываются "внутри" отдела. Мне кажется правильнее если внутри отдела будут формироваться только критерии эффективности (производительности), а критерии оценки качества будут разрабатываться исключительно "потребителями" работы отдела.

О каком уровне разработки критериев оценки идет речь, Александр? Ведь разработка потребителями критериев качества будет приводить к лоббированию интересов потребителя без понимания процессов рамок, сроков, ресурсов исполнителя. Или ты имел ввиду что-то другое?

Юра,
Естественно выработка критериев качества - двухсторонний процесс, исполнитель всегда имеет право отклонить необоснованные (или недостижимые) требования. Но интерес потребителя первичен - он предъявляет исходные требования к качеству работы.

Потребитель дает исполнителю цель его работы и критерии оценки качества. Исполнитель строит свои процессы исходя из этих требований и разрабатывает критерии эффективности (но не качества).

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

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

Добрый день, уважаемые участники Community!

По вашим просьбам выкладываю плагин контроля кода конфигурации (ККК). Хочу отметить, что плагин в данный момент заточен под некоторые особенности внутренней БД Terrasoft, а именно, в нем есть ADOConnecton для работы с запросами на изменения из нашей БД. Для установки плагина необходимо загрузить все сервисы, и в сервисе adoc_PlgSCWork настроить строку соединения с БД. Также придется делать и дополнительные доработки, связанные с адаптацией ADO запросов к этой БД. Я выкладываю ККК сейчас, что бы больше не оттягивать этот момент, но для его настройки придется дополнительно конфигурировать. Возможно, кто либо из участников Community сделает его адаптацию, и выложит для  всеобщего использования.

В данный момент выкладываю ККК для версий 3.3.0, и 3.3.1

Для его запуска необходимо в параметр wnd в командной строке передать значение wnd_PlgSourceControl.

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

Поделиться

13 комментариев

Спасибо.
А можно в двух словах чем отличается 3.3.0 от 3.3.1 

В основном исправление замечаний. Нового функционала там нет. Можно попробовать загрузить 3.3.1 на БД 3.3.0, т.к. изменения формата сервисов не было.

Спасибо, тогда с 3.3.1 и будем эксперементировать.

Буду рад комментариям

Не было в офисе... прихожу, а тут такое! ДОЖДАЛИСЬ!
Обязательно попробую... но, на 3.3.1...

Спасибо!

--
www.it-sfera.com.ua
Terrasoft Solution Partner

а вот такое вылезло при запуке после вопроса об авторизации (не в начале, где нужен выбор конфигурации, а позднее... кстати, зачем нужна вторая авторизация?)

'Ошибка подключения к рабочей базе: '[Microsoft][Диспетчер драйверов ODBC] Источник данных не найден и не указан драйвер, используемый по умолчанию'

после этого, кстати, дерево сервисов подгружается, можно много что делать)) пока разбираемся)) описания краткого нет, я так понимаю?
При переходе по многим закладкам та же ошибка... могу детализировать, где конкретно.
база на sql 2005, Native Client установлен
освоение начал на версии 3.3.1.40

ООО "Лайнсервис"
www.ls-crm.ru

Александр, добрый день.
Описания плагина пока нет, т.к. разрабатывали для внутреннего использования. Все возникающие вопросы по плагину предлагаю задавать в топике, будем оперативно реагировать.
Плагин работает с двумя базами:
1. База разработки, на которой собственно меняем сервисы, создаем пакеты изменений, видим историю изменения сервисов и пр.
2. База данных компании, в которой ведутся Запросы на Изменение. Запросы на изменение из этой базы попадают в пакеты изменений базы из п.1. Вторая авторизация как раз и нужна для того, чтобы соединится с базой, в которой ведутся Запросы на Изменение.

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

ООО "Лайнсервис"
www.ls-crm.ru

"Александр Кудряшов" написал:будет работать все остальное, а упомянутое сообщение просто игнорируем

Точно. У себя Вы можете вообще удалить эту делать, если решите, что она бесполезна.

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

ООО "Лайнсервис"
www.ls-crm.ru

"Александр Кудряшов" написал:Как минимум возможность копирования сервиса в несколько кликов я уже оценил!

Если эта функция очень востребована -- почему же нет соответствующей идеи на community? :)

"Александр Кравчук" написал:нет соответствующей идеи на community

Сейчас организуем))

ООО "Лайнсервис"
www.ls-crm.ru

А есть какие-то скриншоты или описание как этим дополнением пользоваться?

Войдите или зарегистрируйтесь, чтобы комментировать