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
- 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.