Тут я хотел написать длинный обстоятельный пост, в котором рассказать:
-- про соглашение по терминологии: разницу между речевыми сообществами и сообществами значений (поднобней в http://ailev.livejournal.com/1157166.html). Нельзя ожидать, что при произнесении слова "процесс" значение обсуждаемого у всех одинаковое.
-- про важность онтологического рассмотрения (в том числе привести в пример мою любимую картинку по материалам фирмы FutureModels, где в том числе есть и "процесс"
и мою любимую ещё с 2007 года цитату из Криса Партриджа по поводу его метода BORO: "Процесс намеренно исключен [нашим] методом. Опыт показал, что практически невозможно эффективно переработать процесс в модель бизнеса. Проблема в том, что процесс имеет линейную языкоподобную структуру (это как раз то, почему люди говорят о языках программирования по контрасту с системами управления базами данных). Как повседневный язык (и не так, как бумажные таблицы и компьютерные данные), эти ограничения линейности так серьезно искажают процессную группу группу описаний деятельности, что она не может быть переработана систематически. Исключение процесса существенно упрощает переработку. Как замечено выше, это не компрометирует конечную модель, так как более явно структурированные данные содержат более чем достаточно объектных паттернов (включая паттернов событий)". (перевод сделан в 2010 году, http://ailev.livejournal.com/867599.html. Но в 2007 году я уже писал, что методы крутятся вокруг продуктов, а не процессов -- http://ailev.livejournal.com/517723.html -- задолго до того, как узнал об Essence с его акцентом в практиках не на activity, а на alpha).
-- про минимальных три подхода к определению деятельности. В http://arxiv.org/abs/1502.00121v2 я пишу There are three basic viewpoints that stem from such a definition: practice-based (fits best to answer stakeholder’s questions about the Way-of-working), process based (project management related to Work alpha), team-based (related to communications, authority and responsibility of the Team alpha). The same practice-based, process-based and team-based in (Cordys, 2008) calls respectively artifact-based (due to importance of work products aka artifacts to practices), activity-based (process as sequence of activities), communicationbased (one of important things about a Team is the communication about Work division for a given Team, authorities and responsibilities of team members). The same three viewpoints in (Wang et al., 2005) are called respectively information-based (in most non-manufacturing companies work-products mainly information objects), process-based and organization based.
Но я сходил сегодня на заседание ассоциации процессного управления (http://abpmp.org.ru/events/17/genplan/), послушал доклад "Процессное управление в проектной организации" и выступления к докладу. И после этого понял, что большой учебник в пост вписать не получится, да его и не прочтут внимательно (как очевидно читали "по диагонали" мой предыдущий пост большинство его комментаторов). А короткий текст всё одно "не поймут-с", слишком большая inferential distance -- a gap between the background knowledge and epistemology of a person trying to explain an idea, and the background knowledge and epistemology of the person trying to understand it (http://wiki.lesswrong.com/wiki/Inferential_distance).
На заседании мне удалось послушать примерно пять раз в разных исполнениях определение процессов и проектов (определения совершенно классические, но почему-то сопровождаемые фразой "мне много лет потребовалось, чтобы понять, что такое процессы/проекты"). И услышать дискуссию из машины времени: пятнадцатилетней давности "чем процессное управление отличается от проектного" с выводом "ребята, давайте жить дружно". В зале было полно начитавшихся Голдратта, много вопросов было про отслеживание потока "в процессах". Но не меньше было и тех, кто не понимал, о чём их спрашивают: какие такие потоки в процессах?!
Слово "проект" однозначно трактовалось как project. Замечание что "проектная организация" это "проектный институт" и тамошний "проект -- это design", и никакого "проектного управления" в части "проектирования" может и не быть, это замечание игнорировалось и дискуссия про проекты-процессы продолжалась. Кейс-менеджмент иногда поминался, но через запятую с управлением документами (боюсь, большинство в зале issue tracker от CMS не отличили бы: все различалки заканчивались разницей программ проектного управления и процессного управления. И да, почему-то в кулуарах всё время всплывали ERP системы -- но даже мою шутку, что в России при их использовании ставят все модули, кроме модуля планирования, даже эту шутку не очень-то и понимали).
А я ещё хотел узнать там про передовую процессную мысль, про фронтир BPM! Увы, не получилось.
Так что длинного текста про процессы тут не будет. Всё одно нельзя переубедить в чём-то людей, не задумывающихся об онтологической разнице между функциями, процессами, сервисами, экземплярами процессов, типовыми проектами/шаблонами проектов, операциями, деятельностями, кейсами, делами, действиями.
Но я знаю, чем всё кончится. Issue tracker приверженцы проектного управления назовут программой проектного управления, процессники обзовут программой управления процессами, документообороторы -- программой электронного документооборота, специалисты по Lean обзовут "канабан-доской", и так далее. Поставщики классических программ процессного и проектного управления с изумлением обнаружат, что issue trackers генерируют примерно те же отчёты, что и они -- но в разы легче осваиваются, ибо с ними работают не только менеджеры, но и инженеры (или какие там другие содержательные сотрудники кроме инженеров). Этот процесс потихоньку идёт уже сейчас, всякие "системы управления задачами" как раз такой природы. И из бывших сертифицированных проектных и процессных управляющих получатся отличные кейс-менеджеры, и неважно какой терминологией они будут при этом пользоваться и какие сертификаты демонстрировать (главное, что при слове "процесс" они не будут рисовать кудрявую BPMN-диаграмму, а думать о чём-то в разы более декларативном. И в головах у них будет метафора "потока", а не передачи управления по цепочке исполнителей).