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 SAP’s 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 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 my third post, I recapped 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.

In this install­ment, I will try to bring clo­sure to a num­ber of open ques­tions and issues out­lined at the end of the pre­vi­ous blog, which include:

• 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 to SAP Dig­i­tal Access
• Find­ing an equi­table res­o­lu­tion to our time and atten­dance inter­face with ECC human cap­i­tal man­age­ment (HCM)
• Get­ting a defin­i­tive answer on robot­ic process automa­tion (RPA) and dia­log user-based interfaces
• Clar­i­fy­ing with SAP our under­stand­ing of enti­tle­ments includ­ed with SAP Man­u­fac­tur­ing Intel­li­gence and Inte­gra­tion (MII) for shop-floor integration
• 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
• Agree­ing on a ​“good enough” esti­mate of doc­u­ments to move for­ward with licens­ing and nego­ti­a­tions (sub­se­quent doc­u­ments, SAP to SAP, etc.)

Esti­mat­ing ​“Sub­se­quent” Documents

Unfor­tu­nate­ly, with­out hav­ing the SAP Pass­port tech­nol­o­gy imple­ment­ed across all SAP solu­tions in our land­scape, there is no defin­i­tive way of sep­a­rat­ing orig­i­nal or source doc­u­ments from sub­se­quent doc­u­ments. The SAP GLAC team first had to iden­ti­fy the busi­ness trans­ac­tions pass­ing through a par­tic­u­lar inter­face and then look at the ratio between ​“orig­i­nal” doc­u­ments and what would most like­ly be sub­se­quent documents.

For instance, we know that the EDI batch inter­face is pri­mar­i­ly used as an inter­face between our cus­tomers, third-par­ty logis­tics (3PL), and SAP. The ​“source” doc­u­ments being cre­at­ed are either sales order lines or mate­r­i­al doc­u­ments (post goods issue, adjust­ments, etc.). Finan­cial doc­u­ments are cre­at­ed with­in SAP S/4HANA as a result of, or sub­se­quent to, the cre­ation of the ini­tial mate­r­i­al doc­u­ment. It is the opin­ion of SAP that it is ​“rea­son­able” that inven­to­ry trans­ac­tions that cre­ate a mate­r­i­al doc­u­ment would cre­ate two finan­cial doc­u­ments. As you can see in the exam­ple below, in a num­ber of the inter­faces (i.e., RFC­SCALE), the ratio between mate­r­i­al doc­u­ments and finan­cial doc­u­ments is exact­ly 2‑to‑1. For Johnsonville’s EDI batch inter­faces, the ratio is approx­i­mate­ly 2.5‑to‑1.

Our ques­tion on this issue is whether or not there are trans­ac­tions com­ing through our EDI inter­face that are direct­ly gen­er­at­ing finan­cial doc­u­ments as the ​“orig­i­nal” doc­u­ment. Our approach here will be to mod­i­fy the query SAP is using for the finan­cial doc­u­ment counts to exclude any doc­u­ments that have a mate­r­i­al num­ber attached — the assump­tion (maybe bad) being that finan­cial doc­u­ments with­out an asso­ci­at­ed mate­r­i­al doc­u­ment would be orig­i­nal doc­u­ments cre­at­ed for pur­pos­es oth­er than inven­to­ry-relat­ed transactions.

As I have stat­ed in pre­vi­ous blogs, once you are com­fort­able with your ini­tial assess­ment and with engag­ing SAP, I would encour­age you to take advan­tage of the Dig­i­tal Access Eval­u­a­tion Ser­vice offered through the SAP GLAC team. In our case, the esti­ma­tion tool sub­stan­tial­ly over­es­ti­mat­ed the num­ber of required doc­u­ments. The GLAC team can assist in fine-tun­ing the doc­u­ment counts.

Resolv­ing Our Time and Atten­dance to HCM Issue

As I dis­cussed in an ear­li­er blog, John­sonville orig­i­nal­ly deployed an inter­face strat­e­gy in 2004 to pass time-and-atten­dance records from our third-par­ty sys­tem to HCM with cross-appli­ca­tion time sheet (CATS) tables as the ini­tial inter­face point rather than going direct­ly to the HCM infor­ma­tion types used for pay­roll pur­pos­es. Today, we gen­er­ate more than two mil­lion doc­u­ments a year using this inter­face. The approach we have tak­en is con­sid­ered rel­e­vant for Dig­i­tal Access by SAP. Yet if we mod­i­fy the inter­face to direct­ly update the appro­pri­ate HCM info­type (and bypass the CATS tables), we would be com­pli­ant with no Dig­i­tal Access requirements.

We will address this issue with SAP dur­ing our license nego­ti­a­tion, as the cost and effort involved in rewrit­ing this inter­face does not add any val­ue to our business.

Get­ting a Defin­i­tive Answer to RPA and RPA-Like Tools

In my last blog I shared the feed­back from SAP regard­ing RPA: SAP has reit­er­at­ed the fact that RPA con­sti­tutes use, and all use must be appro­pri­ate­ly licensed. More impor­tant to the con­ver­sa­tion, how­ev­er, is the posi­tion that a named user license that is also used for hands-on key­board activ­i­ty by a user does not con­sti­tute appro­pri­ate­ly licensed use. As I also dis­cussed, the fact that these tools typ­i­cal­ly use dia­log-based named users means the SAP Pass­port tech­nol­o­gy will not count these doc­u­ments. Unless you include the named dia­log users using RPA tools in the esti­ma­tion tool, you will not ​“see” the RPA-gen­er­at­ed doc­u­ments in the final report.

As of this writ­ing, SAP has not pub­lished clar­i­fi­ca­tion on how RPA use will be mea­sured or how RPA use should be licensed — either under lega­cy con­tracts or Dig­i­tal Access. This con­tin­ues to be a sig­nif­i­cant risk issue for John­sonville. We cur­rent­ly use RPA tools and have always felt we were com­pli­ant, as the RPA users were appro­pri­ate­ly licensed named users.

Enti­tle­ments Includ­ed with SAP Man­u­fac­tur­ing Intel­li­gence and Integration 

One of our open ques­tions to SAP was clar­i­fi­ca­tion of SAP MII as an inter­face between SAP and non-SAP solu­tions. SAP MII is mar­ket­ed and sold as a solu­tion to inter­face third-par­ty solu­tions, tech­nolo­gies, and data­bas­es in a man­u­fac­tur­ing envi­ron­ment with SAP ERP. Our SAP MII license is based on num­ber of employ­ees. We sim­ply need­ed to get clar­i­fi­ca­tion from SAP that all data that flows through SAP MII to/​from oth­er SAP solu­tions was con­sid­ered appro­pri­ate­ly licensed if we had appro­pri­ate­ly licensed the MII soft­ware. SAP has acknowl­edged that data orig­i­nat­ing in a facil­i­ty appro­pri­ate­ly licensed for SAP MII that ulti­mate­ly ends up in SAP ERP via MII transactions/​interfaces is not indi­rect access under lega­cy con­tracts. Addi­tion­al­ly, SAP MII to SAP ERP is con­sid­ered SAP Appli­ca­tion Access and is there­fore not rel­e­vant under Dig­i­tal Access.

Sales and Ser­vice Order License Swap

When John­sonville licensed SAP in 2003, we licensed the Sales and Ser­vice Order Pro­cess­ing (SSOP) engine. This engine cov­ers all indi­rect use asso­ci­at­ed with the order-to-cash pro­cess­ing of cus­tomer orders. We have received an ini­tial pro­pos­al to con­vert our SSOP enti­tle­ments as part of the Dig­i­tal Access licens­ing pro­pos­al from SAP and are cur­rent­ly eval­u­at­ing the trade-offs. To be clear, the con­ver­sion pro­gram offered under DAAP is the same con­ver­sion pro­gram SAP offers for oth­er license con­ver­sions — a net-to-net license fee con­ver­sion. At this point we are work­ing through an analy­sis based on enti­tle­ment con­ver­sion, not net price. What I need to under­stand is what I am giv­ing up in terms of enti­tle­ments to move to SAP Dig­i­tal Access. I will share our cal­cu­la­tion and com­par­i­son in the next blog.

Where Does John­sonville Go from Here?

At this point, I believe we have a good enough esti­mate of doc­u­ments to begin nego­ti­at­ing with SAP on a fair and equi­table tran­si­tion to the SAP Dig­i­tal Access mod­el. Before we can final­ize a deci­sion, we will need to come to an agree­ment on:

• A res­o­lu­tion to our HCM and time and atten­dance interface
• License swap val­ue for sales and ser­vice order processing
• A defin­i­tive answer on RPA

I do believe there are long-term ben­e­fits to mov­ing to the SAP Dig­i­tal Access mod­el if we can come to terms on an equi­table com­mer­cial agree­ment. There is still plen­ty of work to do to get com­fort­able with the long-term cost/​benefit and risk analysis.

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.