|
Services: Knowledge Portals · Knowledge Map · Knowledge Network · Book of Knowledge · NEWS· INFORMATION
Channels: General Business · Business Technology · E-Business · Knowledge Management Community: Join the Network! · Global Network · Events Calendar · Executive Jobs |
|
Posted by Martyn R Jones on August 15, 1999 at 17:22:59:
In Reply to: Re: Data-Warehouse and Groupware? posted by rdw on August 15, 1999 at 10:33:38:
Hello,
My perspective on this is that using Groupware for requirements gathering is better than not involving the Business Users at all (but runs a pretty close second). I do agree that Groupware (such as eMail, Notes etc.) can be used for example to suggest minor additions (an extra attribute in a table, a new aggregation etc.) but not as a replacement for an in-depth definition work-shop (for the DW iteration).
Indeed, if a company thinks that it is building a DW by "collecting everything and making sense of the collected data afterwards" then it:
- doesn’t understand data warehousing
- is a very small company with a very small amount of data and maybe less than twelve employees
- has IT as its unique core competency
- saying one thing and doing another (fooling the competition into thinking they are really ah! not very smart)
- got the labels mixed up on its RFP
- is maybe God’s way of telling the business they have too much money
The following extracts are taken from our draft book "Manage The Revolution – Information and Knowledge in Telecom" (distributed here with permission from the author)
Understand and Involve The Business User The Business End-Users of the Data Warehouse should form an integral part of the Data Warehouse project team - either directly, or in the case of a large user community, through adequate, appropriate and timely end-user representation. End-User participation in a project does not imply that everyone else can take a back seat. Every assistance possible must be given to ensure that the End-Users understand what is possible, how much it costs and how long it takes. Every relevant piece of data warehouse project data, information and knowledge must be made available to the End-User and when necessary explained to the End-User in terms they can understand. Don't expect users to have all the answers or to be able to provide you with answers in precisely the form that you may be expecting those answers. Be understanding, be flexible, and also don't forget that business is dynamic and in a state of almost constant change. Therefore, don't just hypothesize about users changing their minds, one must expect it to happen. Anticipate change and prepare for it, embrace change and make it work for you. Let's not ever forget that the building of a Data Warehouse is for the benefit of the whole business and a partnership in which everyone has a major stake.
Iterative Approach Most telecommunications companies are faced with enormous amounts of data, in many formats that could potentially be located in a data warehouse. But operational systems, for example, have large amounts of transaction-level data that may or may not be required for analysis. Trying to locate all this corporate data at once is generally not feasible - for logistical and cost reasons alone. If, however, a company can build its data warehouse by moving portions of the data incrementally, as needed to solve a specific business problem, the process becomes safer, more manageable, and less costly, providing a faster return on investment. For example, a telecommunication company can start by consolidating all its customer information in a data warehouse in order to understand how to maintain better relationships with existing customers.
The use of the iterative development approach is the most effective way to balance timely delivery with the complexities of the telecommunications environment - the iterative approach is an integral feature of the /ISF methodology. There are five major drivers that lead us to an iterative development approach:
The value of information will change. The complete value chain of information must be understood and delivered, this is known as a dynamic characteristic. The business processes will continue to change and be refined Scalable technology decisions will need to change and be refined. A flexible organization must be supported. Iterative development speeds the delivery of benefits to users. An initial iteration can deliver limited functionality to a select group of users. Later iterations can be built upon the work of the first, decreasing the amount of effort. The iterations can be carefully planned to deliver the complete value chain of information delivery using your own business priorities as drivers.
--- end of extract ---
Which I hope should also go someway to explaining the what, why and how of DW.
Best regards,
Martyn R Jones