Граница между постоянным совершенствованием и управлением проблемами

Вопрос о том, имеет ли смысл включать проактивное управление проблемами как отдельную процедуру в процесс управления проблемами (problem management, PRB), или это отдельный процесс, отличающийся по своей природе от реактивной составляющей управления проблемами обсуждался уже неоднократно. Также затрагивался и вопрос взаимоотношения процесса управления проблемами с практикой постоянного совершенствования (continual service improvement, CSI). Интересные заметки по данной теме (и ещё более интересные обсуждения в комментариях к ним) можно посмотреть, например, здесь и здесь, а также в комментариях к этой заметке

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

Некоторые считают, что процесс управления проблемами и процесс совершенствования – это одно и то же. Действительно, устранение проблем и тем самым минимизация негативного влияния на бизнес (в том числе влияния потенциального, если речь идёт о проактивной работе управления проблемами) происходит за счёт устранения ошибок (технических, организационных). А это ведь и есть совершенствование (технологий, организации и в конечном счёте услуг).

Но давайте попробуем самостоятельно найти самое главное в том, что эти практики различает. То, что наполняет смыслом выделение отдельных процессов (а вдруг он есть 🙂 ).

Модель №1

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

Кстати, аналогичная картина с риск-анализом. В рамках процесса управления проблемами (особенно если мы говорим про так называемую проактивную составляющую управления проблемами) производится выявление и оценка рисков. Например, для приоритизации проблем.

Также ключевые компоненты управления рисками (идентификация возможных событий, оценка вероятности их наступления и степени влияния, контроль реестра событий и актуальных оценок) реализуются и, например, в процессах управления доступностью, мощностями (и, вообще, во всех «гарантийных» [warranty] процессах).

Аналогично и совершенствование (CSI). Подходы, описанные в одноимённой книге ITIL, используются для совершенствования услуг, процессов (любых), функций. Т.е. эта практика встраивается во все области деятельности, во все процессы. Является одной из основных составляющих деятельности менеджера. Именно так фаза CSI и изображена на картинке из ITIL – область, опоясывающая жизненный цикл услуги, состоящий из четырёх основных фаз (стратегия, проектирование, преобразование, эксплуатация).
Таким образом CSI – это некая основа или инструмент, который используется много где. В частности, и процессе управления проблемами.

Модель №2

В жизни граница между CSI и PRB может проходить не между различными видами деятельности, а между различными уровнями, на которых эти виды деятельности выполняются. Т.е. CSI будет в этом случае неким общекорпоративным (охватывающим всю организацию поставщика услуг [например, весь ИТ-департамент]) problem management-ом. Процессом/практикой, которая позволит вовлечь различные функции и людей в работу по совершенствованию. В крупных организациях этим занимается выделенная структура. Что-нибудь вроде отдел качества или управление методологии. А процесс управления проблемами, как это чаще всего бывает, будет практикой, в рамках которой мы боремся исключительно с техническими ошибками.

Этак картинка, хоть и не столь изящна, кажется мне довольно жизненной. В большинстве организаций, наверняка, понадобятся различные организационные изменения для запуска условного problem management на разных уровнях: работа по исправлению чисто технических ошибок (в том числе как помощь процессу управления инцидентами) и работа по совершенствованию процессов в рамках ИТ-департамента.

Более того, в таком случае на начальных этапах вопрос границы CSI-PRB не имеет практического смысла, т.к. по задачам, которые в рамках каждого процесса будут решаться, пересечение маловероятно. Кроме того, эти практики, скорее всего, появятся не одновременно. Например, в ситуации, когда в организации только запускается процесс управления проблемами, он вряд ли будет сразу охватывать и организационные проблемы. Скорее всего, это будет что-то очень ИТ-шное, выстраивающееся вокруг процесса управления инцидентами. И, наоборот, после запуска широкомасштабного механизма CSI, затрагивающего, например, всю организацию поставщика ИТ-услуг (весь ИТ-департамент) до технических проблем могут добраться нескоро.

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


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

Или, как говорилось в первой части, стоит рассматривать CSI как некую мета-практику. Процесс-методолог, который обеспечивает единые подходы к управлению качеством, используемые везде (равно как и практика риск-анализа). В том числе в процессе управления проблемами. Тогда эти практики, находясь в разных плоскостях, пересекаются.

Т.е., как ни трактуй понятия, предлагаемые библиотекой ITIL, похоже, нам понадобятся обе сущности. И практика постоянного совершенствования и практика управления проблемами.

А как видите вы?
Какое направление мысли симпатичнее вам?

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Сергей Семикин

    Мне больше первая модель нравится. PRB воспринимается больше, как частный более узкий, а поэтому и более подробно описаный случай CSI. Область к его применения ограничена уже переданным в эксплуатацию услугам (или системам, или объектам) с выходом на изменения. CSI же больше по совершение самих процессов/ыункций, в том числе и самого PRB.

    1. Игорь Гутник Автор

      Сергей, спасибо!

      Правильно ли я понял, что позиционируете PRB как исключительно «технический»? (так он чаще всего и трактуется)

      Как на счёт того, что возникновение повторяющихся инцидентов обусловлено специфичной последовательностью выполнения операций (неважно, операций потребления или операций предоставления)? Как в этом случае будет выглядеть взаимодействие этих практик? PRB, разбираясь с такой проблемой, запустит работу в CSI, чтобы оптимизировать инструкцию по использованию/эксплуатации? Или сами в PRB регламент/инструкцию поправят?

      Я не то, чтобы выбрал роль «адвокат дьявола». Исключительно, чтобы максимально точно обозначить позицию. Правильного ответа, думаю, здесь нет. Но, кто, что думает, хотелось бы разобраться детальнее.

      1. Сергей

        В случае если при анализе очередной проблемы вылезет причина не в самой услуге, а в алгоритме ее потребления, то уйдет запрос в контроль системы качества процессов потребителя. Но после анализа его вполне может прилететь и RFC на доработку услуги.

        Описываемая практика точно применима к внутреннему ИТ, область полномочий которого ИТ-услуги/инфраструктура/системы. Если это будет внешний клиент или внутренняя поставка результатов, то скорее всего, меняться/подстраиваться будет услуга за счёт добавления «защит от дурака» и «доп контролем результатов операций».

        Пока писал появилась мысль (или просто вспомнилась услышанная ранее): есть еще одно различие PRB и CSI — скорость процесса. PRB воспринимается, как более быстрый. Меньше операций, более простые объекты анализа. CSI же имеет (могу ошибаться) более длинный цикл принятия решения и его утверждения.

        1. Игорь Гутник Автор

          Ага. Понятно. Спасибо за подробное разъяснение!

          Т.е. получается действительно граница — по областям ответственности (PRB — за услуги в «технической» части, CSI — за всё остальное, включая потребление)

          По третьему абзацу не очень понятно.

          Похоже, это как с восприятием деления процессов управления инцидентами (INC) и управления проблемами (PRB). PRB нередко воспринимается как «медленный INC» (об этом говорилось явно и в упомянутой в заметке публикации)

          Наверное, трудно спорить с тем, что в большинстве случаев среднее время решения проблемы больше среднего времени решения инцидентов. Возможно, и среднее время «улучшений» больше среднего времени решения проблем.

          Но вряд ли это получится использовать для деления работ между этими двумя практиками. Т.е. даже если, например, использовать описанную Вами логику деления PRB/CSI, мы ведь не будем передавать в CSI решение технической проблемы только потому, что понимаем, что её долго решать. Или будем?

          Иными словами, разница во временнЫх масштабах в этих практиках, если она и есть, есть следствие того, как эти практики устроены и чем занимаются, или определяя, кто (CSI/PRB) заниматься задачей, мы исходим из оценки сложности и сроков?

          1. Сергей Семикин

            Игорь, сначала «по третьему обзацу»: более долгие сроки в CSI это все таки следствие особенностей алгоритмов процедур и объектов, с которыми работает процесс.

            По границам же, мне вполне нравится предлагаемая в ITIL цепочка:

            INC получает на вход события и обращения от пользователей/заказчиков о прерывании или деградации качества услуг или CI и пытается устранить последствия. На выходе же даёт временное или долгосрочное восстановление объекта инцидента (услуга/CI). Области внимания и влияния процесса только технические.

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

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

  2. Сергей

    Доброго дня.

    Я за однозначное разделение.

    Совершенствование загнанное в рамки «проблем» — слишком узко.

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

    Т.е. явно отделяли совершенствование от проблема для повышения эффективности обоих процессов.

    1. Игорь Гутник Автор

      Сергей, спасибо!

      Интересно. Но вопрос с границей. Вроде бы всё равно остаётся. Оптимизация ведь – это устранение «непотимальности». Т.е. что-то в наших услугах, конфигурационных единицах, процессах, функциях устроено не так, как могло бы. Эта самая «неоптимальность» есть свойство вышеописанных сущностей (или свойство их комбинации). Причём в некоторых случаях эта непотимальность может приводить к сбоям (например, более частые ошибки персонала при выполнении каких-нибудь штатных операций из-за того, что регламент сложный и запутанный, и ли инструментарий «кривой» и ненадёжный). И тогда, мы будем сталкиваться с повторяющимися инцидентами, которые, при определённом накоплении будут исследованы в рамках PRB.

      Или, например, эта же неоптимальность не приводит к сбоям. Но, проанализировав статистические данные (мониторинг, жалобы пользователей, жалобы ИТ0-специалистов и т.п.) мы в рамках PRB, разумеется, в его проактивной части будем разбираться с причинами выявленных нами трендов.

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

      Как в Вашей практике разводили эти вещи?

      Как, увидев какую-то негативную тенденцию или какое-то узкое место (в инфраструктуре или в процессах), принять решение, кто займётся оптимизацией (PRB или CSI)?

      1. Сергей

        Если выявляет проблем (а он только с инцидентов выявляет) — решает проблем.

        Если выявляет оптимизация — решает оптимизация (у проблема или других процессов может запросить инфу\подключить их — но решает (несёт ответственность) она)

        1. Игорь Гутник Автор

          Сергей, спасибо!

          Понятное деление по триггерам. Одно уточнение. Запуск работ в PRB по инцидентам ведь тоже может быть по-разному устроен. От «не смогли связать инцидент с уже зарегистрированными проблемами» до «анализируем данные по зарегистрированным инцидентам и, выявив тренд, идентифицируем новую проблему». Как у было у Вас?

          Интересно, а проактивная составляющая PRB есть? Или всё, что касается анализа, направленного на предупреждение – это совершенствование?

          1. Сергей

            Доброго, всё верно предположили.

            Проблем работал с имеющимися инцидентами — активно.

            Если успевал проактивно отработать — молодец, но в KPI процесса не выводили проактивный поиск причин.

            Остальное совершенствование (включая проактивный PRB) — его (CSI) не ограничивали в методах, способах и указках где и что именно совершенствовать и именно здесь работали наиболее творческие личности 🙂

    1. Игорь Гутник Автор

      Верно. И несовершенство процесса, то самое несовершенство, которым занимается CSI, может являться причиной инцидентов. Той самой причиной, поиском и устранением которой обычно занимается... 🙂

      1. Андрей другой

        В контексте нынешней моды на всякого рода KPI (надеюсь Дмитрий нас не слышит :)) CSI очень быстро превращается в улучшения ради улучшений и становится Problem Generation. Хотя, Problem Generation тоже, в каком то смысле, Problem Management.

  3. Антон

    CSI и PRB не то, что не равны, на мой взгляд, это сущности разных измерений. Не любой объект приложения CSI является проблемой (хотя в частном случае — может). Я бы все-таки рассматривал CSI как некую метапождход, который может (и должен) быть интегрирован во все процессы. В т.ч. — в PRB. С другой стороны, на определенных этапах работы глобального CSI может происходить инициация PRB. Как-то так.

    1. Игорь Гутник Автор

      Антон, спасибо за дополнение!

      Мне лично очень близка эта модель.

      Но это модель. А если мы попытаемся приземлить это на всё на практику, то, насколько я понимаю, вопросы остаются.

      В какой конкретно практике должны обрабатываться те или иные задачи?

      Представим себе, что у нас есть какой-то набор идей/инициатив/проблем/задач, которые можно в общем описать «нужно поразбираться». С какими из них будет разбираться CSI, а с какими PRB?

      Примерами ответов на этот вопрос могут быть уже озвученные:

      1. Кто обнаружил, тот и занимается

      2. Если это задача возникла из анализа инцидентов, И при этом связана с технической частью, то ими занимается PRB. С остальными — CSI.

      Как аналогичное чёткое правило разделения вывести из описанной модели?

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

СЕН
27
ОКТ
1