What to model

As I already discussed in this previous entry, the project of designing a complete BP model is made up of 3 phases. They all come from the pretty standard Work Breakdown phases:

• the normal, good-behaving case
• the alternative, however still good-behaving cases
• the badly-behaving scenarios: cases that were not covered/expected (exceptions) and errors.

(An interesting approach similar to this, but focusing on the type of audience, is presented by Bruce Silver here)

Doing this for a single process with a tool such as Intalio is a breeze… however, dealing with a real BP in a real organization requires having some development strategy that can help us prevent problems as well as being good for dealing with complexity.

A not-totally-eXtreme approach
I propose you to plan at least the construction of three deliverables at each phase:

• The raw process: determining the steps/activites in order to achieve the process
• the user-screens/forms: what information is required at each step, what information should be asked in order to make an informed choice later in the process.
• the association of process and forms: the creation of links among the process step and its user form (we just produced in the previous step).

The iterations
Each one of the phases is actually made up of a number of iterations. Each of these iterations aims to create a model. A common scenario looks like this:

• First iteration: the process as a single activity: a starting event (or set of events), the process itself, and the expected output. The process has a name, and some text can explain what kind of information is processed in order to produce the output.
• Second iteration: the process as a Start-Do-End sequence. The Start activity includes all the proces setup, and the introduction of information; the Do activity includes the portion where the real processing takes place, i.e. the business rules, the decision-making steps, the alternative branches. Finally, the End activity includes all the process cleanup taks, and the end of transactions (accounting, notifications, etc.). As a result, the user-screens start being specified.
• Third iteration: the initial Do activity is split onto a Start-Do-End sequence. It is clear that the application of the business rules, and the decision-making process is not linear, and require the decomposition of the previous model. In this case, more information is given in how the information is entered into the BP or retrieved by it; the source can be some person or IT system.
• More iterations: a concrete flow of information appears. Each user-screen can be related to an activity on the BP, and the way this information is reused farther down the BP dataflow becomes pretty clear.

Every iteration is accompanied of the corresponding validation. If several actors intervene in the process, each one of those should validate the corresponding data introduced by users. Of course, this won’t be complete for the first iterations, but it will become when both more details and IT are added to the process.

The amount of effort required for creating a good BP model depends on the nature of the current process and of the maturity of the current automation of that BP. For instance, if the process is already in a computerized form, it will require only the re-creation of the user screens; if it is still paper-based or an informal process (i.e. a task-list, phone calls, post-its, requests in the corridor, etc.), it requires a real understanding and formalization of the essential information.

The Process Owner
Do not forget to include the process owner as frequently as possible. She is the only one that has the global view, and the one that understands the global constraints of your project.
The participants of the many specific process activities do not posses enough information in order to improve the general process and to know where it is really applicable.
Besides this, is it the Process Owner the only person that can help you define what the good granularity of your model should be. I avoided this subject in this blog entry because knowing when to stop refining is a difficult subject, and because it all depends on your customer.

Never forget that the process owner wants to obtain some information from the Business Process itself. In a few cases, that result can be obtained simply from the very act of creating a BP model, and no more work is required. However, in most real cases, the process owner wants to obtain something else: to measure something (performance, queue lenght, seasonal variations, cost per instance, etc.), to avoid something happening (paper-based processes, process blocks/deadlocks, no escalation), to make something visible to people working on the real BP (feeding some enterprise portal, contextual information before making a decision, among many others), or some other result.

You MUST establish with the process owner what the bottom line is.