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

Золотая середина

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

Трудно дозвониться до первой линии – плохо, легко дозвониться, но не помогают сразу, а говорят, что разберутся и перезвонят – тоже плохо.  Что делать бедным менеджерам в условиях ограниченности ресурсов? 

В одном из проектов решали такую задачку. Есть две метрики: "Доступность первой линии" и "Количество обращений пользователей решенных на первой линии". Понятно, что улучшение показателей по первой метрике, с учетом ограниченности ресурсов, ведет к ухудшению показателей по второй метрике. В терминах ITIL V3, это Tension Metrics (в русском глоссарии Сопряженные метрики). В итоге волевым решением выбирали, что для нас более важно и насколько мы готовы ухудшить показатели второй метрики. Таким образом, получили приемлемое значение первой метрики, но при этом не гнались за идеальным значением, понимая, что это приведет к совершенно недопустимым значениям второй метрики. 

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

А вы что думаете? Может у кого есть еще интересные примеры?

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

  • Цена, сроки, качество? 🙂

    (извините за банальность)

    • Спасибо за банальность 🙂 Но это сильно высокоуровнево. Конечно можно и так смотреть, но пользы будет немного. Все равно придется спускаться ниже.

  • old fuddy-duddy

    «А вы что думаете?»
    А мы 😉 думаем, что инициируя проект по оптимизации управления ИТ, например, по методологии ITIL, в большинстве случаев нам хочется так выстроить процессы, чтобы обеспечить предоставление услуг требуемого уровня доступными ресурсами. Если же нам это не удалось и приходиться чем-то жертвовать, значит, проект не достиг своей цели, то есть провален.

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

      • old fuddy-duddy

        “И жизнь не стоит на месте, то что раньше было обеспечено ресурсами, сегодня уже захлебывается в звонках разросшейся партии пользователей”
        Объем предоставления услуги надо увязывать со стоимостью.

        • “Объем предоставления услуги надо увязывать со стоимостью.”

          Это полезно, если Вы имеете возможноть управления стоимостью. Отсюда вывод: такая увязка жизненно необходима не всегда, иногда без нее можно прожить.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM