Following up the previous post - may we call a business processes things like “Oil Mining” or “New Product Promotion?”

Once again, the answer depends on the context. In BPPMN they aren’t business processes, definitely. From BPMN perspective business process is a specific sequence of actions initiated by a specific event and ended by some specific result.

In BPMN there is no room for vague things like “Product Promotion”. You can use the term “activity” or “process family,” but not “process”.

E.g. “Product Promotion” is a family of processes that may include “Annual Partner Conference.” That’s a process from BPMN perspective: a start, a predictable sequence of tasks, results - “OK” or “Conference Cancelled.”

Not a Process Any Longer

The other extreme is reached with too much details and a process disappears.

For example if we assign a task “Buy Bread for Dinner,” it won’t confuse the assignee. Now if we try to get into details by giving answers to the questions “which supermarket to go to,” “what to do if the supermarket is closed,” “what to do if the favourite brand is not available,” etc. then we’d probably end up by explaininig where to cross the street on the way and which foot to make the first step with.

And it won’t be a process because it’d be impossible to define a template covering all possible obstacles. It’d be an unpredictable case. And it’d happen all the time if we get deep enough into the process details.

Conclusion

• At the highest level of a process analysis there is no processes yet, only process families.
• At the deepest level of process details there is no process any longer but cases without predefined templates.

We must face the fact that there is no universally-accepted definition of a business process and probably newer will be. Hence it’s no use to develop the true definition and I won’t do that. I’ll try instead to explain what do I mean by the term “business process”.

Search for the true definition is fruitless because the notion of a business process is not self-contained - it makes sence only within a frame of some conecpt. Business process within the process management has one meaning, business process in enterprise applications integration is another thing and the term used in production line design differs from both. A universal definition suitable for all three domains would be too vague and therefore useless.

Some examples: is “From Order to Cash” a business process? Apparently, yes.

Now what about these:

• “Personnel Management”
• “Oil Mining”
• “Expenses Report”
• “Preparing Invoice”
• “Printer Cartridge Replacement”

Maybe they are business processes, maybe not… it depends on the point of view.

I am primarily interested in process management view.

What is process management?

Let’s get back to basics: process management isn’t an artificial concept, it responds to very material problems of functional management.

Here is the issue of any hierarchical organization:

• Specialization comes first: one employee is trained to work in one functional area, the other - in another.
• Then employees are divided by departments and occupy the rooms according to their function.
• At the end of the day every employee cares only about the function assigned to him while the end result - that is, satisfying the needs of the outer worlds which is the ultimate reason for the organizagion to exist - is nobody’s responsibility.

A hierarchical organization builds only head-subordinate kind of relations but it isn’t enough to satisfy the external customer - it requires cooperation of several departments. For example, from the moment the customer turned to us, to the point where he had gone satisfied, the workflow involves the client department, shipping department, the lawyers who approved the contract, accounting who issued an invoice etc.

The hierarchical system tries to resolve the ussue unsystematically: through emails, meetings, “administrative football.” It doesn’t hurt as soon as the company is small and young because all the team is well-motivated. But motivation alone doesn’t help when the company grows - some systematic solution is needed.

There are two possible solutions: project and process management.

• Both in project and process management we introduce regulations establishing horizontal collaboration between departments within our hierarchy. These ”game rules” are mandatory for all participants and following them guarantees a positive outcome.
• Project management establishes the rules for each project e.g. in the form of a project schedule.
• Process management is based on the assumption that our activities are repetitive. Therefore the rules are set for the business process template and each instance of the process follows the template.

Business process and process management

Within the process management scope business process can be defined as a repeating sequence of activities coordinating the work performed by various departments.

The key aspects:

• business process is cross-functional - it involves several upper-level organization units
• business process is repeatabile - a sequence of actions can be defined in advance as a template (it’ss a project, not a process otherwise)

Under this approach, “Preparing Invoice” and “Printer Cartridge Replacement” aren’t business processes while “Expenses Report” is as it involves multiple functional areas.

Business process and functional management

I know that some colleagues won’t agree with the interpretation above. They call a business process and even model in BPMN things like scanning incoming correspondence by a secretary or filling a transport container by a warehouse worker.

I don’t buy it. I believe that business process is not a cure for a functional incompetence that can and should be fixed by functional management. The employee is uncapable? Train or replace. Doesn’t help either? Replace the line manager.

A business process is indispensable in a situation where all employees are functionally competent but the number of participants is so large, they are so far from each other in terms of geography and/or organizational  and the worlfow logic is so complex that functional management fails.

The same idea may be expressed less agressively: you are free to call the business process whatever you want but the effect of using a business process as a management tool will be greater, the greater the number of participants is, the more distant they are from each other and the more complex the logic of their interaction is.

Business processes classification

Now here is a valid question: why the customer is missing in the definition above?

It’s because limiting the business process term only by those that are directly related to the client (the client has come - the client went away pleased) would be impractical.

Let’s consider Purchasing process for example. It isn’t connected to the external customer yet its logic is complex enough and it involves multiple departments (logistics, finance, production). Therefore the same cross-functional issues are inevitable and it’s natural to apply the process management here.

This is why it’d be non-productive to consider external customer satisfaction as a qualifying attribute of a business process. It’s better to introduce the classification of business processes instead:

• Core - those creating a value for the external customer
• Supporting - others creating costs, not value

It should be noted that, although the supporting processes do not create value, they usually are inevitable either because they support core processes, or because they provide conditions necessary for the existence of the company like compliance or fiscal accounting.

The notion of end-to-end business process is close to core - in both casess we deal with processes connected to the customer. They differ in scope:

• End-to-end business process is triggered by customer’s request and ends when all the work initiated by the request is done, a classic example - “Order to Cash”.
• In contrast, “Order Delivery” is a core business process but not end-to-end.

Every end-to-end process is core but a core process may not cover all the process end-to-end i.e. constituate its subprocess.

Business process in terms of BPM

Prior to the millenium process management was meant management of the organization through business processes.

Modern BPM added another aspect - volatility. It postulated that business processes changes over time. (More precisely, it changes much more often than the functions that make up the process.)

These changes occur because of state regulators, pressure from competitors, the growing demands of customers and partners and last but not least because of our own passion to self-perfection.

As a result, the modern process management has two dimensions:

• management of the organization through business process
• management of business processes through classic PDCA cycle

Modern process methodology and BPMS tools view a business process as something constantly evolving. Consequently the waterfall development isn’t applicable to a BPM project - only Agile methods do.

Examples:

• Purchase by Tender
• Competitive Hiring

Simplified diagram depicts the essence of the pattern:

Full diagram:

Comments to the diagram:

1. The “Tender” process announces the tender, records the information in the tenders database for the future references by the bid process and falls asleep until the bid submission deadline. After that the tender record at the database is marked as closed.
2. Each sumbitted bid creates an instance of “Bid” process. Generally speaking we may run several tenders at once so the bid process starts by indentifying the specific tender the bid appllies to. It’s easy in the case of purchase by tender but when it comes to competitive hiring (where an income resume plays the role of the bid and the vacancy is tender’s equivalent) it’s a non-trivial task because people use to send resumes blindly not caring whether there is a suitable vacancy or not.
3. If the tender is successfully identified and the bid passes the qualification (in the case of hiring - the person passes interviews) then the bid is written into the database. The bid process then expects of one of two messages: either the bid is a winner or the tender has ended and the bid didn’t win.
4. The tender process sends the message to the winner after the best from the submitted bids has been choosen. There are two possible outcomes in the bid process: if everything goes smoothly we conclude an agreement with the winner. In this case a message is sent back to the tender process and the tender process informs other participants that their bids has not won. After that the tender process successfully ends.
5. If for whatever reason the agreement was not concluded then the tender process determines the next winner picking it from remaining bids. If there is no bids any more (or there were no bids from the beginning) then the tender process ends unsuccessfully.
6. It is assumed that the time interval between the bid submission and tender decision deadlines is sufficient to evaluate the request that may come “five minutes” before the submission deadline. If it happened that we evaluated all bids prior to the decision deadline then it’s possible to determine the winner earlier (not waiting for that date). In the case of hiring it makes sense while in the case of purchase probably not because in this scenario the end date is declared, well-known to participants and they usually submit the bids at the last moment. This logic can be modelled too but it would complicate the scheme considerably.

A couple of general notes:

• Repetitive actions are usually modeled in BPMN by a cycle (standard or multi-instance) or with the help of exclusive gateway. Here we model repetitive activities (processing bids) by a separate pool - each bid corresponds to an instance of the business process.
• The case for «Resource Planning» pattern is one performer / multiple orders. Here the situation is reversed: multiple potential performers for one task.

Tyrrhenian sea, Stromboli island and volcano (Italy).

Aegean sea, vicinity of Marmaris (Turkey).

Ionian sea, legendary Ithaca island (Greece).

ebizQ editor Piter Schooff recorded a podcast effectively presenting me as a «modeling guy». OK, if Peter believes modeling is a good topic right now then I’m not going to argue. The podcast is published at ebizQ: «Process discovery and modeling done right» (transcript).

Correcton: page 3 of the transcript reads -

PS: What are some best practices for effective process modeling?

AB: You might notice from my blog that I’m a proponent of process patterns. Pattern is a typical process fragment common to a number of real world processes. And the matching word for “pattern” is “recognition.” With an adequate training and some practice, a process analyst just sees familiar patterns in the process task he is working on. And this way, he or she gets the results much faster, [but] they’re more error-prone because they are based on proven fragments or patterns.

Of course I meant “less error-prone” here.

This was my second podcast at ebizQ. Prevoious podcast: «Avoiding BPM done wrong» (transcript).