جديدترين مقالات مرتبط با مدیریت فناوری اطلاعات IT
ارسال شده توسط احمد محمدی | 30 11, 2013 | بازدید‌ها (1224)

مروري بر RUP و قابليت‌هاي آن در توليد نرم‌افزار

چكيده

چه چيز مي‌تواند يك پروسه توليد نرم‌افزار را توصيف كند؟ آيا منظور از پروسه، آماده‌سازي نرم‌افزار صرفاً براي ارائه در بازار است؟ مسلماً در هر كاري وجود يك سامانه و فرايند كاري ضروري است؛ ولي چه چيزي مي‌تواند موجب ايجاد سرعت و كيفيت در فرايند توليد يك نرم‌افزارشود؟ لزوماً طراحي و پياده‌سازي يك فرايند يكپارچه و منطقي مي‌تواند چنين نتيجه‌اي در بر داشته باشد. بدين منظور امروزه از روشي استفاده مي‌شود كه اصطلاحاً RUP ناميده مي‌شود. به حداقل رساندن حجم پروسه توليد يك نرم‌افزار همزمان با حفظ كيفيت و صرفه‌جويي در زمان از مهمترين ويژگي‌هاي اين روش مي‌باشند. معمولاً براي يك شركت توليد نرم‌افزار، سرعت عمل به موقع براي پاسخ‌گويي به تقاضا و شرايط اجتماعي اهميت دارد، اما گاهي اين شتابزدگي سبب فدا شدن كيفيت مي‌گردد. RUP با ارائه يك چارچوب منطقي علاوه بر تعيين زمانبندي مناسب، كيفيت مورد نظر توليد كننده و استفاده كننده نرم‌افزار را تأمين مي‌نمايد. در اين مقاله ضمن مروري بر RUP به عنوان روش يكپارچه توليد نرم‌افزار، قابليت‌هاي آن در افزايش سرعت توليد نرم‌افزار و حفظ كيفيت آن برشمرده مي‌شوند.

كليدواژه : RUP؛ UML؛ فرايند يكپارچه رشنال؛ Rational Unified Process؛ Unified Modeling Language

1- مقدمه

يك پروسه چابك، پروسه‌اي است كه هميشه آماده در آغوش كشيدن درخواستهاي جامعه بوده و  اين درجه از سازگاري را دارا باشد. بنابراين منظور از سرعت عمل، فقط كاستن از حجم پروسه توليد نرم‌افزار يا سرعت ارائه آن به بازار نيست؛ بلكه منظور، انعطاف‌پذيري و حفظ کيفيت است. مطلبي كه در اين مقاله قصد توضيح آن را داريم اين است كه RUP 1 ساختاري پروسه‌اي (چيو 2000) است كه امكان انعطاف‌پذيري را براي توليد‌كنندگان نرم‌افزار فراهم مي‌آورد.

منظور از RUP  چيست؟ در اين مقاله از چند منظر به RUP خواهيم پرداخت:

  • RUP يك پروسه توليد نرم‌افزار است.
  • RUP مجموعه‌اي از تجربيات بسيار عالي توليد نرم‌افزار را كه در عمل با آنها برخورد شده است، در خود دارد.
  • RUP همانند يك محصول نرم‌افزاري به بازار ارائه شده و به فروش مي‌رسد با اين تفاوت كه RUP اولين ساختار توليد نرم‌افزار را ارائه داده و گام نخست را در اين زمينه برداشته است.

2- RUP چيست؟

با پيشرفت تكنولوژي‌هاي مرتبط با كامپيوتر، نياز هر چه بيشتر به گسترش علم نرم‌افزاري نيز احساس مي‌شد كه با پيدايش متدولوژيهاي همانند SSADM 2  و روش آبشاري3 (چيو 2000) ‎آغاز شد. در ابتدا، اين روشها مناسب بود و جوابگوي نيازهاي آن زمان بودند ولي با افزايش داده‌ها و پيدايش مفاهيمي همچون شبكه، وب و غيره ديگر كارآيي لازم را جهت پياده‌سازي و هدايت پروژه‌هاي نرم‌افزاري نداشتند. پس مفاهيم برنامه‌نويسي شيءگرا پا به عرصه وجود گذاشتند و در سال 1991 بطور جدي مورد مطالعه و بحث قرار گرفتند. استفاده از اين روشها و متدهاي برنامه‌نويسي، قدرت و انعطاف بسياري را به برنامه‌ها داد و شركتهاي نرم‌افزاري توانستند با كاهش هزينه‌ها و بهينه‌سازي كدهاي خود، نرم‌افزارهاي قويتري را به بازار عرضه كنند ولي اين روش جديد نيز نياز به مديريت و يكپارچگي داشت. پس روشها و متدولوژيهاي جديدي مطرح شد كه شامل Booch، OMT، OSE و ... مي‌باشند. در سال 2000 شركت Rational روشي را تحت عنوان RUP  مطرح ساخت (گروه كاسميك 2003ب) كه بعد از روش MSF شركت مايكروسافت به دنياي نرم‌افزار عرضه شد و امروزه از طرفداران بسياري برخوردار است. فرايند يكپارچه Rational در اصل يك متدولوژي است كه در جهت كنترل و انجام پروژه‌هاي نرم‌افزاري در نظر گرفته شده است. در اصل اين چارچوبي در جهت انجام صحيح و موفق پروژه‌هاي نرم‌افزاري مي‌باشد كه كليه مراحل انجام يك پروژه كه با معماري و آناليز سازمان شروع شده و به تست نرم‌افزار و ارائه Gold Release ختم مي‌شود را در بر مي‌گيرد (گروه كاسميك 2003 الف).

چرا RUP را يک فرايند يکپارچه مي‌گويند؟  به سه علت RUP را يكپارچه مي‌نامند:

  • اين متدولوژي از يكپارچه‌سازي سه متدولوژي معروف ديگر بوجود آمده است كه شامل Booch، OMT و OSE مي‌باشد.
  • از UML4 در جهت كارهاي خود استفاده مي‌كند. در واقع مي‌توان گفت UML خود ثمره RUP  مي‌باشد و اين خود بسيار خوب است كه متدولوژيي با خودش گسترش يابد (گروه كاسميك 2003الف). مفاهيمي از قبيل Object، Class و ... مفاهيم ساده و ثابتي هستند ولي قبلاً متدولوژيها علامتهاي خاصي داشتند كه اكنون همه آنها يكسان شده‌اند.
  • در داخل RUP يك چارچوب توليد نرم‌افزار است كه ما آنرا براي سازمان و پروژه خود بومي مي‌كنيم و مي‌توان گفت كه در واقع يك قالب فرايند5 است.

 

 مروري بر RUP و قابليت‌هاي آن در توليد نرم‌افزار

شكل 1 ساختار اصلي RUP را مشخص مي‌كند. اگر در بعد زمان به آن نگاه كنيم شامل 4 فاز مي‌باشد و اگر در هر لحظه به آن نگاه كنيم شامل 9 قالب خواهد بود.

 
شكل 1 - ساختار اصلي RUP
شکل 1. ساختار اصلي RUP

3- خصوصيات RUP چيست؟

  • RUP مبتني بر نوعي معماري است كه به اجزاء اصلي مي‌پردازد ولي طراحي به جزئيات نيز وارد مي‌شود. همچنين مي‌توان گفت معماري يكسري اجزا و ارتباط بين آنها است كه سيستم را مي‌سازد و ما را به سمت توسعه مؤلفه‌محور6 راهنمايي مي‌كند.
  • ويژگي Usecase Driven:  يكي از مشكلات OOA اين بود كه مي‌گفتند با هر روشي تبديل و كار كنند و بعد بتوان آنرا به شيءگرا تبديل كرد. يعني مثلاً پروژه SSADM را طراحي كرده و بعداً به شيءگرا تبديل نمود. ولي آن عقيده اشتباه بود و حتماً تحليل شيءگرا بايد صورت بگيرد. خصوصيت خوب شيءگرا كه در ديگر روشها نمي‌باشد اين است كه نوتاسيوني كه استفاده مي‌شود (بوچ، رامباق و جاكوبسون 1999) در همه مراحل يكي است يعني مفاهيمي از قبيل شيء، كلاس، روابط كلاسها و ... در تمامي مراحل يكي است. اهميتي كه Usecase Driven دارد اين است كه با زبان مشتري نوشته مي‌شود. مشتري مي‌تواند آنرا بفهمد و بسيار مناسب براي تشخيص نيازمنديهاي سيستم مي‌باشد. در بخش تحليل و طراحي از روي Usecaseها تحليل و طراحي انجام مي‌دهيم و مسائلي مانند مديريت پروژه نيز تحت تاثير Usecaseها هستند كه ما آنها را دسته‌بندي كرده و مديريت مي‌كنيم. همچنين راهنماهاي سيستم هم تحت تاثير Usecaseها (كراچتن 2000، 298) ايجاد مي‌شوند.
  • ويژگي Incremental: به معني آن است که پروژه بصورت چهار مرحله حلقه‌اي جلو مي‌رود ولي در هر مرحله چرخش يك دسته از Usecaseها كامل و آماده استفاده مي‌شود و كليه اين كارها در 9 جريان كار7 كه در شكل 1 مشخص شده بود، قابل مشاهده است.

4- ديدگاه اوليه درباره RUP

ديدگاهي كه RUP بر اساس آن طراحي شده، به گونه‌اي است كه محدوده وسيعي از اهداف را پوشش دهد تا ضمانت اجرايي جهت انطباق با موارد زير حاصل شود (كراچتن 2003):

  • ابعاد پروژه
  • حوزه كاربردي برنامه (سيستمهاي تجاري يا سيستمهاي فني)
  • زمينه‌هاي تجارت (توسعه خانگي، توسعه محصولات، فروشندگان نرم‌افزار مستقل، توسعه قراردادي).

 همانند هر ساختار پروسه‌ ديگري، RUP نيز روش سيستماتيكي را براي به دست آوردن، سازماندهي و ارائه راهكارهاي مهندسي نرم‌افزار در اختيارتان قرار مي‌دهد. RUP براي سازماندهي راهكارها، بر يك مدل پروسه‌ ساده و کاملاً زيربنايي استوار شده است كه توضيح اين امر در قالب چند مقاله يا كتاب نمي‌گنجد.

با اين وجود، ساختار پروسه مزبور را نمي‌توان به يك ظرف خالي تشبيه نمود. اين ساختار از قبل توسط حجم عظيمي از پروسه‌هاي راهكاري كه قبلاً در پانزده سال گذشته توسط مليت‌هاي مختلف تحصيل شده است و با شركت Rational ارتباط داشته‌‌اند (افرادي كه قبلاً اين شركت آنها را به خود جذب كرده و برخي از شركاي اين شركت نظير IBM ، HP و BEA (كراچتن 2003)) انباشته گرديده‌ است. RUP مجموعه محدود و بسته‌اي نيست كه به منظور كاربردهاي عمومي منتشر شده باشد و پاسخ يا راه‌حل تمامي مشكلات توسعه نرم‌افزاري را دربرگيرد؛ بلكه ساختار RUP ساختار بازي است كه به منظور استنتاج بايد شاخه‌هاي آنرا دنبال كنيد و اين ساختار سالانه دوبار روزآمد مي‌گردد. ساختار RUP تصفيه شده است و پشتيباني ابزاري و مندرجات آن نيز توسعه يافته‌اند.

از يك سو، گروه توسعه پروسه شركت Rational، امر به روز سازي محتويات RUP را همگام با مقتضيات فن‌آوري و بازخوردهايي كه كاربران اين ساختار ارائه مي‌دهند، به عهده دارند و از سوي ديگر شركاي متعدد اين شركت و افرادي كه RUP را براي استحصال و سازماندهي فرايندهاي راهكاري خود پذيرفته‌اند و از آن براي اهداف مربوط به خود استفاده مي‌كنند، ساختار ارائه شده توسط شركت Rational را تبليغ نموده و آنرا را تكميل مي‌كنند.

ساختار RUP پيرامون چند منطق ساده و مرتبط به هم سازمان‌دهي شده است:

  • RUP نقشهايي را تعريف مي‌كند كه بايد در پروسه وجود داشته باشد و بر مبناي آن، صلاحيتها، تخصصها و مسئوليتهاي افرادي كه بايد پيشرفت پروژه را محقق سازند، مشخص مي‌شود.
  • RUP كارهايي را كه هر يك از افراد بايد در عمل انجام دهند، به طور گام به گام تشريح مي‌كند.
  • اين عمليات با استفاده از ابزارهايي واقعي مانند مدل‌ها، كدها، اسناد و گزارشها اداره مي‌شوند.
  • در RUP به وفور با راهنماييهاي مربوط به نقش‌هايي كه افراد بايد به عهده بگيرند، فعاليتهايي كه بايد انجام شوند و مصنوعات مورد نياز برخورد خواهيد نمود كه در قالب خطوط راهنما، الگوها، مثالها و معلمهاي ابزاري ارائه مي‌شوند كه چگونگي به وقوع پيوستن دسته‌اي از فعاليتها توسط يك ابزار بخصوص را شرح مي‌دهند.
  • تمامي اين المانهاي توصيف پروسه در قالب سامانه‌هايي سازماندهي شده‌اند.

 

RUP مقدماتي نه سامانه، بيش از چهل نقش و صد محصول را تعريف مي‌كند و حاوي بيش از هزار صفحه راهنما است. همچنين مي‌توانيد به پروسه‌هاي الحاقي متعددي كه وظايف و مندرجات بيشتري را به RUP اضافه مي‌كند، دسترسي پيدا كنيد. برخي از منتقدين RUP آنرا پروسه‌اي بسيار سنگين تصور نموده و آنرا به كرگدني تشبيه مي‌كنند كه توان انجام تعداد نامحدودي عمل غير معمول را براي شما فراهم مي‌آورد؛ با اين وجود نگاه ما به RUP همانند لوح باشكوهي از معارف است كه مي‌توانيد آنچه را كه نياز داريد، از داخل آن برگزينيد.

 اجازه بدهيد مقايسه‌اي انجام دهيم. اگر فرهنگ لغات مناسبي از 800 لغت را انتخاب كرده باشيد، مي‌توانيد در خيلي از نقاط دنيا و در بسياري شرايط، گليم خود را از آب بيرون بكشيد؛ ولي با انتخاب فرهنگ لغات حجيمي چون Webster ، اولاً هيچ‌كس شما را مجبور به استفاده از لغاتي كه در فرهنگ لغات وجود دارد نمي‌كند، ثانياً مي‌توانيد سطح لغات محفوظي خود را براي انطباق با وضعيتهاي مختلف ارتقا ببخشيد و ثالثاً مي‌توانيد فرهنگ لغات خود را بهبود دهيد. فرهنگ لغت800 لغتي بايد فقط زيرمجموعه‌اي از يك فرهنگ لغات باشد.

5- انعطاف‌پذيري RUP و انطباق با آن

RUP يك اصل عقيدتي يا يك آيين مذهبي نيست. ساختار RUP ساختار خشكي نيست كه بخواهد همه چيز را براي توليد نرم‌افزار در قالب خود درآورد. نيازي نيست كه حداقل چهل نفر را براي تكميل پروسه‌اي كه چهل نقش در آن تعريف شده است، به خدمت بگيريد و نيازي نداريد كه بيش از صد محصول مختلف را پرورش دهيد. اگر سعي خود را به انجام اين كار معطوف سازيد، خيلي زود در معرض آشفتگي قرار خواهيد گرفت. اين المانها در RUP و در فرم الكترونيكي (كراچتن 2003) براي فراهم‌آوردن انعطاف‌پذيري مورد نياز براي انطباق با تقاضايي ارائه شده‌اند كه به شرايط محيطي كه درآن به سر مي‌بريد، بستگي دارد.

RUP تمرينات توليد نرم‌افزار ثابت شده فراواني را در بردارد. شركت Rational ميدان ديد بالايي را براي موارد زير، ارائه مي‌دهد:

  • توسعه مكرر
  • مدل‌سازي بصري
  • مديريت ملزومات تغييرات كنترل
  • بازبيني مداوم كيفيت
  • استفاده از معماري بر مبناي اجزا

 

همچنين URP بر مبناي ديگر اصول كليدي ديگري كه كمتر قابل مشاهده هستند و ساده‌تر به محاق فراموشي سپرده مي‌شوند،  استوار شده است كه فقط براي يادآوري اشاره‌اي به آنها مي‌نماييم (جنر 2002):

  • منحصراً آنچه را كه مورد نياز است، پرورش دهيد.
  • روي نتايج ارزشمند تمركز كنيد، نه روي چگونگي حصول نتايج
  • كاغذبازي را به حداقل برسانيد.
  • انعطاف‌پذير باشيد.
  • از اشتباهات خود عبرت بگيريد.
  • به طور منظم، مخاطرات محتمل را مورد بازبيني قرار دهيد.
  • براي پروسه موردنظر معيارهاي قابل اندازه‌گيري و علمي را بدون موضع‌گيري شخصي استوار كنيد.
  • از گروه‌هاي كوچك و توانمند استفاده كنيد.
  • طرحي را در ذهن داشته باشيد.

 

ذهنيت كليدي در سازگار شدن و سازگار كردن RUP قالب توسعه8 مي‌باشد. يك قالب توسعه نمونه‌اي از RUP است كه براي پروژه ويژه‌‌اي كه مد نظرتان است، مناسب باشد. با مراجعه به ساختار RUP به توضيح پروسه‌اي دست‌ مي‌يابيد كه موارد زير را تعريف نموده و شناسايي مي‌كند (جنر 2002):

  •  چه چيزي توسعه داده خواهد شد؟
  • به چه مصنوعاتي واقعاً نياز داريم؟
  • چه الگوهايي بايد مورد استفاده قرار بگيرند؟
  • كدام مصنوعات در حال حاضر وجود دارند؟
  • به چه نقش‌هايي نياز داريم؟
  • چه فعاليتهايي انجام خواهند شد؟
  • كدام خطوط راهنما، استانداردهاي پروژه و ابزارهايي مورد استفاده قرار خواهند گرفت؟

6- نتيجه گيري

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

مراجع


Booch, G., J. Rumbaugh and I. Jacobson. 1999. The Unified Modeling Language User Guide. Addison- Wesley.

COSMIC Group. 2003a. Valve Control System – Cosmic Group Case Study. École de technologie supérieure, Université du Québec, Montréal, Canada, January 25, 2003 version http://www.lrgl.uqam.ca/cosmic-ffp/casestudies/

COSMIC Group. 2003b. Rice Cooker – Cosmic Group Case Study. École de technologie supérieure, Université du Québec, Montréal, Canada, Janua ry 26, 2003 version http://www.lrgl.uqam.ca/cosmic-ffp/casestudies/

Jenner, M. 2002. Automation of Counting of Functional Size Using COSMIC-FFP in UML. 12th International Workshop on Software Measurement – IWSM 2002, Magdeburg, Germany, Oct. 7-9, 43-51.

Kruchten, P. 2000. The Rational Unified Process, an introduction. Addison Wesley.

Kruchten, P. 2003. The RUP platform. Montréal-SPIN . November, 33.

Schewe, K.D. 2000. UML: A Modern Dinosaur? A Critical Analysis of the Unified Modeling Language. Proc. 10th European-Japanese Conf. on Information Modeling and Knowledge Bases. Saariselk/Finland.

پي‌نوشت‌ها


1. Rational Unified Process

2. Structured System Analysis and Design Method

3. waterfall

4. Unified Modeling Language

5. Process Framework

6. Component Base Development (CBD)

7. workflow

8. Development case

ارسال شده توسط احمد محمدی | 30 11, 2013 | بازدید‌ها (1264)

مقدمه
امروزه با پیشرفت فناوری، سازمان ها به دنبال راه ها و ترفندهایی می گردند که بقایشان را در این عرصه تضمین کنند. سازمان ها می دانند که دیگر بقای آنها تنها در رسیدن به وضعیت سوددهی مداوم نیست و باید به دنبال رقابت و ابزار آن باشند. همچنین می دانند که کلید موفقیت در عصر اطلاعات، اتخاذ تصمیماتی است که بدون تناقض، بهتر و سریع تر در رقابت پیش دستی کند.
یک سازمان در طول حیاتش، داده ایجاد می کند. این داده معمولا پیرامون دارایی، بازاریابی، فروش، منابع انسانی، مدیریت ارتباط با مشتری و ... گروه بندی می شوند و هر بخش یک وظیفه جدا در شرکت انجام داده و داده های مرتبط به خود را جمع آوری می کند. این حقیقت سازمان ها را ملزم به جستجوی ابزارهایی برای تسهیل فرایند کسب اثربخش داده ها، پردازش و تحلیل وسیع آنها کرده است تا براساس آن پایه ای را برای کشف دانش جدید بنا نهند.
برای سالیان متوالی از سیستم های اطلاعات مدیریت موجود مانند:MIS,DSS,ES,EIS  استفاده می شد اما این سیستم ها قادر به ایجاد یکپارچگی میان داده های پراکنده و ناهمگن و شناسایی مناسب وابستگی های موجود میان داده های جدید نبودند. برای اینکه سازمان ها قادر به واکنش سریع در برابر تغییرات بازار باشند، نیاز به سیستم های اطلاعات مدیریتی دارند که بتوانند از سازمان و محیط آن تحلیل های علت و معلولی مختلف انجام دهند.
بنابراین سازمان ها برای حفظ بقا همزمان با پیشرفت فناوری، باید تسلط بر فناوری های جدیدی مانند هوش تجاری را در کسب وکارها یک الزام و ضرورتی اجتناب ناپذیر تلقی کنند. سیستم های هوش تجاری ابزاری را فراهم می کنند که بر اساس آن نیازهای اطلاعاتی سازمان به شکل مناسبی پاسخ داده شود.
تعریف هوش تجاری
تعاریف زیادی برای هوش تجاری وجود دارد، اما به طور کلی هوش تجاری به عنوان یک رویکرد جدید در معماری سازمانی مطرح شده است که این معماری بر اساس سرعت در تحلیل اطلاعات به مدیران جهت اتخاذ تصمیمات دقیق و هوشمند کسب و کار در حداقل زمان ممکن کمک می کند. هوش تجاری یک چارچوب کاری شامل فرایندها، ابزار و فناوری های مختلف است که برای تبدیل داده به اطلاعات و اطلاعات به دانش مورد نیاز هستند، که با استفاده از همین دانش مدیران قادر به تصمیم گیری بهتر می شوند و در نتیجه عملکرد سازمان خود را بهبود می بخشند.
با پياده سازي راهکارهاي هوش تجاري فاصله موجود بين مديران مياني و مديران ارشد از ديدگاه ارتباط اطلاعاتي از ميان خواهد رفت و اطلاعات مورد نياز مديران در هر سطح، در لحظه و با کيفيت بالا در اختيار آنها قرار خواهد گرفت. همچنين کارشناسان و تحليل گران مي توانند با استفاده از امکانات ساده، فعاليتهاي خود را بهبود بخشند و به نتايج بهتري دست پيدا نمايند.
احساس نیاز به وجود یک سیستم هوش تجاری در سازمان برای اولین بار در سطوح بالای مدیریتی احساس می شود و از بالای هرم ساختار سازمانی به بخش های زیرین منتقل می گردد. مهم ترین نیاز یک مدیر، تصمیم گیری است. فرآیند تصمیم گیری می تواند به سه بخش کلی تقسیم شود که عبارتند از:
۱) دسترسی، جمع آوری و پالایش داده ها و اطلاعات مورد نیاز.
۲) پردازش، تحلیل و نتیجه گیری براساس دانش.
۳) اعمال نتیجه و نظارت بر پیامد های اجرای آن.

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

مراحل هوش تجاری

اگر مراحل هوش تجاری را به صورت شکل زیر در نظر بگیریم، منابع داده در مرحله اول جمع آوری می شوند. این منابع می تواند داده های انواع پایگاه داده یا اطلاعات نرم افزارهای موجود را در بر بگیرد.
اطلاعات جمع آوری شده طی فرایند  ETLدر پایگاه داده تحلیلی یا همان انبار داده(Data Warehouse) بارگذاری می شود.
داده در پایگاه داده تحلیلی در بخش های مجزایی به نام داده گاه (Data Mart) قرار می گیرد.
در مرحله بعد هوش تجاری وارد عمل شده و روی اطلاعات طبقه بندی شده تجزیه و تحلیل انجام می دهد.
در نهایت اطلاعات جهت انتشار به ابزارهای سطح بالا تحویل داده می شود.

alt
alt

 

تکنیک های مورد استفاده در هوش تجاری
در عصری که زمان، کلید اصلی در تجارت است، شرکت ها به استفاده از ابزارهای اطلاعاتی روی آورده اند تا بتوانند اطلاعات مورد نظر را به سرعت از منابع استخراج کنند. هوش تجاری در امر تصمیم گیری در سطوح مختلف سازمان به ویژه سطوح مدیران ارشد با تحلیل اطلاعات و روش های پرس و جو تسهیلات زیادی را فراهم می کند که متداول ترین این روش ها به قرار زیر است:
▪ On-Line Analytical Processing (OLAP)
▪ On-Line Transaction Processing (OLTP)
▪ Data Warehousing (DW)
▪ Data Mining (DM)
▪ Intelligent Decision Support System (IDSS)
▪ Intelligent Agent (IA)
▪ Knowledge Management System (KMS)
▪ Supply Chain Management (SCM)
▪ Customer Relationship Management (CRM)
▪ Enterprise Resource Planning (ERP)
▪ Enterprise Information Management (EIM)

لازم به ذکر است، صرف وجود تمام این تکنیک ها در سطح سازمان بدون در نظر داشتن فرهنگ سازمان و رویکرد سیستمی موجود بین کارکنان نمی‌تواند اثبات کننده هوشمندی کسب و کار آن سازمان باشد.

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

ارسال شده توسط احمد محمدی | 30 11, 2013 | بازدید‌ها (1815)

مفهوم هوش تجاري Business Intelligence

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

ابزارهای توسعه هوش تجاری

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

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

استقرار هوش تجاری به دلیل ماهیت متفاوت آن با نرم افزارهای کاربردی، وابستگی ویژه ای به ابزارهای توسعه دارد. چراکه :
- در سیستمهای عملیاتی فرآیندهای جاری سازمان به صورت مکانیزه انجام میگیرد و طول زمانی پروژه معمولا در حد سال میباشد ، ولی پروژه های هوش تجاری به دلیل اینکه به روند تصمیم گیری در سازمان کمک میکنند، سرعت توسعه آنها اهمیت ویژه ای دارد و توسعه آنها افزایشی (Incremental) و در بازه های زمانی 3 یا 4 ماهه صورت میگیرد.
- واسط کاربر (User Interface) در سیستمهای عملیاتی فرمهایی است که طراحی آنها پیچیده نیست ولی در پروژه های هوش تجاری خروجی اصلی، گزارشات و داشبوردهایی است که داده ها را ساماندهی و تحلیل میکند، به همین دلیل طراحی اینگونه داشبوردها به سادگی امکان پذیر نیست و استفاده از ابزار در طراحی واسط کاربر روند توسعه سیستم را سرعت و کیفیت زیادی میبخشد.

ابزارهای موجود در هوش تجاری به دو گروه تقسیم بندی میشوند :
- ابزارهایی که در پشت صحنه (Back End) به کمک تیم پروژه می آیند و در طراحی انبار داده و انجام فرآیند ETL(Extract, Transform, Lod) نقش خود را ایفا میکنند .
- ابزارهای که در روی صحنه (Front End) هستند و جهت طراحی گزارشات و داشبوردها امکانات خود را ارائه میدهند . این بخش را واسط کاربر (User Interface) نیز میگویند.

ارتباط بین Front End and Back End

ارتباط ایندو ابزار بدین صورت است که واسط کاربر مدل داده ای و جداول داده های تولید شده توسط ابزار Back End را دریافت میکند و کاربر میتواند توسط امکانات طراحی موجود در آن گزارشات و داشبوردهای مورد نظر خود را ایجاد کند.

نکات مهم در انتخاب ابزار هوش تجاري

فروشنده های (Vendor) مختلفی وجود دارند که برخی صرفا ابزارهای یک گروه و برخی هردو گروه را ارائه میدهند . نکته مهمی که سازمانها میبایستی به آن توجه کنند اینست که نحوه تعامل ایندو گروه ابزار با یکدیگر مسئله بسیار مهمی است. واسط کاربر میبایستی بتواند مدل داده ای طراحی شده در Back End را شناسائی کند تا نیاز نباشد طراحی مجدد در این قسمت انجام شود. این مسئله نیازمند تسلط تیم انتخاب کننده ابزار به مفاهیم مدل داده ای (Data Modeling) در هوش تجاری و انبار داده است که میتوانید جهت آشنائی با آن به بخش آموزش انبار داده سایت پارس مدیر مراجعه نمائيد. معماری ابزارهای توسعه هوش تجاری نکته مهم دیگری است که هنگام انتخاب میبایستی به آن توجه ویژه ای گردد.

شرکتهای مطرح ارائه دهنده ابزارهای هوش تجاری

شركت هاي Microsoft ، oracle ، SAP ، IBM جزء شرکتهای مطرح ارائه دهنده راه حل (Solution) و ابزارهای هوش تجاری میباشند. طبق دسته بندی گروه گارتنر (Gartner Group) در February 2013 پلتفرمهای توسعه هوش تجاری به شکل زیر طبقه بندی میشوند :

شركت هاي هوش تجاري

ارسال شده توسط احمد محمدی | 30 11, 2013 | بازدید‌ها (1142)

پنج کليد موفقيت هوش تجاری
هوش تجاري در حال گسترش است. به همان نسبت که تقاضا براي پياده‌سازي هوش تجاري در سازمان‌ها و کسب و کارهاي گوناگون رشد مي‌کند، مفاهيم و سيستم‌هاي هوش تجاري توسعه مي‌يابند.
اما سوال اين است که آيا صرف وجود ابزارهاي قوي و متنوع مي‌تواند موفقيت يک سازمان را در دست‌يابي به هوش تجاري تضمين نمايد؟ در اين مقاله با نگاهي دوباره به تعاريف هوش تجاري از نگاه متخصصين، پنج راهکار و نکته را براي موفقيت در دست‌يابي به هوش تجاري ذکر مي‌کنيم.
نگاهي به تعاريف هوش تجاري:
 
1. کتاب «هوش تجاري: داده کاوي و بهينه‌سازي براي تصميم‌گيري» :
شايد بتوان هوش تجاري را اين گونه تعريف کرد: يک مجموعه از مدل‌هاي رياضي و روش‌هاي تحليلي که با بهره برداري از داده‌هاي موجود، اطلاعات و دانش مفيد براي فرآيندهاي پيچيده‌ي تصميم‌گيري، توليد مي‌کنند.
2. کتاب «هوش تجاري در مایکروسافت SharePoint 2010» :
بر اساس نظر استفان کاوي در کتاب هفت خصلت مردمان مؤثر، هواپيمايي که از بوستون به مقصد لس‌آنجلس به پرواز در مي‌آيد، با اين‌که در 90 درصد مواقع از مسير پرواز خارج مي‌شود، در نهايت در لس‌آنجلس به زمين مي‌نشيند و اين به لطف سيستم پرواز است، که با نظارت بر پرواز و ارائه فيدبک مناسب مسير درست را نشان مي‌دهد.
همانند يک پرواز اگر سازمان به درستي هدايت نشود، در 90 درصد مواقع از مسير خود منحرف مي‌گردد.. بيشتر سازمان‌ها يک هدف يا مقصد دارند و براي درک وضعيت خود از وسايل و يا ابزارهاي اندازه‌گيري بهره مي‌برند، تا گذشته و حال خود را نظارت و تحليل نمايند و آينده را پيش‌بيني کنند.
اين ابزارها بينش اطلاعاتي لازم را که مدير براي ايجاد تغيير و يا اصلاح مسير نياز دارد در اختيارش قرار مي‌دهند. اين بينش در شکل گزارش‌ها، کارت‌هاي امتيازي، شاخص‌هاي کليدي عملکرد، داشبوردها و ساير ابزارهاي اطلاعاتي در اختيار مدير قرار مي‌گيرد. اين ابزارها به يک سازمان کمک مي‌کنند تا رابطه بين کسب و کارشان و استراتژي‌ها و اولويت‌هاي مهم خود را ببينند.
تصميم‌گيرندگان دوست دارند تا از تجربه بصري داشبوردها استفاده کنند تا احساس کنند که راننده سازمان خود به سمت مقصدش هستند. خوشبختانه هواپيماها در رسيدن به مقصد، از سازمان‌ها موفق‌ترند. اين موفقيت مديون ابزارهاي اندازه‌گيري دقيق و علمي آن ‌هاست. در طول ساليان دراز، وضعيت هوايي و ساير متغيرهايي که پرواز را تحت تأثير مستقيم قرار مي‌دهند و در ابتدا غير قابل سنجش تصور مي‌شدند، به صورت فزآينده‌اي قابل اندازه‌گيري شده‌اند. ابزارهاي جديدِ هواپيما به خلبانان مختصات دقيق مکاني را مي‌دهند
اکنون براي کسب و کارها نيزشرايط يکساني رخ داده است، داگلاس هابارد در کتاب خود با عنوان «چگونه همه چيز را اندازه بگيريم» ليستي از مواردي را که قبلا غير قابل اندازه‌گيري تصور مي‌شد ولي اکنون قابل اندازه‌گيري است ذکر مي‌کند، مانند:
  1. انعطاف برای ایجاد محصولات جدید
  2. اثربخشی مدیریت
  3. بهره‌وری تحقیقات
  4. خطر ورشکستگی
  5. کیفیت
4. کتاب «ارائه هوش تجاري» :
هوش تجاري، تحويل اطلاعات مفيد و دقيق، به تصميم‌گيرندگان مرتبط، در بازه زماني لازم، به منظور کمک به اخذ تصميمات مؤثر است.
5. کتاب «راهکارهاي هوش تجاريزيرکانه با مایکروسافت SQL 2008» :
هوش تجاري به شکل‌هاي گوناگون تعريف شده است. بعضي از ارائه کنندگان طوري هوش تجاري را تعريف مي‌کنند که محصولشان را در بهترين موقعيت قرار دهد. گاهي هوش تجاري را به عنوان يک ابزار گزارش گيري مؤثر معرف مي‌کنند ولي با امکاناتي که در SQL 2008 تعبيه شده است. هوش تجاري فراتر از يک سيستم گزارش ساز است. با توجه به اهداف اين کتاب ما تعريف مایکروسافت را مد نظر قرار مي‌دهيم:
راهکارهاي هوش تجاري، عبارتند از ذخيره‌سازي و ارايه مؤثر داده‌هاي سازماني کليدي به شکلي که کاربران مجاز بتوانند به سرعت و به راحتي به آن دسترسي يافته و آن را تفسير کنند.
پنج کليد براي موفقيت:
 
1. کمي سازي و اندازه‌گيري
چنانکه در دل تمامي تعاريف فوق نهفته است. يکي از کليدهاي موفقيت در هوش تجاري کمي سازي و اندازه‌گيري است. ما زماني مي‌توانيم اطلاعاتي در خصوص عملکرد سازمان توليدکنيم، که پيش از آن اطلاعات به صورتي کمي و قابل اندازه‌گيري تعريف شده باشند. به عنوان مثال فرض کنيد که ما مي‌خواهيم ميزان رضايتمندي مشتريان را از محصولات يک کارخانه مورد ارزيابي قرار دهيم. اگر نتوانيم قبل از هر کاري شيوه‌اي را براي ارزيابي اين مفهوم و کمي کردن آن تعريف کنيم، امکان سنجش آن به صورت سيستماتيک ميسر نخواهد بود.
شايد تصور اين باشد که بعضي از کارها قابل اندازه‌گيري نيستند. اما تجربه بشر نشان داده‌ است که همواره مي‌توان راهکارهايي را براي سنجش و کمي‌سازي پيدا کرد. شايد اولين باري که انسان موفق به ساخت هواپيما شد، فکر نمي‌کرد که بتواند شرايط جوي، ارتفاع و مکان را به شکلي کمي در اختيار خلبان قرار دهد. اما امروز شاهديم که با توليد ابزارهاي مختلف، امکان بررسي دقيق اين پارامترها مهيا شده است و تمامي آن‌ها کمي شده‌اند. در کسب و کارهاي مختلف نيز مي‌توان با مطالعه، تحقيق و بررسي تجارب مشابه، راهکارهاي علمي و دقيقي براي سنجش کليه وجوه عملکردي سازمان پيدا کرد.
2. هدف گذاري
هدف گذاري براي کسب و کار، و يا سازمان، گام بلندي در راستاي تحقق هوش تجاري است. زماني که شما توانستيد عملکردهاي خود را اندازه‌گيري کنيد و نتايج آن را مشاهده نماييد. گام بعدي بهبود اين عملکرد است. اين بهبود زماني معنا دارد که شما بتوانيد هدف درستي را براي آن مشخص کنيد تا ابزارهاي هوش تجاري، روند حرکت شما را به سمت هدف و يا دور شدن شما را از اهداف اندازه‌گيري کنند و دانش توليد شده را در قالب‌هاي گوناگون به شما ارائه نمايند.
هدف گذاري، در کنار ابزارهاي هوش تجاري، انگيزه حرکت و تحول را در سازمان ايجاد مي‌کند و از آنجايي که به کمک ابزارهاي هوش تجاري روند حرکت افراد تحت نظر است. کارکنان انگيزه بالايي خواهند داشت تا خود را نشان دهند و مورد تشويق مديراني که به دقت عملکردشان را نظارت مي‌کنند قرار بگيرند.
3. استفاده از دانش نهفته در سازمان و نيروي مشارکت
ابزارهاي هوش تجاري زماني به بهترين موفقيت مي‌رسند که دانش مربوط به حوزه کسب و کار به دقت در اجزاي آن حضور داشته باشد. دانش سازمان و حوزه کسب و کار در درون سازمان نهفته است و زماني مي‌توان اين دانش را در حد اعلي خود در اختيار گرفت که تمامي افراد سازمان در شکل‌گيري آن سهيم باشند. به همين دليل پيشنهاد مي‌شود که براي پياده‌سازي هوش تجاري از تمامي افراد بهره ببريد و از کمک همه در تعريف شاخص‌ها و تعيين اهداف و وزن‌ها استفاده کنيد. سامانه پويش با ايجاد فرآيند توليد شاخص، گامي بزرگ را در اين حوزه برداشته است. در اين سامانه شاخص‌ها در يک فرآيند تولي دمي‌گردند فرآيندي که تمامي افراد مي‌توانند در آن سهيم گردند و شاخص‌ها با يک نگاه جمعي و با مشارکت حداکثري به وجود آيند. علاوه بر اين سامانه پويش با ايجاد داشبوردهاي اختصاصي براي افراد گوناگون، دسترسي افراد را به اطلاعات مورد نيازشان تسهيل نموده است.
4. نگاه جامع
زماني مي‌توانيم هوش تجاري را به شکلي موفق در سازمان پياده کنيم، که نگاه جامعي به تمامي بخش‌ها داشته باشيم و تلاش کنيم که کليه فرآيندها و عملکردهاي کليدي سازمان تحت پوشش سامانه هوش تجاري ما قرار گيرند. تنها در اين صورت است که مي‌توانيم ارزيابي جامعي از وضعيت سازمان در اختيار داشته باشيم.
در صورت وجود نقص در سامانه هوش تجاري ارزيابي ما با واقعيت سازمان هماهنگ نخواهد بود و ممکن است اطلاعات ما را فريب دهد. به همين علت بايد تلاش کنيم تا نگاهمان جامع باشد و به چند حيطه محدود نگردد.
 
5. بازنگري مداوم
براي زنده نگه داشتن سيستم ضرورت دارد تا به صورت مداوم به بررسي فعاليت‌هاي انجام شده و مطابقت آن با واقعيت سازمان بپردازيم و با برگزاري جلسات مؤثر نواقص موجود را برطرف سازيم.
ممکن است روش‌هاي کمي‌سازي نياز به بازنگري داشته باشند و يا اهداف تعيين شده به مرور زمان و با توجه به شرايط نياز به تغيير داشته باشند.
زماني موفقيت ما روز افزون خواهد بود که به اين اصل کليدي توجه کافي داشته باشيم.
سامانه پويش با ايجاد واسط‌هاي کاربري ساده امکان تغيير و اصلاح پارامترهاي گوناگون هوش تجاري را فراهم نموده است.
ارسال شده توسط احمد محمدی | 29 11, 2013 | بازدید‌ها (1287)
بررسی ERPهای متن‌باز

سید فرزین فیروزآبادی
معاون نظارت و ارزیابی مرکز مدیریت آمار و فناوری اطلاعات وزارت بهداشت، درمان و آموزش پزشکی
farzinfirouzabadi@yahoo.com

کلمات کلیدی
سیستم‌های متن‌باز برنامه‌ریزی منابع سازمان Open Source Enterprise Resource Planning Systems

چكیده
سیستمهای ERP متن‌باز، اغلب برای شركتهایی طراحی شده‌اند كه نمی توانند نیاز‌های خود را با نرم افزارهای استاندارد برطرف نمایند. همچنین سازمانهایی كه نیازمند انطباق مداوم نرم افزار با مراحل تغییر و نیازهایشان هستند به نرم‌افزارهای متن‌باز روی می‌آورند.
غالبا شرکتهای کوچک و متوسط به حوزه ERP های متن باز وارد می‌شوند، علت اصلی این امر نیز ناتوانی مالی این شرکتها در استفاده از ERP های تجاری است. گزارش فوق پس از بررسی معیارهای مختلف ارزیابی ERPهای متن باز، و شناسایی حوزه بررسی این نرم‌افزارها در اینترنت، و شناخت و رده‌بندی ERP های متن‌باز، 3 راه‌حل برتر در این حوزه را معرفی می‌نماید.
تعریف سیستم ERP
ERP ( سیستم برنامه ریزی منابع سازمان )، تلاشی است برای ایجاد محصول جامعی كه اكثر عملیاتها را در یك شركت مدیریت نماید. تفاوت سیستمهای ERP، این است كه آنها تمامی وظیفه‌مندی‌ها را جمع مینمایند تا یك سیستم واحد یكپارچه، بجای گروهی از سیستمهای مجزا با كاربردهای غیر مستقل بسازند.
تعریف متن‌باز
در این گزارش، تعریف متن‌باز از Open source initiative (OSI) اتخاذ شده است. بر طبق OSI، نرم‌افزار متن‌باز یعنی نرم‌افزاری كه باید با شرایط زیر ( به صورت مختصر ) مطابقت نماید :
1- توزیع مجدد رایگان، شامل فروش یا استفاده بدون دریافت دستمزد
2- كد مبداء باید به صورت خواندنی قابل دسترس باشد .
3- كار مشتق شده از آن، نیز باید تحت همان شرایط مجوز استفاده باشند .
4- انسجام كد مبداء نویسنده ( ممكن است مجوزها درخواست نمایند كه تغییرات فقط به صورت ترمیمی -Patch- مجددا توزیع گردند و در منبع کد تغییری اعمال نشود. )
5- بین اشخاص و گروهها تفاوتی نباشد .
6- بین بخشهای كار تفاوتی نباشد.
7- توزیع مجوز ( مجوز به تمامی كسانی داده میشود كه از نرم‌افزار استفاده خواهند کرد)
8- مجوز نباید خاص یك محصول باشد .
9- مجوز نباید دیگر نرم افزارها را محدود نماید .
10- مجوز باید تكنولوژی بی طرف باشد .
تعیین معیارهای مختلف ارزیابی ERP های متن‌باز
توماس هرزوگ در گزارشی، 5 معیار اصلی برای ارزیابی ERP های متن‌باز معرفی کرده‌است که عبارتند از:
1- مناسب‌بودن از لحاظ کارکردی (Functional Fit)
2- انعطاف‌پذیری (Flexibility)، شامل شاخص‌های:
• سفارشی‌سازی
• ارتقاء انعطاف‌پذیر
• چند‌زبانی – میزان بین المللی بودن
• راحت‌بودن کاربر با آن
• معماری
• مقیاس‌پذیری
• امنیت
• اینترفیس‌ها
• وابسته‌نبودن به سیستم عامل
• وابسته‌نبودن به پایگاه داده
• زبان برنامه‌نویسی
3- پشتیبانی (Support) شامل شاخص‌های:
• زیرساخت پشتیبانی
• آموزش
• مستندسازی
4- تداوم (Continuity) شامل شاخص‌های:
• ساختار پروژه
• فعالیت انجمن‌ها
• شفافیت
• نرخ بروزرسانی
5- تکامل (Maturity) شامل شاخص‌های:
• میزان توسعه
• سایت‌های مرجع
هزینه های نهایی برای سیستم ERP بسیار مهم هستند. این هزینه‌ها عبارتند از هزینه‌های مشورت، تحلیل، مجوز، اجرا، سفارشی کردن، نگهداری، آموزش، ترکیب، پشتیبانی، ارتقاء و انطباق مداوم با فرایندها. تمامی معیارهای ارزیابی مطرح شده تأثیر هزینه ای دارند.
به عنوان مثال مناسب بودن از لحاظ کارکردی، بیانگر میزان سفارشی کردن و توسعه های اضافی مورد نیاز برای تناسب نزدیک با پروسه‌های مورد نظر است. انعطاف پذیری نشانگر فرصتها و امکاناتی است که شکاف میان کارکردها را می پوشاند و هزینه سفارشی کردن را کاهش می‌دهد.
پشتیبانی نشان می‌دهد که انتقال دانش برای اجرا و عملیاتی کردن سیستم فراهم است. تداوم، حمایت پروژه و استقلال سیستم را نشان می‌دهد. تکامل، خطرات انتخاب سیستم با کیفیت نامناسب را متذکر می سازد که مثلا این سیستم فعلا آماده عملیاتی شدن نیست.
مباحث مرتبط با مجوز (Licence) در اینجا نیامده است در حالیکه نوع مجوز نیز یکی از معیارهای اصلی در انتخاب نرم‌افزار متن‌باز است.
مناسب بودن از لحاظ کارکردی
مناسب بودن از لحاظ کارکردی (تناسب تابعی) برای دیدگاه شرکت و عاملیت برای دیدگاه سیستم ERP مورد استفاده قرار می گیرد. هر چقدر تناسب بیشتر باشد، هزینه های سفارشی کردن و اجرا کمتر می‌شود. تناسب تابعی تأثیر زیادی بر هزینه نهایی و زمان اجرا دارد. چون که شرایط تابعی بر اساس بخشهای کاری تغییر می کند، روش اصولی برای اندازه گیری تناسب تابعی وجود ندارد. تعداد جداول پایگاه داده ها به عنوان یک شاخص قابل اندازه گیری میزان عاملیت یک سیستم ERP مطرح شده است، با این فرض که ساختار داده به خوبی طراحی شده است.
انعطاف پذیری
انعطاف پذیری باعث می‌شود که بتوان هزینه‌های سفارشی سازی را کاهش داد. جدا از امکان تطابق سیستم با پروسه‌های تجاری مطلوب، انعطاف پذیری همچنین بر مسائل سهولت کار و اجرا و استقلال پایگاه داده دلالت دارد. انعطاف پذیری در مورد مفاهیم فنی و طراحی نرم افزاری سیستم است. یک سیستم ERP انعطاف پذیر معیارهای زیر را دارا می باشد:
سفارشی سازی
سطح بالای سفارشی‌کردن از طریق ویرایش متا‌دیتا، به این معناست که سیستم از طریق ویرایش سفارشی می‌گردد و اطلاعات به سهولت به جای رمز گذاری سطح پایین در یک زبان برنامه نویسی، قابل درک و خواندن هستند. متخصص باید بتواند سیستم را بدون داشتن اطلاعات ریز برنامه نویسی، سفارشی نماید. هدف، کاهش حجم یادگیری به هنگام ایجاد امکانات قدرتمند برای نظارت بر محدوده گسترده مشکلات است. امکانات سفارشی کردن سطح بالا و قدرتمند، عامل بهره‌وری مهمی برای کاهش زمان اجرا را بدست می‌دهد و باعث انطباق مداوم پروسه‌ها می‌گردد.
سفارشی کردن سطح پایین، نیز بسیار مهم بوده و به عنوان چارچوب کاربردی استفاده می‌گردد. برای طراحانی که خواهان تفحص بیشتر در جزئیات هستند و انعطاف پذیری بیشتری نیاز دارند، سیستم باید به عنوان یک چارچوب برای توسعه کاربردی قابل استفاده باشد. در اینجا سیستم ERP معماری نرم افزار را مشخص می نماید و باعث تطابق عاملهای سفارشی می‌گردد. این کد سفارشی باید مطابق مشخصات API چارچوب باشد. کدنویسی، سفارشی کردن سطح پایین نامیده می‌شود.
ارتقاء انعطاف پذیر در صورتی که سیستم سفارشی کردن به وسیله متا دیتا و کد سفارشی به صورتی که بر مبنای چارچوب باشد را برآورده نماید، بایستی ایجاد روش ارتقاء بدون اثر روی سفارشی کردنها را نیز ممکن سازد.
چندزبانی
آسانترین شکل بین المللی کردن، ایجاد ترجمه هایی برای کاربر و روشهای حسابداری محلی است. زبان بر اساس سطح کاربر انتخاب می‌شود. می توانید بین ترجمه آسان بخشهای دستیابی رابط گرافیکی کاربران (GUI) (شکل منوها، برچسب‌ها و ...) و ترجمه بخشهای پویای GUI (مثل وضعیتهای جریان کار) و محتوی (مثل تعریف محصول) تفاوت قائل شوید. اغلب احتیاجات ملی قانونی، مخصوصاً در حسابداری خواستار جریان کار سفارشی یا منطق تجارت هستند. این به این معناست که تسهیلات سفارشی کردن خوب یک پیش شرط برای بین المللی کردن هستند.
برای سیستمهای ERP متن‌باز، حتی آسانترین آنها که فقط کاربرد محلی دارد، داشتن انعطاف پذیری جهت پشتیبانی از خیلی کشورها برای دستیابی به کاربران بین المللی و کاهش ریسک چند شاخه شدن پروژه به دلیل پشتیبانی محدود بین‌المللی خیلی مهم است. چند شاخه شدن پروژه یعنی انشعاب پایگاه کد که منجر به دو پروژه مجزا و در نتیجه چند تکه شدن انجمن نرم افزاری و کاهش همکاری می‌گردد. پشتیبانی چند سایت دلالت بر خدمات رسانی به چندین سایت توزیع شده بین المللی از طریق کاربرد حسابداری متفاوت و تدابیر هزینه ای در یک سیستم ERP دارد.
برای مدیریت سایت و عاملیت مشخص ملی، سیستم ERP باید اجازه تعمیم عاملیت مشترک را بدهد. سایتها می توانند از طریق یک سیستم مرکزی خدمات رسانی شوند که اتصال معتبر به تمامی سایتها یا سیستمهای توزیع و همگام شده داشته باشد.
راحت‌بودن کاربر با سیستم
رابط کاربر باید بر اساس اطلاعات مورد نیاز کار طراحی شود. یک کار آسان به گذر از میان صفحات زیاد نیاز ندارد. انطباق سیستم ERP با پروسه ها، بخشی از سفارشی کردن است. میانبرهای کیبرد برای کارهای معمولی باید ایجاد گردند. بعضی از سیستمهای ERP فقط چند مؤلفه رابط گرافیکی میان کاربران (GUI) را پشتیبانی می‌کنند. مساعدت کاربر، با امکانات سفارشی کردن، پذیرش کاربر، هزینه های آموزش و هزینه‌های عملیات مرتبط است.
معماری
انتخاب معماری، برای اکثر فاکتورهای انعطاف پذیری مهم است. راه حلهای متن‌باز، معماریهای 2-tire و 3-tire دارند. معماری 2-tire یا سرویس دهنده / سرویس گیرنده مرکب از یک سرویس گیرنده fat شامل GUI و منطق کسب و کار است، که مستقیماً با پایگاه داده ارتباط دارد. در معماری 3- tire، کلاینت فقط در قبال GUI و اعتبار داده مسئول است. تمامی منطق در Application Server است. پایگاه داده مسئول ذخیره اطلاعات به صورت ماندگار است. معمولاً در مورد معماری 3- tire، سرویس گیرنده "thin" یک web browser است و سرور کاربردی یک سرور کاربردی اینترنتی است.
مقیاس‌پذیری
سیستم باید حجم معاملات بالا را با زمانهای پاسخگویی ثابت پشتیبانی نماید. مقیاس‌پذیری بیشتر به معماری و سپس به سرور کاربردی و تکنولوژی مورد استفاده پایگاه داده وابسته است.
امنیت
مکانیسم های امنیتی کاربر یا role – based، به تعریف سطوح مختلف حقوق دستیابی منجر می‌گردد. کاربران مجازند که تنها اطلاعاتی را که برای کارشان مورد نیاز است ببینند و تغییر دهند.
granularity بر روی فرم، فیلد و سطح ردیف مشخص می‌گردد. امنیت در سطح سطر داده، دستیابی به داده ها را محدود کرده و کنترل بیشتر روی آن را امکان‌پذیر می‌سازد. به عنوان مثال، یک کاربر فقط می تواند معاملات مربوطه را که خود مسئول آنهاست ببیند.
اینترفیس‌ها
رابط یک مرز ارتباطی سیستم ERP است. این رابط ها برای ارتباط سیستم ERP با دیگر سیستمها یا تبادل اطلاعات استفاده می شوند.
وابسته نبودن به سیستم عامل
استقلال سیستم عامل، به شما اجازه می دهد تا سیستم ERP را بر روی پایگاه‌های مختلف اجرا نمایید. این یک ویژگی لازم برای سرویس گیرنده جانبی است، در صورتیکه کاربران، سیستم های عامل متفاوتی داشته باشند.
وابسته نبودن به پایگاه داده
پایگاه داده تأثیر زیادی بر مقیاس‌پذیری سیستم دارد. بعضی ها، پایگاه‌های داده متن‌باز را به سیستم های ERP متن‌باز ترجیح می‌دهند. یک رابطه جایگزینی بین استقلال پایگاه داده و ویژگیهای پایگاه داده، مخصوصاً ویژگیهای رابطه ای موضوعی به کار گرفته شده وجود دارد. استقلال بالای پایگاه داده دلالت بر کاربرد ویژگی مشترک حداقل دارد که توسط تمامی پایگاه داده های پشتیبانی شده ایجاد می‌گردد. بعضی از ویژگیهای از دست رفته در زمان استقلال را می توان به وسیله سرور کاربردی ایجاد نمود.
زبان برنامه نویسی
زبان می تواند معیاری برای استفاده از مهارتهای موجود برای دو سطح سفارشی کردن باشد.
زبانهای برنامه نویسی متعلق به سیستم های ERP انتخابی، زبانهای Open Source Scripting (Python) , Perl و جاوا هستند. Python به خاطر قابلیت قابل خواندن، گرامر دقیق و عامل یابی مجدد غیر قابل انتقال، شناخته شده است. Perl به صورت گسترده استفاده می‌شود، اما به تنظیم بیشتر طراح برای گرفتن کد قابل خدمات رسانی محتاج است.
Java یک پشتیبانی صنعتی قوی دارد و خیلی از ابزارهای مهندسی نرم افزار برای آن موجود هستند. شمردن خطوط که برای عاملیت به دلایل زیر یک شاخص بد به حساب می آید: زبانهای Scirpting سطح بالا، به خطوط کمتر کد نیاز دارند. رویکردهای طراحی بر اساس متادیتا انعطاف پذیر نیز، به خطوط کمتر کد نیاز دارند و متادیتا می تواند در کد برنامه نویسی و یا به صورت خارجی مشخص گردد.
پشتیبانی
پشتیبانی به خاطر انتقال دانش به شرکت، باعث کاهش زمان اجرا و عملیاتی شدن سیستم در سازمان می‌گردد.
پشتیبانی به پیشرفت مهارتهای داخلی یا مشاوران خارجی استخدام شده برای اجرا و نگهداری سیستم ERP متن‌باز کمک می نماید.
زیر ساخت پشتیبانی
پشتیبانی قابل اعتماد و پاسخگو بسیار مهم است. این پشتیبانی می تواند محلی یا آنلاین باشد. بیشتر پروژه های ERP متن‌باز، مشکلات را با توجه به نیازهای مختلف ملی از یک شبکه همکار حل و فصل می نمایند. یک همکار محلی می تواند مشاوره، پشتیبانی، مدلهای افزودنی را ایجاد و نیازهای ملی همچون استانداردهای حسابداری، رابط‌های مقامات دولتی و بانکها را اداره نماید. جدا از دانش در مورد احتیاجات ملی، همکاران دانش صنعتی خاص دارند. پشتیبانی آنلاین از عموم، جلسات سانسور نشده و لیست پستی مهم است، چونکه به کاربران و طراحان امکان خواندن و بررسی مسائل را می دهد.
آموزش
در اینجا، کیفیت و تعداد کاربر و آموزش فنی یا سازماندهی کنفرانس ها اهمیت ویژه ای دارند.
مستندسازی
تمامیت و به روز آوری مستندات از اهمیت زیادی در نرم‌افزارهای متن‌باز برخوردار است. بیشتر پروژه ها از سیستم مدیریت Wiki برای نگهداری و نظارت مستند سازی ترکیبی استفاده می‌کنند.
تداوم
تداوم پروژه تضمین می نماید که هزینه های سیستم ERP شما، سرمایه گذاری حمایتی هستند.
به هنگام تمرکز شما بر روی سیستم، شما خطر اینکه سیستم بروز نشود را می پذیرید.
تغییرات سریع تکنولوژی ممکن است مشتریان را مجبور نماید که استراتژی کاری فروشنده و در نتیجه خرید بالا یا پیشنهادات انتقال فروشندگان ERP را دنبال نمایند. ریسک قطع سیستم به دلیل تعویض فروشنده، ور شکستگی فروشنده یا تغییر تکنولوژی وجود دارد.
نرم افزار متن‌باز ریسک سرمایه گذاری را کاهش می دهد، همانطوری که نمی توان از پیشرفت به راحتی چشم پوشید. شما فرصت نگهداری نرم افزار را دارید، اما برای دستیابی به مزایای مقیاس، مهم است که سیستم با شرکتها و انجمن های فعالی پشتیبانی شود که بسته ERP را به روز نگهداری می نمایند. برای ارتقاء بی دردسر سیستم ERP کاملاً سفارشی شده، طراحی نرم افزار انعطاف پذیر مورد نیاز است.
از طرف دیگر، وقتی که پروژه فقط توسط یک شرکت انجام می‌گردد، ریسک انتشار ورژنهای جدید با مجوز متفاوت وجود دارد. شرکت های متن‌باز وابستگی زیادی به انجمن‌های کاربران دارند به طوری که بخش کمی از کاربران مشتاق خرید خدمات دیگر هستند. یک انجمن کوچک، خدمات فروشی مثل مستند سازی اضافی، آموزش، مشاوره یا گواهی همکار را ارائه نمی‌دهند.
فعالیت انجمن‌ها
چهار نوع عضو انجمن برای سیستم‌های ERP متن‌باز وجود دارد، کاربران واقعی که در میزگرد ها فعال هستند، تست کننده‌های نسخه بتا که شرح خطا را ارائه می‌دهند، خالقان محتوا که مستند سازی و مشخصات لازم را ایجاد می‌کنند و طراحان سیستم.
هر چقدر یک انجمن پروژه ERP بزرگتر و فعال تر باشد، ریسک رها نمودن پروژه کمتر می‌شود. هیچ روشی برای محاسبه تعداد مشتریان استفاده کننده از سیستم های ERP متن‌باز به عنوان یک شاخص تداوم وجود ندارد چرا که مشتریان نیاز به ارائه بازخور به رهبران پروژه ندارند.
اگر پروژه توسط http://www. Sourceforge.net - یک پایگاه مورد استفاده گسترده برای پروژه های متن‌باز - میزبانی شود، شما می توانید آمارها را به عنوان شاخص تهیه نمایید.
تعداد پیام ها در لیست پستی یا میزگرد ها یک شاخص قابل اندازه گیری است. در مورد تخمین تداوم، رضایت کاربرد ارتباط طرح مهم تر است. همچنین به عنوان یک اثر جانبی، اشاره ای به تکامل پروژه دریافت می کنید. دیگر شاخص تداوم، خود محصول است. یک سیستم خوب و قابل استفاده به ندرت از طرف انجمن رها می‌شود.
فعالیت ارتباطات انجمن از روش های معین ارتباطات قابل اندازه گیری هستند. در اینجا تعداد پیامها در میزگرد ها و لیست پستی مورد استفاده قرار گرفته است. علاوه بر تعداد، جواب های مشروط و زمان پاسخگویی مهم هستند. فعالیت مستندسازی مانند ایجاد وب سایت و ثبت Wiki، بخشی از پشتیبانی / مستند سازی را تشکیل می‌دهند.
ساختار پروژه
پروژه های قابل اعتنا و عملیاتی‌شدن در سازمان، پروژه هایی هستند که دارای شرکت یا انجمن نرم افزاری هستند، دارای شرکت یعنی یک شرکت مسئول پیشرفت، ارائه خدمات و تأیید همکاران برای پشتیبانی محلی است. یک شرکت نوعی دارای پروژه، دارای شریک های زیر می باشد:
شرکت پروژه متن‌باز ،
شرکت های همکار،
مشتریان با قرارداد پشتیبانی،
مشتریان بدون قرارداد پشتیبانی
و کاربرانی که با سیستم کار می‌کنند.
مدل تجاری و اندازه شرکتهای مورد بحث فاکتورهای تداوم هستند.
پروژه دارای انجمن یعنی، پیشرفت به صورت تعاونی است و هیچ شرکتی به تنهایی مسئول نیست.
شفافیت
این بخش در مورد موانع ثبت برای توسعه‌دهندگان و امکانات انجمن برای کمک و تأثیر در پروسه، کیفیت مدیریت پروژه و همچنین مستند سازی پروسه توسعه است. یک نقشه مسیر مستند و معتبر به تخمین تمرکز فعلی و جهت آتی پروژه کمک می نماید. چون توسعه‌دهندگان، متخصصان هستند، مشتری باید در ازای اجرای یک کارکرد خاص به آنها پول بپردازد، مگر اینکه این مسأله برای پروژه ضروری بنظر برسد.
یک سیستم ردیابی عمومی در مورد جزئیات خطا و زمان صرف شده جهت برطرف نمودن آن، ویژگیهای سازمان‌یافته و اولویت‌دهی آنها آگاهی می دهد. میزان درگیری انجمن در پروسه توسعه، یک فاکتور دیگر برای استقلال فروشنده ایجاد می‌کند. کد سورس باید قابل خواندن و مستند سازی باشند. مستند سازی ابزارهای توسعه و مراحل ساخت به طراحان جدید کمک می نماید تا به سرعت درگیر پروژه شوند.
نرخ بروزرسانی
ارائه مستمر کارکردهای جدید و برطرف نمودن خطاها، علائم تداوم توسعه هستند. یک مدرک log تغییر که در مورد ویژگیهای ورژن جدید آگاهی می دهد، فعالیت به روز درآوری گذشته را نشان می‌دهد. در حالیکه فعالیت انجمن در مورد ارتباطات، به روز درآوریهای معمولی را نشان می دهد.
تکامل
تکامل برای مفاهیم محدود بیشتر استفاده می‌شود و بمعنای کیفیت نرم افزار می باشد. در صورتیکه توانایی نرم افزار به مفاهیم تکنیکی و طراحی نرم افزار مربوط می‌شود. تکامل به شما می گوید تا چه حد این نرم افزار بهنگام اجرا و تست شدن عملکرد درست یا خطاهای کامپیوتری داشته است.
وضعیت توسعه
بعضی بسته های ERP متن‌باز هنوز برای تولید آماده نیستند. آنها می‌توانند در وضعیت برنامه ریزی، الفا، بتا و پایدار باشند. در مرحله برنامه ریزی خصوصیات یک نرم افزار مشخص می‌شود و هیچگونه برنامه اجرایی وجودندارد. اولین نسخه محصول جدید در بازار یک برنامه کامپیوتری ورژن آلفا یا نسخه انتشار یافته آلفا نامیده می‌شود.
این نسخه بنظر می‌رسد ناقص و متغییر باشد، اما برای اهداف تشریحی و نمایش نحوه کار آن و بعنوان اثبات برداشت های مفهومی از نخستین نمونه که بعدها گشترش خواهد یافت، مفید خواهد بود. ورژن بتا یا نسخه بتا، نسخه انتشار یافته یک برنامه کامپیوتری است که هنوز در حال کامل شدن است اما بصورت آزمایشی منتشر یافته است.
بصورت کاربردی بطور کامل تست نشده است و ممکن است خطاهای مهم کامپیوتری ظاهر شود. بعد از اینکه نسخه بتا بطور کامل تست شد و خطا های مهم کامپیوتری آن برطرف شد، برنامه یک نسخه ثابت خواهد شد. بعد از آن فقط خطاهای کامپیوتری کوچک که به عمکرد برنامه صدمه نمی زند، مجاز می‌باشد.
سایت مرجع
کیفیت نسخه پایدار بوسیله اجرا و آزمایش های گسترده نرم افزار مشخص می‌شود. اشکال و خطری که وجود دارد این است که تولید سیستم به اندازه کافی جامع نباشد. بنابراین بهتر است سیستم ERP را در عمل ببینید و با مشتریانی که اخیرا این سیستم را استفاده کرده اند یا می شناسند درباره اجرا و امور کاربردی آن بحث و گفتگو کنید. سایت های مرجع در صفحه خانگی پروژه لیست شده‌اند و قابلیت دسترسی اسناد موارد تجاری نیز معیار مهمی محسوب میشود.
شناخت و رده‌بندی ERPهای متن‌باز
همان‌طور که اشاره شد تمامی پروژه‌های معتبر متن‌باز در سایت www.sourceforge.net ثبت گردیده‌اند. در این سایت بیش از 10.000 پروژه ثبت گردیده و بزرگترین مخزن پروژه های متن باز بشمار می آید. لذا این سایت به عنوان فضای بررسی انتخاب شد. از سوی دیگر پروژه های مرتبط با ERP و فرایندهای سازمان در گروه Enterprise در این سایت طبقه بندی شده‌اند. لذا در این گروه به بررسی ERPهای متن‌باز پرداخته شد. ریسک‌ اصلی انتخاب این سایت به عنوان فضای بررسی، عدم ثبت برخی از ERP های مناسب در این سایت بود اما طبق ادعای این سایت، احتمال بروز این ریسک بسیار پایین است.
داده های مربوط به 200 پروژه برتر در گروه Enterprise با توجه به رده‌بندی سایت sourceforge استخراج و پروژه های مرتبط با مباحث ERP انتخاب شدند. ریسک اصلی انتخاب گروه Enterprise به عنوان گروه مورد بررسی، عدم مشخص کردن موضوع پروژه در هنگاه ثبت توسط ثبت کننده پروژه است. به عنوان مثال TinyERP یک ERP متن‌باز است که در این سایت ثبت شده است اما به دلیل مشخص نکردن گروه آن در هنگام ثبت پروژه، این ERP در گروه Enterprise قرار ندارد.
لازم به ذکر است، از آنجا که رتبه پروژه‌های بعدی بیشتر از 10.000 بود و همین امر احتمال انتخاب آنها را بسیار کاهش می‌داد از بررسی کل پروژه های موجود در گروه Enterprise که بالغ بر 1280 پروژه بود خودداری گردید.
با توجه به اطلاعات ارائه شده در سایت sourceforge، برای هر پروژه‌های اطلاعات زیر جمع‌آوری گردید:
1. نام
2. رتبه (با توجه به معیارهای سایت sourceforge)
3. تعداد دانلود
4. تاریخ ثبت
5. آخرین تاریخ بروزرسانی
6. تعداد توسعه گران
7. پایگاه داده
8. وضعیت پروژه
9. لیسانس
10. زبان برنامه نویسی
11. موضوع
12. ترجمه
13. واسط کاربر
14. وب سایت

هرزوگ نیز بر اساس تحقیقی ضمن معرفی معیارهای ارزیابی ERP های متن‌باز، چند ERPمتن‌باز را بر اساس این معیارها با هم مقایسه کرده است.
جدول زیر به طور خلاصه نتیجه این مقایسه را نشان می‌دهد:
شرح علایم و اختصارات
بله √    نه x    موجود نیست n/a    ناشناخته ؟    بالای متوسط +    متوسط
معیار ارزیابی    ERP متن‌باز                                  
#    معیار تابع    SQL Ledger    LX Office    TinyERP    GNUe    ERP5    Opentaps    compiere
1.                       خرد    +    +    +                   
2.                       کوچک    +    +    +         +    +    +
3.                       متوسط    +    -    -         +    +    +
4.                       بزرگ                        +    +    -
عاملیت
1.                       تعداد جدول ها    45    36    162    n/a    n/a    763    385
2.                       تجارت الکترونیکی         √    √         √    √    √
3.                       حسابداری    √    √    √         √    √    √
4.                       MRP              √         √    √    
5.                       POS              √         √    √    
6.                       لیست موجودی و انبار    √    √    √         √    √    
توانایی نرم افزار برای تطابق با موقعیت ها یا کار های مختلف
1.                       سفارشی كردن              +    +    +    +    +
2.                       ارتقاء انعطاف پذیر    +    +    +    ؟    ؟         +
3.                       بین المللی کردن    + چندسایت    -    + چند سایت    +    + چند سایت    + چند سایت    + چندسایت
4.                       مساعدت كاربر              +    ؟    +         
5.                       معماری    3_tier web    3_tier web    3_tier rich web    2 or 3_tier rich web    3_tier web    3_tier web    2 and 3_tier fat
6.                       مقیاس‌پذیری    +              ؟    +    +    +
7.                       امنیت              +    ؟    +    +    +
8.                       رابطها    CGI,SOAP    CGL    XML_RPC, Office    XML_RPC, Corba LDAP    XML_RPC, SOAP,XML    SOAP, CSV,XML    CSV
9.                       استقلال سیستم عامل                                  
10.                   استقلال DB                        Object db         
11.                   زبان برنامه نویسی    Perl    Perl    Python    python    python    Java,scripting    java
پشتیبانی
1.                       منبع پشتیبانی                   -    +    +    +
2.                       اموزش                                  
3.                       مستند سازی    +    -              -    +    +
تداوم
1.                       ساختار پروژه    همكاران شركت    همكاران شركت    همكاران شركت    انجمن    همكاران شركت    انجمن شركتها    همكاران شركت
2.                       فعالیت انجمن    +    +    +         -    +    +
3.                       شفافیت                   +         +    +-
4.                       تکراربروز رسانی    +         +         +    +    +
5.                       دیگر اثرات in-lock                                  ابزار انتقال
تکامل
1.                       وضعیت توسعه    پایدار    پایدار    پایدار    برنامه ریزی، بتا    پایدار    پایدار    پایدار
2.                       سایت مرجع    +                   +    +    +
موارد دیگر
1.                       گواهینامه                                  
2.                       نمونه اینترنتی                                  
3.                       میزبانی sourceforge                                  
4.                       دسترسی به CVS              فقط همكار                   
5.                       دانلود checksum                                  
6.                       شروع پروژه    2000    2004    2000    2000    2002    2001)2005(    1999
انتخاب 3 راه‌حل ERP متن‌باز برتر
همان‌طور که اشاره شد حوزه اصلی بررسی ما برای مقایسه ERP های متن‌باز سایت www.sourceforge انتخاب شد. تمامی پروژه‌های معتبر Open Source در سایت www.sourceforge.net ثبت گردیده‌اند. در این سایت بیش از 10.000 پروژه ثبت گردیده و بزرگترین مخزن پروژه های متن باز بشمار می آید. لذا این سایت به عنوان فضای بررسی انتخاب شد. از سوی دیگر پروژه های مرتبط با ERP و فرایندهای سازمان در گروه Enterprise در این سایت طبقه بندی شده‌اند. لذا در این گروه به بررسی ERP های متن‌باز پرداخته شد. ریسک‌ اصلی انتخاب این سایت به عنوان فضای بررسی، عدم ثبت برخی از ERP های مناسب در این سایت بود اما طبق ادعای این سایت، احتمال بروز این ریسک بسیار پایین است.
سپس داده های مربوط به 200 پروژه برتر در گروه Enterprise با توجه به رده‌بندی سایت sourceforge استخراج و پروژه‌های مرتبط با مباحث ERP انتخاب شدند. ریسک اصلی انتخاب گروه Enterprise به عنوان گروه مورد بررسی، عدم مشخص کردن موضوع پروژه در هنگاه ثبت توسط ثبت کننده پروژه است. به عنوان مثال TinyERP به ERP متن‌باز است که در این سایت ثبت شده است اما به دلیل مشخص نکردن گروه آن در هنگام ثبت پروژه، این سیستم در گروه Enterprise قرار ندارد.
لازم به ذکر است، از آنجا که رتبه پروژه‌های بعدی بیشتر از 10.000 بود و همین امر احتمال انتخاب آنها را بسیار کاهش می‌داد از بررسی کل پروژه های موجود در گروه Enterprise که بالغ بر 1280 پروژه بود خودداری گردید.
با توجه به اطلاعات ارائه شده در سایت sourceforge، برای هر پروژه‌های اطلاعات زیر جمع‌آوری گردید:
1. نام
2. رتبه (با توجه به معیارهای سایت sourceforge)
3. تعداد دانلود
4. تاریخ ثبت
5. آخرین تاریخ بروزرسانی
6. تعداد توسعه گران
7. پایگاه داده
8. وضعیت پروژه
9. لیسانس
10. زبان برنامه نویسی
11. موضوع
12. ترجمه
13. واسط کاربر
14. وب سایت
با توجه به اطلاعات حاصله از سایت sourceforge مهمترین معیارهای ارزیابی ERP های متن‌باز را به صورت زیر فهرست کردیم:
1. میزان مقبولیت (که با معیارهایی مانند تعداد دانلود، سابقه، ترجمه ها و ... سنجیده می‌شود)
2. میزان پوشش دادن فرایندها (عاملیت)
3. انعطاف‌پذیری
4. پشتیبانی و مستندات
در مرحله اول، با توجه به میزان مقبولیت از میان 1280 پروژه معرفی شده در سایت sourceforge، 50 پروژه انتخاب شد.
در مرحله دوم از فیلتر کردن گزینه‌ها، وب سایت این پروژه ها را بررسی کردیم.
داشتن وب سایت مناسب یکی از مهمترین معیارها برای یک ERPمتن باز است. و نشان از مقبولیت و اهمیت آن ERP است.
پس از بررسی وب‌سایت مربوط به پروژه‌ها، با توجه به معیارهای میزان پوشش دادن فرایندها، انعطاف‌پذیری و پشتیبانی و مستندات از میان گزینه های موجود، گزینه‌های زیر انتخاب شدند:
1. Compiere
2. Opentaps
3. Openbravo
نتیجه‌گیری
Compiere، OpenTaps و OpenBravo هر سه از معماری مستحکمی برخوردارند، انجمن‌های آنها بسیار فعال بوده و شرکتهای همکار بسیاری دارند. از سوی دیگر شرکتهای مشاوره زیادی با این ERPهای متن‌باز آشنا بوده و شرکتها را در پیاده‌سازی آنها کمک خواهند کرد.
متاسفانه با توجه به مستقر بودن شرکتهای پشتیبان Compiere و OpenTaps در آمریکا، همانطور که در پاسخ آنها به نامه ارسالی اشاره شده‌بود، این شرکتها قادر به پشتیبانی مستقیم از این دو در ایران نیستند.
اما در این میان Compiere به زبان فارسی ترجمه شده است. و یک شرکت ایرانی ادعا کرده‌است که حاضر است Compiere را در ایران پشتیبانی نماید. در این صورت Compiere گزینه بسیار مناسبی به شمار خواهد آمد.
OpenTaps نیز بر اساس چارچوب OfBiz است که Best Practice های کاملاً تشریح شده‌است. لذا در صورتی که تصمیم بر این گرفته شود تیمی برای سفارشی سازی یک ERP متن‌باز تشکیل شود به نظر می‌رسد این گزینه مناسب‌تر باشد. از نظر کارکردها نیز این ERP از بقیه کاملتر است اما متاسفانه مشکل اصلی آن نوع مجوز آن می‌باشد.
OpenBravo نیز ERP متن‌بازی است که معماری منعطفی داشته و شرکت پشتیان آن که مقرش در اسپانیا می‌باشد ادعا کرده است که قادر است این ERP را برای هر شرکتی سفارشی نماید. لذا در صورت تقبل مسئولیت پشتیبانی این ERP توسط شرکت پشتیبان، این ERP نیز می تواند گزینه مناسبی باشد.
منابع و مراجع
1. Harris, Russ: Customization versus Standardization: Striking a Balance in ERP Software. In: Machine Design, Jul. 20 2000, Vol. 72, Iss. 14, pp. 6467

2. Chalifour, Josh: TEC Talks to the Open For Business ProjectFree and Open Source Software Business ModelsPart Three: Compiere. in: Technology Evaluation Centers, 20040907
http://technologyevaluation.com

3. ChunChin Wei, ChenFu Chien and MaoJiun J. Wang: An AHPbased approach to ERP system selection. In: International Journal of Production Economics, Volume 96, Issue 1 , 18 April 2005, Pages 4762

4. Deldycke, Kevin: ERP5 Tutorial: Develop your own ERP with ERP5 Business Templates 0.9
http://www.erp5.org/sections/documentation/articles/erp5_developer_tutor3829/downloadFile/file/TutorialKevinen.pdf

5. Everdingen, Y.V.; Hillergersberg, J.V.; Waarts, E.: ERP adoption by European midsize companies. In: Communications of the ACM, Vol. 43 No. 4, 2000, pp. 2731

6. Ferg, Stephen: Python & Java: a SidebySide Comparison. 20040207
http://www.ferg.org/projects/python_java_sidebyside.html

7. Howison, James; Crowston, Kevin: The perils and pitfalls of mining SourceForge. 2004 05
http://opensource.mit.edu/papers/howison04msr.pdf

8. Hyoseob, Kim; Boldyreff, Cornelia: Open Source ERP for SMEs. http://eprints.lincoln.ac.uk/67

9. Kay, Emily: Going global with ERP, July 1 1998
http://www.itmanagement.earthweb.com/erp/article.php/11072_60 3341_2

10. SmetsSolanes, JeanPaul: ERP5: a technical Introduction
http://www.erp5.org/sections/documentation/articles/linuxtag.html

11. Bernroider, Edward; Koch Stefan: ERP selection process in midsize and large organizations. In: Business Process Management Journal, Vol. 7 No. 3, 2001. MCB University Press, pp. 251257.
http://www.emeraldlibrary.com/Insight/viewContentItem.do?contentType=Article&contentId=843480

12. SmetsSolanes, JeanPaul: ERP5: Missioncritical ERP/CRM with Python and Zope
http://pythonology.org/success&story=nexedi

13. Alshawi, Sarmand; Themistocleous, Marinos; Almadani, Rashid: Integrating diverse ERP systems: a case study. In: The Journal of Enterprise Information Management Volume 17, Number 6, 2004. Emerald Group Publishing Limited, pp.454462.
http://www.emeraldlibrary.com/Insight/viewContentItem.do?contentType=Article&contentId=1529220

14. Basil Argasosy: OfBiz An Insider View
http:ofbizwiki1.gointegral.com/Wiki.jsp?page=OFBizInsiderTutorial

15. Chalifour, Josh: TEC Talks to the Open For Business ProjectFree and Open Source Software Business ModelsPart One: OFBiz. in: Technology Evaluation Centers, 20040907
http://technologyevaluation.com

16. Sumner, Mary: Enterprise Resource Planning, Pearson Prentice Hall, 2005

17. Teltumbde, Anand: A framework for evaluating ERP projects In: International Journal of Production
Research, 2000, VOL. 38, NO. 17, pp. 45074520

18. MacVittie, Lori: Buckle Up: Implementing an ERP Takes Time and Patience. In: Network Computing
http://www.networkcomputing.com/1206/1206ws2.html

ارسال شده توسط احمد محمدی | 29 11, 2013 | بازدید‌ها (3026)

همه چیز درباره ERP متن باز

خلاصه مقاله
ERP مخفف عبارت Enterprise Resource Planing می باشد. ERP راهی برای یکپارچگی داده و پردازش های یک سازمان در یک سیستم است.
 
 
متن کامل مقاله

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

یکپارچگی کلید ERP

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


سیستم ایده آل ERP


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


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

پیاده سازی سیستم ERP

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

پیاده سازی یک سیستم ERP در آخر باعث تغییرات عمده در کارکنان و کارها خواهد شد.
یکی از مهمترین خصایصی که سازمان هنگام پیاده سازی سیستم ERP خود باید دارا باشد مالکیت پروژه است. زیرا تغییرات زیادی اتفاق می افتد و تاثیر وسیعی تقریبا روی هر شخصی در سازمان دارد.این بسیار مهم است که مطمئن شوید هر کسی روی تخته است(منظور لحاظ شدن هر فرد در پروژه می باشد) و این کمک خواهد کرد که ساخت پروژه و استفاده از BPR جدید با موفقیت انجام شود.
 

فواید سیستم های ERP

فواید زیادی برای پیاده سازی سیستم ERP وجود دارد. تعداد کمی از آنها از این قرار است:


سیستم های کاملا یکپارچه شده

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

اشکالات سیستم های ERP

برای بسیاری از سازمان ها، فواید پیاده سازی یک سیستم ERP معمولا بیشتر از اشکالات آن است. در این جا بعضی از بیشترین موانع معمول را می بینید :

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

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

احتیاج به مهندسی مجدد فرآیندها
سیستم های ERP می توانند هزینه زیادی برای نصب و اجرا داشته باشند
در پشتیبانی فنی می تواند دارای کیفیت کمی باشد
ERP ممکن است برای سازمان های خاصی که جدید هستند یا می خواهند راه جدیدی را در آینده نزدیک پیش بگیرند انعطاف پذیر نمی باشد.

 

 

ارسال شده توسط احمد محمدی | 27 11, 2013 | بازدید‌ها (862)

Enterprise Resource Planning  A Complete Business Solution


 

 By: Shravan Kumar, Shrikant Nirmalkar, Sudhir Kumar Meesala

 

برنامه ریزی منابع سازمانی

یک راه حل تجاری کامل

  مترجم و گردآورنده: احمد محمدی

دانشجوی کارشناسی ارشد مدیریت فناوری اطلاعات

پاییز 92

 

مقدمه

سیستم برنامه ریزی منابع سازمانی (ERP) به عنوان یکی از نرم افزار کسب و کار کامل در محیط رقابتی امروز در نظر گرفته شده که مدیریت اطلاعات داخلی و خارجی در سرتاسر سازمان ،  مالی و حسابداری، تولید، فروش و خدمات، مدیریت ارتباط با مشتری ، و غیره را یکپارچه سازی می نماید. در حال حاضر ERP بهای ورود و اجرای یک کسب و کار و اتصال به دیگر شرکت ها در یک اقتصاد شبکه ای برای ایجاد "B2B" تجارت الکترونیکی است. بسیاری از شرکت ها بطور اساسی استراتژی هایIT  خود را برای حفظ یک مزیت رقابتی تغییر دادند ، یعنی تبدیل به پاسخگویی بیشتر در تغییرات بازار  و ارائه بهتر خدمت در کاهش هزینه ها برای بسیاری از کاربران ،ERP   یک سیستم "همه را انجام بده است " که همه چیز از ورود سفارشات فروش تا خدمات به مشتریان را انجام می دهد .  با این حال هزینه های بالای آن مانع راه اندازی یک سیستمERP  در کسب و کارهای کوچک می شود و نگرانی های حریم خصوصی در درون یک سیستم ERP و فقدان افراد آموزش دیده ممکن است بر بهره وری ERPتاثیرگذار باشد.

5 شرکت اصلی ارائه دهنده ی ERPدر جهان ، SAP-AG ، Oracle, ، JD Edwards ، PeopleSoft و Baan هستند. پردازشERP بهترین شیوه های کسب و کار را در یک فرم چاپ می کند و شرکت را از مرحله آغاز مهندسی محصول، ارزیابی و تحلیل تا مراحل پیاده سازی نهایی محصول راهنمایی کند.

 

متدولوژی :معیارهای انتخاب یک سیستم ERP

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

 

پیاده سازی یک سیستم ERP

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

 از دیدگاه مدیریت ، ماهیت مشکل پیاده سازی ERP شامل استراتژی سازمان و ابعاد فنی می شود.  بنابراین  پیاده سازی ERP شامل ترکیبی از تغییرات فرآیند کسب و کار (BPC) و تنظیمات نرم افزار برای هماهنگ کردن این نرم افزار با فرآیندهای کسب و کار  می شود . دو رویکرد استراتژیک متفاوت برای پیاده سازی نرم افزار ERP وجود دارد . در رویکرد اول ، یک سازمان هماهنگی فرآیند کسب و کار را با باز مهندسی  فرآیند کسب و کار بر اساس قابلیت های سیستم ERP انجام می دهد، که به معنی تغییرات ساختاری  در روش های طولانی تثبیت شده انجام کسب و کار و دگرگونی نقش ها و مسئولیت های مهم افراد است و مزایای آن بهبود فرآیندها  و جلوگیری از اشتباهات جبران ناپذیر پرهزینه است. رویکرد دیگر سفارشی سازی نرم افزار به جای تغییر فرآیند موجود است ، که سرعت پروژه کاهش داده و شناسایی ایرادات مهلک در سیستم و به روز رسانی نرم افزار برای نسخه بعدی فروشنده ERP  را فوق العاده دشوار می نماید، زیرا سفارشی سازی نیاز به جدا شدن بخش ها و بازنویسی آن ها به تناسب نسخه جدید دارد. با این حال ، اثبات شده که رویکرد اول منطقی تر و موثرتر است .از آنجا که هر یک از گزینه ها دارای اشکالاتی است ، راه حل می تواند یک مصالحه بین طراحی مجدد کامل فرایند و اصلاح بزرگ نرم افزاری باشد. با این حال  بسیاری از شرکت ها تمایل به گرفتن مشاوره از فروشنده نرم افزار ERP خود و تمرکز بیشتر در مورد تغییر فرایند را دارند. نسل فعلی سیستم ERP نیز مدل های مرجع و یا قالب های فرایند که در حال حاضر متضمن بهترین روش های کسب و کار هستند را فراهم می کند. مدل های مرجع توسط فروشندگان نرم افزار ERP و یا شرکت های مشاور با استفاده از دانش فرایند کسب و کار و بهترین روش ها ، ارائه فرصت مقایسه راه حل های نرم افزاری کسب و کار یا تعیین مثبت یا منفی بودن مسائل پیاده سازی، ارائه شده است. پیاده سازی ERP اغلب مستلزم انتقال دانش کسب و کار گنجانده شده در معماری اساسی بسته نرم افزاری در ساختار سازمان است. در مقاله ای ، لی یک رویکرد جدید برای تحلیل پیاده سازی ERP از چشم انداز انتقال دانش پیشنهاد نمود. ابتدا، انواع دانش در مدت پیاده سازی ERP منتقل و عوامل موثر بر این انتقال شناسایی شدند. سپس چگونگی درگیری بین دانش کسب و کار منتقل شده از بسته ERP و دانش سازمانی موجود ، را بررسی نمودند. نتایج نشان می دهد که قابلیت تطبیقی سازمان ​​در مورد توزیع مجدد نقش و مسئولیت و توسعه انواع دانش جدید مورد نیاز ، توانایی های سازمان را برای بومی کردن این فرآیندهای استاندارد در فرآیندهای کسب و کار موثر افزایش داده و یک مزیت رقابتی را ارائه می دهد.

شرکت ها مشکلات قابل توجهی را به ویژه در طول پروژه پیاده سازی واقعی تجربه کرده اند. بانکرافت و همکاران(1998) عوامل بحرانی موفقیت  (CSF)را برای پیاده سازی ERPارائه کردند، از جمله پشتیبانی مدیریت ارشد، وجود یک قهرمان پروژه(نمونه موفق) ، ارتباط خوب با ذینفعان و مدیریت پروژه موثر. عوامل خاص پیاده سازی ERP شامل بازمهندسی فرآیندهای کسب و کار ، درک تغییرات فرهنگی شرکت و استفاده از تحلیل گران کسب و کار در تیم پروژه می باشد. در یک مطالعه ی دیگر،Holland  وLight (1999) چارچوب CSFs را برای کمک به مدیران با برنامه ریزی و پیاده سازی موفق یک پروژه  ERP توسعه  دادند. مدل  CSFsشامل عوامل استراتژیک، از جمله استراتژی پیاده سازی کلی، و عوامل تاکتیکی به عنوان پیکربندی نرم افزار فنی و متغیرهای مدیریت پروژه می باشد.

بانکرافت و همکاران (1998) دیدگاهی از روند پیاده سازی ارائه دادند. مدل بانکرافت پنج مرحله دارد: تمرکز، تحلیل ، طراحی ، ساخت ، تست و پیاده سازی عملی . فاز تمرکز که در اصل فاز برنامه ریزی فعالیت های کلیدی که مجموعه ای متشکل از کمیته هدایت کننده ، انتخاب و ساختار تیم پروژه ، توسعه اصول هدایت پروژه و ایجاد یک طرح پروژه است . فاز  تحلیل شامل تجزیه و تحلیل فرآیندهای کسب و کار فعلی ، نصب  ERP ، نقشه برداری از فرآیندهای کسب و کار در توابع ERP و آموزش تیم پروژه می باشد. مرحله طراحی مستلزم طراحی سطح بالا و دقیق مورد پذیرش کاربر پیرو نمونه سازی تعاملی همراه با ارتباط مداوم با کاربران می باشد .فعالیت های کلیدی مرحله ساخت ، تست توسعه پیکربندی محیطی ، آزمودن نمونه جامع با داده های واقعی ، تست رابط ها ، ثبت و تست گزارشات و در نهایت ، تست سیستم و کاربر می باشد. در آخر، فاز پیاده سازی عملی ایجاد ساختمان شبکه ها، نصب رومیزی و مدیریت آموزش و پشتیبانی کاربر را پوشش می دهد.

 

نتیجه گیری و پیامدها برای آینده

پژوهش سیستم های ERP مجموعه ای از برنامه های کاربردی یکپارچه است که می تواند راه حل کلی برای نیازهای سیستم اطلاعات سازمان با پرداختن به بخش بزرگی از توابع کسب و کار از جمله امور مالی ،حسابداری، منابع انسانی ، زنجیره تامین و اطلاعات مربوط به مشتری باشد. اخیرا، این بسته ها بر روی معماری سرویس گیرنده/سرویس دهنده پیاده سازی شده که نسبت به سیستم های پردازنده مرکزی انعطاف پذیری و مقیاس پذیری بیشتری دارند.بیشتر سیستم های ERP هنوز فاقد تکنیک های هزینه یابی پیشرفته تر محصول ، مانند هزینه مبتنی بر فعالیت (ABC) ، هزینه چرخه عمر و هزینه یابی هدف می باشند . همچنین، آنها فاقد قابلیت های تکنیک های پیشرفته برای مقابله با عدم قطعیت مانند منطق فازی هستند . علاوه بر این ، تکنیک های متضمن به‌روز بودن در فناوری ، مانند شبکه های عصبی و الگوریتم ژنتیک نیز باید در سیستم های ERP موجود پیاده سازی شوند. تلاش تحقیقاتی بیشتری برای  متحد کردن این تکنیک های جدید در سیستم های ERP مورد نیاز است.

Normal 0 false false false EN-US X-NONE AR-SA
ارسال شده توسط احمد محمدی | 26 11, 2013 | بازدید‌ها (1717)

  A DESCRIPTIVE ANALYSIS OF DECISION SUPPORT SYSTEMS RESEARCH BETWEEN 1990 AND 2003

 By: David Arnott     Graham Pervan    Gemma Dodson

 

تجزیه و تحلیل توصیفی از پژوهش سیستم های پشتیبانی تصمیم

بین سال های 1990 تا 2003

مترجم و گردآورنده: احمد محمدی

پاییز 1392

دانشجوی کارشناسی ارشد مدیریت فناوری اطلاعات

 

مقدمه
این مقاله اولین گزارش از پروژه ی تحقیقاتی در مورد تئوری نظری سیستم های پشتیبان تصمیم گیری (DSS) است. حوزه اصلی این پژوهش بر تصمیم گیری و قضاوت نظری بر پایه نظم و انضباط ، استراتژی های پژوهش مورد استفاده در مقالات منتشر شده  و ارتباط حرفه ای تحقیقات DSS متمرکز است.از اهداف این پژوهش درک این است که در تحقیق DSS ، قضاوت و مبانی تصمیم گیری وابستگی نزدیکی دارند.

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

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

روش تحقیق
سوالاتی که این پژوهش را هدایت می نمایند عبارتند از: چه استراتژی ها و روش هایی در پژوهش های DSS مورد استفاده قرار میگیرند؟ تمرکز پشتیبانی تصمیم گیری و ارتباط حرفه ای تحقیق DSS چیست؟  مبانی نظری قضاوت در پژوهش DSS چه هستند؟

بازه زمانی پژوهش های منتشر شده برای بررسی از سال 1990 تا 2003 انتخاب شده است. چرا که این دوره زمانی شاهد یک رشد قابل توجه در استفاده از روش های پژوهش غیر اثبات‌گرایی است .همچنین در  صنعت این دوره شاهد استقرار چندین نسل جدید از DSS ، به ویژه در مقیاس بزرگ EIS ، انبار داده ها، و هوش کسب و کار است .
در این پژوهش یک پروتکل در کد هر مقاله مورد استفاده قرار گرفت و برخی از مقاله ها، به عنوان نماینده ای از انواع مختلف مقاله ها انتخاب شدند. برای بهینه کردن روند کدگذاری مقالات به طور جداگانه توسط دو محقق کدگذاری شدندو محقق سوم همه را بررسی می کرد. تحقیق قضاوت و تصمیم گیری در مستند کد شده توسط یک پژوهشگر دیگر مورد بررسی قرار گرفت. پروتکل های کد شده توسط محقق دیگری در پایگاه داده نرم افزار  SPSS برای تجزیه و تحلیل وارد شدند .این محقق همچنین یک بررسی با ثبات در کدگذاری  انجام می دهد.

بحث

در پرداختن به سوال اول پژوهش (چه استراتژی ها و روش ها در پژوهش های DSS استفاده میشود؟)   یعنی تجزیه و تحلیل عوامل اصلی پژوهش ، مراحل تحقیق و نوع مقالات در نظر گرفته شدند. دوره تجزیه و تحلیل سال 1990 تا 2003 شاهد حرکت قابل توجه در تحقیقات سیستم های اطلاعاتی هستند به دنبال این رویکرد  تحقیق  DSSبه شدت تحت تسلط پارادایم اثبات‌گرایان با 91 ٪ از مطالعات تجربی را دارد.همچنین پژوهش نشان می دهد که حدود یک سوم (32.9٪) از تحقیقات DSS غیر تجربی و  دو سوم ( 67.1٪ ) تجربی است.

در پاسخ به سوال دوم پژوهش (تمرکز پشتیبانی تصمیم گیری و ارتباط حرفه ای پژوهشDSS چیست؟ ) یعنی تجزیه و تحلیل عوامل DSS  ، سطح سازمانی دربرگیرنده ، تمرکز در تصمیم گیری پشتیبانی و ارتباط عملی در نظر گرفته شدند و تحقیق در سه زمینه متمرکز شد : PDSS ، GSS  و سیستم های هدایت شونده داده بزرگ (EIS و انبار داده ها ).این تحقیق نشان می دهد که PDSS  و DSS هوشمند کاهش قابل توجهی پیدا کرده اند در حالی که ، DSS  مبتنی بر مدیریت دانش ، انبارهای داده و سیستم های پشتیبان مذاکره به طور قابل توجهی در حال افزایش است.

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

پژوهش نشان می دهد که به طور کلی، تنها 9.5 ٪ از تحقیقات ارتباط عملی بالا یا بسیار بالا داشتند. از سوی دیگر  53.2 درصد از پژوهش هیچ یا کمتر ارتباط عملی داشتند.

در پاسخ به سوال سوم پژوهش) مبانی نظری قضاوت در پژوهش DSS  چیست؟) یعنی تجزیه و تحلیل مبانی تصمیم گیری وقضاوت، این پژوهش مشتریان اصلی و کاربران در پژوهش هایDSS  را بوسیله ارزیابی نقش سازمانی که دارند یا باید داشته باشند در هر مقاله شناسایی می نماید. بژوهش نشان داد که GSS  و سیستم های پشتیبان مذاکره  به مراجع زیادی برای تصمیم گیری استناد می کنند. از کسانی که منابع قضاوت و تصمیم گیری را ذکر کرده بودند ، کار سایمون تا حد زیادی محبوب ترین بود و  79.8٪ از تحقیقات DSS از یک شکل در مراحل مبانی تصمیم گیری در پایه نظری خود استفاده نکردند. رویکرد نظری اصلی برای تصمیم گیری را در این پژوهش در دو تا از رایج ترین طبقه بندی ها استفاده شد ، طبقه بندی  اول متفاوت بودن بین روش های توصیفی و تجویزی رویکرد ها است که هدف رویکرد توصیفی در واقع توصیف چگونگی فرآیند تصمیم گیری است و هدف نظریه های تجویزی( تئوریهای هنجاری ) توصیه بهترین یا مناسب ترین راه را برای اتخاذ یک تصمیم می باشد. طبقه بندی دوم از رویکرد تصمیم گیری به عنوان همپوشانی های اقتصادی یا رفتاری با اولین مورد را دارد . رویکرد های اقتصادی معمولا در به حداکثر رساندن برخی از موضوعات قابل مشاهده در محدودیت ها و مراقبت کردن از  رویکرد تجویزی هدف گذاری شده اند  در حالی که رویکرد تصمیم گیری رفتاری ، معمولا بر اساس درک واقعی رفتار است .

 

نتایج

این مقاله نشان می دهد که :

1.      تحقیق DSS در سه حوزه برنامه کاربردی اصلی متمرکز است : DSS شخصی ، سیستم ها ی پشتیبانی گروه و در مقیاس بزرگ سیستم های اطلاعات محور . نفوذ تحقیق DSS  فردی در حال کاهش است در حالی که در مقیاس بزرگ و پژوهش سیستم های اطلاعات محور در حال افزایش است.

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

3.      ارزیابی از ارتباط عملی پژوهش DSS نشان می دهد که نظم و انضباط بطور قابل توجهی از عملکرد حرفه ای دور است.

4.      عدم شناسایی ماهیت مشتریان اصلی / حامیان و کاربران اصلی DSS یک کمبود عمده از تحقیق DSS است.

5.      تقریبا نیمی از تحقیقات منتشر شده DSS مبتنی بر قضاوت و پژوهش تصمیم گیری نیست.

6.      رویکرد های تجویزی و رفتاری برای تصمیم گیری در پژوهش DSS بیشتر ذکر شده است.

7.      کار هربرت سایمون بیشترین نفوذ و قدرت را در مراجع مبانی قضاوت و تصمیم گیری  در تحقیق DSS  داراست.

Normal 0 false false false EN-US X-NONE AR-SA
ارسال شده توسط احمد محمدی | 25 11, 2013 | بازدید‌ها (5101)


 

ضرورت ها، پیش نیازها، چالشها و مراحل  استقرار هوش تجاری درسازمانها

سید محمود شجاعی کیاسری، دانشجوی کارشناسی ارشد مدیریت فناوری اطلاعات دانشگاه شهید بهشتی [1]

علیرضا طالب پور، عضو هيئت علمی و استاد دانشگاه شهید بهشتی[2]

 

چكيده

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

كلمات كليدي: هوش تجاری ، تصمیم گیری ، داده کاوی.

 

 

1.       مقدمه

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

این همسویی و مشارکت منجر به تغییر فرهنگ سازمانی، و بهبود روند اجرای فرآیند های حیاتی سازمان ها میگردد و در نهایت منجر به ایجاد سازمانی هوشمند و یادگیرنده میگردد.[4]

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

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

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

2.     ضرورت های استقرار هوش تجاری در سازمان ها

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

با توجه به تحقیقات انجام شده، ضرورتهای استفاده از هوش تجاری در سازمان ها را میتوان بصورت زیر دسته بندی کرد:[1]

1. مهمترين نياز يك مدير، داشتن اطلاعات دقيق براي اتخاذ تصميم درست است عوامل زير در تصميم گيري استراتژيك يك سازمان مؤثر مي باشند:

-       دسترسي، جمع آوري و پالايش داده ها و اطلاعات مورد نياز.

-       پردازش، تحليل و نتيجه گيري بر اساس دانش.

-       اعمال نتيجه و نظارت بر پيامدهاي اجراي آن.

سازمان هايي با مديريت قديمي كه از هوش سازماني استفاده نمي كنند در تصميم گيري ها معمولاً با مشكلات مختلفي روبرو هستند از جمله داشتن داده هاي حجيم، پيچيدگي تحصيل آنها و عدم توانايي پيگيري فرآيندها و نتايج تصميمات گرفته شده و لذا تصميمات اشتباه در اين سازمان ها نتايج خود را به طور روشن نشان نمي دهد و يا ديرهنگام نشان مي دهد اين سازمانها نگاهي جامع از وضعيت جاري و آينده خود ندارند.

2.  ضرورت ديگر استفاده از هوش سازماني، نياز به مديريت دانش در سازمانها است . سازمانها نياز به مديريت هوشمند اسناد و مدارك خود دارند همچنين داده های مؤسسات تحقيقاتي كه به منزلة دارايي اصلي آن سازمانها مي باشند نياز به مديريت دارد. هوش سازماني باعث مديريت بهتر اين داده ها مي شود. از آنجا كه سازمانها نياز دارند خودشان را با دانش روز تطبيق داده و همواره بروز باشند و خود را بر اساس شرايط مخاطبين و بازار و شرايط جديد خارج از سازمان هماهنگ سازند بحث آموزش مستمر كاركنان و حافظه سازماني در نگهداري و استفاده از آموزش هاي سازماني بسيار پر اهميت است و هوش سازماني به عنوان يك ضرورت در اينجا مطرح مي شود و باعث افزايش بهره وري آموزشي و حفظ دانش سازمان مي شود.[8]

3.    پیش نیازهای استقرار هوش تجاری در سازمان ها

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

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

-         وجود تحقیقات و بررسی های مداوم و مستمر درباره نیازهای اطلاعاتی سازمان (نیازهای فعلی و آتی)

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

-         وجود و نهادینه شدن فرهنگ  اشتراک گذاری اطلاعات، دانش و تجربیات در سازمان

-         درک نیاز، تمایل و توانایی در انجام فراتحلیل‌ها و استفاده از آنها نزد مدیران سازمان جهت مدیریت بهتر سازمان.

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

در شکل زیر مدل مشارکت موثر فناوری اطلاعات وکسب و کار سازمان ارائه شده است: شکل ۱

 

شکل۱  - مدل مشارکت موثر کسب و کار سازمان با فناوری اطلاعات برای استقرار هوش تجاری در سازمان[6]

 

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

1.   چه نوع داده هایی برای تحلیل های ما مورد نیاز است؟ و از چه منبعی باید این داده را تامین کرد؟

2.   تجزیه و تحلیل داده توسط چه کسی باید انجام شود و نتایج حاصل از تحلیل ها به چه صورت باید ارايه شود؟

ارايه پاسخ روشن به این ۲ پرسش مسیر حرکت سازمان را برای استقرار هوش تجاری روشن میکند.

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

3.1.                    سخت افزارهای مورد نیاز برای ذخیره سازی اطلاعات و انجام محاسبات

ارتقاء زیرساخت های ذخیره سازی داده ها(شبکه ذخیره سازی، ملحقات شبکه ذخیره سازی،مدیریت ذخیره سازی سلسله مراتبی)

3.2.                   نرم افزارهای کاربردی و منابع داده

نرم افزارها بایدسازماندهی شوند. مشکل انتقال و ارتباط و تجمیع داده ها در نرم افزارهای مختلف حل شود(CRM , SCM ,ERP)

3.3.                  تجمیع داده ها

نرم افزار واسطی ایجاد شود که تمام انواع پروتکل ها، واسط های کاربری، و مدل های اشیاء و ساختار داده ها برای ارتباط نرم افزارهای مختلف با یکدیگر را پوشش دهد. برای این امر نیاز به سرمایه گذاری در بخش اتصال سیستم هاست که امکان تجمیع اطلاعات از انبار های مختلف داده را فراهم میکنند و طی کردن فرآیند ETL که با اتصال به چندین منبع داده مختلف ، داده ها را بدست میآورد و سپس در یک انبار داده همه را مجتمع میکند.

3.4.                  پایگاه های داده رابطه ای و انبار داده ها:

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

3.5.                  پردازشهای تحلیلی آنلاین و موتور های تجزیه و تحلیل اطلاعات:

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

3.6.                   نرم افزارهای کاربردی تحلیلی:

نرم افزارهایی که امکان نفوذ در دادها و تجزیه و تحلیل آنها را میسر میسازند.

3.7.                  نمایش اطلاعات و تحویل نتایج:

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

4.     چالشهای استقرار هوش تجاری در سازمان ها

چالش عمده سازمان ها در استقرار هوش تجاری، بحث یکپارچگی و تجمیع داده های سازمان در قالب انبار داده است. معمولا داده ها در یک سازمان توسط نرم افزارها و سیستم های اطلاعاتی مختلفی جمع آوری میشوند و همین موضوع باعث مشکل شدن کار تجمیع داده ها میشود. ۹۰٪ از پرژه های انبار داده در سازمان ها که با شکست مواجه شده اند، از همین مشکل رنج میبرده اند[4]

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

در این مدل، انبارداده هایی وجود دارند(انبار داده، بازارهای داده، منابع ذخیره سازی دادهای عملیاتی)، صدها نرم افزار و برنامه کاربردی وجود دارند که باید انبار های داده را تغذیه نمایند. یک لایه تجمیع داده و یک لایه هوش تجاری نیز دیده شده است.

 

شکل ۲ -مدل تجمیع داده ها در انبارهای داده سازمان های بزرگ [4]

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

اما برای اتصال زیر سیستم ها از نظر داده ها و تجمیع انها، باید به سراغ استفاده از مستر دیتا یا داده های اصلی سیستم رفت.

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

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

5.     معماری هوش تجاری در سازمان

 معماری CIF  (Corporate Information Factory) که برای پوشش ضعف موجود در سیستم های EIS که همان مشکل ضعف در استفاده از یک منبع داده بود بوجود آمده است.  CIF يک معماري ادراکي پذيرفته شده ( در سطح وسيع ) است که انباره هاي اطلاعاتي اي که در اجرا و مديريت يک زيرساخت محکم و موفق هوش تجاري مورد استفاده قرار مي گيرند، را توصيف و طبقه بندي مي کند. این معماری بر مبنای تفکیک کل داده های سازمان به 5 پایگاه داده عمده بوجود می آید که عبارتند از:[9]

·         پايگاه هاي داده سيستم اجرايي  (The Operational System Databases)،

·         پايگاه داده تحليلي (Data warehouse)،

·         انباره داده اجرائي (The Operational Data Store)،

·         پايگاه هاي داده تحليلي خرد (Data Marts)،

·         پايگاه هاي داده عملِياتي خرد (Oper Marts).

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

·         فرآیندهای عمليات تجاري (Business operations): فرآیندهایی که با اطلاعات  عمليات روزانه و جاري سازمان در ارتباطند.  

·         فرآیندهای هوش تجاري (Business intelligence): فرآیندهایی که با جستجوي مداوم براي درک بهتر سازمان، ورودی های سازمان آن و خروجی های آن، تامین کنندگان و مشتریان و کلیه ذینفعان آن در ارتباط است. فرآيندهاي عمليات تجاري ايستا هستند، در حاليکه فرآیندهای هوش تجاري علاوه برفرآيندهاي ايستا، شامل فرآيندهايي است که همواره در حال تکامل اند و باید دائما مورد بررسی قرار گیرند.

·         فرآیندهای مديريت تجاري (Business management): فرآيندي است که در آن دانشها و بينشهاي جديدي که در هوش تجاري ايجاد مي شوند، در عمليات تجاري روزانه در سرتاسر سازمان معرفي و اجرا مي شوند، فرآیندهای مديريت تجاري تصميمات تاکتيکي که يک سازمان اتخاذ مي کند را در بر مي گيرد و ارزش فوق العاده زیادی برای سازمان دارند و هر میزان که استقرار هوش تجاری در سازمان به بهینه شدن تصمیمات در این سطح کمک کند، ارزش های این نوع سیستم ها بیشتر و بیشتر مشخص خواهد شد.  

در این معماری دو مولفه اصلی وجود دارد که عبارتند از :

5.1.                    دريافت داده (Getting Data In):

 شامل فرآيندها و پايگاه هاي داده اي است كه درگير اخذ داده از سيستم هاي اجرائي، يكپارچه سازي آن، پاكسازي آن و قرار دادن آن در يك پايگاه داده براي استفاده آسان هستند و عبارتند از:

·         پايگاه هاي داده سيستم اجرايي (The Operational System Databases)،

·         پايگاه داده تحليلي (Data warehouse)،

·         انباره داده اجرائي (The Operational Data Store)،

·         اخذ دانش (Data Acquisition)

5.2.                   پس دادن اطلاعات(Getting Information Out) :

 شامل فرآيندها و پايگاه هاي داده اي است که درگير ارائه هوش تجاري به مشتريان تجاري نهايي يا تحليل گران اند و عبارتند از:

·         پايگاه هاي داده تحليلي خرد (Data Marts)،

·         پايگاه هاي داده عملِياتي خرد (Oper Marts)،

·         داده رساني  .(Data delivery)

5.3.                  مراحل استقرار هوش تجاری [11]

1- آماده­سازي (ETL)

        استخراج داده·

        پاك­سازي داده·

        بايگاني كردن داده قبل و بعد از پاك­سازي·

2- يكپارچگي(Integrity)

        تطبيق داده و يكپارچگي چند منبع داده­اي·

3- تحليل سطح بالا

        محاسبه ديدهاي تحليلي از ديدهاي پايه - ايجاد پارامترهاي تحليلي·

4- خصوصي­سازي

        استخراج و خصوصي سازي اطلاعات - ايجاد پايگاه داده· تحليلي خاص

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

باید توجه داشت که تقریبا از مرحله اول نیازمند وجود Repository  برای ذخیره meta data ها هستیم. همچنین ممکن است در مراحل آخر نیازمندی جدیدی برای مرحله ETL[3] پیش آید که در این صورت نیازمند انجام مجدد مراحل اولیه هستیم.

6.     دلایل شکست پروژه های هوش تجاری

پروژه های هوش تجاری، از آنجایی که بیش از همه انواع پروژه های فناوری اطلاعات در سازمان ها وابسته به لایه های زیر ساختی میباشد، توجه بیشتری را متوجه زیرساخت ها میکند. همچنین با توجه به اینکه خروجی استقرار هوش تجاری در سازمان ها بصورت مشخص و واضح قابل سنجش و اندازه گیری نیست، اغلب مدیران را دچار مشکلاتی میکند. با بررسی اخیری که توسط شرکت خدماتی و مشاوره KPMG انجام شده، 6 عامل اصلی شکست پروژه های فناوری اطلاعات به صورت زیر بیان شده است:[2]

1-     برنامه ریزی ضعیف پروژه  2- طرح توجیهی ضعیف 3- عدم درگیری و پشتیبانی مدیریت ارشد4- عدم درگیری کاربر 5- تازه بودن تکنولوژی برای سازمان 6- عدم از خود دانستن پروژه

تمام موارد فوق برای پروژه های هوش تجاری وجود دارد و باید مورد توجه قرار گیرد بویژه بحث تازه بودن تکنولوژی برای سازمان، اما طی تجربیات و پژوهش هایی که توسط شرکت های فعال در این حوزه انجام شده، موارد اجرایی که منجر به شکست پروژه های هوش تجاری شده اند را نیز میتوان در ۸ مورد اصلی دسته بندی کرد:[3]

6.1.                     ﻋﺪﻡ ﺣﻤﺎﻳﺖ ﻣﺪﻳﺮﻳﺖ ﺍﺭﺷﺪ:

ﺩﺭ ﺻــﻮﺭﺗﻲ ﻛــﻪ ﻣــﺪﻳﺮﻳﺖ ﻣﺮﺍﺣﻞ ﺍﺳﺘﻘﺮﺍﺭ ﺍﻧﺒﺎﺭ ﺩﺍﺩﻩ ﻭ ﻫــﻮﺵ ﺗﺠ ﺎﺭﻱ ﺭﺍ ﺩﺭﻙ ﻧﻜﻨﺪ ﻭ ﻳــﺎ ﺍﺯ ﻣﺰﺍﻳ ﺎﻱ ﺁﻥ ﺑــﻲﺧﺒﺮ ﺑﺎﺷﺪ، ﺁﻥ ﭼﻨﺎﻥ ﻛــﻪ ﻻﺯﻡ ﺍﺳﺖ ﺑﻪ ﭘﺮﻭﮊﻩ ﺍﻫﻤﻴـﺖ ﺩﺍﺩﻩ ﻧﻤـﻲﺷـﻮﺩ ﻭ ﭘـﺮﻭﮊﻩ ﻣـﺪﺍﻡ ﺑـﻪ ﺗﻌﻮﻳـﻖ ﻣـﻲﺍﻓﺘـﺪ. ﻣـﺪﻳﺮﺍﻥ ﺍﺟﺮﺍﻳﻲ ﺑﺎﻳــﺪ ﺑﺪﺍﻧﻨﺪ ﻛــﻪ ﺍﺳﺘﻘﺮﺍﺭ ﻫــﻮﺵ ﺗﺠﺎﺭﻱ ﻓﻘﻂ ﺷــﺎﻣﻞ ﻣﺮﺍﺣﻞ ﺍﺳﺘﻘﺮﺍﺭ ﻓﻨﻲ ﻧﻤﻲﺷــﻮﺩ ﻭ ﻣﻤﻜﻦ ﺍﺳﺖ ﻣﻨﺠﺮ ﺑــﻪ ﺗﻐﻴﻴﺮ ﺩﺭ ﻓﺮﺍﻳﻨﺪﻫﺎ ﻭ ﻛﺴﺐﻭﻛﺎﺭ ﺳــﺎﺯﻣﺎﻥ ﮔــﺮﺩﺩ.  ﺯﻳﺮﺍ ﺑﺮﺍﻱ ﺍﻳﻨﻜﻪ ﺳـﺎﺯﻣﺎﻥ ﺑﺘﻮﺍﻧـﺪ ﺍﺯ ﺗﻤـﺎﻡ ﻣﺰﺍﻳـﺎﻱ ﻫـﻮﺵ ﺗﺠـﺎﺭﻱ ﺑﻬـﺮﻩﻣﻨـﺪ ﮔـﺮﺩﺩ ﺑﺎﻳـﺪ ﺍﺯﺗﻤﺎﻡ ﺧﺮﻭﺟﻲﻫﺎﻱ ﻫﻮﺷﻤﻨﺪﻱ ﺍﺳﺘﻔﺎﺩﻩ ﻛﻨﺪ ﻭ ﺭﻭﺵ ﺍﺩﺍﺭﻩ ﻛﺴﺐﻭﻛﺎﺭ ﺭﺍ ﺗﻐﻴﻴﺮ ﺩﻫﺪ. 

6.2.                    ﺷﻨﺎﺳﺎﻳﻲ ﺿﻌﻴﻒ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﺳﺎﺯﻣﺎﻥ:

ﻳﻜﻲ ﺍﺯ ﻣﻬﻢﺗــﺮﻳﻦ ﮔــﺎﻡﻫــﺎ، ﻛــﻪ ﻏﺎﻟﺒ ﺎ ﻧﺎﺩﻳﺪﻩ ﮔﺮﻓﺘﻪ ﻣــﻲﺷــﻮﺩ، ﻣﺮﺣﻠﻪ ﺟﻤﻊﺁﻭﺭﻱ ﻧﻴﺎﺯﻣﻨﺪﻱﻫــﺎﻱ ﻛﺴﺐﻭﻛﺎﺭ ﺍﺳﺖ.

ﺑﺴــﻴﺎﺭﻱ ﺍﺯ ﺳــﺎﺯﻣﺎﻥﻫــﺎ ﺑﻌــﺪ ﺍﺯ ﺍﺗﻤــﺎﻡ ﻣﻌﻤــﺎﺭﻱ انبار داده، ﺍﺯ ﻛــﺎﺭﺑﺮﺍﻥ ﻧﻬــﺎﻳﻲ ﺟﻬــﺖ ﻧﻈﺮﺳــﻨﺠﻲ ﺍﺭ ﻧﺘــﺎﻳﺞ ﻃــﺮﺡ ﺩﻋــﻮﺕ ﻣـﻲﻛﻨﻨـﺪ، ﺩﺭ ﺣﺎﻟﻴﻜـﻪ ﻧﻈـﺮ ﺍﻓـﺮﺍﺩ ﻣﻲﺑﺎﻳﺴـﺖ ﻗﺒـﻞ ﺍﺯ ﻣﻌﻤـﺎﺭﻱ ﻭ ﻃﺮﺍﺣـﻲ انبار داده ﮔﺮﻓﺘﻪ ﻣــﻲﺷــﺪ. ﺑــﻪ ﻣﻨﻈﻮﺭ ﺟﻤـﻊﺁﻭﺭﻱ ﻧﻴﺎﺯﻣﻨـﺪﻱﻫـﺎ ﺩﺭ ﻓـﺎﺯ ﺷــﻨﺎﺧﺖ ﭘــﺮﻭﮊﻩ، ﺩﺭﮔﻴــﺮ ﻛــﺮﺩﻥ ﻛﺎﺭﺑﺮﺍﻥ، ﺍﺯ ﺍﻣـﻮﺭ ﺑـﻲﭼـﻮﻥﻭﭼـﺮﺍ ﺟﻬـﺖ ﺗﻀـــﻤﻴﻦ ﺑـــﺮﺍﻱ ﭘـــﻲ ﺑـــﺮﺩﻥ ﺑـــﻪ ﻧﻴﺎﺯﻣﻨـﺪﻱﻫــﺎﻱ ﻭﺍﻗﻌﻲ ﻛــﺎﺭﺑﺮﺍﻥ ﺍﺳﺖ.

6.3.                   ﻃﺮﺍﺣﻲ ﺿﻌﻴﻒ:

ﮔــﺎﻡ ﮐﻠﻴﺪﻱ ﺑﻌﺪﻱ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﻫــﻮﺵ ﺗﺠﺎﺭﻱ ﺍﺳﺖ. ﻧﮑﺘــﻪ ﻣﻬﻢ ﺍﻳﻦ ﺍﺳﺖ ﮐــﻪ ﺍﺯ ﺍﻓﺮﺍﺩﻱ ﺍﺳ ﺘﻔﺎﺩﻩ ﺷــﻮﺩ ﮐــﻪ ﺩﺭ ﺍﻳﻦ ﺯﻣﻴﻨﻪ ﺗﺠﺮﺑﻪ ﺩﺍﺭﻧﺪ. ﺑﺎﻳﺪ ﺍﺯ ﻃﺮﺍﺣﺎﻥ ﻭ ﺗﻮﺳﻌﻪﺩﻫﻨﺪﮔﺎﻧﻲ ﺍﺳﺘﻔﺎﺩﻩ ﺷــﻮﺩ ﮐــﻪ ﺩﺍﺭﺍﻱ ﺁﻣﻮﺯﺵﻫــﺎﻱ ﻻﺯﻡ ﺑــﺮﺍﻱ ﺍﻳﺠﺎﺩ انبار داده ﻫﺴﺘﻨﺪ ﻭ ﺗﻨﻬﺎ ﺗﺠﺮﺑﻪ ﺍﻳﺠﺎﺩ ﭘﺎﻳﮕﺎﻩ ﺩﺍﺩﻩ ﮐــﺎﻓﻲ ﻧﻴﺴﺖ. ﺯﻳﺮﺍ ﻓﺮﺍﻳﻨﺪ انبار داده ﺷــﺎﻣﻞ ﺍﺳﺘﺨﺮﺍﺝ ﺩﺍﺩﻩﻫــﺎ ﺍﺯ ﻳــﮏ ﻳــﺎ ﭼﻨﺪ ﺑﺮﻧﺎﻣﻪ ﻣﺮﮐﺰﻱ ﻭ ﺗﺒﺪﻳﻞ ﺩﺍﺩﻩﻫــﺎ ﺑــﻪ ﻓﺮﻣﺘﻲ ﻗﺎﺑﻞﺍﺳﺘﻔﺎﺩﻩﺗــﺮ ﺍﺳﺖ.

6.4.                   ﻓﻘﺪﺍﻥ ﺁﻣﻮﺯﺵ:

ﺑﻌـــﺪ ﺍﺯ ﺗﮑﻤﻴـﻞ انبار داده ، ﻣﻮﻓﻘﻴـﺖ ﺑـــﻪ ﺍﻳـﻦ ﺑﺴـــﺘﮕﻲ ﺩﺍﺭﺩ ﮐـــﻪ انبار داده ﺑـــﺮﺍﻱ ﺳـــﺎﺯﻣﺎﻥ ﭼﮕﻮﻧــﻪ ﺭﻭﻧﻤــﺎﻳﻲ ﺧﻮﺍﻫــﺪ ﺷــﺪ. ﺑﺴــﻴﺎﺭﻱ ﺍﺯ ﺷــﺮﮐﺖﻫــﺎ ﺩﺭ ﺍﻳــﻦ ﮔــﺎﻡ ﻣﺸــﮑﻞ ﺩﺍﺭﻧــﺪ ﻭ ﻣﻌﻤﻮﻻ ﺍﻳﻦ ﺑﺎﻋﺚ ﻣــﻲﺷــﻮﺩ ﮐــﻪ ﺍﺳــﺘﻘﺮﺍﺭ انبار داده ﺑــﻪ ﺷﮑﺴــﺖ ﺑﻴﻨﺠﺎﻣــﺪ. ﺍﺻــﻠﻲﺗــﺮﻳﻦ ﺩﻟﻴـﻞ ﮐـﻪ ﺑـﻪ ﻧﻈـﺮ ﻣـﻲﺭﺳـﺪ، ﻓﻘـﺪﺍﻥ ﺁﻣﻮﺯﺵﻫــﺎﻱ ﮐــﺎﻓﻲ ﺍﺯ ﺳــﻮﻱ ﺷــﺮﮐﺖ ﺑــﺮﺍﻱ ﮐــﺎﺭﺑﺮﺍﻥ ﺍﺳــﺖ. ﺑﺠــﺎﻱ ﺁﻣــﻮﺯﺵ ﺁﻥﻫــﺎ ﺑــﺎ ﺟﺰﺋﻴﺎﺕ ﺩﻗﻴﻖ، ﺑــﻪ ﻳـﮏ ﻣــﺮﻭﺭ ﺍﺟﻤﺎﻟﻲ ﺍﮐﺘﻔﺎ ﻣـﻲﮐﻨﻨﺪ.

6.5.                   ﻋﺪﻡ ﻣﻮﻓﻘﻴﺖ ﺩﺭ ﮔﺴﺘﺮﺵ ﺩﺍﺩﻥ ﺑﻪ ﻭﺳﻴﻠﻪ data mart ﻫﺎ:

ﺑﻌﺪ ﺍﺯ ﺍﻳﻦ ﮐﻪ انبار داده ﺍﻭﻟﻴﻪ ﺳـﺎﺧﺘﻪ ﺷـﺪ، ﺑـﻪ ﻧﻈـﺮ ﻣـﻲﺭﺳـﺪ ﮐـﻪ ﮐـﺎﺭ ﺗﻤـﺎﻡ ﺷـﺪﻩ ﺍﺳـﺖ. ﻣﻌﻤـﻮﹰﻻ ﻣﺮﺣﻠـﻪ ﺑﻌـﺪ ﮐـﻪ ﻣﺸـﺨﺺ ﮐﺮﺩﻥ ﻳﮏ ﻃﺮﺡ ﺟﻬـﺖ ﺍﺳـﺘﻔﺎﺩﻩ ﺍﺯ ﺩﺍﺩﻩﻫـﺎﻱ ﺩﺭﻭﻥ انبار داده ﺍﺳـﺖ،ﻓﺮﺍﻣـﻮﺵ ﻣـﻲﺷـﻮﺩ. ﺗﻮﺻـﻴﻪ ﻣـﻲﺷـﻮﺩ ﮐـﻪ ﺑـﺮﺍﻱ ﺗﺴـﻬﻴﻞﺍﻧﺠـﺎﻡ ﻭﻇـﺎﻳﻒ ﮐـﺎﺭﺑﺮﺍﻥ ﻧﺴـﺒﺖ ﺑـﻪ ﺳـﺎﺧﺖ ﻫﻤﺒﺴـﺘﻪﻫـﺎ ﻳـﺎ data mart ﻫـﺎ ﺍﻗـﺪﺍﻡ ﺷـﻮﺩ. data mart ﻫـﺎ ﻣـﻲﺗﻮﺍﻧﻨـﺪ ﺑﺮﺍﻱ ﺳـﺎﺧﺖ ﻳـﮏ ﻣـﺪﻝ ﺑﺴـﻴﺎﺭ ﺳـﺎﺩﻩﺷـﺪﻩﺗـﺮ ﺍﺯ ﺩﺍﺩﻩﻫـﺎ ﺑـﻪ ﮐـﺎﺭ ﺭﻭﻧـﺪ. data mart ﻣـﻲﺗﻮﺍﻧـﺪ ﺩﺍﺭﺍﻱ ﺧﻼﺻـﻪﺳـﺎﺯﻱﻫـﺎ، ﻣﺤﺎﺳﺒﺎﺕ ﻭ ﺗﻐﻴﻴﺮ ﻧــﺎﻡ ﺩﺍﺩﻩﻫــﺎ ﺑﺎﺷﺪ، ﺑــﻪ ﻧﺤﻮﻱ ﮐــﻪ ﮐــﺎﺭﺑﺮﺍﻥ ﺭﺍﺣﺖﺗــﺮ ﺑﺘﻮﺍﻧﻨﺪ ﺑــﻪ ﺍﻃﻼﻋﺎﺕ ﻣــﻮﺭﺩ ﻧﻴﺎﺯﺷﺎﻥ ﺩﺳﺘﺮﺳﻲ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻨﺪ. ﺍﺯ ﺁﻧﺠﺎﻳﻲ ﻛــﻪ data mart ﻫــﺎ ﺩﺳﺘﺮﺳﻲ ﻣﻨﺎﺳﺐﺗــﺮ ﺑــﻪ ﺍﻃﻼﻋﺎﺕ ﺑــﺮﺍﻱ ﻛــﺎﺭﺑﺮﺍﻥ ﻓــﺮﺍﻫﻢ ﻣــﻲﻛﻨﻨﺪ ﻭ ﺑﺎﻋﺚ ﻣــﻲﺷــﻮﺩ ﻛــﻪ ﺣﺠﻢ ﺑــﺎﺭ ﺩﺍﺩﻩﻫــﺎ ﺑــﺮ ﺭﻭﻱ انبار داده ﻛــﺎﻫﺶ ﻳﺎﺑﺪ، ﻟــﺬﺍ ﻭﺟﻮﺩ ﺁﻧﻬﺎ ﺑــﺮﺍﻱ ﺍﻓﺰﺍﻳﺶ ﻛــﺎﺭﺍﻳﻲ ﺿــﺮﻭﺭﻱ ﻣــﻲﻧﻤﺎﻳﺪ. ﺩﺭ ﻧﺘﻴﺠﻪ ﻓﻘﻘﺪﺍﻥ date mart ﻫــﺎ ﻳــﺎ ﻋــﺪﻡ ﻃﺮﺍﺣﻲ ﻣﻨﺎﺳﺐ ﺁﻥﻫــﺎ ﻣــﻲﺗﻮﺍﻧﺪ ﭘــﺮﻭﮊﻩ ﺍﺳﺘﻘﺮﺍﺭ انبار داده ﺭﺍ ﺑــﺎ ﻣﺸﻜﻼﺕ ﻣﺘﻌﺪﺩﻱ ﻣﻮﺍﺟﻪ ﺳﺎﺯﺩ. 

6.6.                    ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﺑﺰﺍﺭ ﻏﻠﻂ:

ﺍﺯ ﺩﻻﻳﻞ ﺩﻳﮕﺮ ﺍﺳﺘﻘﺮﺍﺭ ﻧــﺎﻣﻮﻓﻖ ﺍﻧﺒﺎﺭﻩ ﺩﺍﺩﻩ ﻭ ﻫــﻮﺵ ﺗﺠﺎﺭﻱ ﺩﺭﺳــﺎﺯﻣﺎﻥﻫــﺎ ﺍﻧﺘﺨﺎﺏ ﺍﺑﺰﺍﺭ ﻧﺎﻣﻨﺎﺳﺐ ﻣــﻲﺑﺎﺷﺪ. ﺑــﺮﺍﻱ ﮐﺎﺭﺑﺮﺩﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺍﺑﺰﺍﺭﻫﺎﻱ ﻣﺘﻔﺎﻭﺗﻲ ﺩﺭ ﺍﺧﺘﻴﺎﺭ ﺍﺳﺖ. ﻣــﻲﺗــﻮﺍﻥ ﺑــﻪ ﻋﻨﻮﺍﻥ ﻣﺜــﺎﻝ ﺑــﻪ ﺍﺑﺰﺍﺭﻫﺎﻱ ETL، ﮔــﺰﺍﺭﺵﮔﻴﺮﻱ، ﺩﺍﺩﻩﮐــﺎﻭﻱ، OLAP ﻭ ﺍﺑﺰﺍﺭﻫﺎﻱ web-based ﻧﻈﻴﺮ ﺩﺍﺷﺒﻮﺭﺩﻫﺎ ﺍﺷﺎﺭﻩ ﮐــﺮﺩ. ﻧﮑﺘــﻪ ﻣﻬﻢ ﺍﻳﻦ ﺍﺳـﺖ ﮐـﻪ ﺑﺎﻳـﺪ ﺑـﺎ ﺩﻗـﺖ ﻭ ﺑﺮﺭﺳـﻲ ﺩﺭ ﻧﻴﺎﺯﻫـﺎﻱ ﮐـﺎﺭﺑﺮﺍﻥ، ﻣﺠﻤﻮﻋﻪ ﺍﺑﺰﺍﺭﻱ ﺍﻧﺘﺨﺎﺏ ﺷــﻮﺩ ﮐــﻪ ﺑــﻪ ﻋﻨﻮﺍﻥ ﻳــﮏ ﻣﮑﻤــﻞ ﺩﺭ ﺍﻧﺠﺎﻡ ﮐﺎﺭﻫﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ. ﺩﺭ ﺍﻳـﻦ ﺭﺍﺳـﺘﺎ ﭘﻴﺸـﻨﻬﺎﺩ ﻣـﻲﮔـﺮﺩﺩ ﺳـﺎﺯﻣﺎﻥ ﺩﺭ ﺍﺑﺘـﺪﺍﻱ ﭘـﺮﻭﮊﻩ ﻭ ﺑﻌﺪ ﺍﺯ ﺷﻨﺎﺧﺖ ﻧﻴﺎﺯﻣﻨـﺪﻱﻫـﺎ ﻭ ﻣﺤـﺪﻭﺩﻩ ﺍﺟـﺮﺍﻱ ﻃـﺮﺡ ﺍﻗـﺪﺍﻡ ﺑـﻪ ﺍﻧﺘﺨـﺎﺏ ﺍﺑﺰﺍﺭﻫـﺎﻱ ﻣﻨﺎﺳـﺐ ﺳـﺎﺯﻣﺎﻥ

6.7.                   ﺩﺍﺩﻩﻫﺎﻱ ﺑﻲﻛﻴﻔﻴﺖ:

ﻳﻜﭙﺎﺭﭼﻪﺳـﺎﺯﻱ ﺩﺍﺩﻩﻫـﺎ ﺑﺎﻋـﺚ ﻣـﻲﺷـﻮﺩ ﻛـﻪ ﺁﻧﭽـﻪ ﻛـﻪ ﺩﺭ ﭘـﺎﺋﻴﻦﺗـﺮﻳﻦ ﺳـﻄﻮﺡ ﺳﺎﺯﻣﺎﻥ ﺍﺗﻔﺎﻕ ﻣـﻲﺍﻓﺘـﺪ ﻣﺸـﺨﺺ ﺷـﻮﺩ. ﮔﺰﺍﺭﺷـﺎﺗﻲ ﻛـﻪ ﻧﺘـﺎﻳﺞ ﻏﻠـﻂ ﻳـﺎ ﻧـﺎﻗﺺ ﺗﻮﻟﻴﺪ ﻣﻲﻛﻨﻨـﺪ ﺑـﻪ ﺍﺳـﺘﻘﺮﺍﺭ هوش تجاری ﻟﻄﻤـﻪ ﻭﺍﺭﺩ ﻣـﻲﻛﻨـﺪ. ﺭﺍﻩﺣـﻞ ﺍﻳـﻦ ﻣﺸـﻜﻞ ﻧﻈـﺎﺭﺕ ﺑﺮ ﺩﺍﺩﻩﻫﺎ ﻭ ﻧﻈﺎﺭﺕ ﺑﺮ ﻛﺴﺐﻭﻛﺎﺭ ﺍﺳﺖ. بر خلاف عقیده بسیاری از کارشناسان که هوش تجاری را یک پروژه زودبازده قلمداد میکنند، به نظر میرسد استقرار هوش تجاری یک پروژه به شدت متکی به زیرساخت هاست و بویژه در بخش مدیریت دانش و اطلاعات سازمان نیازمند توجه وسرمایه گذاری برای تامین داده های با کیفیت است.

 

6.8.                   ﻗﺎﺋﻞ ﺷﺪﻥ ﻳﮏ نقطه ﭘﺎﻳﺎﻥ ﺑﺮﺍﻱ استقرار هوش تجاری:

ﺑــﺮﺍﻱ ﺍﺳﺘﻘﺮﺍﺭ ﻫــﻮﺵ ﺗﺠﺎﺭﻱ ﺩﺭ ﺳــﺎﺯﻣﺎﻥ ﻧﺒﺎﻳﺪ ﭘﺎﻳﺎﻧﻲ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺖ، استقرار هوش تجاری در واقع یک پروژه نیست، یک برنامه است. به این معنی که فاز اول برنامه استقرار هوش تجاری در سازمان میتواند بصورت پروژه استقرار هوش تجاری باشد ولی بعد از پایان پروژه، باید بصورت مداوم روی داده های ورودی، فرآیند های انبار داده و داده کاوی و سایر ابزارهای هوش تجاری کار شود تا همواره بهترین و صحیح ترین خروجی را برای کاربران مهیا سازد.

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

7.    نتیجه گیری

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

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

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

مراجع

[1]      آرش خسروی ، ضرورت بكارگيري هوش سازماني در سازمان ها، مرکز تحقيقات کامپيوتری علوم اسلامی

[2]      بررسی دلایل ناکامی پروژه های فناوری اطلاعات

[3]      ﻋﻮﺍﻣﻞ ﻣﻬﻢ ﺟﻠﻮﮔﻴﺮﻱ ﺍﺯ ﺷﻜﺴﺖ ﭘﺮﻭﮊﻩﻫﺎﻱ ﺍﻧﺒﺎﺭﻩ ﺩﺍﺩﻩ ﻭ ﻫﻮﺵ ﺗﺠﺎﺭﻱ، خبرنامه شرکت مگفا بهمن ۱۳۸۷

 

[4]      Data Integration and Management Solutions,Manjunath. B. Assistant Professor, manjunath_b_73@yahoo.com

[5]      Business Intelligence – Past, Present, and Future ,Hugh J. Watson Department of MIS, University of Georgia , nov 2009

[6]      Assessing BI Readiness: A Key to BI ROI, As featured in the Summer 2004 issue of Business Intelligence Journal ,Steve Williams , Nancy Williams

[7]      Knowledge management and business intelligence: the importance of integration , Richard T. Herschel and Nary E. Jones

 

[8]      The integration of business intelligence and knowledge management, W F Cody; J T, Kerulen; V Krishna; W S Spangler, IBM Systems Journal; 2002; 41, 4; ABI/INFORM Global, pg. 697

[9]      http://www.inmoncif.com/home/

 

 

 

[1] سید محمود شجاعی کیاسری.

آدرس پست الكترونيكي: sm.shojaei@mail.sbu.ac.ir

[2] علیرضا طالب پور ، دکتراي الکترونيک (پردازش تصوير، دانشگاه Surrey انگلستان) – عضو هيئت علمی و استاد دانشگاه شهید بهشتی

 

[3] Extract, Transform, Load

 

ارسال شده توسط احمد محمدی | 23 11, 2013 | بازدید‌ها (992)
 
پایگاه داده‌ها [1] یا پایگاه اطلاعاتی، ذخیره‌ای از پرونده‌های [2] حاوی اطلاعات گوناگون و مرتبط به‌صورت یکپارچه [3] و مبتنی بر ساختار واحدی است که امکان جست‌وجو و بازیابی سریع اطلاعات را توسط رایانه پدید می‌آورد. پایگاه اطلاعاتی به‌گونه‌ای شکل می‌گیرد که تسهیلاتی را برای ذخیره، درج، حذف، اصلاح، روزآمدسازی، و بازیابی اطلاعات پرونده‌ها توسط یک یا چند کاربر به‌صورت اشتراکی و همزمان فراهم سازد. غالبآ مدارک موجود در پایگاه اطلاعاتی ارائه‌دهنده اطلاعات همه پدیده‌های فیزیکی مانند کتاب یا سایر متون منتشر شده مانند آثار هنری، اشیای قدیمی، یا حتی اطلاعات مربوط به یک فرد (مانند مدارک استخدامی یا اسناد پزشکی افراد) را در بر می‌گیرد. به عبارت دیگر این اطلاعات می‌تواند، داده‌هایی کامل از این اسناد باشد. پایگاه اطلاعاتی را می‌توان بر روی رسانه‌هایی مانند لوح سخت [4]، لوح لرزان [5]، لوح یا نوار مغناطیسی [6]، لوح نوری [7]، یا هر ابزار دیگر ذخیره کرد.

تاریخچه
در اواخر دهه 1960 و اوایل دهه 1970 ایجاد نظام یکپارچه مدیریت اطلاعات به‌عنوان هدفی واحد مطرح شد و پایگاه‌های اطلاعاتی با این قصد به‌وجود آمد که بتواند امکان ترکیب پرونده‌های جدا از هم، ایجاد ارتباط، مدیریت، و استفاده مشترک از داده‌ها را فراهم سازد. در نتیجه، افزونگی اطلاعات تا حدودی کاهش یافت، صحت و یکپارچگی اطلاعات ذخیره شده تا حدی تأمین شد، و امکان دسترسی مستقیم به اطلاعات و بازیابی آن، به‌کمک چند کلید، و گزارش‌گیری ساده نیز فراهم گردید.
در دهه 1970، به‌سبب تراکم اطلاعات ذخیره شده و ضرورت بازیابی اطلاعات مورد نیاز، یکپارچگی اطلاعات و به حداقل رساندن تکرار آن در پایگاه‌های اطلاعاتی اهمیت بیشتری یافت و موجب شد که در تهیه برنامه‌های کاربردی، روش‌های کارآمدتری نسبت به ذخیره و بازیابی اطلاعات ابداع شود و پایگاه‌های اطلاعاتی امروزی شکل گیرد. این پایگاه‌ها دسترسی چندجانبه به اطلاعات، کنترل اطلاعات، سازماندهی مجدد، ارتباط میان عناصر اطلاعاتی، امنیت اطلاعات، تهیه گزارش‌های پیچیده، و تهیه برنامه‌های کاربردی مستقل از داده را امکان‌پذیر ساخت. از دهه 1980، با توسعه دانش در زمینه‌هاینظام‌های خبره و هوش مصنوعی [8] [9]، تحولی در نظام ذخیره و بازیابی اطلاعات به‌وجود آمد.
پایگاه‌های اطلاعاتی با استفاده از منطق صوری، نظام خبره، هوش مصنوعی، و زبان طبیعی امکان استنتاج منطقی از داده‌ها را به کاربران می‌دهند؛ و بدین‌ترتیب، فن‌آوری نوین سبب ایجاد پایگاه‌های دانش [10] شده است.
در ایران نیز از سال 1362، تلاش‌هایی به‌منظور ایجاد پایگاه‌های اطلاعاتی خودکار آغاز شد (6: 1-3) لیکن تا اواخر دهه 60 نتیجه ملموسی حاصل گردید. مراکز پایگاه‌های اطلاعاتی ایران در حال حاضر به‌طور عمده حاصل تلاش‌ها و کوشش‌هایی است که از سال 1368 آغاز گردیده و تاکنون ادامه داشته است.

اجزای پایگاه اطلاعاتی [11]
محیط پایگاه اطلاعاتی از اجزائی چون داده‌ها، سخت‌افزار، نرم‌افزار، و کاربران تشکیل شده است. هر پایگاه اطلاعاتی مجموعه‌ای از داده‌هاست که به‌صورت یکپارچه مورد استفاده قرار می‌گیرد. داده‌های هر پایگاه میان کاربران مختلف به اشتراک گذاشته می‌شود و از داده واحدی ممکن است برای مقاصد مختلف استفاده گردد.
از سوی دیگر، پایگاه اطلاعاتی برای استقرار و اجرا نیاز به تجهیزات سخت‌افزاری نظیر دستگاه‌های ذخیره‌سازی، پردازش‌گرها [12]، و سخت‌افزارهای ارتباطی [13] دارد. در ضمن، هر پایگاه اطلاعاتی دارای لایه‌ای نرم‌افزاری به نام "نظام مدیریت پایگاه اطلاعاتی" [14] است که ارتباط میان استفاده‌کنندگان و اطلاعات ذخیره شده بر روی دستگاه‌ها را برقرار می‌سازد. از طریق این نرم‌افزار می‌توان به اطلاعات پایگاه دست یافت.
کاربران پایگاه‌های اطلاعاتی را سه گروه تشکیل می‌دهند:
1) برنامه‌سازان کاربردی [15] که پایگاه اطلاعاتی را طراحی می‌کنند و، با استفاده از داده‌های موجود در پایگاه، آن را توسعه می‌دهند و برنامه‌های جدیدی را تهیه می‌کنند؛
2) استفاده‌کنندگان نهایی که با استفاده از پایگاه‌ها می‌توانند به اطلاعات مورد نیاز دست یابند و از آنها استفاده کنند؛
3) مدیران پایگاه داده‌ها که کار کنترل پایگاه اطلاعاتی را برعهده داشته و معمولا از توان بالایی برای تجزیه و تحلیل نیازها و تصمیم‌گیری در مورد روش ذخیره، دسترسی، بازیابی، و کنترل اطلاعات برخوردارند.

عناصر پایگاه اطلاعاتی [16]
هر پایگاه اطلاعاتی از عناصری شامل واژگان داده‌ها [17]، نوع داده‌ها، دامنه داده‌ها [18]، حوزه داده‌ها (فیلد)، پیشینه (رکورد)ها، رابطه‌ها [19]، و نمایه‌ها تشکیل شده است. واژگان داده‌ها مجموعه‌ای مرتب از پرونده‌ها، نمایه‌ها، نگاره‌ها، و اقلام اطلاعاتی برنامه کاربردی است که برای برنامه‌نویس سرعت و سهولت زیادی را در نوشتن برنامه‌های پایگاه اطلاعاتی ایجاد می‌کند. نوع داده‌های هر حوزه (فیلد) نیز مشخص و تعریف می‌شود تا برنامه کاربردی بتواند آنها را در هر زمان و به هر شکل پردازش و بازیابی کند. متداول‌ترین نوع داده‌ها شامل داده‌های مربوط به متن، عدد، تاریخ، تصویر، و یادداشت است.
داده‌های متن از حروف، اعداد، و نشانه‌ها تشکیل شده است. داده عددی شامل اعداد صحیح، حقیقی، و اعشاری است. داده تاریخ به‌گونه‌ای ذخیره می‌شود که برنامه کاربردی بتواند آن را تشخیص دهد. داده یادداشت برای ذخیره متن‌های طولانی مانند چکیده‌ها یا مقالات به‌کار می‌رود.
حوزه‌ها فضاهایی هستند که داده‌های ذخیره شده در پایگاه اطلاعاتی را در خود جای می‌دهند. نام، نوع، و اندازه هر حوزه (فیلد) در پایگاه اطلاعاتی تعریف می‌شود و برای هر حوزه عنوانی متناسب با محتوای آن انتخاب می‌گردد. افزونگی در حوزه‌ها وجود ندارد، مگر برای حوزه‌هایی که، به عنوان کلید، ارتباط میان پیشینه‌ها (رکورد) را فراهم می‌سازند.
پیشینه‌ها مجموعه‌ای از حوزه‌ها هستند که درباره موضوعی خاص در ارتباطی منطقی قرار می‌گیرند. رابطه‌ها در پایگاه‌های اطلاعاتی این امکان را فراهم می‌کنند که پیشینه‌ها به‌گونه‌ای مورد نیاز سازماندهی شوند. به‌طور مثال، پیشینه اطلاعات کتابشناختی مدارک، که در فرایند فهرست‌نویسی مورد استفاده قرار می‌گیرد، با استفاده از رابطه می‌تواند در کارهای امانت یا سفارش مورد استفاده قرار گیرد. نمایه‌ها (شاخص‌ها) در پایگاه‌های اطلاعاتی عامل مهمی در ذخیره اطلاعات حوزه‌ها هستند و با وجود آنها برای بازیابی اطلاعات خاص نیازی به پیمایش سراسر پایگاه نیست، در نتیجه اطلاعات با سرعت بیشتری بازیابی می‌شود.

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

1. پایگاه اطلاعاتی تک پرونده [20]، که در آن اطلاعات از یک پرونده را در هر زمان ذخیره، سازماندهی، و بازیابی می‌کنند. در این پایگاه‌ها حوزه‌های مربوط به یک موضوع می‌تواند تکراری باشد و امکان حذف حوزه‌های زائد در پیشینه‌ها وجود ندارد، در نتیجه، افزونگی اطلاعات در این پایگاه‌ها بسیار زیاد است.

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

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

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

5. پایگاه اطلاعاتی شیی گرا [24]، که به‌منظور ایجاد نرم‌افزاری بهتر، کوچک‌تر، و بدون تناقض به‌وجود آمد و متشکل از مجموعه‌ای از شیی‌هاست. هر شیی دارای اطلاعات (ویژگی‌ها [25]) و برنامه‌ها (روش‌ها [26])یی است که می‌تواند اطلاعات درون شیی را پردازش کند. شیی نفوذناپذیر است، یعنی نمی‌توان برنامه درونی آن را تغییر داد. فقط از طریق پیام می‌توان با آن رابطه برقرار کرد. هر شییî، پس از دریافت پیام، آن را پردازش کرده و سپس پیام(های) مناسبی را ارسال می‌کند. در ساختار این پایگاه‌ها شیِی‌ها که دارای توانایی‌های مشترک هستند در رده واحدی قرار می‌گیرند و هر رده می‌تواند دارای زیر رده‌هایی باشد که از توانایی‌های رده بالاتر از خود نیز برخوردار است.

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

با رویکردی دیگر، پایگاه اطلاعاتی را می‌توان چنین طبقه‌بندی کرد:

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

2. پایگاه اطلاعاتی تمام متن [28]. این پایگاه شامل متن کامل منابع - نه فقط مشخصات ظاهری آنها است. متن کامل مقالات روزنامه‌ها و نشریات، قوانین، گزارش‌های فنی شرکت‌ها، پیام‌های گروه‌های مباحثه در اینترنت، و مکاتبات سازمان‌ها نمونه‌هایی از این‌گونه پایگاه‌ها هستند.

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

4. پایگاه اطلاعاتی ارجاعی [30]. این پایگاه می‌تواند شامل فهرست اشیاء نمایشی در یک موزه یا فهرست گیاهان یک ناحیه خاص باشد. همچنین این نوع پایگاه می‌تواند ارائه دهنده نکات خاصی باشد که در انواع دیگر پایگاه‌ها موجود نیست؛ مانند اطلاعاتی در مورد کوزه‌گری که نیازمند توصیف به‌وسیله شکل، ابعاد، رنگ، و تاریخ کوزه‌گری به‌طور کامل است.

5. پایگاه اطلاعاتی عددی و آماری [31]. این پایگاه عمدتآ شامل اطلاعات عددی است و آمار گوناگونی مانند اسناد فروش یا داده‌های علمی همچون خواص فیزیکی مواد را دربر می‌گیرد.

6. پایگاه اطلاعاتی توصیفی [32]. این نوع پایگاه نکاتی موجز با طیفی گسترده از توضیحاتی درباره نواحی جغرافیایی خاص، برنامه‌های ارائه شده توسط دانشگاه‌ها یا دانشکده‌ها، یا امکانات یک شرکت را دربر می‌گیرد.
بعضی از صفحات خانگی [33] موجود در اینترنت را می‌توان نمونه‌ای از پایگاه‌های اطلاعاتی توصیفی به‌شمار آورد. پایگاه‌های اطلاعاتی توصیفی شامل نکات اصلی متن (حاوی اطلاعات آماری و تصاویر متن) هستند، به همین سبب می‌توان آنها را جزو گروه پایگاه‌های اطلاعاتی تمام متن نیز برشمرد. پایگاه‌های اطلاعاتی توصیفی غالبآ به شکل الکترونیکی اسناد چاپی اشاره می‌کند. واژه کلی‌تر پایگاه‌های اطلاعاتی متنی [34] نیز می‌تواند شامل متن اصلی آثار داستانی باشد.

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

مآخذ:
1) خسروانی، جعفر. "بررسی وضعیت پایگاه‌های اطلاعاتی معاجم لفظی و موضوعی مرکز تحقیقات کامپیوتری علو اسلامی". پایان‌نامه کارشناسی ارشد کتابداری و اطلاع‌رسانی، دانشکده علوم تربیتی و روانشناسی، دانشگاه تهران، 1374؛
2) روحانی رانکوهی، محمدتقی. مقدمه‌ای بر پایگاه داده‌ها (بانک اطلاعاتی). {تهران}: جلوه، 1372؛
3) شورای عالی انفورماتیک کشور. دبیرخانه. ویژه‌نامه پایگاه داده‌ها: خبرنامه انفورماتیک. تهران: سازمان برنامه و بودجه، مرکز مدارک اقتصادی - اجتماعی و انتشارات، 1374؛
4) فرهنگ اصطلاحات کامپیوتری (Webster): شامل شرح 4500 اصطلاح کامپیوتری به‌همراه جدیدترین واژه‌های مربوط به PCها. "پایگاه اطلاعاتی"؛
5) فرهنگ کاربران کامپیوتر. ادیک باغداساریان. ذیل "پایگاه اطلاعاتی"؛
6) مرکز اسناد و مدارک علمی ایران. طرح پیشنهادی شبکه اطلاع‌رسانی علمی و صنعتی کشور. تهران، 1362؛
7) "Data base". The New Encyclopedia Britannica. 15th ed. Vol. 3: Micropaedia Ready Reference. PP. 896-897;
8) "atabase". Encyclopedia of Library and Information Science. Vol 51, P. 107;
9) Date, C.J. An Introductionto Data base Systems. Vol. 1. 5th ed. Reading, Ma: Addison - Wesley Publishing co., 1990;
10) Jacso, Peter; Lancaster, F.W. Database. Chicago: ALA, 1999;
11) Maryanski, F. "Data base Administrator". Encyclopedia of Computer Science and Engineering. PP. 440-441;
12) Moulton, lynda W. Data bases for Special Libraries: a Strotegic Guide to Information Management. London: Green Wood Press, 1991;
13) Olle, T.W. "Data base Management". Encyclopedia of Computer Science and Engineering. Vol. 1, P. 441-447;
14) Semsarzadeh, Gholam Ali. "New Developments in Conception of Application Software". Washington, D.C. 1997 (Poly Copy);
15) Vargo, Mary O. "Data base Computer". Encyclopedia of Computer Science 3 rd. ed. PP. 412-413.

پی نوشت:
[1]. Database
[2]. Files
[3]. Integrated
[4]. Hard disk
[5]. Floppy disk
[6]. Magnetic disk / Tape
[7]. Optical disk
[8]. Expert system
[9]. Artificial intelligence
[10]. Knowledge base
[11]. Database components
[12]. Processors
[13]. Communication hardware
[14]. Database Management System (DBMS)
[15]. Application programmer
[16]. Database clements
[17]. Data dictionary
[18]. Data domain
[19]. Relations
[20]. Flat-file database
[21]. Hierarchical database
[22]. Networked database
[23]. relational database
[24]. Object-oriented database
[25]. Properties
[26] Methods
[27]. Biblilgraphic databases
[28]. Full-text databases
[29]. Image database
[30]. Database referring to other physical objects
[31]. Numeric and statistical database
[32]. Descriptive database
[33]. Home page
[34]. Text database
[35]. Directories and other "reference sources" database
1 2 3  بعدي»

درباره من

  • 9163858398
  • احمد محمدی (کارشناس ارشد مدیریت فناوری اطلاعات و مهندس نرم افزار)

    مشاور و عضو کمیسیون نظارت و ارزشیابی سازمان نظام مهندسی رایانه ای خراسان رضوی

    بنیانگذار و مالک سایت های SEOparsian.com و SMSparsian.com

    جديدترين مقالات مرتبط با مدیریت فناوری اطلاعات

    ahmad.mohammadi.a@gmail.com

آخرين مطالب بروز شده