"So what happens if it fails this check?". The question was a simple one but the answer would cause lots of problems. I was working with a group of people looking to document their internal processes. They had gone the easiest route prior to my arrival by putting their thoughts down in Visio documents. Unfortunately they were not proficient in process definition and the models they had created were -frankly - useless. So I sat with the business analysts and went through each model trying to understand what they were trying to do. For the most part the process was quite easy to understand, although the models needed a lot of work to clean them up and have them make sense.
The problem started when I took a step back to review where we were and what we had documented so far. I realised that I had complicitly fallen into the same trap that they had of only documenting the 'ideal' process.
In every instance of the models the logic was predicated on everything working faultlessly with the process. Hence my original question "What happens if it fails this check?"
You see we had put together a workflow which followed the path of a business transaction through it's various steps. At one point we had an activity 'Validate transaction' followed by an activity 'Update system' ('Verb-Noun', you see. Good process modeling standard). It occurred to me that we were assuming in this case that the transaction would always pass validation. But I knew that wasn't always the case. It was entirely possible for a transaction to fail validation at this point. Our process had no logic to deal with that.
We could, of course, have pretended that the activity of validation included dealing with the items that failed validation. Indeed if this was a top level workflow that detailed the overall process rather than a specific part I probably would. But it wasn't. It was a detailed workflow model. If the logic wasn't included here it would not be included anywhere.
Looking over other diagrams it was the same story. There were no exception processes and nothing to deal with problems or unexpected items.
Now the issue was trying to make the client understand that there would be more work involved in defining what would happen in 'real life' as opposed to 'process life' to allow for the exceptions and the problems to be dealt with. That didn't go down too well.
So here's my question to you: When you're working on designing processes, do you always document the ideal process or do you include logic to deal with situations that don't follow the 'standard process'?
I would be amazed if everyone said 'Yes'
