Prologue:
Defining an ESA roadmap is the current challenge of many Organizations. The hurried approach in creating an ESA roadmap without the client having being in a position to appreciate the pieces of the large jigsaw puzzle called SAP NetWeaver has many System Integrators and Consulting firms adopt an incremental approach to ESA without first thinking through the larger architectural issues. ESA is not to be viewed from a technology perspective alone, it has to be merged with the SAP NetWeaver initiatives with an organization that would ultimately determine the path an organization needs to take in the future – a fact that I was exposed to last week when I had a meeting with customer who was struggling to put together an ESA roadmap. Hit hard by overzealous salesmen trying to extract license revenue and by others looking at pieces of projects as a stream of revenue, the Solution piece took a backseat. In this blog, I will explore three approaches using the SAP NetWeaver platform that I took with this client to ensure that an ESA roadmap is a result of his immediate concerns and the approach that Org. A needs to take with the SAP NetWeaver platform.Option 1 - The Rip-and-replace approach:
ORGA has invested in a best of breed pure-play e-procurement application for Spend management. This was primarily a move way back in 1999, when such applications ruled the roost. Spend Management coming on the radar with huge investments in best of breed applications to streamline MRO spending and track spend on such items in a categorized fashion to negotiate better rates with the suppliers. The MRO spend through such the application in Org. A remains high, but the unfortunately, the spend on catalog items remains low with most of the requisitions still on the non-catalog zone. Punch-Out suppliers didn’t really take off for Org. A and most of the catalogs are maintained by Org. A internally with pre-negotiated rates for the suppliers today. Rather, the spend seems to have gone up on the license front for this pure play application player, who no doubt provides one of the best e-procurement solutions, but the unruly spend within Org. A does not justify its presence. With not enough spend being routed through the application to justify the continuity of the application within ORGA. And Punch-out/Round-trip supplier spend being minimal through these, this application can be done away with a custom application using the SAP NetWeaver Platform.Consider the diagram below where the yellow boxes denote process chinks in the areas – these either mean that the functionality provided by the best of breed application vendor is not used to a great extent or it calls for process chain is incomplete with the best of breed application itself. Example – Purchase orders remaining open despite payments being made, something that the solution may not address automatically without Org.A investing in additional modules of the product (means more spend!)
The same can be extended to the use of XI 3.0 with a POC to replace SeeBeyond or Webmethods in an organization that has decided to call itself an SAP shop is willing to become one. Extend the same logic from a Plumtree (erstwhile) to Enterprise portal by also taking on LiveLink on collaboration and BroadVision or interwoven (based on actual usage of personalization, content management and workflow within).
Option 2 - SAP Core-Build Approach:
Despite the heavy usage of the SD module within Org. A today, certain areas of the process chain have to be processed externally outside of the SAP system today, Org. A has the options of continuing with such legacy applications and create a technically brilliant solution by creating true interoperability between the applications leveraging the SAP NetWeaver platform and ESA, or, do a process consolidation activity to retire these sunset or legacy applications from Org. A’s landscape and bring all processes onto the SAP business suite. As anyways SAP forms the core backbone application within Org. A, it may make sense for them to consolidate such business processes onto core R/3 and let SAP do the job of making the SAP objects ESA compliant. And that, in my opinion, is the true definition of lower TCO, as organizations today seem to fall prey to esoteric solutions being put forth by system integrators that demand higher maintenance and only assist in creating more dinosaurs.Per the diagram below, in the order to cash scenario within Org.A, retiring applications that may increase process workarounds lay more flexibility to the roadmap with ESA, some of which may be dealt with customizations at the R/3 layer. Sometimes, customizations may actually make more sense. Isn’t xApps the changing paradigm of customizations and extended custom applications in the future? Unless controlled, they may become the problems of the future with the ESA roadmap.
Option 3 - The xApps Approach:
As discussed in one of my earlier blogs, some of the clients I meet seem to tilt more towards best-of-breed application providers, which help in making the landscape seemingly more complex and inflexible. An approach with ESA could be to either convert all the custom objects of the extended customized application and creating a xApps in itself, an approach that SAP has taken on with ISVs today. Instead of building and extending such solutions for niche areas in areas which may not make too much business sense for the, the open approach with PBNW and other such initiatives is the right way forward to address niche areas. Org.A, with customizations around the shop floor execution system and preventive plant maintenance systems, have now built huge dinosaurs that demand constant attention in terms of maintenance and development to make it interoperable in certain process areas.
Epilogue:
Org. A needs to think through the SAP NetWeaver initiatives today to ensure that the approach it takes with the core ERP and other applications in the labdscape are aligned towards the ESA roadmap. The road ahead with the ESA roadmap will pose many challenges. And options. The options that exist with any approach with the SAP NetWeaver platform will be many. It defines the role of an ESA architect and has a direct impact on the road ahead with ESA for Org. A. An ESA roadmap has to be the blueprint for how an organization will use web services to enable interoperability between a myriad of systems agnostic of hardware, platform, language and o/s. Such a blueprint cannot be formulated in isolation as an esoteric ESA exercise, but has to encompass the reality of the applications that exist today in the landscape and what approach needs to be taken in which case - A rip-and-replace, a business process consolidation or an xApp route. Nailing this down will help Org. A plan to increase the efficiency of its current landscape itself, leave aside the ESA roadmap.
