3. The user has the option to choose the volume from either of 2 ways:
A. Enter Weight per truck and specify no. of trucks.
B. Enter Total Weight.
A business rule (Maintained at the custom ABAP application level)
checks for the total volume allowed and calculates the surcharges incase the truck is not fully loaded.
4. The ship-to selection will populate the screen with products available for this ship-to.
5. A credit check with an external application instructs the system to process the sales order or block it until credit is cleared.
6. An availability check confirms products at the requested date or a later date.
7. Subsequent functions such as delivery and billing are done on the R/3 side.
8. Once the user reviews the order and submits the order acknowledgement page is displayed.
9. The sales representative can track the order status to see, for example, if the sales order has been delivered or an invoice sent. The sales manager can view sales data those have been automatically extracted and use it for reporting and analysis.
The order confirmation functionality is available for users in the Order Manager role which could include Carriers acting as the Order Managers. The features include:
A. Order Confirmation (Single/Multiple)
An order manager will only see, and be able to conform orders for, their authorized Ship-from locations.
B. Cancel/Modify Order.
Customers canceling orders outside of the order horizon contact the order desk and speak with an order manager to cancel orders.
The Solution Architect Approach
Step 1 – Freeze the Core:
Let the customer remain on R/3 4.6c & BW3.1 till the instance consolidation exercise is over. Moving ahead with mySAPERP 2004 or Enterprise version does not mean much sense to them. Instead, the reduction the in the number of instances and streamlining the business process across the same is what is required as of now.
Step 2 – Freeze the Zone:
While the consolidation exercise if underway, we have seen that the area of maximum potential of Z-objects of BAPIs, RFCs and programs reside maximum in the Order-to-cash process zone. Since the source of truth of development for all instances is the central US instance, it becomes our ideal candidate for process engineering.
Step 3 – Freeze the areas:
As the customization areas have been identified over here as the three main ones –
Credit check, Pricing & Export document compliance & generation
, these three areas have been customized heavily to be made as customized ABAP solutions of their own. (Best practice or not, well, that is debatable)
Step 4 – Freeze the Solution Approach:
Once the instance consolidation exercise is complete, replicate the linearity of the z-object structure across the instances. This includes BAPIs, RFCs, Tables, Programs and Dynpros and other related z-objects to make it work.
– Have a separate instance of a standalone WAS 6.40 (ABAP + Java) and EP6 (SR1+) on a separate server.
– Convert the dynpros into web dynpros and use the BSP/JSP approach based on internal policies via SE80 or NDS (It all depends if the client is in a position to experiment with NetWeaver 2004s).
– Create wrapper BAPIs and RFCs for the z-programs in the R/3 4.6c instance and replicate across.
– Create wrapper web services for calling these BAPIs and RFCs via a JCo connection from the WAS 6.40
– Publish the BAPIs and RFCs and web services into the local UDDI server of WAS 6.40 and have the logical object grouping of these objects based on roles
– Create Web dynpros out of existing dynpros on the ABAP stack or use the Java stack to create the same (based on the avialability of software) and this part is more implementation driven. Web Dynpros with the java stack are a proven thing today with customers. The same with the ABAP stack is more in the POC stage & needs to be tested from an SI standpoint (Try SE80 & see for yourself).
– Call the webservices from the web dynpros displayed via the enterprise portal and have it ready to be built into the Composite process for the future, post upgrade.
– Call the BW 3.1 reports through EP as BEX queries. Create and attach specific queries for reports to users within these external application areas and roll-out.
Now that the application logic gets shifted away from the R/3 4.6c instance to a layer above, the Solution Architect is now in a position to lower the TCO and rollout cost for the client. The aim is to lead towards a loosely coupled architecture as depicted below.
– These application areas now have the ability to be converted as xApps in the future for the client to sell to this specific industry vertical as well.
Clearly, the Solution Architect now is in a position to show immediate savings for the customer result from the following key areas:
1. No upgrade to Enterprise and then again to mySAPERP 2004. This can be deferred till year 2007-2009 till the extended maintenance mode.
2. Alignment of ESA Vision with the existing Instance & Business process consolidation exercise across LATAM, EMEA and UK within the organization.
3. Lead the way for an ESA roadmap where the customer thought it was an esoteric and impractical goal under current circumstances. This approach reduces the cost, effort and time reduction for the consolidation and streamlining activities by taking the application logic a layer higher than SAP R/3 for reusability across multiple geos and instances.
4. The approach is on the web dynpro route (Java or ABAP development as the case may be with 2004s availability) and not the internal WAS 6.40 Internal ITS route of simply “e-enabling” transactions, which is a no-brainer. The idea is to put the client on the path to ESA.
5. The Business benefits are many as there is no disruption to the existing business processes, practically zero training cost, alignment with internal goals and objectives.
Please refer to
“The Architect’s World – Episode 3”
for the solution to move this towards the xApps route and Guided Procedures.
The role of a Solution/ESA Architect is to align with the customer requirements. At times, the role may not fully align with SAP’s direction immediately. Organizations these days are cautious and slow moving. The role of a Solution Architect becomes increasingly more important in marrying up the Business need and IT goals. And that is where the challenge lies. Once again, the above is only the guiding principles – a way forward. There are other ways, but there is no hard and fast rule to say which is right or wrong. It is purely circumstantial and is based on theneeds or the client organization and is purely driven by one fact – Are you, as the Solution Architect, convinced about your solution?.