Sorry, but we have standards!
With an unreasonably large number of heavily be-spoked complex SAP ECC systems in existence, the reputation of SAP being an ABAP’ers playground, and most clients I talk to, wishing to move back to a standard SAP solution, I’m not quite sure what SAP standard are we talking about? I can thinking withing 30 seconds a host of SLA-breaches and/or penalties for drifting away from compliance and differentiation. So, I decided to answer it tackling two fundamental questions.
- What is SAP standard in the S/4 world?
- How do I measure it?
My definition of standard is implementing the SAP core and SaaS products with as few changes to the core code as possible. Changes in interfaces, forms, light coding in pricing or configurable materials, reports largely delivered by standard tools like SAC and embedded analytics are not bespoke, since these are not ‘moves’ from standard.
I would also say that development using BTP or other Cloud Products is also fine, if well managed using standards like Capgemini’s MPSA (Multi-Pillar Strategic Architecture). The whole point of the ‘new SAP’ (S/4, RISE, BTP et al) is that the core is largely untouched, and differentiation / innovation is done in the cloud platform. SAP hasn’t spent the last decade being more open and adaptable (with for instance Fiori) for clients to not use it.
So, how do we measure the level of bespoke work? If I say we are 95% standard – what on earth do I mean and how do I measure it? It this simply a pointless, unanswerable question.
Do we count the lines of code? The number of Z Transactions? The % age of standard transactions used? These could all be meaningless and futile. What if those restricted heavily the ability to adapt the SAP solution to change (proving that even on the most bespoke of SAP solutions 95% of the transactions will be standard), or it was one single transaction that is used very infrequently and the changes are small and have little on cost of ownership and agility.
I believe we use the Level 3 process’s in SAP, multiplied by the number of times they are used and then the work out the %age of standard SAP in use. But really this is always more of a state of mind and minimising the use of bespoke code. We only minimise the complexity of what we do. Setting targets for bespoke developments – simple, medium and complex (yet a trick question could be, Yes Mr. Lowson, how would you define that) – and driving towards it with the client taking an SLA on agreed parameters would probably be the way ahead!
I am really open to ideas, let’s see if I live up to your standards ??
SAP Certified Application Professional-Financials in SAP S/4HANA 1610
3 年My simple answer, SAP standard is how best you can align its working with client's business process or how best you can re engineer client's business process to fit within SAP's standard functioning of modules!.
Vice President, Engagement Director at Capgemini
3 年Indeed an interesting topic and there are several different angles to it. One angle is of course the technical one, where modifications of standard code, Z-programs, extensions of data objects and tables is one way of measuring it (e.g number of objects on the SPAU/SPDD lists). Another angle is how the system is configured and used. A system could be clean from modifications and Z-stuff, but is used in a way that is far from optimal and misusing the way how the system is intended to be used.?
Learner working to improve and adapt to the world while assisting others
3 年Ideally, and too simplistic (back to your picture), is similar to an automotive view of "stock"... they way it left the factory... But even in an automotive analogy that idea breaks down with supercessions and other items. So parallels to the SAP world... "Stock" - but how do you define addons in S4?, I guess they could be factory config items, even if taken later than the initial implementation. We're getting more into the S4 journey and it feels like a culture change - working to what's in the software first rather than the older ECC approach you mention of "Abap playground" to resolve anything that isn't liked. Perhaps it is the process approach. But then on implementation getting business agreement on a standard process verses their view of their best practice can still bring challenges. Looking forward to how this post proceeds, and hoping perhaps this feedback/view makes it into an SAP infosession somewhere ??
Empowers procurement to be outstanding
3 年It is the same as in the world of ECC. The IMG in S/4 is pretty much identical to ECC with the same customization possibilities and similar Exits/BADIs.
Theologian / Stand-up Comedian / Baker of exquisite Sausage Rolls / Occasional IT Consultant
3 年The only people that think businesses are largely the same are those who don't understand details. Typically these are people who work at a powerpoint level where the entire order to cash process is a few rectangles on a slide with some lines which may or may not be going in the right direction if it is the "happy flow". People have 10 fingers and toes ipso facto we are all standard. Reality is much neater if you ignore all the details. Strangely, there's more money in dealing with reality than selling fantasy, but it takes more effort to be frank that might not be so appealing in a sales position.