Different views impact Process Analysis and Design.

When in the requirement phase, the analyst will not only work with people that have a general understanding of the process, but will also have to interview different actors of the process in order to be able to see details beyond the idea of the business process. Through these interactions, he will see several views of the same process.

Sometimes there is a “Documented Process” – I mean a normative, a written rule that defines how the flows and tasks should be – that document is usually out-of-scope of the participants; thus, each of them knows just a little piece of the process, the one in which (s)he is directly involved.

Indeed, those actors might be unaware of the meaning of the process, or its value. They know portions of the “Real Process“.

At last, the owner(s) of the business process can have an idea of what their process is, different from the previous two, that I call “Ideal Process“: a process that gets to its objectives maybe without some behaviours that really happen in the “real process”, and a lot more pragmatical than the “Documented Process”.

Thus, requirement retrieval should not be based on one of those process views, but on all of them, on a conjunction of them. Each view will have pros and cons with respect to a project concerning BPM Deployment or Process Re-engineering.

Documented Process

Pros:

• It works as a clear objective of the scope that analysis, deploys and improvements should have.

Cons:

• It can be obsolete (because the day-to-day process may change in the mean time); basing analysis solely on this view, the product obtained in the project might be different to what expected.

Ideal Process

Pros:

• Is the process that serves to its owners’ goals. It probably addresses roles, process times and deliverables expected of the business process.

Cons:

• The owners may not be aware of the real practices developed in each role; even they may not know the real roles and tasks executed by the day-to-day process actors.

Real Process

Pros:

• It provides the closest information of the tasks done by each actor. It reveals tasks, uses, redundancies and problems that no one knows (because owners don’t see that level of details, and actors may not know what other actors do).
• It has a real view of the costs of each task.
• It’s useful to define interfaces with users, systems, etc. This is important in order to fight against deployment resistance by the users.

Cons:

• It can add noise to how the BPM analysts view the process. This view must be approved by the owners, in order to know if differences are based on pragmatism or day-to-day negative deviations.

In the next article, I will go deeper into these views of a process, trying to identify how to use the best of each one, in order to design a successfull process.

Follow