Business Processes - A definition?

"What is a Business Process?"” is a question we always ask delegates on our Modelling Business Processes course, “and "don't say it is a process in the business!"” is a standard follow-on.

Everyone knows the answer to this, don’'t they, so why do delegates struggle to give an answer? Just why is it so difficult to tie down?


Many are the definitions or suggestions that have been offered by various authors, ranging from “a set of processes which provide value to the organisation”, to a “value chain”, to “whatever set of inter-related processes the business deems to be a business process”. This smacks rather of “how long is a piece of string” and does not really help.

I was triggered to write something on this as a result of reading Alec Sharp’s book Workflow Modelling. He discusses at some length this difficulty of definition and, very unusually for me, I found myself nodding in agreement with many of the points he made.

Everybody appears to agree on some common characteristics of a Business Process (which I shall henceforth abbreviate to BP). These include:

  • Comprise one or more processes
  • Transcend functional boundaries
  • Provide benefit to the business
  • Must have a measurable outcome, or outcomes

Personally I would add a few more, such as ownership, but I will put personal bias to one side for a moment.

One further commonly-agreed characteristic appears to be that a BP needs to be triggered by something. Sharp discusses a triggering event which occurs externally to the business and which initiates the first in a series of dependent processes which eventually produce a measurable benefit. This is where I started to nod appreciatively since the concept of business events and their place in business analysis is one in which I am a firm believer.

Bounds of a BP

Taking a business event as the “start” of a BP and a measurable outcome of benefit to the business as the “end” provides a scope for a BP. Sharp then discusses how he reviews the relationship between dependent pairs of processes. I hope I have understood this correctly because it introduces an interesting way to distinguish whether the dependency chain of processes constitutes one or a number of BPs.

In essence he considers the movement of information between processes and asks whether the relationship between them is 1:1, 1:m, m:1 or m:m. For example, think of an order arriving from a customer and the set of processes that are applied to it. If it is an order for products that are sitting in a warehouse then it may be that the order is processed as an individual item right through to shipping and invoicing. Thus we could think of this as a BP. Alternatively if the order is for products that are made-to-order then there is likely to be a point in the processing where the needs of this order are merged with the needs of other orders to produce a production schedule – processes are related 1:m.

Deliveries of products to multiple stores would create the same 1:m relationship between processes; creation of a statement would create an m:1 relationship (invoice production to statement creation). At each point where the relationship is other than 1:1 there has to be some delay in the processing and at this point Sharp appears to place a boundary – end of a BP; when the processing re-starts, another BP.

Concerns (Quibbles)

As I said, I found myself nodding at the argument. The focus on a business event and a trigger seems to me to be self-evident – any business analysis project where the process boundary appears to start internally definitely needs to be challenged. I like the re-statement that we should be looking at the dependency between processes, albeit there will be some communication between processes at some stage. I like the emphasis on measurable outcomes.

If I have a concern it is that this analysis of relationships between processes can produce some BPs that I would not normally see as distinct.

For example, one computer manufacturer we worked with saw one of their BPs starting with an order from a customer (a re-seller) and ending when they received payment. Along the way they made the box to order and shipped it, along with any other boxes, to the customer. Were they wrong to think of this as one BP?

I would suggest not. But that then argues against Sharp’s view. In practice I think my concern is more of a quibble than a fundamental disagreement; perhaps it is just that it is not easy to see where the benefit to the business is achieved if the final outcome has not been completed.


Even so, the assessment of the relationship between processes is powerful and fits neatly with the ideas of an elementary process put forward by McMenamin and Palmer way back in 1985.

This has been the cornerstone of our approach to BPs and their modelling for over twenty years and provides a firm foundation for scoping processes and BPs. In our view a BP comprises a set of inter-dependent elementary processes, each elementary process being triggered by a business event. Not that different to Sharp but we would allow a process on the m side of a 1:m relationship to be in the same BP as the preceding process, should the business wish to see it that way. What Sharp has given me is a new way to check that the time delay implicit in the 1:m relationship is based on need and not whim.

A good book, well-written and with some thoughtful ideas.