جديدترين مقالات مرتبط با مدیریت فناوری اطلاعات IT
ارسال شده توسط احمد محمدی | 8 12, 2013 | بازدید‌ها (1865)
پروژه ERP ايران خودرو
تعریف ERP
ERP مخفف Enterprise Recourse Planning بوده و از لحاظ لغوی به معنای برنامه ريزی جامع منابع يك سازمان مي باشد. در زير سه تعريف از ERP بیان شده است:
    يك راه حل مبتني بر فناوری اطلاعات است كه تمام منابع سازمان ) مواد اولیه ، ماشین آلات ، نیروی انساني و پول (را توسط يك سیستم به هم پیوسته با سرعت، دقت و كیفیت بالا در كنترل مديران سطوح مختلف قرار مي دهد تا مديران بتوانند بطور مناسب فرآيند برنامه ريزی و عملیات سازمان را مديريت نمايند.

    يك نگرش فناورانه و سیستماتیك برای مديريت موثرتر تمام منابع در يك سازمان است كه اين مديريت از طريق اتوماسیون و يكپارچه كردن تمام فرآيندها و در نتیجه بالا بردن كارايي سازمان ها اعمال مي شود.
    ERP  يك بسته كامل نرم افزاری كاربردی درون سازماني ، جامع و سازمان نگر ، ماژولار ، استاندارد و شامل يك مجموعه از ماژولهای يكپارچه ، آماده راه اندازی ، از پیش طراحي شده و از پیش مهندسي شده ولي قابل تنطیم و منعطف ،پیكر بندی بر اساس نیازهای پويای سازمانها مي باشد. اين راه حل كاملا انعطاف پذير ، فرايندگرا و اطلاعات محور مي باشد و شامل كلیه فعالیتها و فرايندهای اصلي و موثر در ايجاد ارزش افزوده سازمان مي باشد . فرايندهای از پیش تعريف شده در سیستم بر اساس بهترين تجارب دنیا ( (Best practiceاستخراج شده اند.

ضرورت نیاز به ERP در سازمان ها
    افزونگي حجم اطلاعات و نیاز به مدیریت اطلاعات به منظور یكپارچگي، امنیت و در دسترس بودن اطلاعات
    پیچیده شدن فرآیندهاي كاري و نیاز به استفاده از Best Practice هاي دنیا
    محدودیت منابع (4M : Material, Money, Machine, Man) و نیاز به برنامه ریزي منابع
    رقابت شدید نیازمند بستري است كه مدیران بتوانند به سرعت تصمیم گیري نمایند و این كار بدون داشتن اطلاعات به موقع، صحیح و دقیق امكانپذیر نیست. همچنین براي رقابت، نیاز به امنیت اطلاعات در سازمان كاملا ضروري است.
    افزایش فعالیتها و به طبع آن مدیریت سازمان نیازمند وجود سیستمي است كه به آنها كمك كند شرح وظایف هر شخص با توجه به فعالیتها شفاف گردد و از تداخل كاري و دوباره كاریها جلوگیري نماید.
    نیاز به مدیریت عملیاتي سازمان كه این سیستم ها امكان مونیتور كردن فعالیتها را براي مدیران سازمان به منظور مشخص و برطرف نمودن گلوگاههاي كاري ارائه مي دهند.
    ایجاد استانداردهاي كاري و اطلاعاتي در جهت افزایش كیفیت ، كاهش قیمت تمام شده و متعاقب آن رضایت مشتریان
    نیاز به توسعه در سازمان و در همین راستا، وجود سیستمي انعطاف پذیر كه توسعه و بهبودهاي سازمان را به راحتي پشتیباني كند.
    پرستیژ كاري براي سازمان. عملا وجود چنین سیستمهایي در هر شركتي به مشتریان ، پیمانكاران ، تامین كنندگان اطمینان خاطري را القا مي كند.
    ایجاد بستري براي پیاد هسازي سیستمهاي ارتباط با مشتریان و پیمانكاران (CRM, SRM)
    ایجاد بستر اطلاعاتي مناسب براي پیاده سازي سیستمهاي پیشرفته مدیریتي مانند :
    هوش تجاري  Business Intelligence
    مدیریت استراتژیك  Strategic Enterprise Management
    سیستم هاي تصمیم گیري  Decision Making
    مدیریت عملكرد  Performance Management
    مدیریت دانش  Knowledge Management
    بدون پیاده سازي ERP ، عملا پیاده سازي موثر سیستمهاي فوق عملا امكانپذیر نمي باشد.
    ایجاد بستري براي وارد شدن به بحث هاي دهكده جهاني )مباحث e-Business ، Core Banking  )
مزایا و ارزش افزوده حاصل از پیاده سازي ERP
    یكپارچگي روال ها و فرایندهاي عملیاتي و استاندارد كردن فعالیت ها
    یكپارچگي اطلاعات سازمان - ایجاد هماهنگي اطلاعاتي
    قابل دسترس بودن، سرعت و امنیت اطلاعات
    به روز بودن اطلاعات
    بهبود فرآیندها و مهندسي مجدد
    بهبود چارت سازماني
    ایجاد فرهنگ سازماني - بوجود آوردن هماهنگي و هم زباني دركل سازمان
    ایجاد محیطي منعطف در برابر تغییرات سازمان
    استاندارد سازي فناوري اطلاعات و زیر ساخت هاي استفاده شده
    كاهش خطاها به كمك همگرایي سیستم ها
    هم راستا نمودن ماموریت سازمان و فناوري اطلاعات
    كاهش دوباره كاري ها
    كاهش هزینه و زمان توسعه سیستم هاي اطلاعاتي
    امكان برنامه ریزي منابع سازمان
    امكان تهیه انواع گزارشات داینامیك
    امكان محاسبه KPI هاي سازمان و تهیه انواع داشبوردهاي مدیریتي
    سهولت در امر پشتیباني به دلیل عدم وجود Bug و Error
    امكان مونیتور كردن تمامي فعالیت ها
    استفاده از Best Practice هاي دنیا در جهت بهبود فرایندهاي كاري و چارت سازماني

کاهش قیمت تمام شده
 

 
انواع ERP
 
مقایسه انواع ERP
 
تاریخچه SAP
شرکت SAP در سال 1972 در آلمان با چشم انداز ایجاد و توسعه یک نرم افزار کاربردی استاندارد برای پردازش اطلاعات یک سازمان در تاسیس گردید. در حال حاضر SAP جایگاه نخست را در بین رقبای تامین کننده ERP در سطح دنیا دارا می باشد. این شرکت با داشتن 53 هزار کارمند در سطح دنیا و 109 هزار مشتری در 120 کشور و گردش مالی 12464 میلیون یورو در بین بهترین شرکتهای دنیا رتبه 12 را به خود اختصاص داده است. در حالیکه بسیاری از بهترین شرکتهای دنیا در صنایع مختلف کسب وکار خود مشتری SAP  میباشند.
 

استفاده بهترین ها از SAP
 
مزایای پیاده سازی SAP در شرکتهای خودرو ساز
ارزش افزوده
 
 
 
چرا SAP ؟
 

متدولوژی پیاده سازی SAP:
ASAP Methodology
 
بررسی عوامل موفقیت و شکست پروژه های SAP:
    عدم حمایت موثر و به موقع مدیریت ارشد سازمان- Very High
    مقاومت سازمان در مقابل تغییر–  Very High
    عدم حمايت و همكاری مديران ارشد–   High
    عدم تخصیص مشاوران مناسب SAP-  High
    عدم تجربه كافي مدير پروژه–  High
    عدم تخصیص Key User های مناسب–  High
    عدم وجود  Clean Data-  Very High
    ايجاد استثنا های غیر منطقي به عنوان رويه سازمان–   High
    عدم آموزش مناسب كاربران كلیدی–   Very High
    عدم آموزش مناسب كاربران نهايي-  Very High
    طسوت يفاك نامز صیصخت مدع Key user ها-  Medium
    درخواست تغییرات بنیادی در فرايندهای استاندارد سپ- Medium
    تغییر اعضای تیم key User يا مشاوران SAP - Medium
    عدم تهیه داده های مورد نیاز در زمان مقرر- Medium
    آماده نبودن محل پروژه-Low
    آماده نبودن بستر سخت افزاری ) سرور ، اينترنت و .... )- Low
    تغییر در اسكوپ قراردادی Low–
اشاره
يكى از شركتهاى بزرگ كشور كه اقدام به پياده سازى ERP نموده شركت ايران خودرو مى باشد كه محصول شركت SAP  را خريدارى كرده است. به منظور آگاهى از مراحل و چگونگى  نجام اين كار گفت وگويى با مديران پروژه، آقاى دكتر اقدسى و آقاى مهندس تجعفرى انجام داده ايم.
از نگاه شما ERP  یا سيستم هاى برنامه ريزى منابع سازمانى چيست؟
دكتر اقدسى: كاربرد رايانه در كسب و كار سابقه ای طولانى دارد. كسب و كارها نيز بخش های مختلفى دارند كه رايانه مى تواند در آنها موثر واقع شود. سابقة كمك رايانه در حوزۀ برنامه ريزى به حدود 30 يا 40 سال پيش برمى گردد. در آن زمان نرم افزارهايى ارائه شد كه برنامه ريزى(MRP)  احتياجات نام داشت. توليد به عبارت ديگر، اين نرم افزار ها، نيازمندی های اصلى براى توليد يك سازمان را برنامه ريزی و زمان بندى مي كرد. مهم ترين منابع براى يك خودروساز، قطعات و تجهيزاتى است كه بايد به هم وصل شوند تا يك خودرو ساخته شود. اين منابع به علاوۀ منابع انسانى، اگر از طريق برنامه ای مناسب با همديگر به كار گرفته شوند، خودرو توليد خواهد شد. برنامه ريزی تركيبي تمام نيازمندی های مواد، قطعات و نيروی انساني مستلزم نرم افزارهای رايانه ای است. اولين بار از رايانه براى برنامه ريزى در قسمت های توليدی شركت ها استفاده شد. پس از آن، اين كاربرد گسترده تر شد و رايانه توانست تمام منابع سازمان را با جزئيات كامل دربرگيرد. يعني دامنة كاربرد كامپيوتر براى برنامه ريزى در ساير حوزه هاى سازمان نيز گسترش يافت. به عنوان مثال، براى حوزه هاى مالى، فروش، منابع انسانى و... كامپيوتر به كار گرفته شد. البته، بديهي است كه برنامه ريزی بدون كنترل در اجرا و بازخورد برای برنامه های بعدی معنايي ندارد. در ابتدا، هر كدام از اين حوزه ها متناسب با نياز
خاص خود برنامه ريزى شدند. بنابراين، نرم افزارهاى مختلفى براى اين كاركردها توسعه يافت و انواع نرم افزارهاى مالى، انواع نرم افزارهاى فروش، انواع نرم افزارهاى مرتبط با منابع انسانى توسعه پيدا كردند. اما، شركت ها به صورت يك مجموعه نياز داشتند كه اين نرم افزارها و تسهيلات رايانه ای با همديگر ارتباط داشته باشند تا اينكه سازمان از يكپارچگي منطقي سود ببرد. در غير اين صورت، عدم همخواني اطلاعات نه تنها امر تصميم گيری صحيح را ناممكن مي سازد. بلكه، انجام عمليات ارائه خدمت را نيز با اختلال و اشكال مواجه مي كند. به عنوان مثال، يكي از نمايندگي های خدمات پس از فروش ممكن است مدت ها از تغيير يكي از قطعات توسط سازندگان قطعه اطلاع نداشته باشد و نتواند در ارائه خدمت مناسب موفق عمل كند.
به همين دليل، برنامه هايي كه در قسمت های مختلف يك بنگاه اقتصادی به كار گرفته مي شود بايد ضمن انجام يك عمليات مستقل، در يك حوزۀ خاص نيز پاسخگوی كارگر، كارمند و مدير باشند. بايد با همديگر تبادل اطلاعات كنند و اطلاعات فرايندهايي كه توسط آنها به روز و يا كامل مي شود، يكپارچه باشد. به عنوان مثال، اگر مهندس طراح قطعه ای را برای عملكرد بهتر تغيير داد. اطلاعات قطعه جديد تنها در برنامة واحد مهندسي وارد نشود. بلكه اين تغيير در برنامه های مورد استفادۀ بخش توليد، فروش و نمايندگي ها و خدمات پس از فروش نيز تأثير گذار باشد.
برای اين كار تنها برقراری ارتباط بين اين برنامه ها كافي نيست. بايد تمام اين برنامه ها از منابع داده ای يكسان تغذيه كنند و عمليات و كارهای واحدهای مختلف مطابق با وظيفه خاص آنها انجام شود و تغييرات و تأثيرات خود را بر اين پايگاهای اطلاعاتي مشترک بگذارد. اگر برای اطلاعات پايه ای شركت از پايگاه های داده ای متفاوتي استفاده شود.
به عنوان مثال، فرض كنيد پايگاه داده ای مشترى در بخش فروش و نمايندگي ها با همديگر متفاوت باشد. در آن وقت ممكن است كه يكي از مشتريان برای انجام گارانتي به يكي از نمايندگي ها مراجعه كند اما، به دليل اينكه نام او در فهرست مشتريان نمايندگي ها وجود ندارد، او نتواند سرويس گارانتي را دريافت كند. نام اين مشتری بايد در ليست فروش، تعميرات، قسمت مالى، قسمت تعمير و تدارک و... وارد شده باشد.
اين فهرست به يك باره تهيه نشده است و ثابت نمي ماند بلكه، در طول زمان دستخوش تغيير مي شود و اگر از جايي تغذيه نشود مشكلات اساسي براى كسب و كار پيدا مي شود. در واقع، موضوع تنها به اطلاعات و كامپيوتر مربوط نمى شود بلكه، فرايندهاى  انجام كار، كه بسيارى از بخش هاى آن توسط رايانه انجام مى شود، بسيار اهميت دارد.
نرم افزارهاى ERP  در نتيجة اين فكر به وجود آمده اند كه فرايند هاى كسب و كار همراه با يك سيستم رايانه ای يكپارچه كه داراى پايگاه اطلاعاتى ERP مركزى است، انجام گيرد. اين روند شكل گيرى است وشركت هاى نرم افزارى كه در تمام اين مراحل، با كسب و كارهاى مختلف همراه بوده اند و نرم افزارها را توسعه داده و انواع خدمات رايانه ای را به آنها ارائه دادند، يك تجربه غنى از كسب و كارهاى مختلف را به دست آوردند و توانستند بهترين فرايندهاى آن شركت ها را آن كه) Best Practice عده ای آن را به روش مى نامند). ناميده مي شود در نرم افزارهاى ERP خود لحاظ كنند. بنابراين، نرم افزار هاى ERP ها مى توانند با يكديگر تفاوت BP از نظر توجه به زيادی داشته باشند.
استقرار و پياده سازى ERP براى شركت ايران خودرو چه ضرورت، منافع ومزيت هايى دارد؟
مهندس تجعفرى: زمانى كه من برای انجام اين پروژه به ايران خودرو منتقل شدم، درخواست مديريت ارشد، تنها راه اندازى نرم افزار نبود. در واقع، مأموريت من انتقال اين تكنولوژى به مملكت بود و نه يك نرم افزار. اگر شما از تيم هاى نرم افزارى در خارج از كشور بازديد كنيد متوجه مي شويد كه مهندسان موفقي در ميان آنها وجود دارند كه توسعه دهندۀ نرم افزار ايرانى هستند. در ايران نيز مهندسان فارسى زبان ايرانى زياد هستند. تفاوت در چيست؟ به خاطر دارم كه در يك جلسه بحث شد كه آيا ERP  ؟ خوب است يا خير؟ SAP خوب است يا خير؟ از اين سيستم استفاده بكنيم يا نه؟ من گفتم نمى توانم در يك جلسه كوتاه جواب بدهم و بگويم چه منافعى را به همراه دارد. اما، سوأل اين است كه چرا براى چيزى كه به نظر شما خيلى مفيد نيست به مدت 3 سال در تحريم خريد بوديم؟ در حال حاضر نيز، به ازای هر قدمى كه در راستای اين پروژه برداشته مي شود با موانع و تحريم های زيادی روبرو هستيم. به طورى كه براى آوردن يك Tools استقرار (Solution Manager)  بيشتر از يك سال زمان صرف شد تا به ايران آورده شود. با وجود اينكه، بر اساس قرارداد با SAP  هزينه ای ، را نيز در بر نداشت.
دكتر اقدسى: در صنعت خودروسازی برای مدت زيادى پيش از انقلاب و مدتى هم بعد از انقلاب صرفاً يك مونتاژكنندۀ ساده بوديم. بيشتر از يك دهه است كه خودروسازى ايران نيز در يك مسير صعودى به سمت خودرو ساز شدن در انداه های جهاني گام برداشته است. ما براى انتقال تكنولوژى در حوزه های متعددی با خارجى ها ارتباط داشتيم و همواره در فراز و نشيب هاى تحريم و موانع قرار گرفته ايم. اما، هيچ وقت در تحريم هاى سخت افزار هاى صنعتى به اندازۀ نرم افزار مشكل نداشتيم. يعنى، در زمينة تكنولوژى هاى نرم حساسيت وجود دارد اما، در مورد سخت افزار اين گونه نيست.
مهندس تجعفرى: در حال حاضر، در اين شركت مشاهده مى كنيد، ماشين هايى (تجهيزات خطوط توليد) وجود دارد، زماني كه مشاوران آلماني پروژۀ استقرار آنها را ديدند، تعجب كردند كه ما چقدر در تكنولوژى سخت افزار پيشرفت كرده ايم. امكان تهيه كتاب در مورد هر موضوعى نيز به راحتي فراهم است. پس جای چه چيزى خالي است؟ در ايران، وضعيت سخت افزارى خوب است و اطلاعات را نيز دريافت مي كنيم اما، به نظر من بايد به مدل كسب و كار دست يافت. دانشى كه با ابزارى مانند ERP وارد مملكت مي شود. به عنوان مثال، چگونه مي توان برنامه ريزى كرد تا سمند را بتوان 8 ميليون تومان فروخت. يكى از وضعيت هاى رقابتى ما با دنيا ارزان بودن نيروى انسانى در ايران است. هزينة نيروى انسانى در ايران فوق العاده پايين و قيمت مواد اوليه خيلي بالا است. بر خلاف آنچه كه درساير كشورها وجود دارد. حال، چرا آنها از ما جلوتر هستند؟ چرا ما نمى توانيم به عنوان مثال با تويوتا رقابت كنيم؟ چرا كل طول دوره توليد آنها فقط چند روز است و مدام در حال كاهش آن هستند؟ قطعات (مواد اوليه) يكى از مولفه هاى مهم در قيمت تمام شده خودرو است. آنچه كه باعث افزايش قيمت مواد اوليه مي شود، انبار است. چگونه مى توان هزينه انبار را كاهش داد؟ چگونه مي توان پول را در گروه مديريت كرد؟ يكي از امكانات مورد نياز مديران، ابزارهايى براى اجراى اين نوع كارها است تا آنها بتوانند قيمت تمام شده را كاهش دهند.
آيا ايران خودرو نمى تواند شركت يا شركت هاى داخلي را برای ايجاد چنين امكاناتى انتخاب كند تا آنها با كمك دانش خودروسازى و مدل هاى كسب و كار خودروسازى معروف دنيا كه توسط مشاورين بين المللى قابل دستيابى پروژه را اجرا نماييد؟
مهندس تجعفرى : ERP  يك روش تهيه دانش مدل كسب و كار خودروسازى است.
دكتراقدسى: فرايند و تكنولوژى manufacturing يا ساخت با فرايند و تكنولوژى توليد متفاوت است.
تصور عموم بر اين است كه تكنولوژى ساخت دشوار است. در صورتى كه دشوارى مهم تر تحصيل تكنولوژى توليد است كه بدون فرايند هاى تأمين و فروش كه داراى تكنولوژى هاى نرم است مقدور نمى باشد مشكل موجود در خصوص مسأله برنامه ريزى تأمين تكنولوژى است.
يك سر فرايند توليد را بازار و مشترى تشكيل مي دهد كه نزديك به چند ميليون نفر ذينفع دارد. حوزۀ فروش مركزى، مناطق فروش و نمايندگى هاى فروش، خدمات و تعمير گاه ها در يك سوی فرايند توليد قرار دارند و در طرف مقابل، پس از كارگاه بدنه و پرس، نزديك به چند صد شركت تأمين كنندۀ قطعات قرارگرفته اند. اكنون، در نظر بگيريد كه به عنوان مثال، قصد داريم به مشترى بگوييم كه با هر مدل و رنگ و آپشن كه مايل باشى مي توانيم در مدت چند روز آن را توليد كنيم. علاوه بر اين، نمى خواهيم ميزان انبار قطعات نيز از دو سه روز تجاوز كند. چگونه مى توانيم در برابر تقاضاهاى متنوع مشتريان، بدون هزينه هاى اضافى براى تأمين قطعات، پاسخگو باشيم. در اينجا بايد در نظر گرفت كه قطعه ساز نمي تواند هر لحظه تغييرات عجيب و غريب را در توليد خود اعمال كند.
و لازم است كه توليد صرفة اقتصادی داشته باشد. در اينجا تكنولوژى نرم كه همان  BP ها يا به روش هاى  فرايندهاى تأمين به موقع(Just In Time)  هستند به كمك ما مى آيند.
آيا اين تكنولوژى و نرم افزار با استقرارى كه شما مطرح مي كنيد، به هم پيوسته هستند يا اينكه قابليت جداشدن از همديگر را دارند؟
دكتراقدسى : سيستم تأمين شامل سه جزء اصلى است. يك نرم افزار كه به شما اين قابليت را مي دهد كه ارتباط برقرار كرده و بتوانيد برنامه را بسازيد. جزء دوم، نيروى انسانى و جزء سوم نيز ساختار ها و مدل هاى تجارى شركت هاى تأمين كننده است. يعنى نرم افزار در چهارچوب مدل هاى تجارى و دانايى نيروى انسانى تكنولوژى نرم تأمين را تشكيل مى دهند. بنابراين، ما در پياده كردن SAP  تنها قسمت نرم افزار را پياده نمى كنيم. اگر اين چنين بود، سخن شما درست بود. ما در اين سيستم به نيروى انسانى، چگونه كار كردن او، چگونگي برقراری ارتباط و برنامه ريزى كردن او توجه مي كنيم و مدل تجارى شركت و تأمين كنندگان بر اساس دانايى ها و تجارب فرايند های برتر در صنعت خودرو (BP) شكل مى گيرد.
منظور شما از  "ما "چه كسي است؟
دكتر اقدسى: در پروژه SAP مجموعه تمهيداتى را براى دو تيم اصلى داريم؛ يك تيم مشاور كه بيشتر ساختار نرم افزار را درک مى كند و با استفاده از تجارب پياده سازى متوجه مي شود كه چگونه بايد مولفه های نرم افزار را براى نياز يك خودرو ساز شخصي سازی كند. تيم ديگر متشكل از افراد شركت ايران خودرو هستند كه كه با فرايند هاى فعلى ايران خودرو را به 8 ماه در - خوبى آشنايي دارند. اين دو تيم به مدت 9 كنار همديگر كار مى كنند تا تمام فرايند هاى مورد نظر را كه در دامنة پروژه قرار دارند بر اساس BP ها و با جزييات ممكن و خاص ايران خودرو در نرم افزار تعبييه شود. با اين رويكرد، در كنار پياده كردن نرم افزار، نيروى انسانى نيز پرورش يافته و به عنوان مثال، مى داند كه براى سفارش بايد چه كند؟ يعنى فرايندها، و ترتيب آنها و ظرافت كارى هاى فرايند سفارش را در كنار پياده كردن نرم افزار ياد مى گيرد. اين موضوع تجارب SAP بسيار مهم است كه از طريق پياده سازى را به ايران خودرو مى آوريم و نيروى انسانى (BP) برتر ياد مى گيرد كه روش هاى كار را با آن هماهنگ كند.
آيا بايد اين نرم افزار را الزاما از SAP  خريد يا اينكه مى توان مانند ساير تكنولوژى ها دانش فنى را تهيه و نرم فزار را ايجاد كرد؟
مهندس تجعفرى: فكر نمى كنم كه تنها راه آن خريد ERP باشد. موضوع فقط منفعت- هزينه است. داستان نوشتن ERP هايى كه گاهى در ايران طرح مي شود- با احترام نسبت به همة همكاران صنعت IT - اما، من نمى دانم كه آنها چگونه دانش Best Practice  مورد نياز را فراهم كرده اند. قرار نيست همان مدلي را كه ما كار مى كنيم آنها كد كنند. قرار است BPR انجام بدهند. يك روش اين است كه به جاى اينكه من فرايند را تدوين كرده و آن را بهبود دهم، يك مدل پيشرفته تمام شده را انتخاب كرده و از آن استفاده مي كنم. اين در حقيقت دانش مدل كسب و كار پيشرفته است كه به نرم افزار تبديل شده و اين نرم افزار وجود دارد.
اين "ما" يى كه آقاى دكتر بيان كردند،  معمولاً براى شروع پروژه يك تيم استقرار دهنده (Implementer) استفاده مي شود. ما اين سرويس را طي قرارداد با يك شركت آلمانى در اختيار گرفتيم. كار اين تيم، استقرار سيستم است.
روش ما به اين صورت است كه تعدادی كارگاه برگزار مي شود كه در آنها مدل هاى كسب و كار استاندارد سيستم ارائه مي شود. سپس، برخي از شاخص هاى اندازه گيرى توافقى فرايند بايد تعريف شود و سپس، آنها را برای فرايندها اندازه گيری مي كنيم. فرض كنيد فرايند دريافت كالا تا پرداخت فاكتور در ايران خودرو 12 روز و در ERP سه روزطول بكشد. برای رسيدن به سه روز ، بايد تغييراتي صورت پذيرد كه كمي هزينه دارد. اين هزينه به اين بستگي دارد كه شما مى خواهيد شاخص اين فرآيند را به چند برسانيد. پس از تصميم گيری در مورد ميزان تغيير شاخص (با توجه به هزينه آن) در فاز بعدی، سيستم براساس اين شاخص ها و مدل ها، بومي مي شود. يكى از فازهاى پروژه، فاز طراحى است كه در واقع در آنجا همين بحث ها مطرح مي شود. كه البته مهم ترين فاز پروژه نيز تلقي مي شود. زمانى كه اين طراحي به تمام شد، مي توان فهميد كه بعد از استقرار ERP  كجا خواهيم رسيد.
با اين توضيح زماني كه پروژه تمام شد، ما مدل های كامل به Best Practice نرسيده ايم (يعنى تقريبا هيچ جا نمى رسند)، اما، تغييری كه در سازمان اتفاق افتاده است نشان دهندۀ جهش است. باقي آن را مي توان در مرحله بهبود مستمر انجام داد. برای همين ما يك تيم كارشناسي در كنار مشاوران خارجى پرورش داديم تا آنها در ادامه مسير نقش متولي كار را بر عهده بگيرند.
مشاوران استقراردهنده اروپايي نيستند و در كشورهای ديگر مانند كشورهای آسيايي نيز وجود دارند. موضوع خريد سيستم و استقرار آن دو موضوع است و مي توان سرويس استقرار را از شركت های غير از توليد كننده سيستم دريافت كرد.
دكتر اقدسى: من يك توضيح در مورد اين تيم بدهم. اين تيم جداى از پرسنل بيزينس نبوده است. ما بخش مالى را كه پياده كرديم، حدود صد نفر از پرسنل مالى در اين تيم بودند و فقط هشت نفر افراد ثابت پروژه بودند. بقيه از افراد شاغل در فرايند مالى چهار شركت ايران خودرو، ايران خودرو خراسان، ايساكو و ساپكو بودند، كسانى كه كارشان را دارند و در پروژه نيز نقش مهمى به عهده آنها است به طورى كه موقعيت يادگيرى فرايند BP  براى آنها فراهم است. بنابراين تيمى كه گفتم منظورم دكتر اقدسى، مهندس تجعفرى و پنج شش نفرى كه با آنها كار مى كردند نبود.
سوال من اين است كه آيا بايد نرم افزار حتماً از SAP مى آمد؟ يا همان طور كه شما بيان كرديد تكنولوژى آن كه وجود داشت، اين امكان بود كه با استخدام گروهي از مشاوران نرم افزار مورد نياز در داخل كشور نوشته شود.
همان طور كه ما از سال 47 تاكنون هزينه كرده ايم و مانع از واردات شديم تا شما خودروساز شويد. شما هم تحمل مى كرديد تا ما توليدكننده نرم افزار شويم؟
مهندس تجعفرى: مدت زمان اين كار مهم است. به عنوان مثال، مى توان يك ماشين را از پايه طراحى كرد. همان طور، كه چند سال طول كشيد تا سمند طراحي و توليد شود. اين يك روش كار است. روش ديگری نيز وجود دارد. فرض كنيد چند سال مدت زمان زيادی است و قصد داريم در يك زمان كوتاه تر ( به عنوان مثال پژو 206 ) را راه اندازی كنيم. پژو 206 نيز را مي توان مانند سمند توليد كرد. در واقع مى توان تكنولوژى در بحث IT  نيز به همين شكل است. را وارد كرد. يعني، بايد در نظر گرفت كه مي خواهيد چقدر زمان و هزينه صرف كنيد.
بحث شدن يا نشدن نيست. اگر ما از سال47 دروازه ای كشور را به روى واردات بستيم تا ايران خودرو، خودروساز شود و بتواند سمند توليد كند. چرا نمى توان همين اقدام را تكرار كرد تا ما نيز نرم افزار در سطح جهانى توليد كنيم و Best Practice داشته باشيم؟
مهندس تجعفرى: چرا شما به عنوان متوليان IT ايران چنين كاری را انجام نمي دهيد؟ سوال من نيز همين است، چرا اين كار را انجام نمي دهيد؟ چرا بايد از آلمان متخصص آورده شود؟ چرا بايد پول مملكت را به متخصصان خارجى داد؟
دكتر اقدسى: شما عضو يك گروه نرم افزارى هستيد و تصور مي كنيد كه بنده نيز در طرف ديگر، عضو گروه خودروسازها هستم و سوال مي كنيد كه چرا براى حمايت از نرم افزار هاى داخلى اقدام مهمى صورت نگرفته است؟ اول اينكه، من در جايگاه تصميم سازى هاى كشور براى صنعت نرم افزار نيستم. شما مى توانيد از مسئولان مربوط به آن پاسخ مناسبى دريافت كنيد. من، به عنوان يك مدير شاغل در خودروسازى، نظر خود را با شما در ميان مي گذارم.
در فضاى اقتصادى كشور، صنايع مختلفى فعال هستند. متوليان اين صنايع با نيروهاى تصميم گير كشور ارتباط
برقرار مى كنند تا به عنوان مثال، قانوني را تصويب كنند يا نكنند؟ اين موقعيت براى همة صنايع وجود دارد. بديهي است خودروسازان در برابر توليد كنندگان نرم افزار نايستاده اند. اگر لازم است حمايت شوند بايد خود آنها اقدام كنند.
از زاويه ديد يك دانشگاهى - نه از زاويه ديد يك خودروساز - نيز مي توان در مورد انتقال تكنولوژی و سياست ها و دشواری های آن صحبت كرد. انتقال تكنولوژى رابطة بسيار نزديكى با نوع تكنولوژى دارد و تكنولوژى هاى نرم افزارى و انسانى پيچيده ترين تكنولوژى ها به شمار مي روند. اگردقت كرده باشيد بيشتر اوقات شنيده مي شود كه مى گويند ما مشكل مديريتى داريم. عده اى ممكن است تصور كنند كه ما مشكل مديران را داريم. در صورتى كه مشكل مديريتى است و نه مشكل مديران! مديران باهوش و خلاق بسياری وجود دارند. مديرانى كه با متغيرهاى بسيار زياد و در شرايط نامطمئن تصميم مى گيرند و مسائل را حل مى كنند. به طور قطع، اين مدير در فضايي قرار مي گرفت كه همة متغيرهاى لازم برای اعمال مديريت وجود نداشت و اگر تعداد زيادی از متغير ها توسط سيستم مديريت ارائه مي شد مي توانست عملكرد بهتری داشته باشد. بنابراين، سيستمى مورد نياز است كه مدير را حمايت كند. به عبارت ديگر، سيستم های مديريت يك تكنولوژى است. با پياده سازى فرايند هاى BP  تكنولوژى مديريت وارد كشور مى شود.
تكنولوژى مديريت با تكنولوژى ساخت تفاوت دارد. براى تهية نرم افزار ها به دانش كامپيوتر و به دانش فنى مرتبط با كاربرد آن نرم افزار نياز است. اين دانش فنى پشتوانة آن نرم افزار است. پشتوانة نرم افزارى كه پزشكان با آن مي توانند به راحتي كار كنند، دانش پزشكى است. بنابراين، هر نرم افزارى يك پشتوانه دارد. پشتوانة نرم افزارهاى ERP نيز تكنولوژى مديريت است كه در گروه دشوارترين تكنولوژى ها قرار مي گيرد. شركتى مانند SAP  طي دو يا سه سال براى ادارۀ كسب و كار نرم افزار ساخته نشده است بلكه، نزديك به 40 سال است كه تلاش مي كند تا راه حل هاى برنامه ريزى، مديريت و فرايند هاى كسب و كارهاى مختلف را در نرم افزار هاى ERP پياده كند.
در حال حاضر پروژۀ ايران خودرو در چه مرحله اى قرار دارد؟ به نظر شما، آيا نمى توان اعضاء تيم فعال در آن را از ميان شركت هاى داخلى انتخاب كرد؟
مهندس تجعفرى: قرارداد دوم استقرار با يك شركت داخلى منعقد شده است. قرار نيست كه ما همه متخصص عملياتي ،ERP كاره باشيم. در بحث استقرار كه - (Change Management) مديريت تغييرات يكي از حساس ترين قسمت های استقرار است - وجود ندارد. از خارج نيز نمى توان دعوت به همكاری كرد و ظاهراً كسي هم نيست كه حاضر باشد در اين زمينه تلاش كند و متحمل زحمت بشود.
براى پياده كردن نرم افزار چقدر هزينه شد؟
مهندس تجعفرى: هزينه استقرار بيشتر از خريد است. نزديك به 2 سال طول كشيد تا بخش مالى استقرار پيدا كرد.
گمان مى كنيد در چه زمانى كل پروژه ERP درگروه صنعتى ايران خودرو مستقر مى شود؟
مهندس تجعفرى: تعداد زيادی شركت وجود دارد. به عنوان مثال، استقرار سيستم در كارخانه ال90 (تندر90 ) تا هفت ماه آينده به پايان مى رسد. اين قرارداد با يك شركت داخلى منعقد شده است.
دكتر اقدسى: از دو سال قبل بخش مالى چهار شركت آغاز شده است كه در حال حاضر به پايان رسيده است. در ايران بى سابقه است كه شركت هايى كه از قانوني مستقل اما، به يك بنگاه اقتصادى متعلق هستند و در يك زنجيره ارزش با همديگر داد و ستد دارند، بر روى يك زير ساخت مالى و نرم افزارى فعاليت كنند.
اين كه ERP نيست. زيرا تنها بحث مالى را  پوشش مى دهد!
مهندس تجعفرى: اين نمونه مانند ساختماني است كه تاكنون، پاية آن ساخته شده است. استقرار دو مدل دارد:
مدل يكجا (Big Bang) و مدل مرحله به مرحله ، .(Step By Step)
در ايران خودرو با توجه به بزرگي شركت (كه معمولا شركت هاى بزرگ به اين روش عمل مي كنند)، مدل مرحله به مرحله پياده مي شود. ابتدا، از مالى شروع شد و براى قسمت های اصلى گروه به اضافة ايران خودرو ( پنج مجموعه) استقرار داده شد.
حال اگر بخواهيد در همين پنج مجموعه را پياده كنيد، چقدر طول ERP ساير اجزاى مى كشد؟
مهندس تجعفرى: اين موضوع به پروژه ها بستگى دارد.
دكتر اقدسى: اگر زمان پروژۀ مالى در اين پنج تا شركت را در نظر بگيريد متوجه مي شويد كه دو قسمت دارد. زمان خالص انجام كار و زمان هم سو سازى بين ذينفعان. به عنوان مثال، ممكن است تمام ماژول هاى مورد نياز اين پنج شركت، پانزده پروژه و زمان خالص آن كمتر از دو سال باشد. اما، اگر ساير زمان ها را به آن اضافه كنيم بيشتر از دو سال خواهد بود. حتى، در اين پروژه مالى دو قسمت وجود داشت. يكى، از جنس اول كه شايد كمتر از هفت ماه بود و ديگرى از جنس دوم كه وقتى در كنار آن قرار گرفت نزديك به دو سال طول كشيد. جنس دوم از اين نوع است كه شما مى خواهيد در مورد سهم تصميم گيری، نوع و ميزان تصميم و مسئوليت مربوط به يك فرايند كه متوجه تعدادی از افراد است تصميم بگيريد و متغيرها و پارامتر های سيستم را برمبنای آن تنظيم كنيد. جلسه ای كه تمام اين ذينفعان - كه همان مديران پر مشغله هستند- سه بار و هر بار به مدت دو هفته به تأخير مي افتد.
بنابراين، زمان تصميم سازی در مورد پارامتر های سيستم نزديك به يك ماه و دو هفته مي شود. ( جنس دوم زمان) و زمان اعمال اين پارامتر ها در سيستم دو روز است.(جنس اول زمان) مسائل تصميم سازى بسيار زياد است كه باعث افزايش زمان خالص مي شود. البته، كم و بيش بسياری از شر كت هايي كه در جهت تغيير فرايند ها گام بر مي دارند با اين چالش ها مواجه هستند. اين چالش ها در ايران خودرو به قدری است كه پيش بيني زمان را دشوار مي كند. اين نوع زمان ها قابل پيش بينى نيست يا دست كم من در موقعيتى نيستم كه بتوانم اين زمان ها راپيش بینى كنم.
مسأله ديگر اين است كه از همان ابتدا كه اين پروژه به دستور مديريت آغاز شد. مدير عامل و كادر مديريت ارشد ايران خودرو، خودروسازى را به عنوان موتورصنايع ساخت و توليد در كشور قلمداد مى كردند و مسأله اصلى كه مطرح كردند اين بود كه تكنولوژى پياده كردن SAP بايد در كشور نهادينه  شود و فقط اجازه دادند در زمينة مالى با خارجى ها قرارداد منعقد شود و با پياده سازى آن، ساير پروژه ها با توانمندى كارشناسان ايرانى انجام شود. بنابراين، ما بايد در مسيرى حركت كنيم كه يك نهاد با استعداد درست شود. كه خوشبختانه با پياده SAP پياده سازى سازى پروژه مالى اين اتفاق افتاد. قرارداد بعدى با يك شركت ايرانى است و اين شركت به جاى اينكه فقط از پياده ساز خارجى استفاده كند بخشى از كار را خودش انجام مى دهد. به اين ترتيب، در گام بعدى هزينه و زمان كاهش مي يابد.
جناب عالي بيان كرديد كه به هر صورت اين نگاه مديريتى بوده كه با يك رويكرد كلى وارد شده اند. اگر به اين شكل است و آثار مثبت ERP را نيز در سازمان خود مشاهده  كرده ايد پس، چرا به اين پروژه اولويت نمى دهيد تا مدت زمان آن كمتر شود؟
دكتراقدسى: تمام زمانى كه براى اين كار لازم است به تصميم سازى مديريت ارشد مربوط نيست. در اين قضيه يك مجموعة صد نفره از مديران ميانى بايد تصميم سازى كنند. اين مجموعه از مديران ميانى اولويت هاى كارى متفاوت و متنوعى دارند. ضمن اينكه، در بعضى موارد نيز عقايد آنها با يكديگر مغايرت دارد كه البته در مجموعة بزرگى مانند ايران خودرو كاملاً طبيعى است. بنابراين، مدت زمان انجام كار از پيش بينى هاى اوليه طولانى تر مى شود

ارسال شده توسط احمد محمدی | 7 12, 2013 | بازدید‌ها (8487)

بررسی روند تکاملی متدولوژی های توسعه سیستم های اطلاعاتی در موقعیت های مختلف سازمانی

  مقدمه

تلاش ها و اقدامات مرتبط با توسعه سیستم ها ، در ابتدا وابسته به روش های تصادفی و غیرسیستماتیک بودند. در اواخر دهه 1960 ، مشکلات توسعه سیستم ها ، منجر به پدیده ای تحت عنوان بحران نرم افزار گردید. این عارضه به معنی نگاه و تمرکز سیستم ها بر توسعه ، همراه با هزینه زیاد ، عدم کارکرد و زمان طولانی ، است[3]. با توجه به پیچیدگی سیستم ها ، نیاز شدیدی به توسعه بود ، در حالی که وضعیت ، روز به روز بحرانی تر می شد. به همین دلیل رویکردهای متدولوژی به توسعه سیستم ها پدیدار گشت. توجه به متدولوژی در دهه 70 تا 80 بسیار زیاد بود. در این دهه ها بحث ، بیشتر روی دو رویکرد سخت و نرم از توسعه سیستم های اطلاعاتی قرار داشت. در این دوران سازمان های بزرگ و دولت ها از متدولوژی های خاصی برای مدیریت پروژه های IT خود استفاده کردند. مثلا SSADM توسط دولت UK و IDEF توسط US بکار گرفته شد. این دو متدولوژی مبتنی بر رویکرد سخت بودند. استفاده از این متدولوژی ها با مشکلاتی همراه شد. مثلا اینکه آن ها هرگز کار نمی کردند یا با تاخیر طولانی کار می کردند و یا با عملکرد پایین خود انتظارات کاربران را برآورده نمی نمودند. در اواخر دهه 80 انتقادات نسبت به متدولوژی افزایش یافت و در دهه 90 مطالعات روی این  موضوع کاهش یافت و آن هم به دلیل مخالفت با مکتب متدولوژی و شکست های پی در پی آن و مورد دیگر تغییر الزامات و نیازمندی های سازمان ها بود. تحول در تکنولوژی و ساختار سازمان ها عللی دیگر بر عدم پذیرش متدولوژی ها بود[8].
با تغییرات در محیط کسب و کار و افزایش سرعت تغییر تکنولوژی و ساختار سازمان ها و الزامات و نیازمندی های کاربران ، نیاز به متدولوژی هایی برای توسعه سیستم های اطلاعاتی بود که پاسخ گوی فعل و انفعالات محیط امروزی باشد. به همین دلیل رویکردهای چابک ، ترکیبی و چند نگرشی به متدولوژی های توسعه سیستم ها پا به عرصه وجود گذاشتند. اقتصاد دیجیتالی بر روی متدولوژی های توسعه اثر گذاشته و آن ها را پویا کرده است. این مقاله در ابتدا به توصیف متدولوژی ، ویژگی ها ، مزایا و معایب آن می پردازد و سپس به تحلیل و بررسی متدولوژی های مختلف در موقعیت های متنوع سازمانی اشاره می کند.


تعریف متدولوژی توسعه سیستم های اطلاعاتی

در ارتباط با تعریف متدولوژی دیدگاه ها و نظرات متفاوتی موجود است. همین طور از نگاه ها ومنظرهای متنوعی به متدولوژی نگریسته شده است. Olerup در سال 1991 متدولوژی را اینگونه تعریف می کند: یک استراتژی که دلالت بر زیربخش های فرایند توسعه دارد. اصل تقسیم و تسخیر ، یک رویکرد مهندسی و ریاضی برای حل مسائل پیچیده می باشد[3]. متدولوژی های اولیه خیلی تحت تاثیر رشته های فنی و مهندسی بودند. شخصی به نام Langefors در سال 1973 توسعه سیستم ها را به عنوان یک فرایند علمی و عقلایی در نظر گرفت. متدولوژی در دو موضوع زیر تصمیم گیری می کند یک سیستم اطلاعاتی چه کاری را باید انجام دهد و یک سیستم اطلاعاتی بهتر است چگونه آن کار را انجام دهد[3].
Olerup در 1991 با پذیرفتن این نگرش علمی عقلایی ، فرایند پیچیده توسعه را به مراحل زیر تقسیم کرد: تجزیه و تحلیل نیازمندی ها ، طراحی راه حل ، و اجرای راه حل. افراد دیگری مثل Downs در 1992  فازهای دیگری را به این مراحل افزودند. مثل تحقیق و بررسی مقدماتی و نگهداری[3].
یک تعریف قدیمی تر از متدولوژی توسعه سیستم های اطلاعاتی توسط 1987 ، Checkland ، 1995 ، Hirschheim ، 1990 ، R.J Boland وجود دارد و عبارت است از: یک مجموعه ای از مفاهیم ، عقاید ، ارزش ها و اصول هنجاری که توسط منابع مورد حمایت قرار می گیرند[2].
در زمینه متدولوژی ، دو نقطه نظر وجود دارد: 1 – تعریف خاصی از متدولوژی وجود ندارد و این تعاریف موجود ممکن است با هم سازگاری نداشته باشند. 2 – ویژگی های متدولوژی که تقریبا در همه یا بخش کثیری از تعاریف مشترک است. بعضی از اندیشمندان مثل ، 1981 Chechland ، 1995 Hirschheim  و 1990 Vonk بین متد و متدولوژی تفاوت قائل شدند. متدولوژی جامع تر از متد است. متدولوژی برای ارزیابی میزان منطقی و سیستماتیک بودن یک متد معین بکار می رود. در حالی که متد ، روشی برای اجرای فعالیت در حالت ساخت یافته می باشد[8].


ویژگی های متدولوژی ها و اجزای آن ها

متدولوژی های توسعه سیستم های اطلاعاتی دارای ویژگی هایی می باشند که توسط این خصوصیات می توان آن ها را طبقه بندی کرده و مطالعه نمود و در موقعیت های متفاوت از آن ها استفاده کرد.
متدولوژی از سه بخش اصلی تشکیل شده است[8] : 1 – ساختار شکست کار : توسط این بخش می توان فهمید که چه کاری باید انجام داد و همچنین زمان انجام این کار مشخص می شود. 2 – تکنیک های چگونگی انجام کارها و ابزار مورد نیاز 3 – چگونگی مدیریت کیفیت نتایج.
هدف یک متدولوژی این است که در تغییر و توسعه سیستم های هدف به گروه کمک کرده تا این گروه به درک ، ایجاد ، ارزیابی ، کنترل و اجرای تغییرات در سیستم پیشنهادی بپردازد. متدولوژی ها باعث ایجاد نظم و سازماندهی یک سری از قوانین رفتاری و فنی مبتنی بر یک رویکرد منطقی می شوند و مشکلات بنیادی توسعه را بررسی می کنند. آن ها مجموعه ای از قوانین تصادفی نیستند و به ایجاد یکپارچگی و ارتباط منطقی بین اجزای خود می پردازند. متدولوژی ها شامل یک سری از مفاهیم و عقاید هستند که به تعریف محتوا و رفتار سیستم هدف و همچنین تغییرات در آن می پردازند. آن ها ارزش یک سیستم را تعریف می کنند ، یعنی چه ویژگی هایی از سیستم ، خوب و مورد تمایل است. روش های انجام کار و رویه هایی برای اجرای فعالیت ها لازم است ، و اصول هنجاری که انتظارات رفتاری را مشخص می کنند ، در حیطه وظایف یک متدولوژی است.
برای نائل شدن به اهداف و وظایف ، متدولوژی ها باید مکتوب بوده ، مورد تفکر قرار گیرند و یادگیری و انتقال آن ها با مشکل مواجه نشود ، مورد پذیرش اعضای سازمان بوده ، اجرای آن ها همراه با پاداش و ضمانت اجرایی باشد. متدولوژی ها باید قانونی بوده و منابع مورد استفاده در آن ها مورد تایید و پذیرش تصمیم گیرندگان و مسئولان پروژه ها قرار گیرد و باید به این نکته توجه کرد که آن ها نیاز به سرمایه گذاری در نیروی انسانی و مواد دارند.
متدولوژی های توسعه یک فونداسیون و چارچوب ساختاری را برای فرایندهای توسعه ایجاد می کنند که این کار توسط طبقه بندی فعالیت های جزئی و ضروری توسعه ، صورت می گیرد. فعالیت های غیر منطقی و غیر بهره ور در اینجا ، حذف ، و اجرای کارهای مهم ، ضمانت می شود.
در سال 1984 ، شخصی به نام Ahituv ، ابعاد توسعه را شامل بعد فعالیت ، بعد کنترل و بعد نیروی انسانی ، تعریف کرد و این در حالی است که متدولوژی توسعه می تواند با ایجاد یک چارچوب ، ابعاد ذکر شده را بهینه کند[3]. نکته آخر در این بخش این است ، فرایند توسعه از یک سری فازها تشکیل شده که حاکی از اصل تقسیم نیروی کار است. هر فاز تعدادی فعالیت را شامل می شود و افراد متنوعی روی آن ها کار می کنند.


مزایای متدولوژی ها

متدولوژی ها در ابتدا توسط تجربه و تمرین روی پروژه های موفق ایجاد شده اند و سپس به صورت رویه ها و فرمول هایی مکتوب شده و به عنوان اصول راهنما در فرایند توسعه مورد استفاده قرار گرفته اند. Ward در 1992 گفت : قبل از اینکه یک متدولوژی در توسعه سیستم مورد استفاده قرار گیرد ، بهتر است از لحاظ اصول مفهومی ، اجتماعی ، فیزیکی و تئوریکی ، درجه قابلیت استفاده از آن ، مورد بررسی و تحلیل قرار گیرد[3]. اما نکته مهم اینجاست که اصولا متدولوژی ها چه مزیت هایی دارند. باید به این موضوع اشاره کرد که متدولوژی ها باعث سهولت کنترل در پروژه ها شده و این کار مهم را توسط ایجاد ساختاری منطقی از استراتژی ها ، تکنیک ها ، رویه های ممیزی ، فعالیت های بازرسی و کنترل کیفیت ، انجام می دهند. مدیریت پروژه فرایندهای توسعه با استفاده از متدولوژی ها راحت تر است. زیرا در متدولوژی ها ، چیزهایی قابل مشاهده وجود دارد که توسط آن ها می توان به بررسی پیشرفت پروژه و پایش هزینه و سود و مقایسه اینها با برنامه مورد انتظار ، و در نهایت ارزیابی ریسک پرداخت. ضمنا تهیه مستندات که یکی از الزامات مهم در مدیریت و کنترل پروژه است ، آسان تر می شود.
Stage در 1991 اذعان کرد که متدولوژی ها باعث ذخیره دانش به طور سیستماتیک می شوند و انتشار و مبادله آنرا تسهیل می کنند[3]. این موضوع باعث می شود دانش و مهارت از افراد ماهر به افراد نیمه ماهر ،  انتقال یابد. یکی از نتایج ذخیره دانش ، استانداردسازی فرایند توسعه است. Avison و Fitzgerald در 1988عقیده داشتند استاندارد توسعه باعث بوجود آمدن زبان مشترک برای برقراری یک ارتباط آسان در میان افراد مشارکت کننده در فرایند توسعه می شود و در نتیجه ، همکاری و مشارکت بیشتر و وفاداری آن ها به حرفه و شغل خود افزایش و نهایتا حفظ و نگهداری فرایند توسعه میسر می گردد[3].
با استفاه از متدولوژی ها ، وظایف و فعالیت های فرایند توسعه دارای ساختاری مشخص می شوند ، کنترل هزینه و کنترل پروژه راحت تر صورت می گیرد ، و در نتیجه عدم اطمینان کاهش می یابد ، توسط استانداردها و کنترل می توان به هدایت نیروی انسانی پرداخت ، امنیت افزایش یافته و یادگیری فردی و گروهی تسهیل می گردد.




مشکلات متدولوژی ها

علی رغم مزایای فراوان و توصیه های اکید در اجرای متدولوژی ها ، تجربیات توسعه دهندگان و مطالعات و تحقیقات دانشمندان نشان داده است که اجرای متدولوژی ها با چالش هایی روبرو می شود. به طور مثال Paul در 1993 ابراز کرد که مشکلات اجرای متدولوژی ها مربوط به ماهیت و ساختار بنیادی خود آن ها است. و Fitzgerald در 1999 گفت ، تغییرات سریع در محیط تجارت و کسب و کار عامل اصلی در عدم اجرای موفق پروژه های توسعه سیستم های اطلاعاتی با استفاده از متدولوژی ها است[8].
به نظر می رسد برای سازمان هایی که در محیط پویا و پر از آشوب همراه با تغییرات سریع ، زندگی می کنند ، اجرای متدولوژی که رویکردی زمانبر است ، چندان مناسب نباشد. از لحاظ هزینه نیز می توان آن ها را به چالش افکند. سازمان هایی که دارای بودجه کافی برای فعالیت های خود نیستند ،  نمی توانند به راحتی متدولوژی های توسعه سیستم های اطلاعاتی را اجرا کنند. یکی دیگر از مسائل پیش روی سازمان ها ،  انطباق و یکپارچگی متدولوژی ها با ساختارهای موجود در محیط داخلی شرکت ها است. بنابراین توسعه دهندگان باید فرایندهای توسعه را مطابق با فرایندهای درون سازمان خود انجام دهند یا فعالیت های سازمانی خود را به تبعیت از متدولوژی ها ، اجرا کنند. همچنین قابلیت استفاده مجدد از متدولوژی ها در محیط پر از تغییر و همراه با محدودیت منابع سازمان های امروزی ،  مطالعه و بررسی بیشتری را می طلبد و این موضوع به عنوان یک چالش جدی ، فرا روی سازمان ها قرار گرفته است.


متدولوژی های فرموله شده

همان طور که قبلا اشاره کردیم در گذشته متدولوژی ها از نتایج و تجربه اجرای پروژه های موفق ، ایجاد می شدند. یعنی اصول ، رویه ها و فرایندهای موفقیت آمیز این پروژه ها به صورت مکتوب در آمده و در موارد بعدی از آن ها استفاده می شد. اما امروزه نمی توان به راحتی از این استراتژی استفاده کرد. دلایل متفاوتی برای این موضوع وجود دارد که قبلا به آن ها اشاره گردید. ولی در سال 1989 شخصی به نام Constantine رویکردهای توسعه را از سه منظر نگریست[3] : تمایز محصول ، سن کارمندان و ضرورت موقعیت و محل در اجرای فرایند توسعه. Fitzgerald و Avison در 1988 تفاوت بین متدولوژی ها را در فلسفه ، اهداف و تکنیک های آن ها ، دانستند [3]. متدولوژی ها را  می توان به دو نوع سخت مثل SSADM و نرم و مبتنی بر نیروی انسانی ، تقسیم کرد. نوع تمرکز آن ها نیز می تواند متفاوت باشد. مثلا بعضی از آن ها بیشتر متمرکز بر فاز تجزیه و تحلیل هستند در حالی که برخی دیگر به اجرا تاکید دارند.
اجرای متدولوژی توسعه سیستم های اطلاعاتی فرموله شده ، یک فرایند سازمان دهی کارها و فعالیت ها و اثرگذاری بر روش تفکر اعضای تیم نسبت به توسعه می باشد. بنابراین اگر افراد در یک سازمان بدون مشارکت یک متدولوژی ، بتوانند به سازمان دهی تفکرات و فعالیت های خود بپردازند ، در این صورت استفاده از متدولوژی ها بی ارزش می شود. بعضی تحلیل گران با تجربه ای که دارند ، بدون استفاده و کمک از متدولوژی ها ، بر مشکلات و موقعیت های سخت سازمان فائق می آیند. آن ها از قبل با این وضعیت ها به طور مشابه ، مواجه شده اند. علاوه بر اینها بعضی مواقع تیم و پروژه ها در مقیاس کوچک هستند و استفاده از متدولوژی ها ، تنها مشکل آفرین می شود و منفعتی برای فرایند توسعه ندارد.
متدولوژی های فرموله شده ، پشتوانه سال ها تحقیق هستند. بسیاری از افراد که در توسعه سیستم ها تخصص دارند ، معتقدند که برای حل مشکلات اساسی سیستم ها در سازمان خود ، بهتر است از متدولوژی های فرموله شده همان سازمان استفاده کرد. Chapin در 1980 گفت: اگر در توسعه سیستم ها از استانداردهای محلی و فرموله شده استفاده شود ، کارمندان احساس راحتی بیشتری می کنند[3]. مثال هایی از متدولوژی های فرموله شده در گذشته موجود است. یکی از آن ها SSADM می باشد که توسط دولت UK برای اجرای پروژه های توسعه سیستم های اطلاعاتی ایجاد گردید و در حال حاضر بسیاری از کشورها نیز از این متدولوژی استفاده می کنند. ولی از طرفی می توان گفت که کشورهای فرانسه ، هلند و ایتالیا هر یک متدولوژی خاص خودشان را دارند. در نهایت اینکه Jayava در 1994 ابراز کرد که بیش از 1000 متدولوژی فرموله شده در سازمان ها وجود دارد[3].






طبقه بندی متدولوژی های توسعه سیستم های اطلاعاتی

متدولوژی ها را می توان به روش های مختلفی همان طور که در قبل ذکر شد ، طبقه بندی کرد. یکی از طبقه بندی های جامع را در این بخش می خواهیم بررسی کنیم. این طبقه بندی بر اساس وضعیت های مختلفی صورت می گیرد که سازمان ها با آن مواجه می شوند. 5 کلاس برای طبقه بندی متدولوژی ها وجود دارد که در زیر به آن ها اشاره شده است[1]:
وضعیت ها و مسائل ساخت یافته همراه با الزامات و نیازمندی های تعریف شده به صورت واضح
مسائل ساخت یافته با اهداف واضح و الزامات و نیازمندی های نامعین کاربران
مسائل غیرساخت یافته همراه با اهداف نامشخص
مسائل و وضعیت هایی که در آن ها نیاز به تعامل زیادی بین کاربر و سیستم است.
مسائل و وضعیت های پیچیده ، یعنی ترکیب چهار کلاس بالا که احتیاج به یک رویکرد اقتضایی در توسعه است.
اینک به توضیح مختصری از هر یک و متدولوژی های آن ها می پردازیم.
1 – مسائل ساخت یافته همراه با نیازمندی های تعریف شده به صورت واضح
در اینجا از متدولوژی های توسعه سیستم های اطلاعاتی سنتی مبتنی بر رویکردهای سخت استفاده می شود. متدولوژی های توسعه سیستم های کامپیوتری اولیه ، در این طبقه یا کلاس هستند. رویکرد SDLC سنتی را که مرکز محاسبات ملی UK ارائه داده است ، می توان در اینجا قرار داد که دارای فازها و مراحل زیر است : مطالعه امکان سنجی ، بررسی و تحقیق سیستم ، تحلیل سیستم ، طراحی سیستم ، اجرا ، بازنگری و نگهداری. این متدولوژی در جایی کاربرد دارد که افراد در آن سازمان خواستار تغییرات بنیادی نیستند. این متدولوژی در سازمان هایی با عملیات روتین ، فرایندهای ایستا ، قابل اجرا بوده و اصولا در سازمان های کوچک یا دپارتمان های سازمان های بزرگ می توان از آن استفاده کرد. کاربران در این متدولوژی به صورت خیلی محدود دخالت داده می شوند و این متدولوژی از تصمیمات مدیریتی کمتر حمایت می کند.
2 – مسائل ساخت یافته با اهداف واضح و نیازمندی های نا معین کاربران
این طبقه از متدولوژی ها بعضی از مشکلات کلاس قبل را حل کرده اند و برای سازمان های امروزی مناسب تر هستند. در اینجا فرض بر این است که الزامات کاربران نامعین هستند. این طبقه دارای متدولوژی های ساخت یافته ، تحلیل داده مثل مهندسی اطلاعات ، و نمونه سازی ، است.
رویکردهای ساخت یافته متمرکز بر اجرای فعالیت ها در کسب اهداف معین هستند. آن ها از تکنیک هایی مثل DFD ، درخت و جدول تصمیم استفاده می کنند. این تکنیک ها به تحلیل گر در فهم بهتر الزامات کاربران کمک می کند. این رویکرد به مستندسازی تفکرات هر فرد در مورد یک مشکل یا وضعیت می پردازد و این کار باعث تسهیل انتقال تفکرات افراد به یکدیگر می شود. مشارکت و درگیری کارکنان در فرایند توسعه بیشتر شده و تجزیه و تحلیل برای ارائه نتایج رسمی و واضح ، راحت تر صورت می گیرد.
در جایی که فرایندها کمتر ایستا هستند ، رویکرد تحلیل داده ها مناسب تر است. در این رویکرد تاکید بر مدلسازی داده است تا مدلسازی فرایند. طرفداران این روش می گویند ، حتی اگر فرایندهای توسعه در یک سازمان تغییر کند ، باز هم می توان از بلوک های داده که از قبل ساخته شده است ، استفاده کرد. یکی از تکنیک های اصلی این رویکرد ، مدل رابطه – موجودیت می باشد که توسط Chen در 1976 ابداع گردید. مدلسازی داده ها به ساخت یک مدل مفهومی داده برای تعیین الزامات سیستم اطلاعاتی بکار می رود.
اگر چه طرفداران زیادی برای متدولوژی مبتنی بر داده وجود دارند ، اما اشخاصی مثل Benyon ، Skidmore  در سال 1987 ابراز کردند که تاکید بر داده ها و تکنیک های مرتبط با آن ، ممکن است منجر به نادیده گرفتن واقعیات شود[1]. این متدولوژی ها در جایی که درجه تعارض بالا است کاربرد آنچنانی ندارد. به همین دلیل دو متدولوژی ساخت یافته و تحلیل داده با هم ترکیب شدند و از تکنیک هایی مثل DFD و ERD استفاده گردید. SSADM بر طبق این منطق توسعه داده شد. با اینکه ترکیب دو متدولوژی قبل باعث پوشش بعضی نقاط ضعف آن ها گردید ، ولی باز هم نمی شد از آن ها در محیط های با تعارض بالا استفاده کرد. به همین دلیل متدولوژی نمونه سازی بوجود آمد.
این متدولوژی برای وضعیت هایی مفید است که نیازمندی های کاربران غیر واضح است. در چنین رویکردی ابتدا نیازمندی ها و الزامات استخراج شده ، سپس آن ها ارائه می شوند و در پایان توسعه می یابند و این کار به همین ترتیب ادامه دارد تا کاربران سیستم رضایت کامل را کسب کنند. بنابراین ابتدا توسط یک مدل کاری ، سیستم نهایی ساخته می شود و این کار باید سریعا صورت گیرد و از بیان جزئیات خودداری شود. در ادامه مسائل بالقوه در طراحی مشخص می گردد و مرتبا تحلیل گر می تواند متوجه شود که نیازهای کاربران و مدیریت چیست. کاربران و مدیریت همراه با دیگر اعضای فرایند توسعه به طور مکرر با هم بحث و مذاکره می کنند و متدولوژی نمونه سازی به تناوب اجرا می شود. این رویکرد به تسهیل برقراری رابطه با کاربر تاکید دارد.
3 – مسائل غیرساخت یافته همراه با اهداف نا مشخص
متدولوژی هایی که در دو کلاس قبلی به آن ها اشاره شد ، دارای رویکرد سخت بودند. در بسیاری از مواقع اهداف اجرای توسعه سیستم نامشخص بوده و یا اصولا خود سازمان یا ارگان دارای اهداف غیرواضح است ، و همچنین ممکن است بعضی از گروه ها یا افراد در آن سازمان دارای اهداف واضح باشند ، ولی تعارضات بالایی بین آن ها برقرار است. در چنین مواقعی از رویکردهای نرم استفاده می کنیم. یعنی جایی که می خواهیم به اهداف بهینه و توافق شده دست یابیم. یکی از معروف ترین متدولوژی هایی که در این دسته قرار می گیرد ، متدولوژی سیستم های نرم است که توسط Checkland ارائه شد[1]. او معتقد بود که سیستم های فعالیت های انسانی تنها در ذهن افراد وجود دارند و بنابراین چشم انداز افراد است که بر روی نگرش آن ها از وضعیت مساله و اهداف سیستم ، اثر می گذارد. تکنیک دیاگرام تصویر غنی ، با مدلسازی تمام ابعاد وضعیت مساله باعث ایجاد یک تصویر غنی می شود که توسط آن مباحث ، مشکلات و تعارضات را می توان تشخیص داد.
4 – مسائل و وضعیت هایی که در آن ها نیاز به تعامل زیادی بین کاربر و سیستم است.
در بسیاری از سیستم های اطلاعاتی ، مشارکت کارکنان و کاربران تاثیر زیادی روی اجرای آن ها می گذارد. در چنین پروژه هایی باید از متدولوژی استفاده کرد که علاوه بر توجه به مسائل ایستایی فنی ، مشارکت و درگیری کاربران را نیز در نظر بگیرد. یکی از متدولوژی های مهم در این طبقه ، متدولوژی ETHICS است که توسط Mumford در سال 1995 پایه گذاری گردید. این متدولوژی به معنی سیستم های اجرایی انسانی و فنی و کامپیوتر محور است که به تشویق مشارکت کاربران می پردازد و باعث تعهد بیشتر آن ها به پروژه می شود[1]. ETHICS مبتنی بر رویکرد فنی و اجتماعی است. به تامین ابزارها برای تحلیل و هدفگذاری با مشارکت کاربران ، متمرکز است. نکته مهم اینجاست که رویکرد مشارکتی در مسائلی که کاربران و افراد تمایل به درگیری در پروژه ندارند و یا مجبور باشند با استفاده از زور در پروژه دخیل شوند ، کارساز نخواهد بود ، بلکه سازمان باید در این زمینه فرهنگ سازی کرده و سیاست ها و نگرش های خود و افراد سازمان را تغییر دهد. سازمان باید سطوح سلسله مراتبی بوروکراتیک خود را تغییر دهد و درجه انعطاف پذیری را بالا برد.
5 – مسائل و وضعیت های پیچیده
بسیاری از محققین اذعان کرده اند که یک نوع از بهترین متدولوژی برای همه وضعیت ها و مسائل وجود ندارد. انتخاب متدولوژی بستگی به ویژگی و ماهیت پروژه دارد. و برای اجرای یک پروژه سیستم اطلاعاتی بهتر است به بررسی متغیرهای درونی و بیرونی آن پروژه پرداخت. طبقه بندی متدولوژی ها ، صرفا برای این است که ما با ویژگی های هر یک به طور جداگانه آشنا شویم و با این کار نمی خواهیم بگوییم که یکی بر دیگری برتری دارد. بلکه باید به بررسی وضعیت کل پروژه و حتی بخش های یک پروژه پرداخت و سپس متدولوژی مورد نظر را انتخاب کرد. در این حالت ، متدولوژی مقتضیانه بهترین تصمیم است.
در این کلاس ، رویکرد Multiview یا نگرش چندگانه مورد بررسی قرار می گیرد. به جای انتخاب هر یک از متدولوژی ها ، در هنگام مواجه شدن با مسائل بهتر است از رویکرد مقتضیانه در فرایند توسعه استفاده نمود. رویکرد چند نگرشی دارای یک ساختار منعطف است و با توجه به وضعیت های خاص یک مساله ، تکنیک ها و ابزارهای مرتبط را پیشنهاد می دهد. این متدولوژی دارای 5 فاز می باشد که عبارتند از : تحلیل سیستم های فعالیت انسانی ، تحلیل اطلاعات ، تحلیل و طراحی سیستم های اجتماعی – فنی ، طراحی روابط متعامل انسان با کامپیوتر و طراحی جنبه های فنی. در ارتباط با این رویکرد باید به سوالات زیر پاسخ داد تا بعد از تحلیل پاسخ ها ، اقدامات مناسب را به عمل آورد[1].
از سیستم های اطلاعاتی که برای اجرای فعالیت های سازمانی توسعه می یابند ، چگونه حمایت می شود؟
سیستم های اطلاعاتی در سازمان ، چگونه با زندگی کاری افراد تناسب پیدا می کنند؟
افراد چگونه می توانند به بهترین وجه با کامپیوتر در تعامل باشند؟
برای پردازش اطلاعات در اجرای سیستم از چه فرمول ها و توابعی استفاده می شود؟
چه مشخصات فنی از سیستم با تجهیزات شناسایی شده ، در ارتباط هستند؟
در متدولوژی چندگانه می توان از رویکرد ترکیب در استفاده از متدولوژی های توسعه سیستم های اطلاعاتی استفاده کرد. در این روش ، سازمان ها با استفاده از برون سپاری بعضی فرایندها و اجرای توسعه روی فرایندهای کلیدی خود ،  هزینه های خود را کاهش می دهند. آن ها بر اساس موقعیت های مختلف یک پروژه ، از متدولوژی خاص آن وضعیت استفاده کرده و در انتها برای بستن پروژه ، متدولوژی های برون سپاری شده و درونی را با هم ترکیب می کنند[8]. این کار باعث افزایش کیفیت و تخصصی شدن بخش های پروژه شده ، قابلیت نگهداری افزایش می یابد و بهره وری رشد می کند. از این استراتژی ، جدیدا در فرایند توسعه نرم افزار در محیط های شی گرایی و ایجاد کلاس ها و شناسایی اجزا ، استفاده می کنند. نتیجاتا اینکه بهره گیری از این فلسفه در محیط های پویا و همراه با تغییرات زیاد ، بسیار مفید است. زیرا علی رغم تغییرات در فرایندها ، اشیا و اجزای یک سیستم را می توان جداگانه با متدولوژی های مختلف و با استفاده از برون سپاری ، توسعه داد.


متدهای چابک و پویا در توسعه سیستم های اطلاعاتی

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


از ترکیب این دو استراتژی ، پنج استراتژی شکل می گیرد که عبارتند از[2]:
DSDM خطی: که در آن تنها یک بار از استراتژی تکاملی استفاده می شود.
One – pass DSDM: این استراتژی با ترکیب یک رویکرد تکاملی و چند رویکرد تکرار ، بوجود می آید.
Hybrid DSDM: به معنی استراتژی است که شامل چند رویکرد تکاملی بوده در بعضی از این رویکردها چند بار از رویکرد تکرار استفاده می شود.
Full DSDM : ترکیبی از رویکردهای تکاملی و تکرار و از هر کدام چند بار
Phased DSDM : استفاده از رویکردهای تکاملی در چندین مرحله و بدون بهره بردن از رویکرد تکرار
در انتخاب هر یک از اینها باید به نوع پروژه و وضعیت مشارکت کاربران توجه کرد. قبل از اجرای این متدولوژی ها ، بهتر است بین مدیران و مربیان ،  توافقاتی بر سر زمان و بودجه پروژه ها صورت گیرد. نکته برجسته در اجرای این رویکردها ، رضایت مندی و مشارکت کاربر در فرایند توسعه می باشد. گرفتن بازخور از کاربر علاوه بر اینکه باعث تقویت مداخله کاربر در پروژه می گردد ، اصولا عملی مهم در موفقیت هر یک از رویکردهای افزایشی و تکرار است.


متدولوژی Fujitsu در توسعه سیستم های اطلاعاتی

شخصی به نام Fujitsu به توسعه یک سیستم اطلاعاتی پرداخته است که معماری و پشتیبانی توسعه سیستم (SDAS) نام دارد[7]. این متدولوژی برای تکنولوژی های جدید کاربرد زیادی دارد. استفاده از این متدولوژی باعث بهبود کیفیت و کاهش زمان توسعه سیستم می گردد. به تعریف دقیق الزامات و نیازمندی ها می پردازد. قابلیت های توسعه و نگهداری فرایند توسعه در این متدولوژی ، بالاست و از ابزارهای موثری برای اتومات کردن تست و مستندسازی استفاده می کند.
SDAS یک متدولوژی جامع توسعه سیستم است که نخستین نسخه آن در سال 1980 توسط Fujitsu برای حمایت از زیرساخت های COBOL ایجاد گردید. سپس در سال 1990 ، این متدولوژی برای پشتیبانی از سیستم های Client – Server ، مورد تجدید نظر قرار گرفت. در نهایت نسخه جدید آن برای بهبود کیفیت و کاهش زمان توسعه در سیستم های مبتنی بر وب و در کل چرخه تکاملی سیستم ، ساخته شد.
ساختار این متدولوژی همان طور که در شکل زیر نشان داده شده ، از موارد زیر تشکیل یافته است : برنامه ریزی سیستم سازمان ، پشتیبانی از توسعه کاربردی (شامل : الزامات ، طراحی ، اجرا و تست) ، فرایندهای توسعه و مدیریت پروژه ، نگهداری.


شکل 1: ساختار متدولوژی SDAS

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

جنبه های فرهنگی و اجتماعی متدولوژی های توسعه سیستم های اطلاعاتی

اکثر متدولوژی های توسعه سیستم های اطلاعاتی در سال های 1967 تا 1977 ظهور کرده اند. فنونی مثل دیاگرام جریان داده، مدل روابط موجودیت و مفاهیمی مثل شی گرایی و چرخه زندگی توسعه سیستم در مراحل بعدی پا به عرصه وجود گذاشتند. در این دهه بیشتر محققین با رویکرد مهندسی و ریاضی به توسعه سیستم ها می پرداختند. به عنوان مثال Davis در 1988 و Orr در 1989 اعتقاد داشتند که SDLC پایه ای برای متدولوژی های دیگر در توسعه سیستم ها است [4]. این واژه در بسیاری از رشته های مهندسی وجود دارد. Friedman در 1989 و Kraft در 1977 اشاره کرده اند که معرفی این مفهوم در توسعه سیستم همزمان با تمایل به برقراری یک رویکرد مهندسی در توسعه سیستم بود.[4]از طرفی در چهل سال گذشته رویکردهای سخت نسبت به توسعه سیستم وجود داشتند؛ سپس متدهای نرم جای آن ها را گرفتند. SDLC به توسعه سیستم نگاهی سخت داشت. Laudon در 1995 ضعف های اصلی SDLC را این گونه برشمرد[6]: هزینه زیاد سیکل توسعه، زمانبر بودن چرخه، عدم انعطاف پذیری و سستی در تغییرات ایجاد شده توسط SDLC.
نکته اساسی این است که استفاده از متدولوژی های مرسوم، ضامن موفقیت اجرای سیستم های اطلاعاتی نیست. بعضی از متدها تنها بخشی از نیازهای سیستم را برطرف می کنند. به عنوان مثال مرکز محاسبات ملی در UK، فرایند توسعه سیستم را اینگونه تعریف می کند[6]: مطالعه امکان سنجی، تحلیل و بررسی سیستم، توسعه سیستم، اجرا، بازنگری و نگهداری. این تعریف، بیشتر جنبه تکنیکی دارد. متدولوژی هایی که این تعریف را انتخاب کرده اند به متدولوژی سخت معروف اند. چنین رویکردی نیازهای فنی کارکنان را در توسعه برطرف می سازد ولی تضمین کننده الزامات غیرفنی نمی باشد. Sawyer در سال 1994 اذعان کرد که SDLC یک اکسیر نیست بلکه هنوز هم می توان پروژه هایی را پیدا کرد که هنگام اجرای این متد در توسعه با شکست مواجه می شوند. این نگرش که تنها بعد فنی و کاربردی در توسعه سیستم مطرح است، به شکست توسعه منجر می شود[6]. شکل زیر نشانگر این است که چگونه مباحث فنی در فرایند توسعه سیستم غالب شده اند.


شکل 2: غالب بودن مباحث فنی در فرایند توسعه سیستم
اگر چه اندیشمندانی مثل Klein و Hirschheim در سال 1987 به توسعه سیستم نگاهی فنی و تکنیکی داشتند، Land در سال 1985 اعتقاد داشت که سیستم های اطلاعاتی، سیستم هایی اجتماعی هستند که فناوری اطلاعات در آن قرار گرفته است[6] ؛ Lyytinen در 1987 اشاره کرد که در طراحی سیستم ها باید به ابعاد فرهنگی، اجتماعی و سیاسی نیز همانند تکنیکی توجه گردد. بدین ترتیب مشارکت کارکنان در توسعه سیستم امری الزامی و حیاتی است. می توان توسعه سیستم های اطلاعاتی را از دو بعد نگریست: 1- بعد تکنیکی 2- بعد رفتاری،فرهنگی،اقتصادی،اجتماعی و سیاسی. نکته مهم اینکه درنظر گرفتن تنها جنبه های تکنیکی در توسعه، مباحثی مثل پیچیدگی و تغییرات محیطی را لحاظ نمی کند. اگر کارمندان در توسعه سیستم مرتبا به سمت ابعاد تکنیکی روی آورند، شاید یک موفقیت فنی حاصل شود ولی سازمان با شکست مواجه می گردد. پس بهتر است در توسعه به مشکلات و مسائل رویکردی کل نگر داشته باشیم. شکل زیر از جنبه ای دیگر به توسعه سیستم های اطلاعاتی می نگرد[6]. یعنی فرض می کند که ابتدا سیستم اطلاعاتی وارد سازمان می شود، سپس با مباحثی روبرو می گردد که برای موفقیت توسعه الزامی و حیاتی است.


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

Avison در 1995 متدولوژی های توسعه مثل SSADM را مورد نقد قرار داد[9] او معتقد بود که این روش ها تنها بر ابعاد رسمی و فنی متکی هستند و اینکه توسعه سیستم بهتر است از جنبه تکنیکی به نگرش های رفتاری و اجتماعی انتقال یابد. همچنین Wood Harper در سال 1996 اذعان کرد که در توسعه سیستم های اطلاعاتی بهتر است موارد زیر نیز در نظر گرفته شود[9]: میزان اثرگذاری جنبه های رفتاری در توسعه سیستم، تعیین نوع متدولوژی متناسب با نوع رفتار در سازمان، اتخاذ رویکردی مناسب در توسعه در هنگام مواجه شدن با تعارضات سازمانی.
فرهنگ نیز یکی از مهم ترین مباحث در سازمان های امروزی می باشد. سیستم های اطلاعاتی به عنوان یکی از رویکردهای نوین در سازمان ها از این قاعده مستثنی نیستند. به محض ورود یک سیستم اطلاعاتی جدید در سازمان نیاز به تغییر فرهنگ است. Boynton در سال 1987 اعتقاد داشت که توسعه سیستم های اطلاعاتی نیاز به موارد زیر دارد[5]: تحلیل فرهنگ درون سازمانی، ارزیابی سیاست و توزیع قدرت در سازمان، تعیین میزان پذیرش سیستم های اطلاعاتی توسط کارکنان، ارزیابی ریسک، اطمینان از مشارکت اعضای سازمان در توسعه و شناسایی موارد بحرانی اجرای سیستم های اطلاعاتی در سازمان.









نتیجه

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














مراجع


[1] Avison D.E.; Taylor V.,”Information Systems Development Methodologies: A Classification According To Problem Situation”,Journal of Information Technology,1997,73-81.
[2] Aydin Mehmet Naflz; Harmsen Frank; Slooten Kees Van;Stegwee Robert A,”An Agile Information Systems Development Method in Use”,Turk J Elec,Vol.12,No.2, 2004.
[3] Fitzgerald Brian, “Formalised Systems Development Methodologies: A Critical Perspective”,forthcoming in Information Systems Journal,1996.
[4] Fitzgerald Brian,”Systems development methodologies: the problem of tenses”,http://WWW.emerald-library.com,Information Technology & People, Vol.13 No.3,2000, pp.174-185.
[5] Maguire Stuart;Redman Tom,”The role of human resource management in information systems development”,http://WWW.emerald-library.com,Management Decision Vol.45 No.2,2007,pp.252-264.
[6] Maguire Stuart,”Towards a business-led approach to information systems development”,http://WWW.emerald-library.com,Information Management & Computer Security, 8/5 [2000],230-238.
[7] Oshima Takeshi;Kashiwagi Masayuki;Fukao Hiroshi,“Fujitsus System Development Methdologies: SDAS”FUJITSU Sci.Tech.J.,42,3,2006,p.277-285.
[8] Papatsoutsos Dimitrios,“Information Systems Development Methodologies in the Age of Digital Economy”,University of Athens Department of Informatics University Campus TYPA Buildings, 2005.
[9] Rogerson Simon; Weckert John; Simpson Chris,”An ethical review of information systems development”,http://WWW.emerald-library.com,Information Technology & People, Vol.13 No.2, 2000, pp, 121-136.
ارسال شده توسط احمد محمدی | 30 11, 2013 | بازدید‌ها (1255)

مروري بر 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 | بازدید‌ها (1291)

مقدمه
امروزه با پیشرفت فناوری، سازمان ها به دنبال راه ها و ترفندهایی می گردند که بقایشان را در این عرصه تضمین کنند. سازمان ها می دانند که دیگر بقای آنها تنها در رسیدن به وضعیت سوددهی مداوم نیست و باید به دنبال رقابت و ابزار آن باشند. همچنین می دانند که کلید موفقیت در عصر اطلاعات، اتخاذ تصمیماتی است که بدون تناقض، بهتر و سریع تر در رقابت پیش دستی کند.
یک سازمان در طول حیاتش، داده ایجاد می کند. این داده معمولا پیرامون دارایی، بازاریابی، فروش، منابع انسانی، مدیریت ارتباط با مشتری و ... گروه بندی می شوند و هر بخش یک وظیفه جدا در شرکت انجام داده و داده های مرتبط به خود را جمع آوری می کند. این حقیقت سازمان ها را ملزم به جستجوی ابزارهایی برای تسهیل فرایند کسب اثربخش داده ها، پردازش و تحلیل وسیع آنها کرده است تا براساس آن پایه ای را برای کشف دانش جدید بنا نهند.
برای سالیان متوالی از سیستم های اطلاعات مدیریت موجود مانند: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 | بازدید‌ها (1829)

مفهوم هوش تجاري 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 | بازدید‌ها (1151)

پنج کليد موفقيت هوش تجاری
هوش تجاري در حال گسترش است. به همان نسبت که تقاضا براي پياده‌سازي هوش تجاري در سازمان‌ها و کسب و کارهاي گوناگون رشد مي‌کند، مفاهيم و سيستم‌هاي هوش تجاري توسعه مي‌يابند.
اما سوال اين است که آيا صرف وجود ابزارهاي قوي و متنوع مي‌تواند موفقيت يک سازمان را در دست‌يابي به هوش تجاري تضمين نمايد؟ در اين مقاله با نگاهي دوباره به تعاريف هوش تجاري از نگاه متخصصين، پنج راهکار و نکته را براي موفقيت در دست‌يابي به هوش تجاري ذکر مي‌کنيم.
نگاهي به تعاريف هوش تجاري:
 
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 | بازدید‌ها (1334)
بررسی 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 | بازدید‌ها (3081)

همه چیز درباره 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 | بازدید‌ها (877)

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 | بازدید‌ها (1737)

  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

درباره من

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

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

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

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

    ahmad.mohammadi.a@gmail.com

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