Search

Technologies & Products

Best of Breed Process & Technology for New SAP Implementations – Part 2

In a recent post, we explored the benefits of using an agile approach to new SAP implementations.

In this article I’ll consider a more practical angle on those themes. We’ll take a quick look at SAP Activate – SAP’s agile methodology – and dive into some more specifics on the kind of automation that can support it (or any agile approach to SAP implementations, for that matter).

SAP Activate

SAP Activate has been around for a few years now; it is combination of SAP-defined best practices, methodology, and guided configuration, split across a number of phases – Discover, Prepare, Explore, Realize, Deploy and Run – which can be approached in an agile fashion (if you choose to do so). Really it’s a kind of Water-agile-fall, since everything typically goes live in one hit, but that’s natural given we’re talking about new implementations.

Activate works on the premise of leveraging existing content (typically an SAP Model Company) to jump start the process. Instead of starting from a blank slate at the beginning of an implementation, SAP consultants use the pre-defined content to run workshops that identify gaps where specific customer needs aren’t met. This is typically known as the Fit-Gap analysis and is done during the Explore phase.

Gaps that are identified essentially form the basis of what needs to be built. In agile speak, they form stories that go into the Backlog.

The Realize phase is SAP Activate is where the development action happens, and is probably the part where an agile approach has the most impact. It is essentially run in an agile-like manner, with 2-4 week iterations. Work is prioritized and pulled from the Backlog, and at the end of each iteration a showcase is run giving the customers (i.e. end users) a chance to review and feedback.

While this agile approach is great, like all implementations, it needs to be supported by tools and technology to make it work, so I’d like to suggest some possible solutions that can support the process.

SAP Best Practices Explorer

So much of this approach to SAP implementation relies on pre-configured best practices from SAP that the first tool I would propose is SAP’s Best Practices Explorer.

SAP Best Practices Explorer organizes content in a hierarchical manner starting at the Solution Package level, e.g. S/4HANA On-Premise Edition, and then breaking down into Scope Item Group, e.g. Sales. From there, it further breaks down into Scope Item Sub-Group before finally getting to the Scope Item.

See the diagram below…

Figure 1 – SAP Best Practices Explorer

Within the Scope Item itself, customers will be able to find the Scope Item Details which include process flows, test scripts and other artifacts that can be used to jump start the Realize phase.

Figure 2 – Scope Item Details
Figure 3 – Scope Item Details

Atlassian Jira for Backlog Management & Project Tracking

The result of running the Fit-Gap analysis sessions using SAP Best Practices Explorer is essentially a backlog of work items that need to be configured and implemented for the customer.

As such, we will need a backlog management tool to capture and track all of these requirements. Ideally that tool will be capable of following a structure similar to SAP’s Best Practices Explorer to make it easy to map and relate the backlog items to the original Scope Items.

It turns out that one of the most popular agile backlog management tools in the market, Atlassian Jira, has the capability to mimic this structure.

See the diagram below taken the Jira website.

Figure 4 – Jira hierarchy

In this case, we can map…

  • Jira Initiative to Scope Item Group in Best Practices Explorer
  • Jira Epic to Scope Item Sub-Group in Best Practices Explorer
  • Jira Story to Scope Items in Best Practices Explorer
Figure 5 – Mapping SAP Best Practices Explorer to Atlassian Jira Agile

From a timeline perspective, Jira allows its users to create Sprints which can be effectively mapped to SAP Best Practice Explorer iterations.

When work is prioritized from the Backlog, users can simply drag the story into the Sprint in Jira and start tracking progress.

Linking Plan to Execution in SAP with ActiveControl

As work is planned and tracked in Jira, actual implementation is done and deployed completely in SAP.

This is where an SAP-focused change and release automation solution like ActiveControl from Basis Technologies comes in.

ActiveControl provides a single platform for SAP teams to manage and operate the entire change and release process for SAP.

ActiveControl has the facility to…

  1. Capture the business change requests (called Business Tasks in ActiveControl);
  2. Connect them with the actual SAP Transports that contain the SAP configuration and code changes that implement the requested change(s);
  3. Fully automate the end-to-end process of deploying the SAP transports across the SAP landscape;
  4. Carry out these automated deployments safely, leveraging 60+ quality analyzers that check for all sorts of issues that could potentially arise when SAP Transports are deployed.

More importantly, ActiveControl also provides a governance framework (comprised of approval workflows and audit trails) that is highly configurable to support every customer’s needs.

As to how your Initiatives, Epics and Stories (or in this case Scope Item Group, Scope Item Sub-Groups and Scope Items) in Jira are connected with the practical implementation steps managed by ActiveControl, you can find a lot more detail in this blog.

What about Quality?

Quality is an essential aspect of any SAP implementation; the business needs processes to work as designed from day one and given the typically high costs of a new SAP rollout, no-one wants to increase them further with rework and delays. Quality should be baked into whatever approach we take, but is arguably more important than ever in the rapid cycles of an agile implementation.

How do we do that?

Let’s start with the quality of the code or the SAP configuration. We need to ensure activities such as code quality analysis, unit testing and peer reviews are performed during each sprint.

ActiveControl helps here. At a basic level it can be used to ensure transports don’t progress until someone confirms that relevant quality checks have been carried out. More commonly though, the suite of analyzers I just mentioned would be used. The analyzers can be set up to run automatically at user-configured control points, ensuring that code never leaves a dev system without meeting the necessary standards.

More rigorous quality checks at an early stage should reduce the burden on QA teams but testing remains a critical part of the implementation process (from UAT to integration, and so on). Many agile implementations will employ automated testing tools help them cope with the limited time available for testing in each sprint.

ActiveControl can streamline such a process by connecting to test automation tools through platforms like Jenkins or Node-RED, allowing them to be triggered automatically as part of the transport deployment process.

Whatever type of testing you run (manual or automated) ActiveControl acts as the single control point and source of truth. Confirmation of testing and associated test results (perhaps in an attached document, or via a link to a test management system) can be recorded in an ActiveControl Business Task and used as another criterion for whether transports are ready to progress on to the next system in the landscape.

Greenfield means no regression testing though, right…?

This is the natural assumption for many people. After all, what would regression testing even mean if there’s no live system (i.e. no ‘before’ state) to compare against?

But in fact, running an implementation project in a more agile fashion may provide just such a baseline on a regular basis. Rather than waiting until the end of the project for an integrated test phase followed by a big-bang cutover, in our agile approach we’re constantly building and showcasing progress. That means at the end of every sprint we have a ‘before’ and ‘after’ we could compare. With effective regression testing as part of the process we can be more confident that new development doesn’t cause problems and delays by breaking what’s already been built.

This is where a regression test automation tool like Testimony from Basis Technologies may come into play. Unlike other test automation tools, Testimony does not rely on test scripts. Instead it can generate new test libraries automatically with very high coverage in a short space of time – just what you need when you have a system that is frequently changing and you’re working against tight time constraints.

You can find out more about how Testimony works by checking out the video here.

Conclusion

SAP implementation has come a long way since the 1980s, and today it’s certainly possible to set up your systems using an agile approach. In fact, SAP themselves have moved from their traditional ASAP methodology to SAP Activate, a much more agile philosophy, albeit with some elements that are understandably closer to waterfall than ‘pure’ agile development.

However, process alone is not enough, and it needs to be supported by the right technology. In this blog, I proposed SAP Best Practices Explorer, Atlassian Jira and Basis Technologies’ ActiveControl and Testimony as some of the tools that can combine to support a faster, safer, more effective SAP implementation.

To learn more about our technology and how it can help your business, request a demo.  

Share this post

Recent posts

Get a demo

Learn More About Our DevOps and Testing Platform

Search

Read more

News, Technologies & Products