Люди, которые работают в сфере управления ИТ-услугами (IT service management, ITSM) тратят много времени на обдумывание и совершенствование своих процессов. И это хорошо. Но когда мы фокусируемся на процессах в ущерб всему остальному, мы проигрываем. В этом блоге я собираюсь объяснить, почему вам следует думать о том, что вы делаете, с точки зрения потоков создания ценности, а не процессов.
В чем разница между потоком создания ценности и процессом?
Существует путаница относительно разницы между потоками создания ценности и процессами. И это неудивительно, поскольку и потоки создания ценности, и процессы описывают, каким образом разные виды деятельности работают совместно, чтобы достичь какого-то результата. Итак, в чем же различие? Чтобы ответить на данный вопрос, для начала посмотрим на определения из ITIL 4.
Поток создания ценности — набор шагов, которые организация предпринимает для создания и предоставления продуктов и услуг потребителям.
Процесс — набор взаимосвязанных или взаимодействующих видов деятельности, которые преобразуют входы в выходы.
Каждый поток создания ценности начинается со спроса или возможности и заканчивается созданием ценности для одной или нескольких заинтересованных сторон. Например, спрос может заключаться в том, что от ИТ-организации ожидается создание новой услуги, которая будет помогать командам продаж лучше понять своих клиентов. Конечный результат (создаваемая ценность) будет заключаться в росте продаж вследствие возросшего понимания продавцами своих клиентов.
Каждый процесс производит четко определенные результаты. Например, в ИТ-организации может быть реализован процесс авторизации изменений, который принимает запрос на изменение (Request for Change, RFC) в качестве входных данных, а в качестве выхода предоставляет официальное разрешение на реализацию изменения. Однако появление такого разрешения не влияет напрямую на создание ценности для заинтересованной стороны. Этот процесс создаёт ценность только тогда, когда является частью потока создания ценности.
Типичный поток создания ценности включает в себя множество различных процессов, между которыми должно быть реализовано бесшовное взаимодействие. Очень легко представить, что, оптимизируя отдельные процессы, вы в целом совершенствуете свою систему управления. Однако на практике оптимизация отдельных процессов может привести к обратному результату, так как ваш «отдельно улучшенный» процесс может неожиданно для вас оказать негативное влияние на других сотрудников вашей организации. Если же вы оцениваете более широкую картину, вы сможете лучше понять, что действительно нуждается в улучшении и как это сделать таким образом, чтобы помочь всем.
Чтобы добиться значительных улучшений при минимальных рисках, следует улучшать поток создания ценности, а не только лишь отдельные процессы.
Приведу несколько примеров.
Поток создания ценности при изменении услуги
Этот пример основан на реальной ситуации, возникшей в крупной европейской финансовой организации. Заказчики и пользователи предъявляли множество жалоб на процесс управления изменениями. Согласно этим жалобам, процесс замедлял развёртывание нового программного обеспечения и в целом негативно влиял на гибкость всей компании. В ИТ-организации было принято решение о пересмотре подходов к управлению изменениями.
Обычно в подобных обстоятельствах я наблюдаю следующую картину: менеджер процесса совместно с коллегами погружается в поиск возможностей для оптимизации своего процесса с целью снижения накладных расходов.
Но эта организация пошла другим путём. Они поняли, что гораздо лучше рассмотреть весь поток создания ценности, а не просто сосредоточиться на одном процессе. Они назначили одного из старших ИТ-менеджеров ответственным за анализ и улучшение всего потока ценности, в рамках которого создаётся новая функциональность, необходимая бизнесу. Поток создания ценности начинался, когда клиент определял потребность в новой ИТ-функциональности, и заканчивался, когда новая функциональность успешно использовалась.
Это означало, что старший ИТ-менеджер не просто смотрел на процессы. В его задачу входил анализ того, что сейчас мы назвали бы четырьмя аспектами управления услугами — людей, процессов, технологий и поставщиков, — с целью оптимизации сквозного потока создания ценности и обеспечения его эффективности.
Результатом стала действительно впечатляющая трансформация управления изменениями. Ранее разработчики программного обеспечения вручную отправляли RFC, когда были готовы развернуть программное обеспечение. После чего выполнялись оценка и авторизация, что вызывало задержки. Если изменение отклонялось на данном этапе, возникала еще одна задержка, вызванная возвратом запроса на пересмотр и переработку.
Новый подход была направлен на оптимизацию потока создания ценности. Одним из аспектов улучшения явилось использование новых инструментов, которые автоматически формировали RFC, как только вся необходимая информация становилась доступна. Никто не должен был собирать эту информацию, чтобы создать RFC. Это происходило естественным образом в рамках предшествующих этапов потока создания ценности. В результате RFC формировались в достаточной степени заблаговременно, чтобы лицо, назначенное для их оценки, своевременно представило предложения, которые можно было бы легко включить в этап разработки и тестирования. Как следствие, изменения стали редко отклоняться, так как к моменту авторизации вовлечённые люди уже активно сотрудничали, чтобы преодолеть потенциальные трудности и произвести продукты и услуги, которые намного лучше удовлетворяют потребности клиента.
Очевидно, что в рамках трансформации было сделано много других улучшений в потоке создания ценности, но я надеюсь, что написал достаточно, чтобы продемонстрировать, что улучшение всего потока создания ценности намного лучше, чем улучшение одного процесса. Мы не можем позволить себе думать только о выходах (outputs) одной команды. Мы также должны думать о том, как вещи, которые мы все делаем, работают вместе, чтобы создать ценность.
В этом примере менеджер, который перепроектировал поток создания ценности, не отвечал за выполнение работы; он не был владельцем команды разработки программного обеспечения или команды управления изменениями.
Итак, что же такого они сделали, что это привело к впечатляющей трансформации? Они сотрудничали со всеми заинтересованными сторонами для обеспечения того, чтобы все были вовлечены, чтобы все потребности были удовлетворены, и чтобы каждый вносил свой вклад в создание сквозной ценности. Они санкционировали замену некоторых инструментов и обеспечили интеграцию всех инструментов для сокращения объема ручной работы. Они оптимизировали процессы, которые требовали улучшения, и обеспечили наличие у людей навыков и ресурсов, необходимых для успешного сотрудничества. Данный подход может показаться более сложным, чем оптимизация процесса. Но у него есть два больших преимущества. Люди с меньшей вероятностью будут сопротивляться изменениям, если они были тесно вовлечены в их подготовку и, следовательно, лучше понимают их необходимость. Это даёт отличные результаты.
Поток создания ценности для операционной деятельности
Источником следующего примера является медицинское учреждение в Великобритании. Руководство жаловалось, что процесс обеспечения нового сотрудника всем необходимым для эффективного выполнения им своей работы занимает слишком много времени.
В этой организации был налажен хороший процесс управления запросами на обслуживание. Если кому-то нужен был новый телефон, ноутбук, компьютер или учетная запись электронной почты, это решалось всего за несколько дней, хотя могли возникать задержки, если некоторые компоненты не были доступны.
Чего не хватало, так это понимания сквозного потока создания ценности, а именно понимания последовательности действий, «преобразующей» сотрудника, поступающего на работу в компанию, в сотрудника, являющегося продуктивным членом команды. Выполнив анализ потока создания ценности, они обнаружили, что в нём должны участвовать различные части организации, а не только департамент ИТ. Для каждого нового сотрудника требовалось обеспечить:
- выдачу пропуска для доступа в помещения организации
- ознакомление с правилами конфиденциальности, чтобы им можно было предоставить доступ к информации о пациентах, если это необходимо
- набор различных системных учетных записей и разрешений в зависимости от их должности и роли
- ноутбук или ПК, телефон и, возможно, письменный стол или другое офисное помещение.
Как только весь поток создания ценности был проанализирован, стало сразу видно, где находятся узкие места, и что нужно сделать, чтобы их устранить. Устройства можно было заказывать сразу же, как только становилась известна дата начала работы, не дожидаясь, пока сотрудник фактически её начнет. Обучение может быть запланировано на первый рабочий день. Учётные записи могут быть созданы заранее и активированы сразу же после прохождения обучения. Сделав несколько простых изменений, среднее и максимальное время, необходимое для обеспечения новых сотрудников всем необходимым, было значительно сокращено, и новые сотрудники стали приступать к работе намного быстрее.
Заключение
Процессы могут быть очень полезны, но оптимизация ваших процессов может не иметь никакого значения для ваших клиентов. Если вы действительно хотите помочь своим клиентам, то посмотрите на потоки создания ценности, частью которых вы являетесь, и спросите себя, что вы можете сделать, чтобы оптимизировать их.
Если вы знакомы с семью руководящими принципами ITIL, вы, возможно, заметили, как они способствовали успеху организаций в моих двух примерах. В приведённых примерах люди следовали этим принципам, чтобы оптимизировать два очень разных потока создания ценности:
- Фокусируйтесь на ценности: не думайте о своем процессе, подумайте о совместном создании ценности — совместно с потребителями услуг
- Используйте целостный подход: оптимизируйте сквозной поток создания ценности, а не индивидуальный процесс
- Сотрудничайте и поощряйте прозрачность: типичный поток создания ценности включает в себя множество различных команд и процессов; все должны работать вместе, чтобы обеспечить оптимизацию сквозного потока работы
- Оптимизируйте и автоматизируйте: не просто автоматизируйте свой процесс; хорошая автоматизация учитывает сквозной поток создания ценности и обеспечивает получение каждым процессом получает входных сигналов
Я уверен, что эти организации могли бы также использовать и прочие руководящие принципы: Отталкивайтесь от текущей ситуации, Простота и практичность, Действуйте итерационно, используя обратную связь, — все они могут способствовать оптимизации потока создания ценности.
И, наконец, если вы раньше не задумывались о том, что вы делаете с точки зрения потоков создания ценности, то у вас есть отличная возможность улучшить то, что будет иметь реальное значение для ваших клиентов
Об авторе
Stuart Rance — консультант по ITSM и безопасности, работающий с клиентами по всему миру. Является одним из авторов ITIL 4. Также является преподавателем курсов по ITSM и управлению информационной безопасностью, а также участвует в разработке экзаменов.
Facebook Twitter Linkedin emailТакже по теме:
- Не все First Call Resolutions (FCR) одинаково полезны
- Начинается новый сезон бесплатных вебинаров CleverTALK
- Повышение цен на книги Cleverics