How does so much detail get lost in translation?
I have worked on many BPM projects and as such I have been party to the good the bad and the ugly of Process Design. I must start by saying "It isn’t easy”
Documenting complex business scenarios can be a challenging start to a process driven project, especially when you find out that this is the first time it’s been documented!
So what have I learned about how communication of requirements can be improved?
I believe that one key enabler is the design tool that is used. I am confident that you will all have witnessed a simple business design evolve into a complex fully developed process, where the business can't see the wood for the trees and IT are not certain that they have captured all the requirements.
Often, the business struggles to understand the complexity of developing their requirements and IT can fail to understand the business complexity of the requirements. Sounds a little obvious, but it’s true.
A good process design tool should help capture the detail and assist IT in coaxing requirements, the devil in the detail if you like.
In turn it should allow the business to gain a better understanding of how their process can come to life.
The initial flow designs in excel / Visio or an alternative generic design tool, is OK as a starting point. The business understands the simplistic nature of the design and it allows IT to grasp the flow very quickly.
However in my experience these should not be used to evolve the process as this can lead to IT assuming the process is going to be simple and straight forward.
At this point we need to get the process into a modeling tool that will enforce a modeling style that can be interpreted by a machine (and understood by human beings).
SAP like a bunch of other workflow/BPM vendors has adopted and contributes to the Business Process Management Notation (BPMN) standard (see BPMN.org).
Several companies provide such modelers with SAP providing 2 tools for this job :-
- Collaborative Business Process Modeler in SAP Streamworks SAP Social Software
- Process Modeler Perspective in NetWeaver Developer Studio (NWDS) NWDS 7.31 Download
The first one is used by Business Process Experts to define the process in a collaborative way without having to install any software (or pay any fees).The second is used by Business Process Experts and IT to create a process that can be deployed to the SAP BPM server.The good news is that you can exchange models between these tools (and other BPMN modelers), so my advice would be to play with each of them and use the right one for you and your use-case.So now we have the model in a tool we are on our journey to fleshing out the happy path and the unhappy path through the process in question.It is time to start asking tricky questions of the business like:
- Is this actually where the process starts? "Well The sales team do fill out a form first and send it to the business support team"
- Is there only one entry into the process? "Actually the guys in the field can email master data directly and they can start the process"
Even though you don't want to bombard the business with questions that complicate the process, the details that unravel at this point are crucial to the joint understanding and can be the foundation for development.
A traditional approach would see IT trying to define 100% of the process at this stage, with the business signing off prior to any development.
However a more successful approach is to start to deploy the process (with some dummy screens) so the business can see their process coming to life.
As an example, we recently took over a process development project where, after playing back the previous companies workflow diagrams, the business struggled to read their own process.
We took the process and create it in BPMN (ironing out some problems) and started to show how all the steps would hang together. It did not have all the bells and whistles, service calls and complex rules, but the basic flow, decisions and interactions with SAP were there for the business to see. They could visualize what the BPM Inbox looked like and could see the processes in the process dashboard.
Early adoption of NWDS helps drive the right questions from the business themselves.
Causing them to ask questions like "Does this mean only 1 person will receive an email.... it would be perfect if persons A, B and C could receive the mail"
For other projects where the process is really unclear or need input from people around the globe, Allowing the customer to be collaborative at an early stage can provide greater results and huge savings in time lost due to under developed process design and understanding. This is where the Collaborative Business Process Management tool inside Streamworks comes into its own.
If the customer is comfortable in an existing tool that conforms to BPMN, that is OK but the quicker you can get to a deployment and playback the more details you will flush out.
Another must do is to use annotations as you go. That way, when you hand over design to the development team, they understand what they see. They can ask more intelligent questions because of the detail added though annotations, and they have a head start, you've done most of the initial process drawing for them!
As a final thought, this approach won't solve all of the problems encountered at this phase in the project, but it can help a great deal in allowing the two parties to meet in the middle and shorten the gap when many a good idea or important thought has been missed.
This is my first Blog on SCN, I hope you enjoyed reading and any feedback would be much appreciated.
Useful Links
Link to Collaborative BPM (Streamworks)
alan.rickayzen
- SAP Managed Tags:
10 Comments
