Intro:
This 2-part blog series will focus on helping a BPX/ESA Architect create a business case for a composite, arrive at a logical solution that would help one replace a non-SAP solution from the system landscape. Here, we will use iPRO (the procurement composite defined on SDN), as the base.
BPX: Creating a business case for a Composite Application:
The SAP Netweaver Composition platform will find most use in reverse-engineering business processes delivered through existing applications, if value for customers becomes prime. The approach with xApps that will define industry value will be best driven by pre-defined processes, retrofitted from best-of-breed, custom or legacy applications that may be rendered as "white-spaces" to provide an SAP solution to fit the ever-increasing SAP landscape, instead of creating small applications (light-weights) that bring about academic value, rather than delivering true business benefits. Such an approach would only help SAP customers build composite applications on top of their existing landscape using the SAP Composition platform to address the retiral of custom, best-of-breed and third party applications within the system Landscape, addressing Industry-specific business needs. More to be designed as a safe passage from such archaic applications, reverse engineering would only provide a novel option to business needs and lower TCO. Not to mention embracing and testing the value promised by enterprise services. Such a move will bring about the accentuated useage of the ESR, bring about the value of PI (instead ofjust a blind comparison of the same with other EAI tools) and apply them for practical useage. Creating light weight xApps (barring out xApp Analytics), or creating composites on to of composites would be more of a technological showcase than any value delivered. Having been dealing with a string of customers through the ESA workshops, the perceived value with "reverese-engineered" applications is the highest. How do you snuff out an i2 without APO? Ariba without SRM? A shopfloor execution system without enhancing xMII? An HCM application that provides you an 80% process compliance? A spare part management system that does away with your existing one, yet stays on in a better way? A financial reconciliation application?.....the possibilities are limitless. And how does one plan this out to create a business case and value differentiation by making this a reality? These are some of the questions that one constantly grapples with and I try to put these forth in this episode of the Architect's World.
Step 1: Analyze the Cost Imbalance:
A best-of breed application for e-procurment needs has been a norm in most of the SAP installations. Typically, these implementations have a huge financial impact. Breaking down the initiative into logical chinks of cost, a typical bob implementation would be as you see here – An initial outlay for License costs, Infrastructure costs, business consulting costs, FTE costs, travel & logistics costs and the implementation costs amount to a whopping $12 mio initial outlay. Annualized costs for supplier on-boarding, enhancements, stabilizing, user training and consulting costs add an additional USD 1 mio, Upgrade costs and additional module costs add up another million. Add to it the annual license costs, support & trouble shooting costs, patching major gaps as new product add-on costs have another million USD added up. Assume a payback time of 3 years from initiative start, you have the promise of a $ 5 mio USD per annum incremental that would help you lower TCO. Now compare this to the real world: By the time you get the payback, you have spent more than USD 15 mio on the initiative and incurring the annual support costs. By the time, the best-of-breed application starts to truly lower TCO, the technology would have changed rendering this application requiring more investments, the organizational direction would have changed, so on and so forth. Bottomline – The idea for an e-procurement application was a great one, but the realities of implementaing such a solution never got you to the promised land. The benefits are far out-weighed by the costs. You managed to streamline the costs alright, but the costs just went up. There is a big imbalance. If you were to apply the same logic to any of your 3rd party, best of breed, custom or legact application, you will note that you can find this approach as a good starting point for your approach towards creating a biz case for the retiral of such an application.
Gather the rough-cut costs for all phases of implementation @ today's cost and analyze in logical chunks as below:.
Step 2: Analyze the Business Process that you set out to address:
Now, this is what you originally set out to do. With the best-of application implemented, one would note that the standard package only addressed 40%-60% of a business fit. The arrows in red in the diagram below would indicate the problem areas that would have remained to be sealed by investing in an SI for Implementation. Leading to heavy customizations. Areas such as Approval rules configuration, Ordering, Integration with R/3 for PO processing, PO matching, Change Orders and Invoicing are much known in the e-procurement community and these are issues that need to be tacked on a daily basis. Areas such as contracts, budgeting, Supplier NetWork, Invoicing, category Management and sourcing – A new product for every area that is a problem point, definitely, there must be a better way of doing business at a lower cost. There has to be a better way with the NetWeaver Composition Platform route if you can achieve a greater fitment of the business process within your organization with this approach. Such an analysis only provides you a base to create a case for a "reverse-engineered composite".
Note the issues below:
Step 3: Analyze the TCO:
Take for instance, an industry average breakup of MRO spend for a manufacturing organization as shown in the picture below. You will note that the spend has been broken down in categories, and streamlized to reduce maverick buying. Now, take an aggregation of all the red arrows from the picture above and bucket them in the TCO spend as below. The biggest spend category after the “real” spend on product and service purchase is the ugly red slice of the pie accounting for 20%-30% of the total spend. This spend primarily consists of license costs, Implementation and support costs, upgrade and additional license costs, new bolt-on product license and thie r implementation/support costs. So, At the highest level of abstraction, one can safely conclude that an e-procurement application is a must to lower the TCO, but the costs can truly be lowered if you replace/retire your best-of-breed application from your SAP landscape. Certainly, one would presume a catalog spend of this organization more streamlined through catalogs (above 50%) and therefore you are in a better position to track this spend. One inference from this - the organization needs an e-procurement application to reduce maverick buying as seen above, but, is this the right way?
Step 4: Analyze the Potential Savings:
Now, let us analyze the potential areas of savings for the same. Analyze the ugly red slice from the previous image and this is what you get below. Note the heavy potential of savings that you can get if you reduce your IT spend. An inference that can be from this pie is – reduce costs by assembling your services and building composites over your existing SAP Landscape to create true business solutions. Application functionality @ what cost? So, wouldn't an application that would be "reverse-engineered" from the existing solution, enhanced and customized per the organization's requirement, created as an xApp and replicated across the board make sense? In a way, this referes to the classical debate of build vrs. buy, but we are talking assembly and composition here, not in the semantic sense alone, but with an eye of making this an xApp bringing forth heavy use and orchestration of services (Enterprise services from SPS9), if it truly addresses a unique space and defined as a partner composite? Or even if it refers to a competing solution from SAP, what would take precedence is the business value - not the approach alone.
Step 5: Analyze & Monetize the Systemic Issues:
Presume it is a best-pf-breed e-procurment application that you use within your organization for your MRO needs, here are some sample issues that you have given you sleepless nights:
a. Doesn’t align with our ESA Roadmap – Why shoul I have TIBCO in my landscape when I want to move with XI? Or Analytics when I have BI?
b. Too many frills and way too expensive – PunchOuts, P-Cards or other functionality that may not be required in your organization – why pay for it when you don’t need it? Competing solutions are me-too – maybe it’s a solution from SAP which falls under the same trap, think about it.
c. A product for every loophole? Analytics, Invoicing, Category management………….Why cant they have one integrated solution for all my needs?
d. Doesn’t fit the SAP landscape – vendor choice with SAP is given but the direction seems unclear & confusing at times - requisite or CCM? CCM or MDM?
e. So, where do the choices lead toward – A composite application that can be built fast to your custom needs that can help you align with your ESA vision and do away with the existing BOB application, maybe even not contemplating an SAP solution for some.
Step 6: Do the Logical map of the Required process:
This is the eProcurement process from the different iPRO roles perspective. X-Axis takes processes. Y-axis covers the roles. For the Requisition the user logs in with the requestor credentials, creates the Requisition using guided procedures which allows him to carry out different activities as browsing the catalog from MDM, fetching the data fro R/3, capturing requisition data and creates the requisition in R/3 using the composite Guided procedures which will take the user in a wizard route and without revealing the different back end functionalities used. All concerned are notified and the Approver can check the pending Approvals and can take action on the requisition to Approve or deny. The buyer can consolidate the requisitions against the supplier or commodity and raise the order in the R/3. And finally the receiving and invoicing activities carried out to complete the procurement cycle. All these could be completed in as low as 6 min of time. So, defining your process requirements vrs. the roles that execute them is a good starting point to map your process requirements on paper. ARIS process mapping and other means can follow. A white-boarding approach always helps.
Step 7: Do the Application functionality mapping:
This gives the high level process layer view on the Guided procedures followed in iPRO for a Catalog item Request. This has key process steps-Request, Approve, Order, Receive and Settle. And details in terms composite application what happens where and how. For example when a Requestor logs in to the iPRO, he can browse the catalog, carry out accounting, shipping activities and raise a Requisition will create PR at the back end R/3 and based on the requisition parameters and Approval rule will take through an Approval process before creating a PO. So, the approach that you can choose to define the mapping of the broad level activities in blocks that will help you define the application parameters.
Step 8: Do the product mapping:
This is the high level iPRO architecture. iPRO runs on CAF 7.0 SPS 7 on NW 2004s Ep server and connects to SAP R/3 4.6c , MDM 5.5 for the Catalog hosting and BI 3.5 for the Reporting. The iPRO core is deployed on to WAS 7.0. SAP XI was planned as optional but not used in this version of iPRO.
Step 9: Plan/Map the UI & the flow:
A very important activity here is to design the screen layout. What could help here, as a part of our reeingineering exercise is to replicate and better the existing screens being used as is. Increase the usability (instead of applying too much creativity!) and provide the users with similar screens of the past in a new way. it certainly helps.
The GR/IR screes of iPRO as below:
and an electrinic form for supplier creation process as below:
Now, when you plan your composite, this approach could be a helpful starting point. take the desired functionality, break it into pieces as a BPX, wear he hat of an ESA Architect, map on the components on top of the desired process, orchestrate the broad level process within this framework, give it a catchy name (preferably a 3-letter acronym, and you got yourself a new job as an Analyst!
...To be continued...
