The main conclusion of my last entry is:
One of the missions is a time-management system for the administration of one of the “big” Swiss cities, and the other is a portfolio tool for the PMO of a big multinational. As you can see, time is used as the base of the modeling for the first mission, but only as a parameter of object lifecycles in the second. Both systems are rich, complex, and address the concerns of a broad population.
It is really interesting to see how modeling time can get really harsh when trying to formalize it.
Time is an intrinsic notion for humans, but machines do not understand this abstraction. Time helps explain simultaneity and sequencing. Temporal expression can be expressed mathematically.
Now, the fact that –in general– time notions are not formalized in organisations nowadays, means that we have to get the notions of time as understood by the target organization integrated to our analysis before we proceed further. This means working with the community around our Business Process.
It is clear that in the technical world we’re used to deal with more precise models, but you cannot be naive when dealing with the organization that owns the BP.
For instance, in my project for the city administration, people had different interpretations in different departments. Although the HR department had a set of rules “cooked” recently by a committee that has been working for several months, the HR PMs did not read part of the temporal specs in the same way as the IT PM did, and this was even different from what the HR department representative has traditionally used as criteria in her daily work. Although differences were only present in very specific cases, these were actually the most interesting ones (Murphy’s Law).
Even more important, because of the systemic nature of the BP Management projects, let us not forget our friend Heisenberg: you cannot measure without interfering. Once you start asking people and they understand that they were not paying much attention to the formality of the descriptions, they will wonder themselves and question others, and finally help you create a proper model. As a result, the organization will change, and many definitions too; not only this, but definitions and perspectives will change radically over time. Be careful to take measures that prevent change in specs becoming a routine.
Anyway, what you will obtain as specs is a Business Processes description far from the mathematical form. Why? because BPs are rarely specified by IT people. They must be taken from their raw expression and translated to a BP model using some strategy. I have sucessfully used this one:
- Perform some grammatic analysis, and be specially suspicious about all separation symbols (commas, dots, semicolons, bulleted lists, etc.)
- Identify sentences with letters or short names.
- Be always careful when people use sequence-related words like “First“, “Then“, “After“, “Hence“, “In order to“, “Next“, “Last“, “Finally“, and many others.
- Be alert of “big contexts” in the middle of the description. If not identified early enough, they can make you rewrite large parts of the model.This kind of sentences often return to the past, e.g. ” Before you can do action A or B, you must check…“
- Identify clearly the context of each sequence-related word in the sentence. I use various colors to facilitate the task.
- Label the newly identified sentences with letters or short names.
- Establish the sequence with the aid of your customer(s). It can be a simple draft in the form of a flow diagram or –even better– a BPMN model.
- Do not try to be much precise, get relaxed and create a skeleton smodel that makes sense. The interview/discussion with the customer(s) will give better results that pushing her or him. Avoid guessing whenever possible.
- By creating a rapid prototype using Intalio, you’ll be able to determine interactively with your customer whether the model corresponds to her/his expectations. She/he will certainly appreciate seeing the results immediately.
Of course, things won’t be this easy and you have to define a basic path for the first iteration. There are at least two special cases that I recommend to filter out, and to deal with only in a second or third iteration. They do not make part of the main path of the BP, and their context must be clearly marked (initiating/branching point and joining point, if any). If you want to read more about the xPD iterations you can find a first reference here.
- The first one is the processing of alternative paths: They are normally bound by expressions that either deal with conditions or return to the past: “If after X days, no acknowledge is received, then…“
- The second is different in degree because deals with abnormal paths (exceptions and errors). These are cases that are definitively out of the normal path. For example: “Otherwise, do Y…“, “If no one of those actions is finished after X days, then …“, “After N days of wait for R, the issue will scale to the manager“.
A final suggestion: For every and each model segment, try to work with a real business process actor. For real, I mean a person that deals with the level of granularity of your model segment. Don’t take a high-level view for granted because very often this means a late effort must be done to correct the model, with increasing costs.
If it is an segment considered as important by your customer, it is preferable to put off its modeling, and say it clearly.
