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 SAP’s new licensing model. I have committed to documenting that process and sharing insights with you in a series of blog posts.
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 my third post, I recapped insights and additional questions that resulted from my meeting with the SAP Global License, Audit, and Compliance (GLAC) and Pricing teams.
In this installment, I will try to bring closure to a number of open questions and issues outlined at the end of the previous blog, which include:
- Estimating the number of documents that are considered “subsequent” documents and are therefore irrelevant to SAP Digital Access
- Finding an equitable resolution to our time and attendance interface with ECC human capital management (HCM)
- Getting a definitive answer on robotic process automation (RPA) and dialog user-based interfaces
- Clarifying with SAP our understanding of entitlements included with SAP Manufacturing Intelligence and Integration (MII) for shop-floor integration
- Understanding more definitively which documents are covered under our existing sales and service order processing entitlements
- Agreeing on a “good enough” estimate of documents to move forward with licensing and negotiations (subsequent documents, SAP to SAP, etc.)
Estimating “Subsequent” Documents
Unfortunately, without having the SAP Passport technology implemented across all SAP solutions in our landscape, there is no definitive way of separating original or source documents from subsequent documents. The SAP GLAC team first had to identify the business transactions passing through a particular interface and then look at the ratio between “original” documents and what would most likely be subsequent documents.
For instance, we know that the EDI batch interface is primarily used as an interface between our customers, third-party logistics (3PL), and SAP. The “source” documents being created are either sales order lines or material documents (post goods issue, adjustments, etc.). Financial documents are created within SAP S/4HANA as a result of, or subsequent to, the creation of the initial material document. It is the opinion of SAP that it is “reasonable” that inventory transactions that create a material document would create two financial documents. As you can see in the example below, in a number of the interfaces (i.e., RFCSCALE), the ratio between material documents and financial documents is exactly 2-to-1. For Johnsonville’s EDI batch interfaces, the ratio is approximately 2.5-to-1.
Our question on this issue is whether or not there are transactions coming through our EDI interface that are directly generating financial documents as the “original” document. Our approach here will be to modify the query SAP is using for the financial document counts to exclude any documents that have a material number attached—the assumption (maybe bad) being that financial documents without an associated material document would be original documents created for purposes other than inventory-related transactions.
As I have stated in previous blogs, once you are comfortable with your initial assessment and with engaging SAP, I would encourage you to take advantage of the Digital Access Evaluation Service offered through the SAP GLAC team. In our case, the estimation tool substantially overestimated the number of required documents. The GLAC team can assist in fine-tuning the document counts.
Resolving Our Time and Attendance to HCM Issue
As I discussed in an earlier blog, Johnsonville originally deployed an interface strategy in 2004 to pass time-and-attendance records from our third-party system to HCM with cross-application time sheet (CATS) tables as the initial interface point rather than going directly to the HCM information types used for payroll purposes. Today, we generate more than two million documents a year using this interface. The approach we have taken is considered relevant for Digital Access by SAP. Yet if we modify the interface to directly update the appropriate HCM infotype (and bypass the CATS tables), we would be compliant with no Digital Access requirements.
We will address this issue with SAP during our license negotiation, as the cost and effort involved in rewriting this interface does not add any value to our business.
Getting a Definitive Answer to RPA and RPA-Like Tools
In my last blog I shared the feedback from SAP regarding RPA: SAP has reiterated the fact that RPA constitutes use, and all use must be appropriately licensed. More important to the conversation, however, is the position that a named user license that is also used for hands-on keyboard activity by a user does not constitute appropriately licensed use. As I also discussed, the fact that these tools typically use dialog-based named users means the SAP Passport technology will not count these documents. Unless you include the named dialog users using RPA tools in the estimation tool, you will not “see” the RPA-generated documents in the final report.
As of this writing, SAP has not published clarification on how RPA use will be measured or how RPA use should be licensed—either under legacy contracts or Digital Access. This continues to be a significant risk issue for Johnsonville. We currently use RPA tools and have always felt we were compliant, as the RPA users were appropriately licensed named users.
Entitlements Included with SAP Manufacturing Intelligence and Integration
One of our open questions to SAP was clarification of SAP MII as an interface between SAP and non-SAP solutions. SAP MII is marketed and sold as a solution to interface third-party solutions, technologies, and databases in a manufacturing environment with SAP ERP. Our SAP MII license is based on number of employees. We simply needed to get clarification from SAP that all data that flows through SAP MII to/from other SAP solutions was considered appropriately licensed if we had appropriately licensed the MII software. SAP has acknowledged that data originating in a facility appropriately licensed for SAP MII that ultimately ends up in SAP ERP via MII transactions/interfaces is not indirect access under legacy contracts. Additionally, SAP MII to SAP ERP is considered SAP Application Access and is therefore not relevant under Digital Access.
Sales and Service Order License Swap
When Johnsonville licensed SAP in 2003, we licensed the Sales and Service Order Processing (SSOP) engine. This engine covers all indirect use associated with the order-to-cash processing of customer orders. We have received an initial proposal to convert our SSOP entitlements as part of the Digital Access licensing proposal from SAP and are currently evaluating the trade-offs. To be clear, the conversion program offered under DAAP is the same conversion program SAP offers for other license conversions—a net-to-net license fee conversion. At this point we are working through an analysis based on entitlement conversion, not net price. What I need to understand is what I am giving up in terms of entitlements to move to SAP Digital Access. I will share our calculation and comparison in the next blog.
Where Does Johnsonville Go from Here?
At this point, I believe we have a good enough estimate of documents to begin negotiating with SAP on a fair and equitable transition to the SAP Digital Access model. Before we can finalize a decision, we will need to come to an agreement on:
- A resolution to our HCM and time and attendance interface
- License swap value for sales and service order processing
- A definitive answer on RPA
I do believe there are long-term benefits to moving to the SAP Digital Access model if we can come to terms on an equitable commercial agreement. There is still plenty of work to do to get comfortable with the long-term cost/benefit and risk analysis.
Visit our Licensing Resource Center for in-depth coverage of this topic. You can also send your questions to firstname.lastname@example.org 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.