Starting the BPM Implementation: Best Practices in Business Process Management

Business process management (BPM) is used for managing and optimizing the efficiency of a business. Though there are myriad benefits to BPM implementation, improper deployment can jeopardize the overall success of your business critical objectives. This article will help ensure the success of BPM implementation while mitigating the possibility of any potential risks.

Discern how your business operates

When implementing BPM in your organization, one should establish a starting point. You can use business emails, phone calls or chats to extract relevant information about how your business operates. After you have established these benchmarks, you can evaluate and develop a workflow model that you wish to implement in your organization.

Prepare a Roadmap

BPM can do a lot for your business. It can help improve decision making by providing more timely and accurate information. Moreover, it can greatly reduce the pain of labor intensive processes. This will help greatly in prioritizing tasks and requirements. This is an important step that is often overlooked. The roadmap will help highlight the gap between where you are and where you want to achieve.

Think big, act small

It is important to consider that modifying your processes without proper planning could affect your business and operations. While implementing this software, consider starting with a smaller and easily manageable project. When you start with a small yet easily manageable project, you will produce measurable results that should ease the way for wider implementation.

Involve all your stakeholders

There are usually three major stakeholders involved with most BPM deployments. These are business users, IT people and end users. Make sure that you make collaboration between your developers and your end users throughout the deployment process. This will ensure that your BPM application is actually usable and can make the difference.

Choose the tools that best suits your needs

When implementing BPM in your organization, make sure that it answers needs of the business users, IT people and end users. Usually, top level management need to track business processes with a primary focus on quality, scalability, security, visibility, and efficiency. Users want something simple and easy to use software system.

Use professional services when necessary

You are likely to achieve far better results when you contact experts consultants. The main benefit of hiring consultant is the experience they bring. This is especially valuable in the case of software implementation where a minor flaw or miscalculation could create major problems. Using a contractor may cost more upfront, but expertise pays off in the long run.

At last, we will close to a few more pointers to make sure that your mission critical project is successful. Following the steps and guidelines here in this article, you should be able to meet or exceed your goals with BPM.

What is Business Process Modeling

Introduction

Before we can say what business process modeling is we need to know what a Business Process is! This may seem like stating the obvious, this is one of the most widely misused and misunderstood terms in business and in business modeling! Analysts and managers alike often use the term when what they are really talking about is a Business Function or a Business Procedure. No wonder there is confusion!!

Definitions

Business Function: "A coherent, discrete activity that a business must perform in order to meet its business objectives and continue in existence."

Business Process: "Describes the order in which Business Functions need to be carried out in order to achieve a specified objective."

So, in short, Functions describe what a business needs to do in order to continue in existence and Processes describe the order in which this needs to be done.

From this we can also see that it is not possible to do effective Business Modeling before we have modeled the Functions!!

The Building Blocks of a Process

The essential elements are:

• Objective
• Trigger
• Functions
• Precedence
• Outcome

Objective:

Every Business Process must have a clearly defined objective that answers the question "what is this Process meant to achieve?". If the business does not have a clearly defined (written) view of what is meant to achieve then there is very little chance of it achieving it.

It will not be possible to work out what Functions need to be carried out and in what order in order to arrive at the preferred Outcome.

In fact, without having a defined objective, the business might not be able to define what the preferred outcome actually is. This statement might seem simplistic but it is the primary reason why so many Business Processes are inefficient or fail altogether.

Triggers:

These are events that occur that require the business to respond in some manner - they "trigger" a response in the business. Every Process must begin with at least one Trigger.

Outcomes:

Other events occur as the result of activities carried out by the business itself and these are called "Outcomes". In every Process the business gets from the Trigger to the Outcome by carrying out Functions in the correct sequence.

Precedence:

Precedence is not, as many analysts mistakenly believe, a definition of how the steps within a Process are triggered. A more effective definition is to say that it is a very specific way of defining what Functions must have been completed before others can begin.

The succeeding Functions can then begin at any time convenient to the business, in accordance with existing business rules. This definition is especially useful as it makes the business ask the question, "before we begin step X what other steps must have been completed?"

More on Outcomes

There are two types of outcome that can occur in a Business Process: Preferred and Non-preferred.

A Preferred Outcome is the result that the business would like to achieve as the result of successfully carrying out the Process and should correspond to the stated objective.

Every Process must have at least one Preferred Outcome.

A Non-preferred Outcome is a valid and controlled outcome other than the Preferred Outcome.

Suppose that we are taking orders from customers. The Preferred Outcome would be "order authorized" but a Non-preferred Outcome could be "bad credit rating: order declined". A Business Process can have several Non-Preferred Outcomes.

Elementary Business Process

Each step in a Process is a Function, which comes from the Function Catalogue (see the foot of this article for more on this) and ought to be from the bottom level of the Catalogue as it stands at that the moment in time. Ideally, these should be Elementary Business Functions (EBFs). A Process drawn using EBFs is called an Elementary Business Process.

Decomposing Processes

One of the biggest mistakes analysts make when doing Business Process Modeling is to "decompose" (a lovely term!) Processes. This means that they break the Process down into more and more detail.

This is a practice to be avoided AVOIDED AT ALL COSTS as it has two main faults: 1) it requires drawing far more diagrams than are necessary (up to 300% more) 2) it introduces fundamental logic errors.

To avoid these errors all decomposition (somebody will have to think of a nicer word) should be done using the Function Catalogue and each Process model should be drawn using Functions from the bottom level of the Catalogue (preferably EBFs).

Summary

• Business Functions and Business Processes are NOT the same thing.
• A Business Function describes what the business ought to do; a Business Process describes the order in which it ought to do it.
• Business Process Modeling should ALWAYS be preceded by Business Function Modeling
• Processes must always contain all of the defined elements of Objective, Trigger, Outcome, Functions and Precedence.
• The objective of a Process should always be clearly sated in writing before the Process can be properly modeled.
• Business Processes ought NEVER be decomposed - this should be done using the Function Catalogue.