UAT (User Acceptance Testing) is a very important milestone in any ERP implementation. A successful UAT can instill initial confidence in an end user since this phase can ensure that all his key requirements are given due consideration in the implementation. For many of the end users, this phase is his / her introduction to the ERP implementation which in some ways is going to significantly change the way he is going to work!!.
Unfortunately it is also true that UAT is not given the due seriousness it deserves in many implementations. Most of the time, UAT period is considered to be a 'buffer' which can be used in case of time overruns in the earlier phases. The lack of seriousness in UAT can manifest in many ways including hastily prepared test scripts, poorly created test plan, absense of test strategy, insufficient pre UAT communication to the end users, last minute identification of the end user to do the testing.... I can go on.
Why is it that UAT gets very little importance in many implementations. One reason is the time pressure. The go live date has been widely publicised in the top management and the project has had serious time overruns as it approaches UAT. The pressure to meet the 'go live' deadline is so high that implementation succumbs to the pressure to compromise on UAT.
Second reason is that since UAT is the introduction to ERP for the end user, the tendency to make it appear to be successful to the user is very high. So the test plan is prepared with all the generic straightforward scenarios which have been tested thoroughly. This leaves all the complex, one off scenarios to be enterd in the system only post go live and this leads to user dissatisfaction in that phase. Another problem with this approach is that the key users of the organization who have to stabilize the ERP post go live do not have experience in handling these complex issues since they have not been tested previously!
Third serious issue with the way UAT is conducted is that it test only the modules and not the processes or flow. For example the plan for the PO user will contain items like entering PO, doing a material receipt, checking the inventory to see if item quantity has correctly increased etc. And for a payables user the testing will consist of entering invoices, making payments, checking accounting etc. Logically the UAT should test the Procure to pay cycle by following the same PO to its payments and the impact in GL. This seldom happens.
In addition to the point mentioned above, there are other issues as to why less focus is given to UAT. It will be a good idea to have the involvement of an external consultant to ensure the success of ERP. In this context the following article by Venkat Manthripragada in IT Toolbox provides 10 reasons why involving an external consultant during UAT is a good idea. Some of the reasons he mentions include providing perspectives, completeness of test scenarios, expertise etc.
Check this out.
Can you think of other reasons why UAT tend get a short shrift during an ERP implementation? And various ways in which this lack of seriousness manifests itself?
Your comments are welcome.
Unfortunately it is also true that UAT is not given the due seriousness it deserves in many implementations. Most of the time, UAT period is considered to be a 'buffer' which can be used in case of time overruns in the earlier phases. The lack of seriousness in UAT can manifest in many ways including hastily prepared test scripts, poorly created test plan, absense of test strategy, insufficient pre UAT communication to the end users, last minute identification of the end user to do the testing.... I can go on.
Why is it that UAT gets very little importance in many implementations. One reason is the time pressure. The go live date has been widely publicised in the top management and the project has had serious time overruns as it approaches UAT. The pressure to meet the 'go live' deadline is so high that implementation succumbs to the pressure to compromise on UAT.
Second reason is that since UAT is the introduction to ERP for the end user, the tendency to make it appear to be successful to the user is very high. So the test plan is prepared with all the generic straightforward scenarios which have been tested thoroughly. This leaves all the complex, one off scenarios to be enterd in the system only post go live and this leads to user dissatisfaction in that phase. Another problem with this approach is that the key users of the organization who have to stabilize the ERP post go live do not have experience in handling these complex issues since they have not been tested previously!
Third serious issue with the way UAT is conducted is that it test only the modules and not the processes or flow. For example the plan for the PO user will contain items like entering PO, doing a material receipt, checking the inventory to see if item quantity has correctly increased etc. And for a payables user the testing will consist of entering invoices, making payments, checking accounting etc. Logically the UAT should test the Procure to pay cycle by following the same PO to its payments and the impact in GL. This seldom happens.
In addition to the point mentioned above, there are other issues as to why less focus is given to UAT. It will be a good idea to have the involvement of an external consultant to ensure the success of ERP. In this context the following article by Venkat Manthripragada in IT Toolbox provides 10 reasons why involving an external consultant during UAT is a good idea. Some of the reasons he mentions include providing perspectives, completeness of test scenarios, expertise etc.
Check this out.
Can you think of other reasons why UAT tend get a short shrift during an ERP implementation? And various ways in which this lack of seriousness manifests itself?
Your comments are welcome.
No comments:
Post a Comment