Four Tips for Getting the “Right” Requirements for SAP BW | |
To ensure a successful, on-time, on-budget BW project it is imperative that one gathers the “right” requirements for the job. The best way to do this is to gather business requirements that will establish a project scope that stays focused on user needs. Here are four tips for getting the “right” requirements: 1. Use people close to the business than can help you clarify their needs. Instead of only using a system development lifecycle (SDLC) approach to getting the requirements, meet with the business users once a month and demo what you have built. In the beginning it might just be demo of standard content, but after a while you can solicit feedback on layout and design that will assure a system that is more aligned with the users needs. It also provides the users with a great way to interact with your team. BW projects should not be “dark horses” where requirements goes in one end and a solution emerges a few months later they may, or may not, meet the requirements. We do not build data warehouses; we are doing data warehousing (an active and interactive process). 2. Avoid creating a total inventory of all reports in the organization. The top five (most used) sales, distribution, inventory, etc., reports from each department will cover the vast majority of the reporting needs. A single SAP BW report my satisfy dozens of today’s static reports. It is therefore impossible to map each legacy report to an SAP BW report. Avoid attempting to replicate each report based on what you might have in place today. Accept new ways of accessing data (see figure 1).
3. Obtain a copy of each of the current reports used today that is requested to be developed in SAP BW. Legacy reports may be a great source to document the data needs. They can be used to illustrate how data is being summarized and viewed in the organization. Create a physical folder with paper copies of “in-scope” legacy reports. Making sure that the development team has access to them will reduce the time spent in meetings with the business community. Finally, consolidate the requirements and look for “low-hanging fruit” because many requirements can be met with a single SAP BW report. 4. Create a form that captures the core requirements in a structured format. One tip is to create a single form called an “information request form” and use it to gather the core relevant information about each report being requested by the business community. This should include at least the following fields: Contact info about the requestor Finally, deciding which reports should stay in R/3 or in the legacy system is not an easy task. Just remember that not all reports belong in SAP BW; avoid using SAP BW as a “dumping group.” Also, make cost-effective decisions. Just because the report is not in SAP BW does not mean it cannot be in the SAP Enterprise Portal, or on the Web. Be careful to make conscious decisions on what reporting needs you are going to need and how you want to accomplish this. Following the aforementioned tips will help you immensely in your efforts to gather the right requirements for SAP BW. This tip is taken from Bjarne’s presentation, “Best Practices to Plan and Manage Your SAP BW Project.” For more information on next year’s event, please visit, www.sapbwportals2005.com |
| |
|
Ten Strategies for SAP BW-Portal Integration (Part I)By, Naeem Hashmi, Information Frameworks, nhashmi@infoframeworks.com
This tip is the first of two to offer strategies for SAP BW-Portal Integration. In this tip we will delve into strategies one through five. 1. Identify the InfoObjects (SAP BW data) users will need as part of a portal-generated content page. Portal users are role-specific to provide personalized information. Since, browser real estate is limited so users need focused information. Provide them with focused information to ensure that their needs are met. Identify the minimum amount of information users will need to make business decisions. Predict and design how the information will be placed in the portal page and don’t publish detailed reports, streamline the information. 2. Identify How Users Will Navigate Identifying user navigation methods will help you better meet users’ data needs. Behind each need, research the business value behind it and then identify the sources of the drill-down data. Next, select the integration/consolidation method for content navigation such as unification vs. report-to-report or another SAP BW report (iViews – large vs. small). Head’s up: you may need to remodel your SAP BW queries, InfoCubes, etc., to ensure adequate drill-down/query performance. 3. Select the Right Consolidation Technique Content consolidation in Portal is quite resource consuming. Leveraging the proper consolidation technique ensures user satisfaction, adequate performance, and avoids content duplication. Analyze when and where you need consolidated information and then identify consolidated data volumes in SAP BW and their usage frequency. You should also carefully assess run time performance versus operational costs associated with SAP BW MultiProviders and portal unification. Be careful to avoid content duplication--make sure you validate consolidation and aggregation logic for iViews when dealing with multiple information sources such as multiple SAP BW instances, SAP BW and R/3, or MultiProviders. 4. Review Your SAP BW Modeling Assumptions Typical SAP BW models provide access to large datasets such as reporting, slicing and dicing, OLAP, and production reports. However, large data sets are not effective in a portal environment. Identify which portal content units (iViews) you’ll need and define several small queries for the specific iViews. You should also estimate SAP BW and portal content rendering performance. Assess cost/time requires to implement and support additional data stores in SAP BW instead of adding more hardware resources to overcome performance issues. You’ll also want to keep portal-specific requirements in mind when modeling SAP BW objects such as queries, InfoCubes, ODS objects, and MultiProviders.
|
|
Three Tips for Improving Response Time in SAP BW Business Explorer (BEx)By: Penny Silvia, Director, Business Intelligence, Business Information Solutions LLC, penny.silvia@bisamerica.com
One of the challenges that all BW implementations face is the balance of optimizing flexibility with performance in BEx. As an enhanced version of Microsoft Excel, BEx is the area most frequently used by Analysts and Power Users of BW, but the performance of those analyses can cause frustrations and delays. SAP is working hard to improve the performance time for BEx users through systemic changes and enhancements in the processing engines. As you progress in your BW implementations with the latest versions and components you will be able to take advantage of these enhancements built into the product. For example, in OLAP querying caching, the query results and navigation statuses calculated by the OLAP processor are stored in a cache. This then enables the OLAP processor to access data stored in the cache for queries that are similar, thus improving query performance and reducing the load on the database instance. This can be set at the InfoProvider or Query level, thus providing significant performance benefits and the flexibility of where to set these parameters. But for those of you who are still struggling with BEx performance, there are many things that you can do during your query definition and OLAP activities that will increase the response times of your querying. These tips are useful for all versions of BW – and will be applicable to all functional or business areas using the BW system. And while these are predominantly Super User tips and tricks, they can be viewed as overall system design tips that will increase the reporting experience for ALL users of the BW system – casual user or Super User. 1. Strategically Leverage BEx Features BEx offers many Super User functions that can add tremendous value and power into your queries and reports. Some of these, however, come at a cost – performance. In designing both your standard and ad hoc queries it is important to understand the performance impact of your design decisions. One example of this is with Calculated Key Figures and Formulas. For the best performance, you will want to make sure you assess the use of calculated key figures versus formulas. Calculated Key Figures are processed on the BW server, whereas Formulas are processed on your local excel layer. The performance gains of Calculated Key Figures versus Formulas will be especially noticed for highly complex calculations. Another good performance gain comes from date field calculations … think about mapping them to key figures in the data targets. It allows significantly more flexible and powerful queries. For example, you can use Boolean and data functions such “less than,” “greater than,” and “not equal to,” as well as subtracting one date from another. You can’t do these things with characteristic dates! You can further increase performance of your reports with controlling your subtotal rules. Whenever feasible, you should remove subtotal rows from characteristics properties — right-click the characteristic in query designer and select “Properties”. Once there, set “Totaling” property to “never” or “conditional.” The latter will provide grand totals and avoid subtotals. Large queries will also run much faster with this method. Finally, when tackling parallel processing in MultiProviders, set configuration to allow parallel processing, if feasible. This allows base cubes to be read in parallel instead of sequentially, which is the default setting 2. Weigh Processing Versus Storing Extra Model Data If you have a large number of complex numeric computations in your query – calculated key figures - you could potentially see a tremendous improvement in query/report performance by performing these calculations during the update process to the cubes. This performance savings must be weighed against the “cost” of storing computation results in the cube or ODS, for as you know, every key figure that is added directly to the cube increases the overall size of the cube and the complexity of the cube as well as adding additional time to the update process. For those calculated key figures that are used frequently by many users, however, the gain in the performance may be well worth the additional “cost” of update time and database space. Another idea is to evaluate your staging options if you have a lot of BEx filtering on characteristic values. You can create a field in the cube/ODS that determines this state using a start routine during the data load. Then, set the field to X when this condition is true. This reduces BEx processing requirements. One additional aspect of processing versus storing extra model data is the challenge of aggregates and secondary indexes. Even in query results that are small, a large amount of data may have to be processed to produce that result – for example, you may have to run through and pull together results from 60 millions rows in a cube to deliver summarized results into ten rows in the report. Performance tuning for queries is imperative. For example, I was able to cut of my query runtimes from 18 minutes to 1 minute by adding one secondary index on a master data navigable field used in the query. Use well-designed aggregates and secondary indexes; huge performance gains can be achieved. 3. Consider Using the CMOD User Exit As a final idea, you can consider using the CMOD user exit. The CMOD front end user exit is difficult to figure out because it’s not like the other SAP user exits - even when you use the current SAP documentation, there are gaps in the information provided that make figuring out how to use it difficult – but it does offer you the opportunity to break into the BEx code and perform certain otherwise impossible functions … like word-match searching on free text fields! You should also try other methods and only use the user exit as a last resort as it is very powerful, but not easy to use or maintain. Overall, SAP continues to develop tools and technologies that deliver a higher user satisfaction for both the casual user and Super User. Granted there is a great deal of attention paid to web-based reporting for BW, but the tool of choice for Super Users will continue to be the Business Explorer and SAP recognizes this. There are continuous development efforts to respond to the user input gathered at user forums across the world and SAP has come a long way in deploying a product that offers true complex ad hoc reporting capabilities for Super Users. Complex querying and calculating come at a cost however – of either time or data base space. BW is a system of “give and take” … you can GIVE your users great performance on their queries, but you have to TAKE additional space on the database by pre-calculating and loading them directly into your models. Or, you can GIVE your Super Users great performance if they TAKE the time to think about how they are approaching certain queries and build in some of the above-mentioned tips into their designs. As with the other aspects of designing a BW system, there are many, many options to how you can accomplish the same goal. The choice is up to you, but the tips listed above should provide you some good foundations to making those decisions for you and your users. This tip is taken from Penny’s presentation, “Advanced Techniques to Fully Exploit SAP BW Business Explorer (BEx),” given at SAP BW & Portals 2004. For more information, please visit www.sapbwportals2005.com
|
|
|
