ASAP Methodology in practice: involvement of users as the condition of ERP implementation success
Because of my research I am looking for projects with troubles to identify the reasons and formulate remedy. This time I like to focus on the very important accent in ASAP methodology – the involvement of users during the whole ERP implementation project. The participation (in form of key-users) – what is also important – connected with essential interaction with the system – beginning with presentations and early trainings and later possibility to make some prototyping on demo system during the first phases.
The reason of this article is that I found that some companies are still trying to reduce the participation of users in ERP implementation. Just now I found two cases of ERP projects with deep troubles and my conclusion is: users not active involved.
I will be very grateful for your comments – are there probably situations that justify the design of ERP solution without active involvement of users? I am asking because can not imagine effective ERP implementation without the user participation from the very beginning!
Through my whole career in SAP business I was involved in implementation projects which were driven with intensive participation of the users – as the SAP methodology requires. Previously it was SAP Procedure Model and now it is ASAP. From the very beginning the users – selected competent representatives named “key users” – were intensively “immersed” in the SAP ERP – making recognition and training. In fact the design of the solution was made by key-users supported by consultants.
I recall even situation when key users set the configuration by realization of designed solution. To be fair: partly because of responsibility since due to the law the responsibility of accounting system is on the head of management of the company and the management likes to distribute this responsibility to other employees.
By the way due to the very good system transporting settings in SAP which is allowing traceability and audit ability of the settings this is not necessary in fact even in the most conservative institutions. But this aspect is a separate story.
The users did it (the settings of the solution) as part of the knowledge transfer also to built own group of internal consultants. That participation of users was always very effective and impressive as well.
To illustrate better the importance of this I will recall that there was in the past another approach – used mainly by huge professional services companies mainly in USA in huge corporations. In short: the external consultants first collected the information about subjected corporation in dozens of tables and descriptions going through the corporation and asking staff. Then they made the design. Before go-live they organized trainings of staff but limited to the particular positions and roles. Big-bang and all started work in new system. In fact the implementation of ERP under these conditions was often only a small part of biggest consulting service project named “business process reengineering”.
The advantage of this approach was that it has not burdened the staff of subjected corporation. On the other side I have to name the disadvantages (as I see this): very big cost and the fact that the whole competence was left outside the subjected corporation (I am not counting dozens of fat files of mainly useless documentation).
In the past the approach of making design and the solution without active participation of users was – as I guess – successful. It was because the users of the system in big corporations were making the same routine procedures for long time and without the need to see the whole mechanism.
But these times have gone – now even huge corporation are living in the permanent process of change – in time of agility and need of incremental business development. That is not possible in practical sense without competence about the information system possessed by own staff.
So it may be the conclusion that now the involvement of users in the implementation – especially if this is a new one (not upgrade or enhancement) – is crucial for the successful and effective implementation. This is building the base of very beneficial use and further agile enhancement of implemented ERP solution.
I expressed my doubts about the use of Agile implementation method by ERP implementation in cycle of articles:
But now as a conclusion of this article I like to form the thesis and put it under dispute: after successful SAP ERP implementation with very intensive key users participation as the “side effect” remains group of internal consultants “totally immersed” in SAP. This group makes possible to realize further implementations and enhancements in agile way. This is because they together with external consultants can form close working very good focused and motivated group that can work without communication problems. That is fulfillment of the fundamental condition to make Agile projects!
In the next part I will describe and put under dispute another very important – as I think – aspect of user involvement in ERP implementation project.
- PS. Dear Readers of this article –if you find it usable for you please award me wit “like” or even rank with stars! This article is effect of my evaluations with the target to create small focused on most important aspects implementation handbook: I will be grateful for every critical comment – for the essential ones I can make award in the discussion: http://scn.sap.com/thread/3247605
Total involvement of Core or Key Users - Subject matter Experts is a MUST. However, in the modern world while Corporations surviving on Lean Staff Strength, to releive their Key Resources specifically to a ERP Project for 9 to 10 months is an impossible situation. At the same time, the importance & strategic reasons why they should be fully involved to learn the ERP processes & its impact as well the Change Management in the organization also is an absolute must.
Probably the Agile methodology with sprints of 3 to 4 weeks would be a solution to that to an extend as the Key Users can also take their normal load in between.
It is a Catch 22 situation with no definite answers but have to find a workable solution without sacrificing work of the Corporate ( routine work) as well as the ERP Project work without incurring additional cost.
Dear K. Varkey George,
Thank you for the comment! I must say however, that I am naming exactly the same reason (user engagement level) as you are for showing that Agile is not right for ERP implementation – I made some posts about like:
and previous ones.
Please note that Agile requires close contact and in fact full time occupation (concentrated focus on project since the work is without documentation). In waterfall all users from business can plan their engagement day after day and the level of occupation is dependent on the phase but they have always possibility to maintain the common business.
In Agile before the sprints the user involvement have to be significant (even more than with waterfall) to become integral part of the implementation teams. Please note that work in teams is very close and informally but in area of ERP there are individuals with various skills, age and preferences – to make close working teams it is challenging work.
Waterfall gives the requirements of regular on-line documentation what makes the project in ERP area more tolerant and independent from individual behaviors and much more sustainable and reliable. I am not against Agile – this is perfect method for development. But for ERP implementation I am sure not.
This is my opinion of course.