The VisiCalc Syndrome Lives. And Does BI’s Future Depend On How We Manage It? November 20, 2007
Posted by Cyril Brookes in General, Metadata management.2 comments
The revolution caused by VisiCalc in the 70s is still running its course, as I outline later. These days in the BI context there seems to be one of us doing something for every 10 telling us what to do, how to do it, how not to do it, why plan for it, what to buy to do it, etc. This reminds me of Bertrand Russell’s famous observation:
“Work is of two kinds: first, altering the position of matter at or near the earth’s surface relative to other matter; second, telling other people to do so. The second kind is capable of indefinite extension: there are not only those who give orders, but those who give advice as to what orders should be given.”
The number performing the second kind is far greater than those “at the coal-face”.
Last post, I considered the impact on BI of five proposed discontinuities nominated by Gartner that were bearing on IT generally. As is appropriate for the second class of workers lecturing the first, we were then told what to do about them, again with a set of five – the optimal number of slideshow points, it seems.
How should we take this advice? Well, first of all what were we advised to do?
Question Core Assumptions about the Role of the IT Organization
Experiment with Free-form Environments
Help Users Innovate
Segment Users (according to need and importance)
Stop Trying to Provide Everything (i.e. all users aren’t equal)
To my “first kind of worker” mind, these imperatives are really plays on the same theme: BI system users want to be empowered, or will empower themselves, but have varying degrees of skill, ability and needs.
I believe that demand will cause Rogue Users to overwhelm the conventional BI frameworks. I suspect that this has huge implications for the Big Three and their takeovers of Hyperion, Business Objects and Cognos, but maybe they don’t yet know it. User rebellion at the humongous complexity that must result from these takeovers is almost a certainty. The major vendors have the classical bind of needing to protect the base while catering for the new order; in the same way as land line based telephone companies need to protect the base while competing against low cost internet and cell phone carriers.
The answer, of course, lies in the data management.
Quoting from a blog entry by Cindi Howson (based on an Italian experience)
“Thousands of stand-alone spreadsheets disconnected from the BI environment continue to wreak havoc on everyone. Users spend an inordinate amount of time debating whose numbers are right rather than focusing on the business problems at hand. As one person expressed their frustration, “One of the most damning things BI vendors did was to allow direct export to Excel.” In defense of the vendors, users asked for this! In defense of the users, it’s because BI is not always deployed in a way that meets users needs. But just as parents have to say “no” to children, sometimes vendors and IT should say “no”, it’s not in the best interests of the company.”
I disagree that the vendors are driving the situation. Customers are always “right” when this situation exists.
I feel for the vendors, sort of, but this is simply a repeat statement of the VisiCalc Syndrome. If you were professionally active in the 70s, Dear Reader, you will recall the chaos that started this spreadsheet style of BI, Apple II and VisiCalc spreadsheets. Suddenly, we High Priests of IT (or perhaps more accurately EDP) were no longer the critical path for data analysis.
Whatever you think of the merits of massive BI software, the explosion of spreadsheet use since the 70s has far outstripped the growth of BI. It is the foundation of future BI, however. Eyeballs count in new technology, and most of the eyeballs are watching Excel.
This is what makes the Microsoft SharePoint family of application support software so interesting. Will it become the focus for our Rogue Users to tame the spreadsheet anarchy referred to by Cindi Howson? I believe it will, and we will see the progressive, but gradual, atrophy of the large, integrated, BI application as per Cognos, Hyperion, and Business Objects.
Bertrand Russell has another well known quotation: “The only thing that will redeem mankind is cooperation.”
To paraphrase for our discussion: The only thing that will save BI is cooperative collaboration.
Of course, I am not advocating anarchy, I simply believe it is inevitable if we try and maintain the current direction. The path to sanity is surely user empowerment at the application and reporting end, and quasi-Nazi control at the data end. The reason the VisiCalc syndrome was so painful was that the analysts all had bad data, mostly keyed manually from EDP reports (often themselves based on bad data!).
Metadata management is the key task for the workers (the real ones that is) as I have discussed previously. Let’s do it.
Decision Automation in BI – Selecting Decisions to Automate May 25, 2007
Posted by Cyril Brookes in BI Requirements Definition, Decision Automation, General, Metadata management.2 comments
Barring a directive from on-high, i.e. the Executive Floor, so to speak, it can be difficult deciding which new projects, or old ones for that matter, will benefit from automation of business decision making. Selecting the right project candidates is critical. Obviously sophisticated automation of unimportant decisions is a waste of time, however interesting the technology might be.
This post follows on from that of May 17/18. I proposed a set of five project selection and implementation Phases for decision automation projects. This version gives more detail on the first three of these. A later post will deal with the last two.
This discussion is a work in progress. I’ve built several automated decision systems, but have not attempted to define a project management methodology for them. Any further suggestions are welcome, Dear Reader.
The Phases suggested in my last post have been modified in the light of comments and suggestions from many readers. They currently are:
- Identify the controllable business variables in your business environment
- Determine the business processes, and relevant decisions, that impact those controllable variables
- Identify the BI systems that support the business processes and decision contexts selected in Phase 2
- Design the business analytics that are the basis of the decision automation: business rules, predictive analyses, time series analyses wherever Phase 3 indicates potential value
- Evaluate feasibility and profitability of implementing the analytics created in Phase 4
Note: Phases 4 and 5 will be iterative.
Discussion on Phase 1
Phase 1 is, I believe, a novel idea in this context. Most authors writing on Decision Automation focus on decisions and business processes as their starting point, but I think this can result in poor project selection. Just because a business process is important to the enterprise does not mean that automating decisions that are critical to success is the right thing to do. Empowering managers to perform better with improved conventional BI systems may be an optimal answer.
As I see it, controllable variables are likely to be the least common denominators for automated BI. Decisions that can be automated must look to adjust, or consciously not-adjust, one or more of these. Unless it is feasible to monitor and adjust a particular controllable variable there is no point in making a decision that requires this; there’s nothing to do. I might decide that sailing a 50 metre yacht around the world is desirable, but without the funds to purchase it, or ability to sail it effectively, the decision is rather pointless. I may as well decide to fly to the moon.
Or in a business context, deciding to raise product prices when all our customers are on fixed price contracts would be equally useless.
Therefore, a portfolio of identified, automatically adjustable, control variables is an essential commodity in the business of decision making automation.
These adjustable variables are limited in number, because of the nature of business. Below I offer some examples of such control levers, drawn from a product manufacture and/or distribution business context. I chose this sector because it is somewhat different from the insurance or financial services examples that are usually presented in decision automation discourses.
It’s not a complete list, of course, but does demonstrate, I hope, that the gene pool for business process controllability is both limited and deterministic; and, therefore, is a good place to start a search for opportunities and new sources of sustainable competitive advantage. I’ve collated the examples into rough categories, similar to Porter’s Value Chain approach.
Controlling Input Logistics
- Ordering raw materials or manufacturing components
- Adjusting re-order criteria for raw materials or components
- Changing supplier preference rankings
- Cancelling, or modifying, outstanding orders, either to suppliers or from customers
Controlling Operations
- Customer order acceptance, modification or rejection
- Scheduling, and re-scheduling production operations due to quality, demand, raw material or other factors
- Staff short-term allocation to service points based on demand, profit maximization
- Staff longer-term rostering based on advance demand
Managing Distribution
- Re-allocating product during production from a scheduled customer to another based on quality, demand, priority or other criteria
- Scheduling and re-scheduling despatch operations based on production actualities
- Ordering and re-scheduling distribution capacity to meet customer or production imperatives
Setting Financial Variables
- Setting and re-setting prices dynamically on products and/or services
- Adjusting sales commissions or incentives based on demand, performance, or inventory
- Setting and re-setting inventory levels based on cash flow imperatives
- Issuing outstanding payment demand and collection procedures
Directing CRM Activity
- Changing customer credit or priority status
- Placing customers or suppliers on or off credit or other watch-lists based on order, supply and payment patterns
- Issuing outstanding payment demand and collection procedures
Supporting Management
- Adjusting alerting alarm parameters
- Activating these alarms
- Modifying financial or sales performance report or alert distribution lists
Managing Services
- Adjustment of spare parts inventory levels
- Movement of spare parts inventory to different locations based on usage statistics
- Automatic ordering of spare parts and adjustment to order quantities
- Re-allocation of service personnel to divisions or areas
This list should prompt similar candidates for other business sectors. Hopefully it will stimulate your ideas on where you may usefully introduce automatic decisions within the existing and potential BI systems, rather than simply report the facts and rely on management to take action.
Discussion on Phase 2
The aim of this Phase is to discover business processes, existing or planned, that contain and impact one or more of these candidate control parameters and may benefit from automation. Further, the relevant decisions that require adjustment of these control variables must be identified.
The same control variables are likely to appear in multiple business processes. For example, automatic price adjustment could impact BI systems supporting Order Entry, Production Scheduling, CRM, Inventory Management, etc.
In a comment to my last post, James Taylor, proposed that this Phase as originally proposed also required identifying the decisions that would be automated.
I accept that this is correct, we are making decisions to change the settings (or to leave them as they are, a non-decision) of one or more of these control variables. We must, however, realize that these control variables often impact more than one business process. Therefore, there is a very real danger of cross-coupling with unexpected side-effects of a decision, if we don’t check its impact on all business processes impacted by the relevant control variables.
I won’t attempt to list relevant business processes, and associated decisions, that contain or impact specific control variables. This is a blog post, not a text book. Also, any Dear Reader who has stayed with me this far is more than capable of doing his/her own assessment for his/her business.
Discussion on Phase 3
Having identified the candidate business processes, and associated decisions, that should benefit from decision automation, it should be relatively easy to determine the specific BI systems, existing or potential, that will provide the context for the automation.
In my experience, a BI system that contains decision automation components will also provide management information to support human executive decisions. At the very least, it will need to report on decisions taken automatically, and their impact. But, often the operational components that contain automation will also drive tactical and strategic information presentation – directly or indirectly.
Therefore, it will be necessary, before moving to design the business analytics, rules, etc., to determine scope and architecture of the BI system, just like a conventional, information reporting only, project. The metadata describing the character of the underlying data will need to be specified, otherwise the business rule and statistical analyses will become compromised, if not immediately then at some time in the future as green-field turns to brown-field.
Unfortunately, in the real world of system design, analysts prefer to concentrate on the interesting bits, and avoid the boring, housekeeping parts. Specifying business rules, designing trend and pattern matching algorithms, building forecasting models is usually very exciting and challenging stuff. But the enthusiasm for such pursuits has to be sublimated until the overall architecture and scope are determined.
Otherwise we may end up with efficiency at the expense of effectiveness. Not a good result.
In a later post I will discuss Phases 4 and 5; the interesting bits
Rogue BI will be like the Poor, Always with Us. Metadata to the Rescue. April 1, 2007
Posted by Cyril Brookes in BI metadata documentation, General, Metadata management.3 comments
Two recent articles on the place of the maverick in conventional IT, by Joe McKendrick and Ramon Padilla stimulated me to consider the role of the Rogue in BI systems creation, modification and use. It’s more benign in BI than in IT mainstream, that’s for sure.
To mix my metaphors: Blessed are the BI Rogues, for they shall know what they want much sooner than IT will get around to filling their request.
I define rogue BI as the user self-creation of unofficial, unapproved corporate performance reporting, competitive analysis and customer behavior assessment.
The pressure for instant gratification in BI is intense, perhaps more so than the teenager’s need for the new Playstation game. Or maybe it’s just the grown-up version of the same.
The data is there, the report building is now easier, or the same, as building a spreadsheet, and no one is directly affected by poor execution, except that the Rogue gets rubbish instead of the goodies. Of course, the business meeting where the rubbish is put forward will be interesting; much like used to happen in the old old Visicalc days when ingénue spreadsheet creators battled it out with garbage versus rubbish.
It’s the “no one knows” that’s the issue for IT administration. If no one knows that a report exists, no account will be taken of it when the data cubes are redesigned, deleted, re-dimensioned, or whatever.
Reuse is also impossible, obviously, but then again it’s likely undesirable except for the brilliantly capable Rogue. SOA followers don’t want to go here!
Some form of monitoring and control is required of the BI environment, but the jury will be out for some time yet. In the meantime, it is important for us to realize Rogues are part of the shift to the BI brown-field.
In January I blogged that BI issues in 2007 would be focused on metadata because of the brown-field effect. In the brown-field new BI applications would be re-workings and extensions, not new systems for executives without current BI, the green-field. BI Rogues proliferate in the brown-field.
This leads us irrevocably to the metadata management issue. As I see it, it is imperative that IT administration control the Rogues through regular, maybe daily, snapshots of the BI metadata, not just the SQL but also the (using Microsoft examples) the Analysis Services, Integration and Reporting Services content. Lineage that links report content to cube content and maybe data sources is also useful.
Dear Reader, if you’re a regular, you will know that I’ve been working on a metadata documentation and snapshot tool – BI Documenter, which does most or all of what is needed in the BI metadata area, if you’re a Microsoft user. You may care to check the website www.bidocumenter.com.
Metadata snapshots tell the story, the Rogues leave an auditable trail, and all modifications are likewise exposed. Assuming they don’t do something completely stupid, the Rogues can be allowed to create their “thousand flowers” to bloom.
If you cannot, or don’t want to, monitor BI metadata snapshots then I believe your only option is to use governance to manage the inevitable BI Rogues. Good luck, they’re smart!
Next time I’ll look at a code of good practice for BI Rogues.
Green-field to Brown-field BI Environments – metadata analysis holds the key September 28, 2006
Posted by Cyril Brookes in BI metadata documentation, General, Metadata management.3 comments
Our BI systems are getting on in years. What was an appealing virgin territory to the BI enthusiast has become a difficult pre-teen. Maybe bringing up BI systems is like raising children – every stage is the worst. Client executives are getting more aware of what’s possible as well and, of course, the data is still messy.
But the biggest challenge could well be the need to renovate existing systems, rather than have the luxury of starting afresh. Welcome to the brown-field.
I outlined the metadata complexity issue for BI analysts in my September 21 post. Earlier, in my June 30 post, I described the stages and tasks involved in a bottom-up approach to BI system design. I opined that the bottom-up, or rapid development, methods will remain dominant in the BI systems space for the foreseeable future. Now I am attempting to bring these two issues together.
To recap, with some adjustments to fit my current convictions and practice, the bottom-up approach to BI system development requires answers to the following queries:
1. Where are we now? E.g.
- What is the current, synchronized, state of the data warehouse and BI tables: the SQL database documentation, ETL (covering all the space from source transaction system to data warehouse), cubes and dimensions?
- What reports and query specifications are out there, what do they contain?
- What are the outstanding BI specification requests and user complaints/suggestions?
2. What is stopping us perform better in our BI reporting? E.g.
- Bad source data content?
- Inadequate ETL packages corrupting data warehouse content?
- Under-utilized data?
- Unused, wasted, data collection?
- Unavailable data to satisfy specified requirements?
3. What can we do to perform better? E.g.
- Repair the data sources
- Find and fix the ETL errors and omissions, starting with the most dysfunctional
- Check with the client executive base to see if the under utilized data should be reported more or better
- Review the available data with client executives to improve satisfaction
- Design new data warehouse content and associated reporting where possible and desirable (Of course, in this business everything is desirable, only a few things are essential!)
4. Prioritize the work schedule and get going – probably in a series of iterations with highest/fastest ROI first.
I know this is obvious, motherhood and flag, stuff to the experienced BI analyst. However, it is often not understood – I believe – that we are completely dependent on the stage 1 being done right. We must have comprehensive, accurate, up-to-date, access to the synchronized metadata. Further, we need to be able to explore this metadata, its relationships and sensitivities.
Iterative BI design is impossible if we cannot document the metadata adequately. Green-field sites are all migrating to the evolutionary mode as they age, and metadata is king of the brown-field BI environment. Once we have this documentation and analysis capability the rest of the project is fairly straightforward.
Documenting the relatively narrow BI software context isn’t enough; we must be able to reach out to the source data locations wherever possible.
Plus, passive documentation itself is also short of the full whack. It’s like being in the supermarket without the meal plan and recipes to tell us what we need to buy.
I reckon we need to have a “what-if” capability to allow us to explore the metadata world as documented, checking on data existence, link existence and integrity; and reviewing the Drill-down and Drill-through capabilities.
Of course, this capability is also very useful in the virgin, green-field site as well, but we usually have more flexibility to maneuver then.
There are many software documentation tools on the market, and I leave you, or others, to evaluate them for this purpose. However, it is my view that a more fully featured tool is required than those currently available.
To provide an evaluation yardstick, and to act as a design guide for my specific software design purposes, I’ve put together my checklist for a metadata repository tool that serves BI analysts in both their support and design roles. It also avoids the problems, e.g. the dog’s breakfast syndrome, raised in my last post and has the required “what-if” exploring capability.
My repository checklist is based on the Microsoft products, but others would be similar:
- Take regular snapshots of the relational database contents relevant to BI – Tables, Columns, etc.
- Also, snapshot the Integration Services packages: Data sources, Data Flows, Data destinations, Tasks
- Ditto the Analysis Services tables: Cubes, Dimensions, Report Specifications
- Ditto the Report Services content; Datasources, Datasets, parameters, drill-through reports
- Facilitate HTML and diagrammatic documentation for each of these snapshots as needed, with extended diagramming capability to capture design ideas and extensions.
- Provide a server application based analysis tool that:
- Tracks data lineage from SSRS, through SSAS and SSIS to the relational, legacy or other data source, and displays the transformations that occur on the way.
-
Provides cross component impact analysis capabilities, i.e. what is affected if I change the definition of this field – in the database, in the cube, in the report?
It’s taking a while to build this, but even the current status should be useful to the designer. If you’re interested you can monitor the progress and try it out yourself at www.bidocumenter.com. There is a new release due next week.
The BI Metadata Enigma – where did these data come from; and where have they been? September 21, 2006
Posted by Cyril Brookes in BI metadata documentation, General, Metadata management.1 comment so far
These are the kinds of questions we ask our children – where were you, what happened last night? And to the putative, hopeful, BI support analyst and developer, the DW content, the cubes, the dimensions; they are our children. Strangely, the answers are just as hard to get on metadata as with the kids, or at least the right up-to-date answer.
The issue is going to get much worse. Why? Because we are rapidly moving from BI “Greenfield” design situations to “Brownfield” support and re-design environments. We’re stuck with the treadmill of history as well as client executives who want better BI.
There are two different sets of metadata related problems here:
- Support of operational BI systems, and
- Design of new or improved BI
But, they both have the same solution.
Everything is related to the BI metadata, sql database documentation and associated BI development system tables, cubes, etc. This is a problem to us all because:
- Metadata is not in one place – it’s a real dog’s breakfast; even when all the BI tools come from the same vendor
- It is dynamic, so we need to be able to monitor the sql documentation to see what the DW architects have done since last time we looked
- Comprehensive commercial repositories, at least those available today, are cumbersome and not kept current
- Synchronization of the metadata component documentation is super-important to the analyst – without it your project must surely fail.
- BI design is not concerned with much of the metadata available for a database, the focus is on the business related items and not the process type – schedules, update counts, etc. Often, the unrelated stuff dilutes that which is important.
- Metadata standards are too complex, and not a useful categorization tool for BI analysts at present
- Essentially, the issues for BI analysts are: What is in the current DW, the cubes, KPIs, tables, columns, dimensions, reports, etc.; and where did they come from. Most database and BI software analysis tools are inadequate for this purpose.
Support analysts find it difficult to track down the sources of bad data. Clients complain about inaccurate reports, but why is it so? We need, indeed must have, better BI related metadata repositories. We don’t want all the crap, pardon my expletive, just the business related stuff, so we can find out …..Where it came from and where has it been – to make such lousy, and inscrutable, content.
That’s probably enough stating the issue for support analysts.
Next post I’ll detail how these same issues impact the BI developer, especially the person trying to improve on an existing BI system.
I’ll then outline my proposed solution, a specialist BI metadata repository tool.
We’ve always had bad data – but survived. Don’t panic. July 23, 2006
Posted by Cyril Brookes in General, Metadata management.add a comment
There is a lot of consultant self-righteousness out there on the issue of data quality and its impact on the ability of enterprises to build SOA environments generally and effective Business Intelligence reporting specifically. The newsletters are full of the stuff. Mostly its crap, and we all know it. Checklists upon checklists of common sense. Death by newsletter regurgitated bumpf to fill out the ads!
In my opinion there is too much beating of breasts and doom and gloom talk – we’ve always had bad data, and, let’s face it, always will. I don’t condone bad practice, but we do need to keep the perspective – perfect data will cost an infinite amount of resource, and much of it will never be looked at, let alone used in a way that causes grief.
Remember Method One? If you’re old enough in the business, you’ll recall how we had milliions of forms to fill in, checklists to check, signoffs to get. Basically, you either did your job, built the system, or, alternatively filled in the forms and did nothing useful.
Surely the best course for the smart Business Analyst is to know:
What you have in the data warehouse
Where it came from
Who uses it, where
If you think I’ve got it wrong, let me know. But, the path I’m taking in our BI work is to ensure that the metadata is documented, in diagrams and tabular form, and the lineage to and from the cubes and tables of KPIs and measures is easily traced. The same should apply to Service Oriented Architecture projects, everything is desirable, but we should only do what is essential, there’s enough of that.
If a report is queried, there’s a dispute over accuracy or relevance, then check the sources and trace the history. It will soon be clear if there’s a problem or not. So do the sensible thing, cover the obvious issues, and rely on the documentation for the issues that arise. Of course, the documentation has to be right – but this is reasonably easy to do.
Good practice combined with this facility will surely be the cost effective option. I hope to be more prescriptive in the near future. Watch this space, or check the progress on how I’m “operationalizing” this at www.bidocumenter.com.
Keeping score – What’s on all those dashboards? July 17, 2006
Posted by Cyril Brookes in BI metadata documentation, General, Metadata management.add a comment
Who thinks they know how fast we’re going? As the plurality of available reporting proceeds apace for most businesses, we are losing track of what we have, who has it, and what we could/should be doing with it all. It’s likely to be the spreadsheet stakes of the 1970s all over again. Remember? You turn up at a sales meeting and six different people have six different numbers all created on Visicalc on their personal Apple IIs.
Effective BI with adequate controls. We need this, but it will be elusive.
My preferred direction for improving BI is to encourage more creativity in report design, with emphasis on closer matching of information presentation and the executive’s cognitive decision processes. Regular readers will know that I have a hobby horse about inadequate requirements definition for BI, and its consequences.
But, I’m turning my attention, as an interim gambit, towards BI documentation. A form of modified bottom-up development methodology seems to be the most viable approach, given the existing situation in most IT departments and the exigencies of corporate life.
This requires accurate, clear, comprehensive and up-to-date documentation of the BI context. What is in the cubes, what KPIs are active, what measures? And who is using them. Which KPIs aren’t being used, why? If you like, what is in peoples dashboards – read 1970s Visicalc sheets. I’ve been working on a new project, BI Documenter for this, you may care to check it out at www.bidocumenter.com.
With this first step we can analyze the present, and offer executives a better way of looking at it.. I’ll discuss how we can do this in a later post.
BIg questions; Where did all that bad data come from? How do we fix it? April 21, 2006
Posted by Cyril Brookes in BI metadata documentation, General, Metadata management.add a comment
We all have bad data, and there’s no such thing as good bad data, but we don’t have to fix it all. Bad data is like curved roads, its not in the nature of the human race to create perfect data and more than it is to build straight roads. But not every road needs to be straight, some never get travelled.
Where should we start fixing bad data? Are we wasting our time on frivolous pursuits correcting data we don’t need? Are we ignoring the data we should be getting right?
If you’ve dipped into my earlier posts, you’ll know I’ve a fixation on requirements definition, or rather the lack of same, when starting out building BI systems. Surely, though, knowing what we want to report, and the manner in which we want to report it, is an essential prerequisite for any data cleansing operation.
It’s pretty clear now that the IT corporate standard approach to BI systems development is driven by weight of marketing effort by key suppliers – playing the “Keep up with the CIO Jones” syndrome to absolute perfection. If you don’t have DW, ETL, Scorecarding, Dashboards, blah you’re not in the game. Data accuracy isn’t an issue at this purchasing point. Its like buying a several packets of blueberries at the supermarket, then finding out they’re all soft and fungicidal when you get home.
The resultant evolving continuum of BI environment is something like:
Buy data warehousing softwareBuy ETL software
Try and figure out what the hell to do with the above
Buy, or implement “included with server”, software to do BI reporting, data mining, data analysis.
Try and figure out what the hell to do with the above [especially since a lot of the blueberries are crook]
Analyze lots of existing reportsSpecify and then create a set of corporate standard KPIs by aggregating everything everybody gets now [regardless of data quality]
Realize how bad the data is. Start a data integrity project.
Create the ETL and computation transforms, cubes and other magic things that should have integrity.
Build new BI systems that replicate the existing reports, with flashy presentation, but poor data.
Wonder why no one is excited after spending all that money – just like no one really wants a jazzed up version of Ben Hur – it was bad enough first time.
Or, more accurately, as Peter Drucker opined: Efficiency is doing things right, effectiveness is doing the right things.
What is wrong? I reckon that the problem can be summed up by the age old IT adage: We’re building solutions looking for problems.
Information delivery is not matched to the business process.
Worse, information presentation is not matched to executive mental processes
Data collection, and integrity expenditure, is not directed at the real, important, useful information needs
Much effort is wasted on cubes, ETL, etc. that are never to be needed.
No effort is spent to identify new information metrics not yet collected, or not yet present in a report.
Get the specifications right first, then find out what data we really need and how to present the information, then collect clean versions of the same. Simple really.
