In Part 3, we identified problems with the As Is process by interviewing our fictional customers individually and by having a group workshop. We did this in the light of the strategic objectives of the business.
We need to restructure the As Is model to take into account these problems and objectives. Firstly, we produce a high level To Be model to take into account the comments we noted on our high level As Is model. This allows us to take into account certain improvements to the process before we down into the details of individual steps. Remember also that having a high level To Be model allows us to plan our workshops by process stage.
BPMN
I have been using Business Process Modelling Notation (BPMN) as developed by the Business Process Management Initiative. You can find a key to the elements on a BPMN 2.0 poster by Dr. Bruce Silver of BPM Essentials (where I received my BPMN 2.0 training and certification).
If the business process is particularly long and complex, you won’t be able to fit it onto a single page and you should consider breaking it down into several diagrams, perhaps each one representing a stage on the high level model. Such detailed stages are known as “expanded Sub Processes” in BPMN. You can see several “collapsed Sub Processes” on the high level model. The low level model consists entirely of the corresponding “expanded Sub Processes”. BPMN does not require you to use Sub Processes, but it is a handy technique if the diagram is large or complex.
Notice that each of the tasks in our high level To Be Process is a collapsed Sub Process. We could have put all the detail in a single diagram, but that would have made the diagram unwieldy.
The sum of the high level model plus all the expanded Sub Processes makes up the low level model. You will notice that we have taken into account the strategic objectives and concerns examined in Part 3.
Now that we have a To Be business process model (you can download the Visio file here), requirements analysts can use it as the basis for meetings with the customer to establish high level system requirements, which (you may remember) will form the scope for our Change Control Workflow project.
In Part 5, we will document the high level system requirements.
Leave a Reply