هوش تجاری (Business Intelligence)

هوش تجاری (Business Intelligence)

به اشتراک بگذاریم برای یادگیری، یاد بگیریم برای به اشتراک گذاری
هوش تجاری (Business Intelligence)

هوش تجاری (Business Intelligence)

به اشتراک بگذاریم برای یادگیری، یاد بگیریم برای به اشتراک گذاری

عوامل حیاتی در موفقیت سیستم‌های هوش تجاری (Critical Success Factors)


اجرای سیستم هوش تجاری یک تعهد پیچیده است که به منابع قابل توجهی نیاز دارد


مقدمه

اخیرا سیستم‌های هوش تجاری با اولویت بالایی در فهرست بسیاری از مدیران فناوری اطلاعات قرار گرفته است. [12,11]

طبق نظر رین اشمیت و فرانسیس [22]، سیستم هوش تجاری مجموعه یکپارچه ای از ابزارها، فن آوری‌ها و محصولات برنامه ریزی شده ایست که برای جمع آوری، هماهنگی، تحلیل و در دسترس قرار دادن داده ها استفاده می شوند. بطور ساده می توان گفت وظایف اصلی سیستم هوش تجاری شامل اکتشاف هوشمند، یکپارچه سازی، تجمیع و تحلیل چند بعدی داده های نشات گرفته از منابع مختلف اطلاعاتی است [21]بطور ضمنی در این تعریف داده‌ها، منابع بسیار با ارزش سازمان در نظر گرفته شده است بطوریکه از کمیت به کیفیت تبدیل می شوند[27] . در نتیجه امکان یکپارچه سازی داده‌های حجیم سازمان از منابع داده‌ای مختلف فراهم می‌شود و دیدی 360 درجه از کسب و کار ارائه می‌دهد. [5, 27] بنابراین برای تسهیل بهبود تصمیم گیری، اطلاعات با معنی می‌توانند در زمان و مکان مناسب، و به شکل مناسب برای کمک به افراد، بخش‌ها، گروه‌ها و یا حتی واحدهای بزرگتر ارائه شوند.

 بر اساس تحقیق‌های بسیاری که در مورد CSFها انجام شده، پیاده سازی سیستم‌های هوش تجاری پیرو سنت و رسوم پروژه‌های کاربردی ماننده سیستم‌های تراکنشی نیست [10]. اما این نوع پروژه‌ها ویژگی‌های مشابهی هم با سیستم‌های زیر بنایی همچون ERP ها دارند. پیاده سازی سیستم‌های هوش تجاری فعالیت‌های ساده‌ای همچون خرید ترکیبی از نرم افزارها و سخت افزارها نمی‌باشد بلکه یک تعهد پیچیده است که نیاز به زیرساخت‌ها و منابع مناسب در طول یک دوره دارد. [10,19,18]


گام اول در CSFها بحث و جستجو

چارچوب CSFها در شکل زیر نشان داده شده و بطور خلاصه تشریح می‌کند که چطور مجموعه‌ای از عوامل مهم منجر به اجرای موفقیت آمیز سیستم هوش تجاری می‌شوند. آریاچاندرا و واتسون [2]معیار موفقیت اجرای این تحقیق را در دو بعد کلیدی می‌بینند: عملکرد فرایند (مانند اینکه فرایند پیاده سازی سیستم هوش تجاری چطور پیش رفت) و عملکرد زیرساخت(بطور مثال کیفیت سیستم و استاندارد خروجی).

 عملکرد زیرساخت به سه متغیر عمده موفقیت IS شباهت دارد که توسط دلون و مک لین توصیف شده [7, 8]، یعنی کیفیت سیستم، کیفیت اطلاعات و کاربرد سیستم، در حالیکه عملکرد فرایند می‌تواند از نظر برنامه زمانی و بودجه ارزیابی شوند. بطور خاص، کیفیت سیستم مرتبط با ویژگی‌ کارایی سیستم پردازش اطلاعات است. یعنی سیستم باید انعطاف پذیر و قابل سنجش باشد و توانایی یکپارچه کردن داده ها را داشته باشد [2, 7, 8]. کیفیت اطلاعات به دقت، کامل بودن، بهنگام بودن، تناسب، انسجام و سودمندی اطلاعات تولید شده توسط سیستم اشاره میکند[2, 7, 8]. کاربرد سیستم به عنوان "میزان استفاده از خروجی یک سیستم اطلاعاتی" تعریف می شود[7, 8]. متعاقبا،کاربران و سازمان‌ها مزایای اجرای سیستم هوش تجاری را ارزیابی می کنند[13].. این برداشت از مزایا قسمتی از زنجیره تکاملی تعاملی کسب و کار در نظر گرفته می‌شود که برای حمایت بیشتر از نیازهای در حال تحول کسب و کار منجر به بهبود سیستم های هوش تجاری می شود[3,4].

 " سیستم تنها زمانی موفق خواهد شد که کاربران کسب و کار به شناسایی و مدل سازی دانش همچنین نظارت و اصلاح داده را بطور مداوم ادامه دهند. [25]"

بطور خلاصه این قائده یکی از عوامل حیاتی موفقیت در اجرای سیستم‌های هوش تجاری است و فقدان آنها منجر به شکست سیستم می شود.


بعد سازمانی

حمایت و پشتیبانی مدیریت

حمایت و پشتیبانی مدیریت متعهد بطور گستردهای به عنوان مهمترین عامل پیاده سازی سیستم هوش تجاری بیان شده است. پشتیبانی و حمایت مستمر مدیران کسب و کار، کسب منابع عملیاتی لازم مانند بودجه، مهارت‌های انسانی و ملزومات دیگر را آسانتر می‌سازد.

" حفظ تعهد و پشتیبانی حامی پروژه‌ها در سراسر پروژه-زیرا شرایط می‌توانند در طول عمر پروژه تغییر کنند."

 

اگر بانی یا مدیر پروژه از جانب کسب و کار سازمانی باشد سودمندتر از وقتی است که از واحد IT باشد. بطور مشابه مطالعات واتسون و همکاران[30] هم این مسئله را تائید می کند در واقع بانی باید نیاز جدی به قابلیت‌های هوش تجاری را برای هدفی خاص حس کرده باشد.

پیاده سازی سیستم هوش تجاری، عملی ابتکاری برای بهبود تطابق پذیری اطلاعات جهت پشتیبانی تصمیم است [3, 4]. به عنوان مثال مدل بودجه بندی نمونه مبتنی بر تقاضا که برای پیاده سازی سیستم‌های تراکنشی است برای سیستم های هوش تجاری که ماهیت تکاملی دارند کاربرد ندارد. سیستم هوش تجاری از طریق فرایند توسعه تکرارشونده، مطابق با الزامات کسب و کار پویا تکامل می یابد[19]. بنابراین شروع هوش تجاری بخصوص برای سازمان‌هایی در مقیاس بزرگ نیازمند اختصاص منابع و بودجه مناسب از سوی مدیریت ارشد برای غلبه بر مسائل معمول سازمان است. برخلاف سیستم‌های مرسوم پردازش تراکنش برخط (OLTP)، چالش‌های سازمانی در طول دوره استقرار و در عمل بوجود می‌آیند، این چالش‌ها در مسائل زیادی مانند پردازش کسب و کار، مالکیت داده، کیفیت داده، نظارت و ساختار سازمانی آشکار می‌شود. بسیاری از واحدها تمایل به تمرکز بر دستاوردهای تاکتیکی خود دارند و اثرات ناهموار تحمیل شده بر واحدهای کسب و کار دیگر را نادیده می گیرند.

 

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

بنابراین تعهد و درگیر بودن مدیریت ارشد مخصوصا در شکستن موانع تغییر و "ذهنیت" در سازمان ضروری است.

 

استراتژی مناسب و چشم انداز روشن

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

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

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

 " سیستم هوش تجاریی که توسط کسب و کار هدایت نشده باشد سیستمی شکست خورده است. هوش تجاری مفهومی کسب و کار محور است و مشایعت فناوری اطلاعات برای حل مشکل به ندرت نتیجه خوبی دارد.(منظور مشکل کسب و کار است)"

 کسب و کاری یکپارچه که از تحلیل دقیق نیازها منتج می شود احتمال بدست آوردن حمایت مدیریت ارشد را افزایش می‌دهد.

 " به منظور حمایت مدیران ارشد؛ آن‌ها باید درک کنند؛ زمانی که درک کردند به راحتی می‌توانند حمایت کنند."

 بنابراین کسب و کار اصولی منافع استراتژیک پیشنهادی، منابع، هزینه‌ها و زمان بندی را شناسایی می کند. درک اینکه پیاده سازی هوش تجاری یک پروژه نیست بلکه فرایند است بسیار مهم است .[4] سیستمهای هوش تجاری بطور پویا تکامل می‌یابند و لزوما محدود و قابل پیش بینی نیستند. به عنوان مثال حجم پایگاه داده تحلیلی در سال اول بهره برداری دو برابر می شود و همچنین تعداد کاربران بطور قابل توجهی افزایش می یابد [22].

 

بعد فرایندی

پشتیبانی کسب و کار محور و ترکیب متعادل تیم

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

"تیم به رهبر نیاز دارد. رهبر کسی است که ابزارها را می شناسد کسب و کار و تکنولوژی را درک می کند و می‌تواند الزامات کسب و کار را به معماری هوش تجاری(سطح بالا) برای سیستم ترجمه کند."

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

بنابراین رهبر باید از همکاری میان واحدهای سازمان و تیم پروژه هوش تجاری اطمینان حاصل کند.

 اگرچه پروژه‌های هوش تجاری اساسا متفاوت از پروژه‌های OLTP است [22,10] سازمان ها در اکثر پروژه‌های پیاده سازی سیستم‌های اطلاعاتی تمایل دارند به کارکنان حوزه فناوری اطلاعاتشان به عنوان مسئول تکیه کنند. تیم پروژه باید قوی و پایدار باشد که بتوانند با نیازهای در حال ظهور و در حال تغییر سازگار شود و برای این کار به تیمی با اعضای شایسته نیاز است.

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

ازدیدگاه فنی، پروژه هوش تجاری قابل مقایسه با پروژه یکپارچه سازی سیستم‌ها است و نیاز به مشارکت فعال متخصصان فنی سازمان دارد[19]. بطور نمونه تیم پروژه با سیستم عامل‌های متنوع، پایگاه داده‌های متفاوت، رابط‌های چندگانه، اتصال به سیستم های قدیمی، مجموعه ای از ابزار، و غیره سر و کار دارد همه این کارها به افرادی با مهارت‌های مختلف نیاز دارد. بنابراین کلید موفقیت، ترکیب مناسبی از متخصصان فنی و کسب و کار است.

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

 

رویکرد توسعه تکرارشونده و مبتنی بر کسب و کار

برنامه ریزی و هدف گذاری پروژه مبتنی بر کسب و کار اجازه می دهد که تیم هوش تجاری به بهترین فرصت‌ها برای بهبود تمرکز کنند. هدف گذاری به انتخاب پارامترهای روشن کمک می کند و درک مشترکی از اینکه چه چیزی در محدوده است و چه چیزی باید حذف شود را در میان همه ذینفعان کسب و کار ایجاد می‌کند. [1]

"موفقیت نود درصد پروژه ماقبل از روز اول تعیین می شود. این موفقیت بر پایه داشتن محدوده‌ای روشن و مشخص، داشتن انتظارات و جدول زمانی واقع گرایانه و بودجه مناسب از پیش مشخص شده، است"

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

 "محدوده باید کنترل شود زیرا "جهش محدوده" می تواند باعث نرسیدن به هدف شود. این بدان معنی نیست که شما نمی توانید عمل یا فرایند کنترل تغییر در مکان داشته باشید بلکه شکلی از کنترل است. پروژه های زیادی بخاطر جهش محدوده، توزیعشان به خطا رفته و هزینه داشته‌اند."

 متخصصان زیادی توصیه می‌کنند که با تغییرات و تحولات کوچک شروع کنید و سپس توزیع افزایشی (تدریجی) که رویکردی بنام "تعاملی" ست را اتخاذ کنیم. تلاشهایی که برای تغییرات در مقیاس بزرگ انجام می‌شود همیشه مملو از ریسک‌های بزرگتری با توجه به متغیرهای اساسی که بطور همزمان اداره می شوند، است. [1] علاوه بر آن کسب و کارهای مدرن خیلی سریع تغییر می‌کنند و همیشه بدنبال شناسایی تاثیرات فوری تغییرات هستند. بنابراین رویکرد توزیع افزایشی احتیاط آمیزتر است و ابزارهایی برای تحویل در زمان کوتاه و گام‌های قابل اندازه گیری را فراهم می کند. علاوه بر آن رویکرد توزیع افزایشی اجازه ساخت راه حلی بلند مدت در تضاد با اصطلاح کوتاه مدت را می دهد [1, 4].

 " رویکرد توزیع افزایشی ریسک را مدیریت می‌کند، نتایج ملموس قابل مشاهده برای مشتری را فراهم می کند توانایی بدست آوردن مالکیت مشتری را بهبود می بخشد، انتقال دانش را تسهیل می‌کند و راه حلی بلند مدت منظور می‌کند."

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

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

بنابراین، رویکرد توزیع افزایشی (تدریجی) به سازمان اجازه می دهد که روی مسائل حیاتی تمرکز کند و تیم‌ها را برای اثبات عملی و سازنده بودن پیاده سازی سیستم برای سازمان تایید کند.

مدیریت تغییر کاربر گرا

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

 " کاربران باید شریک مهمی در ساخت و تحویل سیستم باشند. بدون ورودی مداومشان، نمی توانیم سیستم درستی ارائه دهیم.

بنابراین نمی‌توان برای دستیابی به نیازهای کاربران، تیم پروژه ای را طراحی و سیستم هوش تجاری‌ را پیاده سازی کرد اما آن‌ها را مشارکت نداد."

 آشکار است که کاربران کلیدی باید در سراسر چرخه پیاده سازی درگیر باشند چون آنها می توانند ورودی‌های ارزشمندی را ارائه دهند که در غیر اینصورت تیم هوش تجاری ممکن است نادیده بگیرد. ابعاد داده‌ها، قوانین کسب و کار، متا دیتا و چارچوب داده که لازم است توسط کاربران کسب و کار در سیستم ثبت شوند و در مقابل اقلام قابل تحویل، تائید شوند. [29] در نتیجه، پشتیبانی کاربر بطور مداوم در پاسخ به نیازمندیهای کسب و کار مکمل کاربردهای هوش تجاری و سبب تکامل است. [10]

 

بعد تکنیکی

چارچوب فنی انعطاف پذیر و مقیاس پذیر، مبتنی بر کسب و کار

چارچوب فنی سیستم هوش تجاری باید قادر به تطبیق مقیاس پذیری و انعطاف پذیری ملزومات در راستای نیازهای پویای کسب و کار باشد. طراحی زیرساخت انعطاف پذیر و مقیاس پذیر اجازه توسعه آسان سیستم برای هم راستایی با نیازهای اطلاعاتی در حال تحول را می دهد[21]. بنابراین دید استراتژیک مستتر در طراحی چارچوب سیستم مقیاس پذیر می تواند شامل منابع داده اضافی، ویژگی‌ها و ابعاد برای تحلیلهای مبتنی بر واقعیت شود و میتواند داده‌های اضافی تامین کنندگان، پیمانکاران، نهادهای نظارتی و معیارهای صنعتی را ترکیب کند. در نتیجه اجازه ساخت راه حل بلند مدت برای پاسخگویی به نیازهای فزاینده کسب و کار را می‌دهد.

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

 در واقع زیر سازی در هوش تجاری برای همه کارها اساسی است و تا لایه فنی برای تمام محیط هوش تجاری شامل استقرار سخت افزار و نرم افزار جدید، قابلیت همکاری میان سیستم‌های قدیمی و محیط هوش تجاری جدید در یک شبکه، پایگاه داده، زیرسیستم مدیریت و غیره می شود. [19] ایجاد زیرساخت فنی برای راه حل هوش تجاری اولیه همیشه زمان بر است. [29]اما با انتخاب درست اجزای نرم افزار و سخت افزار انعطاف پذیر و قابل تنظیم، تلاش برای چرخه بعدی می تواند به حداقل برسد. در نتیجه سیستم می‌تواند خود را با ملزومات در حال ظهور و همیشه در حال تغییر کسب و کار تطبیق دهد.

 

یکپارچگی و کیفیت داده‌های پایدار

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

و باید توجه داشت که بدون داده های با کیفیت، هوش تجاری هوشمند نیست

 

پی نوشت: این مقاله ترجمه‌ای از تحقیقی است که توسط WILLIAM YEOH و ANDY KORONIOS در دانشگاه استرالیا انجام گرفته.


منبع


با تشکر فراوان از خانم باقرزاده


[1] Ang, J. & Teo, T. S. H. “Management Issues in Data

Warehousing: Insights from the Housing and Development

Board,” Journal of Decision Support Systems, 29(1), 2000,

11-20.

[2] Ariyachandra, T. & Watson, H. “Which Data Warehouse

Architecture Is Most Successful?” Business Intelligence

Journal, 11(1), 2006.

[3] Arnott, D. “Decision Support Systems Evolution:

Framework, Case Study and Research Agenda,” European

Journal of Information Systems, 13(4), 2004, 247-259.

[4] Arnott, D. & Pervan, G. “A Critical Analysis of Decision

Support Systems Research,” Journal of Information Technology,

20(2), 2005, 67-87.

[5] Bose, R. “Advanced Analytics: Opportunities and

Challenges,” Industrial Management & Data Systems,

109(2), 2009, 155-172.

[7] Delone, W., & McLean, E. “Information Systems Success:

The Quest for the Dependent Variable,” Journal of

Information System Research, 3(1), 1992, 60-95.

[8] Delone, W., & McLean, E. “The DeLone and McLean Model

of Information Systems Success: A Ten-Year Update,”

Journal of Management Information Systems, 19(4), 2003,

9-30.

[10] Fuchs, G. “The Vital BI Maintenance Process”, in Business

Intelligence Implementation: Issues and Perspectives,” In

B. Sujatha (Ed), ICFAI University Press, Hyderabad, 2006,

116-123.

[11] Gartner Research, “Gartner EXP Worldwide Survey of

1,500 CIOs Shows 85 Percent of CIOs Expect ‘Significant

Change’ Over Next Three Years,” 2008. Retrieved 21 Feb

2009, from http://www.gartner.com/it/page.jsp?id=587309

[12] Gartner Research, “Gartner EXP Worldwide Survey of

More than 1,500 CIOs Shows IT Spending to Be Flat in

2009”, 2009. Retrieved 21 Feb 2009, from http://www.

gartner.com/it/page.jsp?id=855612

[13] Hwang, M. & Xu, H. “A Structural Model of Data

Warehousing Success,” Journal of Computer Information

Systems, Fall 2008, 48-56

[19] Moss, L. & Atre, S. Business Intelligence Roadmap: The

Complete Lifecycle for Decision-Support Applications.

Addison-Wesley, Boston, MA. 2003.

[21] Olszak, C & Ziemba, E. “Approach to Building and

Implementing Business Intelligence Systems,” Interdisciplinary

Journal of Information, Knowledge, and Management,

2, 2007, 135-148.

[22] Reinschmidt, J. & Francoise, A. Business Intelligence

Certification Guide, IBM International Technical Support

Organization, San Jose, CA, 2000.

[25] Turban, E., Sharda, R., Aronson, J. & King, D. Business

Intelligence, Prentice Hall, New Jersey, 2007.

[27] Wang, H. & Wang S. “A Knowledge Management Approach

to Data Mining Process for Business Intelligence,” Industrial

Management & Data Systems, 108(5), 2008, 622-634.

[28] Watson, H., Abraham, D., Chen, D. “Data Warehousing

ROI: Justifying and Assessing a Data Warehouse,” Business

Intelligence Journal, 2004, 6-17.

[30] Watson, H., Annino, D. A., Wixom, B. H. “Current Practices

in Data Warehousing,” Journal of Information Systems

Management, 18(1), 2001, 1-9.

برقراری ارتباط کلیک ویو با Cube

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


استفاده از تمامی Factها و Dimensionها در کلیک ویو نیازمند عبارات MDX پیشرفته و پیچیده‌ است، به همین دلیل پیشنهاد می‌شود در صورت امکان، ارتباط کلیک ویو با انبار داده را به صورت مستقیم برقرار نمایید.


در این آموزش فرض بر آماده بودن یک مدل OLAP برروی سیستم شما است.


توجه: از آنجایی که در این آموزش از پایگاه داده‌ AdventureWorksDW2008 استفاده شده است، باید آن را به بانک اطلاعاتی خود اضافه نمایید. پیشتر نحوه استفاده از AdventureWorksDW2008 در اینجا شرح داده‌ شده است.


به منظور انجام این کار مراحل زیر را دنبال کنید.


1- ابتدا باید یک پروژه‌ی OLAP ایجاد و سپس آن را Deploy و پردازش کرد تا بانک اطلاعاتی آن در Analysis Services قرار گیرد.

  

برای این کار می‌توانید از Adventure Works Sample نیز استفاده نمایید.


2- به صفحه‌ی Edit Script در qlikview رفته و از قطعه کد زیر جهت برقراری ارتباط با Analysis Services استفاده نمایید.


OLEDB CONNECT TO [Provider=MSOLAP.5;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=نام بانک اطلاعاتی;Data Source=نام سرور];


 

قطعه کد بالا ارتباط Cube با qlikview را برقرار می‌کند.

 

 

3- برای خواندن جداول ابعاد و حقایق باید از عبارات MDX استفاده شود. برای مثال عبارت MDX زیر معیار Internet Sales Amount و اطلاعات جداول Ship Date و Product را به QlikView اضافه می‌کند.


SELECT NON EMPTY {[Measures].[Internet Sales Amount] } ON COLUMNS, NON EMPTY

{ ([Ship Date].[Date].[Date].members* [Product].[Category].[Category].members)}

 DIMENSION PROPERTIES MEMBER_CAPTION, MEMBER_UNIQUE_NAME ON ROWS FROM [Adventure Works]

  CELL PROPERTIES VALUE, BACK_COLOR, FORE_COLOR, FORMATTED_VALUE, FORMAT_STRING, FONT_NAME, FONT_SIZE, FONT_FLAGS


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




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



کاربرد Unary Operator در OLAP

می‌توان گفتUnary Operatorاز برای تحلیل‌ بهتر گزارشات مالی استفاده می‌شود. برای درک بهتر این موضوع به مثال زیر توجه کنید.

فرض کنید در یک Cube مالی نیاز به محاسبه ترازنامه (صورتی که وضع مالی یک موسسه را در یک تاریخ معین نشان می دهد) دارید، اگر در SSAS به صورت معمول بعد حساب (Account Dimension) را تعریف و ارتباط آن را با Cube مورد نظر برقرار کنید نتیجه‌ی بدست آمده در خروجی مطلوب نمی‌باشد، چراکه در ترازنامه باید بدهیها ودارایی‌ها با هم برابر باشند و در نهایت تفاضل آن‌ها صفر شود. در حالیکه در OLAP به صورت پیش فرض از مقادیر Sum گرفته می‌شود و در نتیجه مقدار بدهی و دارایی با هم جمع می‌شوند. تصویر زیر خروجی یک Cube مالی را نشان می‌دهد که در آن بُعد حساب‌ها به صورت عادی و بدون تغییر تعریف شده است.



این مشکل با ایجاد تغییرات اندکی در ساختار جدول ایجاد شده در انباره داده و کمک Unary Operator قابل حل است. برای حل این مسئله مراحل زیر را انجام دهید.


۱-   ابتدا به انبار داده مورد نظر رفته و به جدول حساب‌ها یک ستون با نام Operator اضافه کنید.

۲-   بر اساس نیاز ستون Operator را با علائم ((+ و – و...)) پر کنید.

لازم به ذکر است که این کار باید به طور دقیق و با کمک کارشناس حسابداری انجام گیرد.




۳- دایمنشن حساب‌ها را مطابق معمول به Cube اضافه کنید.

حال باید تنظیمات مربوط به Unary Operator را انجام دهید.


۴- بر روی دایمنشن ساخته شده راست کلیک کرده و از منوی باز شده گزینه‌ی Add Business Intelligence را انتخاب نمایید. برروی Next کلیک کنید.

۵- در صفحه‌ی Choose Enhancement گزینه‌ی Specify a unary operator را انتخاب و Next کنید.

۶- مطابق شکل زیر در صفحه‌ی Specify a unary operator ستون Operator را که پیشتر به جدول اضافه کردیم را انتخاب کرده و برروی Next کلیک کنید.

 ۷- برروی Finish کلیک کنید.

۸- پروژه را مجدد پردازش کنید.

در صورتی که عملگر‌های موجود در بعد حساب به درستی تعریف شده باشند و مقادیر موجود در جدول حقایق درست باشند، مقدار کل(Total) برابر صفر خواهد بود.


OLAP به زبان ساده

OLAP  مجموعه‌ای از مکعب‌ها (Cubes) است. داخل این مکعب‌ها داده‌هایی قرار دارند که از پیش انتخاب شده‌اند. ارتباطات بین ابعاد از قبل تعریف شده و همه ابعاد (نتایج) از قبل محاسبه و پیش‌بینی شده است. هنگامی که یک مکعب ایجاد می‌شود، یک واسط کاربر نهایی که می‌تواند یک داشبورد باشد برای یک فرد واقعی پیاده‌سازی می‌شود که کاربر نهایی(مدیران و تصمیم گیرندگان سازمان) بتواند با جواب‌های داخل مکعب تعامل داشته باشد.

اما فرض کنید در یک مکعب برای تحلیل فروش در یک سازمان مقدار و مبلغ فروش را بر اساس ابعادِ مناطق فروش، فروشنده (بازاریاب)، مشتری و ماه یا سال داشته باشیم. زمانی که این مکعب فرضی ساخته می‌شود، نرم‌افزار مبتنی بر OLAP کلیه ترکیبات عناصر داده‌ها را محاسبه و ذخیره می‌کند، کاربر نهایی به این داده‌ها از طریق داشبوردها و یا یک سری فرم‌ها مثلا Pivot Table  ها یا انواع دیگر فرم‌ها دسترسی خواهد داشت.

در این مثال فرضی کاربر نهایی محدود به تحلیل در محدوده ابعاد از قبل تعریف شده مثل مناطق، نمایندگی‌ها، مشتری‌ها و ماه است. اگر کاربر بخواهد درباره فروش هفتگی، روزهای هفته یا محصولات فروخته شده (و یا صدها ترکیب دیگر از داده‌ها) اطلاعاتی کسب کند دیگر شانسی برای بدست آوردن آن ندارد، باید صبر کند که مکعب دیگری از اطلاعات مورد نیاز او ایجاد شود که این یعنی محدودسازی و کاهش بهره‌وری و اثربخشی برای تصمیم‌گیران آن سازمان. به عبارت دیگر کاربر نهایی باید نیازهای خود را از پیش شناخته و برای این نیازها Cubeها، جداول حقایق (Fact) و ابعاد (Dimension) مورد نیاز را پیاده سازی کند تا با کنار هم قرار دادن گزارشات مختلف تا حدودی به دانش استخراج شده و مورد نیاز خود دست پیدا کند.OLAP  برخی از قابلیت‌های تحلیل را فراهم می‌کند، اما تقریبا می‌توان گفت در کشورهای  پیشرفته یک رویکرد قدیمی است و متاسفانه در کشور ما همچنان ناشناخته! یا کمتر شناخته شده است. در حال حاضر انواع مختلف OLAPوجود دارد، مثل MultiDimensiona OLAP (MOLAP) که به آن MMD نیز گفته می‌شود و Relational OLAP (ROLAP)  یاRDBMS  و سیستم های OLAP از نوع

HOLAP.

در پست جداگانه به تشریح انواع OLAP و مقایسه آن‌ها می‌پردازم.

MOLAP، ROLAP و HOLAP

در یک پروژه‌ی OLAP از یک یا چند مکعب داده‌ (Cube) استفاده می‌شود. از اینرو Cube به عنوان یکی از مزایای پروژه هوش تجاری شناخته می‌شود. قرار گرفتن داده‌ها در یک فرمت بهینه جهت ذخیره‌سازی به انجام سریع‌تر کوئری‌ها می‌انجامد. معمولا نحوه ذخیره‌سازی اطلاعات حجیم در Cube باعث تاخیر در ذخیره و بازیابی انبوه اطلاعات می‌شود. به طور معمول در SSAS پردازش داده‌ها از یک بانک اطلاعاتی رابطه‌ای به Cube منتقل می‌شود. پس از اتمام این ارتباط نه چندان طولانی میان پایگاه داده‌های رابطه‌ای و Cube اطلاعات وارد Cube می‌شوند و با تغییر داده‌ها در پایگاه داده هیچ تغییری در اطلاعات موجود در Cube ایجاد نمی‌شود مگر آنکه Cube را مجدد پردازش کنید.

در SSAS2008 سه نوع ذخیره‌سازی وجود دارد؛ MOLAP، ROLAP و HOLAP

در این پست هر یک از انواع ذخیره‌سازی را به صورت خلاصه شرح داده و در پایان با یکدیگر مقایسه می‌کنم. 

MOLAP(Multidimensional Online Analytical Processing) 

این نوع ذخیره‌سازی بیشترین کاربرد در ذخیره اطلاعات را دارد همچنین به صورت پیش فرض جهت ذخیره‌سازی اطلاعات انتخاب شده است. در این نوع تنها زمانی داده‌های منتقل شده به Cube به روز می‌شوند که Cube پردازش شود که این امر باعث تاخیر بالا در پردازش و انتقال داده‌ها می‌شود.    

ROLAP (Relational Online Analytical Processing) 

 در ذخیره‌سازی ROLAP زمان انتقال بالا نیست که از مزایای این نوع ذخیره‌سازی نسبت به MOLAP است. در ROLAP اطلاعات و پیش‌محاسبه‌ها (Aggregations) در یک حالت رابطه‌ای ذخیره می‌شوند و این به معنای زمان انتقال نزدیک به صفر میان  منبع داده (بانک اطلاعاتی رابطه‌ای) و Cube می‌باشد. از معایب این روش می‌توان به کارایی پایین آن اشاره کرد زیرا زمان پاسخ برای پرس‌و‌جوهای اجرا شده توسط کاربران طولانی است. دلیل این کارایی پایین بکار نبردن تکنیک‌های ذخیره‌سازی چند بعدی است.  

HOLAP (Hybrid Online Analytical Processing)  

این نوع ذخیره‌سازی چیزی مابین دو حالت قبلی است. ذخیره اطلاعات با روش ROLAP انجام می‌شود، بنابراین زمان انتقال تقزیبا صفر است. از طرفی برای بالابردن کارایی، پیش‌محاسبه‌ها به صورت MOLAP انجام می‌گیرد در این حالت SSAS آماده است تا تغییری در اطلاعات مبداء رخ دهد و زمانی که تغییرات را ثبت کرد نوبت به پردازش مجدد پیش‌محاسبه‌ها می‌شود. با این نوع ذخیره‌سازی زمان انتقال داده‌ها به Cube را نزدیک به صفر و زمان پاسخ برای اجرای کوئری‌های کاربر را زمانی بین نوع ROLAP و MOLAP می‌رسانیم.

  

مقایسه  انواع ذخیره سازی در جدول زیر نمایش داده شده است. 

 

مدت زمان انتقال داده

سرعت اجرای کوئری

محل ذخیره‌سازی پیش‌محاسبات

محل ذخیره‌سازی داده‌ها

بالا

بالا

Cube

Cube

MOLAP

پایین

متوسط

Cube

بانک اطلاعاتی رابطه‌ای

HOLAP

پایین

پایین

بانک اطلاعاتی رابطه‌ای

بانک اطلاعاتی رابطه‌ای

ROLAP

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