Throw the word ‘process re-engineering’ to an organisation, and you may scare people. It might be because they don’t know what’s involved, or it might actually be because they have had experience, and think you mean large scale change.

I don’t think process re-engineering needs to be that dramatic. Certainly my experience of it is not so dramatic. The end goal is not looking at the processes to necessarily always bring about change. In most cases you are leading people to discover the issues themselves, just through discussing what they do and what the hand off points are. You are aiming for the ‘ahh ha’ moment, not the ‘argh’ moment!

I undertake process re-engineering on the basis of wanting to understand the day to day basis of a business, rather than going straight to the issues and resulting solution. The starting point is recording the deep dive into your business processes. What is ingrained in the business that is never talked about or formally documented? Detail every single step and pass off point, who is involved and what parts are automated and manual. Documenting it opens up the ability to see where elements are double handled and areas that are manual that don’t need to be. More importantly, people often learn things about their role that they had not thought about before or had taken for granted.

In our most recent experience, it took us a few days to walk around all the different departments of a company and ask them what they did, who they interact with, and how they did their job. The output of this was a depth of analysis and insight into the organisation that even upper management acknowledged. It provided a platform for investment decisions and new project initiatives.

I have done this for operational processes, logistics handling, and as a basis for application development projects. In all cases, you interact with the people who are the touch points of the detailed end to end process, focusing on the who, what and how. You also can’t just look at one section or department, because there is much to be found in what happens in hand-offs between departments. The assumptions that are made often don’t enable an understanding of how everyone’s roles link together in the business.

The end goal is a focus on the business structure and processes that may have become blurred. A key benefit is the foundation created for improvement, as well as the active knowledge management from documenting and retaining process knowledge that commonly sits in people’s minds.

So what is a modelling tool and how does it work? Why would I pay big dollars just to draw pretty pictures that I may or may not use again? Why can’t I use PowerPoint, Visio, Excel? The answer to all these questions and more comes back to one thing, “Why do you want to capture your processes?”

Most people are familiar with the term process mapping which is, in a nutshell, the sequencing of a number of tasks in a diagram to produce the end result that we call a process map. Historically this is represented by using two dimensional mapping tools such as Excel, PowerPoint or even VISIO. The resulting ’picture’ is a representation of the tasks that go to make up the process and that is all. Often the output is used briefly, if at all, and then ends up on the bottom of someone’s drawer or lost in the great black hole of documents on their hard drive. Sound familiar?

Business modeling is the sum of so much more. A common definition of modelling is:

“the capture, documentation and analysis and design of the structure of business processes, their relationships with the resources needed to implement them and the environment in which they will be used”

What this means in plain English is that business process modelling (BPM) models the process tasks and their interaction with the environment (e.g. office, customer), systems (IT stuff!) and resources (e.g. people, organisations, and product)

Modelling enables the viewer to understand the relationships between different processes, data, IT systems, people and skills. It captures and aligns with business objectives, products and services and records risks and regulatory requirements. It even allows and assists IT developers to design or improve systems to better support the business.

The above is all very nice but why would I want to ‘model’ rather than ‘map’ my processes? Good point. If all a business wishes to do is to gain an overview of the tasks involved in a particular process then all you need is a mapping tool. You probably already have access to one of these if you have Microsoft or Apple software. Mapping tools are also easily downloaded from any ‘open source’ supplier on the Internet.

If, however, you really need to understand all the components, relationships and interactions of a process then you need a modelling tool.

Process modelling takes things to a much higher level. A model is a ‘living’ document. It introduces rigour and standardisation (models are based on a common methodology). It enables analysis of relationships and data and can even be used as a base for simulation and rapid process engineering. In short it enables you, or anyone else, to gain an understanding of how your business operates.

So questions you need to ask yourself if you are considering capturing your business processes:

• Do I need an understanding of how my business operates?
• Do my business processes align with my business strategy and key performance objectives?
• Are my processes aligned to and support outcomes to my customers?
• Are my systems working effectively to support my business?
• Is my business complex and/or operating in a complex environment?
• Do I have enough/too many staff to carry out the day to day running of my business?
• Are my staff often involved in ‘workarounds’ or frequently fixing errors?

If you answered yes to any, or a number, of the above then it is worth looking at a modelling tool to support your business.