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

Как потоки создания ценности могут помочь вам лучше делать свою работу

Опубликовано 20 октября 2019
Рубрики: ITIL, ITSM, Постоянное улучшение, Процессы
Комментарии

Люди, которые работают в сфере управления ИТ-услугами (IT service management, ITSM) тратят много времени на обдумывание и совершенствование своих процессов. И это хорошо. Но когда мы фокусируемся на процессах в ущерб всему остальному, мы проигрываем. В этом блоге я собираюсь объяснить, почему вам следует думать о том, что вы делаете, с точки зрения потоков создания ценности, а не процессов.

В чем разница между потоком создания ценности и процессом?

Существует путаница относительно разницы между потоками создания ценности и процессами. И это неудивительно, поскольку и потоки создания ценности, и процессы описывают, каким образом разные виды деятельности работают совместно, чтобы достичь какого-то результата. Итак, в чем же различие? Чтобы ответить на данный вопрос, для начала посмотрим на определения из ITIL 4.

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

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

Каждый процесс производит четко определенные результаты. Например, в ИТ-организации может быть реализован процесс авторизации изменений, который принимает запрос на изменение (Request for Change, RFC) в качестве входных данных, а в качестве выхода предоставляет официальное разрешение на реализацию изменения. Однако появление такого разрешения не влияет напрямую на создание ценности для заинтересованной стороны. Этот процесс создаёт ценность только тогда, когда является частью потока создания ценности.

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

Чтобы добиться значительных улучшений при минимальных рисках, следует улучшать поток создания ценности, а не только лишь отдельные процессы.

Приведу несколько примеров.

Поток создания ценности при изменении услуги

Этот пример основан на реальной ситуации, возникшей в крупной европейской финансовой организации. Заказчики и пользователи предъявляли множество жалоб на процесс управления изменениями. Согласно этим жалобам, процесс замедлял развёртывание нового программного обеспечения и в целом негативно влиял на гибкость всей компании. В ИТ-организации было принято решение о пересмотре подходов к управлению изменениями.

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

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

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

Результатом стала действительно впечатляющая трансформация управления изменениями. Ранее разработчики программного обеспечения вручную отправляли RFC, когда были готовы развернуть программное обеспечение. После чего выполнялись оценка и авторизация, что вызывало задержки. Если изменение отклонялось на данном этапе, возникала еще одна задержка, вызванная возвратом запроса на пересмотр и переработку.

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

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

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

Итак, что же такого они сделали, что это привело к впечатляющей трансформации? Они сотрудничали со всеми заинтересованными сторонами для обеспечения того, чтобы все были вовлечены, чтобы все потребности были удовлетворены, и чтобы каждый вносил свой вклад в создание сквозной ценности. Они санкционировали замену некоторых инструментов и обеспечили интеграцию всех инструментов для сокращения объема ручной работы. Они оптимизировали процессы, которые требовали улучшения, и обеспечили наличие у людей навыков и ресурсов, необходимых для успешного сотрудничества. Данный подход может показаться более сложным, чем оптимизация процесса. Но у него есть два больших преимущества. Люди с меньшей вероятностью будут сопротивляться изменениям, если они были тесно вовлечены в их подготовку и, следовательно, лучше понимают их необходимость. Это даёт отличные результаты.

Поток создания ценности для операционной деятельности

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

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

Чего не хватало, так это понимания сквозного потока создания ценности, а именно понимания последовательности действий, “преобразующей” сотрудника, поступающего на работу в компанию, в сотрудника, являющегося продуктивным членом команды. Выполнив анализ потока создания ценности, они обнаружили, что в нём должны участвовать различные части организации, а не только департамент ИТ. Для каждого нового сотрудника требовалось обеспечить:

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

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

Заключение

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

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

  • Фокусируйтесь на ценности: не думайте о своем процессе, подумайте о совместном создании ценности – совместно с потребителями услуг
  • Используйте целостный подход: оптимизируйте сквозной поток создания ценности, а не индивидуальный процесс
  • Сотрудничайте и поощряйте прозрачность: типичный поток создания ценности включает в себя множество различных команд и процессов; все должны работать вместе, чтобы обеспечить оптимизацию сквозного потока работы
  • Оптимизируйте и автоматизируйте: не просто автоматизируйте свой процесс; хорошая автоматизация учитывает сквозной поток создания ценности и обеспечивает получение каждым процессом получает входных сигналов

Я уверен, что эти организации могли бы также использовать и прочие руководящие принципы: Отталкивайтесь от текущей ситуации, Простота и практичность, Действуйте итерационно, используя обратную связь, – все они могут способствовать оптимизации потока создания ценности.

И, наконец, если вы раньше не задумывались о том, что вы делаете с точки зрения потоков создания ценности, то у вас есть отличная возможность улучшить то, что будет иметь реальное значение для ваших клиентов

Об авторе

Stuart Rance – консультант по ITSM и безопасности, работающий с клиентами по всему миру. Является одним из авторов ITIL 4. Также является преподавателем курсов по ITSM и управлению информационной безопасностью, а также участвует в разработке экзаменов.

Оригинал статьи

IT Service Management
Учебные курсы от соавторов ITIL 4

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

  • Андрей другой

    В удивительное время мы с вами живем товарищи!! Мы начинаем по-новой открывать для себя то, что уже было открыто десятилетия назад.Со временем и, я думаю, огромной помпезностью нам изложат принципы SADT и IDEFx. Нам расскажут про декомпозицию и т.д.
    Зачем нужны эвфемизмы (поток создания ценности) для обозначения простых и очевидных вещей(все на этом свете создается в результате процессов)? Зачем путать самих себя – “Типичный поток создания ценности включает в себя множество различных процессов, между которыми должно быть реализовано бесшовное взаимодействие”. Или может автор не достаточно образован и не слышал про процессы и подпроцессы, уровни декомпозиции?

    • Слава Бельков

      Андрей, это статья(и) из иностранной практики… Просто делите на 10… Там много чего узнали для себя нового, когда развалился союз и куча умов ушла туда… Эти умы то и научили этих умников правильным подходам. А мы теперь – повторенье мать ученья, только вид сбоку 🙂 Хотя и это тоже иногда бывает полезно для понимания… всего…

  • Алексей

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

    Меня бы за такой “хороший процесс управления запросами на обслуживание” давно бы уволили, если бы выдача длилась бы больше 8 рабочих часов, а здесь “всего за несколько дней”. Хорошо живут ИТ-шники в Великобритании. )))

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

  • Алексей

    Если вы переводите статью то, переводите правильно или не переводите если там фигня написана, иначе зачем забивать людям голову глупостями.
    Поток создания ценности не заканчивается на создании ценности, он заканчивается на том, что эта ценность попала к клиенту, заказчику этой ценности, и оправдывает его ожидания !!
    В общем статья так себе !!!

    • Алексей, Вы, вероятно, не потрудились прочесть оригинал статьи, иначе Вы бы не стали делать голословных заявлений про качество перевода.
      Также, похоже, Вы не поняли, что статья основана на ITIL 4. Сдаётся, что Вы не знакомы с данной публикацией. Это позволяет Вам выдавать собственные убеждения и слышанные где-то ранее лозунги за истину в последней инстанции. Что, конечно, выглядит забавно.
      Наконец, выдавая подобные комментарии, сначала подумайте – зачем? Чего Вы хотите добиться своим ядом?


Добавить комментарий для Андрей другойОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM