Skip to Content

Intro:

Conceptualize an xAPP in the Architect’s world for Org.A – xPRO. The state that Org.A is in today goes something like this – Year 1999, when the world was smitten by the B2B bug, Org.A decided to venture towards a best-of-breed spend management solution. The promise of the land was a reduction in total operational cost of over 27% by streamlining purchasing across the organization with an application aimed to do just that. Slight hitch, this would just add up to the clutter of the existing landscape along with an added middleware component. But, who really cared? As long as you were associated with the spend-management community that swore by this BOB application and the related suite that promised the world of externally hosted catalogs – whether you dealt with a Boise cascade, Grainger, Corporate express or the like. Suppliers were eager to get themselves enabled to ensure that they swore allegiance to this buying community. And the phenomenal usage of a supplier/commerce network that could seamlessly get across your purchase orders to the suppliers via EDI, xml or fax was the icing on the cake.

A case for xPRO:

There were just a few hiccups and bumps that came by. Suffice it to say, Org. A didn’t really manage to cut costs the way it was promised. Not the fault of the BOB application, though. For instance, it found it really difficult to reduce ad-hoc spend through non-catalog items because there was no way to prevent the users from creating ad-hoc requisitions just to hasten up the PR creating process by searching huge catalogs that took ages to look for the item that needed to be bought. The promise was to reduce the time to create a requisition to less than six minutes and bring down the average cost of a purchase requisition to three dollars. Wow. So, the BOB vendor came up with a contracting module that would prevent users to create ad-hoc requisitions for items that were under contract. Sheer genius! But this added up the cost for Org.A again and cluttered up the landscape even further and increased the stickiness on the BOB application.

The landscape soon boasted of a myriad of applications that managed operational procurement, analysis, category management, sourcing, the use of a supplier network, so on and so forth and Org.A had do rip down its marketplace and exchange owing to the B2B bust. So, all that was left was the spend management suite and now Org.A plans to move away from this BOB spend management suite towards the world of SAP and NetWeaver for many reasons. Primary being – the promised cost reduction was not huge, the spend being channeled through this BOB suite was miniscule and whatever spend was being tracked and costs being saved was efficiently being nullified by the licensing costs, maintenance costs and the added headaches associated with the same that now makes the proposition totally useless.

Org.A’s dilemma:

If Org.A has to move away from the BOB spend management suite towards the SRM suite, will the problems be resolved? Will the spend come down? Will the TCO be reduced? Would the effort and investment associated with this move justify the business reason for the very existence of the BOB? Is the move warranted ASAP? Can the BOB application be allowed a future in Org.A’s landscape just so Org.A can push this problem for a few more years? What if – the BOB vendor certified his spend management suite on the SAP NetWeaver platform (which, incidentally, is on) it adds to the mess further to make the decisions more difficult for Org.A?

Simply put – Is there a middle path that could get the best of both worlds and be at ¼ the cost and seamlessly adopt to the ESA roadmap that Org.A has in mind? Enter xPRO.

Exploring xPRO in the Architect’s world:

Defining/designing xPRO:

xPRO would be a web-based e-Procurement tool that needs to facilitate, integrate and streamline the entire procurement process from consumer to supplier and back for Org.A. Built as an xAPP using the SAP NetWeaver platform, xPRO is to be a scalable e-procurement solution that will help companies replace best-of-breed applications aligned with Org.A’s ESA roadmap. With a powerful intuitive workflow solution (optional component) certified by SAP, xPro would you with an alternative to do away with expensive best-of-breed applications and leveraging mySAP SRM components to lower TCO with the SAP NetWeaver platform, aligned with Org.A’s ESA roadmap. Not as a competition of SRM, but leveraging components of SRM to lower TCO and doing away with BOB – yet aligning perfectly well with Org.A’s ESA roadmap.

image

Once xPRO is to be deployed at Org.A, would there be an easy way to “upgrade” to mySAP SRM? Would that be required at all? Or would it compete with an SRM solution?

First, Org.A is not interested in the entire SRM solution. CCM alone would suffice and solve the purpose from the suite standpoint. So, it becomes an enabler and doesn’t compete with SAP offerings. On the same token, any application that would qualify as an xAPP is bound to have some friction with the existing functionality provided by SAP in one space or the other. But, that should be the very fundamental of an xAPP. Just like a BOB application – the functionality met by the solution would take a match of 70% and there is still a delta functionality of 30%. If an xAPP could be tuned seamlessly to achieve a greater degree of fit for Org.A, what could be a better solution? And if the bells and whistles are to be left out – why not use that as a business driver to lower costs? Second, Once xPro is deployed in Org.A – it becomes only easier to upgrade as the underlying use is to be enables via enterprise services created through R/3 or any system using WAS 6.40 or above – as the case is with MySAP SRM. Third, If Org.A would prefer to step-up to SRM – they could do that, if they wouldn’t want to do that and are happy with xPro – they would still would have upgraded onto the NetWeaver platform. The question clearly comes down to – how to leverage individual components of SRM to build a custom code-free solution that would only align with Org.A’s ESA roadmap in the future. Only one objective – retire the best-of-breed spend management solution.

Once xPRO is ready will it be a plug and run solution or it will require heavy customizations?

In the Architect’s world – xPRO is being built using CAF 7.0, the application would only ask for configuration and not customization. It would be built using a lightweight framework for external facing portals for external partners and the use of webdynpros using CAF. So, there is not customization involved. Top it – this would be implemented in Org.A with sample data in terms of master data – user/catalog/approval rules to provide a templatized approach to an implementation.

Why would Org.A prefer this solution to move away from BOB spend management suite and then going with SRM or is that a logical step at all?

First, Org.A prefers hosting internal catalogs and not externally hosted. However, the catalog management needs to be done by the supplier. xPRO would refrain from addressing functionality like “round-trip/punch-out” as in a BOB or for that matter SRM/EBP (which can also use the BOB supplier network). Second, since the business process of MRO spend in Org.A is routed via P-Cards – a process not requested within Org.A, there would be no need to address that. If Org.A sees the benefit of such functionality to reduce their maverick spend behaviour – the logical extension of such a solution would only be an SRM solution. Therefore, a “stepping-stone” approach could also be possible – especially for a BOB application that is shrouded by skepticism in the business community.

Would xPRO lower TCO for Org.A and be a cheaper alternative ?

Take a hypothetical example of an xAPP which could roughly cost USD 8 mio to buy a set of licenses, USD 2 mio to implement and ongoing cost of support totaling USD 12 mio. xPro (all stages) would end up at 1/4 the cost. So, yes, it would be a lot more cost effective for Org.A. Top it all – all the xAPP would do is to be a base container for enterprise services, use BEx queries for reporting, have algorithms build in to process advanced industry specific logic above than a standard solution, come with a set of business packages as a packaged application, certified by SAP. High probability – it would encapsulate a third party application or come with specific adapters to talk to a third party application. That’s the technical build part of it. But in a broader context , it is the increased business efficiency and cost reduction that would make the difference to an Organization like Org.A, which would require industry specific business content. Another way to look at it could be – it is the future of customization in a code-free world. Anywhich ways one looks at it, the cost differential would be huge. So, xPRO makes sense to Org.A

How easy would it be for Org.A to implement xPRO?

Since the deployment of an xApp is primarily to be on the SAP NetWeaver application server (Phew! The new name certainly takes a longer time to type!) with CAF and GP, it is a matter of deploying the application through SDM on WAS. Second, the BEx queries would be canned out-of-the-box for reuse. Third, the approval rules built with GP will be reusable as there would be a canned set of advanced rules to tweak. The roles and iViews would be canned based on the roles. It only a matter of duplication and tweaking as one would do with standard business packages. Even if an added component as a Powered by NetWeaver application for advanced workflow were to be brought in, it is a matter of deployment and leveraging the application services of the said application to get this up. So, it would be easier for Org.A to implement xPRO and retire the BOB application.

Outro:

Today, Org.A swears by BOB applications in this space, and most have agreed to go the SAP way, doesn’t mean that they are fully convinced about capabilities of the particular solution offering. If you break it down into pieces and for example, look at CCM as an integrated application via xPro – it would only help customers like Org.A. On one hand, you have customers who would be on the BOB applications, in the SAP landscape wanting to do away with BOM and related middleware. They have no choice but to go the Sap way, they would try to delay their SRM adoption for 3-4 years. An xPro solution would expedite the move towards SRM or at least do away with BOB and help customers find a middle path. On the other, you have customers who are on BOB, need that push towards a solution that may not warrant the use of all the components. Or – a customer requirement specifc operational e-procurement composite and a sourcing engine from SAP. And so, xPRO is being built in the Architect’s world.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply