Throughout the lifecycle of a popular product or organization, you can expect names to evolve and change.  Since the acquisition of Business Objects by SAP, however, this has become a much bigger problem.  SAP likes to use “descriptive names” for their products, so they pick names that generically describe what the product does.  It seems like they went down that path for some products (i.e. Xcelsius) but reverted back to the original product names for others (i.e. Web Intelligence).  What we’re left with is a collection of names that may or may not mean something to us.

This post is meant to clear some of the confusion around this renaming, and provide a bit of insight into what each product is used for.  (That is something I often get asked by clients and prospects alike.)  As new products are release/renamed, we’ll update the post to reflect those changes.  For now, you can use it as your starting roadmap to SAP BusinessObjects naming clarity.

SAP BusinessObjects 4.0

This is the name of the complete BusinessObjects release, including BI & EIM
(aka SAP BusinessObjects XI 4.0, SAP BusinessObjects XI 3.x, etc…)

SAP BusinessObjects Business Intelligence 4.0

This is the name of the Business Intelligence components of the release

SAP BusinessObjects Business Intelligence platform

This is the name for the BusinessObjects product bundle for Enterprises
(aka SAP BusinessObjects Enterprise XI 4.0, SAP BusinessObjects Enterprise XI 3.x, etc…)

SAP BusinessObjects Web Intelligence

This is the ad hoc reporting component of the Business Intelligence suite.
(aka SAP BusinessObjects Interactive Analysis, Webi)

SAP BusinessObjects Dashboards

This is the version of Xcelsius designed to be part of a larger SAP BusinessObjects deployment.  Other ‘flavors’ of this tool may be branded under the SAP Crystal solutions banner.
(aka SAP BusinessObjects Dashboard Design, SAP BusinessObjects Xcelsius, Xcelsius Enterprise)

SAP BusinessObjects Analysis, edition for OLAP/edition for Microsoft Office

This is a new product that replaces the Voyager product.
(aka SAP BusinessObjects Advanced Analysis Web/SAP BusinessObjects Advanced Analysis Excel)

SAP BusinessObjects BI Launch Pad

This is the new name for the out-of-the-box portal that’s used by end-users to access content, create reports, etc…
(aka SAP BusinessObjects InfoView, Infoview)

SAP BusinessObjects BI workspaces

This product is replacing the functionality of Dashboard Builder.
(SAP BusinessObjects Dashboard Builder)

Related posts:

1. 5 Reasons Why You Should Use SAP BusinessObjects Universes
2. SAP BusinessObjects Enterprise 4.0 Ramp-up and Analysis!

I recently published the post 5 Reasons Why You Should Use an SAP BusinessObjects Universe to highlight some of the core benefits you’ll see when implementing the semantic layer for you organization.  The post was derived from speaking with organizations new to the Business Objects world about the benefits of leveraging the semantic layer. Throughout those talks, I also get to hear a lot of misconceptions about SAP BusinessObjects Universes.  Sometimes they are born out of a simple lack of understanding of the SAP BusinessObjects architecture, while other times they are propagated by competing business intelligence vendors.  (Shocking, I know.)

In any case, I’m here to set the record straight.  While the universe semantic layer isn’t perfect, it is pretty good at what it does and keeps getting better.  Here are some common misconceptions that I’ve heard over the years.  Did I miss any?  Let me know in the comments…

Universes affect query performance by adding unnecessary overhead.

False. In its simplest form, a universe is merely a semantic layer that maps your database objects to standard business terminology to provide an intuitive way to work with information.  When queries are refreshed, the business terminology is turned back into SQL and executed on the appropriate database directly.  If your query has three items in it, so will the resultset coming back from the database.  There aren’t any middleware components or services that add overhead to this process.

The Universe is simply a cube of my data, formatted for reporting.

False. (See above.)  The data returned by your universe continues to reside wherever it does today.  The universe semantic layer simply defines how those tables are joined, how the objects are defined, etc…

I need to have a data warehouse or data mart to be able to use a Universe.

False. While query performance will generally be better if running against a schema designed for reporting (i.e. data mart/data warehouse), as a technology Universes are equally at home pointing directly to data contained in CRM, ERP and other transactional systems.  We often use this method when implementing operational reporting, where our client needs real-time access to their raw transaction information.

I can’t use a Universe because I want to aggregate by different dimensions depending upon the report.

False. When developing a universe, you simply define how objects should aggregate – sum, avg, count, etc… -  not specific dimensions by which to aggregate.  By properly using SQL Aggregation and Measure Projection in the definition of your universe objects, the result set will dynamically aggregate at whatever level is appropriate given the dimension objects you selected.  If you select ‘Year’ and ‘Total Sales’, the query will return one row for each year showing total sales.  Add ‘Product Line’ to the query, and now you’ll have one row per year per product line, etc…  All of this done automagically by the universe.

Our application uses a proprietary database, so it won’t work with a Universe.

False (sort of). In general, as long as the vendor provides an ODBC driver for the database you should be able to access it’s information through the universe using a Generic ODBC connection.  However (and it’s a big however) the functions that you can use in the universe are limited to those that are supported by the ODBC driver.  If you’d like to roll up all the sales by year and the driver doesn’t support a Date function to do that, you’re out of luck.  (Obviously you could still do these conversions at the report level, but that’s a different topic as we’re talking specifically about universe functionality here.)

At any rate, this lack of support has more to do with the specific ODBC driver than the universe, as you would run into the same issue no matter how you tried to access that data.  In these cases, we typically evaluate the reporting requirements alongside the capabilities of the ODBC driver itself before making the decision to move forward with the generic driver, or work towards getting the data into a more standard database platform.

Question:  What misconceptions have you had/heard about SAP BusinessObjects Universes?

Related posts:

1. 5 Reasons Why You Should Use SAP BusinessObjects Universes
2. What is a Business Objects Universe?
3. Exploring 4.0: Information Design Tool

In meeting with organizations who are new to SAP BusinessObjects or who are legacy Crystal Reports users, we are often asked the question “Why should I use a Business Objects Universe?”.  To organizations who have worked with universes for a period of time, the advantages and value proposition are clear.  But for organizations who are new to universes, it can often be a challenge to quantify the value of the semantic layer.

In this post I hope to outline a few of the reasons why we recommend implementing universes, even if you’re not using an SAP BusinessObjects tool that specifically requires them.

Integrated security

One of the most common ways that security is implemented into an SAP BusinessObjects Universe is to dynamically restrict data being returned by a query.  In this example, only sales belonging to the user that ran the report or viewed the dashboard would be shown.  You can also use this technique to segregate data by customer, regional manager, product division, warehouse, etc… to give everyone a personalized view of their information.  But that’s just the beginning.

You can also use the built-in universe security to restrict access to particular objects (such as salary or SSN), control the types of queries a user can run, change the database connection depending on the user, and even dynamically map to other tables.  Leveraging the universe model gives you complete security over your environment, and the best part is you only have to apply the security once and it takes affect whether the user is refreshing a canned report, viewing a dashboard or creating their own ad hoc report.

Single version of the truth

We’ve all been there.  You’re at a meeting discussing sales numbers and three people give three different answers on what last month’s sales were.  The Sales Manager defines it as bookings made.  The Warehouse Team counts only orders that were physically shipped out the door.  And Finance, well they pull a bunch of different information into their spreadsheet and come up with a third version.  They may all be correct, but they’re also all wrong.

Building a universe layer “forces” you to come together and define the terminology that you use, perhaps in the case above creating separate “sales” and “shipments” measures to satisfy everyone’s reporting requirements.  When reporting through the universe, everyone in the organization will benefit by having access to the same information, defined in the same way, using the same calculations.

Build once and reuse

Some of the clients we meet with, particularly those that have been using Crystal Reports for some time, are resistant to using universes because “it would be easier to just hardcode the SQL” or “our data structure is too complex”.  Sure, it may be easier the first time to hardcode a SQL query into a report, but what about the second, fifth or tenth time you have to do that?  And as for the data being too complex, with few exceptions if you can define it in SQL you can build it into a universe.  This ability to define the universe semantic layer one time and leverage it across the entire SAP BusinessObjects toolset is huge.

Maintenance/change management

Perhaps one of the most overlooked benefits of utilizing the universe layer is around maintenance and change management.  With the universe model all of your logic is in one place, making maintenance straightforward.  Plus, if the data model for any of your upstream systems changes, you can in most cases modify the universe to reflect those changes without having to touch any of your downstream reports, dashboards or analytics.  Just imagine if you had 2,000 reports written against hardcoded SQL sitting on top of a data model that has now changed radically in a new release.  I’ve seen it happen, and it wasn’t pretty.

Intuitive interface for developers and end-users

This is what it’s all about: providing end-users and developers alike with a drag and drop interface where they could build reports using business terminology rather than SQL code.  Which is more intuitive to an end-user: SUM(DB_AdvWorksDW.dbo.FactResellerSales.SalesAmount) or ‘Sum of Reseller Sales’?  Now imagine this simple example using CASE statements, datatype conversions, etc… and you’ll understand the true power of the SAP BusinessObjects universe.

In using the universe layer, report authors and developers can reference information in common business terminology, and be shielded by all the technical complexity and transformations that are happening behind the scenes.

Want to learn more?

There are many benefits to using the Universe model, these are just a few of the most popular.  Want to learn more?  Call us at (877) 844-7476 or email info@alteksolutions.com to see how you can leverage the power of the universe for your organization.

Question:  Does your organization utilize SAP BusinessObjects universes?  If so what advantages do you see, and did you find any downsides?  If you don’t use universes, why not?

Related posts:

1. Top 5 Misconceptions About Business Objects Universes
2. Maintain Peak Performance With a Comprehensive SAP BusinessObjects Health Check
3. Five Reasons Why Ad Hoc Reporting Won’t Work in Some Organizations

I recently posted “Five Reasons Why Ad Hoc Reporting Won’t Work In Some Organizations“.  In that post, I listed some of the major concerns that I hear from potential clients when the subject of ad hoc reporting is broached.  As promised, I will be addressing each of those concerns and showing how they can be overcome.  Today, we begin with the first one: “Our people aren’t smart enough to create their own reports”

As I mentioned previously, I hear this one way too often and it usually is a case of not understanding the capabilities of a well-designed Business Intelligence solution.  Managers are concerned (and rightfully so) about the level of training their users will require, their ability to understand how the data fits together, etc…  But it doesn’t have to be a concern at all.

With the breadth of tools and capabilities that are available in today’s BI solutions — and with a solid understanding of the user’s requirements for ad hoc information access — it can be relatively easy to build a solution that delivers on those requirements without requiring a huge investment in training.

Let’s first take a step back to look at what ad hoc reporting really means.

What is Ad Hoc Reporting?

When a client tells me they are interested in implementing ad hoc reporting, I always ask them to define that for me. My experience tells me that people often have varying views of what ad hoc reporting really is, including:

• Ability for a user to refresh a report themselves and fill in prompts to filter the results
• Ability to perform simple queries or ask simple questions of the data to find the information they need
• Ability to create production-ready reports themselves.

When someone in the SAP BusinessObjects world says “ad hoc reporting”, they typically are referring to the WebIntelligence product.  But as you can see there are a variety of other tools that can be used to satisfy those needs — depending, of course, upon your definition of “ad hoc”.

Using SAP BusinessObjects Tools to Support Basic “Ad Hoc” Reporting

1. Crystal Reports
   While certainly not a tool that I would give to untrained end users, Crystal Reports themselves are an excellent way to implement  “filter and refresh adhoc”.  These reports could also include interactivity to drill into the hierarchy of the data, link to more detailed reports, etc… making it a great way to build a sandbox for simple interactive, ad hoc reporting
2. Xcelsius
   While typically thought of as a dashboard/visualization tool, Xcelsius can also be used to assemble easy-to-use ad hoc sandboxes.  Using filters, drop-down lists and the like, IT can deliver visually stunning, interactive “ad hoc” reporting to end-users.
3. Explorer
   Finally, SAP BusinessObjects Explorer provides search, exploration and visualization — much in the way I’ve described above in allowing ad hoc reporting within a predefined sandbox.

Depending upon your needs, this level of ad hoc reporting may be enough.  In fact, it will probably satisfy most ad hoc information needs.  If you need to move beyond that, however, read on for some tips on how to create a true ad hoc environment with SAP BusinessObjects that people can and will use.

A Few Tips for Creating a True Ad Hoc Environment

Even if you need to deploy true ad hoc reporting, it shouldn’t be cause for alarm.  While there will always be some degree of a learning curve in terms of creating queries, formatting the report, etc…, there are a few steps we can take to minimize the training required.

1. Focus on Subject-specific data
   Throughout my 10 years as a BusinessObjects consultant, I’ve seen a lot of styles of Universe development.  Strike that.  I’ve fixed a lot of styles of Universe development.

   While I suppose it’s noble to develop a universe that contains every bit of information a company needs, if that universe contains 50 classes, 1,200 objects and 9 contexts…I respectfully say you’re missing the point.  (This isn’t an extreme example…unfortunately we’ve seen fixed much worse.)

   Our methodology for developing ad hoc BusinessObjects universes is to focus on a specific subject-area, and provide all the information a would-be end-user needs to answer a specific set of questions.  No more.  No less.

   Instead of developing a “Finance” universe, think about developing one universe for Accounts Receivable, one for Accounts Payable, one for the General Ledger, etc…  Not only will the universes be easier to use, but they’ll be infinitely easier to maintain as well.

2. Start with the data in the correct format
   With SAP BusinessObjects, you have a number of opportunities to get the data in the correct format for a given analysis: at the database level, in the universe, and in WebIntelligence report itself.  And I recommend tackling it in that order.

   If you can “fix” the data at the database level, do it.  Not only will it be easier to develop the universe if the data is structured for reporting, but you’ll also likely gain performance advantages along the way.

3. Build as much business logic into the Universe as possible
   Continuing on with the theme from #2, try to push as much business logic to the universe level so end-users won’t have to worry about data aggregation, calculating averages, grouping data together, etc…Once we understand the specific requirements, we work hard to make the ad hoc environment as close to “drag and drop” as possible.  The less the end-user needs to do to get the results they’re after the better.

That’s it for part 1, “Our people aren’t smart enough…”.  Stay tuned for our next “objection” to implementing ad hoc: “”We usually need to massage our data…”.

Question:  How does your organization use ad hoc reporting?  If you’re utilizing true ad hoc reporting, what steps have you taken to make the environment as easy-to-use as possible?

Related posts:

1. Why Ad Hoc Reporting Won’t Work (part 4): I Pay People in IT to Create Reports
2. Why Ad Hoc Reporting Won’t Work (part 3): I don’t want people poking around in data they shouldn’t have access to
3. Why Ad Hoc Reporting Won’t Work (part 5): If I Give Them Ad Hoc Access to Data, They’ll Keep Asking For More

I’m a firm believer in the solution selling approach, so most of the demo time is spent focused on solving the client’s specific issues.  However, I do like to briefly review the rest of the SAP BusinessObjects product stack for a number of reasons:

1. As a visioning workshop to show them the other tools and technologies they might be able to apply to their organization (you don’t know what you don’t know);
2. To demonstrate how SAP BusinessObjects has the breadth of products to deliver true end-to-end business intelligence; and
3. To head off any potential competitors who try to tout their product of having something that the client isn’t aware of SAP BusinessObjects having.

My demo subjects always welcome this quick look, and oftentimes end up utilizing some of the components that they were unaware of previously.

I’m always struck, however, when we reach the ad hoc portion of the demo and begin talking about WebIntelligence.  While the end-users in the room get excited about having the ability to create their own reports and analysis without waiting on the IT department, we usually get a lot of push-back from the managers and executives in the room.

Don’t get me wrong.  SOME progressive executives “get it” right away.   But the vast majority that I’ve met with are initially resistant to the idea, until I’ve had some time to address their concerns.

It could be a fear of the unknown, or maybe they’ve been burned before by another reporting tool.  In any case, I always get some interesting commentary on how their organization is unique and why ad hoc reporting won’t work for them.  It’s always an eye-opener for me, and it gives me a chance to peak inside the organization’s culture.

I’ve compiled a list of some of the major concerns I’ve heard here, and will address each of them in an upcoming post.  In the meantime, please comment on concerns with ad hoc reporting that you’ve seen in your organization, and what the outcome was.  I would love to include your comments in my response.

1. Our people aren’t smart enough to create their own reports (believe-it-or-not I’ve heard this many more times than I care to acknowledge)
2. We usually need to “massage” our data a bit to make sure it is correct before sending out a report
   
3. I don’t want people poking around in data they shouldn’t have access to
   
4. I pay people in IT to write reports, why should I train end-users to do it?
   
5. If I give them ad hoc access to data, they’ll keep asking for more data / others in the organization will ask for ad hoc access
   

What concerns do you have/have you had with ad hoc reporting in your organization?  What were the results?

Related posts:

1. Why Ad Hoc Reporting Won’t Work (part 1): Our People Aren’t Smart Enough
2. Why Ad Hoc Reporting Won’t Work (part 5): If I Give Them Ad Hoc Access to Data, They’ll Keep Asking For More
3. Why Ad Hoc Reporting Won’t Work (part 3): I don’t want people poking around in data they shouldn’t have access to