Art of Selecting the Right BI Tool - Part 2

Dears,

As promised please find the concluding part of this Blog Article covering the next 3 significant steps in selecting the Right BI Tool.

6. Vendor scripted demos


Vendor demos should be scripted so participants can objectively compare vendors and products. Prepare a consistent agenda for each vendor to follow. In the agenda, allow time for a discussion of strategic considerations as well as specific product capabilities identified as critical. Be sure to invite an extended user base to the demos so you can elicit qualitative feedback and ensure users have a stake in the decision-making process. Based on your priorities defined in step 4, ask demo participants to score the vendors on their ability to meet the various requirements.

Collect these scores immediately following the vendor scripted demos. If you do not gather quantitative feedback immediately after these sessions, users will later forget the differences, or worse, confuse the products and vendors!

Scripted demos can either be based on the vendor’s sample data or based on your own. Using internal corporate data further identifies how each vendor’s tool is different, yet it requires a large investment from both you and the vendor. Such an investment is advisable with a handful of vendors but is impractical with many vendors.

7. Determine the best fit

Determine the best fit using your requirements matrix  score the RFI responses and demo feedback. Incorporate strategic considerations, qualitative research, and customer feedback to determine which vendor(s) most closely matches your company’s short and long-term BI needs. If you have one clear leader, do not fully dismiss the runners-up. You may find out during the proof of concept, contract negotiations, or pilot that your first choice has insurmountable issues.

8. Proof of concept

You may only have one or two vendors that move onto the proof of concept stage. The proof of concept stage is your chance to test the tool in your environment. It is only a test, though. At this point, it’s important to keep the selection committee focused on the critical requirements rather than endlessly playing with the software or attempting to create usable reports. The proof of concept may be a throwaway: its sole purpose is to confirm that the product works as you expect it to. Carefully manage the scope to use one subject area and a handful of sample reports for the proof of concept. The sample reports should be based on information requirements defined in step 3 and be of moderate complexity (don’t waste your time with simple list reports that all BI tools can handle, or, conversely, the killer report that took your best programmer a full month to design). The proof of concept will give you insight into how you may need to adapt the rest of your BI architecture, but it is not the point at which you solve all the implementation problems.

Did I mention that these eight steps only get you to a BI product decision? You then of course have to negotiate a contract, implement, deploy, leverage, and promote the tool!

The BI market has changed significantly in the last few years. Emerging technology, vendor innovation, and acquisition have changed the BI landscape dramatically. Recognize the importance of selecting the right vendor and solution to the overall success of your BI deployment. Ultimately, the more important question is not which tool, but rather: how will you use business intelligence to provide business value?
 
All the Best & (B)e (I)ntelligent with BI
 
Your P&C
DC*