Intro:
Fresh out of a spate of ESA workshops (eight, to be pricise), there is a lot of knowledge out there that is just waiting to be tapped and channelized towards an ESA roadmap. It is the return of ideas with ESA and the SAP NetWeaver platform when you take the Solution Architect paradigm. We never had it better. More and more initiatives being planned around with Enterprise Portals, Business Intelligence and Exchange Infrastructure with the existing SAP customers, corporate interest in these technologies continues to grow. But most of these POC-driven projects struggle to find a reason to exist. The reason for the same is the growing confusion among IT Organizations and corporate, who invariably tend to believe that the sole existence of the SAP NetWeaver platform is to use SOA for enabling all business processes. This is something that I stumbled upon in the host of ESA Workshops I am in the midst of (8, to be precise, over a period of 20 days). The fact is, the choice of processes and sub-processes, that organizations need to identify and map out to see where the fitment for ESA exists. Trying to fit in enterprise services all over the board may not be a wise move. Corporate IT groups struggle to find meanings to the same, having approached the SAP NetWeaver platform from a product-based paradigm, an ESA-enabling approach and finding it now difficult to get the concept sold to the Business users and project sponsors. Loose alignment with business goals & high-visibility projects, soft budget justification, coupled with an array of choices spell doom for this direction-less projects which seem to be verging on ESA alone from an IT standpoint. I would, needless to say, have to conceal the finer details owing to confidentiality. I terms this approach as the Core-Build approach.</>
Having missed the overall picture of benefits and planning out initiatives around the same, such projects threaten to pigeon-hole the SAP NetWeaver initiatives as pure esoteric and learning initiatives for the internal POC teams and exploring ESA. In this multi-part blog series of “The Architect’s World”, I will cover multiple processes, tackle each one of these processes from a NetWeaver standpoint and from an ESA initiative standpoint - with the following six goals:
1. How to leverage the SAP NetWeaver platform to enhance business processes
2. How to utilize the same to do away with best of breed applications
3. How to retain key home-grown applications, yet align with the ESA roadmap
4. How to consolidate business processes and applications to enhance productivity
5. Approaches to make the best use to carve an ESA roadmap for the years to come for an organization
6. Mainly, to explore new ideas
Idea #1:
Process #1: The Order-to-Cash process:
Platform Approach #1: The mySAP ERP Core Build approach with SAP NetWeaver:
Org. A is an organization which decided to tackle its core Order management engine, which was spread across various aplications, primarily being handled in core R/3. The overall direction of the organization is to migrate all applications onto the SAP Business Suite post instance consolidations. The primary objective being to retire third-party applications, best of breed applications and existing middleware, the immediate objective was to streamline the processes in line with core R/3. It doesn't matter if the same is to rendered as a standard business process from R/3, what matters the most is to create a scalable architecture in tune with the roadmap to create placeholders or identify candidates in its key processes which may necessitate the need for enterprise services in the future. With this approach, the end objectices to be achived hold a clear-cut definition and meaning. To retire applications that act as sender or receiver systems to various parts of the Order-to-cash cycle, it needs to be determined as to whether ESA makes sense over here or a B2B or an A2A approach with XI makes sense in the short/long term perspective. The idea was clear - let SAP come up with the enterpirse services and Org.A proceeds with the consolidation exercise. If SAP delivered enterprise services make sense, or would it be prudent to create custom web or enterprise services for Org.A to consume to streamline its supply chain. That is what we termed as the "Core-build" approach for Org.A as part of their ESA roadmap spanning five years. having a uniform interface for the internal portal and creating light-weight components for the external facing portal clearly aligned the logic to proceed with a roadmap that made sense to Org.A.
Potential ESA Candidates:
This step entailed the break-up of key steps using ARIS for creating the business maps with the same being broken down to granular levels at XI from an operational standpoint. What this helps Org.A achieve is to involve the business users in the process mapping and guiding them in identifying areas that fall beyond the purview of classical ERP. Having achieved the same, the IT marriage happens by creating the business need for Solultion manager and XI. This directly impacts the decision of replacing its existing middleware application - except that now XI does not get evaluated as an EAI tool directly with the other products in existance. The immediate start-point being VA01, with an example understood pretty well by all folks alike, this fits in snugly as the sample ESA candidate for Org.A. What is currently the engine for all orders coming in by EDA with gentran, faxcimile orders and direct orders - all being handled by Customer service agents who have to log into multiple application to verify details before creating the orders manually or by directly importing orders into R/3 and putting them on hold - now gets a definitive direction as a justifiable candidate for ESA or the usage of XI in tune with the future direction or the continued useage of other products to act as interim placeholders for future ESA candidates directly influencing the retiral of other applications. Then again - the ESA Architect decides multiple options for the identified Enterprise service candidate.
The other candidate emerges while creating the schedule lines for the goods if they are not part of the finished goods stock. Blocking of stock by DOs has been causing a lot of heartburn within variuos pockets of Org.A, primarily impacted by seasonal variations in demand. This becomes another candidate for ESA - if the stock check is to happen not only within Org.A's group offices and warehouses, but if it has to extend to various 3PL providers whom Org.A has been using to reduce cycle time of delivery to the customers. The nature of business being plagued by obsolescence, it makes sense here. Then again, a lot of business and IT folks tend to get confused and use the two terms intermittently - enterprise or web services. This demands a lot of focussed discussions always.
Similarly, the same metrics could be applied to other candidate areas, such as invoice processing and payment handling as well. It is the logical definition of the business process that shapes and makes this exercise useful.
Outro:
It is amazing that the simplest of fundamentals the IT fraternity takes for granted is so lost or twisted by the business community that demands corporate IT groups to introspect. Here, in Org.A, the interpretation of the SAP NetWeaver platform and the direction with ESA was way out of line. Projects were delving between ridiculous to sublime - with absolutely no practical deliverance to the business users. Such a workshop got people from various groups together in the room, who are to supposedly work towards the same common objective, but have never had a chance to interact. It certainly left me a lot wiser. Bottomline - as the first idea - which we call the core build approach, we set the context as Order to cash business process and objective to define the SAP NetWeaver and ESA roadmap to justify the choice of technology enablement. We will explore other ideas in subsequent blogs. You comments and feedback would be greatly appreciated.
