انبار کالا داده چیست؟

انبار کالا داده
اطلاعات در محیط کاری امروزه اساسی هستند. انبار کالا داده ، داده ها را به اطلاعاتی که در ثبات و هوش سازمانی نقش دارد ، تغییر شکل می دهند. انبار کالا داده ، به عنوان سرمایه مهم در سرمایه گذاری  سازمانها محسوب می شود.در این مقاله سعی بر آن بوده تا با تعریف مفهوم انبار کالای داده ،جنبه های متفاوت از معماری انبار کالای داده ، بررسی انواع مدلهای طراحی یک انبار کالای داده ، برنامه ریزی و مدیریت یک انبار کالای داده به اهمیت نقش انبار کالای داده در ذخیره ، نگهداری و ارائه موثر اطلاعات در انواع سازمانها بپردازیم.

مقدمه
مفهوم انبار کالاها از ترکیب دومجموعه از نیازها است:آن تجارت نیازمند دیدگاه وسیع شرکت از اطلاعات و نیازها بخش سیستمهای اطلاعاتی به اداره کردن داده های شرکت در یک راه بهتراست.داده های انبار کالا تصمیم روند حمایت شده اند.موسسات ازروش داده های انبارکالابرای حل مشکلات و مواجه شدن با نیازهای تجارت استفاده می کنند برای مثال صنعت بانکداری داده های انبار کالا را برای ایجاد تصمیمات مالی متنوع استفاده می کند و برای حالتهای گسترش مالیات استفاده می کند.موسسات تلفن از راه دور از انبارکالا برای تحلیل اطلاعات مشتری برای بازاریابی هماهنگ شده واستفاده می کنند.گروه متا گزارش می دهد که95%درصد از موسسات نقشه برداری شده طرحهایی برای ساخت داده های انبار کالا دارند.این تاییدها یک حرکت مهاجمی به دادوانبار کالا است.

تعریف انبار کالا داده
یک تعریف از داده های انبار کالا داده انبار یک رونوشت از داده های معامله بخصوص دارای ساخت برای تحقیق و گزارش است . راف بیان می کند که یک داده وانبار کالا " یک کپی از داده معامله بخصوص دارای ساخت برای تحقیق و بررسی" است.دو ابهام با تعریف راف  وجود دارد:1-گاهی اوقات داده های معامله در یک داده و انبار کالا ذخیره نشده است – بنابراین شاید 95-99 درصد از داده ها معمولا داده های معامله باشند .2-من میگویم تحقیق و گزارش نسبتاً بیشتر از تحقیق و بررسی است، زیرا بازده اصلی از سیستمهای انبار کالای داده ها همان لیست های جدولی است با حداقل قالب بندی یا حداکثر گزارشات "رسمی قالب بندی " شده است . داده کالا لزوماً به خاطر نیاز به تصمیم گیرندگان یا مستعمل در فرایند تصمیم گیری نیست . البته اگر شما بخواهید هر استفاده کننده را به عنوان یک تصمیم گیرنده تعریف کنید و همه فعالیت ها را به عنوان فرایند های تصمیم گیری سپس این ادعا نادرست هست .اما تجربه نشان می دهد که استفاده های طاقت فرسا از داده های انبار کالا برای جهان خاکی هستند . فرایند های تصمیم گیری بیشتر از سهم تصمیم گیرندگان نیست خلاصه این نیست که بگوییم که استفاده داده های انبار کالا در فرایند تصمیم گیری یک تلاش عجیب یا بازده زیاد بالقوه نیست. اما پیش بینی ما این است که هر چند فشار داد و ستد فروشنده ها و بسیاری از صنایع ویژه نقش داده های انبار کالا  یک محدوده در واقع ما آمادگی فهم واضح را نداریم.

جنبه های متفاوت از معماری انبار کالای داده ها 
این صفحه یک لیست از جنبه های متفاوت از هنر معماری انبار کالا است. هنر معماری تا حدی عبارت محوی است. هنر معماری به عنوان یک سیستم تصمیم گیری است که معمولا به اسانی قابل تغییر نیست .تصمیم به آسانی تغییر نیافته، زیرا میزان کار پول و سیاست شامل اقداماتی از این قبیل است .این لیست از جنبه های مختلف هنر معماری است که داده های انبار کالا تصمیم گیرنده باید خودشان رسیدگی کنند . این لیست به تهیه توضیحات جزیی از انواع مختلف هنر معماری تلاش نشده است ترجیحاً این لیست را ارایه می شود، زیرا  ادبیات داده های انبار کالا معمولاً موضوع هنر معماری  است که مقادیر زیادی از انواع متفاوتی از تصمیمات را خراب میکند .

هماهنگی در معماری داده ها
انتخاب از داده های منابعی است که وابسته به داده های بازار و داده های غیر وابسته به بازار است . در واقع بسیاری از دگر گونیهای استفاده شده اند که نمی توانند به آسانی یک اتیکت شیک داده شده باشد. دلیل اصلی که ما داده ها را در سیستم های داده های انبار کالا ذخیره میکنیم این است که  میتوانند:
1-از داده ها گزارش تهیه  کنند
2- داده ها را تصفیه کنند
3- داده ها را به انبار داده دیگری منتقل کنند ،جایی که آنها میتوانند گزارش شده یا تصفیه شده باشند باشد.

تعیین جایی که ما داده ها را در آن نگهداری می کنیم تا از آنها گزارش تهیه شود ،گزارش گیری در معماری انبار داده نامیده می شود.چنانچه قبلاً ذکر شد، اختلافات بی نهایتی از این هنر معماری وجود دارد.بسیاری از مباحثی که اغلب برای سازماندهی اجرای داده های انبار کالا ایجاد خواهد شد، اغلب یکی از بحث های هنر معماری خالص و زیبا است .

معماری مدل سازی داده
این انتخاب شما از ابزارهایی است که قصد دارید برای تهیه گزارش از آن استفاده کنید. شما می توانید از مدل های نرمال سازی شده ، شی مدار و چند بعدی  استفاده کنید.

مراحل ردیفی(افقی) معماری
این انتخاب شما ازآنچه سکوهای فیزیکی انجام خواهد داد که قسمتهایی از فرآیندهای متقارن که جایگزین می شوند.اگر شما نیاز به محدودکردن دسترسی پایین به ردیف یا سطح زمینه دارید، شما شاید مجبور باشید تا از مکانیسم های  متفاوت محافظتی متداول ، در سازمان خودتان استفاده کنید.به عنوان یک نظریه نهایی می توان گفت  که در طولانی مدت تصمیمات استحکام معماری داده ها شاید تاثیر بسیاری بر بازده تحقیق در داده های انبار کالا از هر تصمیم معماری دیگر خواهد داشت. هوشیار باشید تعیین استحکام در معماری داده ها تقریباً همیشه به استفاده از یک انبار کالا داده نیاز دارد تا تاثیر آن در حین کار معلوم گردد.

طراحی انبار کالا داده ها
متغیرهای کار و خطرهای تکنیکی خیلی منحصر بفرد به هر تاسیسات است. مصرف کننده های تجارت اهداف متفاوت و انتظارات متفاوتی دارند. داده های انبار اغلب بیشتر موفق است. اغلب به کلی طرح انتخاب شده یک ترکیبی از روش شناسی هایی است که به همراه ملزومات اضافی دیگر  در قسمت ذیل نشان داده شده است. انبار کالا داده ها، راه سوم را طراحی میکند .این طرح، بهترین الگوهای طرح هر دو روش شناسی ها را به همراه ملزومات اضافی دیگر استفاده میکند. دیدگاه کیمبال این است که داده های انبار کالا به عنوان یک حوزه انتخابی بازارهای داده است داده های بازار روی تحویل کار عینی برای بخشهایی در سازمان متمرکز است . اسیمون معتقد است که در ایجاد یک داده و انبار کالا روی یک پایه موضوع به موضوع است. 

برنامه ریزی برای انبار کالا داده ها
انبار کالای داده در اشکال و اندازه های متفاوتی وجود دارد که با هزینه و زمان در ارتباط است. رویکرد آغاز کردن یک پروژه انبار کالا داده ، متفاوت است. گامهایی که برای  شروع یک پروژه انبار کالا داده باید طی شود،  عبارتند از :

1) فراهم کردن اطلاعات حرفه ای
انبار کالا داده یک تفاوت بزرگ ایجاد میکند که  منجر به انجام آن می شود. آن یک بسته عظیم ذخیره میکند، که منجر به فراهم  شدن اطلاعات حرفه ای می گردد.

2 ) طرح ریزی داده ها
بدانید که می خواهید از چه معیار هایی برای ارزیابی انبار کالا  داده استفاده کنید و مطمئن شوید  که داده های مناسب برای تحلیل انبار کالا  داده فراهم شده است .

3 ) چه کسی از انبار کالا داده  استفاده خواهد کرد.
قدرت برای انبار کالا داده مشتریان ، تجارت و مدیران مالی هستند . انبار کالا داده نشانه های واضحی را ارائه می دهد که چگونه این حرفه اجرا می گردد. همیشه به یاد داشته باشید که داده های باید به طور جذابی نشان داده شده باشند و درآن صورت مدیران احساس آرامش خواهند کرد.

4 ) یکپارچگی درخواست های خارجی
بیشتر پروژه های انبارهای کالای داده به کمک توانایی هایشان، داده ها  را از درخواستهای خارجی استخراج می کنند .

5 ) تکنولوژِی کدام تکنولوژی !
در سطح بیت و بایتها یک انبار کالا داده، یک پایگاه داده است. متخصصان فن آوری اطلاعات باید بفهمند که چطور سازمان به داده دسترسی می یابد و از آن استفاده می کند و چگونه ابزار های هوش تجاری می تواند در بدست آوردن اهداف سازمانی به کار گرفته شود.

نتیجه گیری
بران در سال 1995ده گام را که برای ایجاد یک انبار کالای داده موفق باید برداشته شود را پیشنهاد کرده است:

1- مجموعه ای از بر آمدهای کار که نیاز دارد تا توسط انبار کالا داده هل شود ، به طور واضح تعریف کنید. 
2 - معیارهای عملیاتی،مالی و مدیریتی و  معیارهای دیگر را توسط اجرای موفق که اندازه گیری شده و ارزیابی شده باشد را شناسایی کنید.
3- آنچه که داده ها در یک انبار کالای داده به آن نیاز دارند ،تعیین کنید.
4- یک انبار کالای داده را با به کارگیری یک مدل داده  که برای  حمایت از تصمیمات مناسب است، طراحی کنید. 
5- داده ها و اندازه فهرست راهنمای داده های ضروری انبار کالا و پروژه را در سال بعد تخمین بزنید.
6-فراوانی داده های جدید که به انبار کالا اضافه خواهند شد و تخمین مقادیر داده ها  را تعیین کنید. 
7- آزمایش داده های انبار کالا با یک زیر مجموعه از داده های واقعی ، بررسی کنید.
8-  نحوه اجرای مصرف کننده های نهایی را داشته باشید و برای دوره ای از زمان با نسخه آزمایشی کار کنید.
9- استراتژی های تولید آینده فروشندگان را  به خصوص آنهایی را که  وابسته به انبار کالا داده  هستند، درک کنید و معیارهای موفق را ارزشیابی کنید.
10- در آموزش و یادگیری تکنولوژی مشتری- خدمت گذار شبکه و یونیکس را بررسی کنید.

فواید داشتن معماری انبار کالا داده ها به شرح زیر هستند:

ارائه یک چهارچوب سازمان: این معماری، خطوطی را بر اساس جزئیات فردی ترسیم می کند ،اینکه  چه کسانی عهده دار کدام بخشها هستند. انعطاف پذیری و نگهداری بهبود یافته: به شما اجازه می دهد سرعت منابع داده های جدیدرا افزایش دهید.  توسعه و استفاده مجدد سریعتر: توسعه دهندگان انبار کالا بهتر می توانند فرآیند داده های انبار کالا را درک کنند محتویات داده های پایه و نقشهای کار با سرعت بیشتر.
ابزار های ارتباطی و مدیریتی : انتظارات را تعریف کنید، نقش ها و مسئولیت ها را تعیین کنید و برای فهمیدن نیاز های مشتریان با آنها ارتباط برقرار کنید.
هماهنگ کردن تلاشهای همزمان : تلاشهای چند گانه مستقل، یک شانس برای پوشش موفقیت آمیز دارند.همچنین های بازار های داده بدون معماری ، لوله بخاری های آینده خواهند شد.

 اطلاعات در محیط کاری امروزه اساسی هستند. انبار کالا داده ، داده ها به اطلاعاتی که در ثبات و هوش سازمانی نقش دارد ، تغییر شکل می دهند. انبار کالا داده ، به عنوان سرمایه مهم در سرمایه گذاری محسوب می شود. انبار کالا داده می تواند پایه ای از کار  برای  تحصیل فواید رقابتی باشد و آینده ای روشن برای آن قابل پیش بینی است.

نگارنده: علی لفظی قاضی
http://tarah.somee.com/computer/data%20warehousing.asp

گرید کامپیوتینگ چیست؟ what is grid computing

گرید کامپیوتینگ(Grid Computing) تکنولوژی تسهیم کردن منابع شبکه ها/دامنه های مختلف و ناهمگون و مبتنی بر سرویس دریافتی است. مثالی می آوریم، شما کلید برق را میزنید و لامپ روشن میشود. زدن کلید برق به عنوان درخواست سرویس و روشن شدن لامپ نیز دریافت سرویس است. آیا برای شما به عنوان مصرف کننده سرویس، اهمیتی دارد که این برق در کدام نیروگاه تولید شده است؟! قطعاً نه.

در گرید کامپیوتینگ بجای در اختیار داشتن منابع گران قیمت اختصاصی که معمولاً بخش اعظم ظرفیت آن نیز خالی خواهد ماند، ترجیح داده میشود تا منابع ارزان قیمتی تهیه شده و بین شبکه ها تسهیم گردد. در این صورت به هنگام لود کاری، از ظرفیت خالی منابع سایر شبکه ها استفاده خواهد شد. این تکنولوژی بخصوص در کمپانی های چند ملیتی که در قاره های مختلف دارای Data center هستند مورد استفاده قرار خواهد گرفت چرا که در سایر قاره ها، مراکز داده در خارج از ساعت کاری بوده و ترافیک کاری آنها به حداقل رسیده است پس میتوان از منابع سخت افزاری آنها برای قاره ای که هم اکنون دارای لود کاری بیشینه ای است سود جست.

منبع:کتاب رهیافتی بر هوشمندی کسب و کار، انباره داده و داده کاوی.  نگارنده خشایار جام سحر

برای اطلاعات بیشتر رجوع کنید به  http://en.wikipedia.org/wiki/Grid_computing
http://www.gridcomputing.com
http://gridcomputing1.blogfa.com/post-62.aspx

مجازی سازی چیست؟(خشایار جام سحر)

مجازی سازی چیست؟
مجازی سازی تکنولوژی است که سخت افزار را به نرم افزار تبدیل می کند. باید دانست که مجازی سازی، شبیه سازی(Simulation) و تقلید(Emulation) نیست. شبیه سازی یعنی اینکه چیزی شبیه چیز دیگری باشد، مثال بارز آن شبیه سازهای پرواز هستند. Emulator، نرم افزاری است که دستورات ماشینی مجازی را برای ماشین فیزیکی ترجمه و قابل فهم می نماید.

منبع: کتابهای آموزشی VMWare ESXi 4.1 .

10 سوال از سوی Shaku Atre.

The 10 columns already published in Information Management are:

1. Who in the World Doesn’t Want to Evaluate Business Intelligence Products? A Guide to Evaluating Business Intelligence Products
2. Who in the World Needs a Data Warehouse? Who needs a data warehouse if it takes VERY long to build one and it provides access only to OLD data in the first place?
3. Who in the World is asking for More Data? Right data in the form of actionable information, to the right people, at the right time and at the right cost is the right BI
4. Who in the World Wants to Change Cars on Every Block During Chaotic Traffic in a Large City? User experience of BI applications should not be chaotic
5. Who in the World Doesn’t Want to Fly into Clouds to Reach Faraway Places? Private, Public, Hybrid Clouds
6. Who in the World Wants to Remain Locked up All the Time? : “Doing more with less” With Open-Source BI
7. Who in the World is going to Use Only Words and Numbers in Reports? Dashboards: Is it the new face of Business Intelligence?
8. Who in the World Needs a Hard Drive? In-memory analytics
9. Who in the World wants to just be structured? Bringing Unstructured Data into the BI World
10. Who in the World Doesn’t want to be Big, Strong and Fast? Who in the World is Driving Application Development for scalability?

منبع: آخرین خبرنامه Shaku Atre نویسنده کتاب DW/BI Roadmap .

Medieval IT Best Practices.

Enter the world of best practices, where we sometimes forget why we do things a certain way. Best practices is a commonly used term – particularly in IT – but the term’s meaning is often unclear. If you search for a definition of best practices, the text books say that a best practice is a technique, method, process, activity, incentive, or reward that is believed to be more effective at delivering a particular outcome than any other technique, method, process, etc., when applied to a particular condition or circumstance. According to other definitions, best practices describe the most efficient (least amount of effort) and effective (best results) way of accomplishing a task, based on repeatable procedures that have proven themselves over time for large numbers of people.

In IT, best practices has many meanings. Sometimes best practices consist of templates that come with a software package. These templates contain certain workflows, business processes, standard reports and performance indicators. Step-by-step manuals on how to best implement the software or "hints and tips" (e.g., how to best tune a database or parameterize an application) are also considered by some to be best practices.

The idea of best practices is very attractive. "Plug and play" and "plain vanilla" are terms often heard when best practices are advocated. Adopting them minimizes the risk in a project. After all, the essence of best practices is that they are proven, so you can't go wrong. Because best practices are bound to be more complete than what you could have come up with yourself, you don't have to reinvent the wheel. You can stand on the shoulders of others. What could be wrong about learning from others, while at the same time saving heaps of time and money? And learning from best practices shouldn't be limited to your specific industry; other industries may have already solved the problems you are facing.

Another great thing about best practices is that they can form the basis of a benchmark^.1 Benchmarking is used to measure the performance of a certain activity and compare it to a peer group within the company, or a peer group of other companies. If you share the same set of processes, way of working, or means of data collection, there is a common basis to compare. This comparison informs you how much better you are than average-in-class or how far removed you are from best-in-class. The measure of success can be anything, ranging from operational measures such as cost, quality and speed, to more strategic measures such as vision, agility, or alignment.

Best practices are not without criticism. The objection most heard is that although a best practice may work in one situation, it may not work when you change the context or the circumstances. For instance, a best practice top-down software implementation may not work in an organization that has a culture that favors bottom-up solutions. Different organizations have different maturity levels, skills and capabilities. Someone else’s best practices could be your worst nightmare. The context of the best practice should be known before you try to apply it. How much of an issue this can be depends on the type of best practice being considered... When considering technical best practices, such as ways to tune a database, it is easier to recognize, change or create the right circumstances. This is harder to achieve when dealing with management best practices, such as a certain decision-making process or a change management approach. However, there are other objections that are more fundamental of nature.

Competing Schools of Thought

The problem with best practices is that there are so many of them, and often they conflict with each other. Each discipline has rigorously thought through its approach and has written the "bible" on the subject, usually including a comprehensive overview of do's and don'ts. In various disciplines, arguments about which approach is correct can go on for tens of years. Remember knowledge management from the 1990s? There were two schools of thought. One school presented the view that knowledge is tacit and located within an individual and his unique frame of reference. Therefore, knowledge management should focus on expertise location, helping people find other people who have certain knowledge. The other school of thought was convinced that knowledge is explicit and can be extracted, codified and stored in systems. Users could access these systems for specific knowledge or these systems could actively support users in their work. Although the term knowledge management is not used that much anymore, the ideology – and discussion for that matter – is back with a vengeance. Enterprise 2.0, consisting of all kinds of collaboration technologies, and Semantic Web, codifying the meaning of information, are bound to keep the discussion alive for many years to come.
 
Likewise, for the last fifteen years there has been a discussion in data warehousing. Bill Inmon heads the school of thought that says data models should be application neutral, and therefore normalized. Ralph Kimball, representing the other school of thought, prescribes a denormalized model – called star schema – emphasizing the end user looking for fast query responses and a data model that is easier to understand^{. 2} The first question among data warehouse professionals sometimes still tends to be "Are you in the Inmon or Kimball school?"
(by Frank Buytendijk)

منبع: http://www.b-eye-network.com/view/15238

دانش چیست؟ What is knowledge

Basic Types of Knowledge

"Knowledge" generally has two major meanings: (a) to be acquainted with someone or something; and (b) to know a fact. In English, both are covered by the verb "to know," but in other languages two verbs identify the concepts separately (e.g., in German, kennen and wissen, respectively). I am certain that no marketer of IT products and services is using "knowledge" to mean "acquainted with," as in "I know my neighbor" or "I know downtown Manhattan.”

So if marketers are not offering to introduce me to people, places, or things, they must mean knowing a fact. But there are problems here too. "Knowing," in this sense, means knowing about something that really exists, being assured that this knowledge is correct, and understanding that this level of assurance cannot apply to statements that are not true. Here I am paraphrasing the entry for "knowledge" in Baldwin's Dictionary of Philosophy and Psychology. Is this really what we are concerned with in data management? It does not seem very satisfying to me.

It is true that data vendors, such as those who sell data on corporations, individuals, financial instruments, etc., might claim to be selling knowledge. In my experience, they do not. Rather they claim that what they are selling is data, and it is up to their customers to turn it into knowledge. However, there are vendors of software products and services who do make claims about knowledge. They are most certainly not selling data, which might be regarded as the raw material of knowledge. Rather they are selling tools and techniques that they claim can produce knowledge or better manage it. Again, what is "knowledge" in this context?

Traditional Types of Knowledge

There is different traditional way of dividing (subtyping) knowledge, which is (a) immediate; and (b) mediate knowledge. Immediate knowledge is when we cannot deny a fact. If you, dear reader, see me robbing a 7-11, you know that I did it and a court of law will accept your testimony as evidence. Mediate knowledge, however, is knowledge that we acquire that has some kind of guarantee behind it. So if my neighbor tells you that I robbed a 7-11, your testimony will not be accepted from you in a court, because it is hearsay – it is mediate knowledge. Ultimately, however, we have to rely on mediate knowledge to a large extent. So if I am convicted of robbing the 7-11, and you have faith in the judicial process, then you can say that you know I did it. You have the guarantee you need.

I do not see how vendors can make any claims about immediate knowledge because immediate knowledge involves someone and the object of knowledge, and nothing more. But mediate knowledge has everything to do with data. Data is a medium in which supposed facts can be conveyed to us, and we can accept those facts as knowledge. But what can vendors claim about it?  Well, they might have more reliable ways by which facts end up as data. The data that comes from sensors that measure manufacturing processes or geographical locations seems to be like this. In this case, better software can result in more and improved knowledge.

But in the enterprises I work in, data is entered by humans,  purchased from vendors, or is simply a starting point for knowledge. Is knowledge just the collection of facts that are stored in such environments?  If so, then knowledge and data are the same. If this is , then knowledge management and data management are the same. This seems very unsatisfactory – instinctively we expect knowledge and data to be different. But how?  We do not seem to be getting much help from traditional definitions of "knowledge," so it might be more helpful to consider this in the specific context of data management.

Knowledge in Data Management

One of the promises of using data as a corporate asset is that a set of data can be used to produce new facts, that these can be facts that nobody knew before, and thus these facts can be regarded as new knowledge. This is very easy to see in business intelligence (BI) environments. For instance, an enterprise can accumulate data on individual customers and then calculate metrics, such as customer lifetime value. This is not something that an enterprise can simply go out and measure, like taking someone's temperature.  It is certainly something that was not known prior to accumulation and analysis of data. Data mining can provide even more astonishing examples, often revealing golden nuggets of information the enterprise can react to (e.g., buying patterns).
 
Another clue to what knowledge in data management might be comes from a definition by the Victorian philosopher Bernard Bosanquet – knowledge is "the representation of reality.”  Again, mere representation is data, but I think that we can kick this definition up a notch to be more helpful and suggest that knowledge is, in part, a model of a specific domain of human experience or subject area. Such a model (some might call it an "ontology") consists of concepts – their relations, rules about their behavior, and taxonomies that organize these concepts. Such a mental model is our knowledge of how things work in a particular domain of interest, and we put data into it to get results aligned to our purposes. This can include planning for the future, or understanding how a particular situation has come about. It enables us to successfully manipulate a representation of reality in our minds, rather than having to deal with only the real world. Anything that contributes to building or managing such models contributes to knowledge. And running such models generates knowledge.
  
Another aspect of knowledge in the context of data management is the need to successfully use a data resource to fuel the models that give us understanding of customers, business processes, etc. To do this we need to find the appropriate data in an enterprise data resource, understand what it means, determine if it is appropriate for the models (ontologies) that we want to run, and so on. Also, we need to know if the data at hand is such that it contains facts that will oblige us to modify these models. Products and services will be valuable if they help us go from data to knowledge by mapping general enterprise data to the specific models that are our understanding of little pieces of the enterprise and its activities. To some extent, this may be part of what is meant by "knowledge management." (by Malcolm Chisholm)

منبع: http://www.b-eye-network.com/view/15228

هوشمندی کسب و کار چابک Agile BI.

The Twelve (or so) Myths about Agile BI.  (Jim Gallo)

Agile development has been applied to software development projects for quite some time. In a white paper that was first published by Robert Holler in the May 2006 issue of Better Software Magazine, entitled "Five Myths of Agile Development," Mr. Holler addressed the following myths with respect to software development projects.

1. Agile Development is Undisciplined
2. Agile Teams Do Not Plan
3. Agile Development is Not Predictable
4. Agile Development Does Not Scale
5. Agile Development is Just Another Fad

In the past couple of years, we've begun to apply agile methods to business intelligence and data warehousing (BI/DW) projects.  Without a doubt, I've heard many of the same things addressed in Holler's white paper said about Agile BI from a number of sources.  Interestingly, when speaking with folks who are both familiar and unfamiliar with Agile BI, yet another set of misconceptions has arisen.  As a contributing architect in the development of Agile BI methods, I've compiled a list of Agile BI myths. As I sit here writing this blog post I'm not sure if I'll end up with ten, twelve or fifteen.  I encourage you to post your "Myths" here on my blog so we can discuss their validity. Who knows what I'll hear next!  At least for now, my list includes:

1. Agile BI is radical and new
2. There is no need to produce documentation when using Agile BI methods
3. Agile BI methods do not support sound BI/DW architecture principles
4. Agile BI displaces the software development lifecycle (SDLC) in its entirety
5. Agile software development methods can be applied without modification to BI/DW projects
6. When working as a part of an agile BI/DW team, anyone can work on anything, without consideration for roles and skills
7. Agile BI only works for small teams
8. Improvement in team velocity is all that matters
9. Agile BI methods only work well with seasoned, highly talented and experienced team members
10. All BI/DW tasks can start simultaneously because waterfall methods are no longer used
11. The BI/DW team must be collocated in order for agile methods to be successful
12. There is little to no correlation between story point estimating and project management estimating and budgeting

Look for future posts as I dispel each of these myths as we head down "The Path to Agility."

منبع: http://www.b-eye-network.com/blogs/gallo/archives/2010/09/the_twelve_or_s.php

5 دلیل شکست پروژه های انباره داده و هوشمندی کسب و کار . دلیل 1 از 5.

Why BI Projects Fail (1 of 5): The Allure of the Silver Bullet (Steve Dine)

The high failure rate of BI projects and programs has been well documented throughout the years.  The reasons why they fail has also been well documented, which leads to the obvious question of "why do they continue to fail at such a high rate?"   Our company is often brought in to assess existing BI programs and provide recommendations to organizations to help turn around their BI programs.  In a series of blogs, I'll address 5 of the most common reasons, why we see BI projects and programs fail.  These reasons are in no particular order as it's usually a combination of issues that play a part in the failure.

The first reason I'm going to tackle is what I like to call the allure of the silver bullet.  In most organizations, BI projects emerge out of an immediate need to report and analyze data that is not easily accessed.  It could be in a source system that has a complex schema, in multiple systems and require integration, be too voluminous to easily analyze, or one of many other data access related issues.  There also may, or may not, be tools available to facilitate the reporting and analytic process beyond MS Excel.   Whatever the reason, experienced BI practitioners will usually estimate the solution at 3 to 6 months on average if no BI infrastructure exists, or 30 to 90 days if one does.  In the face of this daunting estimate, the first instinct of many decision makers is to search for a less costly solution, in terms of both time and money.

Fortunately, for these decision makers, the market has recognized this opportunity and sprouted vendors that have developed pre-packaged reporting and analytic solutions to meet this need.  They are often created for a specific source system, subject area and/or industry vertical.  In some cases, they utilize custom interfaces, but more often they leverage existing BI front-end software.  If they provide ETL capabilities, then it's usually delivered as pre-developed mappings through an off-the-shelf tool.  The sales team provides a well polished demo and promises a solution in less than a week.  It sounds pretty convincing.  So, how can these pre-packaged analytic solutions lead to so many failed BI projects and programs?  The concept in itself isn't the issue, in fact in many cases it can help reduce the implementation time and cost, as well as provide value.  The issue is that these solutions aren't a silver bullet and are usually evaluated tactically rather than as part of the framework of the overall BI strategy.

BI project success and failure is measured by most companies as whether the projects are delivered on-time and on-budget.  In fewer cases, they are measured on the return on investment (ROI).  The challenge with pre-packaged analytic solutions is that they are sold as a quick hit and low cost solution to the traditional BI project.  What they usually fail to mention is that this is only possible in the case where an organization has not customized their ERP system, has a high level of data quality, only moderate data volumes, only requires sourcing data from one system and has 100% overlap in reporting requirements.  Unfortunately, this doesn't describe the state of most data environments.  What is more common is that these projects require more time to implement at a cost that often approaches, if not exceeds, a traditional solution.  If these factors aren't accounted for in the project timeline, budget and ROI calculation, they are seen as having failed.

The challenge that pre-packaged analytic solutions present to the long term success of BI programs is that their data model is often difficult to scale and once customized, difficult to upgrade, especially when an ETL and semantic models are included.  BI architectures that are difficult to change, given the constant change of business and requirements on BI, is a recipe for failure.  They also often don't track changes to the data and provide a flexible architecture, such as staging layers that facilitate the addition of new source systems.  In some instances, it ties organizations to a data integration (DI) tool that doesn't scale or adds another tool to manage in their environment.  At one customer we assessed, the DI tool that was used by the pre-packaged analytic solution was the same one they were using, but a different version and so they had to maintain two versions of the same software.

As I mentioned, the issue isn't with pre-packaged analytic solutions per se, it's that they are often purchased for the wrong reasons and not factored in to their long term BI strategy.  Organizations can derive a great deal of value from these solutions, but don't get lulled into believing that they are a silver bullet.

منبع: http://www.b-eye-network.com/blogs/dine/archives/2011/02/why_bi_projects.php

درخواست ارائه مقاله به کنفرانس انبار داده و هوشمندی کسب و کار اروپا در لندن.

Call for Papers: Data Warehousing and Business Intelligence Conference in London

Are you interested in speaking at the Data Warehouse & Business Intelligence European Conference in London coming November? If you are, please fill in the call for papers.

Previous editions were very successful and attracted more than 200 delegates. Evaluations showed that the attendees were very pleased with the selected speakers, the topics, and setup of the conference.

The 2011 edition is aimed at all aspects of data warehousing and business intelligence, including: trends, design guidelines, product overviews and comparisons, best practices, and new evolving technologies. And like the previous years, the conference is organized together with the highly successful European Data Management and Information Quality Conference.

With this year's call for presentations we are trying to attract proposals for sessions on traditional and future data warehousing and business intelligence aspects. Delegates have expressed a preference for the use of case studies rather than theoretical or abstract topics. We would particularly like practitioners in the field to respond to this call for papers. We encourage new speakers to apply. Success stories - case studies where data warehousing and business intelligence have produced real bottom-line benefits are very much appreciated.

Example topics for proposals are:

• Business and data analytics
• BI in the cloud
• Data modelling for data warehouses
• The maturity of analytical database servers
• Star schema, snowflake and data vault models
• Selling business intelligence to the business
• Big data analytics
• The relationship between master data management and data warehousing
• Guidelines for using ETL tools
• Data virtualization and data federation
• The BI mashup
• The need for Master Data Management in a data warehouse environment
• BAM (Business Activity Monitoring) and KPI (Key Performance Indicators)
• New database technology for implementing data warehouses, such as
  • Business intelligence as ROI for the data warehouse
  • Who needs real-time data warehouses?
  • Business Optimization through BPEL, BAM and SOA
• BI scorecarding
• Customer analytics and insight
• Text mining and text analytics
• Open source BI
• Corporate Performance Management
• NoSQL in a data warehouse environment

Looking forward to your proposal, and hope to see you in London coming November.
Rick van der Lans (Chairman of the Data Warehouse & Business Intelligence European Conference 2011)

منبع: http://www.irmuk.co.uk/dm2011/callforspeakers.cfm

 http://www.b-eye-network.com/blogs/vanderlans/archives/2011/03/call_for_papers.php

شکست در پروژه های انباره داده و هوش تجاری به چه معنا است.

What Does Failed Mean? (Laura Madsen)

There was a LinkedIn discussion posted a few weeks back asking why BI deployments so often failed.  After a number of comments on things like "poor requirements" and "lack of project management" I had to chime in, after all, I have never really seen a BI deployment fail because my project manager missed the deadline, went over budget or under/over scope. 

First, it begs the question:  "What does failed mean?"  If, to you, failed means it costs more than you originally thought then yes, perhaps project management is to blame, or your expectation setting on estimates (another post for another time).  If failed means that you released reports that missed the business users needs then perhaps you can blame poor requirements, but how about looking to your dynamic business model, or the change that has taken place since the last time you actually asked the business what they wanted.

In truth, I wish that it were that easy.  I wish that all I would need is a rock-star project manager and BA to address these relatively simple aspects of BI deployments and all would be grand.  Frankly, I have worked with rock-star project managers and BA's (you know who you are) and the deployment still 'failed'. 

You can't handle the truth
The truth is much harder than that.  The truth is so much more multi-faceted than that it's almost hard to conceive.  And for many of those that commented on LinkedIn with something like "bad requirements" I am just not sure you can handle the truth (forgive me for quoting a Tom Cruise movie).

BI lives in the juxtaposition of IT and business, some of my peers lovingly call it purgatory.  But, as many of you know, that's not an easy place to reside.  The gap is large and the bridge built between it is often poorly constructed.  You cannot simply request better requirements or more aggressive project management and go home thinking you have it nailed, I assure you that you have not.

BI is a living breathing thing that resides within a larger culture of your business.  The challenging thing about BI is that you have to know how to manage both IT concepts like data modeling, ETL and application development as well as knowing, balancing, predicting and managing the needs of your business. 

منبع: http://www.b-eye-network.com/blogs/lmadsen/archives/2011/01/what_does_faile.php

منشا پیدایش عبارت BI در بیش از 60 سال پیش.

Where Did The Term BI Come From? (Claudia Imhoff)

I just watched a cute video by Nic Smith on the history of Business Intelligence. Granted it was a shill for Microsoft but still it was cute and mostly accurate. However, there was one erroneous attribute that I think most people may not know. The term, "Business Intelligence" was not coined by Howard Dresner as stated in the video -- he did a fine job of making it popular but he did not invent the term. Read on to find out where it was first used...

I love history. In fact, I was a semester away from having a history degree in college (German history was my favorite). Because of this interest, I have always been curious about the origins of things. So since I have been immersed in Business Intelligence (BI) for the past 20+ years, I wondered about the term, BI -- where did it come from, who first used the term, did it have a similar meaning to our current definition? Fortunately for me, I ran into a good friend of mine, Alan Meyer, InfoSphere Marketing for IBM's System z (that's the mainframe for those of you not up on IBM's nomenclature) who sent me an article that is the earliest documented usage of BI in its modern sense that I can find.

So where was BI first used (drum roll please...)?
A paper written by H.P.Luhn in IBM Journal, titled "A Business Intelligence System:. The date was October 1958! Yes -- 61 years ago. Dan Vesset of IDC wrote about it in his article on the 50th birthday of DB2. (You don't look a day over 39...)...

So was Luhn's definition on target? You bet it was. Here are just a few excerpts from the short paper and remember -- these were written over 60 years ago:

Abstract: "An automatic system is being developed to disseminate information to the various sections of any industrial, scientific, or government organization. This intelligence system will utilize data-processing machines for auto-extracting and auto-encoding of documents and for creating interest profiles for each of the 'action points' in an organization."

In the body of the paper: "Information is now being generated and utilized at an ever-increasing rate because of the accelerated pace and scope of human activities and the steady rise in the average level of education. At the same time, the growth of organizations and increased specialization and divisionalization have created new barriers to the flow of information. There is also a growing need for more prompt decisions at levels of responsibility far below those customary in the past. Undoubtedly the most formidable communications problem is the sheer bulk of information that has to be dealt with. In view of the present growth trends, automation appears to offer the most efficient methods for retrieval and dissemination of this information."

"The objective of the system is to supply suitable information to support specific activities carried out by individuals, groups, departments, divisions, or even larger units... To that end, the system concerns itself with the admission of acquisition of new information, its dissemination, storage, retrieval, and transmittal to the action points it servers."

Granted, at this time, the new sources of information were things like paper documents, microfilm, and microfiche but Luhn's ideas are spot on with today's definition of BI. As much as we credit Bill Inmon, Ralph Kimball and, yes, Howard Dresner with coming up with these ideas (and they certainly deserve a lot of credit), I have to say that H.P. Luhn was the originator of many of the ideas behind the data warehouse and the ultimate goal of Business Intelligence. Hats off to this true visionary! Wonder what ever happened to him...

منبع: http://www.b-eye-network.com/blogs/imhoff/archives/2009/03/where_did_the_t.php