Mainframe Memory Lane – Part I
Skilling up on SAP’s shiny new ERP (S/4 HANA) inevitably brings comparison with last year’s model: SAP ECC 6.0…and its elder sibling SAP R/3.
S/4 HANA – SAP’s biggest technology leap since R/3. It’s natural then for consultants to ponder how much hard earned client-server-based ERP knowledge is obsolescent as we move toward a “columnar, in-memory” and “cloud-optimised” world.
Having witnessed a similar seismic shift (from mainframe R/2 to client-server R/3) 20 years ago, I’m very optimistic. Some concepts require adjustment in thinking, but there’s no doubt that the foundation laid from past projects puts us in good stead for what is to come.
The old R/2 projects even brought some unique experiences that remained useful and are unlikely to be repeated today. I’m expecting similar observations and nuggets of wisdom from R/3 and ECC projects as we transition to S/4 HANA.
So whilst reminiscing R/2 borders on the esoteric, consider this: History is repeating and so some past lessons could be worth remembering.
I’d be interested to hear if anyone agrees / disagrees – or has their own lessons from the crypt they would like to share.
This will be a two-part blog. First, some recollections of R/2 and the transition to R/3. Secondly, some lessons learnt from those early projects that I still value today.
What was R/2 like?
First impression… Green on a Black screen, as was the order of the day.
Digging deeper…. really complex. This complexity paid off for the large-scale manufacturers of Europe, as they discovered:
One integrated system
- Financials, Sales, Materials, Maintenance, Manufacturing and Human Resources;
- Up to 99 legal entities;
- Multi-currency processing;
- Multi-lingual interface;
- Hundreds of concurrent users connected via dumb terminals;
- Sub-minute response times!
The third and most overwhelming impression was that it was very, very logical. There was kind of overarching symmetry to every module. Naming conventions abounded:
- S = General Ledger (Sachkonten); D = Customer (Debitoren); K = Vendor (Kreditoren); B =Post (Buchen) etc.
- 01 was create; 02 change; 03 display; 04 was delete etc.
- The concept of the A segment, the B segment etc.
- Transaction codes were nicely logically organised by module, always 4-character, and always beginning with “T”.
- Concepts like Number Ranges and Dynamic Screen Modification were applied similarly in each module. We take this such consistency for granted these days – but remember this was before the days of object-oriented programming. Somehow SAP seemingly managed to have all of its application programmers marching to a similar beat.
- Control data like Document Types, Posting Keys, Account Groups became almost intuitive once you became conversant in the design language of SAP.
SAP R/2 had a level of control, order and restraint that came from a disciplined team of less than 100 developers working from one location. I imagined SAP GmbH’s office to be a very ordered and logically organised place.
The software category was yet to named Enterprise Resource Planning (ERP). In 1989, “R” stood for “Real-time” and this was a big deal. The alternative was to run separate specialised mainframe and AS/400 systems. Apart from requiring the services of a JCL programmer, interfaced systems came with an endless cycle of reconciliations and delayed reporting.
When R/2 went live, Head Office accountants rejoiced in a consolidated P&L that could be produced for the Group by Day 15. Although it must be said, end-users and regional offices were often less excited by the new controls and data entry requirements that came with the system.
What was R/2 like to implement?
Getting there wasn’t easy. “Slow And Painful” was a common wordplay. R/2 brought massive organisational change driven through the necessary changes in roles and business processes. This was happening at time when “Change Management” also hadn’t been given a name. Today, ERP projects follow a very structured approach – it is after all a well-worn path tread by large corporates. The early R/2 projects often had to formulate their approach during the implementation. For many of us, it was our first “Packaged System”. The structured methodologies that we had followed previously for “Custom Systems” no longer seemed to fit.
Similar to R/3 and ECC, R/2 was configuration table driven. However, the IMG (Implementation Guide) that SAP consultants rely on today did not exist. Instead, we kept notes with the names of Tables that could be maintained through one transaction: TM31. Need a new payment term? Type TM31 in the OkCode; enter Table T052…and so on.
Tim-Berners Lee hadn’t yet demonstrated the “World-Wide Web”. Our DOS-based PCs were connected via the exchange of floppy disks. So it was another 10 years to wait for Google’s search engine and the online SAP communities. Instead, blue ring-binders combined with a German-English dictionary were the best available source of current information. The required knowledge (as yet un-indexed) was stored in the brains of clever colleagues and ruled notebooks.
Successful projects relied on the team having detailed knowledge of the underlying logic of the system. Being able to convince the business users to align their business processes to the standard functions of SAP was imperative. Unnecessarily modifying the Germanic logic was not a good idea. Abandoning legacy system constructs was a better if not always easy path for the business and project team. The same holds true today.
What were similarities and differences between R/2 to R/3?
Once you got past the Windows front-end and clickable menu paths, R/3 shared a great deal of its parental DNA.
- The modules were remarkably similar in their scope and construction. For example, RF (Financials) and RK (Costing) were replaced by FICO. RM-MAT (Materials) replaced by MM. etc. By the time that R/3 3.1H was released in 1998, R/2’s scope of application had finally been fully supplanted.
- Within each module, the underlying table structures were very similar. Transactional R/3 tables like BKPF, BSEG retained their same function. R/3 Master Data tables like SKA1, SKB1, LFA1, LFB1 were almost carbon copies of the R/2 equivalents SKSA, SKSA, LIFA, LIFB.
- The business processes and transactions were redeveloped in R/3 with little functional change over the predecessor (Transaction TB01 became FB01 etc).
- Many of the configuration tables, technical field names and definitions and even the default values were brought over holus-bolus from R/2. Think Table T001, T002, T003 etc. For example, T003-BLART defined the same object (Document Types) in both systems. And KR still meant Kreditoren Rechnung (Vendor Invoice) and used the same posting keys – Such a relief for the R/2 guys!
R/3’s big changes came with its architecture and platform:
- Three-tier architecture (Database Server>Application Server>Front-End Client) delivering sub-second response times.
- The basis platform capabilities rapidly grew. The suite was rebuilt entirely in SAP’s proprietary language of ABAP. No more locked box assembler programs to contend with. Job scheduling, batch processing, database tuning all moved into the fold of the new windows-based SAP GUI. The underlying capabilities became more accessible. The system became more robust and scalable. By and large it delivered the same logic and function of R/2 in better, faster and more productive form.
The point is the move R/2 to R/3 was all about the platform.
S/4 brings massive rationalisation of transactional tables and the removal of aggregate tables – reducing the database size by more than 50%. A technology shift away from relational database to columnar in-memory has brought a massive boost in performance. However, the master and configuration data that defines the system’s function and form remains largely intact. Once again, the emphasis within this generational shift is on the platform. And so far, what we have in this year’s model all appears perfectly logical. Danke, Herr Plattner!
Next post, I’ll share some lessons I learnt from early R/2 projects. Be sure to visit again in a few weeks if you are interested.
Please feel free to drop me a line or add a comment if you have your own favourite R/2 memory to share.