Измеримый мир
Чтобы продать что-то ненужное, надо купить что-то ненужное.
А у нас денег нет.
Кот Матроскин
А каковы критерии ненужности?
Виртуальный помощник
Наш мир, наша культура таковы, что вольно или невольно — но мы живем в среде, где сравнение есть краеугольный камень всего. Разнообразие породило сравнение. Сравнение принесло в нашу жизнь критерии, по которым мы что-то сопоставляем, выясняя сходства или различия. Критерии, они же метрики, — самая большая удача и самая большая неудача проектного и регулярного менеджмента. Почему?
Сила метрик
Сила метрик в том, что они позволяют выстроить оценку того или иного процесса или события, выстроить систему «светофоров». Сила метрик в том, что с их помощью можно определить реакции на те или иные отклонения — и таким образом «на выходе» получить стройную модель управления. Сила метрик и в том, что они способны сделать прозрачным любой процесс или явление.
Кстати, расстановка метрик — особое искусство. Конечно, в отдельных ситуациях их расставить просто. Например, мы оцениваем некий регулярный автоматизированный процесс движения документа от создания до исполнения. В этом случае имеем дело с метриками документа и метриками процесса. Что мы хотим получить от документа? Чтобы он прошел все контрольные точки в заданное время. Соответственно, применительно к документу метрикой будет время его движения между узлами. Или, как вариант, — время нахождения на узле процесса. При налаженной системе оповещений и эскалации, связанной с этими характеристиками, можно построить некую аналитику и на ее основе сделать те или иные выводы применительно к документу. Процесс же отличается от документа тем, что относится к множеству документов, предусматривает ручные операции и — самое важное — имеет вариации, не заложенные в алгоритм автоматизированной обработки. Как оценить, насколько процесс эффективен? Самое простое — по статистике. Скажем, установить пороги, что выполнение более 95% в согласованные сроки говорит о высокой эффективности процесса, от 90% до 95% — о нормальной эффективности, от 70% до 90% — о низкой.
Но тут возникает немало вопросов. Например, что должно попадать в статистику? Предположим, на каком-то этапе документ может быть отозван, то есть он должен вернуться или к началу, или на предыдущий этап. Тогда увеличится не только общее время обработки документа, но и период его время пребывания документа на каждом узле. В итоге статистика, конечно, статистична, однако картину показывает необъективную. Потому что процесс, по большому счету, нормальный. (Пересогласование документа всего лишь ветка процесса.) Таким образом, получается, что статистику нужно рассматривать в нескольких аспектах: для нормального процесса (без возвратов), для процесса с возвратами. При этом для последнего варианта анализировать количество возвратов и коды отказов... В результате как сбор статистики, так и ее интерпретация с точки зрения оценки эффективности получается достаточно нетривиальным занятием. Но, как и все на свете, если выстроить итерационный процесс улучшения сбора и анализа показателей, то через некоторое время вполне реально построить действенную систему, формирующую достоверную и объективную картину происходящего.
Но это касается одного процесса. В любой существующей компании таких процессов достаточно много. И тут возникает два вопроса: область охвата и единая статистика. Область охвата — это фактически указание, сколько процессов мы будем рассматривать с точки зрения обеспечения метриками. И следующий вопрос — сводная статистика по метрикам. Не секрет, что любой руководитель хоть раз мечтал о неком «волшебном экране», на котором в реальном времени отображается «вся информация» о состоянии компании. Только вот мало кто задумывался, что значит «вся информация» по сути: финансы, скорость обработки и т. д. Понятно, что такой «сводный монитор» очень зависим от сферы деятельности компании: метрики, которые интересны руководству трейдера, без серьезной переработки не подойдут менеджменту логистической компании. Ну и наверное, ни для кого не тайна, что если и существует такой «монитор», то у каждой компании он свой. Впрочем (по личным наблюдениям), подобный «монитор» дает лишь статистику по критичным направлениям. Чтобы понять, что происходит в целом в компании, приходится либо «проваливаться в детали», либо менять мониторы. В общем, это абсолютно логично, и чем больше компания, тем больший уровень абстракции будет в сводном отчете. И тем меньше внимания будет уделено деталям (что не хорошо и не плохо само по себе, просто надо понимать данный факт).
Таким образом, выстраивая систему оценки эффективности процессов в компании, первое, что нужно сделать, — определить область охвата, то есть те процессы, которые будут измеряться, затем необходимо указать очередность включения процессов в систему метрик и заложить возможности для коррекции метрик как отдельных процессов, так и группы процессов.
Важное замечание: перед тем, как принимать принципиальное решение о том, следует ли вообще использовать метрики в текущей деятельности, надо максимально правдиво ответить себе на вопрос: а что, собственно, хочется в итоге получить от метрик? Какова цель? И оправдывает ли она вложенные средства — со всех точек зрения?
Про потребителя
Наверное, все рассуждения про метрики были бы бессмысленными, если не рассматривать один важный аспект, а именно потребителя. (Имеется в виду, конечно же, потребитель метрик процесса.) Почему это важно? Потому что если делать все «по-взрослому», то за теми или иными значениями метрик могут стоять управленческие решения (зафиксированные в процессе или нет), а значит, и потребитель должен быть серьезным. Метрики ради метрик — не наш метод. Кто является потребителем метрик процесса? В первую очередь владельцы процесса — те, кто устанавливает правила его работы. Во-вторых, те, кто так или иначе заинтересован в соблюдении выполнения SLA процесса и в его бесперебойной работе.
Пожалуй, основное, что нужно знать о потребителе метрик, — он должен быть или вовлечен в процесс, или заинтересован в его работе. Потребитель не обязательно должен иметь возможность влиять на ход процесса — но, «по фэншуй», должно быть организовано некое «окно», куда любой потребитель или участник процесса (или результата работы процесса) может направить свои предложения по улучшению. Также желательно организовать process review — мероприятие, посвященное рассмотрению и пересмотру текущих метрик, алгоритмов и эффективности работы процесса в целом. Скажу честно, мало где видел, чтобы эта работа проводилась на регулярной или нерегулярной основе. Но в том или ином виде элементы такой работы присутствуют везде, где есть хоть как-то выстроенный регулярный менеджмент.
Наверное, нет смысла описывать преимущества подобного мероприятия, они очевидны. Процесс живет, развивается, становится адаптивным, развитым... Но здесь нужно обязательно упомянуть про возможную опасность: уйти в работу ради работы и излишнюю теоретизированность процесса. Попав в эту ловушку, потребитель процесса постепенно меняет фокус с эффективности процесса на псевдоэффективность изменений. И увязает в них, в худшем случае переходя к модели «работа ради работы». Кстати, избежать подобного соблазна несложно: достаточно вовремя остановиться, вспомнив, что порой лучшее — злейший враг хорошего. И всегда держать «в голове» — для чего, для какой цели служит та или иная метрика.
И еще одно важное замечание. Для потребителя метрики не равнозначны. Одни имеют больший приоритет, другие — меньший. Исходя из этого, проектируя систему метрик, нужно группировать их по определенным признакам, а не только по отношению к процессу, документу, объекту... В качестве такого признака может выступать, например, эффективность, производительность, натуральные показатели и т. д. Аналогично для потребителя может быть выстроена и многоуровневая иерархия метрик. (Тут важно помнить про алгоритмы расчета показателей верхнего уровня: они могут быть весьма нетривиальны.)
Кстати, работая с потребителем, важно понимать, какие решения будут приниматься на основе каких групп метрик — это позволит более четко сфокусировать их на требуемый результат.
Про SLA
Видимо, не скажу ничего нового, если напомню, что SLA связаны с метриками. По сути, SLA — публичная оферта для разных категорий пользователей, в которой зафиксированы метрики высокого порядка. Тонкость в том, что выполнение SLA — это процесс, каждый из шагов которого может и должен регулироваться и контролироваться при помощи метрик. По большому счету для потребителей SLA не имеет значения, как именно будет обеспечено его выполнение, важно, чтобы оно было реализовано с заданными параметрами. При этом сам процесс чаще всего работает по принципу черного ящика, а параметры SLA сводятся ко времени и некому фактическому ожидаемому результату.
Поэтому не стоит смешивать метрики, указывающие на качество и состояние процесса, и SLA, который, собственно, обозначает публичную (по отношению к процессу) оферту. В реальной жизни, кстати, зачастую оперируют либо одним из этих понятий, заменяя им второе, либо ограничиваются одним SLA по принципу «процесс самоорганизующийся». Нет, конечно, возможно и такое, но вот выявление узких мест в данном случае будет как минимум затруднено. Да и простор для оптимизации значительно сужается: без достоверной информации и статистики объект управления (процесс) приобретает такие неприятные черты, как человекозависимость и отсутствие критериев оценки. Хотя в ряде случаев эта ситуация не является «плохой»: есть организации, которые принципиально не вмешиваются в «нутро» процесса, считая, что важнее выполненный SLA, чем возможная оптимизация.
Продолжение следует
Опубликовано 29.03.2016