Intro:
As our BPX, Dave Mustaine, starts studying the processes for the B2B Orders coming through, he realizes that there are multiple pain points which could be addressed very effectively if Org.A were to harness the power of xApp Analytics. In the last episode, we went through the web ordering process for b2B orders, in this episode, Dave realizes that there is room for value-add in two key processes that could bring about immediate tangible returns for the business users. As one navigates through the newly defined "SAP NetWeaver Composition Platform", one observation becomes the highlight. One could use the Composite Application Framework and Guided Procedures for reverse-engineering processes to bring about productivity improvement and ease of use, while VC could be used to create xApp Analytics to plug in the gaps that could be a layer on top of the xApp to provide a space for proactive action. Corrective or preventive. maybe, xApp Analytics best resemble the top-up benefits of an Insurance cover - the ECC core.
The Fraud and Risky process for xApp Analytics:
Frauds account for a large chunk of revenue losses from a small chunk of this service line, but the steps that Org.A used to curb these, unfortunately, resulted in making the ordering process more difficult for the genuine users. Once the order lines have been confirmed by a customer through the B2B service line, the systemic check entails the validation of the shipment location. If the shipment has to be dropped at a customer location(s), then the necessary locations are validates and created, if absent. Once the location has been confirmed as pre-existing, the check could introduce a function that could be a BAPI checking shipments to that location in the past 6 months of existing data in the system. Issue tracking, that happens in a different database as a standalone application, is tracked for every location, every order. If this could be linked up and the check be done on the R/3 and this application database, a huge manual effort could be done away with - bringing in more accuracy. The issues are recorded in detail by an outsourced agency for Org.A.
The process gap can be completed to a logical conclusion if the orders that warrant the need for putting such orders on hold that demands a sanity check, which could then be tracked and acted upon manually to complete the process. As of now, all drop-shipments go on hold - a fact that Org.A sees as a necessary evil, that delays the drop shipment process and takes away one of the USPs that could be a major differentiator vis-à-vis competition.
Dave starts working on the process. The logic for checking fraud for shipment to B2B Order location and directly to customer remains the same, with minor modifications on the issue tracking level. The data for customers & addresses should be obtained from ZRA_CUSTOMERS and ZRA_ADDRESSES_ALL in R/3; The customers and their Orders , RMA and IRs are stored in the sales order header and detail tables (as part as header and item text, based on the case). One way of connecting a Order to a return or IR is through the Order Number. An RMA and IR could be entered as return in R/3. To put a order on 'Hold', a new hold name in R/3 is suggested as the 'HOLD FOR RISK' reason. The responsibility for applying and removal of this hold will be the same as that used for loading the B2B order. A mail with details of customer and order lines will be sent to ASM/Sales Rep/CSA for further action to closure. These details, once the data can be accessed from an external store that records the issues for certain locations and customers, xApp Analytics would then become a very useful tool to put the fraud detection process in place. On top of an xApp, if need be. The logic, of course, can be enhanced. If there were to be an application designed as a "reverse-engineered" xApp that guides the stakeholders through the process of creating the orders on hold, and then releasing the same once the process is completed. Presuming that the SLAs are mapped out as logical steps to complete the Fraud detection process for "faulty" shipments. Based on the roles defined for the system, namely, ASM, Sales rep, CSA, and of course, the admin, the reports generated at various levels on top of this xApp could be a logical interaction point for action by using Analytics. The process would the work as follows:
Step 1: Check for the Orders coming through the B2B service line. See if a drop-shipment is required.
Step 2: Check for drop-shipment. Query through the Issue d/b and validate.
Step 3: Put Order on Hold if shipment is "faulty" and send notifications.
Step 4: Scan the reports of faulty shipments, complete the manual process of location verification by CSA to ensure validations and pre-payment.
Step 5: Let the good orders flow through as Payment on delivery (POD) Orders, as Org.A does not charge the customers on placing of the B2B Orders for customers as the move is to gain market-share.
Step 6: Release hold, drop shipments.
Step 7: Proceed with standard process.
The B2B Order cancellation Process:
As part of the introductory offer for this service line by Org.A, B2B orders can be cancelled as long as the need by date is in the future. For the same, the process flow is denoted as below:
Dave figures, if the pattern could be tracked within the cancellation process for the b2b service line, action could be taken on an immediate basis that could lead to a) increased sales and b) identifying a pattern in order losses, if there is one.
Dave's thoughts:
Development on VC is a matter of practice, getting used to it. the heart of the solutioning remains the defined .gml file that is the concept into action mode. Having the UI displayed in Flex or Webdynpro is a matter of aesthetics. A luxury that he believes the business users are more prone to. What matters to the CXO, however, is not the UI rendering, but the deliverance to the business users from where the funding comes in from. Having a reverse-engineered x-App to make processes adaptive is one end if the spectrum, in certain areas, there may only be a need for an xApp Analytics. The gaps that are not addressed in automating a manual process, bringing in compliance with CAF and GP, the more tangible benefits would actually come in from xApp Analytics - cavities in the process which demand immediate action that could translate in $$ for the Corporate IT to show.
Outro:
Reverse-engineered xApp - PBNW, CFNW or Composites is certainly the name of the game, but the gaps get concerted into wins, customer stickiness, proactive action is what is made possible through xApp Analytics. Maybe, the "side-car" approach that Shai talked about does make sense. Dave has his mandate of keeping the core ECC stable. Yet he has the mandate to innovate - on a weekly basis and show tangible revenue beneifits. He loves his music, his iPOD. He likes to download his old '80s metal hits from iTunes the same way he would see downloading of his xApp Analytics from the xApp hub. And, Org.A buys the idea.
As a BPX, the objective that Dave has to deliver is value to Org.A Information consumers. To ensure that they have the relevant information needed to take preventive, practive or corrective action in the context of the daily business processes that is relevant for the process users within the B2B Service line within Org.A. As a range of top-up insurance cover on top of an xApp(s) or core ECC, xApp Analytics should be the bunch of easy to build and use applications providing insight into various process details and functions, taking in the “forest-view” or the “tree approach” designed to the specific tasks performed by a specific role within the process chain bringing together information from multiple sources within Org.A. As a BPX, Dave realizes the importance of such an application that doesn’t resemble a simple dashboard as a blast from the past, rather as an innovative solution that enables business users to analyze the transactional work with more intelligence to enable informed decision making and immediate action.
