— (290)

-84963024574500
1959610-237490
00

وزارت علوم، تحقيقات و فناوري
دانشگاه علوم و فنون مازندران
پايان نامه
مقطع كارشناسي ارشد
رشته: فناوري اطلاعات
عنوان: ا ارائه یک چارچوب سرویس گرا مبتنی بر سیستم پشتیبان تصمیم , در معماری ERP مورد کاوی در شرکت‌های خودرو ساز
استاد راهنما: دكتر بابك شيرازي ، دكتر ايرج مهدوي
استاد مشاور: دكتر همايون مؤتمني
دانشجو: معصومه اسدي نژاد
با سپاس از خدای مهربان که توفیق پیمودن این راه را
به بنده عطا نمود و تشکر و قدر دانی از زحمات استاد گرامی
, جناب آقای دکتر شیرازی که بنده را بسیار یاری نمودند.

تقدیم به خواهر عزیزم که همواره مشوق و راهنمایم بود
فهرست مطالب
فصل اول:کلیات
1-1 مقدمه2
1-2 فرضیات مسئله 4
1-3 هدف از اجرا :4
1-4 توجيه ضرورت انجام پروژه5
1-5 سوال تحقیق7
1-6 روش پژوهش و تکنیک‌های اجرائي7
1-7 روش تحقیق8
فصل دوم: مرور ادبیات موضوع
2-1مقدمه10
2-2 ERP 10
2-2-1مفهوم15
2-2-2 تعاریف 15
2-3 سرویس گرایی20
2-3-1 محاسبات سرویس گرا 22
2-3-2 معماری سرویس گرا 25
2-3-3 تعریف 26
2-3-4 مفاهیم اصلی معماری سرویس گرا29
2-3-5 اجزا اصلی یک معماری سرویس گرا31
2-3-6 علت استفاده از معماری سرویس گرا32
2-4 مدیریت فرایند کسب و کار و معماری سرویس گرا 33
2-5 سازمان سرویس گرا 34
2-6 فرایند کسب و کار سازمان 38
2-7 سیستم پشتیبان تصمیم 42
2-7 -1 تصمیم گیری42
2-7-2 دسته بندی مسائل تصمیم بر مبنای سطوح تصمیم گیری:45
2-7-3 فرایند تصمیم گیری46
2-7-4تعریف48
2-7-5 مفهوم سیستم‌های پشتیبان تصمیم50
2-7-6 انواع سیستم‌های پشتیبان تصمیم گیری51
2-7-7 روش‌های پشتیبان تصمیم گیری52
2-7-8سیستم پشتیبان تصمیم گیری و اجزا آن53
 2-7-9 سیستم مدیریت پایگاه داده55
2-8 رویکرد های دیگر 55
2-9 مهندسی مجدد 58
2-9-1تعریف مهندسی مجدد59
2-9-2 مرور ادبیات مهندسی مجدد60
2-9-3 عوامل شكست پروژه‌هاى مهندسي مجدد61
2-9-4عوامل موفقيت پروژه‌هاى مهندسى مجدد61
2-10 جمع بندی 63
فصل سوم:یافته های تحقیق
3-1 مقدمه65
3-2 مدل سازی سازمان66
3-3 پیاده سازی BPR 67
3-3-1 لزوم و نیاز67
3-3-2 گام‌های BPR 69
3-3-3 انواع متدولوژی های مهندسي مجدد72
3-3-4 روش‌های مناسب خاص شرکت‌های تولیدی ايراني كدامند؟73
3-3-4 اجرای BPR74
3-4 تحلیل سازمان 79
3-4-1 تحلیل با استفاده از نمودار ایشی کاوا79
3-4-2 تحلیل با استفاده از نمودار پارتو82
3-4-3 تحلیل کمی سازمان 84
3-4-3-1 نرخ توقف خط تولید 84
3-5 مدل تصمیم گیری در سیستم پشتیبان تصمیم 87
3-5-1 روش تصمیم گیری87
3-5-2 برپائی پایگاه (مخزن) خریدها:91
3-5 -3 بازیابی94
3-5-4 تصمیم گیری 96
3-6 تجمیع سیستم برنامه ریزی منابع سازمانی و سیستم پشتیبان تصمیمگیری96
3-7 ساختار ERP در زنجیره تأمین 98
3-8 معماری داخلی ERP بخش‌های سازمانی100
3-9 معماری DSS عمومی104
3-10 بستر ارتباطی106
3-11 نحوه اجرا107
فصل چهارم: ارزيابي
4-1 مقدمه110
4-2 مقایسه چارچوب با چارچوب‌های دیگر(bench marking)110
4-2-1 بیان پارامتر های مقایسه110
4-2-2 مقایسه قابلیت‌های چارچوب‌ها112
4-3 تحلیل با استفاده از پرسشنامه 114
4-3-1 مشخصات پاسخ دهندگان114
4-3-2 بررسی قابلیت اعتماد پرسشنامه 118
4-3-3 پرسشنامه:122
4-3 شبیه سازی 130
فصل پنجم نتیجه گیری و پیشنهادات
5-1 خلاصه148
5-2 مزایای اجرای این پروژه148
5-3 معایب150
5-4 نتیجه گیری 150
5-5 پیشنهادات با توجه به مورد کاوی برای پیاده سازی ERP های تجمیعی151
5-6 کار های آینده152
منابع 154
پیوست ها162
ضميمه ب: فراوانی پاسخ پرسشنامه 158
چكيده لاتين185
فهرست اشكال و نمودار
شكل 1-18
شكل 2-1- دلایل تکنولوژیکی پیاده سازی ERP [8]14
شكل 2-2- دلایل تجاری پیاده سازی ERP [8] 14
شكل 2-3- لایه‌ها در تحولات از MRP تا ERP توسعه یافته [10] 17
شكل 2-4- يکپارچگي اطلاعات محيطي در سيستم ERP [10]18
شکل 2-5- گام‌های دست یابی به حاکمیت معماری سرویس گرا22
شکل 2-6- حاکمیت معماری سرویس گرا و چرخه در بر گیرنده25
شکل 2-7- حاکمیت معماری سرویس گرا در سازمان و تبدیل سازمان به یک سازمان سرویس گرا34
شكل 2-8- فازهاي سيستم سرويس گرا36
شکل 2-9- هرم‌های مؤلفه های فنی و رهبری خدمت گذار در سازمان سرویس گرا [26]37
شکل 2-10- لایه های بنیادی سازمان سرویس گرا 38
شكل 2-11- فرآيند كسب و كار39
شکل 2-12- فرایند کسب و کار در سیستم سازمانی40
شكل 2-13- مدل تصمیم گیری 3 فازی از هربرت سایمون47
شکل 2-14- توسعه يافته مدل تصميم گيري 3 فازي هربرت سایمون 47
شکل 2-15- ساختار یک سیستم پشتیبان تصمیم53
شکل (3-1) جنبه های مطرح درERP [52]65
شکل (3-2) – خروجی‌های مختلف از مدل‌های سیستم مورد استفاده در چارچوب معماری ERP67
شکل (3-3) چرخه شناخت اولیه سازمان70
شکل (3-4) گام‌ها یا بخش‌های شناخت اولیه سازمان74
شکل (3-5) فرایند مونتاژ در وضعیت موجود یک سازمان تولید کننده خودرو75
شکل (3-6) ادامه فرایند مونتاژ در وضعیت موجود یک سازمان تولید کننده خودرو77
شکل (3-7) ادامه فرایند مونتاژ در وضعیت موجود یک سازمان تولید کننده خودرو78
شکل (3-5) نمودار علی و معلولی زمان تولید 80
شکل (3-6) – نمودار علی و معلولی نرخ بالای تولید خودروی معیوب 81
شکل (3-7) – نمودار علی و معلولی نرخ بالای دوبارهکاری 82
شکل (3-8) – نمودارپارتو-زمان تأخیر فرایندها 83
شکل (3-9) – نمودار پارتو-نرخ مازاد کار-دوبارهکاری 83
شکل (3-10) – نمودار پارتو-ایرادات کیفی مربوط به بررسی کیفیت بخش 83
شکل (3-11) – نمودار پارتو- هزینه مازاد تحمیلی زمان و کارکرد83
شکل (3-12) -نمودار xbar chart نرخ توقف85
شکل (3-13) -نمودار R chart نرخ توقف85
شکل (3-14) -نمودار ترکیبی Xbar chart و R chart نرخ توقف85
شکل (3-15) نمودار توزیع پراکندگی86
شکل (3-16) -نمودار شش سیگما از نرخ 86
شکل (3-17) – شاخص های قابلیت فرایند86
شکل (3-18) چرخۀ روش استدلال بر مبنای مورد CBR [6]89
شکل (3-19) مدل تصمیم گیری در سطح کلان90
شکل (3-20) نمایش متغیر های فازی در نرم افزار MATLAB92
شکل (3-21) – چارچوب CoERP – چارچوب سرویس گرا از collaborative ERP97
شکل (3-22) چارچوب DE (DSS-ERP ) بستر مناسب جهت تجمیع ERP و DSS در سیستم توزیع شده98
شکل (3-22) معماری سازمان تولیدی و معماری سیستم پشتیبان تصمیم خصوصی103
شکل (3-23) – Public web server DSS برای تجمیع و هماهنگ کردن عملکرد کلیه سیستم‌ها104
شکل (3-24) – مکانیزم‌ها و ماژول‌های مورد نیاز برای پیاده سازی سیستم ERP توزیع شده106
نمودار (4-1) سطح تحصیلات شرکت کنندگان در پرسشنامه115
نمودار (4-2) مربوط به رشته های شرکت کننده در تحقیق116
نمودار (4-3) تجربه کاری شرکت کنندگان در تحقیق117
نمودار (4-4) فراوانی میانه پاسخ‌های استخراج شده از پرسشنامه128
نمودار (4-5) فراوانی مربوط به میزان رضایت از حوزه های مختلف مطرح در پرسشنامه129

فهرست جداول
جدول2-1- پيشرفت سيستم ERP12
جدول 2-2- عنوان دهی به ERP و وزن آن‌ها از نظر شرکت‌ها [10]19
جدول (3-1) شاخص‌ها مطرح در صنعت تولید79
جدول (3-2) نحوه ارزیابی معیار انتخاب فروشنده93
جدول (3-3) ساختار نگه داری اطلاعات خریدها (مخزن خریدها)93
جدول (4-1) مقایسه چارچوب‌های شرکت‌های مطرح با چارچوب پیشنهادی113
جدول (4-2) میزان تحصیلات شرکت کنندگان در تحقیق115
جدول (4-3) سطح تحصیلات شرکت کنندگان در پرسش116
جدول (4-4) تجربه کاری شرکت کنندگان در تحقیق117
جدول (4-5) فراوانی مربوط به پاسخ‌های پرسشنامه در نرم افزار SPSS123

فهرست رابطه‌ها
رابطه (3-1) 84
رابطه (3-2)84
رابطه (3-3)85
رابطه (3- 4) 85
رابطه (3-5)86
رابطه (3-6) 90
رابطه (3-7) 91
رابطه (3-8)91
رابطه (3-9) 94
رابطه(3-10)95
رابطه(3-11) 95
رابطه (4-1) 120
رابطه (4-2) 120
رابطه (4-3) 121

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

1-1 مقدمه:
فشارهای هزینه و رقابت بین سازمان‌های امروزی باعث شده که سازمان‌ها به سمت ایجاد یک بستر یا چارچوب مناسب و در عین حال ساده و سازگار بروند تا بتوانند در بازار رقابتی با توان بالا حرکت کنند. در این بستر توسعه به جای کاغذ بازی‌ها و تصمیم‌گیری‌های پایه‌ای، از راه حل‌های یکپارچه و جامع که عملیات‌های مدل سازی، شبیه سازی، پایش، طراحی و بهبود را انجام دهد، استفاده می‌کنند. که لازمه‌ی عملیاتی شدن این راه حل، استفاده از بستر سرویس گرایی و برنامه‌های کاربردی مدیریت منابع سازمان به صورت یکپارچه است.
ماهیت مدیریت فرایند کسب و کار و معماری سرویس گرا می‌توانند مکمل همدیگر باشند. در هر سازمان در ابتدا شاکله سازمان از طریق فرایندهای کسب و کار بدست می‌آیند. این فرایندها برای ارتباطات بینابینی خود به تکنولوژی و فناوری‌های ارتباطی نیازمندند که شکل بارز و بهینه آن در معماری سرویس گرا مطرح و بیان می‌شود. لذا این دو در کنار هم و با همکاری هم می‌توانند به بهبود سازمان کمک کنند.
از عوامل مطرح در سازمان‌ها برنامه‌ریزی منابع سازمان است. این برنامه‌ریزی شامل کلیه تأمین‌ها و برنامه‌ریزی‌های از تا مین اولیه و برنامه تأمین کنندگان شروع و نهایتاً تا تحویل به مشتری و خروج از سازمان ادامه پیدا می‌کند. این برنامه ریزی را اصطلاحاً ERP گویند.
در حال حاضر نقاط ضعفی در ERP وجود دارد: (1) علی رغم دستاوردهای آن در فرایند مدیریت و برنامه‌ریزی منابع، نمی‌تواند به مدیریت جامع بلادرنگ پویا که برای پاسخ به تغییرات عملی و تصمیم‌گیری معقول مهم است، دست پیدا کند. (2) خیلی از شرکت‌ها هنوز از ERP در یک سطح مشترک مثل سیستم‌های اطلاعاتی عمومی (که هدف ان‌ها جمع آوری اطلاعات ، انتقال ، محاسبه است)، استفاده می‌کنند، علاوه بر این، ماژول پشتیبان تصمیم در ERP ، فاز جمع آوری اطلاعات را به جای تجزیه و تحلیل جامع نگه می‌دارد. (3)عدم انعطاف پذیری ERP در روش تکراری تجزیه و تحلیل در شرکت‌های مختلف، و نتیجه‌گیری‌های غیرمنطقی و نامناسب. (4) در حال حاضر، ERP به خوبی در مدیریت اطلاعات داخلی سازمان کارش را انجام می‌دهد، اما ERP در تعامل خارجی و تصمیم گیری گروهی نمی‌تواند اقدامات موثری انجام دهد. (5)امروزه با توجه به توسعه سرویس گرایی و همچنین وجود سازمان‌های شبکه‌ای و گسترده، نیاز به پیاده‌سازی ERP در قالب گسترده و همکار، وجود دارد. اما با توجه به عدم وجود زیر ساخت‌های مناسب و عدم به کار گیری چارچوب کلان و منطبق در جهت بهبود عملکرد ERP , کارایی مناسب محقق نمی‌گردد.
لذا با توجه به نقاط ضعف بیان شده نیاز به چارچوبی کاملاً یکپارچه که کلیه نقاط ضعف را پوشش دهد الزامی است. آن چه که امروزه علاوه بر بحث یکپارچه سازی منابع سازمان لازم است،ایجاد یک محیط است که در آن قسمت‌های مجزای یک شرکت یا شرکت‌های مجزا ،خودشان بتوانند فعالیت‌هایشان را مدیریت کنند و با سایر قسمت‌های کسب و کار و شرکایشان و همچنین مشتریان و تأمین کنندگان، بتوانند تعامل داشته باشند. پس هدف ایجاد محیطی است که کاربران، خصوصاً در سازمان‌های تولیدی، فرایندهای کسب و کارشان را در زیر ساخت‌های کسب‌وکار صرف نظر از آنکه در داخل یا بیرون شرکت باشند، مدیریت کنند.
این امکان برآورده نمی‌شود مگر با فراهم کردن بستر سرویس‌ها. در چنین بستری برنامه‌ریزی‌های منابع سازمان به شکل سرویس‌های مورد نیاز درخواست و در وب سرور مرکزی، سرویس‌دهی می‌شوند. کارایی در سیستم‌هایERP را می‌توان با پیش بینی صحیح زمان و کمیت‌ها، یکپارچگی همه جانبه و کاهش خطا‌ها و بهبود عملکرد ,به شکل قابل توجهی افزایش داد. اما همواره درصدی از خطا امکان وقوع دارد، که نتیجه معکوس در کارایی را ایجاد می‌کند. این خطاها میتوانند خطای محاسباتی و یا حتی اشتباهات و خطاهای حیاتی‌تری باشند.بنابراین استفاده از یک سیستم پشتیبان تصمیم, DSS, همواره خطر وقوع خطا را به همراه خواهد داشت. بنابراین با استفاده محض از این سیستم‌ها، دست‌یابی به اهداف سیستم به خطر خواهد افتاد. بنابراین نیاز است که همواره صحت این تصمیمات بررسی و سپس به عنوان تصمیم به سیستم القا شود. لذا، برای بهبود عملکرد ERP، نیازمند سیستم همکار پشتیبان تصمیم هستیم. علت اینکه این سیستم‌ها برای استفاده در مقیاس‌های مختلف و به شکل وسیع فراهم می‌شود، این است که افراد زیادی در سیستم از تصمیم‌گیری‌های مشابهی استفاده می‌کنند. بنابراین به آن‌ها امکان استفاده از الگوریتم‌های استاندارد و یا استفاده از چارت‌های مختلف را می‌دهد.
1-2 فرضیات مسئله:
در این پروژه، سازمان‌های تولید در صنعت تولید خودرو در ایران در نظر گرفته شده است.
معماری سرویس گرا بدون در نظر گرفتن زبان و ماشین مورد استفاده برای اجرای سرویس‌ها، یک چارچوب برای سرویس‌های ارتباطی توزیع شده فراهم می‌کند.
معماری و ساختار ERP به گونه‌ای است که یکپارچگی و جامعیت اطلاعات سطح سازمان را فراهم نموده و جریانی روان از اطلاعات بین بخش‌های مختلف سازمان فراهم می‌کند.
سیستم پشتیبان تصمیم، سیستمی جهت یادگیری، تأمین انعطاف پذیری، پاسخگویی سریع، پوشش دادن تغییرات و کمک به تصمیم گیری در زمینه های مختلف است.
چارچوب و زنجیره تولید مد نظر, از SCM شروع تا تولید و مونتاژ و تحویل به مشتری و CRM ادامه می‌یابد و چارچوب با نگاه به کل زنجیره ایجاد می‌گردد.
چارچوب سرویس گرا، با ساختاری مبتنی بر فناوری است و تبادلات اطلاعات با استفاده از سرویس‌ها انجام می‌شود.
1-3 هدف از اجرا :
اهداف اصلی که در این پایان نامه مد نظر قرار خواهد گرفت:
حاکمیت معماری سرویس گرا
توسعه چرخه عمر مدیریت فرایند کسب و کار و مدیریت منابع سازمان در جهت پوشش چرخه عمر معماری سرویس گرا
افزایش چالاکی، کاهش هزینه برای سازمان‌های تولیدی و ایجاد یکپارچگی بین سیستم‌های اطلاعاتی و فناوری زیر ساختی
رسیدن به مدل یکپارچه با اجماع ایده های مطرح در دو حوزه کسب و کار و فناوری اطلاعات
کاربردی کردن مدل پیشنهادی با در نظر گرفتن حدود مطالعه موردی
رسیدن به یک چارچوب و سکو جامع در جهت توسعه برنامه‌ریزی منابع سازمان در سیستم‌های سرویس گرا
هوشمند سازی سیستم با در نظر گرفتن سیستم‌های پشتیبان تصمیم در برنامه ریزی‌های سازمان‌های تولید و مونتاژ خودرو در ایران
بهبود فرایندها با استفاده از مهندسی مجدد فرایندها و سوق دادن سازمان از ساختار گرایی به فرایند گرایی با زیر ساخت فناوری در صنعت خودرو سازی
1-4توجيه ضرورت انجام پروژه :
امروزه می‌توان رشد اطلاعاتی در سازمان و پیچیده‌تر شدن فرایندهای کسب و کار را مشاهده نمود؛ لذا این سازمان‌ها به مدیریت و کنترل فرایندهای کسب و کارشان نیازمند می‌باشند. زیرا ساز و کارهای متنوع و مختلفی برای مدیریت بر فرایندهای کسب و کار تهیه و طراحی گردیده است. اما در این سیستم‌ها شناسایی و نظارت بر فرایندها از یک سو و کنترل عملکرد آن‌ها از سوی دیگر، همچنین ملموس شدن این فرایندها در دنیای واقعی مهم‌ترین دیدگاه‌هایی است که در فناوری اطلاعات مطرح می‌باشد و سیستم‌های کنونی این دو را مجزا می‌دانند. چرا که در گذشته در یک سازمان تجاری، فرایندها به عنوان هسته مرکزی قرار داشتند و برای هر فرایندی سیستم مجزایی را تهیه می‌کردند که به آن‌ها سیستم‌های جزیره ای می‌گفتند. به دلیل عدم ارتباط بین این سیستم‌ها و نداشتن یک مدل یکپارچه، اهداف کلی مدیریتی سازمان به نحو مناسبی پاسخ داده نمی‌شد. برای این منظور و رفع مشکلات، ایده های مدل‌های یکپارچه و همکار شکل گرفت.
در یک نگاه جامع، یک سیستم کسب و کار، ممکن است از چندین زیر سیستم مرتبط با یکدیگر تشکیل شده باشد. اما می‌دانیم که طراحی و پیاده‌سازی این سیستم‌ها حجم کاری زیادی را می‌گیرد. اما با توجه به ماهیت‌های فرایند کسب و کار (شامل تحلیل و شناسایی، مدل سازی، طراحی و بهبود و پایش فرایندها) و معماری و چارچوب سرویس گرا (شامل طراحی و پیاده سازی فرایندهای کسب و کار به صورت سرویس‌های کسب و کار) و سیستم‌های پشتیبان تصمیم، از این حجم کاری کاسته می‌شود.
اگر چه معماری سرویس گرا و مدیریت فرایند کسب و کار مستقلند، اما آن‌ها اهداف عمومی را به اشتراک می‌گذارند و باعث چابکی و چالاکی سازمان می‌شوند. پس برای کاستن حجم کاری در سازمان‌ها، رسیدن به چابکی و چالاکی و کاهش هزینه‌ها و داشتن یک سیستم یکپارچه و همکار و بنابراین کاهش زمان تولید در سازمان‌های تولیدی و در نتیجه بهبود وضعیت نهایی سازمان در بازارهای رقابتی، نیاز به یک سیستم یکپارچه و سرویس گرا برای مدیریت منابع سازمان، خصوصاً در سازمان‌های تولیدی امروزی الزامی می‌باشد.
بنابراین ضعف‌های موجود به قرار زیر است:
– عدم وجود فرایند گرایی و سلب و ساختار گرا بودن سازمان‌ها
– ضعف‌های ارتباطی
– جامع و یکپارچه نبودن اطلاعات و وجود سیستم‌های جزیره ای
– عدم وجود بستر و زیر ساخت مناسب فناوری
– نبود سیستم پشتیبان تصمیم که در تصمیم گیری‌های کلیدی و در لایه های مختلف مدیریتی به عنوان سیستم همکار، سازمان را یاری نماید
– نامناسب بودن فرایند های کسب و کار و هم راستا نبودن با اهداف
– عدم تحقق استراتژی‌ها و اهداف سازمان‌ها
– برنامه ریزی نامناسب منابع سازمان
– نا هماهنگ بودن برنامه ریزی‌ها و منابع سازمان با زنجیره تأمین، مشتریان و تأمین کنندگان
– هزینه های بالا و نامتناسب تولید
– عدم دستیابی به کیفیت مد نظر
– عدم هماهنگی با برنامه ریزی‌های زمانی
که جهت رسیدگی به این نقاط ضعف، چارچوبی با اهداف بیان شده ارائه خواهد شد.
1-5 سوال تحقیق:
با توجه به نقاط ضعف بیان شده , این سوالات ذهن خطور می کنند :
آیا با توجه به ضعف زیر ساخت فناوری و سلب بودن ساختار فرایند ها , امکان یکپارچه سازی سازمان و سیستم ها وجود دارد یا خیر؟
آیا با توجه به اینکه اهداف سازمان های تولیدی کنونی به حد رضایت بخش محقق نمی شوند, امکان ایجاد بستر های فناوری برای تحلیل وضعیت موجود و بهبود فرایند ها در جهت دست یابی به اهداف وجود دارد یا خیر؟
آیا امکان پیاده سازی بستر سرویس ها با توجه به وضعیت کنونی سازمان ها وجود دارد یا خیر؟
و نهایتا آیا امکان پیاده سازی چارچوبی سروس گرا و مبتنی بر سیستم پشتیبان تصمیم برای برنامه ریزی منابع سازمان های تولیدی گسترده و همکار وجود دارد یا خیر؟
1-6 روش پژوهش و تکنیک‌های اجرائي:
پس از مطالعات کتابخانه ای و مقالات موجود در سایت‌های معتبر و نمایه شده مربوط به حوزه برنامه ریزی منابع سازمان در معماری سرویس گرا و در سازمان‌های تولیدی همچنین تلفیق با مباحث سیستم‌های پشتیبان تصمیم به ارائه مدل و یا چارچوب پایان نامه می‌پردازیم؛ و سپس الگوریتم‌ها، گام‌ها و روش‌های مطرح شده در آن زمینه را توضیح خواهیم داد و با یک تحلیل به ارزیابی آن می‌پردازیم.
در این پروژه به صنعت خودرو به شکل میدانی وارد خواهیم شد و به دست یابی به اطلاعات در این حوزه خواهیم پرداخت، فرایندها را استخراج، تحلیل و مدل سازی و بعد از بررسی‌ها در داخل چارچوب سرویس گرا با زیر ساخت فناوری، بهبود خواهیم داد.
1-7 روش تحقیق:
676275258445شروع
بررسی روش‌های موجود
مطالعه موضوع
تحلیل راه حل‌های ممکن جهت پیشنهاد
انتخاب موضوع
ارائه چارچوب
ارزیابی چارچوب
استخراج پارامتر های ارزیابی
نگارش پایان نامه
پایان
00شروع
بررسی روش‌های موجود
مطالعه موضوع
تحلیل راه حل‌های ممکن جهت پیشنهاد
انتخاب موضوع
ارائه چارچوب
ارزیابی چارچوب
استخراج پارامتر های ارزیابی
نگارش پایان نامه
پایان

شكل 1-1 گام های تحقیق

فصل دوم
مرور ادبیات موضوع
2-1مقدمه:با توجه به نیاز بشر به فناوری اطلاعات و پیشرفته شدن دانش در این زمینه، رویکرد و چشم انداز بسیاری از سازمان‌ها به سوی به‌کارگیری فناوری اطلاعات می‌باشد؛ لذا در زمینه معماری سرویس گرا تحقیقات ارزنده ای انجام شده است. اما در زمینه ترکیب این معماری با مدیریت فرایند کسب و کار و ایجاد سازمان‌های یکپارچه، همکار، هوشمند و سرویس گرا به دلیل جدید بودن تجربیات زیادی وجود ندارد و در اغلب موارد شامل مثال‌های ساده ای از پیاده سازی بخشی و جزئی از این موارد (با توجه به نیاز سازمان خاص) می‌شود و ارائه چارچوب کلان در این زمینه در زمره تحقیقات روز دنیا قرار می‌گیرد.
2-2 ERP تاریخچه ERP و برنامه ریزی و مدیریت منابع سازمان به قبل از سال 1960 میلادی باز می‌گردد. [ 8]
در این برهه از زمان نرم افزارهایی به نام BOM PROCESSORS توسعه پیدا کردند. که هدف آن‌ها استخراج مواد لازم برای تولید تعدادی محصول بود. این نرم افزارها توجه زیادی به حجم تولید و یا به تعبیری دیگر Lot Sizing نداشته و از سوی دیگر زمان تحویل را هم مد نظر نمی‌گرفتند. به همین دلیل با استفاده از آن‌ها حجم موجودی در جریان افزایش پیدا نمی‌کرد.
بین سال‌های 1960 و 1970 , در اوایل این دهه تمرکز نرم افزاری بیشتر بر روی سیستم‌های کنترل موجودی بود. در این مدت همچنان بیشتر از مفاهیم سنتی کنترل موجودی برای توسعه نرم افزار های مرتبط استفاده می‌شد. اما در اواخر این دهه مفهوم MRP و یا برنامه ریزی مواد مورد نیاز معرفی و نرم افزار MRPΠ توسط IBM توسعه پیدا کرد. مهم‌ترین مشکل این نرم افزار و نرم افزار های مشابه، اجرای آن بر روی main frame های گران قیمت مستقر در مراکز دانشگاهی و یا نظامی بود؛ و همین امر فاصله زمانی بین برنامه ریزی‌ها را افزایش می‌داد. این سیستم به صورت بازگشتی زمان تحویل اقلام مورد نیاز برای ساخت یک محصول خاص را از زمان تحویل به مشتری تا زمان مورد نیاز برای مونتاژ، برنامه ریزی می‌کرد. سازمان‌ها در اجرای MRPΠ مشکلات زیادی داشتند. این مشکلات بیشتر مشکلاتی سیستمی و ناشی از کاربران بود تا مشکلات تکنولوژیکی. از طرف دیگر این سیستم ارتباط بین تولید و استراتژی‌های رقابتی سازمان را چندان مد نظر قرار نمی‌داد. ضمن ظرفیت‌های تولید سازمان چندان در این سیستم لحاظ نمی‌شد.
بین سال‌های 1970 تا 1980, تمرکز با توجه به برنامه کلان تولید یا MPS و توسعه MRP حلقه بسته بود. در این سیستم‌ها، امکان بروز رسانی در زنجیره تولید به حد اقل رسید اما همچنان این سیستم‌ها فقط برنامه ریزی تولید را انجام داده و حمایت چندانی از سایر منابع تولید نداشتند.
بین سال‌های 1980 تا 1990, گسترش MRPΠ به سایر حوزه‌ها و اضافه نمودن سیستم‌های پشتیبان تصمیم به آن‌ها توسعه در تمام عرصه های تولیدی، خدماتی، تجاری، توزیع و غیره، کارایی داشت؛ و نهایتاً ظهور ERP بود. مشکل عمده سیستم‌های MRPΠ و توسعه یافته های آن، این بود که تنها سیستم تولیدی ساخت به منظور انبار یا MTS را پشتیبانی می‌کرد؛ و سایر سیستم‌های تولیدی را چندان پوشش نمی‌داد. اما با ظهور ERP در حوزه تولید، تمامی سیستم‌های تولیدی تحت پوشش قرار گرفتند. بخش‌ها، فرایندها و وظایف مختلفی از جمله کنترل کیفیت، نگه داری و تعمیرات، حسابداری و مالی و غیره به سیستم‌های تولیدی متصل شده و ERP به عنوان حد فاصل سیستم‌های SCM و CRM مطرح گردید. این سیستم بیش از آنکه عنوان جدیدی برای MRPΠ باشد، به عنوان سطح بعدی در سطوح تکاملی سیستم‌های کامپیوتری طراحی شده برای پشتیبانی از عملیات سازمان مطرح گردید.
در سال 1995 , مقوله اینترنت وارد ERP شد و در سال‌های 1998 تا 2000 , EDI و ERP با یکدیگر پیوند خوردند. در سال 2000 اینترنت به عنوان جزئی تفکیک ناپذیر از ERP محسوب و سیستم‌های ERP تحت وب توسعه یافتند که فناوری چند لایه ای در معماری سیستم اطلاعاتی را پشتیبانی می‌کنند. امروزه هم سیستم‌های جدیدی با عنوان ERPΠ در حال توسعه‌اند که اساس آن‌ها وب بوده و تمرکز زیادی بر حمایت از ماژول SCM دارند و عملاً در تعریف امروز ERP , آن را کاملاً مرتبط و جدایی ناپذیر از SCM تعریف می‌نمایند. قابل ذکر است که در سال 1998 , بیش از 20000 سازمان در سراسر جهان، مبلغی افزون بر 17 میلیارد دلار در زمینه ERP سرمایه گذاری نمودند که این رقم در سال‌های بعد بین 30 تا 50 درصد رشد داشته و در سال 2003 به رقمی نزدیک به 100 میلیارد دلار رسیده است.
-8953526987500جدول2-1- پيشرفت سيستم ERPERP Π2005
Extended ERP 2000
Enterprise resource planning (ERP) 1990
Manufacturing resource planning( MRP Π) 1980
Material require planning (MRP) 1970
Inventory control packages 1960

از طرفی، هزینه نگهداری و به روز رسانی سیستم‌های پیاده سازی شده در سال 2000 به رقمی در حدود 21.5 میلیارد دلار بالغ شده که نرخ رشدی برابر 13.1% نسبت به 1999 داشته است. ضمناً طبق بررسی‌های صورت گرفته در حال حاضر، بیش از 70 % از 1000 شرکت طراز اول جهان از دید مجله fortune, سیستم‌های ERP را با موفقیت پیاده نموده‌اند و یا در حال پیاده سازی آن هستند. [8]
لازم به ذکر است که از ERP به عنوان کاتالیزور و یا تسهیل کننده در BPR و یا مهندسی مجدد نام برده می‌شود. اما در مورد اینکه ERP و BPR کدام یک مقدم بر دیگری است، بحث‌های زیادی مطرح شده است. برخی ERP و BPR را لازم و ملزوم هم دانسته‌اند و تاکید بسیار بر اجرای کامل BPR همزمان با پیاده سازی ERP و یا قبل از آن دارند در حالی که برخی دیگر بسیار تاکید بر عدم اجرای BPR سنگین در فرایند های سازمان به منظور افزایش احتمال موفقیت پروژه پیاده سازی ERP در سازمان دارند. تاکید گروه دوم بیشتر بر افزایش دقت در انتخاب ERP مناسب برای سازمان که دارای بیشترین انطباق با فرایند های سازمانی است، می‌باشد.
اما به هر حال باید اشاره کرد که در برخی موارد، نرم افزار ERP خریداری شده و منطبق با آن BPR صورت می‌گیرد. که به آن BPR منطبق بر بستهمی‌گویند؛ و در نوع دیگر BPR استاندارد، اعمال و سپس ERP منطبق با آن انتخاب می‌شود. هر کدام از این روش‌ها مزایا و معایبی دارند.
نکته بسیار مهمی که باید به آن توجه شود این است که پیاده سازی یک سیستمERP به صورت موفق در یک سازمان بسیار مشکل است، به گونه ای که بر اساس مطالعاتی که صورت گرفته، تاکنون در 50% موارد، پیاده سازی این سیستم با شکست مواجه شده است و در 90 % سیستم‌های پیاده شده موفق، فراتر از زمان و بودجه مصوب اولیه عمل شده است. بنابراین با وجود مزایا بسیاری که پیاده سازی آن دارد، تا زمانی که توجیه لازم برای انجام آن وجود ندارد، نباید هیچ سازمانی خود را با آن درگیر کند. تصمیم به خرید و پیاده سازی ERP در یک سازمان به منزله قماری است که کل سازمان در آن شرط بندی می‌شود. در صورت عدم موفقیت پروژه پیاده سازی، ادامه حیات سازمان با مشکل مواجه خواهد شد. از دلایل و توجیهاتی که برای پیاده سازی ERP در سازمان‌ها می‌توان بیان کرد شامل:

شكل 2-1- دلایل تکنولوژیکی پیاده سازی ERP [8]
شكل 2-2- دلایل تجاری پیاده سازی ERP [8]
2-2-1مفهوم:سيستم برنامه ريزي سازمان، يك بسته نرم افرازي قابل تنظيم و بر اساس استانداردهاي جهاني است كه هدف آن يكپارچگي اطلاعات و جريان اطلاعات بين تمامي بخش‌های سازمان از جمله مالي، حسابداري، منابع انساني، زنجيره عرضه و مديريت مشتريان با رويكرد مشتري گرايي و پاسخ به بازار می‌باشد.
در ERP كليه برنامه هاي كاربردي سازمان به صورت يك برنامه نرم افزاري يكپارچه بر روي يك پايگاه داده به گونه اي عمل می‌کنند كه كليه بخش‌ها بتوانند به سادگي اطلاعات خود را به اشتراك گذارده و با يكديگر ارتباط برقرار كنند. اين يكپارچه سازي، در صورت تحقق، بازگشت سرمايه عظيمي را براي سازمان به ارمغان خواهد آورد.
سیستم‌های ERP كه در دهه 90 توليد و توسعه یافته‌اند به صورت يكپارچه و يك جا ارايه می‌شدند و سازمان‌ها می‌بایستی كليه ماژول‌ها را راه اندازي می‌کردند. رويكرد فعلي در ERP به گونه اي است كه سازمان‌ها می‌توانند بخشي از ماژول‌های ERP از قبيل مالي و يا منابع انساني را خريداري، نصب و راه اندازي نمايند و توسعه ساير ماژول‌ها را به زمان ديگري موكول نمايند.
2-2-2 تعاریف :سيستم برنامه ريزي منابع سازمان، ابزار نويني است كه رفع ناهماهنگی‌ها را با تاكيد بر بهبود فرايندهاي سازمان و تصميم گيري صحیح‌تر و آسان‌تر مديران، هدف قرار داده است. به بيان ديگر:
ERP یک بسته نرم افزاری تجاری است که هدف آن یکپارچگی اطلاعات و جریان اطلاعات بین تمامی بخش‌های سازمان ازجمله مالی، حسابداری، منابع انسانی، زنجیره عرضه و مدیریت مشتریان است. [9]
سیستم‌های ERP سیستم‌های اطلاعاتی قابل تغییر و تنظیمی هستند که اطلاعات و فرایند های مبتنی بر اطلاعات در سازمان را در درون واحد های سازمانی و بین آن‌ها یکپارچه می‌نمایند.[10]
ERP يك راه حل سيستمي مبتني بر فناوري اطلاعات است كه به منظور ارتقاي مديريت فرايند و عمليات سازماني منابع سازمان را به وسيله يك سيستم به هم پيوسته، با سرعت، دقت و كيفيت بالا در كنترل مديران سطوح مختلف سازمان قرار می‌دهد.[10]
ERP شامل سیستم‌های مبتني بر كامپيوتر می‌باشد كه براي فرايندهاي يك سازمان طراحي شده و برنامه ريزي، توليد و پاسخگويي به مشتريان را يكپارچه می‌سازد.[10]
روشی برای برنامه ریزی و کنترل موثر تمامی منابع مورد نیاز برای دریافت، تولید، ارسال و پاسخگویی به نیاز های مشتریان در شرکت‌های تولیدی، توزیعی و خدماتی است.[10]
ERP دو مزيت عمده ارايه می‌کند كه در سیستم‌های سازماني غیر یکپارچه وجود ندارند:
يك نگرش يكپارچه سازماني از كسب و كار كه در برگيرنده تمام فعالیت‌ها (وظايف سازماني) و بخش‌ها است.
يك پايگاه داده اي براي سازمان است كه تمام فعالیت‌های كسب و كار در آن: وارد، ضبط، پردازش، نظارت و گزارش می‌شوند.
اين نگرش يكپارچه مستلزم گسترش همكاري و هماهنگي بين بخش‌های مختلف بوده و سازمان را در رسيدن به اهداف خود و ارتقاي قابليت پاسخگويي، توانا می‌سازد.

شكل 2-3- لایه‌ها در تحولات از MRP تا ERP توسعه یافته [10]
در ERP، كليه سیستم‌ها را به سه سطح می‌توان تفكيك نمود كه عبارتند از:
سطح 1: سیستم‌های عملياتي
سطح 2: سیستم‌های تاکتيکي
سطح 3: سیستم‌های استراتژيکي
سطح عملياتي شامل مجموعه اي از داده هاي حقيقي می‌باشد. سطح تاکتيکي توسط مديريت مياني براي تحليل و ارزيابي داده‌ها به کار برده می‌شود. سطح استراتژيک، اطلاعات تجميعي را براي مديريت ارشد جهت پشتيباني از تصميمات فراهم می‌نماید.
شکل زیر فعل و انفعالات امکان پذير عملكرد محيطي اجزاي ERP را نشان می‌دهد. عملكرد محيطي، هر سه سطح را در ERP به نمايش می‌گذارد.

شكل 2-4- يکپارچگي اطلاعات محيطي در سيستم ERP [10]با توجه به ادعاهاي بسياري از شرکت‌ها در خصوص امكان ارايه ERP، اين نكته كه به چه سیستم‌هایی در واقع ERP اطلاق می‌گردد و يا به عبارت ساده چه سیستم‌های نرم افزاري می‌توانند در رده هاي ERP دسته بندي گردند، موضوعي بسيار پر اهميت می‌باشد كه در جدول زير اين ویژگی‌ها همراه با ضرايب وزني آن‌ها ذكر شده است.
جدول 2-2- عنوان دهی به ERP و وزن آن‌ها از نظر شرکت‌ها [10]توصيف وزن عنوان همه ماژول‌ها از پايگاه داده به صورت يكپارچه استفاده مي نمايند. 3  يكپارچگي پايگاه داده 1
نه تنها هر يك از ماژول ها با پايگاه اطلاعاتي مشتركي ارتباط دارند، بلكه با ساير ماژول ها نيز مستقيم مرتبط هستند. 2  يكپارچگي نرم افزار 2
اين كه اين نرم افزار براي فرايندها و گردش اطلاعات در يك صنعت خاص پيكر بندي و بهينه شده باشد و در آن صنعت، تجارب گردش اطلاعات، آزموده شده و باعث ارتقاء كيفي سازمان شده باشد. 4  تجارب معتبر و موفق 3
استاندارد WFMS و امكان تعريف، كنترل و پايش و مديريت فرآيندها در سطح كليه ماژول ها. 2  فرآيند گرايي 4
مهمترين نقطه افتراق سيستم هاي متداول با ERP ها، در امكان برنامه ريزي و پيش بيني جامع منابع است. 5  جامعيت و امكان برنامه ريزي كليه منابع سازمان 5
آنچه در همه تعاریف و مشخصه‌ها ارائه شده، توجه و تمرکز بر روی عبارت enterprise در اختصار ERP است، تا توجه به عبارات دیگر اختصار. چرا که این سیستم فراتر از برنامه ریزی عمل کرده و با وجود تمرکز بر روی منابع سازمانی، عناصری فراتر از آن‌را نیز پوشش می‌دهند.
و از طرفی، آنچه که در تعاریف بیشتر نمود دارد، یکپارچگی و استاندارد بودن سیستم ERP است؛ و همین دو جنبه مهم آن‌را از سایر سیستم‌های اطلاعاتی یکپارچه متمایز می‌سازد. همچنین باید اشاره شود که ERP دارای دو هسته مرکزی و بخش تحلیل بازار است که سطوح مختلف سیستمی سازمانی را پوشش می‌دهد، به این صورت که هسته مرکزی پوشش دهنده TPS و MIS می‌باشد و ابزارهای تحلیل و تجزیه تجاری پوشش دهنده سطوح DSS و EIS در سازمان هستند. البته لازم به ذکر است که این تقسیم بندی چندان شفاف نبوده و مرز مشخصی بین این سطوح و دو بخش اصلی ERP قابل ترسیم نیست و همپوشانی‌هایی در این بین وجود دارد. [10]
در تعريف ارائه شده براي ERP، منظور از ساختار ماژولار بيشتر استقلال بخش‌هاي مختلف برنامه از يكديگر است به اين معنا كه وجود برنامه‌ها يا نرم‌افزارها يا ماژول‌هاي مختلفي از جمله مالي و حسابداري، منابع انساني، برنامه‌ريزي و كنترل توليد و عمليات و … در دل يك بسته ERP مانع از توسعه بخش‌هايي از ERP در سازمان نمي‌شود.سيستم‌هاي ERP بر اساس بهترين فرآيندهاي موجود يا Best Practiceها در بخش‌هاي مختلف صنعت طراحي شده‌اند. به اين معنا كه فرآيندهايي كه در بسته‌هاي نرم‌افزاري ERP براي پشتيباني از روال‌هاي كليدي سازمان قرار گرفته است، بر اساس رويه‌هاي استانداري طراحي شده كه به تجربه ثابت شده بهترين راه براي انجام آن فرآيند خاص است رویکرد های مختلفی برای این سیستم‌ها ارائه شده است که در ادامه بیان خواهد شد. برای ارائه این رویکردها از معماری سرویس گرا استفاده می‌شود.
آن چه که امروزه علاوه بر بحث یکپارچه سازی منابع سازمان لازم است، ایجاد یک محیط است که در آن قسمت‌های مجزای یک شرکت یا شرکت‌های مجزا، خودشان بتوانند فعالیت‌هایشان را مدیریت کنند و با سایر قسمت‌های کسب و کار و شرکایشان و همچنین مشتریان و تا مین کنندگان، بتوانند تعامل داشته باشند. پس هدف ایجاد محیطی است که کاربران، فرایند های کسب و کارشان را در زیرساخت‌های کسب‌وکار صرف نظر از آنکه در داخل یا بیرون شرکت باشند، مدیریت کنند. این امکان بر آورده نمی‌شود مگر با فراهم کردن بستر سرویس‌ها. در ادامه بیان خواهد شد.
2-3 سرویس گرایی:
آنچه که در چارچوب‌های سازمان‌های امروزی مطرح است، حاکمیت معماری سرویس گرا است. حاکمیت معماری سرویس گرا ترکیبی از دو لغت حاکمیت و معماری سرویس گرا است. معماری سرویس گرا در بر گیرنده تکنولوژی محاسبات سرویس گرا است. در واقع تکنولوژی محاسبات سرویس گرا، زیر بنای شکل گیری و ایجاد معماری سرویس گرا است. محاسبات سرویس گرا شامل مفاهیم، پروتکل‌ها و تکنولوژی‌های متعددی است که به مدل سازی و مهندسی سرویس، آنالیز و ترکیب سرویس، طراحی و توسعه تکنیک‌ها و متدولوژی های طراحی سرویس مطابق با مشخصات فرایند کسب و کار می‌پردازد. سرویس‌ها مکانیزمی را برای یکپارچگی برنامه‌ها فراهم می‌کنند. مبنای اجرای این یکپارچگی، معماری سرویس گر است، که زیر ساختی قابل انعطاف و مطمئن را برای استفاده از سرویس‌ها ایجاد می‌کند.
اضافه کردن قابلیت‌های حاکمیت به معماری سرویس گرا، نیازمند آماده سازی سازمان برای پذیرش و موافقت و حرکت به سمت سرویس گرایی است. بنابراین سرویس گرایی سازمان پیش نیاز استقرار حاکمیت معماری سرویس گرا است. سازمان سرویس گرا به فرهنگ سازی، مدیریت فرایند کسب و کار، تشخیص و تعیین ساختارها و فرایند های تصمیم گیری و مدیریت سرویس می‌پردازد. حاکمیت معماری سرویس گرا در پهنه وسیع‌تر و با تمرکز بر چرخه حیات سرویس، به سیاست گذاری و تعیین عملیات‌ها، فرایند های تصمیم و انتخاب رفتارها و در مجموع، مدیریت سرویس می‌پردازد. سازمان در این مسیر نیازمند چارچوب مناسب است تا این مدیریت را به شکل مناسب انجام دهد. در شکل (2-5) این چارچوب نمایش داده می‌شود.

شکل 2-5- گام‌های دست یابی به حاکمیت معماری سرویس گرا2-3-1 محاسبات سرویس گرا :
محاسبات سرویس گرا، یک روش جدید پدید آمده در محاسبات توزیع شده و پردازش‌های الکترونیک کسب و کار است، که زاییده سرویس گرایی و محاسبات مؤلفه ای است و امکان ساخت شبکه ای چابک از برنامه‌های کسب و کار توزیع شده را به وجود می‌آورد.[73]
استفاده از محاسبات سرویس منجر به کاهش پیچیدگی در برنامه نویسی و هزینه های مربوطه، کاهش هزینه های نگهداری، افزایش در آمد و بهبود کارایی می‌شود.[73]
روش محاسبات سرویس گرا می‌تواند برنامه‌ها را با استفاده از سرویس‌های موجود ایجاد نماید، تا فرایند های کسب و کار را اجرا نماید. سرویس‌ها مکانیزمی را برای یکپارچگی برنامه‌ها فراهم می‌کنند. [11]
اساس اجرای این یکپارچگی، معماری سرویس گرا است. یک معماری سرویس گرای خوش تعریف و مبتنی بر استاندارد، می‌تواند با ایجاد زیر ساخت قابل انعطاف، توابعی را برای استفاده از سرویس‌ها فراهم کند. در این روش از سرویس‌ها به منظور توسعه سریع، کم هزینه و تعامل پذیر استفاده می‌شود. سرویس‌ها عناصر محاسباتی غیر وابسته به چارچوب هستند که قابل تعریف و انتشار بوده و می‌توانند درخواست شوند و از کار های ساده تا فرایند های کسب و کار را انجام دهند.
سرویس‌ها یک رویکرد سرویس گرا را برای برنامه نویسی توزیع شده فراهم می‌آورند که قابل استفاده در شبکه می‌باشد. [11]
چارچوب‌های متعددی برای ایجاد برنامه های توزیع شده و ساخت سرویس‌ها به وجود آمده است. از عمومی‌ترین این چارچوب‌ها می‌توان به COM, DCOM,COM+ (مخصوص ماکروسافت) , EJB (که مبتنی بر جاوا است) و CORBA (مستقل از زبان و چارچوب) اشاره کرد. [12]
تکنولوژی‌های قدیمی، علی رغم مزایای متعدد، دارای محدودیت‌هایی نظیر دشواری پیاده سازی و وابستگی به یک فروشنده خاص (DCOM , CORBA) بوده و به سادگی قابل انتشار روی اینترنت نیستند. با توجه به محدودیت‌های موجود، نیاز به یک مدل محاسباتی است که بتواند با طراحی یکپارچه برنامه های توزیع شده، برای استفاده در اینترنت به کار گرفته شود. یک مدل محاسباتی توزیع شده مناسب، مدلی است که مستقل از چارچوبو زبان پیاده سازی باشد. به علاوه استفاده از پروتکل‌ها و استاندارد های آن، برای برنامه‌نویسان آسان بوده و امکان دسترسی به پروتکل‌های طرف سرور و طرف مشتری وجود داشته باشد. بنابراین لزوم یک مدل محاسباتی توزیع شده مبتنی بر استاندارد های اینترنتی مطرح شد. [13]
با پیشرفت تکنولوژی و همگرا شدن وب با تبادل الکترونیکی داده و میان افزار های استانداردی نظیر CORBA , مدل محاسباتی جدیدی بر مبنای یک معماری سرویس گرا با اتصال سست، تحت عنوان وب سرویس به وجود آمده است.
وب سرویس استفاده از مدل محاسباتی سرویس گرا در منابع وب است، تا قابلیت اتصال سست را در پردازش‌های توزیع شده تأمین نماید. [12] وب سرویس یک تکنولوژی میان افزار توزیع شده است که از پروتکل XML برای تبادل داده استفاده می‌کند.[12] تعاملات مستقیم ماشین به ماشین که تاکنون تصور می‌شد غیر عملی است، اکنون با استفاده از تکنولوژی‌های پیشرفته نظیر XML , SOAP امکان پذیر است.
یکی از تفاوت‌های اساسی بین تکنولوژی‌های CORBA و وب سرویس این است که CORBA یک معماری مؤلفه ای شی گرا را فراهم می‌کند، اما وب سرویس‌ها عمدتاً مبتنی بر پیغام هستند.
مطالعات بسیاری در زمینه کارایی وب سرویس‌ها و مقایسه آن با سایر تکنولوژی‌های توزیع شده، صورت پذیرفته است که بیانگر این است که کاربرد وب سرویس باعث کند شدن می‌شود و علت آن سربار ناشی از کدینگ و بازگشایی XML است [14].
علاوه بر این وب سرویس‌ها فاقد یک تعریف دقیق هستند و سناریو های مورد استفاده برای وب سرویس‌ها در مقایسه با تکنولوژی‌های میان افزار خوش تعریفی نظیر CORBA , خیلی قابل فهم نیستند. با این وجود، این تکنولوژی به دلیل خصوصیاتی که دارد، به صورت بی سابقه ای فراگیر شده است. دلایل آن‌را می‌توان سهولت و سادگی ایجاد واسط کاربر، استفاده از HTTP برای انتقال، ایجاد دیوار آتش امن، پویایی بیشتر در برنامه‌ها نسبت به سایر تکنولوژی‌ها، استفاده از URL برای آدرس دهی به سرویس‌ها و ایجاد تحمل پذیری بیشتر با استفاده از قابلیت‌های پروتکل SOAP و غیره دانست. محاسبات سرویس گرا شامل مفاهیم، پروتکل‌ها و تکنولوژی‌های متعددی است. که در بر گیرنده موضوعاتی نظیر سیستم‌های محاسباتی توزیع شده، معماری کامپیوتر و میان افزارها، محاسبات شبکه ای، مهندسی نرم افزار، امنیت و ارائه دانش است.
موضوعات اصلی محاسبات سرویس گرا عبارتند از : زیر ساخت سرویس، ترکیب سرویس، نظارت و مدیریت سرویس است.
در کل می‌توان نتیجه گرفت که لایه‌ها و محور های سرویس مناسب با فرایند های کسب و کار هستند.
2-3-2 معماری سرویس گرا :

شکل 2-6- حاکمیت معماری سرویس گرا و چرخه در بر گیرندهمعماری سرویس گرا مفهومی جدید نیست و از دهه 90 وجود دارد، ولی آنچه جدید است، توانایی اجرا و عینیت بخشیدن به آن است که به کمک ابزارها و پروتکل‌های مربوطه میسر شده است . [1]
معماری سرویس گرا یک معماری به هم پیوسته نیست. بلکه منجر به یک معماری به هم پیوسته می‌شود. می‌توان آن را یک شیوه جدید نامید. SOA یک رهیافت جدید است که منجر به تصمیمات به هم پیوسته کامل در زمان طراحی یک معماری نرم افزار به هم پیوسته می‌شود. [15]
ان توماس نیز معتقد است که معماری سرویس گرا را نمی‌توان ساخت و ایجاد کرد، بلکه معماری سرویس گرا یک شیوه رفتاری است و لذا سازمان بایستی رفتار خود را برای استفاده موثر از این فناوری تغییر دهد.
2-3-3 تعریف :
معماری سرویس گرا از دیدگاه های مختلف قابل بررسی است، هر فرد یا سازمان بر اساس نیاز های خود تصویری از معماری سرویس گرا دارد.
کسب و کار : از نقطه نظر کسب و کار، معماری سرویس گرامجموعه ایست از سرویس‌های کسب و کار مرکب برای رسیدن به یک طرح کسب و کار که سازمان می‌خواهد به مشتریان و ذینفعان خود ارائه دهد. [16]
معماری: از منظر معماری، SOA یک شیوه معماری است که سرویس گرایی را پشتیبانی می‌کند.
پیاده سازی: در سطح پیاده سازی SOA , از یک زیر ساخت استاندارد، مدل برنامه نویسی و تکنولوژی‌هایی نظیر وب سرویس استفاده می‌کند.
عملیات : از نقطه نظر عملیات، SOA شامل مجموعه ای از تعاملات بین تأمین کننده و مصرف کننده سرویس و تأمین کنندگان کیفیت سرویس و ارائه دهندگان متریک‌های فناوری اطلاعات و کسب کار است.
در تعاریف متعددی که از معماری سرویس گرا ارائه شده است، عمدتاً از دو دیدگاه فنی و غیر فنی به آن توجه شده است. اما اینکه آیا معماری سرویس گرا یک موضوع تکنیکال است یا خیر، بیشتر به دیدگاه اشخاص و تفسیر آن‌ها از مفاهیم اساسی SOA بستگی دارد مانند:
معماری سرویس گرا یک محصول نیست بلکه پلی است بین کسب و کار و فناوری به کمک مجموعه ای سرویس‌های متکی بر فناوری که دارای قوانین، استانداردها و اصول طراحی مشخص هستند. [17]
چارچوبی برای یکپارچه سازی فرایند های کسب و کار و پشتیبانی آن‌ها توسط فناوری اطلاعات با کمک مؤلفه های استاندارد و امن تحت عنوان سرویس که قابلیت استفاده مجدد و الحاق به یکدیگر جهت پوشش تغییرات حرفه را دارا می‌باشد. [18]
دو تعریف فوق تعاریف غیر تکنیکال معماری سرویس گرا را ارائه می‌دهند. تعاریف کاملاً به تعریف معماری سازمانی نزدیک اند و تنها تفاوت آن‌ها با معماری سازمانی در سرویس‌ها است. سرویس‌ها بخشی از معماری سرویس گرا هستند. اما پیاده سازی سرویس‌ها معادل معماری سرویس گرا نیست.
تعاریف زیر نیز دید غیر فنی از معماری سرویس گرا مطرح کرده‌اند، اما نوع نگاه به SOA نزدیک به مفهوم حاکمیت است. تعریف دوم برگرفته از مفهوم حاکمیت فناوری اطلاعات است.
معماری سرویس گرا شاکله فرایندهای طراحی و مهندسی و ابزارهایی است که با استفاده از سرویس‌ها و بهره گیری از خاصیت پیمانه ای بودن و قابلیت ترکیب آسان، زمینه تحقق اهداف کسب و کار را فراهم می‌کند. [19]
معماری سرویس گرا یک شیوه معماری است که به سرویس‌ها به عنوان دارایی‌های فناوری اطلاعات توجه دارد. این سرویس‌ها با فرایند های کسب و کار سطح بالا ترکیب می‌شوند و منجر به چابکی کسب و کار در مقابل تغییرات فناوری اطلاعات می‌گردد.
تعریف زیر بیشتر بر محصولات تمرکز دارد. اما نه محصولات فنی، سرویس‌ها در این تعریف خیلی مهم نیستند، بلکه توانایی استخراج و کنترل سرویس‌ها مهم است.
معماری سرویس گرا شامل سیاست‌ها، تجارب و چارچوب‌هایی است که کارکرد های سیستمی را قادر می‌سازد که به صورت مجموعه ای از سرویس‌های توزیع شده، تعریف شده و مورد استفاده در خواست کننده قرار گیرد. این سرویس‌ها با تعریف یک واسط استاندارد از پیاده سازی مجزا شده‌اند. [20]
در تعاریف زیر کاملاً به جنبه های تکنیکال پرداخته شده است و معماری سرویس گرا را یک نوع معماری فنی معرفی می‌کنند و بر تکنولوژی و نحوه پیاده سازی آن تاکید دارند. با توجه به اینکه از تکنولوژی وب سرویس استفاده می‌شود، بنابراین به نظر می‌رسد تفاوت در تفسیر مفاهیم اولیه است. [19]
– معماری سرویس گرا یک فرم از معماری فنی است که مبتنی بر اصول سرویس گرایی است. وقتی که این معماری از طریق تکنولوژی وب سرویس شکل می‌گیرد، SOA منجر به افزایش کارایی فرایند کسب و کار و فناوری‌های حوزه کسب و کار می‌گردد.
– سبکی از معماری است برای ساخت نرم افزارهایی که از طریق سرویس در شبکه منتشر شده‌اند. اتصال سست بین مؤلفه های نرم افزاری باعث قابلیت استفاده مجدد از آن‌ها می‌شود و کلیه نرم افزار های آن بر اساس سرویس‌ها ساخته می‌شوند. [73]
– معماری سرویس گرا یک شیوه از معماری است که برنامه‌ها را با ترکیب سرویس‌های قابل تعامل و اتصال سست ایجاد می‌کند. این سرویس‌ها قابل تعامل بوده و به چارچوب زبان برنامه نویسی وابسته نیستند.[21]
– معماری سرویس گرا چارچوبی است که کارکرد های برنامه‌ها را در قالب وب سرویس‌هایی قابل استفاده مجدد فراهم کرده و منتشر می‌کند.
با وجود تفاوت دیدگاه‌ها در تعاریف فوق، همه آن‌ها بر این اصل توافق دارند که معماری سرویس گرا باعث انعطاف پذیری سازمان می‌شود. همچنین بر اساس تعاریف ارائه شده می‌توان استنباط کرد معماری سرویس گرا قابلیت تأثیر گذاری در همه سطوح فناوری را دارد. از بالاترین سطح معماری سازمان EA تا پیاده سازی سرویس‌ها. علاوه بر تعاریفی که صاحب نظران و افراد سرشناس در زمینه معماری سرویس گرا ارائه نموده‌اند، برخی از شرکت‌های تجاری که مجری این نوع معماری بوده‌اند نیز تعاریفی را ارائه کرده‌اند. از جمله شرکت ORACLE و IBM.
معماری سرویس گرا یک شیوه معماری است که بر سرویس‌ها به عنوان دارایی‌های فناوری اطلاعات تمرکز دارد. این سرویس‌ها با فرایند های کسب و کار سطح بالا ترکیب می‌شوند و منجر به چابکی کسب و کار در مقابل تغییرات فناوری اطلاعات می‌گردند.
این تعریف ارتباط معماری سرویس گرا با کسب و کار سازمان (خصوصاً فرایندها) و تأثیر متقابل آن‌ها را مطرح می‌کند. مفهوم معماری سرویس گرا در این دیدگاه به مفهوم معماری سازمانی نزدیک است.
2-3-4 مفاهیم اصلی معماری سرویس گرا:
مفاهیم اساسی فنی معماری سرویس گرا که قادر به تأمین ویژگی‌های مورد انتظار این معماری است، عبارتند از :
سرویس
ایده معماری سرویس گرا، مجزا سازی جنبه های کسب و کاری یک مسئله است و این تجرد به شکل سرویس ظهور می‌یابد. [15]
هدف معماری سرویس گرا، ساختار دهی سیستم‌های توزیع شده بزرگ بر مبنای تجرید و خلاصه سازی قواعد و توابع کسب و کاری است. تعاریف متعددی از سرویس ارائه شده است که تعدادی از آن‌ها در زیر آورده شده است:
یک سرویس نمایشگر یک وظیفه کسب و کار تکرار پذیر است. سرویس‌ها برای مخفی سازی توابع عملیاتی با فراهم کردن یک واسط خوش تعریف و مستقل در یک برنامه استفاده می‌شوند. سرویس‌ها می‌توانند به وسیله سایر سرویس‌ها با برنامه های مشتری مورد استفاده قرار گیرند. [16]
– سرویس یک مؤلفه نرم افزاری با وظیفه و عملکرد مشخص است. که در بر گیرنده مفهوم سطح بالای کسب و کار است. [22]
– سرویس به معنای نیاز یک مصرف کننده به قابلیت‌ها و امکاناتی است که توسط یک تأمین کننده سرویس فراهم می‌شود. [23]
– سرویس کاری است که به وسیله یک سرویس دهنده انجام می‌شود که ممکن است انجام یک درخواست کوچک روی داده مانند دریافت یا ذخیره اطلاعات باشد یا مربوط به انجام کاری پیچیده تر مانند چاپ یک تصویر باشد. [74]
– سرویس به معنای پیاده سازی یک کارکرد کسب و کار خوش تعریف است که می‌تواند در فرایندها با نرم افزار های مختلف مورد استفاده و فراخوانی قرار بگیرد. [73]
بر اساس این تعاریف هر سرویس مأمور انجام وظیفه یا کارکردی خاص است. بسته به دانه بندی سرویس , عملیات و توابع قابل انجام توسط سرویس متفاوت است. به عنوان مثالی از سرویس می‌توان به سرویس محاسبه عوارض سالیانه اشاره کرد که شامل توابعی است که محاسبه عوارض نو سازی را برای یک ملک انجام می‌دهد. این سرویس خود از چند سرویس دیگر استفاده می‌کند. یکی از آن‌ها سرویس محاسبه ارزش ملک است که اولین تابع از محاسبه عوارض نو سازی است.
2-3-5 اجزا اصلی یک معماری سرویس گرا :
در نمای کلی، معماری سرویس گرا شامل مؤلفه های زیر است :
1- تأمین کننده
2- مصرف کننده
3- مخزن سرویس
هر جز می‌تواند به عنوان یکی از دو مؤلفه دیگر نیز عمل کند. برای مثال اگر یک تأمین کننده سرویس نیاز به در یافت اطلاعاتی داشته باشد که از سرویس دیگری فراهم شود، بنابراین تأمین کننده به عنوان مصرف کننده سرویس عمل خواهد کرد. تأمین کننده سرویس یک سرویس را ایجاد کرده و آن‌را برای استفاده و دسترسی به اطلاعات در رجیستری سرویس منتشر می‌سازد. هر تأمین کننده بایستی تصمیم بگیرد چه سرویس‌هایی نمایش داده شود، توازن و تعادل بین امنیت و دسترس پذیری را فراهم کند و چگونگی قیمت دهی و ارزش دهی سرویس را تعیین نماید. تأمین کننده همچنین لازم است طبقه بندی سرویس‌ها را تعیین کند و توافقات لازم برای استفاده سرویس توسط مصرف کننده سرویس را مشخص کند.[16]
مخزن سرویس مسئول ایجاد یک واسط سرویس و دسترس پذیری به اطلاعات برای مصرف کننده سرویس است. در پیاده سازی یک رجیستری سرویس، باید محدوده سرویس مورد نظر برای پیاده سازی رجیستری مد نظر قرار گیرد. برای مثال، رجیستری‌هایی به صورت عمومی بر روی اینترنت قرار دارند که به صورت نامحدود در دسترس همگان قرار دارند. در حالی که رجیستری‌های خصوصی نیز وجود دارند که تنها قابل استفاده به وسیله کاربران داخلی اینترانت سازمان هستند.
2-3-6 علت استفاده از معماری سرویس گرا:سازمان‌ها باید بتوانند به سرعت به تغییرات بازار واکنش نشان دهند و از سرمایه های موجود (زیر ساخت فناوری اطلاعات و فرایند های کسب و کار و غیره) برای پوشش نیازمندی‌های جدید مشتریان استفاده نمایند. معماری سرویس گرا با طبیعت اتصال سست خود به سازمان‌ها امکان بهره گیری از سرویس‌های جدید یا ارتقای سرویس‌های موجود را فراهم می‌کند. ]2[
بنابراین می‌توان گفت سرویس گرایی راه حل مناسبی برای جوان سازی سیستم‌های قدیمی سازمان، یکپارچه سازی برنامه های کاربردی و بسته های نرم افزاری مختلف و متصل سازی سیستم‌ها و کسب و کار های گوناگون به منظور همکاری و تعامل می‌باشد. معماری سرویس گرا در پاسخگویی به تغیرات بسیار منعطف است زیرا جدا بودن واسط‌ها از پیاده سازی سرویس‌ها و اعمال جابجایی و تغییرات در مؤلفه های تکنیکی سرویس‌ها بسیار میسر است. همچنین:
انعطاف پذیری در کسب و کار و فناوری اطلاعات
وجود استانداردها و چارچوب‌های باز
نرم افزارها و ابزار های موجود برای معماری سرویس گرا
هدایت کسب و کار در حرکت به سمت فناوری اطلاعات
و تجارب بسیار زیادی که در زمینه به کار گیری و پیاده سازی این معماری بدست آمده‌اند، بیانگر دلایل استفاده از این معماری هستند. از طرفی سازمان با به‌کارگیری این معماری از مزایای زیادی بهرمند می‌شود. برای مثال، سازمان‌ها با استفاده از SOA می‌توانند فرایند های تجاری را به صورت افقی بسازند تا سیستم‌ها، افراد و فرایندها را یکپارچه کنند و سازمان بتواند به سرعت و آسان به تغییرات و نیاز های کسب و کار پاسخ دهد. همچنین معماری سرویس گرا فرصت مناسبی را برای سازمان به وجود می‌آورد تا از تکنولوژی اطلاعات به طور مطلوب استفاده نماید که این شامل مزایایی برای سازمان IT و کسب و کار است.[24]
2-4 مدیریت فرایند کسب و کار و معماری سرویس گرا :
سرویس‌ها بخش‌هایی از فرایند های کسب و کار هستند. مدیریت فرایند کسب و کار یک موضوع وسیع است که بعداً بیشتر به آن پرداخته خواهد شد. مدیریت فرایند کسب و کار با جنبه‌هایی نظیر آنالیز کسب و کار (شامل نیازها و فرصت‌ها) , پیاده سازی و یکپارچگی استراتژی‌های کسب و کار، نظارت و بهینه سازی فرایند های کسب و کار، تشخیص ابزار های مناسب و فرهنگ سازی و هم سویی کسب و کار و فناوری اطلاعات سرو کار دارد. [15]
ارتباط مدیریت فرایند کسب و کار و معماری سرویس گرا از آنجا مشخص است که فعالیت‌ها در پایین‌ترین سطح، سرویس‌ها هستند. یک سیستم یا تابع در رویکرد بالا به پایین (نگاه از کل به جز از بالا به پایین) به قسمت‌های کوچک‌تر شکسته می‌شود که تا اینکه به سطح سرویس‌های پایه می‌رسد. در رویکرد پایین به بالا سرویس‌ها با هم ترکیب می‌شوند و فرایندها یا سیستم را می‌سازند. هیچ برتری نسبت به روش‌های بالا به پایین و پایین به بالا وجود ندارد. ولی در رویکرد بالا به پایین در ابتدا به درک کسب و کار و سپس به جزئیات پرداخته می‌شود ولی در پایین به بالا امکان پرداختن زیاد به جزئیات وجود دارد که احتمال ایجاد فرایند های سلب وجود دارد. اصولاً پیشنهاد می‌شود ترکیبی از دو روش استفاده شود. [25][15]
2-5 سازمان سرویس گرا :

شکل 2-7- حاکمیت معماری سرویس گرا در سازمان و تبدیل سازمان به یک سازمان سرویس گراامروزه اولویت‌های اصلی سازمان‌ها برای رقابتی شدن، افزایش کارایی عملیاتی، رشد درآمد و تولید بیشتر است. [26]
کارایی سازمان، ارتباط مستقیمی با چابکی و قدرت پاسخگویی سریع دارد. انعطاف پذیری عامل اصلی برای کاهش زمان بازار و واکنش سریع به تغییرات است. قابلیت انعطاف بایستی در همه زمینه های سازمانی، نقش‌ها و فرایندها و غیره به طور شفاف انجام شود. سرویس گرایی ایده ایست که کمک می‌کند تا سازمان بتواند در برابر تغییرات سریعاً واکنش نشان دهد.
در ابتدا سازمان‌ها برای یکپارچه کردن سیستم‌ها و نرم افزارهایشان از تکنولوژی وب سرویس‌ها شروع کردند. این مرحله بیشتر کسب تجربه بود. [26]
آن‌ها شروع به تلاش کرده و سعی داشتند تا این تکنولوژی را بشناسند و خاصیت اتصال سست را با یکپارچگی برنامه‌ها و سیستم‌هایشان به کار گیرند. در این مرحله تعداد نسبتاً کمی وب سرویس در داخل سازمان‌ها یا بر روی وب تهیه و را اندازی شد. مشتریان شروع به استفاده از چارچوب‌های توسعه وب سرویس نمودند تا این تکنولوژی نوظهور را بشناسند.
چیزی نگذشت که شرکت‌هایی نظیر آمازون، ebay ,google از واسط‌های مبتنی بر سرویس برای وب سایت‌هایشان استفاده کردند. در این مرحله میلیون‌ها وب سرویس تهیه شد که روزانه از طریق اینترنت مورد دسترسی و استفاده قرار می‌گرفت. با گسترش سرویس گرایی در مرحله دوم، سازمان‌های بزرگ فناوری اطلاعات از تکنولوژی وب سرویس به عنوان یک تکنولوژی قابل اعتماد برای یکپارچه سازی برنامه های پشت صحنه و سیستم پردازنده مرکزی استفاده کردند. همچنین تلاش‌های زیادی در زمینه تعیین ارتباطات کسب و کار مبتنی بر تکنولوژی وب سرویس صورت گرفت. در مرحله دوم تاکید بر روی ترکیب سرویس‌ها، استاندارد های مناسب برای کیفیت سرویس و مدیریت سرویس بود. در این مرحله همچنین مدیریت فرایند کسب و کار شکل گرفت که امکان خودکار سازی فرایندها و قواعد کسب و کاری را فراهم می‌ساخت. گذرگاه های سرویس، اسکلت معماری سازمان شدند دو زیر ساختی برای هماهنگی سرویس‌ها به وجود آمد و جنبه های اصلی یکپارچگی، نظیر انتقال پیغام، پروتکل انتقال، امنیت و پذیرش تعدادی از استاندارد های سرویس برای پشتیبانی از هماهنگ سازی نظیر ws-security , BPEL صورت گرفت. سازماندهی ثبت سرویس‌ها و به خصوص استاندارد های مربوط به مخازن و رجیستری نیز انجام شد.
در مرحله سوم که هم اکنون نیز در حال بهبود و شکل گیری است، دیدگاه نرم افزار به عنوان یک سرویس مطرح خواهد شد. این رویکرد یک روش دشوار را در فرایند های کسب و کار، برنامه های داخلی سازمان، سیستم مدیریت فرایند کسب و کار و گذرگاه های سرویس را به همراه دارد. از منظر تکنولوژی، سرویس‌ها در همه جا قابل استفاده‌اند. از منظر تقاضا، مشتریان فرایند های پویایی را خواهند ساخت. ترکیب وب سرویس‌ها در فرایند های هوشمندانه در انتخاب و به کار گیری روش وب سرویس‌ها ضروری است. مرحله سوم موج جدیدی در توسعه نرم افزار به عنوان سرویس به وجود خواهد آورد. [26]
(توسعه مشاب ها نیز در امتداد این مسیر قرار دارد) همچنین این دیدگاه معتقد است که سرویس گرایی همان طور که در لایه های نرم افزارهای کاربردی منجر به سبک معماری سرویس گرا می‌شود، در کسب و کار سازمان نیز می‌تواند اثر بخش بوده و سازمان سرویس گرا را تعریف کند.

شكل 2-8- فازهاي سيستم سرويس گرادر سرویس گرایی علاوه بر تکنولوژی، نیاز به تغییر فرهنگ سازمان نیز هست. سرویس گرایی بیشتر یک فرهنگ است. فرهنگ سرویس گرایی بدین معناست که هدف اصلی، ارائه خدمات به دیگران باشد آن هم به بهترین روش ممکن.
در سازمان‌های سرویس گرا دو هرم در مورد سرویس دهی وجود دارد. اولین هرم سازمان شامل 3 مؤلفه کلیدی سازمان است. که سیستم مدیریت فرایند کسب و کار و زیر ساخت فناوری اطلاعات سرویس گرا را شامل می‌شود. هرم دوم مربوط به مجریان و ارائه دهندگان سرویس است. [26] سازمان سرویس گرا با استفاده از مؤلفه های سه‌گانه و رهبری و مدیریت خدمت گذار می‌تواند در برابر گروه های مختلف ذینفعان موفق عمل کند. شکل زیر مؤلفه های فنی و رهبری خدمت گذار در سازمان سرویس گرا را نشان می‌دهد.

شکل 2-9- هرم‌های مؤلفه های فنی و رهبری خدمت گذار در سازمان سرویس گرا [26]در هرم اول برای سرویس گرایی سازمان سه لایه اساسی مورد نیاز است. مدیریت کارایی سازمان، مدیریت فرایند کسب و کار و معماری فناوری اطلاعات … شکل زیر سه لایه بنیادی سازمان سرویس گرا را نشان می‌دهد.

شکل 2-10- لایه های بنیادی سازمان سرویس گرا
همان طور که مشاهده می‌شود مدیریت کارایی سازمان در سازمان مربوط به کارایی سرویس‌ها در سازمان است در لایه بعدی یکپارچگی سرویس‌ها در فرایند های کسب و کار و زیر ساخت‌ها و تجهیزات و فناوری‌های اطلاعاتی در لایه آخر متناسب با معماری سرویس گرا است. [27]
2-6 فرایند های کسب و کار سازمان :از آنجا که هدف اصلی این پروژه یکپارچه سازی سازمان سرویس گرا است و عملاً سازمان هم بر اساس فرایند های کسب و کار خود ساخته می‌شود، این نیاز وجود دارد که به تشریح فرایند های کسب و کار و تا حدودی به مدل سازی آن‌ها پرداخته شود.
یک فرایند کسب و کار، مجموعه ای از فعالیت‌ها است که به منظور تولید یک خروجی خاص برای یک مشتری یا بازار مشخص طراحی می‌شود. تاکید فرایند روی چگونگی کارها درون سازمان می‌باشد. بنابراین یک فرایند، ترتیب مشخصی از فعالیت‌ها در گذر زمان و مکان است که دارای یک شروع، پایان، ورودی‌ها و خروجی‌ها است که به روشنی تعریف شده‌اند. [28]
یک فرایند دارای قسمت‌های مختلفی می‌باشد که شکل زیر نشان می‌دهد.
455930-220980رویداد
خروجی
منبع
اطلاعات
هدف
فرایند کسب و کار
00رویداد
خروجی
منبع
اطلاعات
هدف
فرایند کسب و کار

شكل 2-11- فرآيند كسب و كارهر فرایند کسب و کار دارای تعدادی هدف خوش تعریف است. هدف بیان می‌کند که سازمان چرا این فرایند را انجام می‌دهد و باید بر حسب مزایایی که این فرایند برای سازمان دارد تعریف شود. فرایند های کسب و کار از اطلاعات برای تنظیم یا تکمیل فعالیت‌هایشان استفاده می‌کنند. اطلاعات بر خلاف منابع، در فرایند مصرف نمی‌شوند، بلکه به عنوان بخشی از فرایند انتقالی استفاده می‌شوند. اطلاعات ممکن است از منابع خارجی، از مشتریان و از واحد های سازمانی داخلی تأمین شوند یا حتی به وسیله دیگر فرایندها تولید شوند. یک فرایند کسب و کار، یک یا چندین خروجی با ارزش را برای کسب و کار تولید خواهد کرد. که این خروجی‌ها، مجموعه ای از نیازمندی‌های داخلی و خارجی را بر آورده خواهند ساخت. خروجی ممکن است یک شی فیزیکی (مانند گزارش یا فاکتور) , یک تبدیل از منابع خام اطلاعاتی به یک تنظیم جدید (مانند تنظیم زمان بندی روزانه) یا نتیجه کلی فرایند، مانند تکمیل سفارش مشتری باشد. یک منبع به عنوان ورودی به یک فرایند کسب و کار وارد شده و در طول فرایند مصرف می‌شود. رویداد، نقطه شروع یک فرایند را نشان می‌دهد. به عنوان مثال رسیدن یک درخواست جدید ممکن است رویداد آغاز یک فرایند باشد.
اصولاً فعالیت‌های درون سازمان به دو دسته تقسیم می‌شوند.[28]
فعالیت خودکار شده یک گام در فرایند است که به طور مستقیم توسط موتور اجرایی انجام می‌شود. فعالیت دستی، گامی در فرایند است که توسط یک فرد مشارکت کننده در فرایند اجرا می‌شود.
مدیریت فرایند کسب و کار، BPM باعث می‌شود که تحلیلگر کسب و کار بتواند با ساخت فرایند های کسب و کار خوش تعریف , سیستم‌های فن آوری اطلاعات را با اهداف کسب و کار هم راستا سازد . سیستم‌های BPM یک مجموعه از ابزار را در اختیار تحلیلگر کسب و کار قرار می‌دهند که مدل‌های کسب و کار را با استفاده از زبان‌های مدل سازی نظیرBPMN تعریف کنند و سپس با فراخوانی سرویس‌ها , این مدل‌ها را اجرا نمایند. [29]

شکل 2-12- ایجاد فرایند کسب و کار از عملکرد سیستم سازمانی در سیستم BPM
روش مدل سازی فرایند کسب و کار، BPMN تکنیکی است که مراحل یک فرایند کسب و کار , افراد , سازمان‌ها یا مسئولیت‌های سیستم برای آن مراحل و داده های وابسته به هر مرحله را فرموله بندی می‌کند. BPMN به ویژه در معماری سرویس گرا بسیار جالب است , از آنجا که یک زبان برای استفاده از سرویس‌های کسب و کار قابل استفاده مجدد فراهم می‌کند. این زبان که BPEL4WS یا به اختصار BPEL نامیده می‌شود , یک مشخصه سازی BPM با زیر ساخت بسیار قوی (BEA, Oracle, Microsoft , IBM )است .[30]
این زبان برای تعریف و اجرای فرایندهای کسب و کار استفاده می‌شود. به طور کلی دو راه برای نمایش دادن یک فرایند وجود دارد : XML و علامت گذاری یا روش‌های ترسیمی. روش‌های ترسیمی نمودار های فرایندی مانند UML را فراهم می‌کنند.
در این پروژه، جهت تحلیل فرایندها از روش ترسیمی موجود در نرم افزارها استفاده شده است. دیدگاه های مختلفی جهت شناسایی و بهبود فرایندها وجود دارد. [31]
این دیدگاه‌ها شامل دیدگاه مدیریتی، در این دیدگاه پس از شناخت مشکلات و نارسایی‌های یک سازمان و نیاز های آن‌ها، فرایند های مختلف تجزیه و تحلیل شده و با مراجعه به IT و با استفاده از توانایی‌های سیستم‌های اطلاعاتی سعی می‌شود تا نیاز های خواسته شده بر آورده شود.
دیدگاه بعدی، دیدگاه توسعه سیستم‌های اطلاعاتی است. در این دیدگاه با آشنایی قبلی از توانایی‌های IT و سیستم‌های اطلاعاتی، فرایند های مختلف تجزیه و تحلیل و سپس با توجه به آن‌ها مهندسی مجدد و بهبود فرایندها، با توجه به فناوری، اجرا می‌شود. که این دیدگاه در این پروژه به کار گرفته می‌شود.
همان طور که در پیش بیان شد، اجرای ERP و پروژه BPR می‌توانند لازم و ملزوم هم باشند؛ و یا همزمان و این به دلیل فعالیت‌های مشترک مابین این دو است. برای طراحی سیستم در ابتدا نیاز به شناخت و بهبود فرایند های کسب و کار است و از طرفی برای بهبود فرایند های کسب و کار باید توانایی‌های ممکن و مورد نظر در سیستم نهایی ERP را در نظر گرفت. این خود بیانگر ارتباط مابین این دو می‌باشد. در ادامه نحوه اجرا و ترکیب این دو را بیان خواهیم نمود.
اما پس از شناخت و حتی ایجاد فرایند های کسب و کار در معماری سرویس گرا، معضلی همچنان وجود دارد و آن نیاز به تحلیل پیوسته و به تبع آن تصمیم گیری‌های مداوم است. زیرا طبق مطالب بیان شده، سازمان سرویس گرا سازمانی متغیر و چابک است. این تغییر در هر زمینه ای می‌تواند باشد. بنابراین نیاز به تغییر در تصمیم‌ها هم دیده می‌شود؛ لذا در یک چارچوب سرویس گرا، همواره نیاز به بخشی تحت عنوان سیستم پشتیبان تصمیم دیده می‌شود. در ادامه این نیاز تشریح و این سیستم بیان می‌شود.
2-7 سیستم پشتیبان تصمیم:
2-7 -1 تصمیم گیری:
 مدیریت فرایندی است که اهداف سازمانی را با استفاده از منابع، به انجام میرساند. منابع ورودیهای مطرح شده هستند و دستیابی به اهداف سازمان به عنوان خروجی نمایش داده می‌شوند. درجه موفقیت سازمان و کار مدیر اغلب با نسبت خروجیها به ورودیها، اندازهگیری میشود. این نسبت یک نشانه برای بهرهوری سازمان  است.
همه  فعالیتهای مدیریتی حول تصمیمگیری سیر میکنند. مدیر در درجه اول یک تصمیم‌گیرنده است و سازمانها نیز با تصمیمگیرندههایی در سطوح مختلف پر شدهاند.  ممکن است تصمیم گیران با انواع مختلفی از مسائل تصمیم روبرو شوند، مثل مسائل ساده روزمره و یا استراتژیهای بلند مدت یک شرکت. تصمیم گیران یک سازمان، در سطوح مختلفی  فعالیت می‌کنند از یک مدیر پروژه توسعه نرمافزاری  تا یک  مدیرعامل از یک شرکت بزرگ. این سطوح مختلف  تصمیمگیری خصوصیات مختلفی داشته و به تکنیکهای پشتیبان تصمیم متفاوتی نیز نیاز دارند.
تصمیمها می‌توانند به دو صورت  شخصی و یا گروهی گرفته شوند. تصمیمهای شخصی اغلب در سطوح پایینتر مدیریت و در سازمانهای کوچکتر گرفته می‌شوند. در حالی که تصمیمهای گروهی معمولاً در سطوح بالاتر مدیریت گرفته میشود. در تصمیمگیری گروهی هر عضو درک و شناخت و راهحل شخصی خودش را برای مسئله دارد. اعضا گروه با تواناییهای مختلف و منابع عملی  در یک تصمیمگیری شرکت میکنند.   تصمیمگیری گروهی نسبت به تصمیمگیری شخصی به علت ناسازگاری بین  اولویتها و علاقمندیهای متفاوت تصمیم گیران پیچیدهتر است. بنابراین ارتباطات بین اعضا گروه در تصمیمگیری گروهی بسیار مهم است. تصمیمگیری هر روز پیچیدهتر میشود و این پیچیدگی  ناشی از سربار اطلاعات اضافی و نوسان محیطهای تصمیمگیری است. با تکنولوژیهای اطلاعات و سیستمهای ارتباطات پیشرفته، ما میتوانیم، کمیت‌های صحیح بزرگ اطلاعات را، با سرعت و به آسانی پیدا کنیم. بنابراین پیشنهادهای بیشتری را میتوانیم  تولید و ارائه کنیم. با این وجود، تغییر محیط تصمیمگیری، عدم قطعیت بیشتری را به تصمیمگیری، تحمیل میکند. که این امر باعث میشود که به تصمیمگیری پویا نیاز پیدا کنیم در این شرایط معمولاً نیاز داریم که تصمیمها سریع‌تر گرفته شوند. به دلیل پیچیدگی اعمال، خودکارسازی (اتوماسیون) و زنجیره اعمالی که یک خطا میتواند در بخشهای یک سازمان منجر شود، هزینه خطاها بسیار زیاد خواهد بود. به این دلایل تصمیم گیران تجاری به پشتیبانی تکنیکی برای کمک به تصمیمگیری سریع در یک چارچوب  زمانی کوتاه، نیاز دارند.  تجارت و محیط آن هر روز در حال پیچیدهتر شدن هستند و این تغییرات در عاملهای مهم، در تصمیمگیری مدیریتی نیز تأثیر میگذارند. به عنوان یک نتیجه، امروزه تصمیمگیری پیچیدهتر از قبل شده و گرفتن تصمیم به دلایل بسیاری مشکل شده است. اول اینکه تعداد پیشنهادهای در دسترس نسبت به قبل بیشتر شده است زیرا تکنولوژیها و سیستمهای ارتباطات پیشرفت کردهاند، به طور خاص اینترنت و موتورهای جستجوی آن، داده‌ها و اطلاعات بیشتری در دسترس قرار میدهند . بنابراین پیشنهادهای بیشتری میتوانند تعیین و توصیف شوند. با وجود سرعت دسترسی به دادهها و اطلاعات، پیشنهادهای تصمیمگیری باید تجزیه و تحلیل شوند که این کار نیازمند زمان و استدلال است. با وجود اینکه اطلاعات بهتر و بیشتری نسبت به قبل داریم،   فشار زمانی، از اینکه تصمیمگیرنده بتواند همه چیزهایی که نیاز دارد را جمعآوری کند و آن‌ها را به کار بگیرد، جلوگیری میکند. دوم اینکه هزینه خطا های ایجاد شده به دلیل پیچیدگی و بزرگی دامنه اعمال، خودکار سازی (اتوماسیون) و زنجیره واکنشی که یک خطا میتواند در بسیاری از بخشهای سازمان باعث شود،  بسیار بالا است. سوم اینکه در محیطهای  با نوسان و با عدم قطعیت در عناصر، تغییرات پیوستهای  وجود دارد. که کار تصمیمگیری را مشکل میکند. سرانجام اینکه تصمیماتی که برای پاسخ به داد و ستد گرفته میشوند، باید  به سرعت گرفته شوند، پیشرفت در تکنولوژی، به خصوص در وب، سرعت بدست آوردن اطلاعات و سرعت مورد انتظاری که ما در تصمیمگیری داریم، را افزایش میدهد .
مسائل تصمیم میتوانند بر طبق ماهیتشان دستهبندی شوند. یک دستهبندی مهم بر مبنای ساختار مسئله به صورت زیر است:
ساختیافته ]3[
نیمه ساخت یافته ]4[
غیر ساخت‌یافته ]5[
یک مسئله تصمیم ساختیافته، میتواند به وسیله مدلهای ریاضی کلاسیک  موجود، توصیف شود. مثل برنامهنویسی خطی و روشهای آماری. روالهایی برای بدست آوردن بهترین راهحل مانند روشهای راهحل استاندارد، شناخته شدهاند. مثالهایی از مسائل تصمیم ساخت یافته: انتخاب یک  محصول  با کمترین هزینه از میان تمام محصولات، تعیین اینکه کدام طرح تولید از بین یک مجموعه میتواند بالاترین سود را داشته باشد.
مسائل غیر ساخت‌یافته، مبهم و نامعلوم هستند و روش حل استانداردی برای آن‌ها وجود ندارد. درک مستقیم انسان  اغلب اساس و پایهای برای تصمیمگیری در یک مسئله غیر ساخت‌یافته است.
مسائل غیر ساخت‌یافته نمونه، شامل: برنامهریزی سرویسهای جدید، استخدام یک مدیر و انتخاب یک مجموعه از پروژههای توسعه برای یک مدت زمان طولانی است.
مسائل نیمه ساخت‌یافته بین مسائل ساختیافته و غیر ساخت‌یافته قرار دارند و فاکتورهای هر دو نوع مسائل را در بر دارند. حل این نوع از مسائل تصمیم، شامل یک نوع  از روالهای حل بهینه استاندارد است و نیاز به درک مستقیم و قضاوت انسان دارد.
تجربه نشان داده است که روشهای پشتیبان تصمیم مبتنی بر کامپیوتر در مسائل تصمیم ساختیافته نسبت به مسائل غیر ساخت‌یافته و نیمه ساخت‌یافته  بسیار مفیدترند.
2-7-2 :دسته بندی مسائل تصمیم بر مبنای سطوح تصمیم گیری:
نوع دیگری از دسته‌بندی مسائل تصمیم  بر مبنای سطوح تصمیمگیری:
برنامهریزی استراتژیک
کنترل مدیریت
کنترل عملیات.
برنامهریزی استراتژیک؛ به مجموعه بزرگی از اهداف و سیاستگذاریها برای تخصیص منابع، اشاره دارد. این چنین تصمیمهایی در یک سطح مدیریتی بالا، غیر ساخت‌یافته نرمال و با درجه بالایی از عدم قطعیت،  قرار دارند.
کنترل مدیریت؛ به اکتساب و استفاده موثر از منابع، در اجرا  اهداف تجاری، اشاره میکند؛ و تصمیمهای مربوط به آن در سطح متوسط مدیریتی قرار دارند.
تصمیمهای کنترل عملیات؛ درباره اجرای موثر وظایف خاص هستند. آن‌ها معمولاً ساختیافته و برای فرمولبندی به وسیله مدلهای ریاضی، نسبتاً ساده هستند و با ابزارهای مبتنی بر کامپیوتر حل میشوند.
تصمیمگیری یک فرایند مبتنی بر استدلال، منطقی یا غیرمنطقی است؛ و میتواند بر اساس فرضیات ضمنی و یا صریح باشد. تصمیمگیری منطقی به مجموعه حقایق و اداره کردن تحقیق مانند آنالیز داده و بررسیها و مصاحبهها، اهمیت میدهد. یک مدل تصمیمگیری منطقی  درگیر یک فرایند شناخت است به طوری که هر مرحله یک ترتیب منطقی نسبت به مرحله قبل را دنبال  میکند. تصمیمگیری غیرمنطقی، فرضیات و نتایج بدست آمده را بدون دادههای صحیح و دقیق و تجزیه و تحلیل و مدل میسازد؛ و اغلب بر اساس تمایلات شخصی  تصمیم گیرنده، عمل می‌کند. در برخی موارد می‌توان این دو رویکرد را به شکل ترکیبی در نظر گرفت. رویکرد مطرح در این پروژه، بر این اساس است.
2-7-3فرایند تصمیم گیری:برای تعیین اینکه یک تصمیمگیرنده چطور تصمیم میگیرد، ابتدا باید فرایند و عمل تصمیمگیری را بررسی کنیم. آنگاه میتوانیم روش‌های مناسب برای کمک به تصمیمگیرندگان را بشناسیم؛ و در نهایت میتوانیم   سیستم‌های پشتیبان تصمیمگیری را برای کمک به آن‌ها توسعه دهیم.
تصمیمگیری: تصمیمگیری فرایند انتخاب از میان پیشنهادهای مختلف برای رسیدن به اهداف است.  
تصمیمگیری و حل مسئله: یک مسئله هنگامی اتفاق میافتد که یک سیستم نتواند به اهداف مسلم خود دست یابد، یا نتواند به نتایج  پیشبینی شده برسد و یا اینکه نتواند طبق برنامه کار کند. تفاوت بین حل مسئله و تصمیمگیری ممکن است کمی مبهم باشد، برای درک بهتر این تفاوت،  فازهای مختلف تصمیمگیری را   بررسی میکنیم. هربرت سایمون در سال (1977). ]3[
فرایند تصمیمگیری را در 3 فاز اصلی بیان نمود. این سه فاز شامل هوشمندی، طراحی و انتخاب بود. او بعدها فاز چهارم اجرا را  نیز اضافه نمود. نظارت میتواند به عنوان فاز پنجم در نظر گرفته شود (نوعی بازخورد)، اگر چه نظارت را میتوان در به‌کارگیری فاز هوشمندی در فاز اجرا نیز دید. مدل سایمون کامل‌ترین مشخصه از تصمیمگیری عقلانی است. یک جریان پیوستهی فعالیتها از هوشمندی به طراحی وجود دارد اما در هر فاز ممکن است یک بازگشت به فاز قبلی (بازخورد) وجود داشته باشد. مدل سازی یک  قسمت ضروری از این روند است.

شكل 2-13- مدل تصمیم گیری 3 فازی از هربرت سایمونتوسعه یافته اين مدل به صورت شکل زیر می‌شود.

شکل 2-14- توسعه يافته مدل تصميم گيري 3 فازي هربرت سایمون
همان طور که بیان شد،  تصمیمگیری یک فرایند انتخاب از میان پیشنهادهای ممکن است. هر عمل تصمیمگیری میتواند به وسیله توصیف مسئله، یک مجموعه پیشنهادها و معیارهای تصمیم وابسته به مسئله،  توصیف شود. یک تصمیمگیرنده تمام این  مراحل را طی میکند و سرانجام به یک راه حل نهایی دست مییابد.
2-7-4تعریف:تصمیمگیری یک فرایند شناختی شامل وظایف شناختی متفاوت مانند جمع آوری اطلاعات، ارزیابی وضعیت‌ها، تولید و انتخاب پیشنهادها و اجرای راهحل است. سیستم پشتیبان تصمیم اغلب به وسیله   تصمیمگیرندهها، برای کاهش خطاهای شناختی و بیشینه کردن کارایی اعمال، استفاده میشود. یک سیستم پشتیبان تصمیم، یک سیستم اطلاعات مبتنی بر کامپیوتر است که برای پشتیبانی از فعالیت‌های تصمیمگیری سازمانی و تجاری، طراحی شده است. ]3[
یک سیستم پشتیبان تصمیمگیری ممکن است به دلایل مختلفی مورد نیاز باشد. به عنوان مثال:
محاسبات سریع؛ یک کامپیوتر به تصمیمگیرنده اجازه میدهد که بسیاری از محاسبات را به سرعت و  با هزینه کم انجام دهد. تصمیمهای زماندار بیشتر برای موقعیتها بحرانی هستند. مثل تصمیم یک پزشک در اتاق اورژانس یا تصمیمگیری یک خریدار سهام برای خرید یا فروش سهامی خاص.  
غلبه بر محدودیتهای انسانی محاسبات و ذخیرهسازی؛ مغز انسان در تجزیه و تحلیل اطلاعات و همچنین یادآوری آن‌ها دارای محدودیت است همچنین انسان ممکن است در یادآوری اطلاعات در زمان مورد نیاز و با دقت بالا دچار مشکل شود.
محدودیت‌های انسانی؛ قدرت حل مسئله یک فرد دارای محدودیت است مخصوصاً زمانی که برای حل یک مسئله به اطلاعات و دانشهای مختلفی نیاز باشد. با تصمیمگیری گروهی میتوان بر این مشکل فائق آمد، ولی مشکلات هماهنگی و یا ارتباط بین اعضای گروه ممکن است به وجود بیاید که سیستمهای کامپیوتری این مشکلات را به اندازه قابل توجهی کاهش میدهند.
کاهش هزینه؛ کنار هم آوردن گروهی از تصمیم گیران مخصوصاً کارشناسان ممکن است هزینه زیادی داشته باشد. پشتیبانی کامپیوتری ممکن است باعث کاهش تعداد اعضای گروه شده و همچنین  با به وجود آوردن امکان ارتباط اعضای گروه از مکانهای مختلف باعث کاهش هزینه مسافرت و یا سکونت میشود، همچنین استفاده از این سیستمها ممکن است بهرهوری را افزایش دهد که چنین پشتیبانیای از طرف تصمیم گیران مورد نیاز است. افزایش بهرهوری به معنای کاهش هزینه خواهد بود.
ارتباطات پیشرفته؛ گروهها میتوانند با کمک ابزارهای مبتنی بر وب، به راحتی با یکدیگر ارتباط و همکاری داشته باشند.
پشتیبان تکنیکی؛ بسیاری از تصمیمات نیازمند محاسبات پیچیدهای هستند. دادهها می‌توانند در  پایگاه دادههای متفاوتی ذخیره شده باشند، مثلاً در پایگاه دادههایی خارج از سازمان، و یا ممکن است دارای قالبهای مختلفی مثل صدا یا گرافیک باشند، همچنین امکان دارد که انتقال سریع آن‌ها از مناطق دور مورد نیاز باشد که در این زمینه کامپیوترها می‌توانند جستجو، ذخیره و انتقال داده مورد نیاز را با سرعت و با کمترین هزینه انجام دهند.
رقابت، فشار رقابتی تصمیمگیری را مشکل میکند. سازمانها باید قادر به ایجاد تغییرات در روند فعالیت‌ها و ساختارها و همچنین نوآوری به طور متناوب و سریع باشند. فن‌آوریهای پشتیبان تصمیمگیری همانند سیستمهای خبره باعث به وجود آمدن قدرت میشوند. به این طریق انسانها میتوانند تصمیمات مناسبی را به سرعت اتخاذ کنند حتی اگر برخی دانش‌ها را نداشته باشند.
دستیابی به انبار داده؛ انبار دادههای بزرگ، اغلب شامل مقدار زیادی، تا حدود پتا بایت داده میباشند. برای سازماندهی و جستجو این دادهها، روشهای خاص و گاهی محاسبات موازی، نیاز است. ]3[
پشتیبان کیفیت؛ سیستم‌های پشتیبان تصمیمگیری میتوانند کیفیت تصمیمات گرفته شده را بهبود بخشند. برای مثال گزینههای بیشتری توسط تصمیم گیران قابل بررسی بوده، آنالیز ریسک به سرعت قابل انجام است. همچنین نظرات کارشناسان مختلف که ممکن است در مکانهای متفاوتی باشند به سرعت قابل جمعآوری هستند. با استفاده از کامپیوترها، تصمیم گیران میتوانند شبیهسازیهای پیچیدهای انجام داده و بسیاری از سناریوهای ممکن را بررسی کرده و اثرات متفاوت آن‌ها را به سرعت و با هزینه کم بررسی کنند.
بیشتر روش‌های پشتیبان تصمیمگیری، پرسوجوی داده سریع و استفاده از مدلها را، برای تبدیل داده به اطلاعات قابل استفاده، برای رسیدگی به وسیله یک تصمیمگیرنده، فراهم میکنند. مثلاً داده می‌تواند به یک مدل پیشبینی داده مدل شود، این مدل بر اساس دادهها، یک پیشبینی انجام میدهد. ممکن است نتیجه پیشبینی به عنوان اطلاعات برای تصمیمگیری، استفاده شود. بعلاوه  ممکن است توسط مدل دیگری نیز به کار گرفته شود و بدین وسیله اطلاعات و یا دانش اضافی را برای تصمیمگیری فراهم میکند. ]3[
2-7-5 مفهوم سیستم‌های پشتیبان تصمیم:اوایل 1970 اسکات- مورتون برای اولین بار مفهوم مهم سیستم پشتیبان تصمیمگیری  را بررسی کرد. او سیستم پشتیبان تصمیمگیری را به عنوان یک  سیستم مبتنی بر کامپیوتر محاورهای که به تصمیمگیرندهها در تجزیه و تحلیل دادهها و استفاده از مدلها، برای حل مسائل غیر ساخت‌یافته، کمک میکند، تعریف کرد. بنا به تعریف دیگری از اسکات-مورتون وکین (1978) سیستم پشتیبان تصمیمگیری  برای بهتر کردن کیفیت تصمیم،  منابع عقلانی شخص را با تواناییهای کامپیوتر، پیوند میدهد.  ] 4[
یک تعریف کلاسیک دیگر از سیستم پشتیبان تصمیمگیری  به شرح زیر است:
سیستمهای پشتیبان تصمیم، سیستمهایی هستند که منابع فکری شخصی را با تواناییهای کامپیوتر، برای بهبود کیفیت تصمیم، پیوند میدهد. سیستم پشتیبان تصمیمگیری  یک سیستم پشتیبان مبتنی بر کامپیوتر برای مدیریت تصمیم گیرها، کسانی که به مسائل نیمه ساخت‌یافته رسیدگی میکنند، است.
کلمه سیستم پشتیبان تصمیمگیری معمولاً برای توصیف هر سیستم کامپیوتری که تصمیم‌گیری را در یک سازمان پشتیبانی کند، استفاده میشود.  یک سازمان ممکن است برای حل مسائل، یک سیستم مدیریت دانش برای همه کارمندان خود، داشته باشد. یک سیستم پشتیبان تصمیمگیری که به طور صحیحی طراحی شده باشد، میتواند یک نقش مهم را در گردآوری اطلاعات مفید از دادههای اولیه، سندها، دانش شخصی و مدلهای تجاری، برای حل مسئله، ایفا کند. این سیستم،   به تصمیمگیرندهها اجازه میدهد که تعداد زیادی از محاسبات را به سرعت انجام دهند. بنابراین مدلهای پیشرفته میتوانند برای حل مسائل تصمیم پیچیده، وضعیتهای اضطراری که اغلب نیاز به پاسخهای سریع دارند، توسط سیستم پشتیبان تصمیمگیری  پشتیبانی شوند. بسیاری از مسائل تصمیم تجاری، شامل مجموعه دادههای  بزرگی هستند که در پایگاه دادههای مختلف، انبارهای داده، و یا حتی در وب سایتهای خارج از سازمان  ذخیره شدهاند، سیستم پشتیبان تصمیمگیری میتواند برای کمک به تصمیمگیری، به طور موثری دادهها را بازیابی، پردازش و تجزیه تحلیل کند.  
 یک سیستم پشتیبان تصمیمگیری  برای پشتیبانی  تصمیمگیرنده در حل یک مسئله طراحی میشود نه برای جایگزینی آن. تواناییهای تصمیمگیرندهها از طریق استفاده از سیستم پشتیبان تصمیمگیری، به خصوص در موقعیتهای تصمیم‌های غیر ساخت یافته، افزایش مییابد. در این مورد ممکن است هدف تصمیمگیری، به جای راهحل بهینه، یک راهحل، مطلوب و راضیکننده، باشد. حل مسائل غیر ساخت یافته معمولاً از طریق تعامل سیستم پشتیبان تصمیمگیری و تصمیم‌گیرنده، حاصل میشود. میخواهیم به تصمیمگیرندهها کمک کنیم تا بتوانند بهتر تصمیمگیری کنند. هر چند که تصمیمگیری بهتر به معنی تصمیمگیری سریع‌تر نیست. اما محیطهای تجاری که به سرعت تغییر میکنند، اغلب نیازمند تصمیمگیریهای سریع هستند  که ممکن است برای کیفیت تصمیمگیری، زیان بخش باشند.
2-7-6 انواع سیستم‌های پشتیبان تصمیم گیری:مطابق با معیارهای مختلف، سیستم پشتیبان تصمیمگیری  میتواند به انواع متفاوتی طبقهبندی شود. مانند سیستم پشتیبان تصمیمگیری شخصی، سیستم پشتیبان تصمیمگیری گروهی، سیستم‌های پشتیبان مدیر اجرایی، سیستم پشتیبان تصمیمگیری مبتنی بر وب، سیستم پشتیبان تصمیمگیری راهبردی، سیستم پشتیبان تصمیمگیری  برنامهریزی مالی، سیستم پشتیبان تصمیم‌گیری  مبتنی بر مدل، سیستم پشتیبان تصمیمگیری مبتنی بر ارتباطات، سیستم پشتیبان تصمیمگیری مبتنی بر داده، سیستم پشتیبان تصمیمگیری مبتنی بر سند و سیستم پشتیبان تصمیمگیری مبتنی بر دانش. 
2-7-7 روش‌های پشتیبان تصمیم گیری:
سیستمهای پشتیبان تصمیم بر طبق روشهای پشتیبان تصمیم متفاوتی، که شامل مدلها، روشها، الگوریتمها و ابزارها میباشند، ساخته میشوند. ] 3[
یک طبقهبندی مبتنی بر شناخت برای روشهای پشتیبان تصمیم پیشنهاد شده که شامل 6 کلاس اصلی است.
مدلهای پردازش: مدلهای محاسباتی هستند که به پیشبینی فرایندهای پیچیده دنیای واقعی، کمک میکنند و فرضیاتی را درباره فرایند و یک تصمیم فرضی میدهند.
مدل پردازش نمونه، مدل احتمالی است، که یک توزیع احتمال از خروجیها  را از یک توزیع احتمال شرایط ورودی در طی یک عملیات تحلیلی بر روی ورودیها و رفتار فرایند، محاسبه میکند. زنجیره مارکوف یک مثال معمول از یک مدل پردازش احتمال است.
مدلهای انتخاب، از یکپارچهسازی ضوابط تصمیمگیری از میان پیشنهادها برای انتخاب بهترین پیشنهاد از یک مجموعه مجزا یا یک فضای توصیفی پیوسته از پیشنهادهای تصمیم، پشتیبانی میکنند. یک مدل انتخاب نمونه، یک مدل تصمیمگیری چندمعیاره است.
روشهای کنترل اطلاعات، توابعی از بازنمایی، دست‌کاری دادهها، دستیابی و بازبینی داده و اطلاعات  را ارائه میکنند.
روشهای نمونه شامل ابزارهای مدیریت پایگاه داده، روشهای بازیابی داده و دانش، انبار داده و  دادهکاوی هستند.
روشهای استدلال و تحلیل شامل برنامهنویسی ریاضی، استنتاج مبتنی بر هدف، استنتاج مبتنی بر پردازش و استنتاج مبتنی بر داده میباشند.  برنامهنویسی هدف، استدلال مبتنی بر مورد و تحلیل حساسیت در برنامه‌ریزی خطی نیز، روشهای استدلال و تجزیه و تحلیل موفقی هستند.
2-7-8سیستم پشتیبان تصمیم گیری و اجزا آن:
یک سیستم پشتیبان تصمیمگیری میتواند از چهار زیر سیستم تشکیل شود، این زیر سیستم‌ها عبارتند از:
زیر سیستم مدیریت داده
زیر سیستم مدیریت مدل
زیر سیستم واسط کاربر
زیر سیستم مدیریت پایگاه دانش

شکل 2-15- ساختار یک سیستم پشتیبان تصمیمزیر سیستم مدیریت داده میتواند با انبار داده سازمان (یک انبار برای دادههای مربوط به تصمیمگیری در سازمان) ارتباط برقرار کند. معمولاً دادهها در پایگاه دادههای مختلف ذخیره شدهاند و یا اینکه از طریق یک سرور وب پایگاه داده، در دسترس قرار میگیرند.
زیر سیستم مدیریت مدل؛ یک بسته نرمافزاری است که حاوی امور مالی، احتمالات و علم مدیریت است  و یا مدلهای کمی دیگری که تواناییهای تجزیه و تحلیل سیستم و نرمافزار منتسب مدیریت، را آماده میکند. همچنین زبان‌های مدلسازی برای ساخت مدلهای خاص نیز وجود دارند. این نرمافزار معمولاً سیستم مدیریت پایگاه مدل نامیده میشود. این جزء میتواند با  مدلهای سازمان یا مدل‌های ذخیره شده خارجی، ارتباط برقرار کند. روشهای حل مدل و سیستمهای مدیریت، در سیستمهای توسعه وب،  برای اجرا بر روی سرورهای کاربرد، اجرا شده هستند.  
زیر سیستم واسط کاربر؛ کاربر با آن ارتباط برقرار میکند و میتواند از طریق این زیر سیستم  به سیستم پشتیبان تصمیمگیری  فرمان دهد. کاربر بخشی از سیستم مطرح شده است. اثبات شده است که برخی از کارهای منحصر به فرد سیستم پشتیبان تصمیمگیری  از فعل و انفعال اینترنتی بین کامپیوتر و  تصمیمگیرنده، مشتق شدهاند. مرورگر وب، یک ساختار رابط کاربر گرافیکی سازگار آشنا، برای بیشتر سیستم پشتیبان تصمیم گیری، فراهم میکند.
زیر سیستم مدیریت پایگاه دانش؛   این زیر سیستم میتواند هر زیر سیستم دیگر، یا هر عمل دیگری را به عنوان یک جزء مستقل، پشتیبانی کند. همچنین میتواند هوشمندی را برای  تصمیمگیرندهها، فراهم  کند. همچنین میتواند  به مخزن دانش سازمان که گاهی به آن پایگاه دانش سازمانی میگویند،  متصل شود. دانش میتواند از طریق سرورهای وب تهیه شود. بسیاری از روشهای هوش مصنوعی در سیستمهای توسعه وب اجرا شدهاند مثل جاوا، و یکپارچه شدن آن‌ها با اجزاء سیستم پشتیبان  تصمیمگیری بسیارآسان است.
بنابراین یک سیستم پشتیبان تصمیمگیری  باید شامل سه جزء مهم پایگاه داده و پایگاه مدل و رابط کاربر باشد. زیر سیستم مدیریت پایگاه دانش، اختیاری است اما  با وارد کردن هوشمندی به سه جزء مهم سیستم پشتیبان تصمیمگیری، می‌تواند بسیار سودمند باشد. این اجزا سیستم پشتیبان تصمیمگیری، هر کدام میتوانند به اینترانت سازمان، یا یک اکسترانت و یا اینترنت، متصل شوند. به طور نمونه اجزاء از طریق تکنولوژی اینترنت ارتباط برقرار میکنند. مرورگرهای وب نیز رابط کاربر را  فراهم میکنند.

سیستم مدیریت پایگاه داده:یک پایگاه داده به وسیله یک DBMSایجاد، دستیابی و به روز آوری میشود. بیشتر سیستمهای پشتیبان  تصمیمگیری با یک DBMSرابطهای، تجاری استاندارد، که توانایی‌های زیر را فراهم میکند، ساخته میشوند.توانایی‌های یک DBMSرابطهای در یک سیستم پشتیبان تصمیمگیری: 1-گرفتن یا استخراج دادهها  برای قرار دادن در یک پایگاه داده سیستم پشتیبان تصمیمگیری.2-به روز آوری (اضافه، حذف، ویرایش، تغییر) دادههای ذخیره شده و فایلها.3-وابسته کردن دادهها از منابع مختلف.4- بازیافتن دادهها از پایگاه داده برای پرس و جوها و گزارشات.5-فراهم کردن امنیت دادههای فراگیر , است. و یک پایگاه داده موثر و مدیریت آن میتواند بسیاری از فعالیتهای مدیریتی را پشتیبانی کند. هرچند که قدرت اصلی سیستم پشتیبان تصمیمگیری  زمانی آشکار میشود که دادهها و مدلها با یکدیگر مجتمع شوند.  
2-8 رویکرد های دیگر :
آنچه تا کنون بیان شد، بسترهایی از ملزومات ایجاد یک چارچوب برای برنامه ریزی منابع سازمان می‌باشند. در زمینه ارائه معماری سازمانی و تولید چابک در سازمان‌های تولیدی تحقیقات بسیاری انجام شده است که در این نوع چارچوب‌های ارائه شده مدیریت فرایند کسب و کار و تصمیم گیری هوشمند دیده نمی‌شود. در واقع در اغلب چارچوب‌ها، تاکید اصلی بر روی معماری سازمانی است و سازمان به شکل فرایند محور دیده نمی‌شود. برای رفع نقص عدم تصمیم گیری هوشمند و ارائه سیستم پشتیبان تصمیم گیری، برخی تحقیقات در زمینه ارائه ماژول سیستم پشتیبان تصمیم در سیستم برنامه ریزی منابع سازمان انجام شده‌اند.[33]
این ماژول‌ها نمی‌توانند در سازمان‌های گسترده جوابگوی تعاملات باشند. ولی می‌توانند به عنوان جزئی از سیستم‌های پشتیبان تصمیم در داخل هر یک از سیستم‌های بخش‌های مختلف مورد استفاده قرار گیرند. با توجه به اهمیت توجه به فرایند های کسب و کار و مدل سازی آن‌ها جهت تفهیم به سیستم، چارچوب‌های مختلفی ارائه شده‌اند که از جهت شناخت بهتر سازمان و استخراج جنبه های مختلف آن‌ها نقشه راه مناسبی را ارائه می‌کنند.
جهت ترکیب برنامه ریزی منابع سازمان و ایجاد یک سازمان هوشمند، رویکرد های جدیدی ارائه شده‌اند. این رویکردها جهت استخراج بهینه اطلاعات و ترکیب مناسب در سطح مناسب آن با سیستم برنامه ریزی منابع سازمان لازم و ضروری است. [34]
سیستم پشتیبان تصمیم و نحوه طراحی آن، کاملاً وابسته به نوع سازمان است؛ و شناخت نحوه استخراج، تحلیل، تزریق به سیستم و نتیجه گیری و نهایتاً پاسخگویی آن روش‌های مختلفی را شامل می‌شود.[35][33] .
در زمینه سیستم‌های پشتیبان تصمیم، شناخت لایه های مختلف سیستم و در نظر گرفتن زنجیره تأمین بسیار حائز اهمیت است. سیستم‌هایی نیز در زمینه طراحی و پیاده سازی شده‌اند[36] .که در سازمان‌های تجمیعی جهت برنامه ریزی منابع سازمان در طول زنجیره تأمین، سیستم پشتیبان تصمیم ارائه می‌کنند. اما در سازمان‌های گسترده و سیستم‌های سرویس گرا، نیاز به نسل جدید سیستم‌های پشتیبان تصمیم وجود دارد. تا بتواند پاسخگوی نیاز های جدید سازمان‌های سرویس گرای امروزی باشد. [37]
چارچوب‌های تجمیعی که در آن‌ها برنامه ریزی منابع سازمان منوط بر ارتباطات متقابل است، نسل جدیدی از چارچوب‌ها هستند که جهت بهبود عملکرد تجمیعی و همکاری بین سازمانی می‌باشند. رویکرد های مختلفی در این زمینه ارائه شده‌اند که اغلب جنبه گرا هستند؛ و به دنبال بهبود بخشی از این تعاملات بین سازمانی می‌باشند. [38]
از این دسته چارچوب cooprider et al که با ارائه چارچوب خود به دنبال بهبود تعاملات مشترک بین سازمانی و بالا بردن قابلیت کارکرد و کاربرد سیستم توسط کاربران بوده و این کار را با بهبود سیستم از فاز های اولیه طراحی و همزمان با آن‌ها در نظر گرفتن فرهنگ سازمانی و هماهنگی با کاربران، انجام می‌دهند. [9]
برخی از چارچوب‌های ارائه شده به ساختار ماژولار و نحوه تجمیع بهینه سیستم‌های ERP خصوصاً در صنایع خاص توجه دارند. از جمله آن‌ها می‌توان به kumbhar , 2011) (اشاره کرد که برای چارچوب پیشنهادی، در ابتدا سیستم را شناسایی و سپس به ماژول‌ها و زیر سیستم‌ها تقسیم بندی می‌کند. این کار به بهبود عملکرد سیستم و تعاملات آن کمک کرده و نهایتاً سود مالی را نیز (با توجه به مورد کاوی که انجام شد، اثبات گردید) به همراه داشت. این زیر سیستم‌ها شامل، مالی، مدیریت، منابع انسانی، مدیریت لجستیک، برنامه ریزی استراتژیک و عملیاتی و غیره می‌باشند. [39]
بسیاری از مدل‌ها و رویکرد های ارائه شده بر مدیریت دانش و تصمیم گیری‌ها در زنجیره تولید سیستم و تجمیع آن‌ها، تاکید دارند. این رویکردها جز رویکرد های اولیه بوده و در دوره های اولیه شکل گیری ERP مطرح بودند. [40]
رویکرد های دیگر، بر جنبه های اصلی معماری ERP , تکنولوژی، سازمان، کاربران و مدیریت پروژه و فرایندها، توجه داشته و به بهبود و ارائه چارچوبی مبتنی بر این اجزا با در نظر گرفتن عوامل شکست پروژه های ERP و ایجاد رضایت کاربران، پرداخته‌اند. [41][42]
با توجه به اینکه کلیه راه حل‌های ارائه شده یا به صورت خاص منظوره بوده و یا جوابگوی نیاز های نسل جدید سازمان‌های تولیدی در صنعت خودرو ایران نمی‌باشد و نمی‌تواند تمامی جنبه های مطرح در بهبود و ایجاد چابکی و دستیابی به اهداف آن‌ها را پوشش دهند، بنابراین در این پروژه چارچوبی را پیشنهاد خواهیم کرد که بتواند تمامی جنبه های مطرح شده را پوشش دهند و سازمان‌های تولیدی در صنعت خودرو را در جهت نیل به اهداف خود یاری نمایند و در نهایت یک سازمان با حاکمیت معماری سرویس گرا و چابک داشته باشیم.
یکی از فرایند های لازم برای عملی شدن چارچوب مطرح شده، بهبود شرایط و وضعیت کنونی سازمان، که شامل فرایند های سازمان و در کل، بهبود شاخص‌های مطرح در صنعت و بازار آن سازمان است، می‌باشد، باز مهندسی فرایندها و یا اجرای پروژه مهندسی مجدد فرایندها است. در ادامه با این پروژه آشنا خواهیم شد.
2-9 مهندسی مجدد:
اکثر کتاب‌ها و مقالات علمی، سابقه مهندسی مجدد را دهه 1980 دانسته‌اند . در این دهه در بیشتر سازمان‌های اقتصادی آمریکا یک نارضایتی فراگیر به علت عدم حصول ارزش افزوده بالا از فناوری اطلاعات حاکم شد. این شرکت‌ها با اینکه سرمایه عظیمی برای توسعه فناوری اطلاعات صرف کرده بودند، اما این سرمایه‌گذاری تأثیر چندانی در افزایش بهره‌وری و بهبود عملکرد آنان نداشت.[ 76]
برای حل این مشکل نظریه‌های متفاوتی از سوی کارشناسان و متخصصان ارائه گردید که مهم‌ترین آن‌ها توسط مایکل همر بیان شد.
بر اساس این نظریه، سه نیرو به صورت جداگانه و نیز مشترک، شرکت‌های امروزی را به گونه‌ای روزافزون به سرزمینی هدایت می‌کنند که به چشم مدیران و دست اندر کاران آن هراس‌انگیز و ناآشنا می‌نماید. این سه نیرو عبارتند از: مشتریان، رقبا و تغییرات. که به c3 معروفند. [43]
در این دنیای دگرگون شده، اصول «تقسیم کار» وضع شده از سوی آدام اسمیت که محور سازماندهی شرکت‌ها بود، دیگر کارساز نیست و لذا برای شرکت‌ها سودمند و ضروری نیست تا کار خود را بر پایه این اصول سازمان دهند. ساختار وظیفه گرا در دنیای کسب‌وکار امروز غیر مؤثر بوده و منسوخ است. شرکت‌ها بایستی اینک برگرد محور فرایندها سازماندهی شوند. [44]
به عقیده «همر» این نظریه (مهندسی مجدد فرایندهای کسب‌وکار) به اندازه اندیشه‌های آدام اسمیت در زمان خودش، انقلابی و دور از دسترس می‌نماید. مدیرانی که نظریه «سازمان‌های فرایند گرا» را شناخته و پذیرفته‌اند، راه خود به سوی آینده‌ای پیروزمند گشوده و همواره کرده‌اند و آنان که چنین نمی‌کنند، از کاروان عقب خواهند ماند.
2-9-1تعریف مهندسی مجدد:
در مورد تعریف مهندسی مجدد بین کارشناسان و متخصصان امر اتفاق نظر کامل وجود ندارد و تعاریف گوناگونی برای آن ارائه شده است، در زیر نمونه‌هایی از این تعاریف آمده است:
منگانلی و کلین: «طراحی مجدد ریشه‌ای و سریع فرایندهای استراتژیک و ارزش افزای کسب و کارــ و سیستم‌ها، سیاست‌ها، و ساختارهای سازمانی پشتیبان آن‌ها به منظور بهینه سازی جریان کارها و افزایش بهره‌وری در یک سازمان.» [45]
اُبُلنسکی: «مجموعه کارهایی که یک سازمان برای تغییر فرایندها و کنترل‌های درونی خود انجام می‌دهد تا از ساختار سنتی عمودی و سلسله مراتبی، به ساختاری افقی، میان فعالیتی، مبتنی بر تیم و مسطح تبدیل شود که در آن، همه پردازش‌ها برای جلب رضایت مشتریان صورت می‌گیرد.» [46]
پِپارد و رولاند: «مهندسی مجدد یک فلسفه بهبود است که هدفش دستیابی به بهبودهای مرحله‌ای در عملکرد به وسیله طراحی مجدد فرایندهاست و در این طراحی مجدد، سازمان می‌کوشد فعالیت‌های ارزش افزا را به حداکثر و دیگر فعالیت‌ها را به حداقل برساند. این رهیافت می‌تواند در سطح یک فرایند منفرد و یا در کل سازمان به کار گرفته شود.» [47]
همچنین می‌توان گفت که، شامل طراحی مجدد، اساسی و رادیکال فرایند های کسب و کار است تا بهبود چشم گیری در معیار های کارایی از قبیل هزینه، کیفیت خدمات، و سرعت بدهد. پروژه های موفق مهندسی مجدد در کاهش چشمگیر هزینه و چرخه زمان نقش دارند و کیفیت طراحی را خیلی زیاد بهبود می دهند اگرچه که ممکن است در مقابل انتظارات زیاد مهندسی مجدد این پروژه‌ها با شکست روبه رو شوند.[48]
2-9-2 مرور ادبیات مهندسی مجدد:مهندسی مجدد برای اولین بار توسط همر و چمپی (در سال 1990)با تعریف زیر به جهانیان معرفی شد:
از اندیشه بنیادین و طراحی نو و ریشه‌ای فرایندها‏، برای دستیابی به بهبود و پیشرفتی شگفت انگیز در معیارهای حساس امروزی، همچون قیمت، کیفیت، خدمات و سرعت.
چهار عنصر کلیدی تعریف فوق عبارتند از:
1-تفکر بنیادین: یعنی ترک پیش فرض‌های پذیرفته شده در مورد کار، به فراموشی سپردن نحوه انجام کار در گذشته و پاسخ به این پرسش اساسی که شرکت «چه کاری» را باید انجام دهد و «چگونه»
2-طراحی ریشه‌ای: طراحی ریشه‌ای یعنی کاری را از بن و دوباره طراحی کردن. مهندسی مجدد برپا کردن شرکتی جدید و نو را در نظر دارد، نه بهسازی، اصلاح و بهبود وضع موجود.
3-نتایج شگفت انگیز: هدف مهندسی مجدد دستیابی به جهشی چشمگیر است. فقط هنگامی که یک انفجار و خانه تکانی در نظر باشد‏، باید به سراغ مهندسی مجدد رفت. مهندسی مجدد از بهبودهای جزئی و تدریجی اجتناب می‌کند و بهبودهای عظیم در ظرف کمتر از یکسان را باعث می‌شود.
4-فرآیند: مجموعه گام‌هایی است که یک یا چند درو‌نداد را به کار گرفته و برو‌ندادی می‌آفرینند که برای مشتری سودمند و خواستنی است.
2-9-3 عوامل شكست پروژه‌هاى مهندسي مجدد:
پروژه های مهندسی مجدد فرایندها در ظاهر مناسب و عامل بهبود به نظر می‌رسند اما لزوماً این امکان وجود ندارد. با توجه به سوابق و پروژه های انجام شده، این قضیه ثابت شده که عدم توجه به برخی عوامل نه تنها باعث رشد و بهبود نمی‌شود، بلکه ممکن است نتایج زیان‌باری را هم به دنبال داشته باشد. بنابراین توجه به عوامل موفقیت و شکست پروژه بسیار حائز اهمیت است. [44]
در بیشتر مطالعات و مقالات به تعریف چیستی (WHAT) مهندسی مجدد پرداخته شده است تا به چگونگی (HOW) اجرای آن. درحالی‌که خطر عدم موفقیت بیشتر در روش انجام کار یعنی چگونگی آن نهفته است.
فاكتورهاي منفي بسياري وجود دارند كه در صورتي كه به آن‌ها بها داده نشود، زمينه‌ساز ناكامي مهندسي مجدد خواهند شد. از جمله اين عوامل مي‌توان به موارد ذيل اشاره نمود :[46]
بي‌توجهي به فرايندها.
بي‌اعتنايي به ارزش‌ها و اعتقادات كاركنان.
فرهنگ سازماني كنوني و گرایش‌های مديريت، موانع آغاز مهندسي مجدد هستند‌.
كوشش به راضي نگه‌داشتن همگان
مشارکت ناکافی مدیران ارشد
2-9-4عوامل موفقيت پروژه‌هاى مهندسى مجدد:
در مطالعه 47 سازمان موفق، زیر پا نهادن ‌تفکر کاغذ سفید، یعنی مدل سازی فرایندهای فعلی به عنوان «بهترین شیوه» دستیابی به موفقیت شناخته شد. مدل سازی فرایندها، درک مشترکی از فرایندهای فعلی به دست می‌دهد و اطمینان می‌دهد که هیچ چیز از نظر پنهان نمانده، سازمان را قادر به شناسایی و نگهداری بهترین اجزای فرایندها می‌سازد، خط مبنایی مبتنی بر واقعیت ایجاد می‌کند تا بتوان فرایندهای جدید را با آن مقایسه کرد و پایه‌ای برای برنامه پیاده‌سازی می‌شود[44].
عوامل موفقیت مجموعه‌ای از آموزه‌های ناشی از اجرای مهندسی مجدد است که به عنوان عوامل تسهیل کننده اجرایی مهندسی مجدد عمل می‌کنند.
12 عامل اصلی به عنوان عوامل اصلی مهم و تأثیرگذار شناسایی برخی از آن‌ها در زیر آمده است. هسته مرکزی موفقیت در پروژه‌های مهندسی مجدد، مدیریت مناسب فرایند تغییر است و حمایت و تعهد مدیریت ارشد همچون چتری فراگیر در تمامی مراحل به‌کارگیری موفقیت‌آمیز مهندسی مجدد نقشی اساسی دارد. حال به بیان برخی از آن‌ها می‌پردازیم:[46]
– حمایت و تعهد مدیریت ارشد
– مدیریت تغییر(عوامل فرهنگی)
– تحریک افراد و سازمان به پذیرش تغییر، فرهنگ‌سازی، آموزش،‏ توانمند سازی، مشارکت کارکنان
– مدیریت تغییر (عوامل سیستمی و ساختاری)
– درک اصول و مفاهیم مهندسی مجدد
– مدیریت پروژه
– متدولوژی مدون
– بهره‌گیری از فناوری اطلاعات
و غیره …
2-10جمع بندی :
با توجه به آنچه بیان شد، در این پروژه به دنبال ERP هایی هستیم که به صورت تجمیعی و همکار در سازمان‌های گسترده بتوانند پاسخگو باشند. این ERP نیاز است تا بر بستر سرویس گرایی و معماری سرویس گرا پیاده سازی شود تا مقصود نهایی (حاکمیت معماری سرویس گرا) محقق شود. همچنین در سیستم نهایی برای بهبود تصمیم گیری از DSS استفاده شود. اما همان طور که بیان شد، ERP موجود در شرکت‌های خصوصاً ایرانی یا به شکل گسترده نیستند و یا بر بستر سرویس‌ها پیاده سازی نشده‌اند. از طرفی در بسیاری از سازمان‌ها صرف محاسبات سرویس گرا پیاده سازی می‌شود و حاکمیت معماری سرویس گرا مدنظر قرار نمی‌گیرد. از طرفی برای نیل به این اهداف نیاز به بهبود فرایند های کسب و کار و باز مهندسی بر آن‌ها هستیم تا بتوانیم به یک معماری سرویس گرا ی بهبود یافته برای برنامه ریزی منابع سازمان دست یابیم؛ لذا برای دست یابی به آنچه بیان شد به یک رویکرد فکری و عملی نیازمندیم تا کلیه نیازمندی‌های سیستم را در آن بگنجانیم و در عین حال سازمان را چابک و قابل رقابت در بازار های امروزی تبدیل نماییم و از طرفی به اهداف سازمان دست یابیم. همان طور که پیش‌تر بیان شد، چارچوب‌ها و رویکردهایی که تاکنون ارائه شده‌اند اغلب خاص منظوره بوده و جوابگوی کلیه نیاز های مطرح شده نیستند و صرفاً بر مبنای یکی از نیازها، ERP تجمیعی، DSS , معماری یا محاسبات سرویس گرا، تولید بر اساس نیاز زنجیره تأمین، مطرح شده‌اند. بنابراین همچنان نیاز به یک چارچوب سرویس گرا و مبتنی بر DSS برای ERP های تجمیعی در سازمان‌های تولیدی وجود دارد.

فصل سوم
یافته های تحقیق

3-1 مقدمه:
امروزه نیاز به ERP و هماهنگی بین فناوری و کسب و کار در کل سازمان‌ها اثبات شده و واضح است. اما مسئله مهم، عدم هماهنگی سیستم‌های پیشنهادی به سازمان‌ها و ماهیت و عملکرد واقعی سازمان‌ها است. همواره فاصله عظیمی بین کارایی مورد انتظار سیستم پیشنهادیERP و آنچه که در واقعیت در سازمان مشاهده می‌شود وجود دارد. [50] [49]
لذا منطبق بودن استراتژی‌ها و اهداف سازمان و در ادامه فرایندها و رویکردها و فرهنگ سازمان با سیستم هماهنگ کننده سازمان بسیار حائز اهمیت است. زیرا با توجه به آمار های بیان شده در فصل‌های قبل، استفاده از سیستم‌های ERP در سال 2004 , 14 % شده که معادل 23.6 میلیارد دلار است و این رقم در سال 2001 , 5.5 % بوده است. از طرفی درصد بالایی از پروژه‌های ERP با شکست مواجه شده‌اند. [8]
بنابراین نیازمند یک رویکرد فکری صحیح و یک مدل مفهومی منطبق با نیاز های سازمان‌ها می‌باشیم تا ریسک پروژه پیاده سازی سیستم‌های ERP را در سازمان پایین آورده و از مزایای آن بهرمند شویم. [51] در شکل زیر جنبه های مطرح در مدل موفقیت ERP را مشاهده می‌کنید. این جنبه‌ها شامل تطبیق داده، فرایند و هماهنگی با کاربر در سازمان و جنبه های هزینه، زمان، کارایی و سود در پیاده سازی ERP، می‌باشند. این جنبه‌ها در یک مدل منطقی منطبق باید لحاظ شوند.

شکل (3-1) جنبه های مطرح درERP [52]
البته نباید تأثیر کاربران را در این پذیرش نادیده گرفت. [53]و هرچه مشخصه آسانی در کاربرد در سیستم بیشتر باشد، احتمال موفقیت پروژه بالا تر خواهد بود.
با توجه به مطالب بیان شده در فصل‌های قبل، هدف اصلی این پروژه، ارائه یک چارچوب سرویس گرا است تا بتوان از آن به عنوان یک نقشه راه و یا یک رویکرد فکری جهت پیاده سازی ERP در سازمان‌های تولیدی امروزی استفاده کرد. این رویکرد باید سازمان را چابک نموده و آن‌را به سمت یک سازمان سرویس گرا و با حاکمیت معماری سرویس گرا ببرد. برای رسیدن به این مهم، نیازها و ملزوماتی وجود دارد. که در چارچوب پیشنهادی تلاش شده است که به آن‌ها پرداخته شود و در عین حال کلیه جوانب، ارتباطات، نیازها و تکنولوژی‌ها در نظر گرفته شود. بهبود حاصل شده بعد از پیاده سازی، نسبی است و نمی‌توان ادعا کرد که پس از پیاده سازی این چارچوب یک سازمان بهینه از هر جهت خواهیم داشت. زیرا در اجرای این چارچوب بسیاری از محدودیت‌ها و مشکلات لحاظ می‌شوند؛ و به نوعی منطبق با شرایط، به دنبال بهینه‌ترین حالت ممکن می‌گردد. بنابراین بهبود حاصل شده منطبق با شرایط جاری سازمان خواهد بود. در ادامه به بیان جزئیات این چارچوب پرداخته خواهد شد.
3-2 مدل سازی سازمان :
از نیازمندی‌های اولیه برای بیان هر چارچوب، مدل سازی سیستم است. مدل سازی سیستم به شکل‌ها و بیان‌های مختلف در بررسی‌ها و تصمیم گیری‌ها و فرایند های مدیریتی، نقشی اساس دارند.
44615101587500Models
00Models
Content diagram
Functional diagram
Behavioral diagram
Domain diagram
Structural diagram
First needed diagram
Model structure
Model configuration
Model function
Rapid prototyping
Object diagram
Resource diagram
Configuration diagram
Behavioral diagram
Content diagram
Functional diagram
Behavioral diagram
Domain diagram
Structural diagram
First needed diagram
Model structure
Model configuration
Model function
Rapid prototyping
Object diagram
Resource diagram
Configuration diagram
Behavioral diagram

شکل (3-2) – خروجی‌های مختلف از مدل‌های سیستم مورد استفاده در چارچوب معماری ERP
همان طور که در شکل (3-2) بیان شده است, در گام‌های مختلف خروجی‌های مختلفی از مدل‌های سیستم خواهیم داشت که در بخش‌های مختلفی از چارچوب معماری ERP مورد استفاده قرار می‌گیرند. کلیه مدل‌های سیستم که در این چارچوب مورد استفاده قرار می‌گیرند و هم چنین ترتیب ایجاد آن‌ها در شکل (3-2) بیان شده است.
3-3 پیاده سازی BPR :
3-3-1 لزوم و نیاز:
همان طور که در بخش‌های گذشته بیان شد، در پیاده سازی هر چارچوب اجرایی در هر سازمان در ابتدا شناخت و در جریان پیاده سازی چارچوب، بهبود فرایند های سازمان، بسیار حائز اهمیت است. اجرای مهندسی مجدد فرایندها می‌تواند به عنوان پیش نیاز و یا همزمان با ERP انجام شود. در این پروژه به شکل همزمان انجام می‌شود. به این معنا که در ابتدا فاز شناخت انجام می‌شود؛ و سپس با توجه به معماری مطرح، به بهبود پرداخته می‌شود. زیرا شناخت صحیح سازمان و تطبیق معماری سازمان با فرایندهای آن بسیار با اهمیت است. نمی‌توان همواره از موفقیت پروژه و تطبیق فرایندها اطمینان حاصل کرد. عواملی هستند که می‌توانند در موفقیت یا شکست مهندسی مجدد فرایندها موثر باشند.
عوامل موفقیت مجموعه‌ای از آموزه‌های ناشی از اجرای مهندسی مجدد است که به عنوان عوامل تسهیل کننده اجرایی مهندسی مجدد عمل می‌کنند. پروژه های مهندسی مجدد فرایندها در ظاهر مناسب و عامل بهبود به نظر می‌رسند اما لزوماً این امکان وجود ندارد. با توجه به سوابق و پروژه‌های انجام شده، این قضیه ثابت شده که عدم توجه به برخی عوامل نه تنها باعث رشد و بهبود نمی‌شود، بلکه ممکن است نتایج زیانباری را هم به دنبال داشته باشد. بنابراین توجه به عوامل موفقیت و شکست پروژه بسیار حائز اهمیت است. [54][55]
گرینبرگ هفت اشتباه رایج در این پروژه‌ها را بیان می‌دارد: تعریف مبهم از چیستی مهندسی مجدد، انتظارات غیر و واقعی، منابع ناکافی، تاخیر بیش از حد پروژه مهندسی مجدد، فقدان حمایت و پشتیبانی، تعریف نادرست حیطه پروژه، فقدان یک متدولوژی موثر، تاکید خیلی زیاد یا خیلی کم بر فناوری اطلاعاتی. [56][57]
برخی دیگر از محققان از عواملی از قبیل فقدان منابع مالی و نیروی انسانی، قابلیت‌های ناکافیIT ، فقدان خبرگی از مشکلات حین اجرای مهندسی مجدد نام برده‌اند؛ و همچنین عواملی مثل عدم پشتیبانی هیئت مدیره سازمان، فقدان چشم انداز استراتژیک، ساختار سازمانی غیر منعطف، و نبود قهرمان برای تلاش‌های مهندسی مجدد را در کنار سایر عوامل اصلی نام برده‌اند. [58]
ابلسکی اکثر تجربه های ناموفق در فرایند مدیریت تغییر را ناشی از پنج عامل عدم درک کامل و جامع منطق تغییر توسط سازمان و کارکنان، عدم برنامهریزی جامع و دقیق برای تغییر، نداشتن مدیریت صحیح و مطلوب بر پویایی انسانی، استفاده نکردن صحیح از سیستم‌های مناسب کنترل و ارزیابی خود مهندسی مجدد در عمل، و بزرگ‌تر بودن میزان فشار حاصل از تغییر در وضع موجود به همراه منافع عائده می‌داند[59]
کاودل شش عامل کلیدی موفقیت با عناوین، درک مهندسی مجدد، ایجاد یک موقعیت کاری و سیاسی، پذیرش یک رهیافت مدیریت فرایند، اندازه گیری و پیگیری مستمر عملکرد، اعمال مدیریت تغییر، وجود حمایت سازمان را موثر می‌داند. [59]
در مطالعه 47 سازمان موفق، زیر پا نهادن ‌تفکر کاغذ سفید، یعنی مدل سازی فرایندهای فعلی به عنوان «بهترین شیوه» دستیابی به موفقیت شناخته شد. مدل سازی فرایندها، درک مشترکی از فرایندهای فعلی به دست می‌دهد و اطمینان می‌دهد که هیچ چیز از نظر پنهان نمانده، سازمان را قادر به شناسایی و نگهداری بهترین اجزای فرایندها می‌سازد، خط مبنایی مبتنی بر واقعیت ایجاد می‌کند تا بتوان فرایندهای جدید را با آن مقایسه کرد و پایه‌ای برای برنامه پیاده‌سازی می‌شود[60].
المشاری و زئیری عوامل موفقیت و شکست مهندسی مجدد را در پنج دسته طبقه‌بندی کرده‌اند: مدیریت تغییر در سیستم‌های مدیریت و فرهنگ، شایستگی و حمایت مدیریت، ساختار سازمانی، برنامه‌ریزی و مدیریت پروژه مهندسی مجدد، و زیر ساخت‌های فناوری اطلاعات. هر دسته خود می‌تواند شامل زیر مواردی باشد که توجه به آن‌ها موجب موفقیت در اجرا و عدم توجه شکست را در پی دارد [61].
3-3-2 گام‌های BPR :
با توجه به آنچه بیان شد، صرفاً با در نظر داشتن BPR در یک سازمان، نمی‌توان موفقیت آن را تضمین کرد. در این پروژه نیز با در نظر گرفتن این نکات و همچنین روش‌های صحیح در مهندسی مجدد فرایند‌ها در شرکت‌های ایرانی به پیاده سازی BPR پرداخته شد.
گام‌های انجام این رویه‌های مشترک (اجرای ERP و BPR) را می‌توان در یک الگوریتم با اصول 9 گانه جای داد. این الگوریتم، الگوریتم PIP، گام‌هایی را شامل می‌شود که شامل: [62]

شکل (3-3) چرخه شناخت اولیه سازمان
1- تعیین آرمان‌ها، چشم انداز ها و دیدگاه های شرکت
2- تعیین اهداف و مأموریت‌های شرکت
3- تعیین استراتژی‌ها و فرایندهای کسب و کار شرکت
4- تعیین محدوده برای BPR
5- انجام طراحی مجدد
I. تعیین حدود و اهداف فرایند
II. دید کلی از فرایند
III. نقشه و مدل کردن فرایند
IV. شکست و استخراج فعالیت‌ها و لیست وظایف
V. آنالیز فرایند و تعیین فعالیت‌های لازم