Skip to Content

As I see the ASAP methodology team in SAP is hard working to adopt ASAP to AGILE approach. That was more than one year ago announced and there are first results available in form of presentation:

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/c059ed1c-5fc6-2e10-7380-ed9af5c44833?QuickLink=index&overridelayout=true&52235392514702

As I see this is also addressed for SAP ERP implementations! I am wondering because on lessons given several years ago for the auditors on management post-graduate study I already have answered the questions that AGILE is not adequate for ERP implementations from obvious and clear reasons. I will name and evaluate the reason in next posts.

During this I named examples of projects where approach like AGILE (or more generic: rapid prototyping) is perfect and effective – like Hyperion implementing analytical tools in a while during presentations! As I recall this has made a lot of anger for SAP. For BI, CRM, and other components of similar nature AGILE may and I beliefe is perfect – but not for ERP!

Even in the definition of AGILE in Wiki we can found that this method is for rather small close cooperating teams of users(testers) and developers. Example of what can bring the use of AGILE by huge and wide project show us NHS RiO project in Britain – after many years and huge effort complete disaster:

http://www.computerweekly.com/blogs/public-sector/2011/08/agile-in-the-nhs-10-years-5bn.html

Why: the success of AGILE depends on the very consequent keeping the “specification/realization/testing” cycles closer and closer. With SAP ERP after many years as project manager and quality auditor on dozens of projects (successful projects!) I can even not imagine the power able to manage this in practice.

By ERP implementation we have several teams with involvement of key users and already this landscape makes the communication in whole project as significant issue. In real live in addition to above we have to face very often scenario like described in the post of Tammy Powlas:

http://scn.sap.com/community/asap-methodology/blog/2010/04/02/sap-project-management-path-to-hero-or-point-of-failure

This means: business very often skeptical or neutral, it is hard to reach the right engagement and support on every level and area. And in this environment you like to use the “trial and error” method (what indeed the AGILE is)? – it’s obvious it will cause even less engagement and more frivolous attitude!

And what are the expected benefits of use the AGILE adopted ASAP? In the presentation I found that in one case the implementation was 20% shorter than planned 12 months. Based on my experience the right implementation time of Sap ERP is 9 to 10 months. It is sometime possible to implement in 7 months but only with right attitude and engagement level of key-users and management. Is really 1 or 2 months shorter time so important to make experiment? I doubt. Please note that all connected with ERP implementation (handbooks, consultants, contracts) is familiar and adopted to “traditional” ASAP. Is it really the huge change of project method and practice worth of it? (please note I am still addressing my doubts to ERP only!)

My recommendation is: for SAP ERP rely on the ASAP as it is based on waterfall – this really works. In my belief it works perfectly since is scrupulously followed step by step with keeping the right tempo. Do not make your ERP implementations as some kind of risky experiment!

To report this post you need to login first.

14 Comments

You must be Logged on to comment or reply to a post.

  1. Mark Chalfen

    I believe there is a place for AGILE for all types of SAP products.

    I have spent most of my time implementing ERP Solutions (Finance mainly) and I have used both ASAP and AGILE.

    Both work – I can vouch for that. Both can be expensive – I have seen clients go over budget with both methods. However with AGILE you can prioritise the solution. Where it goes over budget it is normally because there is extra scope (for extra benefit) that is required.

    And there there is RDS. You can implement core ERP via RDS(s).  The scope is all done for you, the config is standard – and the project could go live in 12 weeks, rather than 12 months. A real benefit for customers who are happy to sacrifice some functionality and choice for a reduction in cost and time.

    (0) 
    1. Waldemar Falinski Post author

      Hi Mark,

      Thank you for your reply! I am just preparing more specific justification of my doubts. I mean SAP ERP implementation as regular “typical” – what is still the majority (no RDS).

      Can you please explain more about your experiences with AGILE – was it used formally on the whole project or only limited to FI as some kind of prototyping before formal realization? How big was this prototyping group and how long it taken to complete one cycle? How many cycles you have completed?

      I will be also grateful about some info according the use of RDS – like what kind of company has used this approach?

      Regards

      (0) 
      1. Mark Chalfen

        OK – you have raised a few questions here I will try and answer them all.

        who would use an RDS? In theory anyone can – in practice you would be looking for smaller clients. Perhaps a single site (country). The usage an adoption of RDS is more around the mindset than the size or type of client.

        If you have an approach to say – what do we REALLY need to go live then that could be an RDS solution. You can use the RDS to build a prototype – and then use that to define the rest of the scope.

        In terms of AGILE I have done this on a number of projects. In fact we use some form AGILE in every project we do. Some are full blown scrums – with 2 week sprints. Some might be more around prototyping and workshops to define scope and solutions.

        My main concern with ASAP is that it can take 3-4 months to Blueprint – and the requirements or business focus may change in that time. If you can visualise the solution upfront you bring the client on a journey and the volume of change is reduced as they can see what the system will look like and act.

        (0) 
        1. Shaun Snapp

          The RDSs seem to be marketed differently than what you have described above. The RDS also assumes a lot. I don’t run into clients that will accept such a vanilla implementation. SAP seems to propose using the RDS as a general accelerator not only for the types of projects that you mention in your comment. My concern is that the restricted aspects of the RDS get sort of deemphasized during the sales process, and then the restrictions of RDS become apparent during the implementation. As in, “yes we can go faster if you accept that the implementation will be vanilla, and will have to be changed in a later phase.” However, if doing very little requirements gathering is accepted, and a vanilla implementation is agreed to, then of course the implementation can be accelerated — with or without using an RDS.

          However, your comment has helped put some extra context around he RDS.

          I think the point is taken that showing the client demonstrations functionality can get better feedback from them. However, if one looks at what is in even the most mature RDSs, I cannot see how that will help build a prototype much faster.

          (0) 
  2. Gregory Misiorek

    Hi Waldemar,

    since i’m familiar with a couple of implementations being more than 10 years in the making, i see your point that agile would hardly fit their experience. however, it does come down to definition.

    if i configure one company code and post a journal on a Sunday afternoon, can i claim a go-live? now, if i’m a large company with hundreds of thousands of employees in every country of the world, using all MISO vendors, four different hardware resellers, five different implementation companies and then some and i deploy a complex, integrated process involving a team of 100 over 2 years and involving only one company code is that agile or not?

    we can’t blame SAP for trying to be agile or to deliver solutions in “realtime”, but as projects’ charters get redefined as soon as the ink dries out on the contract, agile remains in the eye of beholder.

    my 2 cents or 3 Groschen…greg

    (0) 
    1. Waldemar Falinski Post author

      Hi Gregory,

      Thank you for your 3 (trzy) grosze! I see I have to speed up with my explanation.

      I  am not against AGILE – I love it as the former developer! But I am sure that it is not accurate for regular SAP ERP implementation and I will explain why. Soon! My doubt is if AGILE may be used inside the ASAP implementation for SAP ERP in form of cycles inside the “normal” realization phase.

      But of course we can find and use AGILE – similar treatments on the regular |waterfall projects like you mentioned  – also refining of already implemented system (repeating of the whole waterfall) can be seen as AGILE similar treatment. It is OK.

      Waldek

      (0) 
  3. Marcos Aurelio Paixao

    Hi Waldemar,

    I’m a passionate for agile techniques and I really liked your article. I don’t believe there’s a right (or wrong) way to conduce agile projects. I had experiences about the agile with ERP systems, some of they were on an ever-changing environment, which some companies needed the projects quickly as possible for competition advantage. For that, agile fitted well once the specific business needs were approached to be delivered early on the development or implementation process.

    According to the article, waterfall is ideal for the SAP ERP and I think you might be right. When we implemented ERP modules on large corporations, some people from functional sectors are not fully available for project activities. Ideally, agile requires full commitment and face-to-face communications and for some companies this is not so easy, especially if the people are not collocated on distant locations.

    The concept of teamwork, also collocated on a shared workspace during all the project is not common for companies with functional departments which don’t have the need for sharing cross-functional skills. This simple combination of elements is a really challenge for adopting agile practices and the communication flow also is challenge for any project, agile or not.

    Thanks for your article and it is important to share experiences where we can find ways to adapt them into our own projects.

    Best regards,

    (0) 
    1. Waldemar Falinski Post author

      Dear Marcos,

      thank you for the comment! I’am passionate for agile techniques too and in fact on all my “waterfall” SAP ERP projects were objects implemented in incrementall – or “hands on” – way. Now I am preparing the “soft” HR project what I like to do with ASAP 8 Agile since this is an ideal area to be implemented incrementall as a whole. I will make the evidence here of the progress and I count on your comments and advices. Regards Waldemar

      (0) 
  4. Terry Knowles

    I do not see Agile as an acceptable SAP ERP project methodology, but put that aside for a moment.  Each enhancement to SAP ERP creates a point in time from which that functionality is available.  With constant, or several, Agile iterations of functionality, it creates issues for those who “use” the resulting product.

    I strongly agree that Agile is not the best methodology to deliver most ERP implementations.

    (0) 

Leave a Reply