Earlier this year, I published a 6-part blog series illustrating ways to innovate around SAP using modern toolsets / techniques. After the series wrapped, one of the common questions we received from customers/readers was just how real the potential cost savings were. So, we decided to sharpen our pencils and do a quick postmortem on this topic to demonstrate just how transformative these technologies can really be.
In the upcoming sections, we’ll look at some real-world examples side-by-side to demonstrate the cost differences from a development perspective. To be fair, we’re painting with a fairly broad brush here so your mileage may vary. Still, we think you’ll find the evidence is pretty clear — and definitely worth exploring.
Reports (75% Reduction)
For this example, the request from the customer was to create a dashboard which visualized operational performance in several different dimensions. From a development perspective, we’re essentially talking about three 2-D tabular reports and two analytical pages that visualize the data using various charting controls.
When we started this conversation, the initial assumption was that we’d build these reports using SAPUI5/Fiori technology. Here, the SWAG estimate came in at roughly 160 hours. This number was somewhat skewed by the requirements for the two analytical pages where the business wanted the various charting controls to work in lockstep with one another (e.g., a change in chart A causes updated to charts B and C). These kinds of features require deeper knowledge of D3.js — something that not just any Fiori developer may have in their tool bag.
After additional discovery, we learned that the SAP data tables in question for these reports were already being replicated to Google BigQuery by way of SAP SLT. This created an interesting opportunity — instead of building the reports from scratch in SAPUI5, we could just point Microsoft Power BI at BigQuery and then build the reports from there. The only trick there is that we would need to split the development task in half:
An SAP development resource would be needed to map report requirements to the raw data model in BigQuery.
An experienced Power BI would be needed to build the report in Power BI.
The pivot to Power BI reduced the actual development time down to 32 hours. As an added bonus, Power BI added some additional features to these reports that would not have been available in a Fiori report, so it was a win-win on both sides.
Interfaces / Conversions (60% Reduction)
For this example, we had a customer that was looking to interconnect 4 different systems with SAP ECC to streamline transportation management processes. Protocol-wise, we were dealing with a mixture of ALE/IDocs, SOAP web services, REST APIs, ETL (Excel), and webhooks. In addition to the interfaces themselves, there were some interesting workflow requirements:
Since the source system did not emit events, we had to have a job run on a continual loop to invoke REST APIs and comb through the results looking for deltas.
We had to build index tables to centrally track shipments.
There were some complex requirements around transformations between XML and JSON (including real-time lookups).
We had to build in some conditional routing logic to split/merge messages and parcel them out to the right destination(s).
In total, we had 12 integration scenarios that were between medium (4) and high (8) complexity. Using a basic SWAG model for SAP PI/PO development, the initial estimate came out to about 800 hours’ worth of development. Looking carefully at the requirements, we felt like this number was actually pretty conservative given some of the unique challenges.
It was at this point that the project decided to pivot to Azure Integration Services and specifically the low-code Logic Apps iPaaS service. This shift unlocked several key accelerators:
The built-in connectors reduced the amount of mundane development required to connect to REST APIs, SQL databases, parse/splice Excel files, and send notifications.
The ability to utilize Liquid templates significantly reduced the time it took to build complex XML-to-JSON or JSON-to-XML transformations.
Simplified and flexible workflow/process design using simple graphical tools.
Collectively these features allowed us to reduce our actual development time to ~320 hours which was roughly 40% of the original estimate.
Enhancements (80% Reduction)
For this example, we’ll compare the creation of a quote creation app in Fiori vs. Power Apps. In this scenario, the ask was to effectively provide users with a scratch pad where they could run through various simulations as they built out a customer quote. Here, while we were ultimately building a standard quote in SAP, the data could really be staged anywhere. So, instead of creating a series of Z-tables and building a custom Fiori app on top of them, we decided to model this staging area in Dataverse and then create the app using model-driven apps.
This approach unlocked some big wins in terms of productivity:
The app screens literally came together in a day using WYSIWYG tools.
Similarly, we were able to define key business rules using graphical tools as well (e.g., if field A is selected, field B is mandatory, etc.).
The built-in Dataverse security model enabled us to address complex security requirements through configuration.
Since the users wanted to be able to jump in and out of Excel to maintain their quotes as needed, we were able to accommodate this requirement for free using Dataverse.
As a bonus, we were able to provide offline access for the app using built-in functionality in model-driven apps.
Overall, this approach ended up shaving 320 hours off of our original estimate, yielding an 80% reduction in development time.
Note: There was a trade-off in this scenario when it comes to licensing since model-driven apps did require a $5/user/month user license. In this particular situation, that cost was actually less than what it would have cost to provide a similar environment on SAP BTP, but that’s assuming that we include the offline support into the equation.
Forms (80% Reduction)
For this example, we’ll compare the creation of an Adobe form using SAP Interactive Forms by Adobe against the use of Adobe Document Services and Power Automate. In this scenario, the ask from the customer was to create a stylized customer quotation form (e.g., customer logo, dynamic form data from CRM, etc.) and generate it dynamically as part of a workflow process.
As a somewhat niche skillset, it can be difficult to find an ABAP developer that knows the ins and outs of SAP Interactive Forms by Adobe. Resource issues notwithstanding, the typical hours estimate for an ABAP developer to build a dynamic quote form like this would be somewhere in the neighborhood of 40–60 hours.
In this particular scenario, we decided to use Adobe Document Cloud to build the form using Microsoft Word. From there, all that was left was to fetch the quote data using a pre-existing OData service and then merge it together using the Adobe PDF Services connector for Power Automate. Finally, we wired up the Power Automate cloud flow to SAP Business Workflow using an HTTP callout. Collectively, the entire exercise took 8 hours and did not require us to upskill a developer in the nuances of SAP Interactive Forms or the Adobe Lifecycle designer tool.
Workflow (60% Reduction)
For our last example, the requirement was to build a workflow process to automate the collection of ACH payments for construction projects. In this scenario, the workflow was responsible for coordinating a host of activities:
Automating the customer onboarding process as well as the generation of transactional documents such as sales orders and invoices in SAP
Digital forms/signatures in DocuSign
ACH payment processing in Stripe
Although it can sometimes be difficult to find ABAP developers that know their way around SAP Business Workflow, the primary challenge in this case was figuring out how to orchestrate the non-SAP tasks. In this case, even if we could get Basis to allow us to interconnect with these systems, the reality was that ABAP is not particularly well suited to navigating through complex security protocols, wiring up webhooks, or building documents dynamically.
Since the amount of ABAP required to wrangle BAPIs and create transactional documents remained constant no matter how you slice it, we compared estimates based on the amount of time we thought it would take to manage the external callouts. We estimated the effort it would take to build the solution from the ground up with ABAP and ICF clients/services at 400 hours.
When we re-imagined this using Power Automate, we picked up some huge wins right away using the OOTB connectors for DocuSign and Stripe. It also provided opportunities to tap into Azure-based services such as Key Vault (for secure credential handling), API Management, and even Azure Functions in cases where a bit of complex C# was needed to leverage key features of the DocuSign and Stripe SDKs. Power Automate also made it much easier to gracefully respond to potential errors in the payment collection process.
Collectively, these features helped us shave off 240 hours off of the ABAP-only estimate — a 60% increase in productivity.
Closing Thoughts
Hopefully this exercise was helpful in painting a picture of the potential cost savings that can be unlocked with the BEANS approach to SAP development. Obviously, this is not an exact science, and your mileage will definitely vary based on the requirements. Still, we’ve consistently seen 60% as kind of the low bar for productivity improvements with most day-to-day SAP development requirements. If you’d like to learn more about how this could work for your business, please drop us a line and we’d be happy to sharpen our pencils and explore options with you.
