Methodogy of selecting DW vendor?

[itons]

Hellow every friend,

I'm just doing a real DW project for selecting data warehosue vendors. It focus on the initial stage before the formal involvement of any external consultign firm. It addresses the approach how buyer formulates his SHORT LIST OF VENDOR.

The problem is I am not sure the stage sequence for VENDOR / TOOL SELECTION in terms of the whole project lifecycle or methodology. I checked many books or website. Most of them talk nothing about the vendor or tool selection. They only talk about assessment of business needs. It seems for them chooing a vendor is just a piece of pake!

What the methodology adopted by us for whole project lifecycel is:
1) Assess team
2) determine initial business requirements
3) Projetc definition scope
4) Project plan
5) vendor selection
6) Invitation to Vendor (ITT)
7) evaluation the response from vendors: Set evaluation criteria
- Long-term marketplace
- Technical platform
- Link to requirement
- Ability of supplier to meet requirement for long-term
8) Choosing vendor, making acquisition, and launching pilot scheme
9) start implementation

Does any friendcan give me comments?

Cheers

James

 

[blom0344]

Hello James,

Are you sure that you need such a 'heavy' approach to your cause? You sound like buying a datawarehouse like buying a new car of a certain brand. I think it is save to say that DWH's are build and not bought, since specific needs are so company specific. Furthermore, the type of platform chosen depends quite heavily on the platform of transactional sytems. If you run applications on ORACLE databases it is highly implausable that intensive research will uncover that building a datawarehouse in DB2 will be the way to go.

I use both DB2 and ORACLE and both database types have advantages and peculiar drawbacks, but in terms of datawarehouse structure I can build the same in both databases without any user feeling a difference. Technically they have more than you ever need. I think it is far more effective to put energy into getting a clear picture of what users will demand in terms of output from the DWH. This is a topic that is usually underestimated and causes much delay and restarting during the building process. Secondly, make a very good inventory about the tool (ETL) that you will use to populate the DWH. The big ones in the field have their own ETL-tools now, but these are not so sophisticated as the stuff from the top-specialists in the field. Thirdly, how are you going to report from the DWH. Are you going for the Business Intelligence approach, or just use Excel/Access and give everyone carte-blanche?

Extensively calculating which vendor (platform) suits you best is a waste of time. Look at how you run things now and buy something you are already familiar with. T. Blom
Information analist
Shimano Europe
tbl@shimano-eu.com

 

[itons]

Dear Blom,

Thanks very much for your detailed comments. Actually we have done investigation for business requirements for over three years. At this momemnt I just concern the approach of how to select vendors. Some articles have criticized the conventioanl way of formulating matrix to score the vendor, by claiming that it took too much time to ealuate and select vendors and ignored the dynamic change of vendor itself. Indeed we did the scoring matrix based on packaged solution provider, not on each component of data warehouse one-by-one such as ETL, OLAP, reporting, etc. Could you contribute you ideas to comment or ciriticized this approach?

Cheers

James

 

[blom0344]

Hello James,

I wonder if we are talking about the same thing. Are you truly expecting to buy a solution from a vendor (who ?) that gives you all components you need and implement it as such? A datawarehouse is nothing but a structured filling of correlated data on a certain platform using a toolset to populate it and another tool to draw data from it.
The data you put into it and the way it is stored depends on your business requirements and users. Surely you have very specific needs? Apart from this side of the story, big attempts to create complete datawarehouse implementations have a very low succes-rate (below 50%). Go for a low level approach. Set up a limited implementation for a certain department and aim at a specific scope. (We aimed at finance to impress the top-chiefs) Do not think of datawarehousing as a static thing. If you go for a massive implementation your requirements will have changed by the time you start testing. Apart from that people will have waited for to long to get some results and will no longer be very motivated.

In any case, I am interested to learn what vendors you are considering who say they can provide an out of the box solution! T. Blom
Information analist
Shimano Europe
tbl@shimano-eu.com