Peter Schoof posted this question: How much time should be spent capturing the ‘as-is’ of business processes? What follows are two of the ‘no’ answers and one very good suggestion.
- Reality of business processes in large organizations are that legacy remnants that may have no rhyme or reason – “that’s the way it has always been done!” may the standard reply. Plus new technologies may help you completely throw away as-is processes with may be self-service ones. For example, if you can just get rid of phone registration and do only online/mobile registration and that too self-service saving yourself money in the process, why bother documenting old processes?
- ‘Spending time’ to capture as-is processes is a waste of time. The time must be spent on defining the business architecture models before anything can be captured, defined, guided or improved. The process in terms of flow is utterly irrelevant for improvements and if you bring in Six Sigma you get more bureaucracy than before.
- Depending on the overall commitment and readiness of the company, automating the ‘as-is’ process might be the best place to start.
There are some really good reasons to capture your ‘as-is’ process.
Process Improvement – You can’t make an improvement if you don’t know what you are trying to improve. If you try to ‘fix’ [remove, add or change] something in a process, you could break something else or make it worse. You need to know the ‘before’ in order to compare with the ‘after’ – only then will you know if your efforts have been successful.
Metrix – Companies usually take on BPM to solve a problem. Examples include: The process is taking too long; An activity in the process seems unnecessary; or, The way your customer interacts with the process is not optimal. If you don’t measure the ‘as is’, how will you know if the changes you make to the process are actually improvements?
Success – When undertaking this kind of project, upper management will want to know if the project was successful. Success usually is backed up by numbers.
Can you tell your management that your project was successful without giving them numbers?