archive

Leverage Bank Account Management for Payment Signatories-Based Payment Approvals

by Chirag Chokshi, Senior Principal with the Enterprise Finance Group, Infosys Consulting

In today’s global and dynamic business environment, the treasury department often has to deal with the daunting task of managing and controlling large sets of bank accounts across diverse geographies. Some of the challenges include maintaining optimum bank structure, managing large portfolio of bank accounts and signatories, and maintaining a relationship with banks. Degree of automation as well as simplification of processes are essential to enhance efficiency of the organization in the fast-paced global business environment. SAP has revamped Cash & Liquidity Management functionality with the advent of SAP S/4HANA, aligning business processes to provide control to the actual owner of the processes. As a result, several settings which were traditionally configuration items in earlier SAP Releases i.e. SAP ERP became part of master data which are usually owned by business users. Payment approvals and signatories were managed through Bank Communication Management Release Strategy configuration in the classical SAP ERP Central Component (SAP ECC) system, while in SAP S/4HANA Bank Account Management (a submodule of Cash & Liquidity module), managing payment signatories and maximum payment amount is part of House Bank Account master data. This resulted in increased efficiency of payment approval process. This article explains the requisite configuration and house bank account master data needed for the Bank Relationship Management signatory-based payment approval process.

SAP has introduced several enhancements and simplification in the new and revamped SAP S/4HANA Cash and Liquidity Management solution as listed below.

  • Single Source of Truth: SAP has simplified data footprint in several modules such as Universal Journal containing general ledger as well as various subledger data in one table (ACDOCA) and One Exposure from Operations containing Cash and Liquidity Management related data in one table (FQM_FLOW). This helps provide real-time analytics and reporting from transaction SAP S/4HANA ERP system.
  • Simplification & Enhancement of Business Processes: Traditionally, in classic SAP ECC, some of the business-relevant setup was an SAP configuration activity. Due to this, such system setup was done by IT departments at the request of business users instead of by business users themselves. With SAP S/4HANA, activities or system setup relevant for business is driven by master data instead of system configuration, helping to enhance efficiency of the business operations/processes.

Bank Account Management (BAM) is the totally new function of SAP S/4HANA Cash & Liquidity Management through which SAP offers capability to create bank accounts as a master data to manage throughout their lifecycle such as open, close, modify, or reopening of bank accounts. Please refer to article How to Use Workflow to Streamline and Control Bank Account Management Processes in SAP S/4HANA Finance for more information. SAP also added new tabs/fields on the house bank account master data. Payment Signatories and Cash Pool tabs helped SAP to simplify and enhance Payment Approval and Cash Concentration Processes respectively.

Note: SAP S/4HANA Bank Account Management module is also referred as Bank Relationship Management. However, we will use the term Bank Account Management (BAM) in this article as SAP uses both names for this module. We will see “Bank Account Management” in the IMG menu path of SAP S/4HANA.

This article consists of step-by-step configuration required for BAM Payment Approval Process, “Payment Signatory” tab of House Bank Account master data, and sample payment approval process debriefing signatory-based payment approval.

Prerequisites

As SAP S/4HANA Cash & Liquidity Management requires additional license, SAP Offers “Full Scope” with full-blown function with license and “basic scope” to allow classic SAP ECC functionality such as maintaining house bank/bank accounts. This process requires “Full Scope” of SAP S/4HANA Cash & Liquidity Management. For activating “Full Scope”, the following settings are required.

  • Activate Business Function FIN_FSCM_CLM through transaction SFW5. Figure 1 displays that FIN_FSM_CLM is activated (Status tab; Bulb is lit).

Figure 1: Activate Business Function FIN_FSCM_CLM

  • In SAP S/4HANA IMG (Configuration) for Cash & Liquidity Management, select option “Full Scope”. Menu Path: Finance Supply Chain Management -> Cash and Liquidity Management -> General Settings -> Define Basic Settings. This configuration can also be accessed through SM30 transaction, specify table/view FCLM_CONFIG2.

Figure 2: Select Full Scope in Cash and Liquidity Management Configuration

 

Step-by-Step Configuration

 

Once the Full Scope for Cash & Liquidity Management is configured, the next step is configuration of Bank Account Management (BAM) and Bank Communication Management (BCM). Prior to the BAM Payment Signatory function being introduced by SAP, BCM release strategy configuration was used for payment approval process. BCM release functionality is still available, but using Bank Account Management signatory-based payment approval helps to transform control to the business users. Before explaining master data setup of the House Bank, I will explain the configuration required to enable BAM Payment Signatory based payment approval process.

Step 1: Define Settings for Bank Account Master Data

 

Configuration of Settings for Bank Account Master Data is required to support Payment Approval Process, define Sensitive Fields for the House Bank Account Master Data, and Define import methods for bank statements. This article explains the configuration settings required for the payment approval process.

IMG Menu Path for configuration of Bank Account Master Data Settings: Finance Supply Chain Management -> Cash and Liquidity Management -> Bank Account Management -> Basic Settings -> Define Settings for Bank Account Master Data

  1. Account Type Definition: Account Types represent the type of Bank Accounts i.e. Checking Account, Savings Account, Disbursement Accounts, Lockbox, etc. Account Types are primarily useful for two purposes: 1) As a filter or selection criteria for reporting, 2) Assigning payment approval pattern to account types. SAP has pre-delivered account types, and additional account types can be configured per specific requirements. Figure 3 below depicts the Account Type Configuration.

Figure 3: Account Type Configuration

 

  1. Define Signatory Groups: Signatory Groups and Payment Approval patterns would help specify the payment signatories in the House Bank Account master data. SAP offers one-step payment approval or multi-step payment approvals. Multi-step payment approvals can be sequential or non-sequential. Figure 4 shows the Signatory Group configuration.

Figure 4: Signatory Group Configuration

 

  1. Define Approval Patterns: Payment Approval Patterns define the rules of the payments, i.e. approval would be sequential or non-sequential, sequential approval would be single-step or multi-step approval, assignment of signatory group to the approval step of approval pattern. Additionally, minimum approval amount and currency can also be configured, but I recommend specifying a minimum approval amount in the house bank master data. Figure 5 shows the configuration of payment approval patterns P001- two-step payment approval, P002- one-step payment approval, and S001- non-sequential approval. Signatory Groups are assigned to approval steps of P001 and P002, respectively. As S001 is a non-sequential approval pattern, signatory groups are assigned through “Maintain Non-Sequential Approval Patten.” Figure 6 shows assignment of the signatory group to S001.

 

Figure 5: Payment Approval Patterns

Figure 6: Signatory Group Assignment to a Non-Sequential Pattern

  1. Assign Approval Patterns with a combination of Company Code/Account Types: Assignment of the approval pattern with combination of company code and account type drives which signatory group(s) would approve payments made from specific house bank account. Figure 7 shows the configuration of assignment of approval patterns. Multiple approval patterns can be assigned to Company Code/Account Type. Priority sequence would decide which approval pattern would be applicable first for payment approval.

Figure 7: Assignment of Approval Patterns

Step 2: Enable Signatory Control

This configuration step would enable the users defined as signatories in the House Bank Account master data to approve or reject the payments. Signatories information in the House Bank Account master data does not take effect without this configuration.

IMG Menu Path for configuration of Bank Account Master Data Settings: Finance Supply Chain Management -> Cash and Liquidity Management -> Bank Account Management -> Enable Signatory Control

Figure 8 Enable Signatory Control Configuration

Figure 8 shows the configuration of Enable Signatory Control. For the BAM Payment Signatory approval process, the following configuration (circled in the figure) should exist:

  • Process 0BANK002, Function Module FCLM_BAM_BCM_AGT_PRESEL, Product BAM
  • Process 0BANK004, Function Module FCLM_BAM_BCM_REL_PROC_CTRL, Product BAM

The following Configuration in the Bank Communication Management is required for enabling BAM Signatory Control:

  • Rules Maintenance
  • Additional Criterions for Payment Grouping

Step 3: Bank Communication Management Configuration – Rules Maintenance

 

Payment Grouping configuration contains rules for merging different payment documents to create a batch of payment documents which would be sent to banks for making payments. Payment grouping configuration contains the rules that generate payment batches and priorities in case multiple rules satisfy the criteria. Figure 9 displays the configuration of payment grouping rules and associated priorities. Rule “CC1710_11” has priority over “FIDO” and other rules as the value of Priority for “CC1710_11” is 0 which is lower than other rules.

IMG Menupath: Financial Supply Chain Management -> Bank Communication Management -> Payment Grouping -> Rules Maintenance

Figure 9: Bank Communication Management Payment Grouping Rules Configuration

Double clicking on “RI. Maint” opens up the rules maintained for payment grouping. Figure 10 displays the Rules maintained for Rule ID “CC1710_11”. This rule generates the payment batch for the payment documents posted for company codes 1710 and 1711.

Figure 10: Payment Grouping Rules for Rule ID CC1710_11

Step 4: Configuration of Additional Criterions for Payment Grouping

 

This configuration allows two additional criterions for creating a batch for the payment group. As Bank Account Management payment signatories are specified in the House Bank Account, it may be possible that different House Bank Accounts for given company codes may have different signatories. So, one of the requirements is to have first criterion for additional grouping, which should be the House Bank ID (Field Name: HKTID). Figure 11 displays the additional criterions for payment grouping.

IMG Menupath: Financial Supply Chain Management -> Bank Communication Management -> Payment Grouping -> Additional Criterions for Payment Grouping

Figure 11: Additional Criteria for Payment Grouping

Now I will explain how Rule CC1710_11 rule groups payment to create batches.

  • As the Rule ID configuration contains paying company codes 1710 and 1711, payment documents for those two company codes are selected.
  • As a next criteria, HKTID (House Bank Account) is grouping field 1 I and VALUT (Value Date) is grouping field 2, payment documents of those two company codes are first grouped by House Bank ID and then by value date of payment documents.
  • Each batch is created by company code, house bank account, and value date.

This configuration would help to create batches by the house bank account and hence, the batch would go right to the approving user(s) specified in the House Bank Master data. Assignment of Approvers to the House Bank Account is specified in the next section on House Bank Master Data. Please note that Grouping Field 1 of Additional Grouping Criteria must be HKTID.

Once the above configuration is maintained, the next step is maintaining the House Bank Master data. SAP S/4HANA Cash & Liquidity Management is an SAP Fiori application-based solution. The next section displays “Payment Signatories” tab of the Manage House Bank Account application.

 

Process Flow of Payment Approval by Signatory Assigned in House Bank Master Data

 

Once the requisite Bank Account Management (BAM) and Bank Communication Management are configured as explained in the Step-by-Step section, Payment Approval can be done using the BAM Payment Signatory. In this section, I will explain House Bank Master data as well as the  Payment Approval process using Cash & Liquidity Management FIORI APP.

Step 1: Assign Payment Signatories to the House Bank Account Master Data –  “Manage Bank Account” APP – Payment Signatories tab

 

Figure 12 shows FIORI APP – Manage Bank Accounts which is used to create the House Bank with SAP S/4HANA Cash & Liquidity Management. This figure also displays the “Payment Signatories” tab of the House Bank Account. In this tab, Signatory Group G001 (configuration explained in Step 1b to Step 1d) is assigned to User ID “MANAGER2,” and that ID can approve maximum USD 1,000.  This is a one-time setup of a master data. This is a significant improvement from SAP ECC, where this setup was done through Release Strategy configuration in Bank Communication Management module. Now, as it is part of the House Bank Account master data, a business user can make changes without the involvement of IT, which helps with increased flexibility and agility in the Payment Approval process.

 

 

 

 

Figure 12: Payment Signatories Assignment with House Bank Account

 

Step 2: Fund Transfer Request between Bank Accounts using “Make Bank Transfer” APP

 

Using Make Fund Transfer FIORI APP, I crated Payment Request for Fund Transfer USD 400 from Bank Account 12345678 (House Bank HBNK1/Account HCUR1) to Bank Account 87654321 (House Bank HBNK1/Account HSAV1). Figure 13 contains

 

Figure 13: Bank Transfer Request Initiation between House Bank Accounts using “Make Bank Transfer” APP

Clicking “Save” button created Payment Request 53 as shows in Figure 14.

Figure 14: Payment Request Creation

System prompts to create Payment document or not once the Payment request is created. Clicking “Pay” button creates payment document (Clearing Document # 2000100008), Payment Run id 00003R. Figure 15 depicts the payment document creation as stated above.

Figure 15: Payment Document Creation for the Funds Transfer between two bank accounts

Step 3: Review Status of Payment through “Track Bank Transfers” APP

 

FIORI APP “Track Bank Transfers” displays status of Payments posted in the system. In figure 16, header of Track Bank Transfer displays that 4 payments are in “New” status and 4 payments are “Approved” status. Clicking on “New” button displays all the payments in “New” status. Figure 16 displays payments with “New” status. Payment made in previous step through Run id 00003R for USD 400 appears in second line of the report displayed. System assign status “New” once payment is created and it goes to Approver (MANAGER2 for House Bank Account) for approval.

 

Figure 16: Payments with “New” Status – “Track Bank Transfer” APP

 

Step 2: Approval of Fund Transfer by Manager2 through “Approve Bank Payments”

 

Payment Signatory assigned as an approver (MANAGER2 for this use case) logs on to SAP S/4HANA and open FIORI APP “Approve Bank Payments” for reviewing payment batches requiring approval. Figure 17 displays the FIORI TILE of “Approve Bank Payments” tab and Report generated once Payment Signatory double click on this FIORI TILE. This APP being one of the SMART FIORI APP displays “3” on TILE indicating that three payments are awaiting approval.

Report contains two tabs: “For Review” and “Reviewed”. Payment awaiting approval appear in “For Review” tab. Payment posted in step 2 for USD 400 appears in 3rd line of “Fore Review” tab. In the Right top, there is a button called “Submit Reviewed” tab which contains number of payments which are reviewed and can be approved in the parenthesis. At present, there are no payments reviewed by him and hence, count in parenthesis is 0 i.e. Submit Reviewed (0).

 

 

 

 

 

 

 

 

Figure 17: Approve Bank Payment FIORI TILE and REPORT

Double clicking on the payment line opens up the details of the Payment Batches (Figure 18) which contains buttons for action/decision for the payment batch i.e. Approve, Reject, Defer at the top right and payment details in tabs like Batch Details, Payments, Approval Flow, Attachments etc.

 

Figure 18: Payment Batch Details with Buttons for Approval Actions

Clicking “Approve” button opens Screen for Approval Note as in and once payment is approved, Payment Batch status changes from “For Review” to “Reviewed”. Figure 19 shows Approval Note screen and clicking OK approves the payment. Figure 20 displays that Submit Reviewed Batches button count increased to 1 from 0.

Figure 19: Approval Note and Confirmation of Approval of Payment

Figure 20: Payment Batch Status changed to “Reviewed” upon Payment Approval

As a final action of payment approval, Double clicking button “Submit Reviewed Batches” brings dialog box asking submitting reviewed batches as displayed in Figure 21. Clicking on Submit would make approved payment ready for sending instruction to bank for further disbursement.

 

Figure 21: Submit Reviewed Batches of Payment for Disbursement

 

 

 

 

 

 

 

STEP 5: Review Status of Payment through “‘Track Bank Transfers” APP after Approval

 

After Payment Signatory (MANAGER2) approved payment as explained in step 4, FIORI APP “Track Bank Transfer” displays payment under “Approved” status. Track Bank Transfer APP report in Step 2 had 4 payments in New Status and 4 payments in Approved Status. With approval of payment in Step 4, New status count decreased to 3 while Approve Status count increased to 5.

 

Figure 22:

In summary, Bank Account Management Payment Approval process offers following improvements.

  • Payment Signatory and Maximum Approval Amount is now part of House Bank Account Master Data which was earlier part of Bank Communication Management Release Strategy configuration. This shift allowed freedom to Treasury Managers to change signatories and amount reflecting cash positions/personnel with the department and help make this process more agile.
  • SAP S/4HANA Cash & Liquidity Management is a revamped solution and offers Smart FIORI APPs providing high level information on TILE itself (i.e. Number of Payments on “Approve Bank Payments”) with exhaustive details in the report generated. The process flow of the payment approval is explained with example of some available FIORI APPs like Make Bank Transfer, Approve Bank Payments and Track Bank Transfer.

 

 

 

MEET THE AUTHORS

Chirag Chokshi Senior Principal with the Enterprise Finance Group, Infosys Consulting
Read More

Chirag Chokshi is a Senior Principal with the Enterprise Finance group of Infosys Consulting. He is an SAP Solution Architect having 18 years of experience with a major focus on SAP Financials. He has played an instrumental role in the successful execution of various finance transformations and global rollout projects. He is a recognized SME for Record-to-Report (RTR) & Order-to-Cash (OTC) process areas as well as new S/4HANA capabilities such as Central Finance and S/4HANA Cash & Liquidity Management. You may contact him via email at chirag.chokshi@infosys.com.



Digital transformation with SAP – Omnichannel Inventory and Sourcing with SAP Customer Activity Repository (CAR)

Going live on your digital transformation journey, writes Rizing Principal Consultant Chris Veli, is only the first step in a larger journey. To maximize your SAP S/4HANA investment, you should add two key transformation functionalities that will help you vastly improve customer experiences while following through with cost-effective and timely deliveries: omnichannel inventory visibility, which is the ability to know when and where your stock is in near real-time across your organizational channels, and sourcing, which is the method of how customer online orders are filled. How can you leverage these two add-ons to better achieve your business objectives while keeping customers engaged?
Using real-world examples, this article will empower organizations to leverage SAP Customer Activity Repository (CAR) in order to:
• Achieve omnichannel inventory visibility by implementing SAP CAR Point of Sale Data Transfer and Audit, empowering SAP S/4HANA to calculate near-real-time stock
• Ensure the lowest impact to web shops and back-end systems by supplying inventory and time series data
• Improve fulfillment of e-commerce sales by leveraging Omnichannel Article Availability (OAA) to ensure that only available inventory is presented to the customer and that all transactions undergo a final validation availability check
• Understand the components of sourcing, including data sources, filtering, sorting, and business objectives

This is available for Premium Member and Member (Complimentary) insiders.
Login or become an insider to read this content. Learn About Our Membership Levels


Video Q&A: Thomas Frenehard Discusses Top Risks of 2021 and Ways to Reduce Them

Right now, organizations are operating in a changed – and still evolving – risk landscape. In his focus on GRC and cybersecurity at SAP’s Global Centre of Excellence for Line of Business Finance and in his prior experience as Senior Director in SAP’s Governance, Risk, and Compliance Solution Management team, Thomas closely follows trends and issues in Risk Management with an additional focus in Internal Control & Compliance Management, Fraud Management, and Audit Management in order to stay armed with knowledge on what risks businesses face and how they can be reduced. In this brief interview, Thomas sits down with SAPinsider to share his findings on the many different risks that SAP and its customers have identified for 2021 – from economic to cyber threats to environmental – as well as tips on how they can be reduced. Thomas’ overview and advice will help viewers:

  • Understand both internal and external risks affecting organizations right now and in the coming future, and how they affect divisions and people in addition to bottom lines
  • Learn some strategies to help organizations mitigate risks, from monitoring situations with early-warning systems to educating all employees on the impacts to having response teams in place, and why such measures can be effective
  • Hear what steps some of SAP’s most innovative customers have taken toward having more control over risk, from automating risk-based auditing to providing access risk management directly into business applications, leveraging dynamic authorization methods, to using machine learning capabilities to detect threats and protect intellectual property

 



Video Q&A: Steve Biskie Shares Some Controls to Know for a Successful Implementation

During an SAP implementation, organizations might be underutilizing optional SAP controls that could provide extreme value to their SAP system and supporting processes. In this short interview, Steve Biskie, a principal in risk consulting at RSM, will explain how configurations and practices can address both missed and misunderstood controls; why it’s important to learn about controls people often overlook; how to make a case for changing these settings; and what SAP tools can be better used to help organizations become more efficient or to investigate potential breaches.

 

MEET THE AUTHORS

Steve Biskie RSM
Read More

Steve Biskie is a Director at RSM, where he leads the Center of Excellence for Risk Analytics & Automation and is one of RSM's SAP Champions. He has over 25 years of experience spanning all 3 Lines of Defense, and specializes in transforming inefficient and outdated processes and technologies to optimize GRC and audit performance. He has helped organizations from the middle-market to the Fortune 100 implement high-value, sustainable analytics and continuous monitoring programs. He has a passion for using technology to automate mundane, time-consuming tasks to allow organizations to re-focus attention on high-value, thoughtful, and data-informed analysis. Steve is a published author, an internationally-recognized speaker on risk and compliance-related topics, and a six-time IIA All-Star Speaker. He is the author of Surviving an SAP Audit, (SAP Press, 2010), and an expert reviewer for the book Security, Audit, and Control Features: SAP ERP (3rd & 4th Editions). Steve also teaches beginner through advanced SAP auditing courses through the MIS Training Institute, and has traveled to more than 14 countries to share his expertise.



Video Q&A: SAP's Neil Patrick Discusses Internal Audit in the Digital Age

Between adopting loud-based software while still having on-premise operations, automating as many processes as possible, using many types of artificial intelligence, and navigating decentralized and remote environments, it’s no wonder that what needs to be audited, and how it is audited, is changing for organizations. In this short video interview, Neil Patrick, Solution Manager for GRC and Security at SAP, provides an overview of the future and pressures for the internal audit function in the new digitalized era, of how some SAP customers’ internal audit function are innovating their approach and actively assisting their businesses, and how you can provide more visibility and demonstrate the vital value of your internal audit function.

 



Near-Perfect SAP Is Easier to Achieve than Good SAP Is: Part 2

In this Part 2 of his Lessons Learned series, SAP simplifier Kurt Goldsmith walks project managers through achieving Near-Perfect SAP projects. What does that mean? Whereas good = easier and great = hard in other contexts, Kurt’s decades of SAP experience have taught him that good = hard while great = easier when it comes to SAP. This how-to continuation focuses on the tactics that become possible with the five categories from Part 1 as a target, including a case study to help ground readers in the concepts. Read this article to understand:
• The two kinds of business requirements an SAP system can help with, and how
• The variations in ERP that those functionalities must individually allow vs. prevent and must collectively count and allocate

This is available for Premium Member insiders.
Login or become an insider to read this content. Learn About Our Membership Levels

MEET THE AUTHORS

Kurt Goldsmith SAP Solutions Director, Tata Consultancy Services
Read More

Kurt Goldsmith is an SAP Solutions Director for Tata Consultancy Services (TCS). 25 years, and 18 sites, Kurt specializes in clients with highly aggressive project needs in regards to functionality, timeline, or budget complexity. Relentlessly in pursuit of SAP simplification, he co-created in 2002 with Wellesley Information Services (WIS) a condensed format SAP Education concept that became the SAP Financials Expert monthly newsletter. An MBA graduate (University of Texas at Austin), Kurt in his spare time enjoys proving repetitively that it is impossible to win at wagering on thoroughbred horse races.  You can reach Kurt at Kurt.Goldsmith@tcs.com.



Near-Perfect SAP Is Easier to Achieve than Good SAP Is: Part 1

by Kurt Goldsmith, SAP Solutions Director, Tata Consultancy Services

“Kurt!  This client can’t afford perfection!”

Sometimes this is also spoken as: “Let us not allow perfection to become the enemy of the good.”

My comment here is not that either statement is wrong.  Only that a wider perspective belongs.

This article is for Project Managers and sponsors that set out to “save” time and money by aiming at good SAP rather than at great SAP.  In one hour or less, I want to enable you to do three things.

Action Item # 1

Redefine your understanding of Great = Hard while Good = Easier.  Because an SAP Project might be the one exception on earth where Good = Hard while Great = Easier.  We can refer to it as Near-Perfect SAP.

Action Item # 2

Explain three key tactical differences when aiming for Good vs. Near-Perfect SAP achievement.

Action Item # 3

I would like you to be open-minded to the next person, group, or team who asks permission to aim their SAP Project at achieving Near-Perfect, while still supplying the extra time and money that they’d ordinarily ask for merely to accomplish Good.  (more time and money than they’ll need = fun!)

Introduction

I normally aim my How-To articles at a non-technical audience in small enough bites that the content can be appreciated in 15 minutes or less.  Today’s topic is bigger.  But, I want to respect your time.  I will therefore divide the guidance into two halves.

Part 1 focuses on defining my two classifications.  What criteria am I using when I distinguish “Good” from “Near-Perfect” SAP?

Part 2 identifies the three main reasons why … and I’m fully aware that what I’m about to write seems counterintuitive, if not outright impossible … Near-Perfect SAP is easier to achieve than Good SAP is.

Aiming for “SAP Perfection” does not mean aiming for flawless.  Nor does it mean aiming for Standard or Best Practices.  It only means accepting that SAP is finite.  With a degree of interchangeable pieces.  And, that it has to function as an ERP because, well, that’s what it is.

The software is better than ever.  The number of available SAP Functionality experts is the widest and highest it has ever been.  And, yet.  Compared to years past, Projects are slower?  Less predictable?  Yield less?  And, post-Cutover, our deployed scope invites future break-fix and enhancement requests that continuously add – not remove – complexity.  Maybe we should re-verify a couple of assumptions.  Maybe there are a small number of key misinterpretations of what is means to implement SAP, at all.  My opinion on that starts now.

Cutover Day:  The Ultimate Fact-Checker

The people on your Business and SAP teams are skilled, motivated, and optimistic.

If you have a project where in spite of that every single one of them holds their breath on Cutover Day, please read this section of my article twice!

Oh, we worked so hard.

  • We broke out into logical teams (Order-to-Cash, Procure-to-Pay, Accounting, etc.).
  • We really, really, really asked our business users what they want and need the software to do.
  • We built out the individual functionalities and unit tested.
  • We put everything into 1,000 discrete Word docs, PowerPoints, Excel sheets, and Visio diagrams.
  • We combined the individual functionalities into “Business Process” strings, and ran tests.
  • Unexpected test outcomes went into a trusted Defect Tracker with due dates and owner names.
  • We’re getting pretty close to Cutover now, so let’s have User Acceptance testing.
  • More unexpected outcomes.
  • More entries into the Defect Tracker.
  • Maybe some scope-shrink. Maybe some “Can you live with this until Phase 2” bargaining.
  • Maybe a proverbial 150-pounds of super-complex “Z” programming no one understands.
  • Finally! Made it!  Everybody agrees to Go-LIVE!

Well.  Okay.  Hold your breath.  See Figure 1.  On the left side of the yellow bar are our interpretations.  On the right side of the yellow bar is a sometimes-unfriendly fact-checker.  Seemingly more and more, even though our Projects take longer and longer, the gap between Cutover Day interpretations and reality is growing!  Not shrinking!  What if I told you that the reason for this paradox is that we are aiming for Good SAP rather than for Near-Perfect SAP, and that Near-Perfect SAP takes less time – is easier to do than Good SAP is.  Would you keep reading?

Figure 1:  Uh oh.  It’s Cutover Day!

 

Perfect, Near-Perfect, Good

Now that we have our mind on Cutover Day, it is quite easy to define what I mean by “Near-Perfect” vs. “Good” SAP.  I’m referring to how well we understood pre-Cutover how, when, and why the business users and the software were going to interact together post-Cutover.

While looking at Figure 2, below, let us imagine three possible post-Cutover outcomes.

  • Perfect: Our pre-Cutover interpretations matched reality 100%.
  • Near-Perfect: Not 100%, but no big misses.
  • Good: Possibly some big misses, including maybe some that are going to kind of remain baked into the delivered SAP design for a long time, but “it works.”  Nowhere near a crisis.

Figure 2:  Perfect, Near-Perfect, and Good Refer to How Prepared We Are for Cutover Day

It’s the “how, when, and why” part of my definition that I want to call your attention to.  We all know that if six months AFTER a cutover we could time-travel back to the project’s kickoff date BEFORE the cutover while retaining all of our post-Cutover knowledge, we’d be able to implement that exact same project with dramatically less time and effort.  And, even if no one cares about the time and effort – everyone surely cares that we’d implement much better business outcomes for our end-users, too!

We all know this.  Yet, there is resistance to aiming for it.  Which I fully understand.  There is an assumption that the software, itself, is so tremendous that it’s “not worth” all the extra effort to achieve my hypothetical “go to the future and then walk back in time” level of understanding about how, when, and why the business users and the software will interact post-Cutover.  This assumption is half-correct – yes, the software is tremendous.  But, the level of preparedness I’m referring to when compared to the alternative is not extra effort.  It’s less effort.  I refer to levels as Categories.  There are five.

 Category 1: Individual Functionality as a One-Off

In a different article (“Part 2”), I offer explanations for why the tactics behind a project that aims for Good vs. Near-Perfect differ, and why the tactics we need to use for Near-Perfect are – although it is counterintuitive – actually easier on your implementation team due to the unavoidable nature of an ERP software package than are the tactics we need to use for Good.

But, for now, for this article (“Part 1”), let us ignore the question of tactics.  Let us instead focus on Cutover Day.  On preparing for it.  On achieving a 100% match between our interpretations on how, when, and why the business users and the software are going to interact together post-Cutover.

Allow me to offer an opinion that there are 5 categories of interpretation.  What’s more important than the count, however, is the awareness that all 5 involve assumptions about variation.  This is not a software thing.  This is a business reality.  Information Technology cannot bring us into an alternate universe.  But, it can make the one we’re in easier to deal with … if … we ask the right questions.  If we develop at least some base level understanding of what the variation Cause and Effect relationships are.

As shown in Figure 3, the Category 1 variations are limited to data types.  They act as context for each in-scope SAP functionality as a one-off.  This means that if we want a functionality such as automated Sales Order Pricing, then we also need to know from the business users each variable and variable combination under which that one-off functionality is to behave at least in some small way uniquely.

Example: Is our Sales Order Pricing functioning as requested with each in-scope Sales Order Type?  Source?  Customer Type?  Product Type?  Wonderful.  How about with each in-scope combination of Order Type + Source + Customer Type + Product Type?

Figure 3:  The Context for Individual Functionality Scope are our Data Variations

 

Category 2: Individual Functionality in Combination

Our next progression of variation understanding is still limited to data types.  But, now the question becomes slightly more difficult.  Instead of looking at how our various in-scope combinations of Data Type variations interact with a single (“one-off”) SAP functionality, we now look at how those same combinations of variables impact a single outcome.  Such as the creation of one Sales Order.

In other words, if we are confident in each individual functionality within a sales order (Pricing and ATP and Credit Control and Shipping Point Determination and etc.), we then need to ask:  Do any of those react to an in-scope variable or an in-scope combination of variables in a way that brings a negative side-effect onto one or more of the other functionalities that comprise a single outcome?

Figure 4:  The Context for Combinations of Functionality Scope is one Outcome (e.g., one Sales Order)

We can now talk about the one really important take-away that I am trying to communicate with my Two-Part article.  It is the key to your success with an ERP software such as SAP’s ECC and S/4 packages.  It is so important that I’m going to give it its own paragraph!

The act of proving that your in-scope functionality achieves Category 1’s expected responses to in-scope variation does not prove that it achieves Category 2’s.  Etc, et al. (2 does not prove 3’s, and 3 does not prove 4’s, and 4 does not prove 5’s).  Meanwhile, our potential benefits have the inverse relationship in that achieving 5’s expected responses is more valuable to your business users post-Cutover than achieving 4’s, and so on. Given this, what if I told you that when an SAP project manager or project sponsor aims at Good rather than at Near-Perfect, the bulk of your available SAP experts’ time and money will be spent on 1, 2, and 3!  And, almost none on 4 and 5.  Would you keep reading?

Category 3: Combination Outcome in Strings

As represented in Figure 5, as soon as we start to bundle a set of logically-related outcomes into a single iteration (i.e., a string), we now have to account for also a 2nd class of variation:  The Event.

  • Timing: Something occurred earlier or later than expected.
  • Volume: Something that occurred had higher or lower quantity than expected.
  • Content: What occurred arrived with unexpected format, type, or values.

The questions that the SAP implementation team needs answers from the business team on relate to a single instance of a single string.  For example, a single Procure-to-Pay iteration.

  • What kinds of timing, volume, and content variations are unavoidable?
  • How likely are they to occur, both individually and in combination?
  • What is the impact on other business users when these occur?
  • How, if at all, do those answers change depending on the DATA variations?

Uh, that’s only HALF the challenge, though.

Maybe the harder challenge faced by the SAP implementation team is shown in red font in the diagram.  It is an unavoidable reality of trying to connect diverse Job Roles via a single database.  ERP software is a double-edge sword, in that sense.  The tech features that bring the biggest benefit possibilities also introduce the biggest risk possibilities.  They are twins.  Inseparable.  Automated good … and bad!

  • How far in the String do our choices allow an unexpected DATA variation to propagate?
  • How far in the String do our choices allow an unexpected SINGLE EVENT variation to propagate?

Ugh!  The farther a variation can propagate, the more its potential for harm magnifies!

Figure 5:  The Context for Combinations of Outcome Scope is one String (e.g., one Procure-to-Pay)

Category 4: String Combinations at Volume

Time for a breather.  And, to think!  Some people believe that implementing an SAP system is easy!  I mean, all those functionalities are just sitting there in the base package, right?  Someone else already did all the programming!  The screens and the layouts and the database tables.  What the heck is the dang problem – just pick out the ones we need and go convert some data!  Offer some end-user training!  And, then, go “LIVE”.

Well.  I admit.  It would be nice if implementing SAP functionality for end-users in a way that helps more than it hurts was as easy as asking the chefs in a kitchen to produce winning outcomes based on how a set of diners articulated their preferences ordering food off of a restaurant menu.

Alas, most of the variables on a restaurant menu are short-lived in that if they occur at all (“Can I substitute asparagus for the French fries?”), the answer is Yes or No, and we’re done.  By comparison, most of the variables in an SAP system are ongoing in that once we make our choice that choice is now permanently exposed to other variables!  Some of which we can control.  And, some of which we cannot.  And, this brings us to Category 4.

As represented in Figure 6, although one iteration (one “String”) of a business process operates as a discreet set of fixed work steps, the collective usually does not.  On any given moment of any given work day, a business process such as Procure-to-Pay might have dozens, hundreds, or even thousands of iterations started but not completed.  If there are 10 discreet work stations in place to enable the A to Z of that business process, the workload can be distributed amongst those 10 in any number of ways.  Variation can accumulate in-between work steps at random.  In what ways do the business users want or need to interact with their SAP system in order to recover back to a Steady State status?

Figure 6:  The Context for one String at Volume are Bottlenecks (e.g., all in-flight Procure-to-Pay)

 

Category 5: Business Processes at Volume in Combination

Software such as SAP’s ECC and S/4 are referred to as ERP applications.  The “E” stands for Enterprise.  And, this brings us to Category 5.  As represented in Figure 7, the organization as a whole has to absorb quite a lot of variations.  Both DATA- and EVENT-related.

Figure 7:  The Context for Business Processes at Volume is an Ongoing Concern (i.e., the Enterprise)

I raised a point earlier that I will repeat here in a slightly different way.  Suppose that I could guarantee for you an SAP implementation where each in-scope functionality perfectly achieved in a “One-Off” manner the business users’ requests … but … did less well at achieving the “One Outcome” requirements?

I’m confident that you’d not be in favor of that result.  You’d not want me to aim for that.

The point of an ERP package is to allow the business users to achieve desired ENTERPRISE outcomes in spite of unavoidable variation between, among, in front of, and that (generally speaking) are impacting the individual parts of the enterprise.  But, if you are assuming that by giving your SAP team extremely clear specifications (sometimes called “Requirements”) about which individual functionalities are to be in-scope and on how the end-users are to interact with those individual functionalities, and that this AND THIS ALONE leads to what I’m depicting in Figure 7 as Enterprise net benefits, then I have a question.  If I told you that that assumption is invalid, would you keep reading?

Next Steps

In this first article (“Part 1”) of Near-Perfect SAP is Easier to Achieve than Good SAP is, I introduced a concept related to an SAP project’s Cutover Day.  In this concept, Cutover Day acts as a Fact Checker.  It tells us how well we interpreted pre-Cutover how, when, and why the business users and the software were going to interact together post-Cutover.

I then distinguished for you 5 levels, or Categories, of that kind of pre-Cutover interpretation.

The key point is that the Categories are somewhat independent.  Your requirements for what I presented in this article as Category 1 challenges do not fully “roll up” into the Category 2 challenges.  And, the requirements for the Category 2 challenges do not fully “roll up” into the Category 3 challenges.  Etc.  Each of the 5 Categories has its own challenges!

Among authors, there is an expression: “There is no such thing as good writing, only good editing.”

Among business software implementation practitioners, it would be quite fair to offer a similar expression: “There is no such thing as good software, only good specifications.”

Best Practices and Standard SAP only get us so far.  They help.  They are a great starting point.  They are unable to be, by themselves, the ending point.  If you want consistently predictable Category 4 (“Business Process Resource Management”) and 5 (“Enterprise”) benefits, then you have to give to your SAP implementation team Category 4 and 5 requirements.  You have to go beyond just Category 1, 2, and 3 requirements, plus the proverbial 150 pounds of hope.  Plus a due date.  Plus a budget.  Plus a Weekly Status Report.

If that is all you provide to your team, then your Category 4 and 5 outcomes are going to be somewhat random. The by-product (symptoms) from that randomness will sooner or later be reported after the Cutover as Category 1, 2, or 3 break-fix. The support team will “fix” the symptoms by adding unnecessary tech scope which, yes, makes the end-user happier but which also clutters the deployed scope and, therefore, harms the I.T. team’s ability to respond to future change requests. In short, your SAP system gets on a one-way ride to Gordian Knotsville.

“Come on, Kurt!  This client can’t afford perfection!”

What if I told you that Near-Perfect SAP was easier to achieve than Good SAP is? Less work. Less cost. Less uncertainty. Would you read Part 2 of this Lessons Learned series?

 

MEET THE AUTHORS

Kurt Goldsmith SAP Solutions Director, Tata Consultancy Services
Read More

Kurt Goldsmith is an SAP Solutions Director for Tata Consultancy Services (TCS). 25 years, and 18 sites, Kurt specializes in clients with highly aggressive project needs in regards to functionality, timeline, or budget complexity. Relentlessly in pursuit of SAP simplification, he co-created in 2002 with Wellesley Information Services (WIS) a condensed format SAP Education concept that became the SAP Financials Expert monthly newsletter. An MBA graduate (University of Texas at Austin), Kurt in his spare time enjoys proving repetitively that it is impossible to win at wagering on thoroughbred horse races.  You can reach Kurt at Kurt.Goldsmith@tcs.com.



Video Q&A: Brian Tremblay Discusses Compliance and Risk Strategies Everyone Should Know

by Annie Kennedy, SAPinsider

The increasing overlap of compliance, cybersecurity, and business continuity related to IT General Controls and regulatory & compliance matters such as Sarbanes Oxley (SOX) and the General Data Protection Regulation (GDPR) creates increasing challenges as well as opportunities.

Brian Tremblay, Compliance Practice Leader at Onapsis, sat with SAPinsider’s Annie Kennedy to discuss the importance of a holistic view toward compliance while sharing best practices for organizations to implement proactive, rather than reactive, compliance plans. Brian also shared how cyber is becoming more of a focus for internal control audits, especially those that support regulations like Sarbanes-Oxley, and how companies can best protect mission-critical assets within compliance strategies.

 



Q&A: How Protiviti's Identropy Acquisition Meets Growing Identity and Access Management Demands

by Annie Kennedy, SAPinsider

In the past year, a global shift to remote working and transformations to digital environments have amplified business’ need for more efficient and secure access governance. SAPinsider spoke with management and technology consulting firm Protiviti about how their recent acquisition of Identropy, which specializes in identity and access management (IAM), can help organizations address those concerns. In this interview, Protiviti Technology Consulting Managing Directors Aric Quinones, SAP Practice Lead; Terry Jost, Security and Privacy Segment Lead; and Victor Barris, Digital Identity Lead (and co-founder of Identropy) share with SAPinsider how Identropy’s integration into Protiviti is helping organizations enable their IAM and cybersecurity services.

Q: What led to Protiviti making this acquisition?

A: IAM has been a key component for satisfying business needs and requirements. Protiviti was already familiar with Identropy’s technology and architectural depth. We saw an immediate opportunity to build upon and be able to combine the companies’ intellectual property and talent and launch more robust services for clients. The acquisition also expands Protiviti’s ecosystem with major alliance partners in the identity world. Digital identity is no longer optional if you’re constructing large digital apps — identity is emerging as a domain in and of itself. At the same time, Identropy was seeing these same trends moving at an unprecedented rate due to identity being at the center of digital transformation initiatives. Identropy had been viewed as a mid-sized boutique and knew that scale would be a constraint, so they found the opportunity to join Protiviti a natural fit.

Q: How will Identropy’s identity and access management expertise help Protiviti better meet customer needs?

A: The pandemic redefined the future of work, and accelerating digital transformations are amplifying a need for systems that are not siloed. These factors, along with enterprise workflows recharting what industry ecosystems look like, were tremendous drivers for Protiviti to help clients understand the importance of identity and access management. It all started with questions about data: What can we do with someone’s data? Why is it there? What identity is associated with it? These questions drove Protiviti to start supplying smart technology for digital identity management and contributing to the construction and value of digital apps. If you think about how the past 9-12 months have created fragmentation, the complexity of security is magnified in a more virtual world going forward. It is more important than ever to manage identities quickly and efficiently, whether at the app layer, network layer, or database and operating system layers. Having the skills to help clients using any platform has become important to managing risk appropriately.

Q: Can you share your thoughts on current trends and issues in identity and access management? Why is IAM so challenging for organizations?

A: In the past, larger organizations like Oracle and IBM had solutions which required heavy lifting, with a great deal of complexity and customization contributing to long and costly projects. Over the years, a fleet of mid-sized companies came to the marketplace with more efficient frameworks and made it easier for solutions to be consumed, presenting an opportunity for specialized firms like ours to deliver with better ROIs. Now, due to the contemporary nature of implementations, there is again complexity. Technology has become robust and scales well, but it requires expertise to deploy it efficiently and address business enablement and regulatory requirements. There is a tremendous shortage of qualified talent to be found, hired, and retrained. Combined with an increase in demand for IAM, that skilled labor shortage is putting a stress point on organizations across most industry segments.  Companies are realizing that they must make access changes very quickly — such as when hiring thousands of workers for an online distribution center or changing wholesale distribution to another country — and businesses need to manage risk and compliance efficiently with appropriate identity management to manage larger volumes of onboarding and offboarding.

Q: What does this acquisition mean for SAP customers? What will they better be able to achieve as a result?

A: The SAP ecosystem is complex. In the past, people thought of SAP as an ERP company, but if you really understand it, it can be anything — it has business intelligence products, the SAP S/4HANA solution for central finance, SAP Analytics Cloud, and all of the functions of products like SAP Ariba, SAP SuccessFactors, and SAP Concur. Then you combine those large ecosystems with the complexities of a security role management framework to govern them, and you have a daunting conversation for customers. This acquisition allows us to work with clients using both SAP and non-SAP software to understand and streamline IAM processes, choose the best tools, consider management approval process, set up multiple tiers across an organization, automate offboarding if needed, create a greater user experience, and meet ever-changing regulation requirements. These things are all incredibly important in this COVID-19 world, and an influx of Identropy talent from this acquisition will increase Protiviti’s ability to meet those needs for clients.

Q: How does this acquisition complement and extend SAP offerings?

A: SAP’s access management products are varied, from SAP Access Control in the GRC suite and SAP Cloud Identity and Access Governance to manage end-to-end and SAP HANA security, as well as SAP Enterprise Threat Detection and solution extensions such as SAP Access Violation Management by Greenlight. Pre-built integrations for identity access governance and cloud identity and privileged access management can deliver an end-to-end service to any organization, whether they are seeking databases, cross-application operating systems, cloud versus on premise, or national or global regulatory compliance. The extension of SAP in the IAM space and the work we can offer in digital identity management is going to create interesting opportunities for mining data, specifically entitlement data. When you think of it, large banks could have literally billions of entitlements making up the population of identities for all of their constituents accessing financial data. SAP will probably always be the workhorse managing the internal operations of an arm of an organization, but we have questions on the front end to ask about identity, considering how many households now have products like Alexa or Echo. Should a refrigerator have an identity? A car? What if they had multiple identities? These home and consumer devices represent a fraction of the various units within plants and offices that businesses are working with. We have incredible data management resources with tools like SAP HANA, and after acquiring Identropy’s expertise, we are well positioned to answer a lot of these questions and help companies manage security going forward.