Process Models: Who is doing what?

Every Business Analyst and Business Consultant should know something about Process Models and Process Modelling. Creating a simple model of what is happening outside the IT System can be a very useful place to start. You may even benefit when there is no IT System at all!

Ways of using Process Models

A Process Model is simply a representation of what the process is doing in the real world. This representation is usually graphical. There are different notations, and a large number of tools to help you draw the pictures.

Trivial Process Model - Documented using a Process Modelling tool — Trivial Process Model – Documented using a Process Modelling tool

Process Models can be used in a number of ways, many of which overlap.

A model can be used as a framework to assess the process against some criteria.
Models can be used to explore the effect of some change to the process.
Models can also be used to show how the physical world and IT interact.
Using Process Models appropriately can help ensure that any changes are beneficial to the business.

Process Models: “As-Is” and “To-Be”

Process Models can be used to explore changes to a process. The “As-Is” model shows how the process works now, and the “To-Be” model shows how the process will work after the proposed changes. Comparing the two models allows us to demonstrate how the changes will be beneficial to the business.

The changes need not be changes to IT systems. The benefits which can be demonstrated may be the elimination of roles, or reduction in time or the number of steps.

Process Models: How does IT mesh with the business?

Gears - Process Models show how things interact — Gears – Process Models show how things interact

The Swim-lane process models demonstrate how different roles collaborate or people use several different tools or IT systems to perform their work. Imagine the different roles or tools as “gears” and you will understand what I mean. Using swim-lanes helps you to visualise and communicate how the different lanes interact.

Traps you can avoid using Process Models

Where a business process involves activities in the physical world (and not just doing things at a screen) then a process model can help put the IT systems into context. Doing this may prevent you spending time on details which are not important.

Ways Process Models can trap you!

Many process modelling tools allow you to break-down individual steps into smaller pieces. Resist the temptation to break things down too early, or everywhere. If you keep your models at a high level you will reduce the amount of work you have to do, and you will not reduce the value of the models.

Conclusion

Process Models can be used to put the IT system into a wider business context. They can even be used to analyse and rationalise processes where the IT systems do not play a significant role. Process Models are commonly used to demonstrate the claimed benefits of a new way of doing things, the so-called “As-Is” and “To-Be” models.

The keys to success with Process Models are to present the simplest model which is appropriate for your needs and to control the amount of detail.

Context Diagrams: Putting things in Context

Simple Context Diagram

Every Business Analyst should know something about Context Diagrams. I often draw an informal Context Diagram as the one of my first activities when I start a new project. Context Diagrams are good for focussing the mind and reminding you what you don’t know and need to find out.

What is a Context Diagram?

You have almost certainly seen Context Diagrams, even if you haven’t recognised them by name. A Context Diagram is a shape (usually a rectangle or circle) which represents “the system” which is the focus of our interest. This shape is surrounded by other shapes which represent things like:

Users of the system (or actors)

Other systems

The satellite shapes are joined to “the system” by lines. Sometimes the arrows on the lines have real significance, sometimes they are there for decoration.

Context Diagrams were commonly used as the top-most level in decomposition methods (such as SSADM). They are still with us in the form of the Use Case diagram in UML.

When are Context Diagrams useful?

Context Diagrams are useful at towards the start of the project. They are good for communication and especially good for summarising who and what interacts with the system.

Although they don’t define our system at all well, they do make it clear what is outside. As a consequence, they are good for communicating “scope”. I even use them to help define scope during project initiation.

A really good use of Context Diagrams is to emphasis interfaces with other systems.

Limitations of Context Diagrams

There is something seductive about a well-drawn Context diagram. It seems to say a great deal, but actually it doesn’t say a lot.

It is wrong to try and make a Context Diagram do too much. Imagine a diagram with tries to show connections with 100 different objects. It would turn into a mess which nobody could read. As a result, the number of satellites is often edited. That makes the diagram easier to read but removes important information.

As a consequence, Context Diagrams are best used for illustration and communication, rather than definition.

Conclusion

Context Diagrams are a great way of providing overview and “putting things in context”! They are easy to produce and people understand them intuitively. They are good for communicating ideas to a non-technical audience.

To get the best from Context Diagrams you have to recognise their limitations. They are good at describing what is outside “the system” but they say very little about the system itself. They are not very good for detailed definition, and if they contain too much detail they actually become less useful!

Month: April 2017