Skip to Content
Author's profile photo Former Member

Agile or Waterfall – what works best for FSCM?

Following from my previous article about why FSCM is becoming more popular with customers a key question that customers ask is, “what is the best methodology to implement FSCM?”

The traditional methodology  to implement a SAP module or product is known as a “waterfall” methodology which follows  the SAP specific “ASAP” methodology.

The key phases of the ASAP methodology are:

  • Project Prep
  • Business Blueprint
  • Realisation
  • Final Prep
  • Go-live and Support.


This provides a structure to a project, however certain procedures need to be fulfilled and the duration of similar projects can be off putting to potential project sponsors who are considering implementing FSCM. Further to this each phase needs to be signed off before the next phase can commence.


The other option is the AGILE methodology.  The key concept and differentiator here is that by using the AGILE methodology, the phases are joined together to allow small groups of functionality to be packaged into  “sprints” of no more than 4 weeks to design, build test and implement the functionality. A project can have a number of sprints – however after 4 weeks some functionality should be signed off or delivered into Production. Further to this the functionality can be prioritised so the key functionality is implemented in the first sprints.



FSCM focuses on enhancing the cash flow for a client. It would therefore seem sensible to implement in the project in the most cost effective manner.

There are a number of articles that will cover the benefits of each of the different methodologies and I don’t want to provide a pro and con listing for them. What I intend to do is to focus on the actual FSCM product, the business users groups that are being implemented to and also the rationale for the implementation.

The core FSCM product is fairly simple to implement. The volume of physical configuration is not that great nor is the complexity of this configuration. SAP have created a number of BAPI’s that will personalise the build. Workflow could be used to automate some of the processes, or escalate certain events. The key to the development is mapping the required business processes to the FSCM solution, or amending the business processes and mapping that to the FSCM solution. As such if the business process requirement is known it can be easy to break out the required functionality into smaller chunks of work that can be managed in an AGILE manner. However if there is to be some form of business process re-engineering or this is a new business process the effectiveness of using an AGILE methodology reduces. 


The key business users using the new FSCM solution should also be considered. There are a number of very mature SAP ERP Finance users within certain clients.These business users have been using standard Finance Accounts Receivable for a number of years and are comfortable with the screens.  Within an AGILE project business users and technical users work together closely. The technical team will be providing prototype solutions and ideas to the business users, and if the business users have the detailed Finance knowledge their input will be better received. However if you are implementing FSCM to a user group that is not familiar to ERP Financials such as new implementations of SAP, or users who are using 3rd party software for Accounts Receivable processes this will be different. These users will need to be up-skilled, including navigation skills, SAP terminology and integration to consider which align more to the ASAP methodology.


The last key consideration is the original rationale of the implementation. Does the project sponsor require immediate returns for this project? Has the project sponsor got a certain budget for this project? Has anyone done any analysis on the priorities of the functionality that is being included in the scope? One of the real benefits of the AGILE methodology is that you can deliver small groups of functionality at regular intervals. However whilst this can be a good idea, the whole project team needs to be able to be AGILE, they need to be able to feed into the scrum’s and potential key business users will need to reduce the time they spend on the normal day to day duties.  One example of where the AGILE methodology did not work was when a client who had a business process that took 5 days to create a SAP user. The project required a specific user, and requested the day before the user was due to start which lead to certain required functionality not being implemented in the agreed scrum.


In summary there is not one answer. The actual product does lead itself well to the AGILE methodology, however there are certain examples where the traditional waterfall methodology is best suited.  To work out which implementation methodology is correct for you I would recommend that you consider some of the points I have raised here.  If you have implemented or are in the process of implementing FSCM please comment on how you chose your implementation methodology.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      "4 weeks" to design, build test and implement the functionality is a challenge. Keeping the solution simple and broader in the first phase will help in realizing the immediate benefits. More refinements may be required based on user response and additional enhancements.

      It helps the in-house team to understand the product when working with solution specialist in the first phase, and maybe they can do the enhancements with little guidance.

      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Hi JH

      Thanks for you comments.

      The AGILE methodology does work for FSCM, I have personally used it.

      The key to AGILE is to break the whole project into different stories and to deliver that story via a sprint in a short period of time. The whole reason for my blog was to get customers to question what the best methodology was for THEM to implement FSCM.

      A story could be, design the "BP extension of customer masters for Collections Management". This could easily be achieved in a 4 week sprint.

      The first sprint maybe "review the current business process and agree the to-be solution" One of the key concepts is to get all of the required business users and technical users to deliver the stories agreed to be delivered in a sprint.

      Where I am working at the moment, they are in the middle of their 13th sprint for the same project (not FSCM). Functionality has been provided to the business at the end of each of the sprints.

      Within a standard FSCM implementation there is real scope to break out the full scope of the solution into smaller pieces of functionality that can be delivered via sprints providing constant business benefit.

      I hope this answers the points that you were raising.

      Author's profile photo Former Member
      Former Member
      Hi Mark,

      I was interested to read you FSCM Agile vs Waterfall. We are a large Consulitng house in aus with a lot of SAP consultants who are accustomed to the waterfall approach. My team are the development team and we have migrated to the agile approach to projects and capability releases. i noticed this blog was dated 11th may and wondered what you experiences have been on client adoptiong of the agile vs waterfall approach. cheers mark

      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Hi Mark,

      I am currently working in an AGILE manner for a client. I have been on various pojects (sprints) for around 6 months.

      My first observation is to be AGILE the whole Organisation needs to be AGILE not just a project team, or a team of developments. Everyone needs to be bought into the change.

      The benefits of deliverying small chunks of work to the business really does work, however some of the work within the team can be a challenge.

      This article looked at implementing FSCM at clients, and it can work. Providing a PoC to a client, before they have even looked at scoping a solution can be hard - however it allows the client to get up to speed on the product straight away and reduces the time spent on scoping, blueprinting, and realisation.

      In Summary for the right client, with the right product AGILE works very well. However performing a re-implementation of ERP may be a bridge too far.