One thing I've noticed over my years in the business of implementing packaged and homegrown Enterprise Apps: business intelligence is usually an afterthought. There's such a focus on modeling and automating transactions that reporting becomes a "oh yeah, that too" kind of thing.
If we'd stop to consider what business intelligence ("BI") really is, many of us might grow a different perspective about how we implement enterprise apps. What if we implemented with an eye to what kind of information we'd like to get from our enterprise apps? I'd wager that such thinking would dramatically change how enterprise apps are implemented. But the first step in that thinking is to have a clear definition of BI. Not OBIEE (a product) or dashboards (a means of delivering information from data) or any of the hot buzz marketing terms, but a conceptual understanding of BI.
So, right about now, you're probably thinking: "so what's Floyd's definition of BI and why does he think it's important enough to write about?" Fair enough. Let's lay that out.
"Those who cannot remember the past are condemned to repeat it" - Reason in Common Sense, George Santayana. George's statement goes to the heart of BI's purpose: providing information about the past in order to make informed decisions regarding the present and the future. Not a bad start for getting to a clear definition of BI, but a bit incomplete. We really don't want random bits of information, or even all the information, do we? We want the best information. In my humble opinion, the best information has five components:
1. Accurate - the information, and thus the supporting data, has to be right
2. High-Value - has a measurable impact on the organization: better, faster, cheaper
3. Actionable - information that not only leads to conclusions, but has the potential to drive actions
4. Timely - the information has to be as fresh as possible and available when you need it
5. Simple - the information must be easy to access and easy to understand
So, with all this in mind, my definition of BI: accurate, high-value, actionable, timely and simple information regarding past performance, provided to support decision-making on present and future events.
Why is it important to lay out this definition? Because, as different vendors lay out the marketing spiel on their unique solutions and cutting-edge technologies, keep the basics in mind helps to slash through the baloney. The same definition also helps define the parameters for a successful BI project. And, finally, keeping the definition in mind might significantly change the way you implement your Enterprise Apps the next time around.
Agree? Disagree? Say so. Find the comments.
UPDATE: Unbeknownst to either of us, pal David Haimes wrote on the same subject at roughly the same time. Very worthwhile reading here.
2 comments:
Floyd, my definition of BI: Getting the right information, to the right person, at the right time to enable better, actionable business decision making for improved organizational performance.
Sadly, most organizations approach their transactional systems "backward" in that they focus on getting data into the application and not so much about accessing data from the the application, i.e. reporting.
A great example of this is in a comment that a client's controller made to me, "We don't have a data problem; we have a reporting issue." Nevermind, that the organization didn't take the time during their implementation to consider seriously which data they needed to collect, and from where, so that their reporting processes would be efficient. What a concept, huh?
What I'm wondering about in the reporting space is the overlap between BI, analytics/ad hoc reporting, scorecarding, BAM, and CEP.
These can be judged by the same criteria but wind up being very different solutions, often in distinct (non-integrated) toolsets.
What I am clearer about is that BI is NOT operational reporting, although you can use BI toolsets to help visualise operational reporting data marts (built in different ways). To me this is the distinction:
If you need a report to determine the current status of a process in flight, or to determine the "do next" in business process, then it is operational--and probably should be explicitly called out in your most detailed process flows (in SIPOC or BPMN). It probably doesn't have much in the way of drill/filter, just needs to be real time and quick to obtain, may not even be paper, a self refreshing display on a TV--like an arrival or departure monitor in an airport.
If the report shows a KPI (or even a PI) then it is one kind of BI. Ideally you can drill the KPI "traffic light" or % to get details of how the answer was arrived at which might inspire action, often exceptional action outside of a process or a tactical change of direction. For example, seeing on your sat-nav or a highway matrix sign that your route ahead is slower than normal (say less than 80% of speed limit) may cause you to take a different route.
KPI report can lead to something more operational (less likely) or more ad-hoc BI reporting.
Post a Comment