We begin our discussion of extensions by examining the term extension. What is an extension? What is it exactly that we are extending? And most importantly, why are we extending it?
All software is designed with a scope in mind. This scope defines two things, as follows:
- The outcome for the customer that the software is providing
- How the software provides that outcome
From the customer's perspective, it is the fulfillment of outcomes that creates value. For a software vendor such as SAP, scope is the foundation of the value proposition presented to the customer, and is a critical part of the software design process.
Without a doubt, one of the greatest advantages of SAP ERP over its history has been its scope. Delivering a product conceived to cover virtually all business processes in the areas of logistics, finance, and human resources is a tall task. Add in the fact that SAP's customer base covers over 30 different industries and the magnitude of the task becomes even clearer. Each industry has its own specialized ways of executing certain business processes (for example, banks may design and execute procurement processes differently than a governmental entity or the military) and even within the same industry, individual companies may design and execute a process differently. But the challenge of scope has never been one that SAP has avoided. Quite the contrary – it has been embraced with enthusiasm.
The Need for Flexibility
While the breadth of scope covered by SAP applications undoubtedly is an important factor for customers in adopting SAP solutions, there is another factor they valued. Flexibility: The ability to adjust the delivered scope in such a way to fit their unique needs. Thus, another challenge presented itself to SAP: How to not only provide scope to customers, but also flexibility to adjust that scope as per their unique needs? As was the case with scope, SAP embraced the flexibility challenge with enthusiasm. Meeting this challenge, however, required some "out-of-the-box design thinking" on the part of SAP.
One potential solution would have been to provide a system to the customer where once installed and live, the source code is "frozen". The customer would have no ability to adjust or change this code, and they would only be further concerned with routine maintenance, updates, and upgrades – all of which would be, for the most part, simple and painless. The IT department responsible for maintaining the system would simply apply the relevant patch, or at the appropriate time, upgrade the software. Afterwards, they would perform a quick test to make sure that everything still works okay and the job is done. While IT would be happy with such an approach from an ease-of-use perspective, the business stakeholders and most importantly the end users (where the true value of a software system is realized) most likely would not be, as both groups require a software package with more flexibility with regards to adjustments. Needless to say, this approach was not adopted by SAP.
Another potential solution lies on the opposite side of the spectrum: A system delivered with a baseline repository of code, but that code is a "suggestion." The system would be a free for all. Changes, modifications, and wholesale deletion of code would be fair game. In this environment, even the simplest maintenance release by SAP (just applying a simple technical patch to correct a bug) would be fraught with uncertainty. It might take months to apply such a patch, when it should only take a few minutes. A full-fledged upgrade could be a nightmare. Depending on the scope of the customer, changes that have been done in a simple upgrade could take half a decade. The costs associated with this type of approach are considerable, both to SAP and the customer. Beyond the financial costs of having IT devote so many hours to what should be simple operational tasks, there are also opportunity costs in having a system incapable of responding quickly to changes in a market that requires the ability to adapt quickly. As with the first approach, SAP did not adopt this one either.
What was needed was the "Goldilocks" approach, where the needs of the following three distinct groups are balanced:
- End users who want software with a consistent user experience (more on this in a later lesson) that is simple and easy-to-use.
- Business stakeholders (particularly and especially process owners) who want an application that is stable but can be tailored to the unique way that they desire a business process to be executed.
- The IT department who must install and maintain a system, where the needs of the two groups mentioned previously are met but one in which those costs are managed in an optimal way for the business.
This approach bore fruit as customer-initiated code adjustments. The system was installed with standard functionality (based on best practices) but also with the ability for the customer (in a clear and controlled manner) to adjust that functionally to achieve desired outcomes consistent with the needs of stakeholders in a cost-effective manner. While at first this approach may sound inevitable, it is easy to forget that decades ago, when SAP R/3 was introduced to the market, it was considered revolutionary. But it is fair to say that over time, this balanced approach has become one of the single most important factors in the phenomenal success of SAP ERP.