The entire group of BusinessObjects frontend tools is currently called the SAP BusinessObjects portfolio (or BOBJ for short). This group includes the SAP
BusinessObjects Explorer (formerly SAP BusinessObjects Polestar), SAP
BusinessObjects Web Intelligence (WebI), SAP BusinessObjects Xcelsius, and Crystal Reports. These naming conventions are subject to change as SAP makes adjustments to the functionality or repositions certain tools.
With any new functionality in the SAP space, our first concern is how the changes affect our road map and strategies moving forward with the overall SAP process. With all the new frontend components, figuring out what component does what and where the overlaps in functionality exist is a bit of a challenge. But the big question in most shifts such as this, where an entire reporting frontend is shifted from the BEx approach to the BusinessObjects approach.
With the acquisition of Business Objects in 2007, SAP has made a shift that combines bestin - class business and industry applications with best-in-class solutions for business users. To integrate these two components, SAP Business Suite and the SAP BusinessObjects solutions, SAP has used the NetWeaver Business Warehouse (BW) Enterprise Data Warehouse (EDW) platform. For customers that have invested in BW, this has been considered the fundamental building block for their enterprise business intelligence (BI) capabilities. This gives the business users access to additional capabilities and tools that will allow them to extend and deliver business intelligence to almost any part of the organization. As in many cases with new functionality and toolsets, some companies have had little or no exposure to the new BOBJ components and need guidance and assistance for integrating the “new” products into their existing NetWeaver and BW landscape and also understanding of the going forward road map for SAP integration.
Two primary cases need to be addressed when planning an implementation of BusinessObjects solutions as an additional reporting component to the BW system. The first is the case where a new implementation of BW 7.0 is being deployed, or an older version of BW is being upgraded. At the simplest level, the migration of key business functionality from current systems and platforms to BW 7.0 makes maintaining the status quo with regard to BI capabilities a challenging process because current interfaces will begin to change as data moves over time from existing platforms to BW 7.0. Existing data extraction and loading processes, report templates, and most every other facet of the current reporting and analytical capabilities throughout the enterprise will likely require maintenance on functionality at some point during the rollout or migration. Beyond the simple “the interfaces will change” argument, however, a widely accepted best practice for ECC (and by extension, BW) rollouts is that organizations should not simply re-create their respective existing collections of reports to accompany the new environment but instead—even taking risk and complexity factors into consideration—any ECC and BW implementations should be viewed as an opportunity to rationalize the end-to-end BI framework and adopt an updated approach to reporting and analytics; one guided by the increasing need for timely, actionable, high-value insights for decision making and in support of work processes and operational reporting.
In the case of a BW implementation, BW or BI typically provides the catalyst for the organization to review its BI process and build on and deploy a new generation of BI capabilities. In most cases, the implementation will touch all corners of the enterprise. Further, by design, BW is architected around multiple components to achieve the best possible balance between uniformity, consistency, and flexibility, with individual business units or functional areas given a certain degree of flexibility to tailor the information and system to their particular business needs. This multiple-component approach is widely recognized as a best practice to serve multiple business groups and users across a large, complex enterprise; not only in the transactional realm, but also in the informational and analytical realms and concepts. The point is that although there are always multiple approaches that could be implemented for customers, a key factor to defining the overall strategy is the need to support multiple business user groups across the company. As the saying goes, information, and therefore BI, is one of the most critical factors in the success of your company and growth in this economic environment.
Another closely related principle to the preceding ones is the necessity to follow sound migration practices as the current “as-is” state slowly evolves to the future “should-be” end state. Migration best practices often involve components such as interim bridges and “reverse bridges” between legacy and new components; the “sprucing up” of existing components that—even though they will eventually disappear—need to be enhanced for a short duration to support iterative migration; and thorough integration and interface testing. In many cases, this “short period of time for support” turns into years of effort and needs to be looked at in this light. The business needs to develop a road map and work to be as consistent and practical as possible, but there are some situations that come up that will not allow the business to follow that particular road map. A case in point is the current (2008–2010) economic environment, in which many companies have had to redirect their attention to other, more critical issues in terms of driving sales and growth simply to survive. So, the BI process and projects are then moved from six months to two years in scoping and if these bridges for the current/future view of the reporting strategy are not consistent throughout your company, you will be dealing with other survival issues including the ability to generate useable reports.
One of the points I made in the migration is that you look at new functionality and components with an eye on how this will support our company and not jump from the frying pan into the fire by just adding an additional layer of reporting components to a system that may need some help and is possible broken. It looks great for a time but the issues are still there, just the reports look better and more dynamic. But the underlying data and consistency issues are still there. So, an enterprise’s pursuit of a new era of business intelligence and the resulting timely, actionable, high-value business insight should take advantage of leading-edge core technologies and products but at the same time, the mission-critical nature of what business intelligence should be necessitates being careful and methodical when implementing leading-edge BI products, components, and capabilities, as well as their associated architectures.
BI strategy and architecture teams have a duty to look critically at selected core technologies, products, product families, and architectural frameworks to develop an overall BI architecture and BI road map that is heavily driven by existing, proven technologies and at the same time can support and architecturally evolve toward technologies that are in the pipeline. Most importantly, the teams should be looking to match technologies and products with the BI strategy and documented needs from the business users and community. For example, if it is found that most business processes and analytic needs can easily be satisfied now and in the future by batch-oriented data, the BI strategy and architecture teams should not recommend that real-time data flows dominate the BI architecture. Basically, the recommended solutions should be neither over-architected nor under-architected with regard to likely current and future business needs and requirements.
“Business intelligence” means different things to different people and in a very similar way the concept of a “dashboard” has evolved—locking down a definition of a dashboard is as difficult as getting one definition for business intelligence. All of us have come to understand it in different ways, and we have been witness to customers where we only discovered well into the meeting that when we used the phrase “BI,” one group was talking about a particular product, whereas another group was talking about it in terms of a concept or knowledge area. If such confused conversations are taking place even among business users or groups in the same company, implementers should be very aware of the likelihood that both our customers and other members of the project team have had no prior exposure to the SAP BusinessObjects solutions, and how we have conceptualized business intelligence.
SAP BI Related Interview Questions
|SAP BO Interview Questions||SAP ABAP Interview Questions|
|SAP BW Interview Questions||SAP BPC Interview Questions|
|SAP BODS Interview Questions||SAP BDC Interview Questions|
|SAP BW on HANA Interview Questions||Sap Bapi Interview Questions|
|Sap Business One Interview Questions|
Sap Bi Tutorial
Bex Web Analyzer Reporting Functionality
Getting A Fast Start With Bi Patterns In The Bex Web Template
Basics Of The Web Application Designer
Advanced Configuration Using The Web Application Designer
Advanced Functionality Of The Report Designer
Developing Effective Web Reports
Developing High-impact Dashboards
Migrating 3.x To 7.0 Bex Web Reports And The Wad
Integration Of Sap Businessobjects Components Into The Bi Environment
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.