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. In the first post, I pro­vid­ed some back­ground and laid out Johnsonville’s high-lev­el approach to the process. In this post, I will cov­er the ini­tial steps we took to get an under­stand­ing of our indi­rect access expo­sure and an esti­mate of doc­u­ments required to address that expo­sure under the SAP Dig­i­tal Access licens­ing model.

Before I con­tin­ue, I need to note my lack of tech­ni­cal knowl­edge. I have great folks at John­sonville who are experts in secu­ri­ty, BASIS, ABAP, and con­fig and have tried might­i­ly — in a very short time — to edu­cate me on SAP tech­ni­cal jar­gon. I have done my best to learn, how­ev­er, I may have butchered some tech­ni­cal details here.

And now, back to my favorite top­ic — indi­rect access.

Start­ing with the Basics

Like many SAP cus­tomers, John­sonville is a bit appre­hen­sive about invit­ing the SAP Audit and Sales teams into its envi­ron­ment to dis­cuss indi­rect access with­out first hav­ing a good under­stand­ing of what our poten­tial expo­sure may be. Our approach will be to per­form as much due dili­gence as we can inter­nal­ly and then engage the SAP teams to eval­u­ate and fine-tune our findings.

For our ini­tial assess­ment of indi­rect access we took a four-step approach:

Step 1: Iden­ti­fy the inter­faces with SAP that could be gen­er­at­ing indi­rect access.

Step 2: Iden­ti­fy the user IDs that are embed­ded in inter­faces, whether they be batch or real-time jobs.

Step 3: Run the SAP Dig­i­tal Access Esti­ma­tor Tool using the iden­ti­fied user IDs to get ini­tial doc­u­ment counts.

Step 4: Eval­u­ate results from the esti­ma­tor tool to iden­ti­fy miss­ing doc­u­ments and areas to explore. Based on these results and iden­ti­fied miss­ing doc­u­ments, repeat steps 1 – 4.

Iden­ti­fy­ing the Interfaces

Inter­faces with third-par­ty solu­tions will be the pri­ma­ry points where indi­rect access man­i­fests with­in our SAP land­scape. At John­sonville, our main inter­face tech­nolo­gies include EDI, SAP PI/PO, and ABAP code using exist­ing IDoc, BDoc, BAPI, and BADI capa­bil­i­ties. John­sonville does not use third-par­ty inte­gra­tion tools.

For­tu­nate­ly, the num­ber of inte­grat­ed third-par­ty appli­ca­tions and ser­vice providers we use at John­sonville is rel­a­tive­ly low. Third-par­ty appli­ca­tions (on-premise and SaaS) include trans­porta­tion man­age­ment, time and atten­dance, Man­u­fac­tur­ing Exe­cu­tion Sys­tem (MES), claims and deduc­tions pro­cess­ing, and main­te­nance plan­ning. Our most preva­lent inter­face is EDI, which we rely on to inte­grate our 3PL net­work, cus­tomers, ben­e­fits providers, and select suppliers.

Iden­ti­fy­ing the User IDs

The next step in the process was to iden­ti­fy all the poten­tial user IDs that were embed­ded in these inter­faces. Some of these were very easy to iden­ti­fy, like batch EDI. Much of our EDI pro­cess­ing occurs with two ​“EDI BATCH” user IDs, so those were easy to iso­late. Get­ting a list of all non-dia­log users from our secu­ri­ty team was straight­for­ward and pro­vid­ed all of the IDs that were poten­tial­ly embed­ded in batch inte­gra­tion jobs.

From there, the process got a bit more inter­est­ing. Some of our inter­faces are fore­ground jobs exe­cut­ed with a named user, and oth­ers use a system/​technical user ID that is con­fig­ured as a dia­log user. We were not smart enough on the first cou­ple pass­es of the esti­ma­tor tool to iden­ti­fy these users — it required us to ana­lyze the results and iden­ti­fy miss­ing doc­u­ment counts that we knew should be there. (More on that later…)

Run­ning the SAP Dig­i­tal Access Esti­ma­tor Tool

The first step here is to down­load the appro­pri­ate notes from SAP. There are two notes avail­able that pro­vide the doc­u­ment esti­ma­tion tools: one for SAP ECC sys­tems and one for SAP S/4HANA.

At John­sonville, we have two ERP land­scapes — SAP ECC and SAP S/4HANA. The SAP ECC land­scape is lim­it­ed to our HCM imple­men­ta­tion, while the SAP S/4HANA land­scape is our core ERP system.

Accord­ing to our BASIS team, down­load­ing and apply­ing these notes is a sim­ple process that takes just a few min­utes. Run­ning the esti­ma­tor tool is straight­for­ward as well. Sim­ply pro­vide a date range, the user IDs you are inter­est­ed in, and select whether you want detailed (Dis­play Tech­ni­cal Users check box) or sum­ma­rized results. With­in our 1 TB sys­tem, the reports gen­er­ate in under a minute. If you select the Dis­play Tech­ni­cal Users option, you will see doc­u­ment counts by user for each of the doc­u­ment items. The sum­ma­rized ver­sion sim­ply reports total doc­u­ment counts by doc­u­ment item.

In the report exam­ple below, we chose the Dis­play Tech­ni­cal Users option. This pro­vides a col­umn with doc­u­ment counts for each user includ­ed in the report.

Eval­u­at­ing Johnsonville’s Dig­i­tal Access Results

Based on our ini­tial analy­sis and our cur­rent inte­gra­tions, we believe we have three areas of con­cern that need fur­ther inves­ti­ga­tion and clarification.

Area 1: Time and Atten­dance Inte­gra­tion with ECC HCM

The first is our inte­gra­tion between our time and atten­dance sys­tem and our ECC HCM envi­ron­ment. Today, we use a third-par­ty sys­tem for the col­lec­tion of time and atten­dance records for our hourly mem­bers. This infor­ma­tion is uploaded to the Cross-Appli­ca­tion Time Sheet (CATS) solu­tion via a fore­ground job sub­mit­ted by a named user (dia­log user). A stan­dard CATS trans­ac­tion is then used to trans­fer data to the HCM info­types for our nor­mal pay­roll pro­cess­ing. In our ini­tial runs of the esti­ma­tor tool, we exclud­ed all named dia­log users. As a result, we were miss­ing the doc­u­ments cre­at­ed by the upload from the time and atten­dance sys­tem to CATS. As we dug into the inter­face (devel­oped in 2004), we dis­cov­ered that it was a fore­ground job using the named dia­log user. When we includ­ed all the named users that process time and atten­dance data in the list of tech­ni­cal user IDs, we were able to see the doc­u­ment counts on the report.

We have just start­ed explor­ing this par­tic­u­lar use case with SAP and have raised some inter­est­ing ques­tions that need clar­i­fi­ca­tion and answers. In the absence of any spe­cial licens­ing (Employ­ee Users, Nego­ti­at­ed Enti­tle­ments, etc.), the trans­fer of time and atten­dance records to HCM to enable pay­roll pro­cess­ing from a third-par­ty time and atten­dance solu­tion is con­sid­ered indi­rect access. Under the SAP Dig­i­tal Access mod­el, the answer about whether or not the trans­fer of time and atten­dance records is rel­e­vant (i.e., will be count­ed against your doc­u­ment count) depends on HOW and WHERE those records ulti­mate­ly end up in HCM. (More to come on this top­ic in my next blog post.)

Area 2: EDI for Integration

Our sec­ond area of con­cern is cen­tered around EDI and our use of EDI as the pri­ma­ry inte­gra­tion tech­nol­o­gy for our entire order to cash, logis­tics, ware­hous­ing, and trans­porta­tion process­es. In 2003, we licensed the Sales and Ser­vice Order Pro­cess­ing Engine (SSOP) to cov­er our use of EDI for these sce­nar­ios. (SSOP is licensed based on cus­tomer orders.) In our envi­ron­ment, we have SAP ware­hous­es con­fig­ured for each 3PL to track and man­age inven­to­ry. Ini­tial dis­cov­ery on this top­ic has raised a num­ber of con­cerns and ques­tions regard­ing enti­tle­ments grant­ed with our SSOP license and assump­tions we made regard­ing those enti­tle­ments. (SSOP enti­tle­ments vary for each SAP cus­tomer.) Specif­i­cal­ly, we have open ques­tions in the area of inven­to­ry man­age­ment with the 3PLs (inven­to­ry moves, adjust­ments, etc.). We believe that trans­ac­tions direct­ly relat­ed to the cus­tomer order are cov­ered (Order Cre­ation, Ship­ment Noti­fi­ca­tion, Invoice, etc.). It is all of the oth­er trans­ac­tions that sup­port order ful­fill­ment that are open for discussion.

Anoth­er area that war­rants fur­ther dis­cov­ery is our inte­gra­tion with our third-par­ty trans­porta­tion man­age­ment provider. In the trans­porta­tion man­age­ment case, all users have named user licens­es for SAP, so we should be com­pli­ant. As we eval­u­ate the doc­u­ment-based licens­ing mod­el, how­ev­er, we will have to under­stand where we will be essen­tial­ly pay­ing twice (named users and doc­u­ments). Ulti­mate­ly, those users do more than just inter­act with the trans­porta­tion man­age­ment sys­tem, so trad­ing in the named user licens­es to cov­er the cost of the doc­u­ments in the SAP Dig­i­tal Access mod­el is not an option. Trans­porta­tion man­age­ment is not the only area where this dou­ble dip­ping will be an issue — it will poten­tial­ly occur in our time and atten­dance use case, as well.

Area 3: Robot­ic Process Automa­tion (RPA) and Indi­rect Access

The last issue we need to address is a gray area in the indi­rect access/​SAP Dig­i­tal Access mod­el dis­cus­sion. That is the use of Robot­ic Process Automa­tion (RPA) and RPA-like tools that auto­mate the process of cre­at­ing and main­tain­ing doc­u­ments. These tools typ­i­cal­ly sit on top of SAP GUI or oth­er stan­dard SAP user inter­face tech­nolo­gies. My ques­tions here revolve around the SAP Pass­port tech­nol­o­gy. How will that tech­nol­o­gy dis­tin­guish between a hands-on-key­board user and a robot that is using the GUI technology? 

Here is a hypo­thet­i­cal sce­nario: If I con­vert my EDI inter­face from a back­ground job using a non-dia­log tech­ni­cal user to an RPA tool using a named dia­log user and con­vert to the SAP Dig­i­tal Access mod­el, do I need to license the doc­u­ments cre­at­ed by the RPA tool? I’m not say­ing John­sonville would do this, or if it is even prac­ti­cal or eth­i­cal, but it does help high­light the issue. The use of RPA and RPA-like tools to auto­mate the doc­u­ment cre­ation process will only grow. SAP has even bought and is  its own RPA tool–Con­tex­tor.

Where We’re Going from Here

As I put the fin­ish­ing touch­es on this blog post, I am on a flight to the SAP offices in New­town Square, Penn­syl­va­nia to begin con­ver­sa­tions with mem­bers of the SAP Glob­al License and Audit and Pric­ing team. ASUG will have much more to come on the top­ic of indi­rect access and the SAP Dig­i­tal Access mod­el as we con­tin­ue to engage SAP in this dis­cus­sion while John­sonville is in its dis­cov­ery phase.

Beyond get­ting clar­i­ty on our spe­cif­ic enti­tle­ments and cur­rent expo­sure to indi­rect access, oth­er ques­tions I will attempt to answer in the upcom­ing weeks include:

1. How do we address the dou­ble dip­ping issue? I am def­i­nite­ly look­ing for­ward to the upcom­ing nego­ti­a­tion cycle as we work to under­stand the total costs of con­vert­ing to dig­i­tal access.
2. What options do we have for our HCM inter­face besides a rewrite of the inter­face? For instance, giv­en the over­whelm­ing num­ber of hourly mem­bers in our plants and that we are ful­ly licensed for Man­u­fac­tur­ing Intel­li­gence, Inte­gra­tion, and Ana­lyt­ics (MII), can I use MII to gath­er time and atten­dance data and inter­face to CATS?
3. How does the new pass­port tech­nol­o­gy count inte­gra­tions with fore­ground jobs and named dia­log users?
4. What about RPA tools that essen­tial­ly cre­ate doc­u­ments through a dia­log user? Is it OK if I set up an RPA tool to cre­ate doc­u­ments because it is using a named dia­log user in a fore­ground job ver­sus a tech­ni­cal user ID (non-dia­log) in a batch mode (e.g., EDI)? Could I con­vert my EDI inter­face to an RPA-based tool and be con­sid­ered com­pli­ant under the SAP Dig­i­tal Access license mod­el? Can the pass­port tech­nol­o­gy dis­tin­guish between a bot and a hands-on-key­board user? If not today, what about in the future? Will I now have a new com­pli­ance issue if the tech­nol­o­gy becomes avail­able to dis­tin­guish an RPA bot from an actu­al human?

Look­ing for­ward to recap­ping the learn­ings from my meet­ings with SAP in the next blog post. Hang in there as we con­tin­ue mov­ing through this process.

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.