Чтобы говорить о правильном разбиении процесса (бизнес-процесса) на процессные элементы (а также об уровнях моделирования процесса), стоит дать определение процесса. Берём наиболее частое и примитивное (ему уже лет 20): процесс - это деятельность, преобразующая входы (материалы, информацию, данные и т.п.) в выходы (результат деятельности: материалы, продукты, изделия, информация и т.п.). Иногда к определению процесса добавляют, что деятельность выполняется с определенной целью. Целью деятельности может быть достижение результата деятельности, а может быть цель не отождествляется с результатом, например, результатом процесса обслуживания может быть решение клиентской жалобы, а целью - удовлетворение клиента. Иногда определение процесса расширяют за счет введения в определение дополнительных его свойств, которые нужно специфицировать: метрик, владельцев и т.п. Однако все эти определения всё же не вносят ясности:  при попытке описать (смоделировать) какое-то явление или бизнес три аналитика принесут три разных процессных описания. Так в чем же тут дело?   

Давайте разберемся. И начать придется с анализа на тему, как же мы всё-таки определили термин ПРОЦЕСС. Однозначно можно утверждать, что процесс - это деятельность. Но как можно определить (задать, специфицировать) саму  деятельность? Для этого мы (человечество) выработали несколько способов:

1. Деятельность можно определить, указав вид совершаемой деятельности (вид работы): ПИЛИТЬ, СТРОГАТЬ, РЕГИСТРИРОВАТЬ, ОФОРМЛЯТЬ, ПРОДАВАТЬ...
2. Деятельность можно определить через ее входы-выходы. На входе - материалы, на выходе - продукция. На входе - проблема, на выходе - решение. На входе - абитуриент, на выходе - студент. На входе - руда, на выходе - чугун. На входе - овощи, на выходе - борщ.
3. Деятельность можно определить через указание субъекта, выполняющего эту деятельность: деятельность государственной думы, деятельность аппарата президента.
4. Деятельность можно определить путем указания цели этой деятельности: деятельность по сокращению затрат; деятельность, направленная на рост выручки; деятельность во имя мира на земле; деятельность по спасению природы.
5. Деятельность можно определить через устройство (программа, механизм), выполняющее деятельность, например, работа снегоуборочной машины, работа крана, работа насосной станции.
6. Деятельность можно определить через особый поток входов-выходов такой как смена состояний: на входе - проблема, на выходе - гипотеза по её решению. Или на входе - проблема, на выходе - локализация проблемы. На входе - задача, на выходе - назначенный исполнитель. В приведенных примерах мы видим, что в материальном мире может ничего не меняться, но в информационном пространстве происходят существенные изменения, которые пощупать зачастую невозможно, но можно и даже нужно их как-то манифестировать. Например, я получил на вход проблему/задачу и через два дня у меня появилось убеждение, что задача поставлена не верно. В таком случае я должен как-то отчитаться о проделанной работе и где-то отметить факт своего решения, то есть факт изменения состояния у проблемы/задачи. 

Можно найти еще 2-3 способа, как определить/указать/выделить какую-либо деятельность, но и так уже ясно, что в зависимости от вида деятельности мы определяем её (задаём её границы) по-разному. Но в интересах дела стоило бы отталкиваться не от удобств аналитика, а от целей описания процесса. Нам важны виды работ (например с целью построения таксономии компетенций)? - значит через них и будет определена деятельность. Нам нужны результаты работ (например, для реинжиниринга технологии)? - значит через них будет определена деятельность. Нам важны участники деятельности (например, нужно обосновать расширение штата)? - значит именно они будут ядром нужной нам спецификации.

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

Из перечисленных выше способов вычленения процессного шага следует, что крупность шага не является постоянной и предсказуемой величиной (вспомним терблиги). Не зря же один аналитик принесет нам процесс продаж из 5 шагов, а другой опишет те же самые продажи из 25 шагов. Здесь стоит обратить внимание, что традиционное определение процесса вообще не намекает на возможность его декомпозиции до шагов, подпроцессов, операций или транзакций. В самом деле, кто решил, что процесс должен декомпозироваться? Однако же оставим это в стороне и сосредоточимся на вопросе, что же предопределяет размер или крупность/детальность шага? Существует несколько равноправных факторов влияния:

1. понимание состава материального потока (не думаю, что все четко понимают, как железная руда превращается в железо или тушка коровы в колбасу)
2. понимание состава участников процесса (кто проектировал что-либо в гос.управлении вполне согласится, что выделить участников и их вклад бывает очень не просто)
3. понимание информационных состояний (здесь вообще нет надежды, что хотя бы 10-15% аналитиков понимают, о чем речь)
4. понимание используемых механизмов или программных продуктов, в том числе какие их функции задействованы на рассматриваемом шаге. Здесь, как правило, совершается меньше всего ошибок, но до функций тоже редко кто опускается. Ну разве что консультанты и интеграторы.

Итак, мы рассмотрели, чтО может влиять на определение сущности действия (шага в процессе) и его крупность/детальность. Учитывая эти соображения, мы теперь понимаем, каким образом можно вычленить элементы деятельности из всей совокупности действий, разворачивающихся перед бизнес-аналитиком (наблюдаемых бизнес-аналитиком). Сосредоточим еще внимание читателя именно на аспекте деятельности: деятельность [на определенном шаге процесса] может быть представлена тремя принципиально разными способами:

1. деятельность как [присущая или консруктивно определенная] функция, то есть деятельность, как свойство механизма, программы или исполнителя выполнять какую-то работу. В способе №1 внимание фокусируется на видах совершаемой работы. Эти виды работ вытекают из конструктивных особенностей субъекта-актора. CRM система может делать только то, на что она запрограммирована, а отдел продаж организован таким образом, что может только продавать, но не производить товары. Насос может качать только воду и только в том объеме, на который он спроектирован. Такой способ описания мы выбираем, когда функции акторов четко определены и заранее известны, а наша цель - улучшить горизонтальное взаимодействие акторов. ISO 9000 как раз про это. Это поток функций.
2. деятельность как обязанность (нормативное предписание) субъекта достигать какой-то результат. В этом способе акцентируется внимание на субъекте деятельности и ожидаемых от субъекта результатах. Имеется ввиду, что субьект деятельности - это человек или подразделение. Например, отдел урегулирования претензий. Как они достигают результат - описать формально практически невозможно, но можно указать признаки или вычленить какие-то стадии, указывающие на прогресс или регресс. Такой способ описания мы выбираем для интеллектуальных (когнитивных) процессов, как например, решение проблем, управление претензиями, расследования, планирование, оптимизация. Системы класса ACM (adaptive case management) - они про это. Они фиксируют состояния или прогресс процесса, сами же действия - вторичны (не специфицируются). Это поток состояний.
3. деятельность как процесс (исходя из математической рекурсии, что процесс может состоять из процессов): внимание акцентируется не столько на виде исполняемой работы, и не входах-выходах работы, а на прогрессе финального результата. Вроде бы всё ясно, но ничего не ясно. Математически, процесс (процесс в том смысле, за что именно выдали Нобелевскую премию) - это не совокупность акторов, исполняющих свои функции, а поток результата. Например, вы едете по трассе на скорости 100 км/ч и разговариваете с супругом уже более часа. Процесс - это ваш разговор, ваш сеанс связи, а не совокупность взаимодействий базовых станций. Но за прошедшие 60 минут уже сменилось 2 десятка базовых станций и даже вы переехали в другую роуминговую зону. Две-три-четыре-пять телекоммуникационных компаний ведут контроль за тем, чтобы ваш диалог с супругом был непрерывным.  Что является шагами этого процесса? - шагами процесса являются сообщения сторон диалога. Это поток сообщений.
4. способ №4 - это вариант функционального потока (см. пункт 1 в текущем перечне), только его последовательность контролируется неким модератором или координатором, в качестве которого, как правило, выступает система класса BPMS. Система BPMS либо назначает функции на исполнителей (такое назначение называется task, задача), либо иницирует определенные системные функции, например, вызывает методы определенных систем через API этих систем. Чаще всего способ №4 - это именно поток методов.

Итак, мы хотим подчеркнуть, что при желании смоделировать какое-то групповое поведение (какую-то деятельность) в виде ПРОЦЕССа, мы должны сознательно подойти к способам моделирования каждого шага (иногда используют синоним - каждой работы) в процессе. При этом наивысшую важность имеют:

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

Примечание: можно добавить сюда определение целей каждой работы, механизмов, исполнителей и т.п., но от этого процесс не станет более процессным. Более того, в процессах обработки информации произошел отход от акторной теории [уже более 10 лет назад], что мы можем наблюдать по трендам в области роботизации процессов. То есть исполнителем шага процесса всё чаще и чаще является система, специально запрограммирования на выполнение определенной работы в процессе, а скорость исполнения работы стремится к мгновенной.

И вот теперь можно вернуться к вопросу: каковы же должны быть (или могуть быть) уровни моделирования процесса и как правильно выбрать границы процессных элементов? Ответ почти очевиден: и границы процессных элементов, и их уровень (крупность/детальность) зависят от перечня (классификации или списка) видов исполняемых работ и степени подробности, с которой могут быть описаны входы-выходы. Если мы ничего не знаем в подробностях о входах и выходах или входы-выходы не носят стационарный характер (не могут быть четко зафиксированы), то вряд ли нам принесёт пользу изощренное знание видов работ. Равно как и наоборот, подробное знание видов работ вплоть до мельчайших операций без понимания того, чем заканчивается та или иная операция, не позволит нам смоделировать процесс на самом нижнем уровне.

Таким образом уровень моделирования и гранулярность моделируемых работ определяются:

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

При моделировании процессов сервисных и цифровых компаний (как например, телекоммуникационные операторы, маркетплейсы) с целью их автоматизации, нижний или нужный уровень моделирования определяется:

• составом информационных объектов (сущностей, данных, таблиц), которые есть входы и выходы процессных элементов,
• состояниями объектов,
• перечнем функций информационных систем, которые участвуют в обработке/преобразовании информационных объектов.

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

1. УПРОЩАТЬ
2. НОРМАЛИЗОВЫВАТЬ (УНИФИЦИРОВАТЬ).

Упрощение подобно искусству. Нормализация требует лишь умений следовать нормам, но самое сложное - найти сами нормы. Для процессов - это, как правило, отраслевые таксономии, например Business Proccess Framework для сервисных компаний (ранее известная как eTOM); а для информационных объектов - это SID.