The Second Most Important Question in the World

There’s a lot to be said for business intelligence practitioners being responsive and being able to deliver to and meet the needs of their clients quickly and much has been written about the benefits of BI teams partnering with their business colleagues in order to provide the best outcomes and value.

But doing so shouldn’t just be interpreted as giving business users everything they ask for as fast as humanly possible. Across my career I’ve found one simple two word question very powerful. That question is: “so what?”

The value of asking "so what" comes partly from asking the “how will you use this data?”, “what decisions will it inform?”  type questions, but it is even more powerful when turned around. Ask the question: “If I didn't have that data available to me - so what?" If the answer is something along the lines of: “I wouldn't know that we had a preventable problem and in 5 minutes there'd be raw sewage running down the main street” then it's worth doing something about. Write that report, enable those analytics – and do it quickly. However, if the answer sounds more like: “I might need that extra piece of information one day”, then perhaps let's wait for one day to come before we spend the effort, time and money.

In today's climate funding and resourcing are not what they once were in BI. There are few open cheque books left and those of us managing the function have to work with other leaders in our organisations to prioritise. Not only does working on low value things demoralise the members of the BI team, it's also an opportunity cost to the organisation. Working on a low value or low impact requests means that something else, something that may have enabled a better decision, led to time saved, a lower cost to serve or a customer prevented from churning was pushed aside and missed.

The “so what?” question is a powerful one. Just be careful how you ask it, and never presume to know the answer or to be able to second-guess your business colleagues!

And, as to the matter of the [first] most important question in the world. Having just spent two weeks travelling long distances on planes and in cars whilst on holiday with my kids I can assure you that the most important question in the world is “ARE WE THERE YET?”

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.

So That's What IT Recruiters Are Good For!

The BI Market seems to be fairly hot right now, at least in Australia, if the number of calls I'm getting from headhunters and IT Recruiters is any sort of indicator. However an experience I had this week makes me wonder.

Right now I have a need to ramp up the number of BI folks in our company to handle some project demands. It's a short term gig for the time being so we directly approached a few service firms as well as posting in one or two LinkedIn groups. Two days later I received an email from an IT Recruiter offering me the chance to interview for a great BI position with a first class company there were working very closely with. The position description felt very familiar and no wonder, I'd written most of it only a few days earlier. It had been augmented a bit to give the impression that what was in reality a short term engagement with a slim chance of extension was instead just the initial piece of a long engagement. A hunch had me checking Australia's main jobs website. Sure enough, two more recruiters were also advertising jobs which were also obviously the roles I was trying to fill. Both had extra or erroneous information, I suspect to make their version of the job more attractive than the one being advertised by their competitors.

Recruitment "consultants" taking initiative and creating opportunities to make income for themselves and their companies is one thing, but it causes problems for those of us working in, or managing those working in, the BI arena. With multiple parties now advertising my two roles now seemed like eight, so when those two are filled it will seem as if many more roles have been quickly filled. I suspect this contributes to the general feeling that demand is high and might even be artificially forcing rates up. Worse still will it cause a scenario where this perception of great demand draws people from other IT areas to re-train in the BI field, potentially causing a future glut of supply?

So let's be generous and say that recruitment consultants generate a buzz for us and drive potential candidates our way, but those of us with our own Human Resource Departments could do that anyway. What else do recruiters bring to the table? In my experience the majority of those I've dealt with lack any depth of understanding - matching skills and expertise to roles is haphazard at best, and even basic screening of applicants seems limited to "if they can spell BI then they're qualified to get a second interview".

So, for me I struggle to see the value..... But then I had an experience that made me realize that recruitment consultants do serve a valuable purpose - they're here to make us laugh. I was approached by a recruiter interested in my data warehousing expertise and keen to learn if I had a forklift license and what my typing speed was. I suspect data warehousing may have been a new term for him! Another, during a preliminary chat when I was trying to find a candidate to fill a new data warehousing role, asked me if I felt rising real estate costs would make warehouse space more expensive and cause my firm to lift our rates.

So, guys, keep the laughs coming, but you'll excuse me if I pass on your other offerings!

The Next Data Rock Star

I miss the 1980s, there was lots to like about that time: great music, a lifestyle less cluttered by technology, crazy hair, the fact that I could still grow enough hair to have crazy hair. For most of my adulthood if you had asked me which time in my life I'd like to go back to I'd have picked the 1980s. But now I'm not so sure, I'm starting to pine for the late 1990s through to the mid 2000s. Why? Because, that was a time when quite a few data folks working in the business intelligence arena were the rock stars of IT.

I'm lucky enough to have worked on my fair share of interesting and high profile data warehousing and BI gigs during that period. The problems I had the privilege of working on were often difficult, few (if any) commodity solutions or services had manifested, and the solutions we provided were often anything but cheap. However in solving those problems we added real value to the business, at times doing things that their traditional IT staff or software vendors had said couldn't be done or had tried (and failed) to solve with more application centric approaches. Perhaps most importantly during that period few BI projects were undertaken unless the business could really see the benefit. Maybe this was because of the high cost, maybe not. Whatever the reason, those of us lucky enough to be leading the charge and playing key roles in these projects often got the accolades of not just our IT and data colleagues but also  of key business stakeholders as well. I was fortunate to parlay this into a successful consulting career  with word of mouth securing a series of back to back BI engagements stretching for over a decade.

But I fear that the BI Rock Star is a thing of the past. It's becoming a crowded field. Any number of people now "do BI" and what was once bordering on black magic is commodity thanks to advances in (BI) software products and hardware processing power. Even worse, the phrase "reporting" is commonly be used almost interchangeably with "business intelligence". We've all too often moved away using BI undertakings to support complex decisions and solve wicked problems to one where often all too many reports are produced for banal reasons or reasons unknown. It's no wonder then that business stakeholders seem to be seeing less value from their business intelligence dollar.

So, if BI is indeed on the wane, I wonder where the next Data Rock Star will come from. If I was to encourage my kids into the field where would I point them? Will the Data Scientists be the next wave to be lauded by the business, or will those jumping on the Big Data bandwagon get that privilege? Maybe those playing in the NoSQL space are about to be thrust to glory, or perhaps the social media tsunami will mean that's it the intersection of all three which will be the sweet spot. I actually think it won't be any of these. Both Big Data and Data Scientists to me still feel like buzz words - hot topics - that the industry has thrown up and bandied about to the point where airline magazine syndrome has kicked in. I don't see the clear path to the wide stream killer need that means business stakeholders will clamour for solutions in these areas enmasse any time soon.

So, if you can see more clearly than I, I'd love to know what the next big data thing will be. I miss being a rock star!

BI - It's Not Just Reporting

Many times across my career I've been frustrated by what is, in my opinion, a gross under utilisation of business intelligence tools, platforms and even functions and teams such as Business Intelligence Competency Centres. All too often significant investment has been made in purchasing software, building data warehouses and other solutions, training staff and hiring external consultants, only to have this considerable horsepower and potential being set to work on (just) "the reporting".

Building BI solutions often comes at considerable cost in both time and money and if the chief item provided is purely a set of static reports that tell us what has happened in our organisations then someone, somewhere (and probably somewhere higher up in the organisational chart) will sooner or later start to question the wisdom of the investment. And that's not just a problem for the here and now of the current project, but for the future too. If he has been tainted as to the general value of business intelligence then he may well push back against future initiatives in the area, potentially robbing the organisation of future competitive advantage or effectiveness gains. The problem is made worse still when the default approach to setting project scope is to examine the set of existing reports available from in and around the incumbent solution. In this case the company will have a shiny new toy and (maybe) a prettier set of reports, but may not have gained much in the way of additional business value or actionable insight.

We need to remember that BI offers the potential for much more than just reporting. This was true well over a decade ago and is even more true today with the technology and tool advances we've seen between then and now. Just look at the name: BI, that's Business intelligence folks - intelligence for the business. Simply knowing what happened (via a report), for the sake of compliance, audit or because the procedures say we need to have a piece of paper punched and filed on a shelf, really does little for the running of the business, let alone its advancement. BI should be about helping make decisions that better the business, that help it carry out its operations in the best way possible.

The term "decision support" may seem a bit old school, but perhaps it does capture what BI can offer to the business other than just "the reports". Recently I heard the phrase "the three tenses of BI" and it resonated with me. The first phase is historical - this is the looking back, telling us what happened, function of BI - these are the reports that so often get developed as the majority, or even the entirety, of a BI project. The second tense is the present tense. BI instruments in this area tell us what is happening right now. Reports can serve this function too, but often they miss a key component that stops them playing an effective role. Whatever is used here, be it reports, OLAP components or some type of complex event processing, the information conveyed must be provided in a form and in a time frame that allows it to be used by the recipients in a manner and a timeliness which causes a change which benefits the business that would not otherwise have occurred. The third tense of BI looks to the future - using not only internal information but also looking at wider information sets to try and predict what may happen in the future in and around the organization, thereby providing food for thought for those setting the strategic direction for the organization. What's important to note there is that the second and third tenses of BI require information and intelligence to be presented in order not just to enable decisions to be made, but perhaps also go so far as to highlight that decisions should, or even must, be made.

Simply having a great set of tools available isn't enough. If we want to move on from being perceived as just report writers then it's up to us, as BI professionals, to educate others as to the potential of BI, challenging and assisting them to find ways in which it can be better used across our organisations. So go on, take the first step - share this blog post :)

When I Grow Up I Want to Be a Data Scientist

Some time in the early 1970s I formed my first career aspiration. When I grew up I wanted to be a bus. Yes, you read that right - not a bus driver, but a bus. It seems ridiculous now, some 40-odd years later, but I certainly wanted it bad back then! The reason it didn't seem crazy all those years ago is that I really had no idea what being a bus involved and what's more a bus seemed like a pretty cool thing to be - lots of the books that I had read to me featured buses zooming all over the countryside having all manner of exciting adventures, there was at least one cartoon where one of the main characters was a bus, and buses even had songs sung about them. Why wouldn't a three year old boy want to be a bus?

Fast forward 40 years and focus on the data industry: big data is being talked about in server rooms, board rooms and everywhere in between, and the term Data Scientist is becoming more and more common. It's a position I'd never heard of twelve months ago and now it seems hardly a day goes by where I don't see it mentioned in a blog post, industry email, or white paper, etc. A quick look at a number of job posting sites across the web confirms that organisations are indeed looking to hire people into roles with the Data Scientist title. But does anyone really know what the job entails, is there an agreed job description, even in a general sense? Judging by the diverse descriptions of the job ads I looked at it certainly doesn't seem so. I've talked before about my concerns that the Big Data concept is very much an overloaded and poorly understood term and I worry that the new "must have" role of Data Scientist is facing the same problems.

But, so what? Does this situation even matter? I think so. I applaud anything that raises the profile of those of us that work in the data and information space. I still remember what it was like to ride the wave in the early days of business intelligence and data warehousing and if others can have similar experiences and success today due to the next big thing being data centric then that's a good thing. However, I worry if the  shining beacon of the Data Scientist role starts to lure people from other facets of IT, or potentially worse still, attracts students entering University whilst the speciality is still in its infancy. With the role a Data Scientist will play, and how they will deliver value, yet to become understood in a consistent way then how can we expect our higher education institutions to prepare courses of study that will equip students with the skills that they will need when they reach the work force? I wonder if we will see such courses morphing, emerging and disappearing over coming years as industry and the universities try to better find what is expected of Data Scientists and how to build the knowledge and skills base they need to be successful. What of these early students, the guinea pigs or crash test dummies of the coming wave of graduate data scientists? Are we leading them astray, promising them areas of work, challenges and career paths which no-one yet knows will actually be there in the same form (or at all) five or ten years from now? Let's not promise too much too early. Better people come to the profession with their eyes open and with realistic views of what to expect, than simply because of hype.

Enough doom and gloom. If anyone can really tell me what a Data Scientist does, I'd love to know. I actually might want to be one when I grow up.

Big Data: Are We Really Ready for the Final Frontier?

I've just read an excellent post from Rich Murdane entitled "Big Data" and the Failure to Communicate. I'm glad Rich penned this piece as I was beginning to think I was either alone with my position and thoughts or, worse still, just missing the point! Rich has managed to nicely put into words a feeling that has been gradually building with me. For a few months now I've had a growing sense of disquiet that "big data" was becoming a buzz word - a phrase that was on everybody's lips but often with little substance behind it. That is, folks are talking about it because they feel they should be talking about it, but in reality they (and we as the broader industry) have not yet taken the time (or perhaps more kindly, had the time) to really think through what big data is and more importantly what it means to each of us and what  value it might deliver to our organisations.

I fear there is a real chance that much money will be spent too early as folks jump on the big data bandwagon before they they really have a good handle on which part of big data they should be focusing on. If we look at what "Big Data" is then a number of things spring to mind. For me the the obvious one is condition monitoring data - generally structured time series data. It's not just the size of this data that makes it big, it's how fast it arrives - what's beginning to be more commonly talked about as the velocity of data.

For me, and the big data problems I'm likely to face in my industry, I think this may well be the key issue at least in the short term. Operational technology is prevalent and in some cases this could mean thousands of data points arriving per second - huge waves of data washing in. One of the questions that I think needs to be considered is how high velocity big data should be used, or perhaps how the best value can be derived. Quite a bit of the discussion I'm hearing and reading suggests that this question is not being asked, but rather there's a leap of faith being taken resulting in a default position that this data needs to be stored and analyzed. I agree that over time this might well be the case, but for many right now I wonder if this value proposition is understood well enough to be effective. Perhaps it might be wiser to wait and look at other ways to gain value from this style of big data, one of which might be a form of complex event processing to monitor the stream of data and pluck out those events or short term trends which allow an action to be taken to materially impact operations. Those of us without a compelling business case to store, and later interpret across, huge data volumes might be best to wait and watch, taking action not because we feel that we should be, but because we understand what the value is and how we will unlock it.

This watch, monitor and wait brief should be wide enough to make sure that all forms of big data that might deliver value are considered. This means that it's not just the structured data area that is important, unstructured data is perhaps even bigger. For many of us with long pedigrees in the data space this may be somewhat of a new and unfamiliar area. I think we have no choice but to step outside of our comfort zones and become more familiar with this space. Much of the short to medium term value to be derived from big data, in my opinion, will come from this area for many industries. Sentiment analysis and mining of data from social networks is a great example of this which is already becoming important for many organizations. It's also an example where a stream of data can be monitored for data if interest as well as gaining value from analysis across larger pieces of historical data.

Big data is here to stay. It's not a matter of if it will impact your company, but now only a matter of when. You'll have to jump in and ride the wave at some time, just be sure you don't jump into too soon. Make sure you haven't worn out your funding and senior management support, will and trust before there is a real opportunity for you to harvest value from big data. Big Data may or may not be the final frontier. I could borrow from Star Trek, but I'd rather borrow from 1980s one hit wonder Star Trekkin'. It's Data Jim, but not as we know it. Good luck in your explorations, but be careful. There may not be Klingons on your starboard bow, but there is almost certain to be an executive or two asking the hard questions if his money disappears into a black hole with no value return.

Where’s the BI Value Proposition?

I can remember a time when the pitch for BI could (almost) be made along the lines of reducing headcount – “put in this reporting solution and you’ll no longer need the team of people who currently spend all of their time compiling numbers in spreadsheets for others in the business to use”. Even when BI cost a mint this scenario still offered an organization the chance to come out in front financially. These days things aren’t so simple. Despite decreasing costs for BI the sales pitch is probably harder today than it was a decade ago. And I’m not just talking about vendors and consulting companies selling BI products and services into their prospects. I’m also talking about selling the value of BI inside companies – making the case for a BI initiative to internal funding boards is getting tougher and tougher with shrinking budgets and competition from other projects and programs.

To have the best chance of success the value proposition needs to be clear.  Often now BI projects will be seen as providing productivity support. They won’t save headcount but they may free up some percentage of time for resources throughout the company or help those within the organization make faster and / or better decisions. Proposing cost savings based upon these time savings is a dangerous endeavor. Such savings may not be viewed as real given fixed wage and salary costs or, perhaps worse still, the department may simply have next year’s budget cut by that amount to ensure the proposed benefit is locked in for realization.

Coming up with the appropriate value proposition may need you to stand back and honestly examine what’s within the scope of the proposed BI program. Is it just static reporting or are you largely replacing existing reports like for like due to a burning platform? If so then perhaps it’s time to swallow your pride and pitch the program like an infrastructure project. Chances are your client or your internal funding board looks at the criteria for assessing these types of projects differently than others, recognizing that they are unlikely to deliver strategic value, cost savings or drive top line growth, but rather just have to be done to sustain the business as usual state – to keep the lights on, if you will.

If your proposed initiative is broader and can be aligned to more tangible business objectives then you have a number of things you should be mindful of when building the BI value proposition:

·      Value is a subjective thing. Look at the perceived value of the initiative at different levels of the organization. Do they all see the value, or does your push to realize enterprise value actually make things harder for one or more departments? If you can find win-win scenarios or at least avoid win-lose scenarios then it will be easier to get agreement on the value.

·      Can you show how the value can be measured over time (and is it actually going to be possible to measure this value)? Financials are just one aspect of this. Speed of decision making, greater visibility and transparency and reduced risk might be things to consider. What ever you decide to include make sure that you can measure and articulate the current state. Not only will it give you a benchmark to measure against but you’ll also have concrete examples of the issues you are trying to solve, rather than just pitching the value of the initiative based around academic or theoretical concerns or problems that have manifested in other industries.

·      Is all of the value expected to be realized in a short to medium timeframe? Chances are this isn’t the case, especially if the project involves analytics or data mining. There likely to be a perceived drop in value whilst the design and implement stages are underway and the business resources are having to participate in workshops, field questions and test while holding down their day jobs. The perceived value is likely to spike once the initiative goes live as the low hanging fruit are harvested but chances are the perceived value will again dip as the business gets more complex and costly due to changed and changing processes, new ways of working and information overload. The real value pay-off may well not come until this stage passes and this state of anxiety and uncertainty can be resolved by working with the business to work with these new learnings and new information to further enhance the analytics and any new or changed processes to again simplify the way people work. Expect this, plan for it and build it into your value proposition. If this pushes the benefits realization out too far to the right then look for ways of chunking the program down into smaller tactical projects all building toward the strategic end game. Show the early value and paint the alignment with the strategic aims and the later value that will be realized.

And of course if you’re coming from the IT side of the fence don’t forget to work with the business through all of this. Not only are you likely to have covered off more stakeholders prior to the pitch, but chances are you’ll reap a higher value from the finished product as well.

Oh, and if you’re from the business side, bring the IT guys in on things too!! Involving them early will lead to higher longer term value.