Customer Question of the Month: Custom Code and Fiori
If you’ve been on SAP for more than a few years, custom code can be a significant challenge to your digital transformation. It’s easy to forget how much has changed since you first got on SAP. In nearly 50 years, the company has gone from providing niche mainframe applications, to a cutting edge cloud-enabled ERP solution that works across nearly all industries and use cases. Many users have spent years or decades improvising along the way, building their own internal apps or customizing SAP code to provide tools that weren’t available at the time.
Many of those custom apps are now outdated relics — good for their time, but clunky and inadequate by modern standards. And yet, they’re still lurking in your legacy landscape. In many cases, they’re abandoned and forgotten. In other cases, they’re still using resources, costing the company money and processing power that could be used for running the business. And sometimes, that legacy code is still in service, as an integral part of your landscape.
Custom code can pose a particular problem for SAP Fiori implementation. SAP Fiori isn’t just a new look for SAP — it’s a genuinely new UI, that interfaces with your SAP landscape in different ways than previous generations of SAP UI. Custom code that worked fine with SAP GUI can interfere with Fiori functionality, or limit the benefits of the Fiori UX if it isn’t handled properly. Here’s what you need to know about custom code and SAP Fiori.
How Custom Code Affects SAP HANA and Fiori Implementation
-
Wasting system resources
Custom code poses a few essential problems for SAP HANA in general and Fiori implementation in particular. First of all, custom code is wasteful. Many SAP users don’t have a strong routine for house cleaning. Rather than turning off applications they’re not using, they just forget about them and leave them running in the background. These applications waste processing power on their own, and might also contribute to other wastes of resources, such as printing out daily logs that no one is reading, or imposing extra steps that are no longer relevant in the workflow.
-
Cyber security risks
Custom code can also pose dangers for SAP security and interfere with compliance processes. SAP HANA has strong built-in security protections, enabling companies to encrypt data, control and monitor access and report on potential risks. Older software is built to older, less secure standards. Custom applications are not only more vulnerable on average, they may provide a backdoor for hackers to access other areas of your system.
Hackers will always take the easiest way in that they can find. An old application with a default password, or other flaw can potentially enable attackers to steal or deface confidential customer data, trade secrets and employee records. In many cases, remediating these security risks may require customers to scrap the custom code altogether.
-
Lack of SAP Fiori UX compatibility
SAP Fiori is a dramatic leap in SAP user experience. SAP traded in the menu dragging and form filling of the legacy SAP GUI interface for a slick, mobile-friendly UI, optimized for user accessibility. It works on any device, puts the most commonly used functions at your fingertips and gives users the ability to optimize and configure their UX to fit their actual workflow and preferences.
To accomplish all of that, Fiori had to be completely reengineered. It accesses SAP functions in a different way than SAP GUI, using service authorizations instead of transaction starts, and has a much different architecture, designed around the capabilities of HANA and the needs of the modern business user.
Unfortunately, that means that custom code designed for an ERP system using SAP GUI won’t always work properly with SAP Fiori. It may decrease some of the benefits of Fiori and HANA for certain use cases, or require complex workarounds during implementation. Certain custom apps may just not be compatible at all. Others may be usable in SAP Suite on HANA but not suited for S/4HANA. And even when there is a way to utilize a custom app, it may not be worth saving. More often than not, S/4HANA has the functionality available.
-
Dependance on the Custom Code
In some cases, retaining a piece of custom code may actually be necessary. For example, it may enable a specific function that S/4HANA doesn’t have off the shelf, or a workflow that’s well-designed for for your particular needs. Just as importantly, remediating the custom code may have a significant cost associated with it, and pose little to no significant benefit for your company. In that case, it may be worth delaying remediation, or putting it off indefinitely.
Custom Code in SAP HANA Transformations
In the SAP Activate methodology, custom code is audited in the second phase of the project: the Prepare phase. This stage of the project follows the Discover phase, where your company sets broad project goals and defines the scope of the transformation. In Prepare, your company and SAP managed services partner dig deeper, investigating where your landscape is at the moment, and the steps required to accomplish the broad goals defined in Discover.
One of the most important tasks in Prepare is auditing custom code. This has historically required a technical team to manually examine your system, which can take a couple weeks. And most companies lack an asset who can confirm the findings, so they just have to hope their partner gets it right.
Historically, decisions about what code to remove have involved a lot of trial and error. Essentially, teams switch on the system and see if anything breaks. In this process, companies rarely prioritize elimination of unnecessary code if it doesn’t directly harm the system — even if there’s no need for a particular app anymore.
This approach may get you where you need to go, but it’s filled with inefficiencies, from the manual code audit to the retention of unnecessary custom code. There’s a better way to do it.
How Should I Handle Custom Code in my SAP Fiori Implementation?
Automation is one key to effective custom code remediation in SAP Fiori implementation. While many SAP providers have excellent resources on staff, most do not have a mature approach to automating the SAP Activate process. Instead, they use an ad hoc patchwork of tools and largely manual processes to plan and execute the transformation. This requires extra work, from auditing the code to testing and tweaking SAP Fiori, to post go live tuning. It also increases the risk of human error.
Protera FlexBridge accelerates SAP HANA and S/4HANA transformation, as a complete platform for executing the SAP Activate process. The FlexBridge approach begins with a free, automated code audit of your landscape. This process will quickly provide a detailed picture of your landscape — including custom code — and show you the steps required to bring you to Suite on HANA or S/4HANA. This empowers you with the knowledge to plan the most effective SAP transformation for your company.
Protera FlexBridge helps with SAP Fiori implementation in other ways too. Flexbridge helps you choose the right Fiori apps for your transformation, and analyze and turn off unneeded applications, ensuring you have the tools you need, while eliminating resource waste in your new landscape.
Sign up for a free SAP assessment, and take control of your SAP Fiori Implementation.