Design for support is a common concept in the manufacturing world that you can extend to the SAP environment. The SAP system takes care of the design aspects of the generic software functionality, but the implementation partner plays a big role in the way the software is configured and developed to suit a particular company’s needs. Company-specific configuration and development must be supported by the company using it or by a support vendor engaged by the company. Therefore, it’s important that long-term supportability is kept in mind during such configuration/development.
Up to this point it seems logical, correct? However, there are hundreds of cases when months after implementing an SAP solution, companies discover that basic supportability issues were not kept in mind when the solution was designed.
This story is about a large, fast-moving consumer goods company that wanted to enable its demand planning process using SAP APO. The company had more then 20,000 finished goods SKUs and wanted its sales force of 1,200 to participate in the demand planning process by providing input on expected sales for the next three months. A few months after system go-live, users started experiencing system slowdowns when entering data. In most cases the drill down to the lowest level was getting terminated. Finally the company’s support team had to take up another project to redesign specific planning books, data views, selection IDs, macros, and batch jobs.
What Went Wrong?
In this case the consensus planning process was designed in a way that the company’s sales forces needed to input their data at the lowest product location level. In the beginning of the month while entering expected sales data for each SKU for the entire planning horizon, there was a need to open up close to 50,000 cells in planning books. During these two days of the consensus demand planning cycle, a huge number of users was trying to log on the system at the same time (the time frame for data entry was very small). This resulted in serious system performance issues and users were locked. Another problem was the huge planning hierarchy and too many characteristics levels for planning, which resulted in issues such as multiple disaggregation or rounding effects.
Design for Support Considerations for Designing Planning Hierarchy, Books, and Views
Planning hierarchy design:Few companies want to achieve the capability to plan at every possible level using SAP APO. Some planning levels may not ever be used. While the product provides the capability to plan at any level, it’s important to remember that every increased level in product or location hierarchy may create issues in terms of disaggregation or rounding, or lead to longer times for batch job runs. Some large implementations have realized this over time and rationalized their characteristics levels in the next version of their solution.
Planning book and data view design: The performance of SAP APO planning books reduces drastically if there are more than 30,000 cells at any point. There are quite a few SAP notes on this and it is important to keep this restriction in mind while designing planning books and data views. However, there are options to work within that restriction and still meet the business need – for example, the way you design selection IDs or keeping a minimum number of key figures in highly used books, etc.
For more case studies of flawed implementations of SAP APO, see Rajesh’s full article inSCM Expert.
Ned Falk,Senior Education Consultant, SAP America, shows how your SAP NetWeaver BW projects can benefit using ABAP in his article “20 Uses for ABAP on SAP NetWeaver BW Projects,” which was posted to the SAP Professional Journal Web site in February 2010. Here are four of those uses.
1) Perform Open Hub transformations:
SAP NetWeaver BW supplies the Open Hub service to meet requirements for getting information to third-party applications from SAP NetWeaver BW. The data types, field names, and field lengths are often not the same in SAP NetWeaver BW as they are in the external application, or additional value manipulation is necessary. For this, an ABAPer needs to code the custom logic for the manipulation in a Business Add-In (BAdI). BAdIs, based on ABAP OO, help you accomplish custom enhancements in a controlled way.
2) Build authorization values:
ABAP implemented through variables filled by a user exit can be used to dynamically build authorization values when the user logs in. This is sometimes an easy way to maintain many allowed values for a cost center range for a specific user.
3) Process chains:
The process chain is a scheduling tool for various tasks in the data warehouse. In some cases, you can use ABAP code to schedule a job on the source system or run a small ABAP program on SAP ERP to raise an event on SAP NetWeaver BW. This event could then be used to start a process chain. A business case for this could involve a transaction or ABAP code run on SAP ERP to indicate that the Financial Accounting (FI) system is done with the month-close process. This ABAP program calls SAP NetWeaver BW and raises an event. When this event is raised, the process chain called “FI Monthly Process” starts.
4) Virtual InfoCube with services:
Virtual InfoCubes allow for the direct read of source data in real time. You do not have to load the data into an InfoCube — it is loaded into memory directly from the source when the report is run using standard SAP NetWeaver BW query and reporting tools. The three types of virtual InfoCubes are SAP remote InfoCubes, general remote InfoCubes, and virtual InfoCubes with services. SAP remote InfoCubes use SAP ERP or SAP CRM DataSources (and their associated extractors) to read the data in real time, while general remote InfoCubes access data that is normally purchased (e.g., Nielson). Virtual InfoCubes with services are used if the source is a custom table or group of tables. In this case, custom ABAP function modules (services) can be written to properly present the data from these tables to the SAP NetWeaver BW query tools, making your table look like an SAP NetWeaver BW InfoCube. This provides real-time data, not replicated data, from your application to the user.
Tom Rodden, Director, Enterprise Applications, Varian Medical Systems, will be hosting a Q&A about this IT transformation initiative in the Insider Learming Network forums this Thursday, September 23, at 1:00 ET. Get details.
Varian Medical engages SAP Enterprise Support to cover a range of topics, such as support issues, project activities, special performance activities, and bi-annual performance analytics that are delivered in the SAP Enterprise Support report.
In a general sense, Rodden says that his department and the company as a whole are in a much better position as a result of their work with SAP Enterprise Support. He sees the collaboration as a nice win for both companies. “It’s mutually advantageous to look to each other as partners in many ways, including approaches in collaboration and approaches to development,” he says. “And because the business is well aware of the great results from our collaboration with SAP, we’re not at the end of the relationship in terms of the depth to which we can go.”
Here are three lessons learned by Varian Medical System’s Experiences with SAP Enterprise Support:
1. Understand everything your support package offers. SAP Enterprise Support is more than a simple tech support engagement. Varian Medical quickly learned that support services could play a mission-critical role in three vital areas: project support, production support, and the provision of insight and education for a deeper understanding of current and emerging SAP solutions.
2. Connect with your support advocates often. Varian Medical not only made good use of the overall support services, but also forged close relationships with SAP support advocates who were able to provide regular technical expertise and serve as a human interface into the larger SAP organization. This interaction enabled the company to receive timely service, quickly access the right resources, and better understand its many support options.
3. Properly prepare for each support engagement. Varian Medical optimized its use of SAP Enterprise Support by engaging in thorough discussions and interviews with SAP representatives and providing relevant data and information. The result has been greater speed to project completion and OSS ticket resolution, as well as higher-quality outcomes.
For two more lessons learned from Varian Medical’s experience with SAP Enterprise Support, read the full article in insiderPROFILES of join Tom on Thursday for the live Q&A.
Join us on September 23 for more tips and additional insights, and ask Tom Rodden your own questions about how to apply these IT transformation practices in your own organization.Get details.
