The Hidden Properties of SAP Business Objects Dashboards

Aka: What to do when the Properties window of SAP Business Objects Dashboards isn't visible.

Having had this happen to me three times now on three separate laptops, and also having spent, and lost, countless hours looking (largely unsuccessfully - until now) for a way to remedy the situation I thought this one deserved a blog post. So here goes. Hopefully the next person who strikes this problem can solve it with a five minute Google rather than a five hour session of window movement and software uninstalls and re-installs.

My problem originally occurred with SAP Business Objects Dashboards 4.0. I'd been happily working with the product for about a year with no problems until one morning I plugged in my laptop and opened up an existing dashboard to find that the Properties window was nowhere to be seen. No matter what I did I couldn't make it visible. I tried everything I could think of:

• A Google search;
• An SCN search;
• Right-clicking an object and selecting Properties;
• Highlighting an object and using the Alt-Enter keyboard shortcut;
• Highlighting an object and Selecting View->Properties for the menus;
• Using keyboard shortcuts to give the Properties window focus and then moving it with the keyboard arrows thinking it may have been hidden off screen or somehow thinking that it was on an extended display on another monitor;
• Plugging in a second monitor and then toggling which display was primary and which was extended.

All of these were tried (several times) but to no avail. Next I bit the bullet and tried re-installing the software. Several hours later I found that the Properties window still had an extreme case of shyness and wouldn't show up on my screen.

Luckily, not too much later, I was in line for a laptop update so when my laptop arrived with a fresh install of the Dashboards software all was fine once more - the Properties window was no longer hidden..........at least for about three weeks when the problem re-occurred. Faced with this situation I did what any good manager would do and gave the dashboard work to someone else to take care of.

A week or so ago I moved to another new more portable laptop and installed SAP Dashboards 4.1 on it. Hardly daring to look, I opened up my first dashboard, and .............. joy of joys - I had a Properties window once more. Or at least I did until this evening.  It was there when I left work at 6pm, but not there when I logged back on to my laptop at 9pm. Facing a looming deadline to publish some new corporate dashboards and with no more budget to change laptops again I decided to dive into the Registry.   I found the key that sound about right, exported it for safety,  and started flicking through each of the sub-keys looking for anything that sounded like it might be about window positions, toolbar settings or last saved details. After numerous failed attempts to reset values in keys that looked to fit the bill, and urged on by the dulcet tones of Peter Gabriel, I pulled out the sledgehammer and deleted all of the sub keys under the settings key. I figured / hoped that they would be rebuilt next time I opened the Dashboards tool and I'd trigger a reset to factory settings type operation by brute force. With fingers crossed I re-opened Dashboards, and there it was in all it's glory - the Properties window: 

So, should you find yourself unable to make the Properties window show itself fire up Regedit and navigate to HKEY_CURRENT_USER>Software>SAP Business Objects>Dashboards>Settings>en

From there delete every subkey under en. Don't delete the en subkey as well, as that seems to render Dashboards unable to start. 

I've tried to identify the specific subkey that needs to be deleted, but with no luck. But that doesn't seem to matter as deleting them all fixes the problem and doesn't seem to have any nasty side-effects. 

This works for a Dashboards 4.1 system and I suspect it would also work for Dashboards 4.0 and probably even for earlier Celsius versions too.

If anyone else has experienced this problem and has figured out what triggers it, I'd love to hear from you!

LCMs - Oldies Just Don't Get It!

Here in Australia we have a breakfast bar that goes by the name LCMs. For those of you that don't know them, they're much like the Rice Krispie Squares found in other parts of the world. The marketing folks behind LCMs appealed to the kids market with the tagline: "LCMs - Oldies Just Don't Get It".

Recently I've been dealing with another LCM - the Life Cycle Management component within SAP's Business Objects suite. Strictly speaking, it's now known as Promotion Management, but I'm old school enough to still think of it as LCM.

Now, I'm all for the style of deployment that Promotion Management enables, but recently I've struck an odd error with its use that perplexes me. There's one think about LCM that this oldie doesn't get!

Recently I've had to turn my hand to something that it's been a while since I've done. I've had to play 3rd level support / SysAdmin to a production Business Objects reporting environment and its supporting development and testing tiers. Some new developers had joined a project using these environments to bring in some new WebI reports along with a few tweaks to the Universe. All went well until one of the new folks tried to promote a report between the development and testing tiers. The nature of the data in play means that the two tiers aren't allowed to have a communications path between them so the promotion needed to make use of a BIAR file. When attempting to create the promotion job after importing the BIAR file to the test server the developer was getting an odd, and not particularly graceful error. It read:

"AjaxRequestThrowsError":"True"

Attempting the same task with a user with admin rights was successful and, interestingly, so was undertaking the task when signed in as one of the original developers.

Effectively this seemed to rule out something more basic wrong with Promotion Management on that box. So, to me this looked like a permissions issue at heart. My first instinct was to look to see if the new developers had been granted to access to use Promotion Management. Aha! None of the new folks had access to the Promotion Jobs folder on the test server. Surely that's the problem.

Easily fixed. A quick application of user security and back to the developers to test. No luck - the same error we'd seen earlier persisted. Now I'm no masochist and I'm far to busy to re-invent the wheel, so off I went to ask Google and SCN. Sure enough both came back with a number of hits that described the same error, but none that matched our case or symptoms closely enough for my liking. So, like it or not, there was a bit more digging to be done. Through a process of comparison and elimination I noticed that there was one group membership that the new developers were lacking. Digging some more showed that this membership gave access (Full Control)  to the folder on the test server that the WebI report to be promoted would live in. And sure, enough after adding one of the new developers to this group the Promotion Management error disappeared and he was able to successfully promote via BIAR file.

Problem solved!

However, one puzzling aspect the remains for me is why this particular error was thrown on the creation of the promotion job and not on the execution of the promotion itself. Even more confusing was the fact that when we temporarily allowed a communications path between the the development and test servers the developer was able to successfully directly promote his changes from server to server (i.e. taking out the need for the BIAR file) even before we'd add the group membership.

With luck, if I ever have to solve the same problem again, this blog post will prompt me to remember the solution without the need for the investigations that went along this time. Even better, it may help someone else being confronted and confused by the same error!

Even better again, if you can shed some light on this odd set of behaviour, I'd love to hear from you. If I'm missing the obvious here, please point it out to me. This oldie doesn't mind it if he's able to get this LCM! And I'm sure the marketing folks as Kellogs won't care either!

The Desire Paths in Your Data

On the days that I drive to work I have around a one mile walk from my car park to my office. There's one particular spot where I can take a shortcut by going off the paved path and cutting across some open ground. It saves me a minute or so on the way to work. Despite the fact that there is a perfectly good sidewalk built by the local council it's obvious that a lot of people must do the same as me, and opt for the faster route as well, because there's now a clearly worn path across the open ground, established by people choosing this path every day. Urban planners call these desire paths - the paths that people choose to take between two points regardless of other options that may be available to them.

If you look hard enough you'll find desire paths through your data as well. Your business intelligence solution offers many conventional paths (like the sidewalks built by my local council). These are the pre-built reports and other instruments that you present to your users. But I bet many of your users have built desire paths - the tips and tricks they use to get and analyse the information they need to do their everyday jobs. Or perhaps the extra things they have to do, those downloads and manipulations in Excel or the sneaky Access database sitting on a spare PC under someone's desk,  because your BI solution doesn't let them do their jobs or perform the analysis they need in its entirety. Now you could argue that desire paths in a BI solution actually represent a form of self-service BI. However, unless you've engineered things this way then you're probably only kidding yourself. Yes, desire paths are examples of your users finding ways to help themselves, but chances are that it's due to shortcomings, not features, within your BI solution.

Desire paths have a dark side in the natural world - they often result in trampled vegetation, can contribute to erosion and (not being as safe as constructed sidewalks) can also lead to injury for those using them. Similarly, in the IT world they are actually likely to cause harm to the reputation of your BI solution or of your BI team. Just like people in the natural world wandering a direct route desire path, shaking their head(s) and wondering why their local planning authority spent all that money building a meandering sidewalk twice as long as it needed to be, your users may well wonder where all of that IT spend on BI went, especially when they "can do the same thing (but better) in Excel". Perhaps worse still desire paths can cause actual harm to your organisation, be it financial or other type of loss, due to decisions based upon flawed analysis or data as desire paths can lack the checks and balances that come from underlying planning.

Our challenge as practitioners, managers and custodians of our organisations' BI assets is to find these desire paths (and in so doing also to find which of our pre-built paths are no longer as relevant as they could be). Can we build established footpaths where the users' desire paths have been worn in over months and years of usage? It works in the natural world and it can work in the technology world as well. There are stories of park planners in some countries visiting areas after fresh snowfall to get a sense of where those using the area are choosing to walk. I've heard of at least one university which built no structured sidewalks on a new campus until such time as the students established desire paths between buildings, simply choosing to pave these paths one year on.

In today's reality of shrinking budgets we all get busy just keeping our BI environments running and meeting the needs for new reports and analytics, let alone spending time worrying about how we'll deal with the next big (data) thing looming on the horizon. But I'd advocate there may be good value to be had in taking the opportunity to look for and act on desire paths when we can. The trick will be finding, or engineering, those occasions, like those times of fresh snowfall, when the circumstances are right to see the desire paths and incorporate key ones amongst them into your BI solution.

Happy (re)building!

Your BI Project Shouldn’t Be a Lag Activity

There's a school of thought which advocates that Business Intelligence work should lag behind the other pieces of a larger project and that one should never attempt to undertake business intelligence (BI) activities in parallel with the other "core" activities of the project. The line goes something like this: you can't undertake a major project, say the implementation of a new ERP system, and design and implement BI over that system at the same time; the BI components have to happen 6 months or so later, they can't be designed and built as part of the main project because they are dependent on the main project items being in place first. Those espousing this popular line would have us believe that one can't build BI until the system is up and running, there's a good volume of data available and the business users have worked out what reports they really want and need. Anyway, there's no rush - reports and other BI items are only an output after all!

I disagree. Business intelligence items are as much an input as an output. Yes, they draw upon data in the system, but, compliance reports aside, the information they present should be used as part of a decision making process which then causes some course of action to be taken in a larger process. If this isn't the case then I'd argue that the report in question adds no value. It may just as well not be there!

Look at the idea of doing the BI components at a lag behind the main project through another lens. What this is really saying is one of a few things: 

• We don't need the information we'd get from the reports to base decisions upon;

•  We’re happy coming up with and using a range of time consuming workarounds;

• We’ve got a good gut feel for the business. We can get by making guesses for a while; or

•  We can get by not doing some of the things that we used to do before we put this new system in place. This could be anything from something as simple as not providing team managers with trend reports of absenteeism through to things with much more potential for a financial sting in the tail such as not re-forecasting project budgets after the initial baseline as been set.

Also take some time to think about the resultant behaviors that may arise from not having reporting and analytic capability available early in the life of your new system. People in your business need to make choices and they need information to do so. If they can’t get it from BI, from the right channels, then they’ll find and develop a myriad of workarounds in attempts to continue to do their jobs. Wait too long to bring BI to the party and chances are a good number of those workarounds will persist in various pockets throughout your business. 

So I’d suggest a pause for reflection before rushing to adopt the common [BI] scheduling wisdom. Put it in the above terms, mull over it, have the leaders in your business consider it too and then see if there’s still the same appetite to defer that BI work for six months. Yes, bringing the BI work in to the main project isn’t easy, challenges abound, at times it feels like you’re building on shifting sands but the pain of not doing it may be much worse.

Data Migration: Low Hanging Fruit Can Be Bad For Your Health!

 If you’ve been through a few data migration exercises then you’ll probably recognise the scene.  You’re in the midst of a busy data migration, the pressure is on, there’s too much to do and too little time to do it in. You’ve been back and forward with the business users trying to resolve data quality issues that are preventing data from successfully loading in the new system. One, two, three, or more trial data loads have come and gone and still there are pieces of data which stubbornly refuse to play ball and load in to the new system.

With deadlines looming you start looking for ways to solve the problem, to migrate the data, to just get it in there. Or perhaps, even worse, those above you begin to apply the pressure for you to do the same. The questions / demands start to come. “Look for the low hanging fruit, what can you do to just make it work? Just get the data loaded!”

One common idea is that a whole parcel of load errors associated with free text fields can be easily and quickly solved by simply truncating the data to match the maximum allowable length of the fields in the target system.  Load the data in; produce an exception report for the text fields that were too long and were truncated and, hey presto, problem solved! You’ve got a bundle of errors out of the way and proved that the data can load. There’s now confidence that, come the next cutover trial or the real cutover and go live, that the migration in this area will be fine. Now it’s been done successfully once it can be repeated successfully and can only get better. After all the business users will get your exception report and immediately and diligently get to work on cleansing those fields which needed attention.

They will, won’t they? It’s not like they got anything else competing for their time. Their line manager doesn’t need them to do anything else. They’re ready and waiting to cleanse data for you as their top priority.

OK, wake up and head back over to the real world! Once (or if) they finish doing the day to day tasks of their own job, not to mention the tasks of those of their colleagues who have been seconded to that big project that is underway they may have time to add the data cleansing tasks to their to do lists, but I bet those tasks don’t get added to the top of the list.  If that data is going to get cleansed then you need to present a reason to prioritise its cleansing.  A hard failure is that reason, and a much more compelling and immediate reason than an exception report for data which (after all) has already loaded.  If the data doesn’t load then it needs to be cleansed if it is to be available I the new system.

Give the business all the help you can. Point out exactly and ambiguously what the problem is, show them exactly which field(s) in which record(s) need to be cleansed and what good looks like (i.e. what rules and conditions must be met before the data can migrate) and use data profiling tools to give them some indications ahead of the next trial load that the cleansing they are doing is effective and having the desired effect. But, don’t own their problem nor try to solve it for them in isolation. Most times, the business folds will know the data much better than the data migration folks. As soon as the data folks start making assumptions about what is safe to do with the data in the name of getting it to load, be it truncating text fields or some other technique, then the organisation takes on a long tail risk and liability in that the meaning of the data may have been lost or changed which may manifest in negative impacts to process or operations at some point post go-live. Bad for the organisation and bad for you as often times it is the data migration folks that will be perceived as having been the cause of the problem.

But, in the end, pragmatism must rule the day. Your data migration must run. There will be those (hopefully few) areas where you’ll just have to make some calls for the sake of allowing the data to get into the system at final cutover. If you don’t you’ll find your name quickly in the same sentence as the words “…we didn’t go live because of…” So go ahead, pick that low hanging fruit, but wait until you absolutely must, it still may be poisonous, but less immediately deadly than the alternative! 

Data as an Asset – Walk the Talk

Establishing data governance programs, data quality initiatives or other projects aimed at looking after or enhancing the well being of a company’s data can be difficult to get underway and sometimes even more challenging to keep alive.  Such initiatives (especially if your company’s funding approach forces you to tackle them as a series of individual projects) cannot always deliver the concrete and tangible “things” that you might get from a more traditional IT project. More often than not there is no new asset created, no new system to implement and enable across a go-live weekend, nor are benefits always obtained and measurable in the short term. Unless your business is facing real pain (and honestly attributes that pain to not just problems with the data itself, but also with how the data came to be in the state it is) then you may well struggle building support for, and keeping data initiatives running.

Often this seems surprising to data folks. It seems that this isn’t logical. The business says all of the right things about valuing data quality, about wanting a single source of truth from which to make better, faster and more cost effective decisions and maybe someone has even sprouted the “data as an asset” phrase, but this hasn’t resulted in them beating down the door with bags of money to fund data improvement initiatives. At first glance it seems key business stakeholders are showing moral support for the concepts but no commitment to the actions required to really solve the problems in the longer term.  They are the chicken to the data team’s pig.

But perhaps it’s not all that surprising. Are you, as a data leader, walking the walk or simply talking the talk? Do you treat your company’s data as an asset yourself? And does your data strategy reflect that? Do you even have a data strategy or are you one of the many, described by Joyce Norris-Montanari in her recent blog post  (http://www.dataroundtable.com/?p=12661), who fall into the group lacking a vision for their data and a strategy to help them get there?

If you’re not walking the talk then chances are that you’ll need some work up front to sell a congruent picture to the business, and particularly to those stakeholders holding the purse strings.   Make sure that you can show the basics around the company’s data that you would have around any other asset.

• Knowing what you have – an inventory of your data;
• Knowing where this data is – which systems house which data and (ideally) how it moves around between them;

• Knowing which stakeholders care about which data (you don’t need to get to business data ownership just yet, but at least you should know which data helps achieve, or threaten, which stakeholder’s bonus package);
• Knowing what preventive maintenance is required to keep your assets running at the required level and optimize the investment in them- some idea (and documentation) of where the problem areas lie. The big data quality issues (and importantly their real impact on the business);
• An understanding of how you can protect your asset – which may include classifications for data along with associated handling rules and other security aspects; and
• A vision for continuous improvement and a better future state of asset management – thought out and documented ideas for better use of your asset (which might include identifying and reducing redundancy, identifying inventory gaps or working better at the extreme ends of the asset life cycle).

With enough of the above in place you have your house in order and can say that you are indeed making efforts to treat data as you would any other asset. Now that you have a congruous story to present to the business you may find your next funding request is met more favourably. Even better, chances are you may well have identified a number of projects to deliver some concrete shorter-term benefits along the way as well.   

Could External Quality Assurance Hamper Your Chance of Data Migration Success?

I’m not sure of the exact rate for failures in data migration projects. Along the way I’ve seen Gartner report that somewhere around 83% of migrations either fail or overrun budgets and schedules and if memory serves I believe I’ve read that Forrester reported the success rate at around 16%.  The exact number probably depends upon who is doing the reporting, whom they survey and how candid the responses they receive are. Whatever the case, the number is big, scarily big.

To my way of thinking any area of a major project where the weight of historical evidence suggests that somewhere between 8 and 9 of every 10 attempts will be significantly challenged should be subject to two things:

•  External quality assurance processes in an attempt to make sure that the chance of success isn’t derailed by things not being done as they should. Adding another voice of experience or another set of eyes if you will; and

•  Some form of contribution to the wider data migration community of practice to help understand where things go wrong and over time (as a collective drawing from the positive and negative experience across many projects) look to evolve the methodologies used to undertake data migrations and lift the success rate.

Unfortunately, at least in my experience at least, the two items often work at cross-purposes. All too often I’ve seen the first endeavour block or even derail the second.  Quality assurance efforts will often be established as a risk mitigation exercise. That same aversion to risk often results in lack of comfort and confidence in anything which can’t be shown to have been done many times before. An established methodology is preferred over that which might be construed as cutting or bleeding edge.  That’s all well and good but, chances are, if you are following an established approach then that approach has been followed by a fair number of those 83% of projects that failed (to some degree) before yours.

This resistance to any attempt to stray from the well-worn path hinders the adoption and evolution of new concepts in so doing prevents them from gaining wider acceptance, development and enhancement over time by the wider crowd of data migration practitioners.

So we, as those practitioners, have two choices. We can accept that we can do little to change accepted practice, keep our heads down, collect our pay cheques and hope that luck or our best efforts place us in the lucky 17%, or we can look to find ways to not only increases the chances of success for our project but also contribute to the longer term average success rate of data migration projects in general. If we do want change then we must also recognise that radical shifts in methodology just won’t be possible; governance and quality assurance processes simply won’t allow that. Instead I think we must look for chance to use new techniques to build upon more accepted methodologies, filling the gaps or shoring up the problem areas that pose the biggest problems in our particular current projects.  This could take any number of forms from using lead indicators alongside lag indicators to build gradually build confidence across a project or the gradual introduction of new and improved approaches to the techniques and timing of reconciliation. 

Whatever, and however, we may go about this I hope that over time as a community of practitioners we can slowly build acceptance for new techniques, new methodologies and new measurement paradigms and over time slowly shift what is deemed to be acceptable and common practice. Who knows, maybe sometime before the end of my career we may actually see a failure rate that doesn’t send cold shivers down the collective spines of project managers everywhere.