In my role as CIO of Johnsonville, I am analyzing indirect access, the impact of digital access licensing, and the pros and cons of adopting the new licensing model. I have committed to documenting that process and sharing insights with you in a series of blog posts.
Where Johnsonville’s Indirect Access Journey Started
In my first post, I provided some background and laid out Johnsonville’s high-level approach to the process. In my second post, I walked through the actual steps Johnsonville took to get a first-pass estimate of our document counts. In this post, I will recap insights and additional questions that resulted from my meeting with the SAP Global License, Audit, and Compliance (GLAC) and Pricing teams.
I highly recommend reading the first and second posts in this series so that you will have a base understanding of indirect access, SAP Digital Access, and the Johnsonville use case. The key insights I share here will be more valuable once you have this background.
Digging into the "Indirect" in Indirect Access
Even after spending two years with SAP on the topic of indirect access, I still encounter the occasional “aha” or “ugh” moment. While discussing Johnsonville’s use of third party software as a service (SaaS) solutions, I was reminded of the “indirect” in indirect access. Let me use two examples that we uncovered in our review of our document counts and the associated interfaces. In each case, there is no direct transfer of information from a third party to SAP S/4HANA—they are both examples of data flowing through an intermediate system.
Indirect Access Data Flow Example 1: Claims, Deductions, and Cash
The first example revolves around our use of a third-party SaaS solution that automates the claims, deductions, and cash application processes for Johnsonville. At a very high level, there are four parties involved in settling claims and deductions and subsequently applying cash to open invoices in SAP: Johnsonville, our customers, our banks, and our SaaS provider.
Our third-party application performs two basic functions. First, it automates the collection of information and documentation required to support or dispute claims and deductions from our customers. The other basic function of the solution is to process payment information. Customers submit payment information to lockboxes at our banks. The banks, in turn, send remittance advice to our SaaS solution, which matches payments to open invoices, claims, and deductions to provide recommendations. Once that process is complete, Johnsonville members review the recommendations, make any adjustments that are necessary, and then approve them. Once approved, payment information is sent to SAP for the typical cash application process.
So, what’s the issue? In discussion with the SAP audit team, my understanding is that all customer and bank employees engaged in entering or preparing data that is ultimately sent to the third-party application need to be licensed as SAP Named Users. There are two obvious concerns here. First, neither SAP nor Johnsonville have any method of accurately counting the number of potential users within the bank or the customers submitting data. Second, even if we could count the number of users, that would potentially be a very large number. Given that the actual number of users can never be accurately counted (or even estimated), the Named User licenses required would be a matter of negotiation.
Indirect Access Data Flow Example 2: Transportation Management
Johnsonville has a similar indirect access scenario related to our use of a third-party SaaS-based Transportation Management System (TMS). The particular issue uncovered by the document estimation process involved supplier invoice line items (one of the nine document types) generated by the integration of freight invoices from the TMS solution to SAP S/4HANA. Under the legacy licensing model, employees of external partners creating data that eventually enters SAP ECC or SAP S/4HANA need to be licensed as indirect users—regardless of the document type or type of access (read/write/update/delete). In our scenario under our legacy contract, every carrier that submits an invoice to the third-party TMS solution will be required to have an SAP Named User license for each of its employees engaged in creating those invoices. Because the documents being created are one of the nine document types, this indirect access is also relevant under the Digital Access Licensing model.
The incorrect assumption I have been making for the past 15 years is that as long as all the Johnsonville users of the third-party solutions were fully licensed SAP users, then the data flowing from those third-party solutions to SAP was part of our entitlement.
Getting the SAP Document Counts Right
One of the fundamental design concepts of the SAP Digital Access model is the idea that documents created within SAP subsequent to the creation of an initial document are not counted. Unfortunately, the SAP document estimation tools are not smart enough to separate initial documents from subsequent documents, which is why they overestimate the number of documents needed in certain situations. To overcome this limitation of the tool, SAP has established the Digital Access Evaluation Service, delivered by the GLAC team. I would highly recommend using this service prior to licensing conversations with your account executive to make sure you have accurate document counts.
What’s Included Vs. Excluded from SAP Document Counts
As I have shared in the past, Johnsonville uses EDI to integrate our third-party logistics (3PL) warehouses. We record all inventory movements and adjustments at those 3PLs within SAP S/4HANA. Let’s use a simple inventory adjustment transaction as an example: When a 3PL makes an inventory adjustment, that adjustment transaction is sent via EDI to Johnsonville and creates an initial material document as part of the EDI interface job. The creation of the material document triggers the creation of multiple financial documents within SAP S/4HANA. These financial documents are recorded with the Technical User ID of the EDI interface—however, the financial documents were created within SAP subsequent to the material document without further input from outside of SAP S/4HANA. As a result, the financial documents are not relevant for SAP Digital Access.
Long story short, the financial documents created in this scenario need to be excluded from the document counts provided by the estimation tool. This is a manual exercise that will rely on some assumptions/estimations when you are trying to derive a final document count. Note that the counting of subsequent documents does not occur if/when the new SAP Passport technology is implemented because the subsequent documents created within the ERP system will be tagged with a valid passport indicator.
Revealing “Hidden” Indirect Access Examples
One topic that I will continue pursuing with SAP is the indirect access that occurs but will not be measured using the existing SAP Passport technology available today.
As I highlighted in the second post in this series, one of our interfaces is a foreground job executed by a named dialog user that transfers time and attendance data to CATS from a third-party system. By SAP’s definition, the transfer of time and attendance data to CATS tables is indirect access and needs to be licensed. These transactions will be “hidden” due to the fact they are generated by a dialog user in a foreground job. These documents will be tagged with an SAP Passport, making them appear as if they were entered by a hands-on keyboard user logged into SAP GUI. This same issue occurs with robotic process automation (RPA) tools that sit on top of the SAP GUI.
If SAP cannot specifically identify these transactions, how can I realistically manage my compliance? Can I safely assume that any transaction stamped with an SAP Passport will be considered compliant? Given the existing audit tools, SAP can identify user IDs that appear to be abnormally efficient at creating transactions and may use that information as an indicator that some sort of indirect access is occurring (either through non-SAP RPA assistance or foreground jobs). How that access is measured, licensed, and managed—under either legacy or Digital Access models—becomes unclear.
SAP will continue making enhancements to its measurement tools and I am confident SAP will find a means to measure this “hidden” access in the future. The risk is that these hidden documents become exposed after licensing under the SAP Digital Access model and customers will face additional licensing requirements. Again, I would encourage engaging the GLAC team to help expose and quantify these potential licensing gaps and identify a means for you to mitigate future risk.
How Robotic Process Automation (RPA) Fits Within Indirect Access
I recently met with the SAP GLAC team in Walldorf, Germany to discuss the issue of RPA, along with proposed measurement options. To be clear, SAP considers documents created with the assistance of RPA tools (either attended or unattended) as "Use" of the software. Every SAP contract (unless otherwise negotiated) has a definition of "Use," and all "Use" is required to be licensed. As such, the RPA-assisted activity needs to be appropriately licensed under both legacy contracts and under Digital Access. I will have an update on the RPA topic in the near future.
Next Step: Prepping for the Digital Access Cost Estimation
Our next steps are to clarify several open questions and ultimately fine-tune the document counts required to cover our current use. We are also looking to understand the cost to become compliant under legacy contracts. Over the next few weeks, we will attempt to come to a resolution on the following topics:
- Estimating the number of documents that are considered “subsequent” documents and are therefore irrelevant for digital access.
- Understanding the cost to become compliant in our human capital management (HCM) Time and Attendance use case.
- Getting a definitive answer on RPA and dialog-user based interfaces.
- Understanding our liability and potential licensing costs to become compliant on our third-party SaaS solutions for our claims/deductions/cash application and TMS freight invoices.
- Understanding more definitively which documents are covered under our existing Sales and Service Order Processing entitlements.
- We still have an outstanding question regarding SAP Manufacturing Integration and Intelligence (MII) entitlements for shop floor integration. Ultimately, we need to understand what use cases that use MII for integration to SAP S/4HANA would be considered indirect access, if any.
We hope to have answers to a number of these items within the next few weeks.
Visit our Licensing Resource Center for in-depth coverage of this topic. You can also send your questions to licensing@asug.com or register for one of our licensing webcasts for ASUG members. Additionally, we welcome all ASUG members to submit their ideas for blog posts they want to write.