In my role as CIO of John­sonville, I am ana­lyz­ing indi­rect access, the impact of dig­i­tal access licens­ing, and the pros and cons of adopt­ing the new licens­ing mod­el. I have com­mit­ted to doc­u­ment­ing that process and shar­ing insights with you in a series of blog posts.

Where Johnsonville’s Indi­rect Access Jour­ney Started

In my first post, I pro­vid­ed some back­ground and laid out Johnsonville’s high-lev­el approach to the process. In my sec­ond post, I walked through the actu­al steps John­sonville took to get a first-pass esti­mate of our doc­u­ment counts. In this post, I will recap insights and addi­tion­al ques­tions that result­ed from my meet­ing with the SAP Glob­al License, Audit, and Com­pli­ance (GLAC) and Pric­ing teams.

I high­ly rec­om­mend read­ing the first and sec­ond posts in this series so that you will have a base under­stand­ing of indi­rect access, SAP Dig­i­tal Access, and the John­sonville use case. The key insights I share here will be more valu­able once you have this background.

Dig­ging into the ​“Indi­rect” in Indi­rect Access

Even after spend­ing two years with SAP on the top­ic of indi­rect access, I still encounter the occa­sion­al ​“aha” or ​“ugh” moment. While dis­cussing Johnsonville’s use of third par­ty soft­ware as a ser­vice (SaaS) solu­tions, I was remind­ed of the ​“indi­rect” in indi­rect access. Let me use two exam­ples that we uncov­ered in our review of our doc­u­ment counts and the asso­ci­at­ed inter­faces. In each case, there is no direct trans­fer of infor­ma­tion from a third par­ty to SAP S/4HANA — they are both exam­ples of data flow­ing through an inter­me­di­ate system.

Indi­rect Access Data Flow Exam­ple 1: Claims, Deduc­tions, and Cash

The first exam­ple revolves around our use of a third-par­ty SaaS solu­tion that auto­mates the claims, deduc­tions, and cash appli­ca­tion process­es for John­sonville. At a very high lev­el, there are four par­ties involved in set­tling claims and deduc­tions and sub­se­quent­ly apply­ing cash to open invoic­es in SAP: John­sonville, our cus­tomers, our banks, and our SaaS provider.

Our third-par­ty appli­ca­tion per­forms two basic func­tions. First, it auto­mates the col­lec­tion of infor­ma­tion and doc­u­men­ta­tion required to sup­port or dis­pute claims and deduc­tions from our cus­tomers. The oth­er basic func­tion of the solu­tion is to process pay­ment infor­ma­tion. Cus­tomers sub­mit pay­ment infor­ma­tion to lock­box­es at our banks. The banks, in turn, send remit­tance advice to our SaaS solu­tion, which match­es pay­ments to open invoic­es, claims, and deduc­tions to pro­vide rec­om­men­da­tions. Once that process is com­plete, John­sonville mem­bers review the rec­om­men­da­tions, make any adjust­ments that are nec­es­sary, and then approve them. Once approved, pay­ment infor­ma­tion is sent to SAP for the typ­i­cal cash appli­ca­tion process.

So, what’s the issue? In dis­cus­sion with the SAP audit team, my under­stand­ing is that all cus­tomer and bank employ­ees engaged in enter­ing or prepar­ing data that is ulti­mate­ly sent to the third-par­ty appli­ca­tion need to be licensed as SAP Named Users. There are two obvi­ous con­cerns here. First, nei­ther SAP nor John­sonville have any method of accu­rate­ly count­ing the num­ber of poten­tial users with­in the bank or the cus­tomers sub­mit­ting data. Sec­ond, even if we could count the num­ber of users, that would poten­tial­ly be a very large num­ber. Giv­en that the actu­al num­ber of users can nev­er be accu­rate­ly count­ed (or even esti­mat­ed), the Named User licens­es required would be a mat­ter of negotiation.

Indi­rect Access Data Flow Exam­ple 2: Trans­porta­tion Management

John­sonville has a sim­i­lar indi­rect access sce­nario relat­ed to our use of a third-par­ty SaaS-based Trans­porta­tion Man­age­ment Sys­tem (TMS). The par­tic­u­lar issue uncov­ered by the doc­u­ment esti­ma­tion process involved sup­pli­er invoice line items (one of the nine doc­u­ment types) gen­er­at­ed by the inte­gra­tion of freight invoic­es from the TMS solu­tion to SAP S/4HANA. Under the lega­cy licens­ing mod­el, employ­ees of exter­nal part­ners cre­at­ing data that even­tu­al­ly enters SAP ECC or SAP S/4HANA need to be licensed as indi­rect users — regard­less of the doc­u­ment type or type of access (read/​write/​update/​delete). In our sce­nario under our lega­cy con­tract, every car­ri­er that sub­mits an invoice to the third-par­ty TMS solu­tion will be required to have an SAP Named User license for each of its employ­ees engaged in cre­at­ing those invoic­es. Because the doc­u­ments being cre­at­ed are one of the nine doc­u­ment types, this indi­rect access is also rel­e­vant under the Dig­i­tal Access Licens­ing model.

The incor­rect assump­tion I have been mak­ing for the past 15 years is that as long as all the John­sonville users of the third-par­ty solu­tions were ful­ly licensed SAP users, then the data flow­ing from those third-par­ty solu­tions to SAP was part of our entitlement.

Get­ting the SAP Doc­u­ment Counts Right

One of the fun­da­men­tal design con­cepts of the SAP Dig­i­tal Access mod­el is the idea that doc­u­ments cre­at­ed with­in SAP sub­se­quent to the cre­ation of an ini­tial doc­u­ment are not count­ed. Unfor­tu­nate­ly, the SAP doc­u­ment esti­ma­tion tools are not smart enough to sep­a­rate ini­tial doc­u­ments from sub­se­quent doc­u­ments, which is why they over­es­ti­mate the num­ber of doc­u­ments need­ed in cer­tain sit­u­a­tions. To over­come this lim­i­ta­tion of the tool, SAP has estab­lished the Dig­i­tal Access Eval­u­a­tion Ser­vice, deliv­ered by the GLAC team. I would high­ly rec­om­mend using this ser­vice pri­or to licens­ing con­ver­sa­tions with your account exec­u­tive to make sure you have accu­rate doc­u­ment counts.

What’s Includ­ed Vs. Exclud­ed from SAP Doc­u­ment Counts

As I have shared in the past, John­sonville uses EDI to inte­grate our third-par­ty logis­tics (3PL) ware­hous­es. We record all inven­to­ry move­ments and adjust­ments at those 3PLs with­in SAP S/4HANA. Let’s use a sim­ple inven­to­ry adjust­ment trans­ac­tion as an exam­ple: When a 3PL makes an inven­to­ry adjust­ment, that adjust­ment trans­ac­tion is sent via EDI to John­sonville and cre­ates an ini­tial mate­r­i­al doc­u­ment as part of the EDI inter­face job. The cre­ation of the mate­r­i­al doc­u­ment trig­gers the  cre­ation of mul­ti­ple finan­cial doc­u­ments with­in SAP S/4HANA. These finan­cial doc­u­ments are record­ed with the Tech­ni­cal User ID of the EDI inter­face — how­ev­er, the finan­cial doc­u­ments were cre­at­ed with­in SAP sub­se­quent to the mate­r­i­al doc­u­ment with­out fur­ther input from out­side of SAP S/4HANA. As a result, the finan­cial doc­u­ments are not rel­e­vant for SAP Dig­i­tal Access.

Long sto­ry short, the finan­cial doc­u­ments cre­at­ed in this sce­nario need to be exclud­ed from the doc­u­ment counts pro­vid­ed by the esti­ma­tion tool. This is a man­u­al exer­cise that will rely on some assumptions/​estimations when you are try­ing to derive a final doc­u­ment count. Note that the count­ing of sub­se­quent doc­u­ments does not occur if/​when the new SAP Pass­port tech­nol­o­gy is imple­ment­ed because the sub­se­quent doc­u­ments cre­at­ed with­in the ERP sys­tem will be tagged with a valid pass­port indicator.

Reveal­ing ​“Hid­den” Indi­rect Access Examples

One top­ic that I will con­tin­ue pur­su­ing with SAP is the indi­rect access that occurs but will not be mea­sured using the exist­ing SAP Pass­port tech­nol­o­gy avail­able today.

As I high­light­ed in the sec­ond post in this series, one of our inter­faces is a fore­ground job exe­cut­ed by a named dia­log user that trans­fers time and atten­dance data to CATS from a third-par­ty sys­tem. By SAP’s def­i­n­i­tion, the trans­fer of time and atten­dance data to CATS tables is indi­rect access and needs to be licensed. These trans­ac­tions will be ​“hid­den” due to the fact they are gen­er­at­ed by a dia­log user in a fore­ground job. These doc­u­ments will be tagged with an SAP Pass­port, mak­ing them appear as if they were entered by a hands-on key­board user logged into SAP GUI. This same issue occurs with robot­ic process automa­tion (RPA) tools that sit on top of the SAP GUI.

If SAP can­not specif­i­cal­ly iden­ti­fy these trans­ac­tions, how can I real­is­ti­cal­ly man­age my com­pli­ance? Can I safe­ly assume that any trans­ac­tion stamped with an SAP Pass­port will be con­sid­ered com­pli­ant? Giv­en the exist­ing audit tools, SAP can iden­ti­fy user IDs that appear to be abnor­mal­ly effi­cient at cre­at­ing trans­ac­tions and may use that infor­ma­tion as an indi­ca­tor that some sort of indi­rect access is occur­ring (either through non-SAP RPA assis­tance or fore­ground jobs). How that access is mea­sured, licensed, and man­aged — under either lega­cy or Dig­i­tal Access mod­els — becomes unclear.

SAP will con­tin­ue mak­ing enhance­ments to its mea­sure­ment tools and I am con­fi­dent SAP will find a means to mea­sure this ​“hid­den” access in the future. The risk is that these hid­den doc­u­ments become exposed after licens­ing under the SAP Dig­i­tal Access mod­el and cus­tomers will face addi­tion­al licens­ing require­ments. Again, I would encour­age engag­ing the GLAC team to help expose and quan­ti­fy these poten­tial licens­ing gaps and iden­ti­fy a means for you to mit­i­gate future risk.

How Robot­ic Process Automa­tion (RPA) Fits With­in Indi­rect Access

I recent­ly met with the SAP GLAC team in Wall­dorf, Ger­many to dis­cuss the issue of RPA, along with pro­posed mea­sure­ment options. To be clear, SAP con­sid­ers doc­u­ments cre­at­ed with the assis­tance of RPA tools (either attend­ed or unat­tend­ed) as ​“Use” of the soft­ware. Every SAP con­tract (unless oth­er­wise nego­ti­at­ed) has a def­i­n­i­tion of ​“Use,” and all ​“Use” is required to be licensed. As such, the RPA-assist­ed activ­i­ty needs to be appro­pri­ate­ly licensed under both lega­cy con­tracts and under Dig­i­tal Access. I will have an update on the RPA top­ic in the near future.

Next Step: Prep­ping for the Dig­i­tal Access Cost Estimation

Our next steps are to clar­i­fy sev­er­al open ques­tions and ulti­mate­ly fine-tune the doc­u­ment counts required to cov­er our cur­rent use. We are also look­ing to under­stand the cost to become com­pli­ant under lega­cy con­tracts. Over the next few weeks, we will attempt to come to a res­o­lu­tion on the fol­low­ing topics:

• Esti­mat­ing the num­ber of doc­u­ments that are con­sid­ered ​“sub­se­quent” doc­u­ments and are there­fore irrel­e­vant for dig­i­tal access.
• Under­stand­ing the cost to become com­pli­ant in our human cap­i­tal man­age­ment (HCM) Time and Atten­dance use case.
• Get­ting a defin­i­tive answer on RPA and dia­log-user based interfaces.
• Under­stand­ing our lia­bil­i­ty and poten­tial licens­ing costs to become com­pli­ant on our third-par­ty SaaS solu­tions for our claims/​deductions/​cash appli­ca­tion and TMS freight invoices.
• Under­stand­ing more defin­i­tive­ly which doc­u­ments are cov­ered under our exist­ing Sales and Ser­vice Order Pro­cess­ing entitlements.
• We still have an out­stand­ing ques­tion regard­ing SAP Man­u­fac­tur­ing Inte­gra­tion and Intel­li­gence (MII) enti­tle­ments for shop floor inte­gra­tion. Ulti­mate­ly, we need to under­stand what use cas­es that use MII for inte­gra­tion to SAP S/4HANA would be con­sid­ered indi­rect access, if any.

We hope to have answers to a num­ber of these items with­in the next few weeks.

Vis­it our Licens­ing Resource Cen­ter for in-depth cov­er­age of this top­ic. You can also send your ques­tions to licensing@​asug.​com or reg­is­ter for one of our licens­ing web­casts for ASUG mem­bers. Addi­tion­al­ly, we wel­come all ASUG mem­bers to sub­mit their ideas for blog posts they want to write.