|
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 […] In Part 2 we took a moment to remind ourselves that the customer owns the process and that we must be sensitive to that. Having been presented with a documented As Is change control process, we must investigate what the stakeholders think about that process. There are different techniques available to […] In Part 1 we took a look at a sample As Is change control business process as presented to us by our fictional customer. The customer owns the process Don't go stomping all over the customer's processes like you own them Our next goal is to produce a To […] In a previous series of posts we took a look at drawing workflows. However, before you draw a workflow, you really have to understand the underlying business process. Remember that our definition of a workflow referred specifically to the identified work object. This is because the workflow does not cover the […] 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 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 […] |