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

Output и Outcome в ITIL4

Опубликовано 17 апреля
Рубрики: ITIL
Комментарии

Сегодня мы разберём ещё одну ошибку, которую очень легко допустить при освоении ITIL. Эта ошибка — путать Output и Outcome.

На русском языке чуть проще: мы специально разделяем эти 2 термина. Output переводим, как выход, а Outcome — как результат. Но ITIL не издают на русском, а Google Translate упорно переводит оба термина, как результат. Да и в простой речи мы постоянно путаемся с непривычки.

Сейчас мы попробуем разобраться в этом:

  • Найдём различия между Output и Outcome
  • Рассмотрим на примерах из жизни и из IT
  • Научимся правильно произносить слово «торт»

 

Чтобы правильно понять контекст, давайте начнем с простого примера, не связанного с IT. Представим, что у вашего младшего брата пятый день рождения. Вы идете в местную пекарню или булочную и заказываете торт с человеком-пауком к утру праздника. Что будет являться результатом – outcome-ом этой операции?

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

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

 

Определение выхода и результата

Если говорить на языке Service Management, то вот как мы можем определить разницу между Output и Outcome.

Outcome — то, что потребитель услуги хочет получить.

Output — это действия/элементы, которые способствуют достижению outcome-а.

 

  • Потребитель хочет быстро доехать (outcome) — поставщик услуг такси предлагает ему спортивный автомобиль (output)
  • Потребитель хочет правильно питаться и совсем не готовить — поставщик услуг предлагает ему доставку готовой еды каждый день
  • Потребителю нужна помощь в продаже квартиры — поставщик услуг, риелтор забирает все хлопоты и задачи за скромный процент.

 

Outcome — результат — всегда находится на стороне потребителя,

Output — выход — всегда находится на стороне поставщика

Для того, чтобы получить Outcome потребуется Output и, зачастую, какие-то действия на стороне потребителя. Ту же компанию счастливых детей мы не получим, если не заберём торт и не накроем стол.

 

Если вернуть в мир IT, то результаты(Outcome) обычно представляют собой выгоду, которую получают наши клиенты от предоставляемых технологических решений. И для того, чтобы двигаться к достижению результатов, нам необходимо по-настоящему понять потребности своих клиентов. С какими проблемами они сталкиваются? Какие проблемы, ограничения и приоритеты важны для них?

 

Зачем нужны 2 разных термина

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

Те из управленцев, кто чувствует разницу, на практике используют специальные механизмы компенсации; например: давайте думать не про формальные результаты проекта, а про их использование, давайте «пропишем» не только проверяемые критерии качества услуги, но и её «полезность» для потребителя.

 

Разница между выходом и результатом

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

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

 

Связь выхода и результата

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

 

Эффект арбуза

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

 

Подведем итоги

Таким образом путаница между двумя похожими терминами — это нормальное следствие изменения мышления. Если раньше у нас были абстрактные результаты, которые могли быть как на стороне поставщика, так и на стороне потребителя, то сейчас мы чётко разделили. У поставщика — output, у потребителя — outcome. А цель output-a — в том, чтобы потребители могли достичь своего outcome-а. Проверьте свои действия с помощью новой категории. Что вы создаете с помощью ИТ-услуг, которые предоставляете: Вы покупаете торт, ставите его на стол и каждому кладёте по кусочку или собираете полную комнату счастливых детей?

Посмотреть видео 

 

ITIL 4 Foundation, MPT, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от участников разработки

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

Ваш адрес email не будет опубликован.

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Внедрение ИИ для вашей службы поддержкиВнедрение ИИ для вашей службы поддержки
      Но что на самом деле означает внедрение ИИ для возможностей ITSM вашей организации, особенно для службы технической поддержки?
    • Бесплатная конференция IT-Entrance для тех, кто хочет стать айтишниками
        28 мая в Минске пройдет бесплатная 11-я международная конференция IT-Entrance. Это мероприятие для тех, кто хочет попасть в IT, для начинающих IT-специалистов уровня junior с
    • ITIL 4 Specialist: High-velocity IT. Что внутри?
      В дополнение к уже опубликованным обзорам курсов по направлению Managing Professional (MP) сертификационной линейки ITIL4, сегодня мы рассмотрим еще один модуль – ITIL 4 Specialist: High-velocity IT (HVIT).
    • Весення уборка в бэклоге продукта: порядок за четыре шага!
      Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы. 
    • Warranty и Utility в ITIL4
      У услуг, которыми мы управляем в рамках Service есть две основные характеристики: гарантия — Warranty и Utility — полезность. Эти характеристики нужны нам, чтобы определить, будет ли услуга способствовать достижению результатов, которые нужны пользователю, а как следствие — создавать для них ценность.
    • Шесть практик для лучшего взаимодействия бизнеса и ИТ
      Хотели бы вы, чтобы руководители предприятий и ИТ могли лучше работать вместе, совместно работать над проектами и в полной мере обмениваться информацией? Если вы похожи на большинство ИТ-руководителей, ответ — да. Преимущества эффективного сотрудничества между бизнесом и ИТ включают в себя специальные проекты, которые лучше соответствуют бизнес-целям, улучшенное управление изменениями и более активное участие в новых инициативах.
    • Используйте технологии для повышения эффективности рабочего процесса вашей ИТ-команды
      Эффективное рабочее место создает, так сказать, хорошо смазанную машину, повышая итоговую прибыль и, как следствие, успех вашего бизнеса. Дополнительное время на работе не всегда означает большее достижение. Важно то, что вы делаете с тем временем, которое у вас есть, а это все об эффективности рабочего процесса.
    • Хранение данных и «внутренний хомяк»
      Хранение информации, которая больше не пригодится, сопряжено со огромным количеством рисков. Иллюстрация этому — череда сливов персональных данных пользователей крупных сервисов, которую мы могли наблюдать с января по март. Кажется, что предприятиям нужны правила, когда и как избавляться от данных.
    • Action BiasAction Bias — известная ловушка, в которую мы всё равно постоянно попадаем
      Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.
    • бэклог27 антипаттернов бэклога продукта
      Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT