I am sure AGILE is not for big SAP ERP implementations… Part II
Requirement of proper blueprinting by SAP ERP implementation:
is my next one objection about the use of AGILE by SAP ERP. Indeed it is close connected with arguments presented already:
Because of its importance they have to be considered separate. Based on experience blueprint prepared for SAP ERP implementation should be complete on sustainable level: precise enough for realization phase.
Remark: this article is about the ERP core scope (no CRM, SRM, BI etc) and focuses on so called “transactions” – components of processes having influence on the data base. The reports (visualizing in any form the collected data but not changing them) are separate area an may be changed in every moment – are not a subject of this article.
Please also note that this article is about the AGILE as integral part of ASAP as the way the whole project is managed. The AGILE or similar treatments however may be used as part of SAP ERP project in individual teams to make some prototyping. There are areas where the AGILE similar treatment in necessary: like in interfaces in logistic chain by volume and transfer tests.
SAP ERP implementation can be almost fully predicted in the conceptual stage – so there is even no business need for the “make and try” cycles as for whole solution. On dozens of SAP ERP implementations I have no observed necessity to make major changes after the “one-way” approach of waterfall. Typically some adjustments in last phase were fully sufficient
AGILE from its nature accepts that blueprint is open and will be changed due to the results of the “sprint” cycles. That is working perfectly in implementation of other components and development projects but will not work by SAP ERP. Based on my experience from big implementation I can not even imagine the necessary effort on project management level to make the cycles in the right way like I wrote in:
There are SAP ERP projects however where the ASAP/AGILE may work very good: SME or startups where (in both cases) RDS are in charge. That I will discuss in another post.
Once again: AGILE is from the definition like:
For rather small very well integrated teams:
“Team size is typically small (5-9 people) to simplify team communication and team collaboration”
SAP ERP implementation are definitely not this kind of projects!
- PS. Dear Readers of this article –if you find it usable for you please award me wit “like” or even rank with stars! This 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
I understand that you are sceptical about Agile in ERP implementation. While I believe understand the source of the scepticism I can not accept your broad statement that Agile does not work in ERP implementation. There are ERP implementations that used Agile successfuly and delivered integrated solution using different way of working.
Another point I want to make is about the way we implemented Agile in ASAP. We took into account specifics of SAP implementation and trully iterate in Realization phase. It is also critical to understand that we are not starting the project as a blank canvas and develop everything from scratch. The approach to blueprinting has been streamlined taking into account the fact that design is part of each iteration, but we still need to understand the customer needs.
My last point is probably the most critical - you do not have to use Agile in project if that is not a good fit for your client. ASAP continues to be delivered for traditional implementations following the traditional Build cycle with one go live. Agile is provided as an alternative to this approach and is especially useful in cases when project takes advantage of standard packages like RDS that could be used as baseline build and team can quickly deploy standard solution for ERP or any other solution SAP offers.
thank you for your comment. Please note that I wrote that it is my belief that AGILE is not right for big erp implementation. I am formulating this as thesis for dispute on the forum presenting the objections based on practical experience.
This is for sure not "broad statement that Agile does not work in ERP implementation" - I am not allowed to formulate that kind of statements and do not like to do this. But OK - if you are finding this that way I will look in my articles and to correct if something sounds like broad statement.
This both: AGILE and waterfall are good but different and having they "pros and cons" for various kind of projects. Where AGILE may be very effective (and much better than waterfall) for components like CRM I am sure that for big ERP that can be risky and very hard to manage.
That what are you writing on the end is exactly also my aim in this articles - I am looking for conditions and circumstances where the AGILE may be used as the main approach on big ERP projects. Use of RDS is that situation - however the massive use of RDS on big ERP projects is rather rare?
Are probably some new reference materials about practical use of AGILE-modified ASAP on ERP projects - especially the real big ones?
While the use of a formal AGILE/Scrum approach is probably not conducive to an ERP rollout, I do believe that the principles of iterative processes encompassed by AGILE are almost always incorporated in ERP roll outs. The scope and timing of major ERP projects almost always extends beyond a range of time where static blueprinting and business processes are valid. As an example if you are rolling out a SAP HR/PY and Finance implementation for the Jan1 go live in a US company, the requirements will absolutely be guaranteed to change. The external legal and country specific financial and payroll rules are not known. The project would likely have started at some point between 1 Jan and 1 March in the project year. Having an AGILE or LEAN approach that incorporates a method of iterative design elements and connects them by having a governance process that also accepts iterative changes seems like a good way to minimize risk and delver the value of the project. Waterfall methodologies , as originally conceived , included a period of reconsideration of the requirements. The dynamic nature of processes and requirements can be ignored but when that occurs the ROI and project value is significantly diminished.