IBCS – an emerging standard for business #dataviz

In my previous post I introduced the SUCCESS model of Rolf Hichert. In this post I’d like to introduce you to the subject of IBCS – the International Business Communication Standards. IBCS’ aim is to “foster the level of understanding in reports and presentations” (Source: IBCS). Currently, IBCS consists of two main parts:

Notation of meaning
The part “Notation of meaning” describes basically the semantics of a standardized business communication language. It covers all aspects of meaning in the context of business communication and suggests an appropriate notation.

Design of components
The part “Design of components” covers rather the syntactical aspects of a standardized business communication language. It describes the basic report elements and specific rules to use them for the design of objects such as tables and charts. Several objects and additional elements make up complete pages. Although this part should not consider aspects of meaning, but only define the “grammar” of a unified communication language, some overlap to the “Notation of meaning” (semantics) is inevitable. (Source: IBCS)

IBCS and SUCCESS are closely related, therefore I will start with some explenations about how the two topics are positioned against each other. First of all SUCCESS and IBCS can be looked at from a time perspective. Clearly, SUCCESS was developed first:

Folie1

From this point of view IBCS  is a refinement of certain aspects of SUCCESS (namely the Unify part in SUCCESS). This refinement can be seen in the following perspective too:

Folie2

SUCCESS provides only generic guidelines without concrete implementation details, e.g. the following one:

UnifyStandardDimensions

Souce & Copyright: HICHERT + PARTNER

This guideline just tells you: If you visualize this year’s revenue with blue in chart number 1, you should also use blue in chart number 2. But the guideline doesn’t tell you to always use blue. If you wish to take brown for current revenue, it’s OK. Just use brown whenever you visualize current revenue. This and many of the other guidelines (some of them are mentioned in my previous blog post) in SUCCESS I therefore attribute to what I call “common sense” or data visualization basic recommendations. Now IBCS comes into play. Whereas SUCCESS is rather generic IBCS defines the details and writes them down. As indicated above IBCS does this in mainly two parts:

- the notation of meaning clearly defines which elements have which meaning:

UnifyStandardDimensionsIBCS

Source: IBCS

This way business communication should be simplified through standardization the same way as you are used to it with geographical maps for example. Blue always means water, north is always at the top of the map etc. This “semantic layer” is something which differentiates IBCS from other data visualization and information design concepts. Most if not all of them focus on generic recommendations only. In contrast, IBCS wants to harmonize the visualizations in a business context and make them therefore easier to understand.

- the second aspect of IBCS is the design of components

Let’s have a look at the SUCCESS guidline first, e.g. for chart design:

Source & Copyright: HICHERT + PARTNER

Source & Copyright: HICHERT + PARTNER

IBCS gives you much more information, e.g. regarding legends:

LegendsIBCS

Source: IBCS

You can look at IBCS and SUCCESS from a third perspective too:

Folie3

In this perspective IBCS is the solid base with all the detailed rules to consider for efficient data visualizations in business communications. Yet the IBCS rules are hard to digest (as every other industry standard…) SUCCESS can be seen as an implementation methodology of them (as IBCS and SUCCESS are mostly congurent to each other). SUCCESS is an acronym of seven verbs – if you act on them, you’ll see that implementing IBCS is pretty straight forward.

IBCS is work in progress and it is open-source (based on the Creative Commons BY-SA license). Its further development is orchestrated by the IBCS Association which again is run by HICHERT + PARTNER. Simply create a login on ibcs-a.org and start to add your own ideas to further refine and extend the standard.

If you want to learn more about IBCS, SUCCESS and how it can be implemented, join me during the BOAK conference this autumn. It takes place on Tuesday, September 16th in Zurich / Switzerland. In the data visualization track (sessions E1 to E4) you’ll find several sessions dedicated to IBCS. Jürgen Faisst, CEO of HICHERT + PARTNER will elaborate on the goals of IBCS. My friend Lars Schubert will demonstrate how you can apply IBCS using the IBCS certified software “graphomate” as part of SAP Design Studio or SAP BusinessObjects Dashboards. I myself will present together with a customer showing how we implemented an IBCS oriented design in Web Intelligence. The day after I will teach these best practices during a one day workshop. A sneak peek on the Webi reports you can find on my Hichert Certified Consultant page. Looking forward to seeing you during the BOAK conference!

What do you think about IBCS and the semantic layer? Do you think it is worth the effort to harmonize data visualizations in a business context? Just add a comment now!

The bug paradox: When fixing the bug leads to wrong reports

My workmate Christoph Gnodtke wrote an excellent blog about how to identify SAP BusinessObjects Web Intelligence reports which are impacted by various calculation changes in newer BO versions. What I would like to point out here is that not only BO 4.x migrations are concerend but also “simple” service / support package upgrades e.g. from XI 3.1 SP2 to SP6. In my current customer case we’ve found many many reports which obviously were created in a wrong way, namely that the table structure contains the merged dimension (e.g. [Merged Country]) where as the cells within the row use a variable containing e.g. a Where operator using the original dimension ([Query1].[Country]). In our case the business requirement would have been to use the merged dimension here as well. As outlined here, in former BO support package levels a bug resulted in the effect, that the just mentioned example still showed what the business expected. Now (e.g. in XI 3.1 SP6) that the bug is fixed, the reports start to show wrong values. Although the software 360Eyes doesn’t solve the problem, it at least helps to identify concerned reports. Unfortunately we still need to look into every single report and compare between the version running on the XI 3.1 SP2 environment and the SP6 environment. In order to speed up this process we use 360Cast. This software provides similar features like BO Publications e.g. for report scheduling and bursting. The main advantage namely in the case of report testing are two fold (compared to BO out of the box features):

  1. Report selection for a schedule job can be done using good old BO categories. That means you can assign e.g. a test category to all reports you want to test in one single run. In our customer case we use categories for each data mart. In 360Cast, instead of choosing every single report individually, we just choose to select all reports of this test category.
    CategorySelection
    In order to run all these reports with one single click there is just one thing missing: Providing all the necessary prompt values, often the same values for the same prompts (like Year) over many reports. This is where the second advantage comes into play:
  2. To provide prompt values 360Cast accepts both manual input values (where a value can be applied to a all prompts with the same name) but also values from an Excel sheet (or even from an SQL query). We usually use the Excel alternative. Based on this we can easily vary input parameters for different test purporses by simply using another Excel sheet. In addition we can specify the export format and the recipients, e.g. by providing an email address.
    PromptSettingMapping
    (The values in the drop down menues correspond to the columns in the underlying Excel spreadsheet)

After all, also 360Cast doesn’t solve the initial problem. But at least we don’t need to run every report (identified by 360Eyes earlier) on its own but can automate the refresh process and we can easily rerun reports (e.g. with different prompts by simply modifying the values in the Excel list).

Issue with Null Filters prior to Webi XI 3.1 SP6.3

After some more “theoretical” blog posts back in 2013 I’d like to start the new year with a short technical contribution. As some of you may know I’m trying to upgrade the BO XI 3.1 SP2.7 environment of one of our major customers to XI 3.1 SP6. This is sort of a painful experience as we are working on it since more than 12 months now. Still, there is some light at the horizon as back in December Fixpack 6.3 was released which contains an important bug fix. Not to mention that the bug wasn’t yet there in SP2.7 but was introduced somewhen between SP3 and SP6. The issue is referenced in the SAP KB1897777 and it seems to be fixed now.

What is our situation? We have Webi reports containing containing multiple queries and merged dimensions. If we use dimensions from two different queries in the same table, variables as well as filters containing “IsNull” functions do not work properly.

Here we are with the report in XI 3.1 SP2.7:

SP27

Now the result in SP6 (prior to Fixpack 6.3):

SP61

… and finally how it looks like with Fixpack 6.3 applied:

SP63

The tricky part was to detect this error (the above screenshots are very simplified tables for debugging purposes). Obviously even our business users didn’t caught this at first sight. Therefore I’m glad if I can contribute that you double check this if you are on a lower version than Fixpack 6.3. On the other hand: Please let me know if you find other (newly introduced) bugs in FP6.3…

And by the way: Happy New Year and lot’s of fun in the Business Intelligence world ;-)

The Generic BI front-end Tool Selection Process

Finally – I’m blogging again. Time flew by and “my life as a BI consultant” kept me busy with migrations from Oracle to Teradata or from BO XI 3.1 SP2 to SP6. Or maybe you’ve also heard about our BusinessObjects Arbeitskreis (can be translated as “workshop”), I’d call this the “only BOBJ dedicated conference in Europe”: www.boak.ch It was a pleasure to build and execute an interesting agenda for our participants as well as welcoming great people like Jason Rose, Mani Srini, Saurabh Abhyankar, Mico Yuk or Carsten Bange. I also had the pleasure to do the closing key note during BOAK. It was around BOBJ front-end Tool Selection. I used this opportunity to further develop a generic yet simple method how to approach the frontend tool selection. The basic idea I formulated already in my last blog post back in April 2013. But I agree with some of the comment writers that this first rule of thumb was maybe to specific to be applied in all situations. Therefore let me share what I think is a more generic approach – by the way you can use this of course for other BI vendors and not only SAP BusinessObjects (the following illustrations are just examples – the listed and selected tools don’t have any concrete meaning!):

PART A: Preparation
Step 1: List all available BI front-ends

The first thing to do is to get an overview what BI front-end tools are available in general from a specific BI vendor. As I’m a big fan of working interactively with people, e.g. gathering in front of a whiteboard or flipchart, I suggest you write down product names to sticky notes and post them on the flipchart:

Step01

Step 2: Divide tools into “in scope” and “out of scope”

Depending on your environments you can do a first, yet very rough tool selection and divide the intially listed tools (see step 1) into two groups:

“Out of Scope”: This is maybe easier to start with: If you don’t have SAP BW as a source, you can eliminate all tools working with BW only. Or if your security policy prohibits the use of Flash, maybe Explorer or Xcelsius are out of scope a priori.

“In scope”: All the tools which are not out of scope.

Step02

PART B: Build a working hypothesis
Step 3: Select the tool which covers most of your requirements

This step assumes that you have quite a clear understanding of your business needs to be solved with a BI solution. I’m fully aware that this is often not the case. But to keep the basic process for tool selection as simple as possible I won’t go into details about how to find the “right” requirements. Not yet, but maybe in a further blog post.

Anyway, let’s represent the total amount of requirements symbolically as a circle. Now think about which tool has the broadest coverage of your requirements. Take the sticky note and put it onto the circle. Please be aware that this is only a “working hypothesis” – trust your gut feeling – you can always revise your tool choice later on in the process.

Step03

Step 4: Select the tool which covers most of your left over requirements

Repeat step 3 and think about the tool which might cover most of your left over requirements and put the corresponding sticky note into the circle.

Step04

PART C: Validate your working hypothesis

Nothing is more annoying than “strategies” which exist only on paper but cannot be transformed into reality. Keep in mind that you’ve just built what I call a working hypothesis. Now you should validate it and test against the reality. It will either prove your gut feeling regarding tool selection was right or wrong.

So far you have selected two tools. They represent a selection hierarchy. For any given or new requirement (or group of requirements) you should now do a hands-on test. Always start with the first chosen tool: How well can you implement the requirement? Does the implementation fullfil your expectations? What do your end users think about it? Do they like it? For now I leave it up to you to define the “success criteria” to decide in which case a prototypic implementation passes the hands-on test and when not. Anyway, if the implementation passes the hands-on test, you should go with tool #1 for this kind of requirement now and in future situations.

If the implementation fails the hands-on test for tool #1, go forward to tool #2 and do a hands-on test again with this one. Hopefully your prototypic implementation now passes the test and you can define to go with tool #2 for this kind of requirement now and in future situations.

Step05

What happens if a prototypic implementation fails the second hands-on test too? There are three alternatives:

  • If you fail the second hands-on test for let’s say <10% of requirements, you should think about a specific solution for these obviously very special requirements: Mabye you simply continue to solve these requirements “manually” in Excel? Maybe you need to buy a niche tool for it? Just find a pragmatic solution case wise.
  • If you fail the second hands-on test for let’s say <30% of requirements, you should think about adding a third tool to your tool selection hierarchy.
  • If you fail the second hands-on test for let’s say <60% of requirements, you should definitely revise your working hypothesis and play through another tool selection hierarchy.

Closing Notes

I’m fully aware that the outlined process is simplistic. That’s why you might not be able to use it “as is” in your current frontend tool selection project. But it shows the basic idea (namely to build a tool selection hierarchy and validate it with hands-on tests) on how to narrow down the number of useful tools in a given context – and it is your job to apply respectively adapt it to your environment. Let me know what you think about it – and how it works in your environment!

The Rule of Thumb for BOBJ Tool Selection

What is the right SAP BusinessObjects frontend for a given situation? A question I’m asked nearly every day. When I was confronted first with this topic  a few years ago the taken approach was a highly sophisticated Excel spreadsheet in order to assess all available BOBJ tools based on a feature list. The only problem was: At the bottom line there was never a clear winner. Next approach were the famous decision trees like the following:

BO-Tool-DecisionTree

Not bad as a first guess. And in an ideal world where the basic functionality would be the same for all BOBJ tools such a tree could work indeed. But given the situation that even today – nearly ten year after the aquisition of Crystal by BO – support for universes is still not exactly the same in Webi, Crystal Reports and Xcelsius (aka Dashboards) and especilly the maturity of a tool or a sub component of it is vastly different, there is no clever way to tell you which tool to use for which purpose.

Although you can’t give a distinct answer to the question “which tool to use for what”, I’m convinced that the following rule of thumb will be valid in most situations and for a majority of organisations – the only assumption is that there is no limitation out of licensing. That means I assume you have a license for all or at least the most important frontend tools. The idea behind this rule is that a priority rating is more helpful than a feature or use case driven decision tree.

Here is my rule of thumb:

  1. Try it with Web Intelligence
  2. If Webi didn’t work, try it with Crystal Reports
  3. If Crystal Reports didn’t work, try it with one of the “niche” tools

Let me share some thoughts about this priority list:

Why should we start with Web Intelligence? There are various reasons for this:

  • From a features perspective Web Intelligence provides the most widest range in the BOBJ tool suite. You can use Webi for creating classical standard reports, you can use it for dashboard like applications (think about Input Controls and the ease of use regarding drilling – e.g. compared to Xcelsius…), you can use it for self-service reporting, you can use it as a data pump using XLSX export or interface to other applications using BI Web Services etc.
  • From a maturity perspective it is one of the most stable and mature applications in the BOBJ world. I tell you this as an native “Crystal guy”. But whereas Crystal Reports 2011 runs stable the same way as it did for the last decade, the new Crystal Reports for Enterprise is just crap compared to both, the legacy CR and Webi.
  • From a data source perspective: Webi is the only tool which fully supports all kind of Universe stuff. I’ve never heard of any limitation that Webi would not support something what you can do in a Universe (by design). But let me compare this to Crystal Reports: On one hand you can use only UNX universes in CR4Ent, on the other not all type of queries are supported. Crystal still has the limitation that if a universe query results in multiple SQL statements it fails to handle it as there is no local “micro cube” as with Webi. Of course this whole argument implies that we value a “common semantic layer” to be of high “added value” to an organization and therefore should be supported in its full scope. But there is even more to add: Webi handles not only multiple SQL result sets per query, it can also leverage multiple queries and easily join them. Although I’m not a friend of “merged dimensions”, there are many situations where this capability is the only work around to get the job done at the end of the day (and not three monthes later when the data finally arrived in the DWH…). No clever way to do this in Crystal Reports or Xcelsius directly.
  • From an SAP BW perspective: Two or three years ago we had to decide for Crystal Reports often because of its better connectivity to SAP BW and all around it with hierarchy handling etc. These days are “passé”. My most recent experience with Webi using the BICS interface are very promising. Totally in contrast with CR4Ent which crashes regularly, even with the latest patch level.
  • From a usability perspective: Although SAP currently tries to position Webi to be the tool where business users develop the reports, I think its usability is equivalently valubale for IT folks too. Report development is quick and straight forward – once you’ve got used to the ribbon style menues ;-)
  • From an installation footprint perspective: Given the situation that SAP releases new patches nearly every third or four week, patching client installations is an nightmare. The more valuable are fully web based deployment scenarios. Therefore once again, Webi is the favorite.

Still, Web Intelligence has some short comings. That’s why you should evaluate Crystal Reports in a second instance:

  • One of the major differentiators between Crystal Reports and all the other frontend tools is Conditional Formatting. As you may know Crystal Reports has a powerful formula language integrated. This formula language can be used to control neary every property you can set in Crystal Reports. This way you can implement what I call “guided interactivity” at its best: Let the end user choose some parameter values and use these values to control both, the data in the report but especially the layout too. The typical use here is: A customer wants to build 10 similar reports. They are not exactly same regarding the layout, but similar. For example, in Webi there is no straight forward way to show conditionally show or hide some parts of the report. In Crystal Reports such a thing is a no-brainer.
  • Interactive / proactive Alerts: As of today, only Crystal Reports based alerts can be used to send an email notification if they are triggered.
  • Export formats: Crystal Reports has a multitude of available export formats, including Word or XML, which aren’t available in any of the other tools.
  • Hierarchical Grouping for relational data sources: Crystal Reports can dynamically resolve a Child-Id-to-Parent-Id relationship and apply calculations over such a hierarchy.

But before you choose Crystal Reports remember there are two versions of Crystal Reports: The legacy Crystal Reports 2011 and Crystal Reports for Enterprise. The first one is mature and stable, but does not contain new features introduced only to CR4Ent. On the other hand, CR4Ent is a de facto “1.x” product regarding its code maturity. For now I simply cannot recommend to use it as your major reporting tool without intensive testing of your own use cases in your environment. On the other hand – depending on your situation – the legacy Crystal Reports does not support UNX universes at all nor does it support UNV universes as you’d expect it coming from Webi.

What about all the other tools? I call them “niche tools”. This is due to the fact that all of them have quite a narrow scope of application compared to the “generalists” Webi and Crystal, let me name a few:

  • SAP Visual Intelligence: This is a great tool for ad-hoc-analysis. But that’s it. No way (yet) to publish documents online (except over Explorer), schedule them or create more sophisticated standard reports.
  • Explorer: Not the most mature product, especilly in the context of SAP BW and BWA as a datasouce… In general, Explorer is nice for “standard” visualizations. But have you ever tried to customize even basic elements of these charts? Or have you tried to add a simple table into an Exploration View? Or export an Exploration View as a whole? As of today these basic things seem to be impossible…
  • Analysis, Edition for OLAP: Limited to OLAP data sources, no clever integration into scheduling, publishing etc.
  • Analysis, Edition for Microsoft Office: Only BW support…
  • Dashboards / Xcelsius: Limited capabilities in terms of data volume that can be processed, no straight forward way to realize drill downs, no common export formats, no full Universe support, no scheduling capabilities…
  • Design Studio: Not usable for productive environements in the current version 1.0, and even for subsequent versions I’m very sceptical… In addition the scope of the tool is focused on BI App development which as such is clearly a niche.

This doesn’t mean that these tools are not valuable in the context of specific requirements. But assuming that there is a value in reducing the number of used and supported tools to a minimum, these tools should be chosen only after having evaluated Webi and Crystal beforehand. According to my experience chances are quite high that your requirements can be covered by one of these two tools.

What is your experience with tool selection? Would you agree with my rule of thumb? Anything I missed? Looking forward to reading your comments!

BO 4.0 FP3: get eFashion and other MS Access datasources working

I’ve just noticed a problem with our IT-Logix Migration Assessment Environment. The problem is with eFashion and other MS Access based demo databases, namely that you get the following error in (online) Webi, both on BO 4.0 SP02 as well as with FP3 – due to 64bit connectivity problems:

You don’t get the error in Webi Rich Client usually. In this post I will quickly outline the reasons for this and how to solve it:

First of all: Others got these errors too:

http://scn.sap.com/thread/2118132

http://scn.sap.com/thread/2043784

The answers from SAP (namely http://scn.sap.com/people/henry.banks) are not really satisfying. Of course it is not very clever to use Access as a demo datasource – but why SAP then provides these (access based) samples in BO 4.0 and not e.g. within the database they include within the setup? Anyway, there are three options you can choose:

  1. Move your efashion and other MS Access databases to a “real” database like SQL Server (Express), MySQL etc. It must be just accessible by 32 AND 64 bit drivers.
  2. Migrate to BO4 FP3 – and read the rest of the blog of how you can get Access databases running…
  3. If you are on BO4 SP2 – sorry, I don’t know a way how to get Access running on a 64bit driver – if you are interested in the reason, read on… (If you know another solution, please post a comment!)

In BO 4.0 still all the client tools (like the Webi Rich Client) use 32bit drivers. Regarding eFashion this is not a problem as any default Windows XP / 7 / Server will provide preinstalled drivers. The BOE setup will automatically create the corresponding 32bit-ODBC datasources. Therefore you’re all fine.

On server side it is important to note that e.g. Webi Processing Server always uses 64bit drivers. As far as I can overlook it as well for MS Access. But these 64bit drivers seem not to be installed by default, at least they weren’t on my cloudshare.com environments. In addition there is a strange thing that the BOE setup creates both, 32bit as well as 64bit ODBC connections for eFashion and club.The below screenshot shows the 64bit ODBC Admin (trust me :-)

But be careful: Whereas the 32bit ODBC connections work fine at least on my side I got the following errors when I wanted to modify e.g. the efashion connection:

If you want to create a new ODBC connection you will notify there are no 64bit drivers installed for MS Access:

My suggestion to solve this is to go here and download the Microsoft Access Database Engine 2010 Redistributable – because there is a 64bit setup / drivers for this:

http://www.microsoft.com/en-us/download/details.aspx?id=13255

Download the 64bit setup… and run it:

Finally your 64bit ODBC Admin “Add connection” dialog should look like this:

Now you can create the efashion, efashion-webi etc. data sources. Make sure you write it absolutely identical as it is written in the 32bit ODBC connection!

So far everything works fine for both, BO 4.0 SP02 as well as FP3. As usual there is a big BUT: You will still get the same errors shown right at the beginning of this post. Remember, you just installed the Access 2010 redistributable. This means you have to change your universe connection to use the appropriate driver (for this log in to Universe Design Tool and choose Tools – Connections). And here is, where at least I had to say there is no (obvious) way of how to solve it with SP02:

Sorry guys, no Access 2010 support in BO 4.0 SP02. But at least FP3 provides something for us:

And finally it should work. To sum up:

  1. On a BO 4.0 FP3 server install MS Access 2010 Redistributable 64bit
  2. Create necessary 64bit ODBC connection
  3. Modify your universe connections to point to the Access2010 driver
  4. have fun with efashion ;-)

PS: I don’t have any issues with our BO 4.0 SP02 environment which has SP02 installed only as a Patch. We installed this environment during ramp-up for SP02 (in these times Webi was still labeled Interactive Analysis, that’s why I noticed the difference…) and only later applied SP02. I didn’t investigate, but it seems like Webi Proc servers uses 32bit drivers here… (no 64bit drivers for access installed on this system…)

PPS: Don’t have FP3 available but you ‘d like to test yourself? I can get you easily access to copy on cloudshare.com – see the corresponding blog post.

Do you have similar experiences? Any other hint I missed? Please post your comment.

BO 4.x Migration Challenges

I plan for a few blog posts around migration to the next major SAP BusinessObjects release. This first one is about the challenges in general. It does not cover the setup of the BO 4.x BI platform as such (might be worth a separate blog…) and the question whether you’d better go directly to Feature Pack 3 (now in ramp-up) or if you start with the currently available version of Support Package 2.

Overview of Major Challenges

  • Which reports to migrate?
  • What happens to still existing Desktop Intelligence reports and especially corresponding report instances?
  • Do you want / need to rework your access management settings during the migration?
  • Should you plan for a “big bang” migration or better in smaller pieces? If yes, how do you deal with the parallel operation of two BO versions (e.g. regarding client tools?)
  • How can you check a migration was successful?
  • Do we have enough licenses?
  • How much education is needed for administrators and end users?

In the rest of this blog I gonna detail on these points.

Which reports to migrate?

The less reports and universes you have to migrate, the less effort you have to invest in the migration and the subsequent testing procedure. Therefore you should try to identify unused or duplicated reports before doing the migration. Think about all the possible copies of reports residing in user’s favorite folders or inboxes. Do you really want or need to keep them?

What about Deski?

Desktop Intelligence is now definitely end of life and not existent anymore in BO 4.x. In theory you can convert Deski reports into Web Intelligence reports. But there are still differences which – depending on your reports – might force you to rebuild some reports manually in Webi. Have a look at this blog from Michael Welter / @UniversePro : http://michaelwelter.wordpress.com/2012/04/19/deski_webi_delta/

A typical challenge I encountered is that many Deski users don’t use the central repository of BO. They use the tool purely as a desktop application, that means as an administrator you don’t know exactly how many Deski reports exist out there or how often a report is used. Unfortunately the BO Audit functionality does not properly track local Deski usage.

A specific other problem might be that you cannot convert Deski instances to Webi. Therefore think about whether you need to keep them somehow or if you can drop them once your BO 3.x system is taken offline.

The migration itself

Typically you don’t want migrating waste. This is true for access rights too. A migration is always a good point in time to tidy up and realign things.

Especially in larger BO environments I recommend not to do a “big bang” migration. Anyway you will usually migrate the same content more than one time. First, after having installed the new software release, you might want to do a test migration and let some end users test on the new platform. In parallel the still productive system XI 3.1 continues to run. Therefore you’ll have to reimport content before you go live with your BO 4.x system. Metadata reporting tools can help you to compare contents between the old and the new system and therefore make sure everything was moved successfully (I will address this in a separate post later on).

Especially in case of a partial migration approach you need to think about side-by-side installation of client tools. Unfortunately this is not trivial as e.g. there might be conflicts with Web Rich Client:

Understand Side-by-Side Client Installation

Understand Side-by-Side Client Installation

(Source: http://wiki.sdn.sap.com/wiki/display/BOBJ/All+you+need+to+know+before+upgrading+to+BI4.0)

Licensing

You should consider the following paragraph in the Admin Guide (p. 84):

The BusinessObjects License Measurement Tool (BOLMT) is a java command-line utility used to collect and store BI platform licensing data. The output XML document contains license deployment measurements and is sent to SAP Global License Auditing Services (GLAS) for consolidation as part of a license audit.

Except you or your customer has an “all you can eat” license for your BO system this might be of interest to you. The availability of certain features in BO are not enabled or disabled by the license key. It is purely a matter of access rights how many users can use such a feature. In XI 3.1 and earlier nobody really cared about this as there was no direct possibility available for BO / SAP to verify license compliance. With BO 4.x this is different and you’d better think of your license situation before you migrate.

Education

Many things in BO 4.x are “somehow” new to existing administrators and users. What do I mean with “somehow”? Let’s take Web Intelligence: There are now ribbon toolbars and the more experience you have with Webi the more you’ll ask yourself where things have moved to. A well done overview the new Webi you’ll find here: http://michaelwelter.wordpress.com/2012/04/18/impressions-of-web-intelligence-4-0/

Another example is Crystal Reports for Enterprise: It is not completely different compared to its “origin”. Nevertheless it took me quite a few hours of struggling with the new interface and differently labeled functionality…

More different compared to its predecessor is the Information Design Tool. Although the basic principles of how to design a Universe remain the same, the approach and architecture of the new semantic layer (= UNX universes) is something you should invest some time to get up and running. A good starting point: http://michaelwelter.wordpress.com/2012/03/21/impressions-of-information-design-tool/

All taken together: Yes, both administrators as well as power and end users need additional education and training to enable a smooth transition from XI 3.1 to BO 4.x.

Additional Link

An additional link and quite good summary of materials for your migration you’ll find here: http://scn.sap.com/docs/DOC-25474

What is your experience with the migration to BO 4.x? Any migration specific aspects I missed?

Follow

Get every new post delivered to your Inbox.

Join 515 other followers