Практика настоящего цикла Деминга-Шухарта (как посчитать SLA)

Мой бывший коллега Саша Цимбалистов написал-таки отличную статью.

Я уже миллион раз слышал вопросы - а как рассчитать показатели SLA? Что делать с инцидентами, которые не укладываются в плановые сроки? А что будет, если мы больше половины инцидентов решать вовремя не будем?

Ответы на все эти вопросы ищите во второй части (статистический анализ инцидентов на реальных данных Service Desk). И это настоящая практика цикла Деминга-Шухарта, а не бла-бла о совершенствовании и девятишаговых процессах в пустоте. Краткий пересказ нужных разделов теории качества, чтобы не путаться в понятиях - в первой части. Кому нужен подробный, читайте библию теории качества (о картах Шухарта в основном) - о литературе я тоже писал.

ps. еще обязательно напишу об этом, со временем только туго пока.

Рекомендации по метрикам управления знаниями

Очень внимательно по случаю перечитывал KCS (Knowledge-Centered Support). Рекомендации по организации процесса управления знаниями (knowledge management). С первого прочтения было ясно, что эту штуку неглупые люди писали.

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

Верноориентированных целей. Ребята открывают и закрывают тему для управления знаниями буквально в паре абзацев:

Our first important concept distinguishes between activities and outcomes. If we put goals on leading indicators (activities), we will get what we ask for. Unfortunately, the activity by itself is not an indicator of value. For example, if we set a goal for each support analyst to create 10 solutions per month, we will get 10 solutions a month. However, if we are paying attention we will notice these solutions are often created on the last few days of the month and they contain little or no valuable information (things like “fixed the customer problem”). Goals on activities do not generate the desired outcome. In fact, in a knowledge management environment, goals based on activity will corrupt the knowledge base.

Что сказать? Неоднократно рекомендовал и буду рекомендовать для строящих процесс knowledge management разок глянуть в ITIL v3, а затем много раз смотреть в KCS, благо для частных интересующихся оно бесплатное и доступное. Спасибо Сергею Осадчему за нахождение и рекомендацию KCS пару лет назад, пользовал с тех пор неоднократно.

Маленькая забавная книжка для процессников

Aris коммьюнити подбрасывает периодически интересные инструменты или материалы. А в этот раз небольшую книжку о том, как делать процессы более эффективными. Книжка доступна бесплатно (для этого нужно будет зарегистрироваться) вот по этой ссылке: http://www.softwareag.com/corporate/res/books/pi/default.asp

Сбербанк - отлично!

Просто невероятно, товарищи!

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

Ну правда, лет пять назад не ожидал такого увидеть в своей жизни в нашем Сбербанке. Рад, что не разучился удивляться!

CobiT v5

Доступна ссылка с черновым проектом CobiT v5 (Design Paper Exposure Draft), читаем, критикуем - предлагаем.

Работаем с метриками

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

Вроде разумно и просто?

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

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

Осмелюсь доложить результаты наблюдений: с проектированием метрик творится бардак, товарищи:
- иногда метрики, показатели вообще не проектируют, обходятся набором встроенных отчетов системы;
- если проектируют – то исходят только из технических возможности системы или аппаратной части;
- лучшим руководством считается единственная переведенная на русский, не очень внятная книга Питера Брукса;
- подавляющее большинство менеджеров процессов и консультантов слабо различают KGI, KPI;
- наборы метрик из ITIL многие до сих пор считают стоящим примером для подражания! (о ужас)

Как правило, все проектирование заключается в игре вытащить из полной шляпы примеров кролика – единственно верную метрику! В шляпе с примерами кроликов сидит: все тот же Брукс и аналоги, ITIL, любая библиотека метрик и туда же CobiT до кучи. Хорошо, если понимается связь KGI и целью процесса. Высшим пилотажем будет наличие не десятка бессмысленных показателей в KGI, KPI, а всего лишь нескольких – отражающих ключевые цели и задачи.

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

Свободная библиотека KPI

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

После регистрации доступно около 900 KPI (библиотека постоянно обновляется), из них 450 KPI в разделе IT Management.
О библиотеке, с сайта: the free KPI Library is a community that provides an extensive library of Key Performance Indicators (KPIs).

Издание о метриках на русском

На русском языке вышла книга Питера Брукса "Метрики для управления ИТ-услугами" (в оригинале Metrics for IT Service Management). Книга заявлена как "практическое руководство по проектированию, созданию и использованию метрик и KPI в качестве механизма управления ИТ-услугами".
Скажу честно, я не очень понимаю, что именно автор подразумевал под "проектированием" и "созданием". Но пусть будет создание через запятую с проектированием. Книга для российской аудитории свежая, да еще с примерами ИТ-метрик. Нужно прочесть!

Прочел целиком, имею сказать следующее.

Вердикт – покупать и читать можно, но не обязательно.

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

Структурно книга разбита так – примерно треть о создании метрик, две трети отведено на примеры. Задумка хорошая, да подкачало наполнение. О концептуальных вещах автор пишет живенько. Из правильных, жизненных советов: для проектирования метрики необходимы четкие цели, для проектирования метрики соберите всех заинтересованных лиц, сделайте семинар принятия решений, не смотрите на софт – смотрите на потребности, т.е. на цель. Есть интересная, хотя и спорная главка о интеграции метрик. Однако целиком теория весьма пафосно описана. Есть мнение, что автор давно не проектировал метрики сам, ручками. Абсолютно не сделан акцент на процессе проектирования: не показана ясно связь между целями и итоговой метрикой, не описан процесс получения вариантов метрик от цели. Выбору границ метрик уделено всего ничего, а не помешало бы. Т.е. в представлении автора создание метрики выглядит так:
1) Определили цель (верно!)
2) Собрали заинтересованных лиц (аплодисменты!)
3) Черный ящик проектирования, выдающий метрику и стартовые границы (вообще ничего не написано, а на деле – самое интересное, что и должно быть в теории)
4) Передаем метрику в эксплуатацию.
5) Серый ящик эксплуатации (описано фрагментарно, а ведь это – соль!)

Дальше началось проектирование на примерах и тут книга перестала мне нравится. Навскидку совершенно крышесносящий пример метрики управления конфигурациями: "Число инцидентов, связанных с невыполненными изменениями из-за неправильно задокументированных конфигурационных элементов". Я не говорю о формулировке метрики, которую редкий технарь поймет на слух. Я не говорю уже о том, что только в идеальном мире три процесса внедрены и максимально интегрированы. Да любая связка из трех независимых показателей в одной метрике не будет работать никогда! (в реальном мире)
Оттуда же метрика "Число нарушений SLA, вызванных ошибками CMDB". Прямая цитата: "Хотя в большинстве случаев показатель, по видимому, будет равен нулю, его существование подчеркивает значимость SLA…" Как говорится, комментарии излишни. Отличный, отличный пример цели для метрик!
Ну и вполне логично, примеры метрик в приложениях не блещут – метрики из cobit, itil, и крайне небольшое число оригинальных метрик с понятными целями.

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