– Set the context with the larger agenda – SAP roadmap with a complete ERP migration to SAP Business suite as the financials today gets consolidated on a different ERP. IS-Solution along with SAP R/3 4.6c is in place today.
– Provide inputs to a phased approach for migrating to the client to the SAP NetWeaver Platform for the ERP Implementation
– Lay down the guiding principles with the SAP NetWeaver
– Set the stage for an ESA Roadmap exercise
The Client Organization Primer
The client organization is one of the top marketers of Natural Gas related products. Many employees operating, processing, storing, and transporting natural gas liquid to facilities across the United States, Canada, and United Kingdom. The client organization engages in the purchase, sale and trading of their products, accounting for thousands of barrels per day.
Specific initiative around 4 areas are ongoing at the client organization:
– ERP Selection/Pilot & evaluation/functionality testing
– Planning a strategic way forward with SAP NetWeaver to create an open and scalable platform for the future
– ARIS mapping of all business processes for ERP implementation.
– Lay down an ESA roadmap considering the future landscape
Sandbox IS-Solution has been tested to provide Supply Chain Management functionality that is possible via a custom middleware solution by the client organization, an IS-Solution instance has been set-up in US. An ITS instance in front of this IS-Solution system for exposing key transactions using the in-built ITS of WAS 6.40 SP11 has been set up. Showcasing of the key identified supply chain processes can be handled out of the box by SAP. (Note: This is a cultural issue of that has the ITS-driven employees swear by the same, as an architect, do not even attempt to change that now!). APO as an example of an add-on component is being considered.
The IT Community is open to the idea of the third-party middleware to be replaced/piloted by XI3.0. (Obviously, such a drive cannot happen overnight.). Project ERP’s march towards implementing the custom middleware at the Client Organization was intercepted by the Central IT. Central IT is very much the final authority on this, it dictates what will be implemented. The weakness of the custom middleware tool to building real-time interface is our opportunity with XI.3.0
XI 3.0 could be a standard whenever SAP/other ERP is implemented, an approach to the same will be explored in this blog. So long as there is an SAP instance at one end to talk to, it makes the job of a Solution Architect a lot easier to push the same (mostly the case with IDOC adapters and standard business content to start with).
WAS 6.40 SP4/5 (ABAP+JAVA) with inbuilt ITS to be used to create Business specific Webdynpros as pilot for added functionality. (The Business functionality will be determined by the IS-Solution team). Inbuilt ITS may be of no use here if the application is not deployed on WAS6.40. (Curiously, the client was under the impression that once could use a WAS 6.40 instance as a separate ITS server without the application deployed on it clearing up the air took some time)
A standalone ITS to web-enable IS-Solution for internal users, if ITS would need to be looked upon a way to web-enable IS-Solution transactions.
ITS has been included because of the success of a pilot / demo to the client organization Team. The functionality demonstrated had been kept at a minimum. There has been no thinking on the likely Web Architecture (version of WAS, etc). The CRP was solely concerned with showing how IS-Solution functionality could meet the key supply chain scenarios. From an SAP NetWeaver and an ESA roadmap standpoint, this becomes a very important part of the entire implementation way-forward. We use it as the fulcrum to push our ideas through on an ESA roadmap.
All the above exercises need to be designed in a way to lay the foundation to a future roadmap with SAP NetWeaver.
As evident from the documents made available to Wipro, a potential area for creating a sound mobile infrastructure can also be looked at for all device independent non-SAP/SAP applications build for wireless operations. (A good case for web-dynpros to be put forth by the Solution Architect)
To create an infrastructure that is to be scalable, open & robust, it is essential to zero-in on the way forward with the core ERP engine as well. The way to look at moving forward could be aligned as below:
An assessment of the current scenario @ the client organization – points to bring all initiatives together:
Complete configuration of SAP environment and test IS-Solution to determine how far SAP can be leveraged final technology solution. This is the part for the ERP implementation, a quick closure is recommended. The ESA initiative could make sense (logically, not techno-logically!), when the back-bone application is SAP driven irrespective of what the analysts say.
Determine what additional applications may be required for the 1st delivery of SAP Financials (replacing the existing ERP solution) and Supply Chain Management, preferably by October 2005.
Complete configuration of SAP environment and test IS-Solution to determine how far SAP can be leveraged final technology solution. The SAP Sandbox testing needs to start immediately and for the most part, run parallel to the business process mapping. Of course, the affinity of replacing the existing ERP cannot be ruled out especially in core financials.
The client organization Enterprise Architecture Team has put together an architectural strategy that is intended to be part of the road map for all The client organization business segments. However, this needs direction from the SAP NetWeaver standpoint.
Although SAP is used for day to day transactions, the financials are rolled up and reported at the BU level by the existing ERP in the US.
At this time, there is no burning desire for an ESA roadmap rather the IT Organization wants to show some quick wins to consolidate its position within the organization to spwan a lot of new initiatives. For them, the migration to SAP Business suite has far reaching implications. For a Solution architect, this is an opportunity to ride the wave of this migration to create a strategic ESA roadmap and get the attention of IT & Business alike.
Putting together a few quick-wins
Given the above points towards coming up with an applicable IT Roadmap with SAP NetWeaver, a Quick win project has to be undertaken around SAP NetWeaver which aligns with some of the Projects that have been arrived at as a strategic model to achieve the overall vision, namely:
– Strategize usage areas for using EP/KM/TREX & Collaboration by initiating the transition of the corporate Supplier extranet, which is a web application on a Sharepoint server. (This sets the pace for the EP POC)
– Identify Web Dynpro candidates: Use EP as the front end to expose key transactions from existing R/3 applications with webdynpros deployed on WAS. (This sets the tone for the ITS replacement strategy and the exploration with web-dynpros)
– ARIS integration with XI 3.0 POC and the usage of Solution Manager 3.2 beyond this POC
– Identify feasibility for creation & consumption of Web services from R/3 applications & custom legacy applications/Usage of ESS/MSS Business packages* (If you want to test out the complexity of the environment, extend the above towards web services consumption via RFCs to EP. Availability of ESS/MSS is version driven see if the version has the business packages available)
– Explore/Strategize creating & using XI 3.0 Adapters to communicate with R/3 systems as pilot. (Pick out the most complex set of interfaces with the existing middleware, both B2B and A2A and create a ground for comparison with logic)
– Identify Composite Application/xAPPs candidates using CAF & usage of Analytics (For the roadmap definition)
– Identify candidates for xApps by porting existing Non-SAP applications on WAS6.40SP11+ (A Powered by SAP NetWeaver application can make you prove a point to migrate applications from other technology platforms)
– Pure play porting of Java applications on WAS6.40 (J2ee standalone) to set the ball on a landscape transformation landscape.
– Recommend options for phasing out pureplay applications like LiveLink (replace with KM/Collaboration, replace Vignette with EP workarounds etc.)
All the above must align with the client organizations Future Business Model Criteria the points which become the guiding principles in creating an SAP NetWeaver platform.
The SAP NetWeaver Solution Architect Approach
Process consolidation approach: The ESA roadmap based on the future landscape would help create a rough-cut plan. The ERP decision has to be taken soon, an ESA workshop would help expedite the process.
Speak with POCs: The best way to prove a point is to have sensible case-driven POCs. Nobody is sure until business process templates are fully evaluated; In the above scenario, it is likely that MM and PP will be needed in addition to the primary financials modules in the base R/3 system along with the IS-Solution – propose to do it on a seperate instance.
A Fact-driven approach: Suggest to implement what is necessary, phased and proposed. Bring on the legacy applications onto the SAP platform if possible, else, propose options with retention of legacy applications on a phased manner, some processes and applications are best left untouched in the beginning.
Size does matter: Given the size the client organization, SAP is willing to provide them with “trial” licenses for the add-on modules for testing, but a caveat that the client organization needs to engage some of their experts in the development and testing of the same.
Push the right solution: There is no clear cut benefit for the client organization to go to R/3 Enterprise (Rel 4.7). The implication with IS-Solution needs to be worked out. Even if it means a delay to the roadmap definition. Our role demands the right solution
Get real: MySAP ERP (ECC 5.0 might provide benefits due to SAP NetWeaver, but IS-Solution would still be an “Add-on” and may require custom development).
Have a few options ready: Options would therefore be: 1) Current 4.6c with IS-Solution and customization, 2) Custom development on R/3 Enterprise or MySAP ERP 2004, or 3) Custom development on top of an IS Utilities environment or 4) Instance consolidation and ERP decision first
Carve the ESA Blueprint: The next steps should be to develop a “blueprint” for the business processes and determine what can be handled via current functionality and what will require workarounds or future development.
Do not rule out custom development always: If custom development is needed initially, it might just lead the way to an xAPP in the future. (There is a customer I interact with who thrives on this approach)
NetWeaver is only an enabler, its not the end-all:This is where, as a Solution Architect, one would prefer not to proliferate other instances of SAP if possible and work toward a more consolidated view in the long term.
As can be seen from the above case, it is not always an easy task for an SI to get into the ESA Architect mould. (SAP AG may find this a lot easier!). In such cases, the deeper the ESA/Solution Architect gets into the overall client Program, chances of making a difference become better.
Hope this information makes some sense and is of benefit to you. The role of an ESA Architect/Solution architect makes sense if, and only if, the larger aspects of businesses are touched upon. The role cannot be relegated to SAP NetWeaver alone. Without a sound understanding of SAP NetWeaver technologies, business processes and SAP, the role of a ESA/Solution Architect may not pack a punch..