Out with the Old and In with the New: From R/3 to ...

Former Member · ‎01-20-2009

This topic comes in 3 installments. In the first blog, we shall walk through the changes that have occurred over the years concerning SAP’s ERP technology, and what ignited these changes. We’ll also take a look at how SAP’s present and future go-to-market strategy of the ECC platform shares a close connection with SOA, and how the two are interrelated.

Then in the second and third blogs, we’ll dive deeper into the impacts of this overall change from R/3 to ECC, considering why it is necessary for SAP practitioners and customers to increase their awareness and up-skill themselves in terms of the new capabilities that ECC brings. The third blog will also reflect on why we see evident push back and slow assimilation from some SAP users in terms of fully realizing and utilizing the enhanced benefits of ECC (of which SOA is an integral part).

But let's not get ahead of ourselves...first let us see how ECC came to be what it is today.

What has changed from SAP R/3 to ECC?

So we all know that SAP has gone through a lot of changes since the 1990s. Just to summarize briefly... R/2 became R/3 (which is related to the term ‘real-time’ and consists of 3 tiers of architecture or layers: Presentation, Application, Database). With the advent of R/3, R/2 was used mostly for mainframe architectures.

Then in 2004, what was considered to be SAP’s R/3 enterprise (version 4.7) was enhanced with the addition of SAP’s first web application server (WAS 6.20), thus providing integrated web capabilities that were actually built into the ERP platform for the first time ever.

It is important to note here, that although the ITS (Integrated Transaction Server) platform had already come into existence offering web-enabled capabilities, the major disadvantage of ITS was that it was not integrated with what at that time was a completely ABAP-based core application server of R/3. There were other complexities involved as well, due to having 2 non-integrated application servers (which I won’t go into as part of this blog).

WAS, on the other hand, provided a completely integrated application server core of ERP. Also, the inclusion of both ABAP and JAVA stacks (complementing each other in countless ways) greatly enhanced the capabilities of WAS, as compared to R/3’s application server. One of the many examples of WAS’ web-enabled functionality is its ability to expose BAPIs as web services. This particular feature supports the notion that WAS is claimed to have lead the way for the ERP structure to have its underpinnings grounded on SOA, mainly because of its capacity to expose core SAP functions as web services.

So here we are in 2009, and it has now been 2 years since SAP officially released their latest version of ERP, which we know as SAP ECC or ‘ERP Central Components’.

As we bring the focus primarily on R/3 and ECC, it’s important to realize that within a timeframe of 10-15 years, SAP have gradually and increasingly brought a more versatile and multi-faceted environment for enabling flexible business solutions.

The diagram below depicts the overall shift from R/3’s highly stable but rigid functionality to a far more sophisticated platform, which has been designed to be a lot more adaptive and agile.

Moving from left to right, the architecture gets more loosely coupled from the core, while the SAP NetWeaver-based application platform provides the architectural foundation and progressively assimilates more technologies. Also, by 2007 you see SOA becoming the focal point of ECC’s architectural strategy, supported by the fact that literally thousands of enterprise services (the heart of SOA) cover all the major functionalities inside ECC.

So here’s a recap: SAP R/2 --> R/3 --> SAP R/3 Enterprise --> mySAP ERP 2004 --> SAP ECC/ERP 6.0

Now that we’ve covered a brief history of SAP’s evolution over recent years, it is important to identify and address the REASONS that brought about these changes and why this evolution of the platform was necessary to support business demands of today.

Why this change was necessary...

Today’s business demands for ERP are far different and more complex than the demands of yesterday, simply because there is big distinction between the current-day business models compared to the business models of the 1970s. The main factor with business models of today is the high level and frequency of change that organizations experience (due to acquisitions, mergers, shorter product lifecycles, and globalization). SAP has responded to the changing demands for ERP by addressing what is more relevant in the present for SAP customers and practitioners, which can be summarized as follows:

The need for flexibility and cost-effectiveness to configure/customize
The need for easier integration with non-SAP platforms
The need for better reporting and process visibility for decision-makers
The need for better support for industry-specific business needs

Essentially, R/3 is not feasible in current business requirements anymore, primarily due to the following 3 reasons:

No longer boundary walls of just internal processes
In previous years of doing business, customers generally focused on their internal processes. They didn’t have much linkage and direct system interaction with external forces such as their vendors, suppliers, partners, nor was the idea of having extended business networks very common or necessary before. But gone are the days when companies could function independently from their suppliers, partners, and vendors. Nowadays, these companies are required to integrate their systems with the ‘enablers’ mentioned in order for their businesses to thrive.
No longer a need for extensive training
Another reason that this change needed to happen: since the R/3 system was so rigid and rich in its functionality, it was built to be utilized primarily by highly trained users. So there was a good deal of training involved in enabling users to be able to maintain the system. Also these days, constant user training is not very feasible or practical in any given organization’s continuously changing environment.
No longer can generic solutions be applied – because business cases vary
Because the R/3 system had more generic functionality, it could not necessarily apply to every business, and everyone knows –- no two business models or business' processes are exactly alike, since there are always variations. So there ended up being a lot of customization required to work around R/3’s general functionality, thus making future upgrades more difficult and expensive.

Here’s a brief summary of what has changed:

The extent to which ERP has evolved from R/3 to ECC can best be summarized by the following points in relationship to the images below:

[Above image adapted from Dr. Hichem Maya’s presentation called “SAP NetWeaver® Overview” from the SAP World Tour ’06]

In a nutshell, the main differentiator is the SAP NetWeaver platform. With NetWeaver as the foundation, ECC is capable of assimilating the use of both JAVA and ABAP languages and easily supports new product introductions. Since NetWeaver Developer Studio is for JAVA-based development and ABAP workbench is for ABAP-based components of the new ERP system (but with improved and additional features), it is clear that these development tools significantly enhance ECC’s functionality, further supporting and validating the main distinctions from the R/3 system listed above.

Additionally, the user interfaces have a noticeable contrast when weighing R/3 against ECC. What sets them apart is that in ECC, one can easily develop/customize the user interface according to user preferences (with the use of in-built tools like Visual Composer and WebDynpro). Similarly, the layout of ECC’s UI is way more process-centric as opposed to transaction-centric, thereby further facilitating usability for business users and streamlining workflow.

So now that the key differences have been identified, I shall bring the first part of this topic to a close.

Next, I will pick things back up in Out with the Old and In with the New: From R/3 to ECC & SOA (Part 2: IMPACTS) by addressing the impact of these changes that have happened from R/3 to ECC on a solution approach level and a system level, as well as the need to up-skill in order to keep up with these changes.

In the meantime, one more thing for you to mull over is...