Gathering Requirements for Business Processes
Business Process Development is agile, rapid and highly business oriented. Business Analysts face the challenge of figuring out what should be the best possible way of documenting business processes without making it an over kill. Here are some of the things which I have found to be helpful in documenting.
Get the AS-IS documentation
AS-IS or the current processes form the base of any discussion. If your client does not have an AS-IS document – beware, this could be tricky. Either he is not the right person or there is no policy. Either way you will end up wasting your time figuring out what's right and what’s not. If your client accepts that he is the right person but still does not have the document, then start by creating the AS-IS document first. I will try to write something on documenting AS- IS processes sometime.
Also, make a note of the issues with the AS-IS process. You need to know why is the automation being done.
Ask your Users what they want as a To-Be Process
Ask why they need to automate, what goals – long term and short term will this initiative solve for them. Ask how this to be process would solve their issues. Remember BPM is about business, if you don’t understand and appreciate their concerns you will never be able to build something.
Lock the Scope
Often discussions wander to I want this, I want that and so on. Try to chalk out a process scope while discussing itself. For example the scope of a leave management process could be – Leave Approval, ERP Update, Payroll reports. Seems to be simple right …. Now think of this, your client would have Holiday Calendars, Leave Policies, Regional Leaves, Payroll Implication of Leaves, Swipe card systems, Out of Office duties and so on …. A simple system like Leave management could take forever to build if you don’t freeze the scope at the very beginning.
Prepare a workflow diagram
Use a simple tool like Microsoft Visio or Even Power Point to draw the simple workflow. Indicate who would do what, what happens after what. Identify how the process starts and how it ends. A crucial part here is the fact that sometimes one single person may not know the entire workflow. You should document who will provide you details on which work step.
Prepare a Document
Prepare a simple document which covers the following
- Process Scope
- Stake Holders
- Process Diagram
- Mockup Screens
- For Each Worksteps
- Workstep name
- Performer and how would it be decided
- Basic description with what milestone is achieved here
- Fields – editable and non editable
- Notifications if any
- For Each Integration
- Brief description along with what you achieve
- Interface type
- Reporting Requirements
- Compliance and Other requirements
- Appendix – Add all current scanned forms etc here
Prepare a presentation
Once you are ready with something that could be built (do include your technical team in the decision), show them to the users and get their feedback. The more you engage them initially the less painful it will be later on.
Hope the above article helps you in taking requirements. Feel free to post your questions.