Портал №1 по управлению цифровыми
и информационными технологиями

Количество проблем в обработке

Опубликовано 12 июня 2014
Рубрики: ITIL, Практика и опыт, Управление проблемами
Комментарии

«Разрешите поинтересоваться в целях повышения образованности…»
Из м/ф «Зима в Простоквашино»

 

overloadЗадал мне недавно один клиент отличный вопрос. Не в бровь, а в глаз. Сколько проблем одновременно может эффективно обрабатывать координатор / менеджер?

Обсудили разные принципы определения такой границы  – число Миллера, Top 5-10. Но однозначного ответа, конечно, нет. А вопрос важен, поскольку бороться с меньшим числом проблем и побеждать гораздо лучше, чем тонуть в потоке проблем, не достигая результатов. Лучше и с моральной, и с экономической точек зрения. Вот и Kanban, например, одним из принципов провозглашает ограничения уровня максимальной загрузки (work-in-progress limit) и, как мне кажется, не зря. А некоторые мои знакомые применяют Kanban в том числе и к практике управления проблемами.

Посему вопрос к коллегам-практикам: какое максимальное число открытых проблем Вы можете обрабатывать параллельно? Или может быть вы считаете такое ограничение надуманным?

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление поддержкой ИТ-услуг
Строим эффективную ИТ-поддержку, оптимизируем существующую

Также по теме:

Комментариев: 10

  • Alexander Popov

    Alexander Popov

    Универсальное правило гласит: “Не более 2 дел одновременно!”
    Добавишь 3-е — потеряешь координацию.

    • Дмитрий Исайченко

      Александр, скажите, пожалуйста, значит ли это что Вы, как problem manager, ограничиваете число активно обрабатываемых проблем по 2 на сотрудника?

  • Евгений

    На мой взгляд проблему нужно решать исходя из фактора уровня влияния проблемы на бизнес. Если проблема одна – хорошо. В смысле плохо что проблема, хорошо что одна. Если проблем более двух, то опять же отталкиваться от критерия: уровень влияния на бизнес.

    • Дмитрий Исайченко

      Евгений, Ваш ответ безусловно логичен. Но, как мне кажется, это ответ на другой вопрос 🙂 Вы пишете о том, в каком порядке обрабатывать проблемы. Я же спрашиваю о том сколько проблем в состоянии параллельно / одновременно обрабатывать координатор проблем. И что делать с этим лимитом.

      Поясню. Предположим, у нас есть 10 проблем в некоторой проблемной области. А координатор проблем в этой предметной области в состоянии, предположим (!), работать с пятью проблемами. Да, можно проранжировать проблемы по степени влияния на бизнес. Но за сколько потом браться? Предположим у нас 1 критичная проблема, 3 важных и 5 – скажем так, не самых приоритетных. За сколько браться – за 1? За 4? За 5? (Каких?) За 10? (Зачем, если это непосильно?) Или у нас 2 критичных, 5 важных и 3 остальных. Опять же – сколько проблем запускать в обработку, ожидая от координатора своевременных действий (а своевременность по крайней мере диагностики – судя по всему оправданное понятие: http://www.realitsm.ru/2013/10/defining-problem-deadline/).

  • Дмитрий Исайченко

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

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

    То есть вопрос на самом деле немного сложнее, чем “сколько”, но и “почему” и “когда”.

    • Юрий Ерин

      На недавно прошедшей конференции ОСП-2014 Романа Журавлева попросили ответить, что считать маленьким ИТ-подразделением, сколько в нём сотрудников. Ответ Ромы мне понравился и звучал он примерно так: ИТ-организацию можно считать маленькой пока руководитель знает, чем конкретно занимается каждый сотрудник в то или иное время.

      Координатор проблем живой человек. Сколько он может “взять на себя” зависит от его способностей. Также, количество проблем, которыми он может эффективно управлять, зависит от объема выделяемого ему для этого времени, от объема работы, которую требуется выполнять в отведенное время.

      Поэтому, это зависит. В известной тебе организации менеджер процесса управлял примерно 5-ю десятками открытых проблем, находящихся в разных стадиях обработки. Координаторы там же управляли (на своем уровне) от 1 до 10. 

      Ты обозначил основные стадии. Виды деятельности, осуществляемые координатором на тех или иных стадиях, в целом известны. На основе этой информации и исходя из ограничений на выделяемое координатору время (координаторы, как правило, еще и в “полях” трудятся), можно примерно прикинуть, сколько проблем он может “тянуть” на тех или иных стадиях и в целом. При подсчете не забыть, что кооринатор не один задействован в этом процессе. Его затраты могут быть существенно ниже тех, кто задействован в расследовании, применении решений, контроле устранения и т.д.

    • Юрий Ерин

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

      • Дмитрий Исайченко

        Это разумеется, но хотелось бы примеров: такие-то координаторы, такая-то загрузка, столько-то проблем. Нужен ориентир, не обязательно точные цифры.

      • Роман Журавлёв

        …и для других участников других процессов тоже. Мне кажется, в итоге задача сводится к обычному ресурсному планированию, без какой-то особой специфики управления проблемами. 

        Или я неверно понял суть вопроса?

        • Дмитрий Исайченко

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

          Если речь про ресурсное планирование на год – да. Но если речь про оперативное взаимодействие, то как ты представляешь это на практике (тем более с учетом того, что ресурсы координатора проблем запрашивают, как правил смежники, которые ресурсы координатора не планировали)? Например, при планировании зафиксировали, что координатор проблем выделяет на диагностику 10% рабочего времени. Далее начинается диалог:

          – У нас тут еще одна проблема повилась. Берешь?

          – Не-а. В рамках моих 10% я продолжаю диагностировать одну проблему и на большее времени нет.

          Такая постановка абсолютно не стимулирует координатора обрабатывать больше / быстрее. Солдат спит, служба идет. Обратная ситуация – получи проблемы, не зависимо от загрузки – ведет в другой тупик (постоянному падению процессных KPI и полной потере заинтересованности координаторов).

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

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.