«И того, и другого! И можно без хлеба.»
В.П., мультфильм «Винни-Пух и все-все-все»
В последней версии библиотеки ITIL появилось новое для ITIL понятие «поток создания ценности» (value stream). Понятие же «процесс» (process) присутствовало в библиотеке задолго до четвёртой версии.
Некоторые люди, входящие в мир управления ИТ-услугами через ITIL, испытывают сложности с разведением этих двух понятий. Иногда и люди, не являющиеся новичками, смешивают понятия «поток» и «процесс».
Но, если мы говорим о практическом применении этих понятий, то стоит договориться о том, где проходит граница (и зачем её проводить). Вот как выглядит моя картина мира.
В чём разница?
Определения, которые даются в книге «ITIL Foundation»:
Поток создания ценности
последовательность шагов, которые предпринимает организация для создания и предоставления продуктов и услуг потребителям.
Процесс
набор взаимосвязанных или взаимодействующих действий (видов деятельности), который преобразует входы в выходы. Процессы определяют последовательность действий (видов деятельности) и их зависимости.
Похожие определения двух этих терминов даются и в других источниках. И на первый взгляд различие вполне понятное. Процесс — это способ структурирования деятельности в той или иной области. Определение порядка выполнения работ, взаимодействия. Поток — это создание результата (в виде появления новой услуги и изменения каких-то характеристик существующей), ощутимого для потребителя. И, как следует из самой формулировки, видимо, обеспечивающего (поддерживающего) создание ценности (точнее, «совместное создание ценности», как мы помним из определения термина «услуга» в ITIL).
Итого, процесс — описание того, как работу работать, а поток — описание того, как создаётся ценность.
И в чём проблема?
То, что процесс, судя по определению, необязательно заканчивается чем-то, с чем непосредственно соприкасается потребитель (продукта или услуги) не даёт чёткого критерия, на основе которого можно различать потоки и процессы. Ведь определение и не запрещает иметь сквозной процесс, который заканчивается тем, что потребитель, простите, потребляет.
Например, в некоторых организациях понятие «процесс» (бизнес-процесс) используется для описания именно такого сквозного сценария, а для более детального структурирования деятельности на отдельных участках этого сквозного процесса описываются «подпроцессы». И то, что теперь для процесса верхнего уровня появилось новое название «поток» никак не помогает. Природа объектов управления (процесс, подпроцесс) идентична. Кажется, дополнительный термин для анализа или проектирования не нужен. То есть в описании и сквозных сценариев можно обойтись без «потока».
Кроме того, предложенная выше формулировка (процесс — описание того, как работу работать, а поток — описание того, как создаётся ценность) обычно не сильно помогает разобраться, так как вроде бы очевидно, что ценность-то создаётся за счёт того, что работа работается. Поэтому противопоставление не становится понятнее.
Особенно с учётом того, что мы строим процессы и управляем процессами, понимая, что они (процессы) нужны не сами по себе, а как механизм обеспечения какого-то конечного результата (в том числе обеспечения нужных характеристик продуктов и услуг). Ровно об этом модель ITOCO, где среди ключевых элементов процесса для его управления нужно идентифицировать не только «выход» (output — непосредственный результат процесса), но «результат» (outcome — конечный результат, ради которого процесс существует — например, предоставление услуги).
Всё, тупик? Граница между понятиями полностью размывается?
Тем более, что, вводя понятие «поток создания ценности» при описании производственной системы Тойота (TPS), Джеймс Вумек и Дэниел Джонс говорили о «совокупности всех действий, которые требуется совершить, чтобы…». То есть про действия (в том числе).
Попытка найти формальные различия потока и процесса мне кажутся не очень эффективными. Чаще всего в рассуждениях различных экспертов на эту тему можно встретить следующие соображения.
«Процесс — это только про деятельность. А в описании потока важные ещё и информационные потоки.»
«В потоке важны временные характеристики, а не только структура деятельности, как в процессе.»
«В отличие от процесса в потоке нам важно учитывать потери (например, простои) и управлять ими.»
Вопрос типа «Можно определить процесс с описанием всех вышеперечисленных дополнительных аспектов? И, если да, то в какой момент времени процесс, описание которого постепенно обрастает упомянутыми деталями, превращается в поток?» обычно остаётся без ответа.
Да, и как на него ответить? Разве что договориться, что процесс это только про деятельность. То, что описывают в текстовом виде (в практических руководствах ITIL 4 в виде таблиц). А ещё в виде диаграммы workflow процесса. Ну, и распределение ответственности — какие роли с каким уровнем ответственности вовлечены в выполнения того или иного действия в процессе. Документируется чаще всего в формате матрицы RACI. И ничего кроме этого. А всё остальное — это уже поток.
В такой картине мира поток состоит из какого-то набора процессов и ещё много из чего (того, что не входит в границы понятия «процесс», как мы его договоримся трактовать — вариант приведён выше).
Но мне кажется, что так теряется исходный смысл заложенный в понятие «поток создания ценности».
Так в чём же разница?
На мой взгляд, разница как раз в том, что «процесс — это описание того, как работу работать, а поток — описание того, как создаётся ценность».
Когда мы пытаемся разобраться с тем, как устроена или спроектировать, как будет устроена наша производственная система, будь то фабрика или организация, занимающая созданием нематериального результата (например, ИТ), мы можем подходить к этому с разных сторон.
Один вариант — давайте определим, кто в какой последовательности какие действия выполняет, и как эти действия взаимосвязаны. Здесь мы говорим о процессе. Объектом управления будут субъекты, выполняющие описанные действия (люди в том числе). Воздействуем мы чаще всего на людей.
Другой вариант — попытка понять, как двигаясь по нашей производственной системе, изделие или задача «обрастает ценностью» — тем, что нужно потребителю там, в конце потока. Объектом управления является задача. И воздействуем мы в первую очередь на устройство нашей производственной системы, то, как она организована (например, вытягивание, WIP-лимиты).
Чем на формальном уровне могут различаться эти подходы?
Ну, например, в случае потока, понимаемого вышеописанном способом, мы в каких-то случаях не будем пытаться определить порядок работ и взаимодействия. Например, рассчитывая на то, что сотрудники сами поймут, или менеджер будет вынужден всякий раз принимать решение по ситуации. Это наиболее разумный способ управления в тех задачах или на тех этапах решения задачи, где степень определённости невысока, много меняющихся факторов, влияющих на принятие решения, высока вариативность, часто встречаются возникает необходимость решать уникальные вопросы. И, соответственно, выполнять упражнение по формированию матрицы RACI по отношению к каждому шагу потока, как, предлагают авторы ITIL®4: Create, Deliver and Support (например, в разделе 3.1.6 Describing a step of the value stream), возможно, но не всегда целесообразно.
В описании же процесса обойтись без определения ролей и их ответственности — подвергать риску стабильность результата процесса.
То есть суть различия, на мой взгляд, в том, что для того, чтобы обеспечить достижение конечного результата может не потребоваться структурировать деятельность. И тогда мы можем обойтись описанием потока. А может потребоваться структурирование деятельности (на всех этапах (шагах) потока создания ценности или на некоторых; вся деятельность или только какая-то её часть). И тогда мы определим/переопределим какое-то количество процессов.
Нам обязательно нужны оба понятия?
Мой ответ — нет.
Можно обойтись только процессами. Такие организации известны.
Можно обойтись только описание потоков. Такие организации тоже существуют вокруг нас.
Как понять, что нам нужно какое-либо из двух?
Нужно понять, какую задачу решаем. Разбираемся с тем, как должна выполняться работа, выстраиваем чёткий порядок сложного взаимодействия или разбираемся с тем, как должен создаваться результат.
Какую производственную систему строим/оптимизируем. Например, в зрелые продуктовые команды в некоторых организациях являются весьма эффективными производственными системами, прохождение задач через которые представляет из себя быстрый, равномерный поток (это другой «поток» — поток задач, flow). Такие команды обычно работают с потоком создания ценности. При этом деятельность может не быть чётко не структурированной. Привлечение тех или иных специалистов на том или ином этапе потока и взаимодействие между специалистами… просто происходит. И если кто-нибудь попробовал бы описать происходящее в виде чёткой процессной структуры, то вполне возможно, что не смог бы. Команда работает как команда.
