Recently, I was involved in a full lifecycle implementation of SAP SAC with a large media company. Working closely with SAP product owners and developers, the SAP SAC project successfully went live at the end of 2019. We learned a lot during this implementation – so much that I thought I’d share my top 10 lessons as well as some recommendations to help your implementation go as smoothly as possible.
For SAC implementations, there needs to be a change in policy to keep the source systems up to date.
- Ensure your source systems are kept up-to-date and in line with recommendations in SAP Note 2541557
- This is one of the most important lessons learnt and will be relevant for any future SAP SAC implementation. It was often necessary to implement SAP notes and sometimes entire support packs in the source systems (in our case, both S/4 and BW) for SAC fixes to work. In addition to this, new functionality sometimes only worked with an up-to-date source system.
- For SAC implementations, there needs to be a change in policy to keep the source systems up-to-date in order to progress with SAC build. This will be at odds with the requirement to keep the source system stable if it is going through its own implementation. The recommendation is therefore to only implement SAC if the source systems are not going through their own implementation – go live with source systems first, then start the project for SAC implementation.
- Be prepared to employ work-arounds for fixes to fully work or to take advantage of new functionality
- Throughout the project, we often relied on temporary changes in the source systems to allow us to develop the SAC stories. A common temporary change was to either add or remove filters in the BEx layer so that the required selections were possible in SAC filters.
- You’ll need to design and develop a different solution for your live data connection
- Our SAC implementation started with showcasing mock-up SAC stories based on import data connections because the source systems were not available. When it came to designing and building the SAC stories that would go live, it became apparent the stories based on live data connections needed to be built differently. A good example of this was the need to build measure-on-measure variances with a live data connection, whereas version/time based variances were possible with an import data connection. It’s also necessary for the technical names of dimensions from different source systems to be identical if you want to use them in linked analysis. Although functionality may be possible in both import and live data connections, be prepared to design different solutions for live data connections.
- Be careful what you promise when showcasing functionality with an import data connection because that functionality might not be fully available with a live data connection
- Although the functional gap between these connection types is closing, there are still some important differences. If you intend to demonstrate SAC functionality to customers who intend to use the live data connection, you need to consider this.
My recommendation is to highlight what the live data connection can do that the import data connection cannot do. A good example of this is the inheritance of data security. A calculated dimension is a good example of functionality that works with an import data connection, but not a live data connection - so do not use this in your mock-ups and demonstrations.
- Be aware of limitations when reporting data from separate source systems in one story
Be aware of limitations when reporting data from separate source systems in one story.
- With the live data connection, we had a lot of difficulty with filters based on hierarchies from different models where the models were joined with linked dimensions. Although most of these issues are now resolved, there remains fundamental challenges when trying to join together data from different sources, which is probably one of the reasons data blending is still not an option for live data connections. Even when data blending does become available, I suspect it will be wrapped in caveats such as it only works for flat data structures that have the same technical names
- Keep on top of SAC updates – functionality is being enriched at a very fast pace, so what is not possible today might be possible tomorrow
- SAC tenants are updated either every two weeks or quarterly depending on the stability or access to the latest functionality is the biggest driver for a customer. To take maximum advantage of SAC, end users should keep abreast of the latest updates via https://www.sapanalytics.cloud/product_updates/.
- Make use of the SAP Influence site both to submit requests for functionality and to vote on others
Make use of the SAP Influence site both to submit requests for functionality and to vote on others.
- During a large implementation when a project might last more than a year, it is worth remembering that you can influence what functionality is implemented in future releases of SAC by submitting and voting on SAP’s Influence site https://influence.sap.com/sap/ino/. Using this site, we changed the priority for SAP for pieces of functionality that were critical to the project.
- Accept short-term limitations using SAC in mobile devices One of the big selling points of SAC is the ability to report from multiple mobile devices. Although this works well with the import data connection, there are limitations with live data connection. The entire architecture of the current mobile app is undergoing a redesign by SAP. Until the redesigned mobile app is available, SAP recommend using the Safari browser (embedded mode). However, with this option SAC prompts are suppressed, so only default values can be used – it is not possible to change these default values. Issues with Story and Page Filters are due to addressed in wave 04.2020.
- Accept that waterfall charts behave differently to other chart types
- As we discovered, waterfall charts do not have the full range of functionality. For example, the option for linked analysis on waterfall charts was removed during our implementation based on incidents we raised. There are other important traits of waterfall charts that need to be considered when designing SAC stories. See my next point.
- SAP BW nested selection limitation is inherited in SAC, so be careful how you restrict KFs in SAP BW if they are to be consumed in SAC
- One of the benefits of SAC with SAP as a source system is that it inherits functionality without the need for additional build work. A good example of this is with data security. However, if there are limitations in the source system, then these limitations are also inherited. As an example, SAP BW is unable to report an RKF on another RKF if they are restricted by the same characteristic (i.e. nested selections on same characteristic) because this leads to a complex restriction that cannot be handled by SAP. See KBA 1962321 for an illustration. This limitation is compounded by the fact an SAC waterfall chart acts like an RKF. It is therefore not possible to include an RKF in an SAC waterfall chart if the RKF is restricted by the same characteristic (i.e. dimension) as the dimension used in the waterfall chart.
I hope these lessons were helpful – SAC is a great solution when implemented right, and our client was very happy with the result. Please do not hesitate to get in touch, and please share your experiences implementing SAC in the comments below.
