BPM Consultancy
With the latest research indicating that over half of all software development projects don't deliver what users wanted due more often than not to a breakdown in the requirements gathering process, investigating alternative methods should be high on the agenda of any organisation about to embark on a new software project.Although there are some powerful established techniques available to analysts and developers to help them analyse and define requirements, it is alarming to see over and over again that the software delivered did not match the users' needs. Perhaps this is indicative of the fact that most organisations don't know what they do. In other words, they know what they want but they don't know what they need.
Our job therefore during the requirements analysis phase of the project is to identify the client's business processes and document them. We do this using the Metastorm BPM Designer tool. We build the business process (which we refer to as a Metastorm BPM procedure) with interactive audience participation and we find that this technique produces immediate results. We then run the procedure through a web client - that's right, the users can instantly review the business process from end to end and with immediate feedback, we can incorporate this 'dynamic' feedback into the procedure and present it to the users again. We refer to this activity as "Prototyping the Process".
Of course, vendors as well as implementation partners will normally do a certain amount of analysis along these lines too but in an 'academic' way. They will generate 'high level process maps' that describe what they think (or what the client thinks) the overall business flow should look like. Unfortunately, unless you go down to the lowest detail, it will not be obvious that in actual fact no-one in the client organisation actually knows how their processes work in detail.
When we write our process prototype BPM procedures, we attempt to extract every detail of a client's business process in such a way that they become visible to every person involved. If there are disagreements, we attempt to resolve them there and then.
Over the years we've developed this approach for capturing this kind of information in an efficient and effective way. We get a number of users in a room, and we map out the process with them. There are a number of advantages to this:
 |
We find out as much out about the process in the shortest possible time. |
|
|
We achieve buy-in from the people in the room for the process that we design for them, resulting in a strong feeling of ownership. |
|
|
The client gains a deeper understanding of the format of a Metastorm BPM procedure |
|
|
We identify and resolve any disagreements within the group regarding the existing process and how it should function. |
By the time we've finished our prototype, not only is the actual business process written down, everyone has a much clearer idea of their own responsibilities in relation to others in the process. The overwhelming benefit we bring to the organisation is that when the process is documented and the client wants to automate what they do, there's no confusion about requirements, and we are able to use the prototyped BPM Procedure as the basis of the system itself.
The BPM system that is deployed is therefore much more easily understood by users and managers alike. If the process subsequently needs to be changed or improved, the revised procedure can easily be prototyped from the existing system, and the cycle starts again.