Introduction to Business Process Management

Think about the last time you made a cup of coffee.

I generally use a French press to make my coffee and there are several steps to make one cup o’ Joe. I have to fetch the beans, grind them, place the grounds in the pot, boil the water then pour it on top of the grounds (with an artful swirl) and, finally, I press the filter down after a wait of 3 1/2 minutes.

Making coffee is something that most of us do without thinking. However, there are many business process concepts that can be illustrated here.

1. Processes are often done without any thought – it takes some discipline to think through every step and document exactly what needs to take place.
2. A functioning process often has lots of room for improvement. Instead of boiling the water after grinding the coffee beans, I could have started the water boiling and ground the beans at the same time. This would create a parallel execution path and would decrease the time to completion.
3. Since I make an entire pot, it takes exactly the same amount of effort to create 3 cups of coffee as it takes to create 1 cup of coffee. However, if I needed 4 cups of coffee (for a meeting), it would require twice as much effort since I would need to do this process twice. If I had to produce more than 3 cups on a regular basis, a simple optimization would be to get a bigger French press. With one equipment upgrade my process workload is cut in half.
4. There are a number of tasks in this process that are left implied, but need to be explicitly handled. For example, the assumption at the beginning of the procedure is that the pot is clean and ready to make a new cup of coffee. In addition, it’s assumed that the beans are available in sufficient quantities. Cleaning the pot and stocking the supplies are procedures that need to be handled, but are outside the scope of this one process. Likewise, many real world business processes have interdependencies that can’t be ignored.

It may seem overly simplistic to draw real world business process concepts out of the procedure to make a cup of coffee; however, many successful companies have been built on exactly this sort of replicable procedure.

BPM is ultimately about looking at a business as a complete system. People and systems both work together to accomplish the overall goals. A BPMS allows your disparate software systems to integrate with the day-to-day tasks of your staff. I like to think of BPM in terms of “Business as software”. When look at your business as a software application, it changes the way you run things. Let’s look at a real world example. A sales rep closes his first deal for a new website with Bow Tie Websites. The client would like to have the domain www.acmetoothpicks.com. However, they are unclear about whether they currently own the domain (or a variant of the domain). So a process is started to secure that domain name. This is a perfect example of a process that could be automated. A search through WHOIS tells us that the domain is available, and most domain registrars have sophisticated APIs to automate everything. However, if we tried to automate the process before we set up this website, we may well lose the business. Automating the process could take several weeks and the client wants the website finished sooner than that.   So, we build our first version of the process with people executing the steps. A person is much more flexible than a program and they can handle a task like “Search WHOIS for acmetoothpicks.com” without explicit levels of detail. Each task must have general instructions and specific outputs – but a person will always handle the unexpected better than a program. Image 1.1 shows the basic process using standard BPMN. Don’t worry about the notation specifics; we’ll cover them in detail in later lessons.

Life Cycle

If you have a technical or programing background, you may be familiar with the software development life cycle. The BPM life cycle is very similar. As we talked about in the previous section, BPM becomes much more straightforward if you think of a business as a software project. In both cases (software development and BPM), the life cycle is iterative and is based upon the concept of continuous improvement. Image 1.2 shows the general process and the actors in it. Image 1-2 – BPM Life Cycle   The upshot of this cycle is that at no time are we having designers create whitepapers and submit them for comment before “tossing them over the fence” for the developers to implement. A practical, functional system is one that is highly collaborative. A designer often will sit with the actual implementer (or “domain expert” if you prefer the business parlance) and discuss how a process is accomplished. The modeling happens at the same time to create a functional, executable process on the fly. This process will be run and watched to confirm that it does, indeed, do the job properly. If it doesn’t, it will be optimized to catch special cases and missed scenarios (and the process starts all over again). Common questions a designer will put to an implementer are:

• Is this what you do?
• What happens when you get the information back?
• Where do you record that detail?
• What happens next?

During the course of modeling and execution, a designer will discuss with IT, managers and system administrators the technical implementation details to actually execute the process. Common points of discussion with IT and managers are things like:

• How do we connect to that database?
• What will we use to log users in?
• What are the Key Performance Indicators (KPIs) that we need to monitor?
• Where and how will we deploy Bonita?

While the process is executed, designers will talk with the end users to determine if it works the way the users expect it to.   Generally, this is the point that a designer will get the most practical feedback. Some of the information gathered at this point comes from analysis of the processes themselves. Other (often better) information can be gleaned from conversations with the end users. Good questions to ask at this point are:

• What could we do better?
• Where are the bottlenecks?
• Is this task clear enough?
• Do you have all the information you need at every step?

The optimization part of the life cycle can deal with everything from changing the process flow to remove bottlenecks (or split linear processes into parallel processes) to changing repetitive human tasks to service tasks. Be careful with optimization, often it’s possible to break a functioning process by optimizing for to specific a scenario. Things to think about during optimization:

• Should we split up a process so two people can work at the same time?
• Do we need to upgrade hardware or software to speed things up?
• What tasks could a computer do more efficiently than a person?

• Sometimes a wholesale change may be required of the way an organization does a specific process. Just because something has been done one way forever does not mean the current way is the best way.

Processes should remain fluid and dynamic. The point to stop when developing a process is when that process is “good enough”. If it does the job, does it consistently and efficiently, then and only then will we call a process “done”. Could we optimize further? Almost certainly… But, the law of diminishing returns applies. Generally, it is better to move on to a new process once an existing one has been optimized a couple of times.

Process vs. State

A developer mindset is usually centered on data and state. Is the door (object/data) open or closed (state)? To develop a system with this design philosophy, we must first abstract every part of the business into business objects which can then be interacted with programmatically.

In contrast, a BPM designer comes at problems with a process oriented paradigm.

Since Bonita takes care of most of the implementation details, a BPM designer can think more in terms of actions, events and decisions. This mindset is much closer to how real business works. The “Business Logic” is built into the process itself. As a result, a process-centric system will be much clearer to users and be much simpler to implement.

What is a process?

Most processes can be distilled down to a series of if-then-else decisions, they don’t rely on “black box” business objects and are much easier to understand and work with.

The following questions help define a process:

• What is the particular business scenario covered by the process?
• What discrete steps does this process break down into?
• What events could start the process?

Once a process is broken down into steps, ask questions like this to further understand the process:

• What happens now?
• What happens next?
• If this happens, then what happens?

A key point to understand about business processes is that they can (and often do) span multiple departments and integrate with other business processes.

The example above checks domain availability, but the process itself is started by an event triggered when the deposit is confirmed paid. This process comes from the accounting department yet it triggers events in the technical administration department.

Another example from a different business context would be when a sales order of a physical good triggers an event to restock inventory in the warehouse.

What is Business Process Management Notation?

Business Process Management Notation (BPMN) is a standard graphical notation for modelling business processes. The Object Management Group (OMG) proposed the first version of the standard in 2004. The OMG is the same group who proposed UML, CORBA, Data Distribution Service and many others. The current version of BPMN is version 2.0 (which was released in 2011). Basically, BPMN provides organizations with a standard way to define, exchange and collaborate on processes. By using a standard to define the process, different users can use different tools and still communicate effectively. If a designer created a process flow in Visio, the final process could still be implemented in Bonita. Image 1.3 – Core Set of BPMN Elements (source: OMG – bpmn.org

Image 1.3 displays the core elements of BPMN. There are essentially four types of elements to concern ourselves with. Flow objects contain the details of what needs to be done and decisions that need to be made. Connecting objects join flow objects together into a logical sequence. Swimlanes define the process boundaries. Artifacts define details related to flow objects. So, what is a Business Process Management Solution? In short, it’s a set of software tools to implement BPM in an organization. There are a number of solutions out there, but the vast majority of them are accompanied by legions of consultants (which generate a final price tag with far too many zeros at the end to be palatable for most businesses). This course (and the whole site, really) covers the BonitaSoft BPMS. While much of the BPMN sections and design principles could be used in other systems, we will focus exclusively on the Bonita solution. Something to be very clear on: In Bonita a pool is a process and a process is a pool. The two terms are completely interchangeable. Image 1.4 – Bonita Implementation of BPMN