From customization to standardization in SAP, how to avoid falling again into traps from the past

The world of large ERP implementations where we were starting from a blank page and doing several months of blueprinting sessions are far gone. Organizations do not have that luxury and those types of budgets anymore. Now we need to focus on Rapid deployment, lean and standard processes.

How were we used to do SAP implementations in the past?

We used to do large implementation projects with 7, 8 or 10 Consultants for Finance, another similar number for Materials, Sales and so on. At the end all adding up close to 100 hundred SAP Consultants easily. And we were not implementing SAP at Walmart, just at a normal company …

We would do 4 to 6 months of Blueprint sessions where we would look into every single thing out there in a process and configure SAP accordingly and mimicking the legacy process into SAP configuration. We would configure even the smallest things that SAP allows us to configure (Ex. Optional or required fields on Finance Posting Keys, changeable fields on a posted Finance document, just to name a few of those ones out there, but the list could be big). All because we had the time and budget to do it and an “open bar” policy for these type of things. And these were the standard things that SAP configuration allowed us to do.

Then we would look into all sort of business requirements that were not standard SAP and we would do custom developments for them. Tons and tons of lines of Abap code for custom reports, custom Transactions, customize SAP standard delivered screens and even customize and append Standard SAP Tables because the business had a requirement.

(Before you jump, I would never, ever recommend customizing an SAP screen or appending a standard SAP table …)

This would lead to months of development and testing and re-testing, many times even all the way up to the cut-over weekend because some of those developments were complex and intricate. In some cases putting more than one go-live at risk ( … I am sure you can relate to some of these examples and you are now remembering some cases in your mind …)

Then after go-live, you would continue doing new developments over the subsequent years whenever the business would come up with a new requirement. Instead of analyzing the situation, trying to find solutions within standard SAP and adapt the process; NO we would develop something new. A new “Z” Transaction and new “Z” field and new Z something.

You end up after a couple of years of following this approach in a complete ZAP environment (SAP with Z), where you do not recognize the system anymore. Everything that the users do starts with a Z, transactional or reports, all would start with a Z.

Several years ago, I remember working for a customer; where it took me a while to adapt to their SAP system. You would click SAVE and a bunch of things were happening in the past that would change the complete behavior of the system. Screens that had extra fields that you would not recognize because there were not part of SAP standard. And the worst thing is that most of this was not documented anywhere because it was done many years ago and they did not have a lot of discipline. It was in someone’s head that luckily could still be around or not. This client had been in SAP for 15 years at the time. Coming easily from SAP versions 3 or 4. The amount of custom at this client was insane. (And it is still that way because they are still using their old ECC).

Another client, in complete different industry…. We went to do an assessment to implement S/4. They too have been using SAP for ages … We were analyzing their processes and we asked them to provide us the list of Z Tcodes and Z reports to analyze them and see which ones we could replace with standard SAP. They came up with more than 150 just for Finance, Materials and Sales. 150 custom developments are a lot. Someone would say, I have seen more than that. Oh yes, I have seen more than that too. But it is still a lot …

Some of these clients they have even customized and created their own entries in the IMG, with custom IMG options to maintain all these extra customizing that they have created over the years. Customized the IMG !!! A bit too much.

And I have a couple of other similar examples too of big companies but not as big as a Boeing or Walmart.

How much does it cost to maintain all of that? A lot !!

What is the impact of having all of these undocumented solutions?  It cannot be measured

Then you bring outside people (like me at one of these clients) and for someone that knows SAP, all of a sudden, he needs to learn it all again. That has a cost for organizations too that have to pay for that long ramp-up period.

These has other consequences too. All of these clients cannot do upgrades anymore because it would cost them a fortune; more than doing a brand new implementation. Some are still stuck in versions 4.6 or 4.7 that are way out of maintenance from SAP. This client even ended-up hiring a company from India that provides support for SAP environments that are out of maintenance. Like a generic aftermarket auto-parts manufacturer but for SAP solutions.

These customers cannot comply with new legal requirements delivered by SAP via OSS Notes and for sure they cannot benefit from new developments or new technologies as well.

Now, what can we / you do to change that? 

Not easy and definitively it takes time …

Over the years, SAP has run out of opportunities to sell new implementations to the Walmarts, Boeings, Airbus of the world (just to name a few). All the big guys and not so big too they were already in SAP. Those big ones are the ones who, “to some point”, they can still afford to have big implementations. But the others, no. So, they started looking some levels down in the pyramid to sell projects. But those companies did not have the same budgets and luxury that the big guys had. They needed to find a new approach for that market.

That is when we started seeing more and more implementations in the market using the Best Practices packages from SAP, with pre-delivered configuration for different scenarios, with pre-built configuration guides, process flows and testing scripts. All this pre-built material helped reduce the costs and accelerate the delivery. Many of the Consulting companies had picked up these documents, added their own logo, fonts, colors, added some of their own flavor and would sell them to customers as “accelerators”. Many are still doing it with every version.

We were starting from a good base, and we did not need to configure everything from the ground up.

But this was fixing some part, but we were still doing a lot of custom developments.

 

Some companies started seeing and putting all these variables together:

• high or impossible to upgrade costs,
• high maintenance costs of their own customization developments and
• lack of standardization

In the meantime, SAP launched SAP Simple Finance which later turned into S/4 HANA with their In-Memory Database. Promoting digital Transformation, Machine Learning technologies and a completely new UI like Fiori that would simplify the user experience making it in line with the type of intuitive user interfaces that we have today in our cell phones.

They also replaced their ASAP Methodology by their new “SAP Activate Methodology”. This new methodology got away from the traditional waterfall approach and got closer to Agile but still with certain reminiscences from waterfall.

 

For these clients something needed to be done, they wanted to be able to adopt new technologies. They were in outdated platforms too at risk with the OS and their Databases too.

As I mentioned before, some of these clients were (and a lot still are); in systems that are way beyond salvation, there is no “brownfield” option for an upgrade … So a new “greenfield” implementation was the only way out for them. Complete re-design from scratch.

This was the tipping point for them.

So they said, “… Let’s do a “greenfield” implementation … but how can we avoid falling into the same traps and making the same mistakes we did 20 years ago?. The industry has changed and those big & gigantic SAP programs where everything could be customized cannot be executed anymore. There is no more money and time for all of that.

As I mentioned, SAP Activate is Agile with a flavor of waterfall (a mix of the best of both worlds).

Within the methodology, as key part of this Standard vs. Custom approach is in the “Fit to Standard Analysis”.

We stopped doing detailed Blueprint workshops and started to do “Fit to standard” workshops.

The business users would explore the SAP best practices and standard business processes such as order-to-cash, procure-to-pay or hire-to-retire that are mapped for S/4HANA

We would show them the standard SAP delivered processes, show the fit on the client processes or see where their processes could fit in regards to standard and then question and challenge the parts that were not a fit.

In plain words we would ask “… Mr. Customer, tell us why you cannot use this standard process to do “xyz” and you need to customize it. Please justify it … ”

 

Out of those “Fit to standard” exercises a list of gaps would emerge. There are 2 possible solutions for them Adopt or Adapt.

·       Adopt the SAP process and become standard.

·       Adapt but using SAP standard configuration and still remain standard.

These last 2 would have some process reengineering and change management to do.

OR …

·       Adapt the system and customize / develop a tailor-made solution.

A complete fit-gap exercise ensures greater visibility of the gaps that the standard S/4HANA is unable to offer. In such cases, a fit-gap strategy decides if a system’s enhancement, a customized application, or activating a business add-in will address the identified gaps.

This is where companies should make a shift on their approach.

These companies implemented rigorous revision processes before approving any custom developments.

They created “design review committees” where they would scrutinize each and every single development asking Why is it needed? How will it be done? And most importantly, What happens if we don’t do it? What is the monetary impact? What is the business impact if not done? Is there a standard workaround that could be used instead?

Custom developments like some of the ones that used to be done in the past by some reckless consultants that would modify standard SAP code, are completely out of question. Even putting enhancement spots.

Some are going even further these days and the moment they hear something starting with Z, they shut it down right away. I personally faced this to address a business requirement where we would use a series of standard function modules and BAPIs but all wrapped up in a Z program. I was not even allowed to present it to the committee.

This process needs to have rigorousity and needs to be unbiassed for at least 2 main reasons.

1.       Keep your project budget under control, otherwise you end up with an endless list of custom developments that put you at risk to meet your go-live date. AND

2.       Avoid over customizing your system beyond the point of no return, like I described earlier where some systems become ZAP (SAP with a Z) and you cannot upgrade them anymore unless you are willing to invest a fortune on it.

These “design review or design authority committees” are made of different technical and non-technical people such as Solution Architects, Development Team Lead, System Integrator executives, Integration Managers, some line of Business executives and other individuals with many years of experience too. Another member of this committee is SAP itself. Clients would hire SAP Max Attention services to be part of this decision making process of reviewing these developments to add another level of scrutiny and legitimacy.

In some cases, during an S/4 HANA assessment project we had SAP Max Attention within this committee early on when we were doing the proposal for a future project, and we had to justify every custom development in front of them for them to provide an opinion to the customer if the development was justified or not.

In other cases, Max Attention was an integral part of the project on an ongoing basis and was a permanent member of this committee.

The committee will act as the guardian of your solution, protecting you from yourself, protecting you from falling into the old habits of deviating from standard SAP solutions and overly customizing your system.

In many cases, this will get a lot of business people upset and feeling that they are losing functionalities and information. This is where you will have to work redesigning your process and in change management with your people.

But this strategy will pay off in the long run as you will stay within standard SAP, and allow yourself the possibility of doing upgrades and adopting new technologies as they are released by SAP.

S/4 HANA on-premise is a system that has been constantly evolving since its launch in 2015, every year there is a new release with new features and functionalities. Staying standard will allow you to adopt them faster and reduce maintenance costs too.

 

Remember:

You have a decision to make …

Do you want to address every single business requirement not matter if it requires doing custom development, making you spend a fortune, increasing your maintenance costs and putting you at a disadvantage for an SAP upgrade? This should be part of the past way of doing business.

OR

You prefer to reduce implementation costs, reduce your maintenance costs while staying standard, invest in change management and process reengineering and allow you to adopt new functionalities and technologies faster whenever they are released? This should be your future vision and approach. Today this should be a no brainer decision for all organizations.

If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.

www.dnabusinessconsulting.com

Understanding S/4 HANA Adobe Forms for Functional Consultants

SAP has used over the past (many) years different technologies and development languages to build outputs / printouts for different processes (Ex. PO printout, Customer Invoice and/or Check printing and many more too). Some of these technologies can still be used if you want, but now a days you have better, easier and a more robust technology that can be used. This is Adobe Lifecycle Forms in S/4 HANA or some call them Adobe forms.

In the past, we used to do many of these mentioned outputs with SAPScript technology. These was ok for that time, but it is a little bit of a tedious language and adjusting drawings and positions takes a lot of try & error and definitively not really user friendly. Also, if you needed extra information that was not part or accessible in the original SAP delivered form; you most likely needed to create a "custom print program" to be able to accommodate the extra info or logic needed. We all know by know what custom means in terms of future upgrades and maintenance costs ...

Then after SAPScript came Smartforms, which it was the 1st possibility of dealing and producing Adobe PDF type of outputs. I worked with it a bit, but unfortunately being a Finance consultant I still had to deal with SAPScript as Smartforms was not widely available or used in Finance. It was more available for modules like SD for their Customer Invoices and related outputs.

But today since the inception of S/4 HANA, SAP has introduced a newer, better and more user friendly technology called "Adobe Forms".

Before being able to use this technology, some technical pre-requisites need to be in place in your S/4 HANA environment which your Basis and infrastructure team will have to work on it first. For this to work, you will an ADS Server (Adobe Document Server) to be installed in your landscape. And this runs in JAVA, so you will need to install it in a JAVA based server. I know from the past that the PI/PO server was JAVA based, so a couple of clients were sharing it for both technologies. Once that is in place, then they will have to connect them and after that you will be able to start using it. If you try to use it without this being in place, you will get a lot of errors and you will not even be able to display a form nor create one.

It is funny that I have to highlight that, as one would think this should be standard out of the box for any S/4 implementation; but apparently it is not ... This year, I went into a client where another SI was kicked out for doing a terrible job, and among many of my findings were that these guys designed all the outputs by still using the old SAPScript technology and the ADS server was non-existent in the client landscape.

Note: Don't ask me more technical questions about the ADS server as I am just a Functional guy, not a Basis resource.

How do we use and deal with these forms in S/4 HANA ?

As we were used to before with SAP, they have delivered a series of standard forms for each of the available outputs for the different processes that we can always leverage to start from them and add / remove / modify them as we see fit as per client requirements. Like adding a logo, changing columns or adding extra information that is not standard delivered.

As usual and in proper development practices, you should "never" modify an SAP standard form. You should ALWAYS create a copy and work with your own custom form. 

To access these forms, you can use Tcode SFP and enter (or search) the form name that you want to work with.

In my example, I will be working with the Vendor Payment Advice form which is a typical form that we use in Finance for payments.

Then you go Display and you will start looking at the definition and design of the Form. 

Within the Context tab, you will see a lot of the Structures that the form deals with and their individual fields that are available for the form to be added in the output. 

Here you can browse through the different Structures and fields and can take note of any extra fields that you might want to include in your customized form to add it to you Functional Specification document so then your Abaper can add them.

From my example (Payment Advice), you can clearly identify these structures as being the ones that are also available when we execute payments or when we build or deal with DMEE's. So any field that you want from those structures can be added to your form. There are fields at the header level and line item as usual. Same for any other forms for any other processes.

If for example, I want to add to my form "Payee Bank account #" and "Payee Bank Name", I just need to provide those technical field names (ZBNKN and ZBNKA) to be added to the form. 

Another possibility that you have, is to go to the Properties Tab and double click in the Interface name (Ex. FI_FPAYM_DATA). These will bring you another screen where you can then display the Structures definitions that we were seeing in the prior step in a more technical way as if you were displaying them in SE12.

Or, you can copy the Interface name and paste it right when you call Tcode SFP in the Interface field and display it. (Same result).

After you double click in any of the Type Name's for the Import Form Interface, you will see that structure the same way as you would see it in SE12 with all its technical definition, data type, length and so on ... Very useful when you want to see how big is the information you will be adding / removing to/from your form.

Next ... If you want to take a look at a draft layout of the final output form, you need to go back to the beginning to the "Layout" tab.

Before you are able to display the form layout in a PDF like way, you need to install Adobe Lifecycle Designer in your computer. In your own PC, not in the SAP server. Without that, you will not be able to display the form here in SFP. You can download it from the SAP Marketplace and then install it. 

Then you will see in the center of your screen, a little bit of a PDF display that also contains some technical information about the fields mapping (see below).

When you move to the left pane and drill down in parts of that hierarchy, the part that you are clicking on will get highlighted in the form just beside it in the central part of your screen. 

Also, if you see the right bottom pane, you will be able to see the field "binding" (field that is assigned to) for that field too.

All of these information will help you navigate through the form for you to do your analysis on which fields you need to add or remove from your form and provide a better Functional Specification Document (FSD) with detailed information and not just screen fields like I have seen many Functional consultants doing in the past (and still today ...).

Once your Developer finishes doing the changes in the form, you will just need to update the configuration for the process to include the new form name and it will be ready to be called by the system

Finally ...

What if I need to add fields that are not part of the structures that are available already in the form ?

What if I need to add custom logics to derive those fields or read other tables from other modules (Ex. SD or MM) ? How can I do that ?

In the past, to achieve this we needed to end up doing a Z / Custom program. Take a copy of the standard program and modify it as I mentioned earlier on.

Today with Adobe forms, there is NO MORE NEED TO CREATE A CUSTOM PRINT PROGRAM. If you see someone (Abap or functional) trying to repeat those old habits from the past. STOP HIM right away !!! That person has not updated his skills to S/4 HANA. 

There is absolutely no need for a Custom print program anymore. ZERO !!!

Any custom logics, fields, calculations, Abap code can be accommodated inside of the form where there is a section for you to put your own code, Form Routines and Data Definitions. I will not tell you how to do this part exactly because I am not an Abaper, but he should go back and investigate that as it is pretty simple to do in Adobe Forms.

Once he added the custom code to the form, you will be able to obtain the expected results and no SAP code would have been modified and this form will continue to be called by standard SAP programs.

This last part is really important, as I have passed through S/4 clients in the last years and I have seen Functional consultants that still asked for a custom print program and also delivered a form by using SAPScript. That should not be the approach for S/4 HANA anymore !

The technology stills exists and is still available for you to use it if you want. But you should not use it as you will be using old technology and not benefiting from the latest innovations. (Can you still work with a Monochrome amber or green screen ? for certain things probably yes. But there are better monitors now a days. So this is the same ...).

If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.

www.dnabusinessconsulting.com

Planning in S/4 HANA without breaking the bank ($$$)

How to do Planning in SAP has changed who knows how many times in the last 15 years. From Classic Planning using the CO Tables in ECC, then adding some sort of planning in BI with NWBC, SAP recommending BPC (Business Planning and Consolidation) and some other variations. Once S/4 HANA was launched, they started pushing for BPC Embedded for S/4 (around S/4 1610 version). Then "cloud season" started and they came up with SAC (SAP Analytics Cloud) which is the latest one that they want you to adopt. But for sure it does not come for free and you have to pay an extra fee / subscription to use this Cloud solution.

Now, if you do not want to break the bank and pay extra for a Cloud solution that you might not want. How do you do planning in S/4 HANA ?

Classic Planning using the old totals tables (Ex. CO Planning, Profit Center Planning, COPA KEPM Planning), it is not the preferred option for S/4. It comes already deactivated out of the box and you have to follow a couple of OSS Notes to re-activate that. Also the new series of Actual vs. Plan Fiori Apps, do not read those tables. So if you try to use them for reporting, they will not show you Plan data. There is a way around it to transfer the Classic planning figures so the Apps can report that data, but not the preferred one either (at least for me).

BPC Embedded for S/4 HANA, could be an option. SAP has recommended it at the time of S/4 version 1610 or 1709 but has moved away from it since and it is not recommending it anymore. In fact they have plan to sunset this one too. Also in order to use this option, you need to have an extra license for BPC Embedded ($$$). Not my preferred one either.

Finally, SAC - SAP Analytics Cloud for planning. It is the new kid on the block from SAP for Planning. More and more "planning stories" are being developed and released every year for it and it became a world on its own. SAP wants you to adopt it. For sure, it is extra ($$$) and you have to pay a subscription to be able to use it.

Now ... I have a solution that is hidden out there that is none of these 3 and will not cost you a penny and comes included as part of your S/4 HANA package and license. It is just a small configuration / activation change and it will become available for you.

The solution

The solution is based on the below 2 OSS Notes and an SAP Help link.

 

https://launchpad.support.sap.com/#/notes/2503495

https://launchpad.support.sap.com/#/notes/3033876

 

SAP Help Procedure to EDIT the variable INFOPROV

https://help.sap.com/viewer/74785309615c47a1b7497b1f8942ebd1/1809.001/en-US/3ceafc57bde70f70e10000000a44147b.html

From the Notes

1. The customer could – at system setup – set the default value for the variable /ERP/P_0INFOPROV to Info Cube or ACDOCP.

S/4 HANA out of the box, comes configured with the Info Cube option; which it translates into using BPC Embedded for planning. This is not an option that you would prefer, as it will require you to have an extra license.

If you set it up for ACDOCP, all the Actual vs. Plan Fiori Apps will work correctly and report Plan data.

Also you will be able to upload your Plan data using the Fiori App "Upload Plan Financial Data". This will store the data directly in Table ACDOCP. This applies for COPA Market Segments plan data, Cost Center, Profit Center, P&L, Balance Sheet Planning, Internal Orders, etc.

This App will allow you to plan outside (like in Excel), populate the loading template and then upload it in the App.

 

Step-by-step setup

Tcode RSPLAN

 Click in "Filter" and then in the Filter field, enter any filter which uses the variable /ERP/P_0INFOPROV, for example, any filter starting with /ERP/SFIN_xxxxx and select "Display"

Locate the InfoObject 0INFOPROV (InfoProvider) in the Selections screen area. Choose right next to the Restriction column the "puzzle" icon.
In the View field, choose Variables from the dropdown list

Choose the /ERP/P_0INFOPROV variable in the Variables of Single Values table. Then choose the "pencil" icon to modify.

Note: You are finally in the editing dialog of the /ERP/P_0INFOPROV variable.

Click in the "footprint and yellow arrow" icon twice to get to the Default Value(s) field. 

Choose the InfoProvider of your choice and confirm it

InfoProviders for Plan Data

You can use the following InfoProviders for storing plan data:

• /ERP/SFIN_R01 S/4HANA Financials: InfoCube for Plan Data (this is S/4 out of the box and will use BPC Embedded for S/4, which we do not want to)
  
  
• /ERP/SFIN_V20 S/4HANA Financials: Plan Data from ACDOCP
  Virtual InfoProvider which stores plan data records in the ACDOCP table, which has almost the same structure as the ACDOCA table. (this is the one we want and that costs nothing ($$$) and does not require an extra license)

This solution will allow you to load data using Fiori App "Import Financial Plan Data" and execute all the reporting Fiori Apps that give you Actual vs. Plan data that will retrieve the uploaded data. If you do not modify this system variable, you Fiori Apps will show NO Plan data figures.

Note: This solution is not Transportable, it has to be done manually in each environment and you need the config to be open to do it.

If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.

www.dnabusinessconsulting.com