As I’ve spent more time working with ECM (Enterprise Content Management) solutions during the past months, and I still have a strong BI background, I was asked this question today:
Could you give me a quick synopsis of the major benefits one would get from a serious BI application vs a serious Enterprise Search application like Autonomy?
And here is my answer:
At first glance, these two solutions are totally different, yet from an end user standpoint they might look similar.
In a nutshell, a BI solution allows searching, digging and making sense of structured data (i.e. stored in a database of all kind: relational, multidimensional, etc…), and build reports, real time dashboards, etc.
An Enterprise Search solution allows searching and digging unstructured information (mainly text based, from various sources including managed content or external sources such as web pages or even scanned papers).
The interesting part is that a user would like to search something globally, across structured and unstructured data, as the most important part for them is what they search, not where or how it is stored. The segregation between structured and unstructured content is mostly driven by technology although the real need is for these technologies to converge.
The convergence of these two world also comes from growing links between structured and unstructured information, as a big part of what ECM and Enterprise Search solutions are doing is to “structure the unstructured” by adding structured Metadata to unstructured information.
Most of the time though, the BI applications are not yet able to leverage this Metadata, mainly because it’s written in a very proprietary way, not designed for easy reporting but rather for the ECM own performance purposes.
I’ll revise this post regularly based on my findings and experience.
Items in this list may only show my inability to perform a specific action with one solution, which at least means that there is a usability issue with it 🙂
Crystal Reports XI:
- + Formula Editor
- – No permanent data model: a new data model needs to be recreated each time I create a new report
- – No ability to work on results and combine them together
- – No ability to aggregate on the server: I didn’t find for instance how to create the following statement: With the help of Paul’s comment, I was able to find how this works in Crystal: you need to turn the “Perfrom Grouping on Server” option for both the report AND the general option. [cc lang=”sql”]select count(my_field) from my_table[/cc]
Open Text BI 8.5.1:
- – Doesn’t support multiple outer joins with SQL ODBC connection
- – Can’t report on a table named “users” with SQL ODBC
- + Can work with results and create complex “super queries”
Following up on the BI strategy, here is a non exhaustive list of questions to ask before planning and implementing a BI project:
1 – identify the business needs:
- What is the business of this organization, and what is the purpose of their reporting needs?
- What kind of reports are needed:
- Decision support?
- Performance management?
- Dashboards and Scorecards?
- Customer oriented, financial?
- System analysis?
- Data Quality?
- Enterprise BI?
- Data Warehousing?
- Master Data Management?
- Predictive Analysis?
- Are the needs local to a department or general?
- Are the needs reproducible or would they be generated on an Ad-Hoc basis?
- How will reports be used:
- Embedded and read in another document?
- Printed and archived for historical purpose?
- Accessed on line (intranet or extranet)?
- Accessed on a mobile device?
- Presented during a projection or in a book?
- Scheduled on a time or event based frequency?
- A mix of the above?
- What will the retention of the report be, should historical reports be kept?
- Can we define each reports or groups of reports:
- What is the purpose of the report?
- What are the metrics of the report?
- How should the report be sorted, ranked, filtered?
- In what format should the report be presented: tabular, chart, cross tab, a combination?
- Are there calculations involved? Exceptions highlighting? What are the business rules for these?
- What are the selection criteria for this report? Are these criteria pervasive across reports?
- Who should access the reports, who needs them?
2 – What are the technical constraints?
- What is the budget for the BI project?
- What is the time line for the BI project?
- What kind of security applies to the content of the reports or system and how is this security handled and applied: at the system, the database or the report level?
- Where is the data stored?
- Is is easily available?
- Is there a test environment?
- Is it a multi-sources report?
- Are some of the content not available in databases?
- Are some of the content stored in proprietary systems (such as ERP, etc…)?
- How clean is the available date, would there be any data cleansing required?
- Is the data “report ready”, or are transformation or transfer required and possible?
- Is the operational system accessible, or should the data be duplicated? How often, how “fresh” should the data be? Are there any concerns in accessing the operational database?
- Metadata: are they defined, needed, accessible?
- Are there non structured information involved?
- Is there a corporate graphic chart to follow (for portrait, landscape, web reports)?
- Are there some technical constraints: platform, OS (client and server), web browser, Database, network, security, login, hardware (RAM, CPU, etc..)?
- What languages should the reporting project be available in?
- What training is planned or scheduled?
- Are there other existing similar projects we could rely on or improve?
Planning, implementing and maintaining a BI project is not an easy task.
Ever since companies started 20 years ago with “Decision Support Systems” and “Data Warehouses” projects, one simple advice has always been the most important of all: use the 80-20 rule for your project time:
80% of the project’s time should be spent understanding the end users needs to defining the project, and the remaining 20% should be used to implement the project.
Most failures in BI projects are due to a nice (and costly) tool that doesn’t quite answer the end users needs and eventually adds more to their workload than helping them making good decisions, and eventually is not used.
And by needs, I mean real needs, not just what they want:
If you ask someone what car they want, chances are that they will describe you their dream car, a car that they will probably never be able to afford! But when you ask them what they really need, the dream car disappears to be replaced by one that is just pragmatic, with 4 wheels, and engine and seats for everyone!
The same applies to BI projects while defining it. Some user would dream about a system that would magically take decisions for them, automatically gathering heterogeneous information from everywhere.
But their real needs might not be so fancy, and some indicators and an easy access to the database information, with the insurance of the quality of that information is often all they need.
This is what a good BI project should provide.
