Introduction
When I first encountered SAP Best Practices on an SAP implementation, I was surprised that there was a documented version of what I had been doing for years; based on my initial SAP Academy training in 2000.
SAP has not only written documentation on Best Practices in lines of business, industries, technologies as well as things like migration and integration, but also provides process maps and other tools. See link https://rapid.sap.com/bp/# to access the Best Practices Explorer for both SAP ERP and S/4HANA solutions.
Over the years I noticed that many problems would not have occurred had Best Practices been followed. This article is article is about why an optimization project might be necessary, how to go about it and how Best Practices will help companies with an eventual move to S/4HANA.
Why Optimization is Needed
There are many reasons for changing an SAP setup, particularly where companies have implemented SAP many years ago. The business model may have changed or companies want to take advantage of new functionality such as the New General Ledger (New GL) or, more recently S/4HANA. Perhaps the company has made a number of acquisitions which don’t fit their original system design but were bolted onto the original configuration anyway, or the company has evolved in a different direction and their original SAP blueprint is no longer appropriate in the current climate.
Companies in a Group may have their own processes, chart of accounts and master data, making it impossible to run global reports in the one system, necessitating additional tools to consolidate reporting. Real-time data is critical with increased pressure to close periods quicker, so overnight transfers to BW are not ideal and InfoCubes and interfaces need updating with any report changes.
SAP may not have been well implemented, programmers writing too many bespoke routines, creating Z tables, Z transactions, user exits, etc. which could now be replaced with standard functionality. You may have to debug programs to make minor changes because documentation is unavailable or not updated.
Implementation partners may have been pressured into copying existing processes onto SAP, without benefiting from the experience and best practices of others in the same industry. If expansion has been by acquisition there may be inconsistencies and duplication between the different businesses, perhaps a lot of old coding has been kept only because of historical data and needs a good clean up. There may be a requirement for better master data governance.
The below diagram was taken from a 2015 KPMG study called SAP Value: A Balancing Act
Review
The optimization project may have been prompted by Corporate Strategy, expansion, cost reduction moving to the Cloud, etc. or support issues. SAP Business Suite is supported until 2025, but Oracle database licenses may have a shorter timeline. Either way the first step is probably the review.
The review may be carried out by external resources in order to present a business case for the final work, or you may have the skills internally to determine areas of improvement, what the issues are, and whether they can be fixed in the existing system by changing a few processes, implementing support packages, amending a bit of configuration etc. or whether wider action is required.
Generally, this kind of work will include documenting the As-Is processes, both to ensure that you do not miss any business-critical processes and to highlight areas which can be improved and where processes have deviated from Best Practices and are no longer efficient.
Business Case
Clarifying that the system is messy and inefficient is not going to get you funding for any major change, simply arguments against spending money for no apparent outcome. You (or your external partners), will need to come up with financial figures to detail and justify the outlay, as well as advantages such as improved morale, increased productivity, higher profitability, better and consistent reporting and analysis, transparency across the group, quicker closing etc.
In a recent Panaya crowd wisdom survey, it was reported that while the majority of enterprises have S/4HANA in their near future strategy, most have no idea on why or how to get there! Over 51% of organizations have already committed to the move to S/4HANA, yet 69% of these companies still lack a business case and a good reason for migration.
S/4HANA is coming, so it makes sense to prepare the way if you cannot implement it immediately, by already setting up Best Practices, and if you do change system ensuring that it is HANA compatible, preferably with a HANA database so you can benefit from faster processing.
Best Practices means that you will be working more efficiently with fewer resources. By having better control and access to data you are in a better position to make faster and more accurate decisions, improve profitability and competitiveness, reduce costs and improve cash flow.
In Finance and Procurement, there are many areas to quantify savings, for example, using self-service catalogues, automating the purchase order approval process, using only approved vendors to negotiate better discounts, receiving and sending invoices electronically or flipping PO’s (allowing a supplier to convert a PO into an invoice and transmit that invoice to the customer that placed the PO). You will no longer waste time and resources chasing paperwork or signatures etc. and using electronic documents reduces storage costs.
In Cash Management, having the system download statements from the bank, import them and match payments to customer accounts automatically, means resource can be directed at exception reporting and will ensure tighter credit control and improve cash flow. Bank fees can be reduced if you use In-House Cash to drive inter-company and foreign currency payments through virtual accounts instead of paying fees at the banks, electronical approval and automating the sending of encrypted payments to the bank reduces errors.
In Sales and inventory, better profitability analysis and reporting will help target the right customer, prevent stock outages, improve production etc. Perhaps you can use mobile devices and the Fiori user experience to encourage use of SAP and cut back on training
You should be able to come up with a number of KPI’s to show how things could be improved against industry averages for example. for invoice turnaround, credit note processing, stock turnaround, stock write-offs, DSO (days sales outstanding) etc.
From the review, you should have some idea of how major the necessary changes will be. Ultimately there are three routes you can take, the first two apply regardless of whether you decide to move to the New General Ledger or S/4HANA or just adopt Best practices for a smoother move later.
Which Route?
Your option swill depend on the type of changes you want to make, when you want to make them and if you optimize everything in one go, or take a phased approach. It may depend on cash flow, and both internal and external resources; you can’t have your finance team in workshops, testing and training during period- or year-end closing, or downtime in the middle of the busiest season. Do you want to implement other cloud solutions such as Ariba, Concur and how will they fit?
The complexity and cleanliness of both transaction and master data may be another factor which points to one option over another. Whether you convert the master data or upload it, fields will require specific formats and mandatory fields must be filled. You don’t want to transfer across rubbish when you are making the effort to optimize.
Convert existing system
In an ideal world, the least disruptive and cheapest route, is making changes in your existing system, but you will need to keep certain settings and master data to be able to access historical data, so changing certain processes may be difficult or impossible. You may be able to set up new company codes or a new client, but some changes affect all company codes, and client independent settings and bespoke programs may prevent a complete break from old processes.
New GL and New Asset Accounting are mandatory on S/4HANA, but introducing new parallel ledgers once migrated, is available since the S/4HANA 1610 on-premise version, with conversion to document splitting expected in 1709. If that is required functionality, depending on the timing (New GL migration can only be done at year-end), it may be better to set up an initial project for the New GL migration to be followed by conversion to S/4HANA later.
Depending on what functionality you choose to implement, migrating an existing system has little or no disruption to existing business processes and relatively little training is necessary. The disadvantage is that you may have to initially bring across some bad practices and not so clean master data along with your historical transactions.
If you want to move to S/4HANA straight away you can do so by converting the existing system but only if you intend to stay on premise. You may or may not need to move to different hardware first, but you will need to convert the database before you convert the Business Suite to S/4HANA.
Greenfield
A Greenfield Implementation (or reimplementation) on a new ECC or S/4HANA Best Practices system, means you can migrate individual or groups of companies at any period-end. The advantage is that a Best Practices Implementation allows you to use ready to run processes rather than re-invent the wheel. The disadvantage is that it is rare to be able to upload much historical data, mainly because of the complications of trying to map transactional data posted under old processes.
If you are a good fit for standardization, S/4HANA Cloud version (on a secure multi-tenanted public cloud) will probably be cheaper, more flexible and completely standard. Costs are operating rather than Capex, there is no initial outlay for the hardware and software and everything is maintained for you with mandatory quarterly upgrades. There is limited access to the configuration and bespoke programming is not allowed, and Fiori is mandatory (no SAP GUI option).
If, however, you cannot manage without a number of modifications and want to have your say when upgrades occur, or want to manage your own system, then on-premise may be better, where there are also various Cloud, non-Cloud and Hybrid options available.
Landscape Transformation
Long-term big-bang projects have a number of risks and more chance that the goal posts keep changing. The business or economic climate is not static and the planned version of software may be already out of date by the go live. Central Finance available with S/4HANA, allows a number of companies to continue with their existing system, whether it is ECC6 or a legacy system, but simultaneously post real-time into an S/4HANA finance system.
This is the quickest way to take advantage of the benefits of S/4HANA Finance without the upheaval of migrating a number of companies at the same time. The workload is mainly mapping which is carried out using the SAP SLT (System Landscape Tool). It even allows drilldown to some original documents, for example if you post a sales order to an ECC system, although only the financial posting is made to S/4HANA, you can nevertheless drilldown to the billing document and sales order in ECC from the S/4HANA system.
It allows you to migrate selectively, for example to go live on S/4HANA first with the companies or areas with the highest return on investment (ROI) and lowest total cost of implementation (TCI) using Central Finance for everything else, transferring the others in a phased approach later. However, bear in mind you will occur the costs of running two ERP deployments in the short-time.
Methodology
Once the initial business case has been approved, and you have your project team, change management and implementation partners ready to go, there is different methodology to approach the project.
Even if you decide on a Greenfield Implementation, there is a move towards smaller phased projects using accelerators, such as SAP’s Rapid Deployment Solutions to deliver value quickly. You may have heard of or used SAP ASAP Methodology, which was very much requirements driven and used for many implementations historically. It consisted of the five phases below.
Activate is the new more agile methodology, which replaces ASAP and has three pillars, Best Practices, Guided Configuration and Methodology. It works with on-premise, cloud and hybrid solutions. With ASAP, Businesses built a blueprint of what was required, and consultants would fit it to SAP; with Activate customers are guided to the Best Practice solution, leveraging preconfigured business content.
Stages of Activate
In the Discover phase, the business is given a model standard SAP system to try out and understand the functionality available. Prepare works out the implementation plan and resources. In Explore, the project team carry out fit-gap analysis and verify which model scenarios are in scope and whether they are a good fit for the business.
In Realize, the solution is built and incrementally tested based on the requirements Explore. Finally, in Deploy, the configuration is transported to production and for the go-live and support.
Content available as part of the Rapid Deployment solution includes process maps, configuration documentation, predefined test scripts, migration templates, integration information with other SAP Cloud solutions etc.
Below are some examples of Scope items in SAP S/4HANA Finance.
Some of the things that could have gone wrong
I have seen many things that could have been done better with hindsight. A great many are related to the original design not matching unexpected expansion, from a resource and hardware point of view down to the individual coding convention, where the quantity or range of codes required was misjudged or too few digits used.
To give an idea of what could have gone wrong and the consequences, I have listed some examples where Best Practices were not followed
Chart of accounts
Badly designed without proper controls. Accounts not in the appropriate range, to appear correctly in the financial statements
Not harmonized across companies
same account being used for different things (quicker than requesting new one) or duplicates being created because not clear what the existing accounts are for
companies put items in the chart of accounts which should in cost or profit centers or internal orders
sections of chart of accounts with an additional 2 digits are used for country requirements, e.g. account numbers beginning with country code 44 are for UK, 39 for Germany, 49 for France etc. (Parallel ledgers would be better)
Assets
Too many (200) asset classes and GL accounts used for reporting instead of evaluation groups
No default useful lives or policies, identical assets with different live preventing accurate depreciation simulation
One invoice per asset, even where invoice contained different items, causing problems when assets disposed and for inventories (normally you would have multiple quantities on one asset for low value items)
fair values uploaded to overwrite existing assets instead of using standard functionality and separate depreciation area in order to keep history
approval and budgeting process outside of SAP, so no automatic control over capex
use of WBS elements where no need for hierarchy (WBS designed for complicated installation projects such as buildings, large plant and machinery - internal orders for simpler purchases)
Master data
Suppliers and customer set up under different codes in different companies
Material master duplicated because coding unclear
No central accounting committee and policy guidelines, takes years to get agreement from all companies in the group
Revenue recognition
Manual postings, reversals and reposting to revenue and tax accounts, instead of using SAP standard functionality
Unorthodox organizational structure
Instead of using document splitting to report by profit center, /sites set up as company code (company code normal equal to legal entity)
resulting in enormous amount of unnecessary cross company postings
transfer postings at wrong values where one site manufactures on behalf of another
Tax procedure of one country was assigned to another to avoid extra configuration, causing reporting problems later
GR/IR account
Allows manual postings
Summarized by PO, difficult to reconcile and report
Posting accruals manually because purchasing process bypassed
Manual reclassifications not standard functionality
Liabilities over one year
Split Capex/Opex purchases
Debit/Credit balances
Manual reporting or manipulations in BW because of missing data
Weight and commodity code not held in Material master for Intrastat
VAT registrations numbers missing from customers and supplier master data so tax incorrectly calculated
Programmers required for small amendments to bank files and forms instead of using new payment medium workbench
Out-of-date functionality
Random OSS notes implemented instead of regular support packs
Amending standard codes instead of copying and renaming beginning with Z, risk of being overwritten during upgrades
Poor tax setup, too many codes
UK, Germany, France all have a plant in the Netherlands subject to Dutch tax. Instead of using the Dutch tax code, each company has its own code
Plants abroad functionality ignored
Poor control over testing and changes, requiring intervention of SAP to repair tables
Fiscal Year changed mid-year in productive system
Additional local currency removed mid-period – existing invoices could not be paid
Tips
Get the right project sponsors and change management to drive change top-down
Get agreement on group policies upfront, for example accounting policies such as credit control, fixed assets, payment terms
Don’t expect experienced employees to be able to keep up a full-time job and devote time to the project
Avoid Scope creep
Ensure Master Data clean or cleanse it - GIGO (garbage in garbage out).
Keep modifications to a minimum
And finally, don’t try to exactly match your current processes or try to bend SAP to fit, use Best Practices and improve your processes!