Other things about SAP (which might block Agile)

To finish off my BPM/BPE/SAP mini-series here are some other things I learned about SAP and BPM. These might be specific to the team I encountered or they might be generic. I think all of them present obstacles to doing SAP implementation Agile. Not impossible, just difficult.

Please, if I have any of this wrong correct me. I’d love to be wrong on most of these things. I’m also acknowledge my dataset is small so anything you can add to these notes would be great.

First a word on TLAs, it gets confusing:

• BPR - Business Process Re-Engineering; where it all began (sort of), comes from a book by Hammer and Champy and was very popular in the 1990’s. Largely discredited now, a blunt instrument used by many consultants which caused a lot of damage
• BPM - Business Process Management; and
• BPE - Business Process Engineering; I don’t know the difference between these two terms, they seem to be the same thing. They describe the thing that rose from the ashes of BPR. Still focused on business processes but removing some the neutron bomb like aspects
• BPM (again) - Business Process Modeling; the activity of examining your business processes, a step in applying BPM (Business Process Management), something you can buy tools for
• CRM - Customer relationship management; and
• ERP - Enterprise resource planning; two of the most common applications for which BPM, and SAP in particular, are used.

As you can see, it get confusing.

OK, things I learned about SAP:

• Actually understanding what SAP does, and does not do, is very difficult. Despite masses of literature very little of it contains hard data. Most of it is hand-waving generalist, marking speak or so focused on outcome that it is impossible to tell which bit SAP did all by itself, and which bit was a custom bit bolted on the side.
• Nobody is a developer, there are lots of designers, even the people who you might think did configuration and table updates are designers. They all expect to have someone below them to actually get their hands dirty.

• SAP culture seems decided un-Agile. There is an expectation that business processes are be defined up front, software design up front, etc. etc.
• At the end of the development everything is rolled out, i.e. change is imposed on others.

• SAP people are plug compatible, well so I was told. Apparently you can give the SAP HR person a week off, call up the consultancy they work for and have another SAP HR consultant for that week.
• SAP consultants have a lot of frequent flyer miles. Don’t expect them to attend a 9am Monday stand-up meting or hang around on Friday afternoons.
• SAP consultants tend to work for big name consultancies. These consultancies seem to have an attachment to waterfall development. Perhaps because it gives them some nice sign-off (i.e. billing) points. Strategy, requirements, design, implementation, testing, change management, ....
• SAP is all encompassing. It is a development environment, a programming system/langauage, a run time environment, a source code control system and many other things too.
• SAP “configrability” seems to be at a GUI level, cannot textualise the configuations. Thus very hard to automate tests, compare differences and version control.
• Similarly code reviews are difficult but pair-programming should work. But given the prices consultancies charge for their consultants I don’t see many takers.
• SAP source code control does not provide for branching or merging - and probably not importing or exporting.
• Some SAP configuration can only be done by hand. So no automated builds or unit tests. (SAP doesn’t even try to support them.).
• SAP has a programming language, ABAP. Its supposed to be a little like Cobol. There is an ABAP Unit test framework. It won’t do you much good because most SAP “programming” is done through configuration and there is no way to do unit testing on that configuration.
• (These and other aspects of the SAP tool set very old. This will make life difficult to Agile teams who may need to create new technology to address these issues.)
• Once you have finished your SAP application you pay SAP to “maintain” it. Or rather, pay them not to break it with a future SAP release.
• Nothing from SAP works out of the box. One of the first things you do in an SAP project is switch on the bits you want and switch off the bits you don’t. Some of these appear to be one time only decisions, you don’t get to change your mind.

Overall I got the impression that when you buy SAP you buy a legacy system. You start from nothing and you move immediately to legacy maintenance. That should be ideal but in buying SAP you buy lots and lots of functionality you don’t need and that imposes an horrendous maintenance burden.

I hope that doesn’t come across as SAP bashing. I’ve spoken to some people this year about other ERP and CRM type systems and it appears they are all largely the same. For example: there is no way to do unit testing in Microsoft Dynamics.

SAP present their product as a suit of unified tools. This seems to be pure marketing. It seems that the system has been developed by so many different companies, teams and at different times its a miracle that any of it works together. The Microsoft and Oracle equivalents seem to be in even more divergent as these have been assembled by buying the components in.

I also learned recently that a lot of these fancy “business process” applications are actually just a series of forms on screen. People fill in forms on the screen and it gets stored in a database. Or it triggers a dispatch. Or some such. Business Process Management is often just forms and workflow. Nowhere near as exciting at as “re-engineering” or the other fancy terms that get used in this space.

For the moment I think “Business Processes” is a very a grand title for what is basically: flow charts.

Whether it is exclusive locking on a source code control systems or flow charts, I kept feeling like I was back in the 1970’s, or maybe the 1980’s. Of course, I’m too young to remember those times in IT so I may be wrong. But this is a very different world from the internet world I’m use to.

In my research, I also learned that SAP have tried Agile, specifically Scrum, internally. However corporate anti-bodies killed most of the attempts. Some infection might remain. Having seen what I saw this year I think SAP corporate culture probably can’t stand the idea of Agile in reality.

Still, my experience of using Agile on SAP projects is limited. As you can see from the list above I think there are many obstacles. I think it can be done but I think you need to go back to basics, values and principles.