SAP Activate – with Agile, really works and save time?
Announced at Saphire 2015 with the promise of replacing ASAP, it seems that Activate is becoming a popular subject in SAP articles and being mentioned in Hana implementations – please note this methodology is aimed for Hana projects (Cloud / OnPremise), but due to its nature and procedures, it can be used for all types of project.
It is important to highlight that the correct name would not be “methodology”, but “framework”, since its main cornerstones are best practices, guided configuration and methodology as a whole.
- Best Practices
- Ready scenarios, optimized for S4Hana
- Best Practices for S4Hana integration/migration
- SAP BP creates processes or own processes
o Whether SAP is Cloud or OnPremise used, both will start with the Solution Builder tool in order to activate Best Practices.
o Please note SAP cloud updates are faster and should be immediately implemented.
o For Cloud, the Expert Configuration may modify or add existing processes.
- Guided Configuration
- Tools for assisted implementation
- Users and IT may access service tools for implementation
- Contextualized content and knowledge on what will be implemented
[Tools that may help delta customization à http://searchsap.techtarget.com/answer/Which-SAP-Activate-tools-can-I-use-for-an-S-4HANA-Cloud-implementation]
Moreover, there is methodology, in which is possible to apply agile methods – this has to be decided in the planning step, considering the company’s cultural understanding of Agile. Do not try it if you do not know it.
Apparently, there is still some opposition regarding using Agile Methods for ERP, which may pose a matter of company’s lack of practice or presentation and certainty. This article presents a helpful point of view on the subject, besides the practical insight on the new methodology adoption. Even though it is from 2016, which seems a lot of time, the following article is an excellent reference: http://www.insidesap.com.au/can-the-agile-methodology-actually-work-in-sap/.
My intention is not to detail this methodology, since it may be referred in several available posts. In case you do not find appropriate links, please see the reference links for a detailed explanation. In this article, we will focus on the Agile opportunities and insights, and talk about the common mistakes related to simply accepting a task that you may not be ready for.
The Agile methodology replaces or intends to replace the former model, ASAP, which used a traditional BBP meeting method to develop solutions and seek understanding without yet having the system. However, in this methodology system only arises after the BluePrint phase, which takes a time, besides the arguable ASIS/TOBE evaluation.
In 2013, I had the opportunity to manage an SAP implementation project using the ASAP RDS methodology, which shows a format similar to Activate – in other words, there is no BBP, it is direct in the system, there is an initial system assessment before starting the project and approval of what is being delivered, quality gates are well defined, etc. Its major goal is to reduce complexity and present the system as faster as possible, mainly when implementing projects in Brazil: the most cumbersome country to implement ERP due to its legislation specificities.
Regarding that project, SAP was hired to do the Quality Assurance, verifying projects status and taking steps in each Quality Gate. Moreover, I strongly recommend another company taking care of the QA, since it makes a difference and may help a lot. In addition, do not hire the same company that is implementing SAP. Instead, hire a QA-dedicated company, formed of systematically expert employees, who are focused on project coordination, recommendation, ideas and alternative options – which means management, project and implementation experience.
However, there was not a Scrum presentation, even though we used a KanBan board for ABAP development guidance and the common practice of project development based on an initial environment or pilot. I remember managing WEB projects in 2004 and starting them with user interaction and screen templates developed by inters. By the way, Design Thinking involves a prototype visual model analyzed and interplayed by the user. This reduces documentation, endless meetings, misunderstanding, improves delivery and user experience – muy bien, it looks exactly the Agile method.
It is important to mention that in Activate courses (ACT100 / ACT200) we can understand the team’s maturity in order to decide on the Scrum usage. The type of implementation model – SCRUM, ASAP, regular – should be decided in the PREPARE phase, for example, if the team can have a project manager. Personally, I think is important, since there are activities that are not mentioned in the Product Owner scope, such as schedule, status report, project cost, consultancy recruitment, project status meetings, cut over elaboration, integrated testing stages, go, hypercare, etc). If possible, hire experienced people because the in-house development is highly difficult.
This is a suggestive team model that you will use in ACT100. This governance model will align the project development, providing an agile orientation. Additionally, “agile” does not mean forgetting about actions, organization and documentation. Being agile demands a lot in terms of prior organization and preparation, including the fact of having well oriented and skilled workers involved in the project. Like this, I strongly recommend you do not act “agile” in an ERP implementation if you have not experienced this idea before – even if it is an ordinary project, try learning a bit of this “culture”.
I have been talking to companies and tried to see this in SAP projects, and it seems to be something that is described as a “reduced time methodology”. People usually do not mention the hard work for this – only the theoretical advantage on reduced time. I reinforce no agile resists without preparation.
The recommended Scrum approach in SAP Activate is used in several projects and follows existing models (if you wish to know more about SCRUM, there are many links available on the internet). Get ready, study and practice. Do not try it without understanding it, and develop the Scrum Master and Product Owner roles.
Every SCRUM tool is welcome and useful. As we see, training on the appropriate usage demands a lot of practice, but especially “culture” of being acquainted. At the EXPLORE phase, we have the great opportunity of practicing SCRUM.
At this point, users fully see the system operation and create the backlog along with consultants. Consultants can indicate the deltas in regards to what SAP provides – in the form of User Stories, for example, where user tells a story of how he/she develops the coordinated process, and then the process is split into activities that appear on the SCRUM board.
Product Owner should support the prioritization of backlog-cataloged items, being responsible for the classification based on the company’s needs and priorities – the integrated knowledge is a crucial feature for this character.
Scrum Master will mentor the methodology appropriate usage, supporting understanding and coordinating methodology required practical actions.
One of the ACT200 recommended techniques is the Planning Poker – which I struggle to accept since it seems to drive to average defined by the expert, in practice. Besides that, if we will use an expert, the practical inclination is close to his/her estimate, so I believe we can save time shortly directing it to the expert estimate.
In addition, it is crucial to establish a fair amount at the backlog exit in order to feed the sprints, at least for two weeks and up to four weeks. This streamlines the interaction and avoids waiste time in a moment the team is waiting for the implementation of items.
During Sprint process, we have to align the testing process on what is being delivered, integrated to the sprint. Depending on the items, we can test one by one or wait for the end of the sprint to test the package – some companies/projects hire a specific team for items testing, creating the UAT (User Acceptable Test) for the delivered packages. Please consider this option, since it may be a way of efficiently controlling the testing phase, besides the benefit of another separate point of view.
This whole process may and should be documented – there is a common misunderstanding here because some people still think being agile is having little or no paperwork. “Agile” means presenting an agile documentation. For example, in my opinion, code documentation seems useless (this will be in SAP and will be monitored by versions and mapped/analyzed by ATC – tool that reviews adherence to ABAP code).
SAP provides an amazing tool for each methodology phase: SOLMAN or Solution Manager. This tool allows us to download all the documentation templates that support the methodology and write whatever needed, directly in the tool. Furthermore, there are several possibilities in this tool, such as scenario download, best practices, testing routine development and documentation phase download (please check a reference article at https://www.linkedin.com/pulse/solman-um-pequeno-overview-jarlei-n).
I suggest (better late than never) to plan the post-implementation called HyperCare phase, which is not a part of the Activate as a methodology, in the RUN step, where we will have a project support team helping the immediate start once the project is implemented.
The team operation and interaction should be defined as soon as possible. I use to say that the Project itself is not as important as the daily routine, which is crucial. Careless planning/preparation is a high price to pay right in the project beginning, on Monday morning.
After this, the company is at a normal pace and improvement projects arrive – we may use the same implementation method but with more experience and strong onboarding. Try Scrum or another agile method in your company! Please note the interactive action is not something new, such as RAD, created by James Martin in 1991 [https://pt.wikipedia.org/wiki/Desenvolvimento_r%C3%A1pido_de_aplica%C3%A7%C3%B5es].
Moreover, the different ways of working (currently famous in the information systems area) come from the automotive industry and are adapted/adopted by the technology area. This history should be reviewed, so people can understand how these things arise and the importance of boosting people and companies, which may end the obsession of defining everything as agile, such as Agile PMO, agile developer, agile project manager, agile cafeteria. “Agile” is not a stamp or obligation. First of all: learn, practice and get used to it.
Regardless the methodology, Always tries using the continuing improvement process and, if possible, innovation and a lateral thinking. Try providing current available disruptive options for the company (virtual reality, augmented reality, IoT, M4, M2M, and a lot of LEAN – but this is a subject for another post).
[Shewhart] à Deming à Toyota System à Lean]
Would like to figure it out? Read about Deming.
Doesn’t matter the method, PDCA is the essence.
I look forward to hearing from you until the next post! Try attending ACT100 and ACT200 courses.
[ Linkedin article -> https://www.linkedin.com/feed/update/urn:li:linkedInArticle:6302248295209189376/ ]
A Practical Insight
Data Migration Tool
On Premise Methodology
SAP Best Practices
SAP Activate Community
ASAP Agile Methodology
Free SAP Courses
SAP Packages (Best Practices)
Agile Usage in SAP Project
Activate Information [blog]
Detailed SOLMAN Methodology
SAP and Agile
Access trial: http://cal.sap.com
New 30-day trial for SAP S/4HANA, on premise edition 1511 FPS 01 available
Agile Methodologies Overview
ABAP Code Inspector