SAP development process hasn’t changed much during the last 50 years. The process is characterized by too many chefs, no reuse, and a lengthy software lifecycle.
For the past 50 years or so, developing reports and interfaces in SAP was done in the very same way. Namely, the Business end-users (hereinafter: “Business”) approach business-analyst with a new business requirement in SAP – Requirement Document. The Business-analyst drafts a Specification Document and hands it to the development. Development, in its turn, writes a Design Document and codes it into SAP. Testers make sure that the specification, design, and outcome code are aligned together. If all goes well, the code is moved to a Quality Assurance (QA) system for further testing and to the Production system, thereafter. Business, Analyst, Developer, and Tester working together to fulfill the development process.
The above process takes variants depending (mainly) on the size of the company and the industry it operates in. That is to say, bigger companies and those operating under heavy regulation (pharmaceutical, for example), tend to add links to the Development Process chain. Thus, in some enterprises, one may find additional actors such as SAP application manager, development manager, and others.
In the traditional SAP development process, each actor of the development process chain (Business, Analyst, Developer, and Tester) masters only one part of the development-process puzzle. While Business understands their organization’s specific processes, business analyst understands how SAP manifests these processes and the developer knows SAP data-model and how to code in it. In many cases, the information does not flow coherently throughout the various actors, yielding undesirable results. Too many times, the result looks more like the famous Swing-cartoon and less like what Business wanted.
The above process holds a few paradigms that must be put into question.
- Chain of value loss – The only reason Business does not fulfill its own needs is their lack of ability to ‘talk’ with SAP. No-one would ask IT to ‘develop’ an Excel spreadsheet. Each part of the knowledge chain (Business, Analyst, Developer, Tester) masters only one part of the development-process puzzle. Thus, the development process – by definition – turns lengthy, costly, and inefficient.
- Zero reuse – With over 50 years of continual development of SAP systems by thousands of ABAP developers, it looks as if customers repeat every development from scratch.
- Zero business reuse – SAP system is shipped to customers with a huge set of reports and queries that help end-users to query the application. Alas, often those SAP standard reports are falling short to fulfill all customers’ needs. Using the ABAP integrated development environment (IDE), customers will employ developers to code their own reports. In case only the gap between the existing SAP standard and the needed report had developed, time and resources would have saved.
- Zero technological reuse – In many developments (reports/interfaces) building bricks are repeated (this way or another) time and time again. Have not we already sent data as an Excel spreadsheet over email? Have not we already enabled drill-down to business objects (order, invoice, employee) from the report? Have not we already searched the log tables for changes in business objects? Needless to say that doing those micro-tasks over and over again yields a lengthy, costly, and inefficient development process.
- Zero UI reuse – Following the last point regarding reuse, one may broaden the question to reuse at the UI level as a whole. That is to say, we can see the outcome as a SAPGUI report, why can not we have it automatically parsed as an Excel spreadsheet? Why should we develop everything from scratch to see the result as a Fiori application?
- Software life cycle – Indeed, if everything is developed over and over again, it should be tested over and over again. Thus, on top of the development process, Change Requests (CRs) are moved from the Development system to the QA system and over to Production. This procedure alone is forcing an even more lengthy, costly, and inefficient development process.
Yet, time has changed. No one saves documents, versions, or even sends documents copies anymore. These days documents are constantly saved, tracked, and shared with others. Is not it time for the SAP development cycle to evolve as well?
Imagine a world where Business ‘talk‘ with SAP just like they talk with Excel or BI-tools.
Suite, an SAP-certified product, is natively coded in SAP using ABAP. InsightSAP is a platform that allows business analysts, consultants, and business end-users to create, enhance, and publish ALV Assets (e.g., SAP reports, locally developed (Z) reports, ABAP queries, DB tables, Views, etc.) – All done directly in Production, within SAP and w/o coding.
InsightSAP executes any existing SAP ABAP list viewer (ALV) as a base layer. On top of that layer, the ALV can be enhanced in terms of content (new columns) and/or presentation (coloring, grouping, and graphs to list a few) via a simple configuration and w/o coding. Any change of the configuration applies directly to the result ALV (without any CR or additional deployment).
InsightSAP is as simple to operate as Excel. Thus functions (actors) could now be extracted out of the development process. Everything done in InsightSAP could be easily shared in many forms and shapes (Excel spreadsheet, Fiori application, to list a few). Since InsightSAP is all about reuse, and its core functionality was already tested, InsightSAP makers can use it directly in the Production system.
