What to model – II

.
Now that we have a first idea of what our model of Business Process should be like.

However, what is it supposed to look like?

Well, as in any language, there are several levels of analysis: lexical, syntactic, semantic and pragmatic. Whereas the first two or even three depend on the language, the pragmatics define what you should obtain in real life.

Surprisingly, lots of information exist on those three first levels of language analysis. I mean “surprising” because they are just a means to obtain what you really want. This means that the modeler is given all this:

• rules about what he can or cannot express @ each level
• many shorthand & tips & tricks about how to translate from one level to the next
• rules of governance, because this gets really complex

This does not only overwhelm and give headaches to modelers, but the design space explodes because of the dimensions growth is exponential.
This is natural in approaches where the modeler should create a number of models that go from a very abstract one to –finally– one that is really executable, and those are written using different languages.

Since Intalio is not like other modeling tools, you can create your model and make it executable after very few changes. It is power at your fingertips.

I will start from the other end, the pragmatics, as a more natural way to constrain the business process design.

Actually, I will deal in this entry with what we should avoid (the design space outer space), in order to establish what we want to get (the actual target: BPM pragmatics).

THE BASIC THINGS TO MODEL
As I showed in a previous entry, a process model in Intalio is a description of what you actually do, in the form of tasks
Some features of that description are the following:

• Each task can be either composite (made up of other tasks) or not
• These tasks are performed by one or more actors
• The actors that fulfill the tasks are modeled via pools.
• The actors can be either organizational units, roles, real people, IT systems, or some unknown system.
• The most fundamental thing is that the functional/non-functional contract linked to each task is performed by some actor

Once we have understood what tasks and actors are about, we should start thinking of how to make them work together. This is done via communication:

• The underlying modeling principle is to make actors communicate in a proper, flexible, scalable manner.
• The model of sequence and synchronization will tell what action is enabled to be executed
• The process logic will tell the orchestrator if a given task should actually be triggered
• The actual execution will be performed by the orchestrator.
• Several actions can be triggered in parallel, each branch having its own process logic. The merging of branches is also done by the orchestrator
• When required, non-merging branches (or autonomous branches) can also be modeled.

What You May Not Model

.

• If your intention is to model operational risk, I strongly suggest not to use Intalio.
• If you intend to compute the organizational performance a priori (via benchmarking the working capacity of the organizational units in a company), Intalio may not be the tool you’re looking for.
• If you want to compute process time or process cost, this cannot be done directly. You should wait until having an executable process, and then this may be feasible. However, there are other tools that may fit much better this requirement.
• If you need just to replace a composite application, and you focus on low-level notions (synchronous and asynchronous communications), be warned that Intalio and BPM do not include those kinds of
  primitives directly, and that your modeling can be uncomfortable. There are plenty of BPEL-level modeling tools that might fulfill your requirements directly.
• If you already have a model process written in some other language like EPC, UML, OSSAD, b-Flow… do not expect to find plug-ins that will help you import/translate.
• If your requirements do include the creation of a process framework (or a process library/reference), know that Intalio does not provide any process repository functionality. You should build one of your own.

• If there is not need for an executable BP as a result of the modeling effort, you’re not going to use the maximum capacity of Intalio…
• If you have no need of rigorous semantics that help you build valid and correct Biz Process models, just use any drawing tool with the notation you prefer.

Of course, Intalio is a great tool, but you will get no satisfaction of using it for what it was not intended.

Beware of the Law of the Hammer:

The child who receives a hammer for Christmas will discover
that everything needs pounding
– Gerald Weinberg

.

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.