After I wrote previous post about enhancement of ASAP by AGILE:
http://scn.sap.com/community/asap-methodology/blog/2012/09/22/agile-for-sap-erp-implementation-no-th...
I realized from the feedback, that I am threaten as the “rookie” who simply loves ASAP only in waterfall form.
So please let me introduce myself – I am with SAP implementations for almost 20 years. My way with SAP you can see on LinkedIn – so only to give picture: because of my role during more than 10 years career in SAP I participated in dozens of various projects in roles like problem solver, quality assurance, project management or sometimes as escalation manager. I started in 1995 with introduction of R/3 on the local market and then also introduction of industry solutions and preconfigured solutions as well. In year 2002 I was responsible for deployment of the operation with SAP Business One. During these years I experienced implementations by full spectrum of customers from small to huge and in various industries with public sector as well. From the end of 2004 - as the contractor - I jumped back to project management of “big” SAP ERP.
So as you can see I have experience giving me title to make observations about the implementation methodology in practice. As a former developer (in the time before I started my career by SAP) I love the prototyping approach like represented by AGILE. But based on experience and the nature of ERP I have full confidence in that AGILE is not accurate for ERP implementations on big projects.
It is very good that SAP is listening the voices and is still working with the methodology. It is very good that now we have the possibility to modify ASAP to be AGILE compliant. But it is obvious to use this wise - considering the experiences not to repeat bad practices. I am sure that AGILE may be perfect for many components of SAP landscape like CRM or BI. In view on ERP implementations AGILE may be and is a very good approach for small enterprises especially when the preconfigured solutions and RDS are in charge. But I am sure AGILE is not for “big” ERP implementations – in terms of exchanging the one way approach design/realization/testing of waterfall into AGILE cycles. Why not? - There are many reasons. As the first three I will name:
1. Scope
ERP business processes are going through the whole company in terms of resources administration – big part of the functions are transactions changing the data in the data base. To even try to test this in some reasonable matter the whole fundamental of that have to be designed – the whole company structure has to be reflected in the system.
2. Data structures
The consequence of the above is that the database reflecting the business processes being implemented has to be complete. Looking on the structure we will see many references between various tables. Every transaction - even the allegedly simple - may have consequences for data in many other functional areas.
3. People involved
The working teams are built up from functional consultants and key users. On really big ERP projects there may be even hundred people involved from various departments. The main responsibility of the project manager by big ERP implementation is to keep the all teams going with the synchronized tempo. On regular ASAP implementation once the blueprint is been formally acknowledged built the base for further steps. Than all project teams have it to execute. It is really hard to formulate the good blueprint under this circumstances.
Consequence after the above points 1 and 2 to make the testing in the effective way the test scenarios have to be prepared and – that’s clear – they have to reflect the business processes implemented and the whole data base structure below. The base for this is the blueprint and this shows once again that the blueprint has to be complete and sustainable.
In view on the 3rd point we come to conclusion that to make reasonable test we have beside complete company structure, data base structure, all transactions also all people who are involved: aware, trained and with very good described test scenarios. But once we have this completed implementation is by the end! On the other side how to manage well the AGILE cycles with the huge and “heterogeneous” project organization? How - after completing the tests - to make the “back-turn” and in organized and formalized way repeat the whole cycle? And the main question is for what reason? In my career looking on dozens of projects I can recall probably the only one situation where the complete redesign was necessary and that was in the case of very frivolous project management.
I am fully aware that AGILE and Agility are buzz words today and it is trendy to make possibly all connected with them. There is a lot of space to make small pieces of prototyping (AGILE-similar) even on big ERP implementations: inside the projects teams or to make isolated add-ons). But I do not see the reason to make the whole ERP implementation in AGILE way- I am sure it will be:
- risky – the circles in view on point 3 above can go easy out of control
- longer (or much longer) than with waterfall
- harder to maintain in terms of understanding by stakeholders and documentation.
I heard as the argument, that the main “obstacle” in waterfall approach is that blueprint needs to be completed in about 3 months. In view on huge organization (corporation or institution) that will be affected by the implementation is that really to long? Please note that this is design of the entire company structure and processes that have to be solid and reliable. These 3 months are necessary for both sides (customer and vendor) to really make good work that will be acknowledged at the end by all responsible stakeholders. But blueprint is a big matter itself and I will write about it in another post.
I have to say that all situations I faced on the projects with troubles were caused by low quality of blueprint (too general, with open items) and frivolous project management. AGILE approach requires by the definition open blueprint and leads that the project teams will be not as much motivated as they have since they will know the all story will be repeated. Once again – by the definition AGILE is for very good cooperating, well focused possibly small development/tester teams. Big ERP implementation is not this kind of project.
