Skip to Content
Author's profile photo Former Member

Is modelling about to overtake coding? I’m 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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Nathan Genez
      Nathan Genez
      There have been SAP tools in the past that have enabled functional resources to develop solutions that previously had to be done by programmers.  Query, LSMW, eCATT, et al did this but are simplistic in nature.  If you're right, I think it will re-build the services gap between the technical and functional resources in SAP.
      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Yes you are correct: there are many other tools in SAP which help consultants accelerate the delivery phase all ultimately for the customer benefit.
      The modelling tools I have mentioned will help bridge the gap between business and IT during SAP projects.
      Using collaborative and Agile implementation methodologies, one can already see deeper involvement of business users with SAP consultants throughout the project phases: from the initial accelerated blueprint to the multiple build or sprint iterations.
      Author's profile photo Former Member
      Former Member
      I agree with you on the point of demise of Business Navigator application. Now Solution Composer is used to make end to end models, but there are inconsistencies between what Solution composer offers to what Business Process Repository has. Solution Maps in Solution Composer should be consistent with BPR content to make sure there is smooth transition of system design from Solution Composer to Solution Manager.

      And yes more modeling and less coding is the way to go in the future.

      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Solution Composer as a tool and in terms of content has not been updated for a while (as this a downloadable offline tool).
      There is probably a better correlation between the BPR and the Entreprise Service Workplace which is available online.

      Regarding Solution Manager, you should be pleased to know that Solman 7.1 -going in rampup Q1 2011- will apparently integrate the Solution Composer tool: you therefore -hopefully- get the full integration BPR/Solution Composer/Solman 🙂

      Author's profile photo Ajay Kumar
      Ajay Kumar
      BMP does not mean replacing the coding, behind BPM at every step there will be service associated with that which is actually a coding.

      BPM just replacement of functional people. It will speed up the blueprinting time and technical people can start coding without much clarification from functional people.

      Business people can directly define business proccess through BPM which can be further updated by technical people.

      So there is direct contact between business and technical people by minimising functional people.

      There is diff. between functional and business people.

      Business: Who knows the actual business process.

      Functional: people who is more a SAP but less a business.

      Technical: More a technical very little business

      So now functional is out and Business and Technical come in direct contact.