Is modelling about to overtake coding? Im a happy SAP business consultant :)
Amongst all the products being pushed by SAP over the last 2 years, one trend I have picked on is the pervasive emergence of modelling tools:
- SAP BPM as a modelling (and execution) tool for composing innovative business processes outside pre-configured and often heavily bespoke SAP Business Suite processes
- SAP BRM or BRFPlus as modelling tools for extracting and managing business rules outside SAP Business Suite’s coded-in processes and rules.
- Project “Gateway” – The Rise of UIs will also help support the move initiated by SOA to decouple the user interface from SAP backend. As a result, user interface graphical modelling tools will also become prominent in SAP implementation projects in the next few years.
Modelling tools will now slowly but surely replace coding in many part of SAP implementation projects and this is great news. This trend has got me all excited (again) with selling and implementing SAP projects.
I have always seen myself as a business consultant trying to help our customer making sense out of SAP. When I started as a junior functional consultant in 1997 with R/3 3.0, the largest proportion of SAP consultants on a project was functional. Nowadays many consultants are either technical or technico-functional consultants and this has not helped with the SAP original promise of bridging the gap between business and IT.
Back in the old days (I now sound really old, don’t I?), a very useful modelling tool for implementing SAP end-to-end processes was the SAP Business Navigator. This was a graphical viewer for navigating any process (e.g. Order-to-Cash) in the form of Event-Driven Process Chain (EPC) diagrams. One could even drill down from a process step into the actual SAP transaction. Magic! Very business user friendly as well as I would typically run blueprinting workshops with business users using the tool themselves.
Don’t look for transaction SB10 or SB09 though; it has disappeared from any SAP system long ago (from R/3 4.7 onwards to be accurate). From that point on, licensing and using ARIS Modelling tools has been the only way to have this process-oriented view of SAP. Even Solution Manager’s business process repository (BPR) is only a textual and hierarchical representation of SAP reference content.
I see 3 main reasons why coding has slowly started to dominate over modelling over the last 15 years or so:
Lack of enough flexibility in SAP suite of products to cope with the acceleration of changes in business requirements
Almost all SAP applications of the client/server era were built on top of a single database. The tight vertical integration and associated complexity meant the same developer or team controlled the application from the user interface to application logic to the database. This trend has started to be reversed for example with the advent of the web UI configuration tool for SAP CRM: business users (and myself) can regain some -still limited- control over how screens should be designed.
Lack of functional knowledge about SAP standard processes and associated configuration
Very often and pushed by budgetary or time constraints, a solution design involves more coding than necessary because it is seen as the safest way to deliver. A little more time invested in solution design (or more time on proper training on SAP products) could often lead to a more standard SAP solution and reduce the project TCO.
The vicious self feeding circle of SAP bespoke solutions
I have seen too many customers by now stuck in what I call the “SAP moving sands”. As their SAP solution has become more and more bespoke, it has become even harder to come back to standard SAP. As a result, coding has called for more coding as an easy way out to meet business requirements. I know many of these customers are now totally unable to get out of this mess and to move their solution forward.
The impact of the modelling tools mentioned earlier will be strongly felt across the whole SAP microcosm. I can see the following playing out over the next few years:
A lot of “manual coding” or technical skills will be taken out of projects and replaced with modelling
- SAP BPM already automates some of the UI generation work with Visual composer, ABAP or Java webdynpro UI tasks.
- Modelling business processes with SAP BPM means taking out deep (and relatively rare) technical skills like SAP business workflow skills
- SAP BRM and BRFPlus provides users with intuitive so-called “normal programming languages” which isolate business users from the actual generated runtime code used in business processes.
- Many non SAP user interface modelling-based toolset also isolate users from actual generated code.
Deeper engagement with business users
The new division of labour supported by modelling will bring together business analysts and SAP business consultants throughout the project lifecycle. Agile implementation methodologies which put a stronger emphasis on collaboration are actually made possible by this application development paradigm shift towards Model-driven software implementation.
Different skill set for customer facing consultants
As a result of the above, learning how to use these modelling tools will become more important for SAP functional or business consultants. Customer-facing will take a whole new dimension as well. For example, user interface development will become an integral part of a process definition and will require iterative workshops with business users.
Different skill set for technical consultants
- Removing coding from projects does not necessarily mean the death of SAP technical consultants. We will still need hardcore ABAP programming skills but I suspect lesser and lesser over time. All the tools mentioned above currently still require some level of coding when getting to a lower level of detail. Overtime, automated code generation will supplant that task (could just be me dreaming here or watching too many science fiction movies…)
- In the SOA world, technical consultants will have to adapt as there will still be many different high value and technically challenging roles – Enterprise service provisioning being an obvious one.
This redistribution of roles on SAP projects will undoubtedly impact both consultancies and customers. Let’s see how this will play out. In the meantime, I will keep my smile on the face.