So, I just wanted various views and opinions (So that I can pick the best) of how to approach documenting a current business process? I know modeling it would be the basic step, but other than process models, what other artifacts can be documented?? Also, do you just keep the client in the loop of telling him what you have documented? Simply by getting a sign off on the artifacts? What can we as BAs do, to make it more efficient.
Thanks,
Utsav
Utsav,
The best place to start is by getting the clients requirements, that way you are mapping process within a scope and this will be a big help when you come to get sign off from the client. Furthermore it helps you with change mangement. If you go in with what you think is right and then approach the client and the client tells you that wasn't what they wanted your investment is sunk.
When the you have left the client who will own the processes that you have mapped? If it is the client then you need to involve at the earliest possible time.
In terms of what you should document that would be lagerly driven by clients requirements but things that you may need to consider the resources responsible for carrying out the tasks, the process owner, work instructions, measures - how the process and activities are performing, business rules and screen shots of any system screens that are used.
Adam
Thanks for the reply. In my case our client wants to switch to our system and we are documenting their current process to make sure if our system is a good fit for them or not. So I guess, I need to start with their current pain points, which might become my source of requirements later on. But thanks for the reply. :-)
Yes client requirements need to be documented first, but how does one do that? How doe an analyst position use cases, data flow diagrams, BPM diagrams, and activity diagrams relative to each other? The primary considerations are:
1.) How big is the system. Big systems at the high level are characterized as having processes that have no definable sequence: the processes can occur in any order. Therefore, sequence-dependent techniques such as BPM diagrams and Activity diagrams are not applicable.
2.) Which techniques are strongest in guiding the analyst through the partitioning of the processes. Big systems need to be documented using decomposition; there is no other way of handling complexity. And unless a logical, natural partitiioning is used, decomposition soon becomes unattainable.
3.) Which techniques employ a lithmus test of completedness? That is which techniques make logical "holes" in process analysis glaringly evident?
I feel that Michael Hugos (author and contributor for CIO magazine) has it right: Some tight data flow diagrams, ERD diagrams, and screens shots is all that is really needed. This is AGILE.
Tony
Hi there
How are you getting on with documenting the current system processes?
I am being interviewed for a role which will require me to do this & i am a bit stuck on where to begin with this as I am not typically a BA!
brought to you by enabling practitioners & organizations to achieve their goals using: