Intro:
The “Solution Architect” approach to an issue resolution might lead to some unexpected inroads into an organization’s ESA initiatives. In two of my recent workshop experiences, I found the knowledge coming onto me from the core client community. It is surprising to note how glued in the SAP Customer community is on SAP NetWeaver and ESA initiatives. Sample a classic case of looking at lowering TCO from a business angle which provides enough meaning to the IT initiatives underway which ultimately culminate onto the SAP NetWeaver roadmap. The usage of web dynpros to lower TCO is not to be looking at e-enabling SAP R/3 key t-codes as a move away from the ITS approach, rather, it can be a very flexible solution set once the technicals are married to the business need. And that is precisely what architecting a Solution is all about. In this blog, let us take a look at how this approach can lead to a lowering of costs and time spent in training and cost reduction. To say the least, I left a lot wiser after conducting these two ESA workshops.
Problem definition :
Org. A has a java application that deals as the Capex system. This application talks to the core R/3 application and feeds in the approved requisitions once the operations in the capex system is completed. Org. A had the following three choices in front of them:
Option 1: The Technologist Approach: Take the .ear and deploy the java application from another application server onto WAS 6.40, take the APIs, create stateless session wrapper beans to call the APIs, convert these into web services using the NDS, deploy them onto the local UDDI server of WAS 6.40, create web dynpros and call these web services through the web dynpros and deploy them on the enterprise portal and have them accessible for specific user groups based on their UME.
Option 2: The Functional Consultant Approach: Bring this functionality for use in Investment Management in the core R/3 application and approach the same by mapping the functionality of the legacy application onto R/3 as a standard functionality and customize the workflow with SWDD.
Option 3: The Solution Architect Approach: Deploy option 2 and use the Enterprise Portal to deploy custom web dynpros that bring multiple functionality onto the same screen making the user to avoid making redundant trips through multiple t-codes. Down the line, Integrate the IM solution with PS and CO modules and extend the web dynpros to lay down the guided procedures nailed down as best practices to create this as an xAPP using CAF for this user group comprising 350 odd users.
Needless to say, the third option had the maximum vote count. Of course, there are other logical options but they don’t really find a buy-in from a business stand-point, so I will leave them out. Let us take a look at the business process being tackled innovatively now to lower TCO in a tangible form:
The Business need:
The procedure is aimed at reducing the administrative work around smaller capexes and streamlining major projects approval process. Major projects approval is organised in a clearly defined timetable that allows enough time for Business Group management to analyse and understand these projects. The capex approval procedure is organised as (a) below a mio, (b) above a mio, but lesser that 2 mio, (c) greater than 2 mio but lesser than 3 mio…till 5 mio and above. All requiring a different set of users as approvers and watchers based on the nature of the capex request. The underlying workflow has to consider the user group hierarchy, the dollar limit approval process, the nature of capex item and the budgetary allocation to its respective cost center or profit center.
Bringing it on further, once the CO linkages are in place, the capex requests need to be tagged onto projects in PS, to the relevant WBS elements as existing and valid based on the accounting segments in place. Presume that Org. A has a five segment accounting combination key, some keys would be existing as the combination would be valid and existing, some keys would be valid and non-existent, so they will have to be created on the fly, some keys would be invalid and non-existent and the accounting combination key should not be created. Presumably a BAPI call to execute the same, the bet becomes in having this custom BAPI converted into a web service and published locally for calling during runtime though the web dynpro for execution during run-time.
The capex approval requests are to be electronically processed only through the system where the Cost Value Analysis calculations and other relevant information and documents need to be submitted and approved. The capex is not to be approved until it has been approved in the existing legacy application all relevant approvers. No commitments or payments related to a capex can be made to third parties until final the final approval has been obtained in the legacy application. The process will remain the same even once built in core R/3.
For high-value capex requests, additional documents like justification reports will have to be submitted during the capex creation process. Suffice it to say, that the capex approval process has to have the relevant underlying workflow to create, change and delete any capex request with the ability to be tagged on with attachments of a restricted variety of .pdf only for regressive analysis and effective decision-making. The specific steps (which are confidential in nature), need to be addressed with the solution built that needs to have BI alerting capabilities and e-mail notifications. The solution also needs to be considering annual budgetary definition and utilization with roll-over capabilities for de-allocation of the capex into another fiscal year with specific checks and balances and these key boundaries would define the key constraints of the solution boundaries including parameters that would provide Org. A with a logical path for CO-PA reporting at the minutest level to be a SOX compliant system. (A topic in itself which we can keep aside for now).
The Solution Architect Approach:
Since the legacy application within Org. A that deals with this business process requires a high level of maintenance and monitoring, forget not the training costs, the choice of a solution that effectively leverages existing investments, provides the path of least resistance in terms of cost, timelines and acceptability needs to be the critical parameters in creating a business solution that lets Org. A align with SAP’s ESA roadmap. Minimal t-code switching, simple navigation, effective workflow and alerting capabilities define the choice of options leading us to Option 3 from the above. This gets further accentuated by the need for standard reporting facilities in an SAP driven solution coupled with notification and alerting mechanisms. The choice to go to IM in R/3 will align Org. A with the organisation’s continuous strive for simplification, uniformisation, standardisation as well as integration. IM, being a part of the standard R/3 capable of existing in an isolated manner, has a natural advantage over other the other options as discussed above. Inclusion of this process in the core R/3 application will lower costs by doing away with unwanted integrations, maintenance, monitoring and training – and that is only a part of the overall TCO lowering factors that could lead Org. A towards the path of economic salvation.
Extending this solution with FICO and PS would provide a business solution to Org. A that would provide the talked about benefits. Appropriation request is the SAP IM term for what we know as a capex (request). Add this with ABAP workflow capabilities and standard reporting functionality, having this integrated with budgeting for close monitoring and budgetary approval process for Org.A’s defined cost and profit centers would leverage SAP NetWeaver as the ESA enabling platform. Great, now that we opened the Pandora’s box, why should Org A not stop at having a solution based on SAP NetWeaver, but why should it targeting ESA as the key benefit provider?
The answer lies in our storyboard. First, If you remember, the very way that Org. A has grown over the years is through mergers and acquisitions. The biggest business driver for the CTO is business process and instance consolidations and stabling onto a single version. If the CXO office continues to make unnecessary and uncalled for investments in technologically brilliant solutions, instead of focussing on a single consolidated controlling area at multiple levels of cost and profit centers based on business models, it would cost the CXO his/her job.
Second, the Solution Architect drive would result in instance and business consolidation, SOX compliance and towards a central controlling concept to drive a linearity of processes across Org. A. This would mean that the key business process have to be defined as the best/next practices, the central reference instance becomes the focal point for the object conversions and benchmarking into web and enterprise services (e.g. the BAPI we discussed earlier on) an having these published as web services internally, having the custom web dynpros as standard iViews and business packages published for re-use, will also drive the User management strategy internally within Org. A across the business divisions – existing and to be taken over.
Third, the single common UI with the relevant sections from multiple t-codes with standard document approval process in .pdf and integration of business reporting through BW with callable objects from iXOS and the like will provide a unified solution that will drive training, maintenance and re-deployment costs through the floor-board. Now, with this as the Solution approach, it does make sense in converting these key business process as enterprise services for use via web dynpros today and guided procedures in the future. So, it sure is ESA now.
The Build:
Once the legacy application has been configured on SAP R/3 in IM, the ESA and web dynpro candidates become the t-codes for create, change and delete appropriation request. There are now three choices with the workflow to be used: (a) Use SAP workflow, (b) Use a third-party workflow engine like Flow-Brix or K2, (c) create a custom java workflow engine, or (d) look at KM Ad-hoc workflow, if found useful at all once the APIs are available or (e)Look at XI as an option. The need to explore options (as long as they are logical) around this is a one single need to improve the performance of the existing systems with SAP Workflow being looked upon as a huge resource-hogger. The more complex the workflow, the more the number of the same, will certainly impact system performance in the long run. So, decisions around the same are open for Org. A to choose and analyze with finally bringing on multiple relevant sections of the t-codes along with BW reports and alerting and integration with document management using web dynpros and extending the solution with other R/3 modules, ADS and leading to Guided procedure using CAF will result in cost savings and increased productivity – purely based on the way you architect the solution. Outro:
The abuse of web dynpros by the SI community and customers alike give birth to consultants who fall in the category of plumbers (the integration fans), the make-up artists (the jazzy EP screen builders), the undertakers (the workflow & BASIS fans doing the graveyard shifts) and the electricians (The technology of the future fans) sidelining the end user community’s need craves for Solution Architects who can define business solutions that leverages the SAP NetWeaver platform and helps find relevant usage of ESA in the business solution. Your feedback is appreciated.
