Среди управленцев становится модным проблем-менеджмент(Problem manadement) или проблемно-ориентированное управление. Трактовка проблем-менеджмента разнится от толкователя к толкователю. Поделюсь своими взглядами. Проблем- менеджмент лучше внедрять сверху. Верхи оперируют отчётностью, которая описывает состояние ИТ- предприятия. Совершенно логично начать рассуждения с формирования проблемно-ориентированной отчётности.
На многих ИТ-предприятиях отчётность состоит из показателей и метрик. Столкнувшись с с показателями и метриками в первый раз, я предположил, что их важность преувеличена. Однако вскоре отогнал эту мысль, решив, что многого не понимаю в управлении. Сейчас, проработав с моделированием инструментов управления ИТ много лет, я до сих считаю, что отчётность, ограниченная показателями и метриками не несёт большого смысла.
Представьте, что вы директор по ИТ или CIO. Типовая отчётность о состоянии ИТ-услуг и ИТ-инфраструктуры в показателях выглядит примерно так:
Сценарий управления на основе данной отчётности таков : Похвалить за положительную динамику, заслушать оправдания отрицательной динамики, пожурить и заслушать обещания.
Управление, основанное на подобной отчётности, незатейливо и бесполезно—директор во время совещаний может пить кофе или чатиться с красавицей. Или просто сидеть с важным и строгим видом. Отчётность показывает нам «красные зоны», но этого недостаточно для управления. Управление, основанное на такой отчётности, акцентируется скорее на административных мерах, чем на работе с решениями реальных проблем ИТ. Важно заметить, что административные подходы в управлении ИТ почти всегда исключают участие в управлении админов, разработчиков и экспертов. Пусть основные причины просадки показателей нашей отчётности кроются в низком качестве ERP-систем и типовой проблематике работы с большими данными PostgreSQL.
Проблемно-ориентированная отчётность, ставящая во главу угла противоречие или проблему(организационную, техническую, сервисную и т.п.) приносит больший эффект, чем административно-показательная, приведённая выше.
В нашем случае, для проблемно-ориентированного управления требуются детали «из первых рук», от админов, программистов и экспертов. От качества этих данных зависит оперативность выравнивания показателей. Многие руководители, получают карьерные неприятности, по причине того, что не умеют «в детали». Учёные в общих чертах обрисовали работу с проблематикой показателей, но практик, с моей точки зрения, явно недостаточно.
Перед тем, как рассматривать формат проблемно-ориентированной отчётности, пару предложений про теорию разработки управленческих решений. Проблем- менеджмент—это про то, какие проблемы были, какие проблемы есть и какие проблемы будут. Жизненный цикл управленческого решения(далее ЖЦ УР) в области ИТ можно представить в следующем виде.
Хорошая отчётность описывает все этапы ЖЦ УР. Пройдёмся по ним.
Показатели и метрики, из которых обычно состоит административно-показательная отчётность, справляются только с описанием текущей ситуации, динамики показателей и трендов. Такая отчётность помогает подсветить проблемные зоны управления. Предыдущая таблица с показателями показывает «красные зоны» предоставления ИТ-услуг и состояния ИТ-инфраструктуры. Очень хорошо, если к табличкам с показателями, будет прилагаться матрица рисков предоставления ИТ-услуг примерно такого вида.
Ситуация, когда отклонения показателей от целевых значений не анализируются с точки зрения рисков — это довольно распространённое в управлении явление. Рассуждая об отчётности, нужно заметить, что хороший анализ риска невозможен без участия админа, разработчика, эксперта и т.п. Анализ риска включает в себя оценку факторов риска, которые являются причинами сбоя или инцидента. Иными словами, фактор риска—это проблема ИТ (не устранённая причина инцидента © ITIL). В отчётность о состоянии ИТ необходимо добавлять информацию о проблемах ИТ в соответствии с жизненным циклом проблемы. Жизненный цикл проблемы очень похож на жизненный цикл управленческого решения(управленческое решение начинается с проблемы). Решение проблемы, по большому счёту, это и есть управление. Сравните:
Жизненный цикл пробелемы
При хорошо организованном менеджменте процессов, управлении проблемами осуществляет эксперт, администратор или разработчик. Это значит, что эксперт, администратор или разработчик становятся ключевыми участниками управления ИТ. Руководитель участвует в процессе только для решения экстраординарных, не стандартизированных, эскалированных проблем. Такой подход рождает следующую проблему: чаще всего, эксперт, администратор или разработчик не умеют «в риски ИТ». Вообще, хорошо «в риски ИТ» мало кто умеет, потому, что это сложно, непонятно и требует абстрактного мышления.
Вспомним, основные причины просадки показателей нашей отчётности кроются в низком качестве ERP-систем и типовой проблематике работы с большими данными PostgreSQL.
Работа с рисками ИТ включает в себя две задачи: оценка вероятности возникновения сбоя и оценка критичности последствий сбоя для предоставления ИТ-услуг проводится на основании совместного опыта разработчика и администратора, «вручную». Вместе с тем, можно приоткрыть завесу над этой весьма таинственной областью. Встречался с тем, что оценка вероятности рисков проводилась на основании предыдущих состояний, без участия администраторов и разработчиков— это пример формального подхода и гонка за модными тенденциями в управлении.
Добавим в отчёт следующую табличку:
Данные, содержащиеся в таблице, помогут вам, как ИТ-директору, увидеть следующие детали матрицы рисков:
факторы рисков/причины проблем
стоимость проблем в сбоях, произошедших на ИТ-инфраструктуре
влияние проблем на пользователей
фазу на которой находится решения проблемы
фазу изменений, устраняющих корневую причину инцидентов
критичность и вероятность реализации рисков (рецидива инцидентов)
срок минимизации или устранения риска
Безусловно, для оценки рисков нужно много больше данных, однако вам, как ИТ-директору будет приятно видеть какое-то измеримое объяснение матрицы рисков и в таком виде.
Тут хочется заметить следующие важные моменты: корневые причины или факторы рисков должны предопределять понятную и конкретную цепочку действий, которая ведёт к устранению или минимизации фактора риска. К примеру, если вы видите, что корневая причина связана с неработоспособностью PostgreSQL на больших объёмах данных, то нужно попробовать настроить параметр huge pages. Корневая причина должна быть понятна и ИТ-директору и администратору с разработчиком, она должна быть устраняема (это мега важно!). Неправильно, если корневая причина имеет общее название, типа «некачественное ПО», «ошибка проектирования». Справочники корневых причин, состоящие из не устраняемых факторов рисков — довольно распространённое явление и является следствием менеджеризма, процветавшего в нулевых.
Любая приличная отчётность содержит информацию об изменениях/проектах, часто в виде диаграммы Ганта. Пусть сегодня второй квартал 2024 года. Простенький пример диаграммы Ганта показывает ход реализации проектов.
Данная диаграмма демонстрирует «административный» подход к контролю реализации проектов. Добавим в неё несколько колонок и она станет проблемно-ониентированной.
Описание проблем, которые сопровождают внедрение, повышает эффективность и результативность. Вовлечение в регистрацию проблем админов, разработчиков и экспертов, повышает достоверность информации. Обратите внимание на услугу «ERP-персонал»: мы видим типовую ситуацию, когда в эксплуатацию принята проблемная информационная система. В таком случае, полезно контролировать её до решения проблем, уже на стадии эксплуатации. С помощью дополнительных TimeLine(красненькие) мы видим запланированные сроки решения проблем. Вторая, расширенная диаграмма Ганта несёт существенно больше информации для управления.
Если приглядеться к представленным примерам проблемно-ориентированной отчётности, то мы можем убедиться, что все этапы ЖЦ управленческого решения оказались под контролем(инициация, проетирование, реализация, переосмысление).