In many of my ERP implementation projects, I have seen and even involved in doing a process re-engineering prior to starting an ERP implementation. Many companies do this basically to set right the existing process or lean out the current complicated process. The idea being not to bring the current redundant steps or procedures to the new process that would involve ERP. This do sound very reasonable thing to do and the concept quickly caught as a best practice as a pre-implementation activity. Re-engineering experts were hired to assist them in identifying their existing process bottlenecks, and provide them with a value stream maps that would remove all these reduntant steps and bring in process improvement.
While all these sounds very right, I am personally not convinced with this approach as a pre-implemenation activity and here are the reasons why..
Future Process Maps
What ever may be the existing process, during the ERP implementation, the consultants comeup with the future process documents which is not the same as the leaned or improved process. The ERP consultants still have to discussion with the business users to understand their existing process and chart out the future process taking into consideration the ERP application functionalities and process. Since ultimately the users will have to work in the ERP application, doing a re-engineering activity without considering the process steps within the ERP application does not make any meaning. One of the prime flou that I have seen is the customers using pure re-engineering resources who do not have knowledge of the ERP system that they are planning to implement. They conduct workout sessions and comeup with value stream maps in isolations of the ERP application. Lot of time and energy is spent on this activity which will anyway again be re-looked when the ERP implementations gets underway. So this raises the following questions
- Why not involve the ERP consultants ( may be along with the re-engineering consultants), in the entire activity of coming up with the leaned or improved process?
- Instead of concentrating too much on the ASIS process, why can't they look at what they want, the future process. ( which will automatically be the improved process from the existing )?
- Why spend too much money and energy on a pre-implementation, re-engineering activity? Why can't the re-engineering activity be clubbed with the future process design phase of the ERP implementation itself ?
Having been little negative on the ERP pre-implementation re-engineering activity, I would like to also mention some specific areas where value stream maps will be useful.
- Where the business is aware of a complicated process which they need to streamline
- Where the busniess is aware of reduntant activities that they think should be removed
- Where there is a process bottleneck that can be avoided.
Re-engineering can be specifically targeted on the above which are non-ERP related and which may be needed even after ERP is implemented. For example, if the goods are delivered to the customer site, but it takes 2-3 days to confirm the delivery of the goods to the billing team ( due to the remote customer locations) and thus resulting in delay in revenue recognition or billing. The process step could be that the truck driver faxes the delivery note with the customer signature to the billing team after the goods are delivered. The availability of fax facility may not be near the remote customer location and thus the delay. The re-engineered process may be to provide the truck driver with an handheld device that sends immediate information of the delivery directly to the billing team thus saving the valuable 2-3 days of delay in revenue recognition or billing to the customer.
In the above scenario, there was a problem and the process is now improved (re-engineered) by issuing the hand-held device to the truck driver. The solution would be the same whether ERP is implemented or not. Such scenarios really qualifies to be a candidate for re-engineering prior to ERP implementation.
Conclusion
Doing general re-engineering activity prior to starting any ERP implementation is more a waste of time and money, since the processes will anyway be re-looked to suite the ERP oriented steps and procedures. Any process that is independent and will not change with ERP system that need to be re-engineered qualifies as a candidate to be looked into pre-implementation.
I would appreciate your views and feedbacks on the topic.
I would appreciate your views and feedbacks on the topic.
Nice article Moni,
ReplyDeleteI tend to agree with your opinion that BPR (Business Process Re-engineering) should be done as part of the ERP Implementation rather than as a separate activity before the commencement of the ERP project because in any case, the business process will need to be fitted to the process that can be mapped out in the ERP.
Having said that, there are two major reasons why businesses get BPR done by domain experts who are specialist business process re-engineers as opposed to the ERP consultants
1. The business owners are skeptical about the ability of the ERP consultants to provide effective consultation with regard to BPR because they (the business owners) believe that the ERP consultants will tilt the BPR towards the capabilities of the ERP rather than what is actually the best practice for their industry. In my opinion, they are correct to an extent. The primary goal of an ERP consultant is successful implementation of the product. Also ERP consultants believe that the business process mapped out in their ERP is the best for the industry. When implementing Baan, I & my colleagues (the manufacturing consultants) were firmly of the belief that Baan had the best business process for discreet manufacturing.
2. The other reason is that ERP projects are generally awarded through a bid process. Given this, the proposals are usually pared down to the bones and this means that extra work such as BPR is not included in the implementation prices. During discussion with the short listed vendors, a potential ERP customer, who in many cases believes that his business process has got redundancies and bottlenecks, often finds that the vendors are willing to perform BPR but at an additional cost. Given this, the customer may think that instead of paying extra for BPR by an ERP consultant it is better that BPR be performed by a BPR professional.
The above are, in my view, the basic reasons why BPR is often entrusted to a so-called BPR expert rather than to the implementation team.
As you mention, this may lead to significant mapping issues during ERP implementation because a customer who has invested significant resources in getting his business process re-engineered will be quite rigid about his new process and not be amenable to alter it to suite the ERP product. This is where the project manager needs to step in mediate.
In conclusion, implementation of an ERP system brings with it a certain degree of Business Process Re-engineering whether or not the company has recently gone through a process of re-engineering and so spending money on a separate BPR exercise before an ERP implementation may be wasteful except in a situation where the current business process is so opaque or confused that BPR is necessary to make sense of the process before an ERP implementation.
You are right and thanks for pointing out on why they tend to go for re-engineering as a pre-implementation activity. I agree with you on both the points mentioned by you as the primary reasons for going with BPR before ERP.
DeleteYour view on customer being skeptical on the capability of the ERP consultant to do a good job with BPR is very true. While this can ofcource be mitigated by hiring BPR consultants to work closely with the ERP consultants during the phase of designing the future process maps, I still feel that an experienced ERP consultant will do even better job than a BRP consultant when trying to lean out the process through ERP.
On the question of 'Why?' they do BPR before ERP, I would like to add a third point, where many customers wrongly believe this to be a best practice and would like to invest on the same.
Nice Article Ram,
ReplyDeleteMy view will be from a person who is new to ERP. I totally agree with your view on BPR. BPR team should be part of the ERP implementation from the beginning and after implementation. I think BPR may have more insight how the business process works from different perspective view than ERP consultants. Their knowledge might have different view on how business process should run for a company. Therefore, BPR team and ERP consultant should come together to find best alternatives business process for the company with ERP system as a core implementation system. I think BPR team will be a big factor after the implementation because they might see what can be changed that they didn't see during implementation for GO LIVE has more activities than testing stage.
-Mike
Informative Post...
ReplyDeleteIt looks like you spend a large amount of time and effort in writing the blog.
All the points are very informative and easy to undersatnd.
Components of BPR like processes, organization & information technologies which automates business processes across the enterprise & provides an organization with a well- designed & well- managed information system.
Thanks for sharing such a nice post on bpr in erp implementation.
Ramdin -Appreciate your feedback. Thanks.
Delete