Being a Platform vendor is a double-edged sword. In this blog, let us try to evaluate the emergence of CAF to leverage the SAP NetWeaver platform to do away with Best-of-breed solutions as well as avoiding a move towards a “soft” solution from SAP. Bad for SAP from a myopic BU perspective, good for SAP from a larger perspective. Anyways, good for the customers either-ways who are wedded to an “SAP-only” landscape approach.
Typically, an effective e-procurement system would allow for the following:
–>Centralized control of contracts, product data, catalogs and price updates for indirect procurement
–>Implementation and maintenance of specific rules that govern procurement
–>Increased use of strategic suppliers
–>Diminished use of localized ordering
–>Diminished exchange of orders or pricing information with suppliers via phone and fax
–>Greater Integration with the existing system landscape
–>Increased rigor in authorization processes
–>Changes in receiving practices
–>Greater visibility of individual and unit spending
–>Realignment of roles and responsibilities
–>Change of buyer roles from administration to strategic sourcing in the future
–>Streamlined operational spend through catalog items, reduces maverick buying behavior
–> Externally hosted catalogs made available through Punch-Outs/Round-trips
–> P-Card driven spend
–> Usage of a Supplier NetWork
Note: This would differ from organization to organization, the above categorization is for conservative Organizations who would avoid increased spend on their Spend management system licenses/development/maintenance costs to be routed through a spend management system itself!
Five reasons – why Ariba users are unimpressed by SRM:
Reason #1: Is there a consistency of approach on the Catalogue Management Engine front at all?
Reason #2: What if CCM is given way to MDM, talks are on for integration between CCM & MDM, doesnt make too much sense
Reason #3: SSN a “follow-me” approach with ASN? Especially when it was declared that ASN will be supported?
Reason #4: We had evaluated ASC and C1. Ariba scored the brownie points, why revisit the same?
Reason #5: There is no cost benefit when I move from one BOB to another, without a strong business case
Five reasons – Why SRM users are unimpressed by Ariba:
Reason #1: Need to get off Ariba Buyer, but SRM doesnt really excite
Reason #2: Punch-Outs & P-Cards are an over-kill for us ASN may not be globally adopted
Reason #3: Do I need a product for every business requirement?
Reason #4: Big challenge with change orders
Reason #5: Custom Integration events, custom UI, custom PS Integration. Custom Ariba Buyer?
Five reasons – Why xPRO could make Org.A do without both – Ariba & SRM:
Reason #1: Helps build a true composite with CAF 7.o, aligns with the SAP ESA roadmap
Reason #2: Adheres to Operations only, strategic procurement can be done later with the same approach
Reason #3: Strategically align the landscape applications – EP/WAS/XI/MDM/BI/CAF and lay the groundwork for more composites instead of investing in a new-dimension BOB
Reason #4: Individual products scale, xPRO scales
Reason #5: Feasible at 1/4th the cost of ASN or SRM
xPRO as a stepping stone to a Sourcing solution:
With operational procurement being commoditized and huge investments, Org.A could choose to move away from its Ariba Spend management Suite and use xPRO as a stepping stone to the Sourcing solution as part of the SRM Suite – still driving costs lower. This approach would make financial and business sense, no doubt, as well as leaving the rest to the best in class applications to drive through a strategic sourcing solution. This approach would clearly help Org.A differentiate its Operational, Tactical and Strategic goals to make the right investments. I would term this the “Stepping stone” approach.
The CAF Concept:
The separation between the design time and the run-time is the similar architecture that one gets to see in XI. Quick definitions of the layers is probably the best thing to do with the Services Modeler integrated into the NWDS as the CAS perspective. With the UI modeler as a web dynpro based application where one defines the UI patters to be developed entities and the GP process modeler finally knits it all together with business logic. Only the Service modeler generates the java code and the UI and process modeler generating metadata on the design time finally to be consumed by the GP runtime. Webdynpros, being used for the UI patters, the choice is unto Org.A to see what to use from CAF based on its existing skill-set. For it is a choice to see – all the external services can that be used with a plain web dynpro to be used on to of it or have it as a servlet based application that can be used to consume from the persistence, or a mix of UI patters and web dynpro applications depending on the scenario to be built or the performance that needs to be rendered. The same is true for GP. The choice as to use GP as stand-alone without the CAF core or with the CAF core. The choices would vary from situation to situation.
The Entity Services modeler provides to model the objects that can be locally persisted or modeled against remotely persisted objects to be finally generating these entities to be shielded by the Application services as a level of abstraction. Once the objects are in place, one could create the business logic on top of these entity services with the help of the Application service modeler thereby shielding the entity services.
Guided procedures, meant to model and manage business processes to drive collaborative processes across roles and responsibilities being reflected through the UWL, the additional usage of Adobe forms to translate the same virtually to retain training costs covered within GP through callable objects would only be an additional choice. Having a set of functions enabling business experts to model processes and create reusable components through the GP design time leading to more detailed elements created to execute external applications and services within the GP framework is the job of the callable objects, which can be attached to actions representing process/sub-process steps during runtime executed in blocks either sequentially, parallel or in a loop.
With the design time supporting the definition of data persistency between the process steps to be executed as actions within a block, the mapping of parameters as an output of one action to be provided for as an input to the next action with added details, if needed from an RFC or another external service, the data context becomes the key factor in the process execution within the block as part of the overall process. The same again renders itself for reuse within different business scenarios to be used as a sub-process as part of another business process – considering a process being constituted of several blocks (which now becomes a best practice of sorts for Org.A). To ensure that the data gets transferred from step to step within the process to be saved by the service via the context to be executed by different roles as part of the process once they are notified based on process execution. The GP roles would allow the assignment of specific actions to a specific user so that a process executor acts when a work item appears in his work list based on the role that one performs as part of the process. These roles would later lead to specific business packages as part of the composite being defined.
Mapping the CAF Concept to xPRO:
Lets apply the logic above to meet the ground realities of business as below – a sample scenario from xPRO, where one looks at a catalog purchase:
Step 1: Requestor logs in to Enterprise portal to access xPRO functionality by providing the user credentials leveraging SSO of EP using LDAP authentication (If need be and aligning with the portal strategy with no fear or variants and partitions and monitor through WAS as any other composite application)
Step 2: Gets a simple intuitive UI to browse/select Create Requisition Catalog Item (Using MDM 5.5 as a cataloguing tool)
Step 3: Search for catalog items from MDM 5.5 and add items (and be refused to create Ad-hoc requisitions is supplier is a catalog commodity supplier)
Step 4: Add/change Accounting details for requisition or by line item. Split accounting possible per line item
Add Shipping Details for requisition or by line item. Scalable to Integration with PS if its already implemented for Capital purchases (can leverage existing Ariba Buyer development for the same)
Step 5: Add comments for requisition or by line item (Store as header text and not worry about Integration events failing) View the Approval flow for the current requisition which is being created. This is chosen of the approval rule which is based on the requestor dollar limit or on on behalf of requisition (Standard templates built in the ME along with templatized UM data)
Step 6: Guide through – procedurally to summary of the requisition being created. The requestor can also directly come to this screen to enter the details. Submits the requisition. PR is created in the back end R/3. The approver and subsequent approvers in the approval flow will approve or reject the requisition. If the requisition is not approved (denied or changed in a manner that affects the total dollar amount, an email is sent to the originator. User will either edit the requisition and resubmit, or withdraw it. (The same approvable logic applies for all other approvables with a standard templatized set of actions and blocks for re-use)
If the requisition is approved, it is converted to an order (or orders), with the terms and conditions embedded, and sent via the vendors preferred transmission to the vendor (With the logic as exists in your R/3 engine, no changes required).
Suffice it to say, the shortcomings of both Ariba Spend Management Suite and SRM have been covered here. Extended, if need be, scalable, if need be. And, of course, reusable, if need be. Lowering TCO and providing a business case?
The X-tended xPRO Playground:
Add to it a custom Powered By NetWeaver Application like “Flow-Brix”, in the same, as an optional component for advanced workflow, or any other, if the business needs more scalability in the Workflow engine. This rounds-up the xAPP. Of course, what is not being discussed are the other capabilities that are possible within xPRO, but the bottom line is clear – If business processes being driven within organizations are of a nature that demands customizations to a certain extent, there is an approach that Org.A can take leveraging CAF and GP. Now, two things could happen (I’m not a soothsayer), SAP ships out its products driven by CAF (Built using Web dynpros, and the next version of Visual Composer) and simultaneously the best-of-breed application vendors would be driven towards “SAP NetWeaver Compliance” to ensure the mad-rush towards ESA adoption. This is what I would call the “Gold-rush” as of the B2B days. But customers would now have a new paradigm of development – just the procurement aspect being demonstrated by xPRO, in other areas as well. This could lead to a buy-out of some of the new “Best-of-breed” xAPPs (Could Vendavo be next? Aren’t SAP customers out there who have done so much more than what one would get to see in an xAPP of vertical choice?). The possibilities with CAF is limitless. CIOs realizing the same at the earliest would stand to benefit hugely from a cost perspective.
And xPRO, within the Architect’s World, is just an example showcasing CAF – like David taking on the Goliath. And the outcome is known…….