Abstract
In this white paper, you'll discover what SAP BusinessObjects and Web Intelligence can deliver. When it comes to accessing large amounts of data and then creating customized and sophisticated analytical reports, you'll see why Web Intelligence is a wise choice.
Sample
The life of a business intelligence (BI) developer can be very rewarding, but it can also be challenging to say the least. Every client and every project is different and they always present new and unexpected twists. Being skilled in various technologies is a major benefit. But even if you're an absolute champion in a handful of specific tools and an MVP in a couple of others, being versatile enough to pick up the client's tool of choice and run with it will make all of the difference in the world.
If you're lucky, your client or the company that you work for will have SAP BusinessObjects in place. With this powerful business intelligence platform, you'll be able to create refined analytical documents that can be used throughout your company. It's versatile enough to handle almost any set of requirements and easy to share with your users through a browser-based portal-the BI Launch Pad. Since its biggest strength is with its ability to query multiple databases to create data-rich custom reports, developers have many ways to bring business data to life for analysts to uncover trends and important results.
Even though some users and data consumers generally view reporting as simple and straightforward, most BI team members will tell you otherwise. The reports are the "tip of the iceberg" in a data warehouse. The majority of the work often occurs behind the scenes. Almost all reports are usually always preceded by extracting data from source systems, transforming it into a workable format, and loading it into tables. Reports also include the development of calculations and formulas needed to comply with the business logic that most effectively communicates results to users. And almost all of these steps are never seen or known to report consumers. From a user's perspective, the data warehouse is, simply, the reports and dashboards.
That's why every effort must be made to produce perfect reports. If mistakes are found, your users will begin to lose faith in the entire business intelligence and data warehouse implementation. No pressure. Just be perfect. We'll talk more about this later. But for now, remember these three steps and you'll be on your way to ensuring accuracy and success: validate, validate, and validate.
So how do we as report developers overcome ridiculously challenging requirements? Simple. Push all difficult tasks to the extract, transform, and load (ETL) team to handle. I'm only kidding, of course. We'll be able to handle our share of the workload in our SAP BusinessObjects universes and reports. In all seriousness though, complex data issues should be handled in ETL and at the table level. For additional modifications to data, case logic and other transformations can be applied at the Universe level.
And for more unique and ad-hoc needs, apply IF-ELSE logic to variables and formulas in reports. For the most powerful reports, take advantage of every layer available to you to create an extensive collection of objects with precise definitions.
From Design to Delivery
In this white paper, I'll describe how a report developer can overcome numerous reporting requirements to produce useful documents that meet and exceed expectations. Even with knowledge gaps in both business data and business intelligence skills, SAP BusinessObjects is intuitive enough for intermediate and beginner developers to create valued reports.
Believe it or not, sometimes a project manager (or if you're a consultant, someone from the sales team) will make seemingly impossible promises to the client. This usually includes the amount of time it will take to complete a project or the numbers of developers needed to complete the work. Lastly, the functionality in a dashboard or information in the final report deliverables can also feel like an insurmountable task. While developers will always prefer to "under promise" so they can "over deliver", project managers usually have a good handle on what can actually be achieved, even though they're often accused of over promising.