Processes are ways of getting things done. All businesses run on processes, although in many cases the processes are ad hoc, scattered and inefficient.
Business process re-engineering (BPR) aims to rationalize and automate the processes as much as possible to make the business run more smoothly and profitably. It is a key component of installing an ERP system and it also applies to setting up a CRM system.
It’s important to understand that not every industry process can, or should be, automated in this way. Many processes are too variable to allow for successful automation. Others, such as deciding who to hire, require human intelligence to operate successfully.
The processes surrounding these events can, and should, be automated, but the core of the processes has to be left to humans.
BPR starts with business rules. These are conditions the development meets and which the system can act upon. Rules are the foundations of the BPR process and one of the first jobs in BPR is extracting and codifying the rules.
Business rules are usually expressed as IF-THEN-ELSE or CASE statements. While they can be embedded in the code, it is usually better to separate them out so they can be modified without affecting the program as a whole. Rules are kept in a separate module and called as needed by the main program.
Once the rules have been extracted, the next step is to map the accessible process. Usually, this is expressed in the form of a flowchart to make things clear. This isn’t necessary, but it is a help.
The next step is to define the inputs and outputs of the process. You need to list everything that goes into the process, including its source(s) and show everything that comes out. The inputs and outputs can be multiple and complex, but it’s important that you trace down every one and include it in your chart.
Taken together, this gives you a picture of the process as it now exists. Often it isn’t a pretty picture. Processes tend to arise organically without regard to logic or completeness. Very frequently this is obvious from a glance at the flowchart.
Obvious problems or not, you need to examine the flowchart carefully for trouble spots and places the flow can be made smoother. Look for duplications, unneeded steps, and other problems. Also, make sure all inputs and outputs are accounted for.
Sometimes you will have to draw two or three iterations of the chart to work out all the kinks. That’s fine, just keep at it until you have a nice, smooth table that describes every step in the process and all possible process states.
Once you’ve got your charts, the next step is to implement the processes. This is often a consultative process where you spend time explaining to everyone how the new processes are going to work and the reasons for the change. You may have to do some persuading but keep at it. The people will make or break your new processes and it’s important to get them on your side.
Finally, keep an eye on the processes as time goes on. Processes tend to change on their own, which is fine as long as the changes are well incorporated.