A question (or even discussion) often heard in projects is, if we should start the project doing business process analysis or jump directly to specifying requirements for the system. Often it is not an either or question, and it really depends on what you want to accomplish.
In short you can say that Business Process Analysis is about: understanding the problem/context while requirements is about: specifying what is needed in order to solve the problem (what must the system do?).
So, the question is what you need the most; understanding the problem or specifying the requirements in order to solve the problem?
Below, I have outlined what I find are the top 10 reasons why Business Process Analysis should be considered before digging into the requirements specification:
1) You don’t fully understand the problem or the context you are dealing with
One of the most likely reasons to fail with your requirements specification is, if it is build before you fully understand the underlying problem. Sometimes time pressure pushed you in that direction. The result is very likely a vague requirement specification that doesn’t fulfill the desires and expectations.
2) You want to procure a standard system
If procuring a standard system you don’t want to specify every detail. Instead it will be better to specify the processes and functional requirements the system must support. For example when procuring a standard system you will not specify the screen mock-ups involved with fields and features needed. It will be must better to specify what processes the system must be able to automate, and what key functional requirements must be fulfilled.
3) You want to optimize the existing processes
If optimizing the current business processes you obviously need to start analyzing the business processes.
4) If it is important that the system fits the business processes
If it is important for your project success that the system supports you business processes and not enforces changes to your business processes, you need specifying what processes must be supported.
5) If the business area or system to develop is representing a competitive advantage
If the system you are going to build is supposed to bring a competitive advantage to your business it is most likely that the competitive advantage has its offset in the business process design – for example by doing things faster, cheaper, in better quality, or by determining manual processes that must be automated.
6) If it is unclear what main functionalities the system should have
This related back to reason number 1.
7) If it is unclear what processes the new system should automate
This is partly related to reason number 1, but also a question of knowing which processes it makes sense to automate and relate this to a business case.
8) If you already know the business process model
Then you are all set.
9) If the business processes can be derived very fast
If the business processes can be derived very fast – for example by taken advantage of business process mining – then, why skip it? It might bring valuable information
10) If you want to know what changes a system enforces to your processes
New system either supports the processes in place or enforces new processes to be followed. If you need to know the impact on your processes of a new system, you need to know you own current processes.
