The term “process” has different meanings depending on the context, confusing BPMN beginners. This brief note should help.
1. BPMN process is repeatable
E.g. “Company closure” is not a process because it may be executed only once. (Of course if you do not provide liquidation services for others. )
2 . BPMN process is predictable
A process may take different paths depending on data or events, it may run in parallel etc., but it is assumed that we know all the gateways in advance - not at the execution but at design time.
This is a strong assumption that doesn’t match everything we call processes in everyday life. For example it’s hardly possible to predict the route of patient’s treatment at the hospital from his admission to the emergency room. The same applies to a case in court: the opposing party may submit a document that will turn the course of the process by 180 degrees from what we’ve planned in advance.
Such unpredictable scenarios should be treated as projects or cases depending on the context.
3 . BPMN process is non-trivial
If a it can’t be decomposed into tasks then it’s not a process. A process is a set of related tasks and/or sub-processes i.e. it’s not atomic.
A subprocess is non-atomic too. The difference between a process and a subprocess is that a process is associated with external events (it responds to an event at start and initiates an event at completion) whle a subprocess is triggered not by an external event but simply by a control flow in the parent process or subprocess.
4 . BPMN process is concrete
A BPMN process has a well-defined start event, a predetermined flow of actions and defined set of completion states.
“Budget process”, by contrast, isn’t a BPMN process. From BPMN perspective it’s a set of related processes (e.g. “Budget approval”, “Budget execution reporting”) plus tasks belonging to processes from other domains like “Check budget availability” in the “Purchasing” process.
Similarly, “Promotion process” isn’t a process but a family of related processes in terms of BPMN. “Manage something” probably stands for a process family, too.
5 . BPMN process is discrete
If there is a flow in your process that returns it to the very beginning e.g. after an approval task then consider an altenative option - to end the process with a negative status having in mind that another instance may be started any time.
E.g. if a hiring process didn’t succeed then it’s better to end it with appropriate status than to loop. It can be started over again, probably with different input (with a more generous salary offered).
It’s better in terms of monitoring and analysis: we honestly admit that the process is not always successful. The process duration data becomes more trustable, too.
6. BPMN process inputs and outputs are primarily events
The common view of a process is something processing inputs into outputs - here inputs and outputs are resources.
BPMN processes are different: they respond to inputs and generates outputs, i.e. inputs and outputs are events. I’ts also possible to model input and output resources in BPMN but these are optional while start and end events are obligatory.
Process start is a handler of some external event, process end initiates an event in the external environment. A particular but quite common case is “none start” (free will) event and “none end” event that produces no effect to the environment.
7. BPMN process is the story of an object, not of a subject
Do not attempt to use BPMN for things like “employee’s working day”.
The right approach is to model processes like “Client’s order end-to-end”.
8. BPMN process is not completed until all the work is done
BPMN process starts when someone is willing to initiate a certain sequence of activities or when an external event (e.g. a client’s order arrived) triggers it and it doesn’t end until the very end, i.e. while there are things to do (e.g. a customers service called a buyer after shipment) .
“Here the sales process ends and accounting process begins” is a bad idea - it’s a single cross-functional process, not two separate ones.
9. BPMN process is customer-oriented
Treat a process as end-to-end, ruled not by business units boundaries but by the customer’s view (external customer’s, ideally): start from the customer’s request and continue until valueable result is delivered.
Switching from traditional “inside-out” view isn’t easy so use the following method: instead of modeling the saless process consider the process of buying by your customer; the process of submitting a complaint and obtaining response instead of internal complaint processing and so on. Find out what is the optimal process from the customer’s perspective.
Internal consideration’s should be taken into account at some stage of process design too but it’s better to start from the customer’s view of the process.
10. BPMN process is macro-, not micromanagement
It’s possible to use BPMN for detailed regulation of a single workplace activities but it’s not why we love it. If employees are not trained then it’s a problem indeed but it’s a functional rather than process problem. And there are many solutions for it apart from BPMN.
The process problem is this: employees are functionally competent (i.e. are able to do their jobs) but the whole process is complicated as it requires precise coordination of efforts of business units separated by the hierarchy and geographically. The responsibility for the handoffs and for the end result is unclear, resulting in poor overall performance.
BPMN is the tool of choise for this kind of problems because it makes the interaction between participants explicit and equally clear for all stakeholders - top management, business units and “process engineers” (including IT) responsible for the process implementation.
Thank you Anatoly, that may help beginners with BPMN a lot. I recently started with BPMN in the cloud ( http://www.iyopro.com ) that has much help but you need to learn bpmn and that is not always easy.
Thank you
Basti
My pleasure and thank you for the link.
К п. 4 хотел бы дополнить. Часто в ИТшной среде приходится сталкиваться с такими “процессами”, как “ведение такого-то справочника”. Что такое “ведение справочника”? Это обеспечение наличия в нём актуальной информации обо всех объектах описываемой им сущности. На первый взгляд, ведение справочника действительно может показаться процессом или группой процессов (например, “Добавление записи”, “Изменение записи”, “Блокирование записи”). Но в общем случае атрибуты объекта не возникают на ровном месте, а являются следствием выполнения каких-то бизнес-процессов, причём атрибуты одного объекта могут становиться известными или изменяться асинхронно и независимо друг от друга, в рамках разных бизнес-процессов. И где тут тогда место “процессу ведения справочника”? Только в голове у ИТшников, которые таким образом обозначают даже не семейство процессов, а разрозненные функции из разных процессов, связанные между собой только влиянием на одну сущность.
Подпроцесс? Точнее, Global Activity.
Does it matter if it is a BPMN process or just a process? What would not be a process, but still constitute work to be done? What would be the relationship between a process and that other way of completing work?
Jonas
“Just a process” may mean a lot of very different things depending on the context. For example, manufacturing process or a process in PMBOK sense differ considerably from BPMN process.
Project is not a process but still consitute a non-atomic work to be done. Same is true for cases. I was writing about it here http://mainthing.ru/item/681/
Hi Anatoly,
I must have interpreted your post wrong. My mistake. I thought you were describing a new type of processes as a BPMN process.
Should I read your post as what processes could be expressed with BPMN?
If so, would a Case (a dynamic process) be possible to express with BPMN or are there other notations more suitable for this kind (such as CMMN)?
Jonas
Yes, now you’ve got me right.
Regarding cases, I believe that case and notation are mutually exclusive. Case is a dynamic check list plus associated data.
Great.
I agree that dynamic processes and predictable processes should be treated differently, but there are so much relationships in between them. They interact with each other.
I’m trying to understand the reasons for organizations not to standardize what should be regarded as routine work. What is not standardized and, by extension, can not be regarded as an object of automation should be such which has exceptional impact on the company’s distinction to be competitive. I mean that there should be good reasons to regard work as impossible to classify as routine just because it has some elements of human presence. I think it’s easy to dismiss the work could be standardized only to parts of it requires a knowledge worker’s input. This leads to missed opportunities that exist to automate work.
Would you say these two aspects of a process has a future to evolve together or should they be treated as different things?
Cmmercial interests of certain vendors and/or consultants force them to push their products hence the marketing fad around e.g. ACM.
Yet I believe there is a consensus today about cases and processes being two sides of one coin. Nobody needs distinct systems managing cases and processes separately because as you rightfully noted they interact (call) each other. Besides, they tend to mutate to each other: e.g. a certain type of work may be a process in essence yet we may decide to treat it as case for the sake of agility or vise versa: a mature case work may be reshaped into a process. One more argument towards unification is that both cases and processes have task management as a common basement.
So they definitely will evolve and they are in fact already involving. It’s a matter of time and of the fear of cannibalizing their current separate offerings that some vendors may have.
Thanks for sharing.
In our organization, we face a decision about whether to continue to look at work as something very unique to each case that is not even worth discussing in terms of details that might indicate a mixture of routine work and decisions made ad hoc. Vendors have at least made it clear that there is a cooperation between the ad-hoc work and standardized processes, hence providing integration between the tools that they market. Those who primarily advocate the idea that they should live apart is the outsourced management group of the tool support we have for CM. It’s a shame because it is in their very interest to consolidate the differences. I believe the same debate and political standpoints is similar everywhere among organizations and vendors, don’t
you think?
Jonas
I’m not in position to make statements about all or majority of organizations. Besides it depends much on the process maturity of the organization.
My observations are from BPM/ACM experts community, i.e. professional blogs and conferences.
Sorry. not my intention to force you in to an answer. I appreciated our talk, thanks
My pleasure, too.
Thanks for the info! I have also found out What is BPMN? using Lucidchart and it is super easy to use! Check it out!