Intro:
In this blog, we will explore the business need and the defining factors for a composite application for Org.A in the Architect’s world. To be built using CAF 7.0 (a far cry from the woes of CAF 2.0), xPRO needs to be justified as a logical business project for Org.A. xPRO is to be a spend management solution which will be built using CAF to include web dynpros as callable objects that will be driven by an intuitive GP-driven UI for the creation of Purchase requisitions for catalog, ad-hoc requisitions using business-specific b-forms and templatized e-forms to enable quick supplier enablement. Org.A needs the UME to be EP. Extendable to the suppliers through the EFP with components built using the light-weight framework and leveraging the use of Bex queries for reporting. xPRO would leverage the use of CCM from the mySAP SRM Suite as a standalone component on the SAP NetWeaver Application server and could use custom adapters with XI. It should enable suppliers to maintain their catalogs through the EFP and should be able to view/edit/upload only their individual catalogs as a standard feature with CCM.
Org.A has identified the business need for an optimal, scalable xAPP that would enable it to do away with its existing B.O.B Spend Management Suite without having to go the whole hog with mySAP SRM solution. A middle path that would enable it to lower TCO to 1/4th of what it is now and what it could be tomorrow, complimenting the SAP landscape at a low cost.
Suffice it to say that xPRO is not to compete with EBP/SRM, but an application that needs to be built to do away business functionality that does not find a place in Org.A’s functionality roadmap – like the use of externally hosted catalogs accessible via Punch-Out and a purchasing enabled warranting the use of P-Cards. Given the fact that not all customers would like to move away from best-of-breed applications in this space to mySAP SRM. But not all customers find their requirements fully met by either of the two. Org.A, belongs to the latter category.
What’s the big idea?
Not all organizations today are ready to move away from BOB applications and completely embrace SAP solutions where there is maximum fitment. Then again, the aim of an ESA/Solution Architect remains to define optimal business solutions that improve business efficiency by cutting costs and adopting standards. If one gets a 60%-70% fitment through a best-of-breed application and a move to its relative SAP solution offers the same or lesser, the only option of moving towards an SAP solution is more driven by an organization’s commitment towards application standardization. Nothing wrong with that. On the same token, If the application standardization objective is achieved by embracing ESA and composites and aligning with the SAP NetWeaver roadmap, why not? And so, xPRO makes sense to Org.A. And probably, to other organizations that face a similar situation. However, for organizations finding a higher degree of fitment with a counter SAP Solution, SRM in this case, it makes sense to toe the SAP AG line fully.
Exploring Org.A Internal conflicts on xPRO:
The Stand-alone thought: Typically, to push the usage of a composite leveraging CCM on Internal users of Org.A, to counter BOB Spend Management Suite and the like, who are clear about not going forward with the entire SRM solution, yet wanting to move away from the existing Spend Management Suite. So, it is ONLY CCM in a standalone environment minus the other components of SRM with a composite built around it leveraging the existing SAP landscape. If Org.A just wants a slice of SRM i.e. the CCM as a standalone installation, agreeing to be covered under the SRM licensing, would that be permitted? If yes, how would it work? (Granted that to some extent any product built around the same could be considered competitive by SAP.)
Conflicts?With CCM as a stand-alone application, Org.A is planning to just take CCM as a standalone catalogue application, do away with the need for the entire SRM solution and create buyer applications on top with delta business functionality, as well as sourcing and auction engines built using the CCM engine alone. The opinion is – xPRO – as an application built using CCM would challenge EBP (erstwhile C1) or an Ariba or any other. The fact is – Org.A can always develop its own composite applications around CCM. In some cases, it could compete directly with SAP offerings as well. And business becomes the sole driver. But the same applies in other areas as well. Like MDM, for instance.
MDM vrs. CCM for xPRO:Integrated with MDM is another conflict. MDM itself can be used as the catalogue engine. So, xCat vrs. BugsEye? Of course, the roadmap dictates it to do a lot more. But Org.A can surely use MDM as the Cataloguing tool doing away the need for a CCM as well? The choice of MDM vrs. CCM as a catalog for SRM or xPRO within Org.A would depend on different factors. MDM is another choice which would make sense when high-end master data management is required on the top of simple catalog management. CCM is tightly integrated with MDM. Why would Org.A see a business need to integrate the two of they can use MDM in place of CCM? Org.A could use MDM alone for this purpose as well. If Org.A is to replace, say, an Ariba Buyer instance from a customer’s landscape, xPRO could just do it with CCM and do away with the need of SRM altogether with CAF. And with CCM as a standalone on WAS 640 (java + ABAP), xPRO could just take the CCM solution and build custom applications around it. MDM does things that CCM does for sure. But in this context within Org.A, CCM would do things that MDM cannot with regard to supplier portal, contract compliance, operational procurement and others. And so, Org.A defines the catalogue engine for xPRO as CCM.
The middle path – Bring it on - xPRO:
The xPRO design with CAF 7.0 thoughts:
The e-Procurement process could be designed to handle two types of requisitions along with e-forms and supporting b-forms:
1. Catalog Item for items hosted internally and accessible to external suppliers for maintenance through an EFP.
2. Ad-hoc Item with b-Forms for additional information capture and at the same time preventing the procurement of contract items under contract without having to define specific contracts and maintaining the same.
3. e-Form for approvals including quick processes to be built on like travel and expense, supplier on-boarding, business cards, internal services, so on and so forth.
Sample the key processes being defined and enhanced in the following steps for Searching, Requesting, Approvals with GP or integration with ABAP Workflow or an existing approval engine or the use of GPs calling approval rules as blocks, Ordering services or items, Receiving and Settlement. In turn, each of the above can have specific pre and post conditions to be completed to proceed with the next step.
Org.A might consider to convert the approvables to Processes in a composite by defining the key steps as the Blocks, the pre and post conditions and the actual step as the Actions and custom webdynpros as callable objects calling RFCs, BAPIs and web services as external services through entity and application services finally providing a logical definition to the business processes to be orchestrated within xPRO integrated with CCM, and other SAP components in the landscape – agnostic of the fact whether Org.A has 4.6c, 4.7 or ECC 5.0.
Outro:
Best of breed applications tried to address the above space by streamlining spend across the board for MRO items. These BOB applications were loosely integrated with the core ERP applications. On one end of the spectrum you have the BOB Spend Management Suite that provides an sound solution servicing 70% of the streamlined process for e-procurement, but such best-of-breed solutions but are expensive to maintain and involve high costs of implementation and licensing with the added factor of external middleware and application servers. On the other, Org.A has with mySAP SRM – yet is not fully convinced about the same and doesn’t feel the need for all the components and the fitment still stops at 65%-70% of the business functionality. And extra not-needed functionality. The middle-path is a space for applications that keep the bells and whistles out of the application, yet, help align an organization to the SAP NetWeaver and ESA roadmap, without having to invest in either suite fully by still allowing customers to enable Org.A to tighten control over “maverick” purchasing and increase streamlined spend without the bells and whistles of a BOB application or a full SRM Suite. Or the identified need for xPRO.And Org.A has decided to make the same.
