Нет, речь не о том, что процесс начинается стартовым событием и событием же завершается, это понятно. Речь о том, что считать процессом, а что нет.
Несколько цитат, демонстрирующих разброс мнений по этому вопросу -
Пол Хармон комментирует дискуссию “Process and Capabilities” в группе BPTrends на LinkedIn:
Существенное различие между практиками - одни используют термин “процесс” для обозначения диаграммы или даже в еще более узком значении - для обозначения паттернов потоков работ, а другие называют “процессом” все, что относится к получению определенного результата. Я определенно отношусь ко вторым… для меня отделение “ресурсов”, “людей” или “менеджеров” от “процесса” - это просто слишком узкий взгляд на процессы… “Способности”, о которых говорят в армии, это маленькие процессы - или действия, если хотите - которые при необходимости собираются в более крупные процессы. Высадка на резиновой лодке - одна способность, марш-бросок на 10 миль - другая, и т.д. Когда, например, возникает ситуация с заложниками, процесс (проект) комбинируется из множества отдельных действий и исполняется.
Как мы видим, Пол называет процессами буквально все - действия и комбинации действий любого масштаба, не делая разницы между процессами и проектами.
Сходной точки зрения придерживается Говард Смит, который пишет в статье на BPTrends.com:
Стремление обвести процесс рамкой и приравнять его системам пошагового выполнения работ - это фикция, отрицающая всю современную теорию и практику процессов. “Адаптивный кейс менеджмент” это всего лишь определенный тип процесса, обозначение процесса, заключенного внутри. Откройте коробку с надписью ACM и внутри вы обнаружите процесс.
Ассоциация BPM-профессионалов в своде знаний BPM CBOK (глава 6, раздел 6.2.2) высказывает иную точку зрения:
… очень многие компании определяют процесс и управление им как работу, совершаемую в рамках отдельного подразделения. ABPMP официально не согласно с таким определением… Согласно определению ABPMP, «процесс» является кросс-организационным и включает в себя все работы, необходимые для создания и предоставления продукции или услуги. При этом процесс может быть разбит на подпроцессы, которые выполняются подразделениями…
В чем эти взгляды сходятся и в чем расходятся?
- Общей является нацеленность на конечный результат и на эффективность (понимаемую в широком смысле слова). (Гэри Раммлер, являющийся авторитетом для представителей обоих лагерей, называл то, чем он занимается, performance consulting, а не process consulting.)
- Все также согласны с тем, что необходимо рассматривать выполняемую работу на всех уровнях - на верхнем уровне сквозного процесса, на уровне потока работ внутри подразделения и на уровне конкретного рабочего места.
Различие во взглядах двояко:
- ABPMP предпочитает резервировать термин “процесс” для верхнего уровня процессной иерархии, а для более низких уровней использует термины “подпроцесс”, “поток работ”, “действие”, “задача”. Альтернативная точка зрения - называть “процессами” все вплоть до атомарной задачи.
- Пол Хармон и Говард Смит не делают разницы между процессами, проектами и кейсами, для них это все - разные формы процессной работы. BPM CBOK, напротив, проводит четкую грань между процессами и проектами.
Но есть ли смысл обращать на это внимание? В конце концов, это всего лишь вопросы терминологии - в практической работы, уверен, представители и того, и другого лагеря используют одни и те же методы.
Я считаю, что смысл обращать внимание есть. Слова - это не просто буквы и не просто звуки. Это отчасти еще и магия, программирующая поведение людей: “как вы яхту назовете, так она и поплывет”. И с этой точки зрения, я считаю, что называть “процессом” все что угодно - плохая идея, вредная.
Это приводит к профанации - к тому, что люди теряют из виду цель - ценность для потребителя, и средство достижения цели - сквозной процесс. Ведь куда проще и комфортнее имитировать “процессную деятельность” на нижних уровнях. Не выходя за рамки подразделения, не вмешиваясь в существующий баланс сил… Как-то так, примерно:
Но, извините, “что безвредно, то и бесполезно”, и поэтому мне лично ближе позиция ABPMP, которая заключается в том, что если вы не дотягиваетесь до уровня сквозных процессов, значит, вы не можете претендовать на то, что вы управляете своими бизнес-процессами.
Что касается второй линии раздела - между процессами и проектами, то ставить между ними знак равенства мне тоже представляется непродуктивным. Допустим, с точки зрения конечного результата все равно как вы его достигнете - наладив процесс или выполнив проект. Но ведь методы и средства управления проектами, процессами и кейсами различаются, и достаточно существенно! И как мы будем этим методы развивать, как будем их осваивать, если “это все одно и то же”?
Не нужен BPM, если перед нами стоит задача провести Олимпиаду в Сочи. И не думают люди, которые эту Олимпиаду блестяще подготовили и провели, в терминах процессов - я вам точно говорю!
И для управления основной деятельностью адвокатской конторы недостаточно чисто процессных методов и средств. Для страховой компании - в самый раз, а ведение дела в суде можно описать в процессных терминах только на самом верхнем уровне.
Что лучше в этой ситуации - сделать вид, что “это все процессы” или же акцентировать внимание практиков на том, что есть процессная методология, она может то-то и то-то, но здесь вам ее недостаточно, и в дополнение вы должны иметь средства управления кейсами? По-моему, второе явно более продуктивно и вернее приведет к цели.
Если же надо как-то назвать всю совокупность средств достижения целей организации, включая и проекты, и процессы любого масштаба, и кейсы, то у меня предложение: давайте использовать термин “коллективная работа”.
В следующей серии заметок я поделюсь своими дальнейшими рассуждениями на тему - в чем сходство и различие между проектами, процессами, кейсами (а также документооборотом, инцидентами, поручениями, задачами), какие существуют средства для управления всеми перечисленными разновидностями коллективной работы и как могла бы выглядеть унифицированная среда для управления всеми видами. Собственно, статьи эти уже были опубликованы на e-xecutive.ru на русском и на BPM.com на английском, так что нетерпеливые могут сами найти и прочитать. Для остальных буду выкладывать по две в неделю.
Похожие статьи:
Анатолий, согласен, что «называть “процессом” все что угодно - плохая идея», но не согласен называть “процессом”, только сквозные процессы.
Получается какая-то сакрализация термина, перегиб в другую сторону. Мне это видится утопичным на практическом уровне, приходишь к руководителю отдела и говоришь: “давайте обсудим Ваш подпроцесс/поток работ”, а когда кто-то, всуе, скажет “процесс” поправлять и напоминать, что до процесса мы не дотягиваем, ростом не вышли. Так и результат не будет достигнут (пусть он и локальный) и коммуникация нарушена.
ИМХО, если есть взаимодействие нескольких участников (т. е. не говорим о функции или задаче) и мы можем сказать, что оно повторяется (не проект), то можно и слово “процесс” произносить не задумываясь о том на каком уровне иерархии он находится. Не всегда же решаются задачи полноценного управления бизнес-процессами.
Сергей, я не за фанатизм. К терминологическим вольностям отношусь спокойно и сам их частенько допускаю. Но только при условии, что *понимают* все все верно.
Но если у вас в организации принято рассматривать “процессы на уровне отдела”, то это именно то, против чего я выступаю. Это имитация процессной работы. Работаем как работали, но теперь хвастаемся процессами? Результат достигнут не будет, субоптимизация - это не результат.
Вот как вы будете улучшать “процесс подразделения”, не поняв что представляет собой процесс на верхнем уровне и какой вклад данный подпроцесс вносит в общий процесс? Не верю, извините.
Анатолий,
часто встречаюсь с тем, что люди путают 3 термина процесс, подпроцесс и бизнес-процесс. Отличие подпроцесса от процесса в том, что подпроцесс не реагирует на события во вне, а запускается потоком работ родительского процесса.
Мне кажется, что доля правды есть и в Ваших словах и в словах Ваших оппонентов т.к. Вы, в моем понимании, говорите о разных вещах. Процессы могут существовать на уровне подразделения или даже локального рабочего места, СУБД и т.д., примеров таких процессов огромное количество, но для бизнеса, сами по себе, они ценность не создают, поэтому бизнес-процессами я бы их называть не стал. А вот сквозная кросс-функциональная цепочка процессов, достигающая цели бизнеса - это, в моем понимании, бизнес-процесс.