Продолжаем разговор о том, как сделать так, чтобы то, что должно быть сделано, делалось.

Сегодняшний прием: поставить процессные метрики.

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

Проще всего объяснить на примерах:

• Дисциплина ведения CRM. Совершенствуем CRM процесс, хотим, чтобы продавцы вовремя обновляли информацию по пресейлам. Создаем в карточке пресейла поле: «Дата последнего обновления». На отчете/дашборде к планерке подсвечиваем пресейлы, которые слишком давно обновлены.
• Дисциплина ведения задач в системе контроля поручений. Внедряем систему контроля поручений. Как проверить, что система работает?Отличная процессная метрика — количество поручений, у которых прогнозная дата исполнения находится в прошлом. Прогнозная дата исполнения — это коммуникация исполнителя с постановщиком задачи. Если прогноз исполнения в прошлом, это может означать только одно: исполнитель не коммуницирует, т. е. не пользуется системой. За это можно спрашивать очень строго.

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

• Исполнение процедур проектного управления. Например, перед стартом реализации проекта у руководителя должен быть готов паспорт проекта, план, реестр результатов и реестр рисков. К сожалению, не всегда в реальной бизнес-среде удается добиться, чтобы эти документы появлялись вовремя: топ-руководитель попросил запустить проект в ускоренном режиме, руководитель проекта — важный человек от бизнеса, может подзабить на требования проектного офиса и т. п. В этой ситуации подойдет индикатор, который указывает, что в проекте не соблюдаются процедуры проектного управления, что означает повышенные риски. Индикатор выводить на дашборд как «мнение проектного офиса».
• Количество неправильно оформленных/недозаполненных элементов. Баг-репорты в бэклоге, которые приехали от пользователей, но которые еще не проверил бизнес-аналитик. Недавно созданные записи в базу знаний, которые не проверил на качество оформления ответственный сотрудник (нет отметки «проверено») или не заполнены некоторые нужные поля (аналитический признак в карточке).

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