Нюансы менеджмента процессов на примере процесса «Управление инцидентами ИТ»⁠⁠

Фармацевтическая компания Fox-Meyer Drugs, стоившая порядка 40 миллиардов долларов, из-за неверного внедрения ERP системы обанкротилась и была продана конкурентам за 80 миллионов долларов. Банкротство произошло потому, что складская логистика компании не измерялась, не мониторилась, не была охвачена ни метриками, ни показателями, ни KPI. При внедрении ERP не заметили разрушение ключевых бизнес-процессов: склады оказались переполнены, клиенты не получали продукцию. В компании отслеживалась прибыль, но не были формализованы логистические бизнес-процессы, которые разрушились за несколько дней. Отсутствие управления—неприятный нюанс, присутствующий на всех предприятиях. Это нужно принять, как данность, вопрос критичности, в том, какие зоны предприятия неуправляемы.

Управление в наши дни опирается на KPI. Хорошая, сбалансированная система KPI, показателей и метрик— это цифровой двойник предприятия. Показатели и метрики должны опираться на процессы, иначе будет, как в Англии.

В Англии Министерство здравоохранения в целях сокращения времени ожидания в отделениях неотложной помощи решило наказывать больницы, где ждать приходилось больше четырех часов. Программа оказалась внешне успешной, но. На самом деле некоторые больницы стали держать поступающих пациентов за пределами своих стен в машинах скорой помощи, чтобы уложится в отведенные четыре часа(“Bevan and Hood, ‘What’s Measured Is What Matters”).

Здесь представлена типичная «гонка за KPI». Искажение данных—еще один неприятный нюанс, который так же присутствует на всех предприятиях, тоже неприятный нюанс. Но здесь есть ещё любопытный момент: KPI «времени ожидания лечения» оказался «подвешенным в воздухе», он не опирался на понятный и прозрачный процесс. Процесс определяет цели показателя, его контекст и факторы, влияющие на его фактическое значение. С моей точки зрения, показатель вне процесса скорее создаёт иллюзию управления, чем пользу. Показатели без управляемых процессов не являются источником оптимальных управленческих решений.

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

Начнем с моделирования.

Менеджмент процессов организует управление с учётом организационных противоречий, существующих в организации. Моделирование процессов—это часть процессного менеджмента. Разработаем упрощённую модель управления с учётом вышесказанного, чтобы приоткрыть завесу и показать как. Чтобы ответить на вопрос: "Может ли обычный руководитель управлять процессами?"

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

В ИТ есть показатель MTTA(Mean Time To Acknowledge), среднее время подтверждения и взятия инцидента в работу после возникновения первых симптомов сбоя. Очевидны параллели между MTTA и «временем ожидания лечения» из «английского» примера. Есть масса способов манипуляций с MTTA (знаю не менее десяти). Искажение информации здесь базируется на сокрытии первых симптомов неработоспособности путём искажения классификации: обращения пользователя о неработоспособности могут оформляться, как просьба о консультации. Предупреждения системы мониторинга о медленной загрузке страницы могут закрываться, как ложные. Информация о симптомах может «теряться» из отчётности...

В ИТ есть ещё один показатель: MTTR(Mean Time To Repair). Здесь под R может скрываться четыре слова с разными смыслами и способами измерения: решение(repair),реагирование(respond), устранение(resolve) или восстановление(recovery). Не спрашивайте почему так—сам «в шоке». Нам подойдёт repair. Напишу несколько строк о манипуляциях с этим показателем.

Пусть целевое значение показателя MTTR—58 минут, а фактическое значение 65минут после пяти сбоев. Встанем на место руководителя отдела администраторов, отвечающего за эксплуатацию ИТ-ресурсов. В его арсенале есть целый набор «нюансов», позволяющих «дезавуировать» нарушение целевого значения. Приведу несколько незамысловатых приёмов:

• Фальшивые сбои. Если у вас плохие показатели устранения инцидентов, вам достаточно быстренько перегрузить какой‑нибудь маловажный сервер. К примеру за 10 минут. После быстрого рестарта вы поправите себе показатель и получите премию вместо нагоняя. Проверим: (65+10)/6=12,5 минут. Вы‑действительно молодец!

• Деление длинного сбоя на несколько коротких. Пусть система А поставляет информацию системе Б. Сбой в функционале системы А вызывает сбой в системе Б. Восстановление работоспособности Б требует последовательного восстановления системы А(42 минуты) и системы Б(47 минут).Суммарное время такого восстановления 89 минут. Целевой показатель MTTR в 58 минут нарушен(89/1=89). Однако, если считать MTTR, как время восстановления двух систем по отдельности, то получится хорошо (89/2=44,5). Вы снова молодец, с точки зрения показателей в этом случае.

• «Досрочное» устранения инцидента. В погоне за KPI, можно рискнуть и сказать, что инцидент устранён, не проверив работоспособности и даже не дождавшись полного восстановления ИТ‑услуги. Пусть сервер перегрузили, он восстановил работоспособность, а система на сервере ещё не развернулась или не обработаны накопившиеся очереди сообщений. В этом случае, вы не соврёте, если скажете, что работоспособность восстановлена, несмотря на недоступность сервиса у пользователей.

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

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

Первичная модель строится на основании опыта разработчика, с учётом мнения экспертов. Это набросок и эскиз будущей картины.

Рассмотрим процесс «Управление инцидентами», описывающий технологию устранения сбоев в ИТ. Цель процесса: минимизация негативного влияния инцидентов на бизнес заказчика. Чаше всего минимизация негативного влияния сводится к минимизации времени устранения. Схематично и очень укрупнено процесс выглядит примерно так:

Моделирование управления начинается с наброска с жизненным циклом процесса.

Рекомендую рисовать для себя, можно на листочке, карандашом и криво—помогает в управлении и объяснении. Детализировав до того уровня, на котором управление возможно и оправданно. После этого можно расставлять KPI, показатели и метрики. Здесь мы видим, что минимизировать время устранения инцидента(MTTR) возможно следующими способами:

1. Сокращение времени взятия инцидента в работу

2. Сокращение времени поиска способа решения инцидента

3. Применения оптимального, заранее проработанного «обходного решения»

Эти три момента кто-то должен контролировать. Так, как инциденты—это операционный уровень, то и управлять процессом должен операционный директор ИТ или сотрудник с его ролью. Введём метрики MTTA, метрику «оперативность поиска решения» и показатель MTTR. Мы прекрасно помним, что показатели могут быть искажены, мы понимаем, что аномальные отклонения показателей требуют расследования и анализа, поиска решений. Отдадим эту роль аналитику, которыми обзавелись почти все предприятия подряд. Рекомендую закреплять за аналитиком контроль качества данных. С учётом сказанного, процесс «Управление инцидентами» схематично будет выглядеть так:

Обходное решение (workaround) – уменьшение или устранение влияния инцидента или проблемы, для которых в текущий момент недоступно полное разрешение.

Применение обходных решений — это наиважнейший инструмент повышения надёжности ИТ-инфраструктуры. Но он же и наисложнейший.

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

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

Модель разработана.

Что даёт нам данный процесс и зачем тратить деньги? Процесс даёт следующее:

• Возможность управлять планированием решения инцидентов с помощью обходных решений.

• Возможность контролировать время диагностики и поиска решений, которое должно стремиться к нулю.

• Возможность контролировать время реакции на инциденты.

• Возможность точнее регулировать SLA устранения сбоев

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

• Можно доминировать над ИТ‑шникамии раз в неделю орать на них, к примеру о том, что не стоит часами перегружать сервера, когда сеть не работает.

Мы разработали модель управления инцидентами—ура! Следующий этап управления процессом—организовать исполнение этого процесса.

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

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

P.S. Менеджмент процессов — это нехитрая наука, которой может овладеть любой хороший руководитель. Можно даже полюбить это дело. Если влюбитесь и на месяц погрузитесь в интернет по этой теме, то вы вы сможете дать фору любому консультанту с самым звонким и даже зарубежным сертификатом.