|
It’s important to keep one’s skills current and to seek constantly to improve the way one does things. With that in mind, I have been brushing up on BPMN 2.0 recently and taking a course by BPMN guru Bruce Silver. As a result I have tidied up the diagrams I produced for the series of […] In the previous posts on this topic, I have suggested a definition of “workflow” and I built on some high level statements of requirement to draw a visual model of a leave request workflow. I have broken down the drawing into several steps for the convenience of demonstrating the technique. However, […] In Step 4 we modelled the exception path when a leave request is rejected, but to complete our diagram, we need to take into account any SLAs. SLAs can be documented textually as part of your business rules catalogue, but how they impact your flow should appear on the diagram.
In Step 3 we continued our workflow by exploring the path where the leave request also requires the approval of the HR Department. Now we shall investigate the exception paths when the leave request is rejected. In this case, when the Requestor reviews the rejected leave request, he can choose to […] In Step 2 we continued our workflow by using connector shapes to show the flow between the different stages of the work. In this step we are going to model any alternate flows that still lead to an approved leave request (in this case, just one alternate flow). The business rule […] In Step 1 we started drawing our workflow based on what we knew from the high level statements of requirement in the project scope. The next step is to start connecting the dots, the dots being the functionality available to the users. As I said in another post, we […] In the foreword, I suggested a definition of “workflow” and provided some high level statements of requirement which provided the scope of our leave request workflow. I also said that four of those statements could be investigated in the form of sub-processes, use cases or user stories. I have tried to comply to […] A workflow can be described as a repeatable co-ordination of activities that affect an identified piece of work (work item), across multiple roles and governed by business rules, beginning with the generation of the work item and ending with the resolution of the work item. I am quite specific in my […] |