Buying business intelligence (BI) software can be hard -- with technical evaluations, prioritizing requirements, getting the funding you need and avoiding political landmines, there's a lot to consider. But in my experience, these are the most important considerations for business intelligence software buyers. OK, so eleven is an odd number -- but in addition to the eight things you should consider, I wanted to cover three things you should not consider. In my experience, some people give far too much weight to certain issues that have little or no relevance when choosing a BI system, so it seemed valuable to list these as well.
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
1. Return on investment (ROI)
ROI is king. It's top of the list because it's the bottom line (if you see what I mean). We don't implement BI systems because they are trendy; we don't do it because the technology is fascinating. We invest the company's money in a BI system because we expect to get more money back, in terms of income or savings, than we invest. Of course, calculating the income/saving is often a major challenge, but it must not be ignored. All the remaining points essentially follow on from ROI.
2. User requirements
This could arguably be at the top of the list, but ROI got in first. There's no point building a BI system unless it delivers exactly what users are requesting/demanding -- so take the time to go through the requirements-gathering process with your business users, however painful it may be. Make sure you can deliver what people want, or just don't start -- a failed project helps no one (and certainly not your career path).
3. Ease of use
Traditionally, BI systems have been difficult to implement, set up, understand, drive – everything about them has been hard. The good news is that the situation is improving, so buy one that is easy to drive. Give serious consideration to ease of use for the end user, but also consider that the easier it is for your technical staff to build and deploy a BI system, the cheaper it will be to implement. The systems that are currently available vary hugely in ease of use -- so make ease of use a priority in all areas.
4. Existing expertise within the organization
Suppose your enterprise has a policy of using just one database engine and has developed a very experienced technical team on-site. If you buy your BI solution from the same vendor, you get double benefits. Almost certainly your staff will find the new tools easier to use, because of the family similarity that runs through products, and secondly, the staff will be happier. If you force them to use a product from a manufacturer they don't respect, they'll hate it on principle and blame it (and/or you) for everything that goes wrong. And they will make sure it does go wrong.
5. Compatible technologies
Notwithstanding the point made above, few vendors currently supply complete end-to-end BI systems. So, depending on your needs, you might not be able to source everything from one supplier. If that is the case, before buying any of the components, ask searching questions to ensure maximum compatibility with your existing infrastructure. All too often, individuals within the enterprise lobby for the purchase of a BI component without taking this into account. (I'm thinking here of, say, the finance officer who insists upon a particular analytical tool.) Compatibility lowers the cost of producing an integrated system (something that finance officer might appreciate, once you explain it).
6. Killer functionality
It may be that one BI software product alone offers a single piece of functionality that outweighs virtually every other consideration except ROI. I have no idea what that might be for your particular enterprise, but you'll know it when you see it (or your IT team will tell you about it, long and loud). It might be support for spatial data types, for example, allowing you to incorporate GPS data for tracking deliveries, or perhaps decomposition trees for innovative data visualizations. But sometimes, that one killer feature makes the whole investment worthwhile, as opposed to trying to get another product to do something that it really wasn't designed to do.
7. Data volume
How much data do you have -- and how much will you have in the future? If you're a large retail chain collecting point-of-sale data, you have lots of data. If you're a telecom company, you have lots of data. If you're NASA … and so on. Certain BI technologies do not scale well. In-memory querying is a case in point: It can be very effective with surprisingly large data volumes, but there are limits to what it can handle. Some software products (particular data mining algorithms, for example) scale badly. They may work well with a million rows, but with 10 million, they may run like a (slow) dog. Try to gauge data volume accurately and match it to software/hardware capabilities. Then make the vendor really prove to you that the software can handle it.
The hardware available for BI covers a huge range:
- Commodity standalone boxes.
- Commodity boxes bolted together to form Massively Parallel Processing (MPP) arrays.
- Dedicated MPP machines.
Costs vary accordingly. If you under-specify the hardware or try to use the wrong hardware for your new BI software, your system will never perform optimally and the ROI will fail to appear.
The business intelligence software buying points that you should not consider:
Cost isn't important; it's return on investment that counts. It's better to invest $5 million and reap $30 million than to invest $2 million and reap nothing. (Best of all is to invest $2 million and reap $30 million, of course.) With the right calculations and a convincing business case, you should be able to prove this to the money people at your company.
10. Current source systems
Existing operational systems such as the finance, CRM and human resources systems are typically underpinned by a database engine. Just because you're using Engine X for transaction processing does not mean you have to use it for the new BI project, for the simple reason that the Extract, Transform and Load (ETL) tool essentially sits as a buffer between them. Any good tool will be perfectly capable of extracting data from any number of different source systems and transforming it into any flavor you like. This doesn't mean you should ignore the existing expertise in your company – see above – but, in terms of functionality, there is little need to consider the existing engine.
11. The sales pitch
I don't know how to break this to you -- but some salespeople make things up. They exaggerate, omit pertinent information and even lie. This is sad, but inescapable. At best, they often lack a technical grasp of the capabilities of the systems they are offering. It is essential to talk to technically competent people and get them together with your technically competent staff. In my experience, technical people are less likely to stretch the truth. This is not a hard-and-fast rule, simply an observation based on experience. I have, however, heard a technical guy say: "Don't use our Component Y – it's rubbish." I've yet to hear the same words from a salesperson.
About the author: Dr. Mark Whitehorn specializes in the areas of data analysis, data modeling, data warehousing and business intelligence (BI). Based in the U.K., he works as a consultant for a number of national and international companies, designing databases and BI systems. In addition to his consultancy practice, he is a well-recognized commentator on the computer world, publishing about 150,000 words a year, which appear in the form of articles, in publications such as PCW and Server Management Magazine, white papers and books.
He has written nine books on database and BI technology. The first one "Inside Relational Databases" (1997) is now in its third edition and has been translated into three other languages. The most recent is about MDX (a language for manipulating multi-dimensional data structures) and was co-written with the original architect of the language – Mosha Pasumansky. Mark has also worked as an associate with QA-IQ since 2000. He developed the company's database analysis and design course as well as its data warehousing course.
|Tags: Business intelligence technology platform, Business intelligence best practices, VIEW ALL TAGS|