منابع و ماخذ مقاله سیستم پشتیبان تصمیم، سرویس گرا، زنجیره تأمین

دانلود پایان نامه ارشد

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

شکل (3-21) – چارچوب CoERP – چارچوب سرویس گرا از collaborative ERP

چارچوب CoERP در شکل (3-21) , یک چارچوب سرویس گرا از collaborative ERP است که در آن DSS برای بهبود دانش سازمانی و کارایی بیشتر به شکل کاملاً توزیع شده و سرویس گرا با ERP تجمیع شده است. برای نیل به این هدف، در ابتدا در هر بخش از سازمان توزیع شده، نیاز به ERP و DSS به شکل مجزا است (شکل تعامل DSS و ERP) . دلیل اصلی آن، بهره گیری از تمرکز روی اطلاعات و کارایی بیشتر است. زیرا عملکرد هر بخش با بخش دیگر متفاوت است و تصمیمات مدیریتی و اجرایی در هر بخش ممکن است نتایج متفاوتی را از بخش دیگر ایجاد کند. از طرفی به این شکل تصمیمات تخصصی‌تر و کارا تر خواهد بود زیرا با تمرکز بیشتر و با آشنایی بیشتری با بخش‌های مختلف انجام خواهد شد.
اما در سطح کلان‌تر نیاز به یک نگاه از بالا به پایین داریم. تا هماهنگی بین بخش‌ها و تصمیمات کلی‌تر و حیاتی‌تر را برای سازمان تأمین کند. منابع و دانش و اطلاعات در سطح کلان با ترکیب کردن و توجه به تک تک بخش‌های خرد (زیر سیستم‌ها) انجام می‌شود. بنابراین، در هر زیر بخش ERP ،DSS مختص آن بخش را خواهیم داشت و در کل سازمان نیاز به یک DSS عمومی است، که عملاً نقش ترکیب کننده و نرمال کننده کلیه اطلاعات و تصمیمات سازمانی را بر عهده دارد. برای فراهم سازی چنین بستری نیاز به مکانیزم‌ها و ماژول‌های خاصی است که این همکاری‌ها را ممکن و عملی سازد. این بسترها و زیر ساخت‌ها از طریق ابزارها، مدل‌ها و تکنولوژی‌ها تأمین می‌شوند.

3-7 ساختار ERP در زنجیره تأمین :

شکل (3-22) چارچوب DE (DSS-ERP ) بستر مناسب جهت تجمیع ERP و DSS در سیستم توزیع شده

برای تجمیع DSS و ERP، یک چارچوب DE (DSS-ERP) تخصیص داده شده است. همان طور که در شکل (3-22) می‌بینیم این چارچوب بستر مناسب را جهت تجمیع ERP و DSS در سیستم توزیع شده، فراهم می‌کند. این چارچوب بر روی زنجیره تأمین (supply chain) ایجاد شده است اما در کنار آن بستر سیستم و تکنولوژی را به آن افزوده است. در مرکز، یک سیستم مرکزی است که تجمیع کننده و واسط بین کلیه برنامه‌ها، ERP ها,DSS ها و تکنولوژی‌ها است. هر بخش می‌تواند در هر زمان با سازمان مرکزی (هسته سیستم مرکزی، که در اینجا قسمت integration از enterprise است)، ارتباط و همچنین با سایر بخش‌های مربوط به تأمین یا مشتری، همکاری و تعامل داشته باشد. در هر زیر بخش تصمیم گیرندگان به سیستم مرکزی دسترسی دارند تا بتوانند تصمیمات را دست‌کاری و یا تصمیمات جدید اتخاذ کنند. تصمیم گیرندگان با استفاده از محیط داخل سازمان و یا از طریق زنجیره تأمین، می‌توانند به داده‌ها از طریق ارتباطات دسترسی پیدا کنند و با استفاده از زیر ساخت‌های IT از تکنولوژی‌های ارتباطی در جهت ایجاد و بهبود تصمیمات خود استفاده کنند.
در گام بعدی نیاز به بیان اجزا، پیش نیازها و ورودی و خروجی‌های هر کدام از DSS ها و ERP ها در درون چارچوب CoERP ، برای یک سازمان تولیدی می‌باشد.
در یک سازمان تولیدی، پیش نیاز اولیه، ایجاد یک کانال تبادل اطلاعاتی بین سیستم برنامه ریزی و بخش تولید و ایجاد یک سیستم تجمیعی real-time برای تولید است و از بین بردن گپ‌های اطلاعاتی یک نکته کلیدی در دست یابی به این اهداف و ایجاد یک محیط عملیاتی و تولید چابک است. بنابراین باید به دنبال ساده سازی و حذف لایه های مختلف نرم افزاری و حذف لایه های نرم افزاری غیر ضروری و در نظر گرفتن استاندارد های سیستمی در کسب و کار بود. 3 عنصر مهم در استراتژی این معماری موارد زیر می‌باشند.
1. سرمایه گذاری روی تکنولوژی ساخت برنامه های کاربردی
2. تجمیع و همکاری بهینه برنامه های کاربردی
3. وب سرویس و شبکه جهت پیاده سازی پروژه‌ها و برنامه های کاربردی تولید

3-8 معماری داخلی ERP بخش‌های سازمانی

معماری سازمان تولیدی در شکل (3-22) نشان داده شده است. برای نیل به استراتژی‌های مذکور XML ,OPC یک راه بسیار ساده جهت ایجاد تبادل اطلاعات استاندارد است. OPC، یک فرمت ساده از بیان فرایندی بوده و به تبادل اطلاعات بین برنامه‌ها، سخت افزارها و فرایندها تمرکز دارد و XML، یک فرمت داده استاندارد بوده و به نگه داری و تبادل اطلاعات بین برنامه‌ها تمرکز دارد. بنابراین کاربران به راحتی می‌توانند تبادلات مختلف را انجام دهند. به همین جهت یک لایه میانی که شامل XML , OPC و سایر مدل‌ها و زیرساخت‌های میانجی و بینابینی است، وجود دارد. این چارچوب از یک بخش فرایندی اصلی و از یک بخش پشتیبانی و مدیریتی تشکیل شده است. از دلایل اصلی استفاده از این فرمت‌های استاندارد پیاده‌سازی سرویس‌هاست که برای دست یابی به اطلاعات و تصمیمات real time نیازمند این تبدیلات می‌باشیم.
قسمت فرایندی، شامل فرایندهای عام تولیدی است، که شامل، انبار مواد اولیه، فرایند تولید، فرایندهای کنترل کیفی و لجستیک که اصولاً به صورت همگام و یا مرتبط با تولید انجام می‌شوند و فرایند انبار محصول نهایی است. اطلاعات این فرایندها در مدیریت اطلاعات فرایندها استخراج و در قسمت لایه میانی به شکل نرمال و استاندارد تبدیل می‌شود تا در بخش‌های دیگر مورد استفاده قرار گیرد.
بخش‌های کنترلی و پشتیبانی که در قسمت بالای این معماری قرار دارند، شامل: مدیریت انبار، برنامه‌ریزی، مدیریت و برنامه ریزی تولید، بهینه سازی فرایند، مدیریت مواد و برنامه ریزی منابع انسانی است. این فرایندهای کنترل و پشتیبانی به صورت کاملاً همکار با هم و با فرایندهای اصلی کار می‌کنند. برای مثال مدیریت انبار با توجه به برنامه ریزی تولید، به میزان مورد نیاز از مواد اولیه پی می‌برد و با توجه به فضای در دسترس انبار به مدیریت آن می‌پردازد و اطلاعات و تصمیمات آن به مدیریت مواد می‌رود. مدیرت انبار، به برنامه ریزی و کنترل موجودی انبار می‌پردازد. اطلاعات مربوط به این بخش از اطلاعات مهمی است که کلیه فرایندهای تولید را تحت تاثیر قرار می‌دهد.
برنامه ریزی، به کلیه فرایندهای برنامه‌ریزی در زمینه مواد اولیه، میزان تولید، کیفیت مورد نیاز، نحوه انجام فرایندها و سایر برنامه‌ریزی‌ها می‌پردازد و یک پایگاه هماهنگی بین سایر فرایندهای کنترلی است. برنامه‌ریزی تولید، به برنامه‌ریزی در زمینه میزان تولید، نحوه تولید و کیفیت تولید نیز می‌پردازد. بهینه‌سازی فرایند، به برنامه‌ریزی و توسعه و بهبود فرایندها در جهت بهبود و دست‌یابی به یک فرایند بهینه و ناب می‌پردازد. این بهبود شامل: کاهش زمان تولید، کاهش هزینه تولید، چابک سازی فرایند و غیره می‌باشد. مدیریت مواد، , به مدیریت مواد اولیه مورد نیاز با توجه به مدیریت و برنامه‌ریزی انبار و برنامه‌ریزی تولید می‌پردازد. نهایتاً برنامه‌ریزی منابع انسانی که مربوط به تخصیص فرایندها به افراد و واحدهای کاری است. همواره این معماری به دنبال فرایند گرایی و اصالت فرایند است. به همین دلیل از افراد به شکل پویا و با توجه به کارکرد و روند فرایند استفاده می‌کند.
در این معماری دو بخش سیستمی دیگر وجود دارد. که اطلاعات مربوط به بخش فرایندهای تولیدی را دریافت و آن‌ها را بررسی و ارزیابی می‌کند. بخش مدیریت کیفیت، شاخص‌های مورد نیاز خود را از لایه میانی و با فرمت استاندارد دریافت می‌کند و بررسی‌ها را انجام می‌دهد. نهایتاً این پارامترهای ارزیابی در تصمیمات و برنامه ریزی‌های بخش کنترلی موثر خواهد بود. بخش مدیریت مهندسی به مدیریت و ارزیابی کیفیت و نحوه کارکرد سیستم‌ها، برنامه‌ها و زیرساخت‌ها می‌پردازد. این معماری سازمان تولیدی مورد نظر است که در آن به برنامه‌ریزی منابع سازمان پرداخته شده است؛ و یا به بیان بهتر معماری داخلی individual ERP است.
بخش بعدی که در تعامل با هر individual ERP می‌باشد و عملکرد آن نیز در مطالب قبلی بیان شد، individual DSS است. معماری داخلی آن مطابق شکل (3-22) است. این سیستم پشتیبان تصمیم مختص هر ERP خاص است. خوراک اولیه آن از اطلاعات مربوط به آن سیستم (ERP آن سیستم یا زیر سیستم) است. همان طور که بیان شد در هر سیستم و یا زیرسیستم اطلاعات به شکل نرمال و استاندارد تبدیل می‌شوند تا امکان انتقال آن‌ها بین سیستم‌های مختلف و وب سرور به راحتی انجام شود. بنابراین اطلاعات اولیه وارد سیستم پشتیبان تصمیم می‌شود. این سیستم از یک پایگاه داده (شامل داده‌ها و قوانین اولیه)، و یک موتور استنتاج تشکیل شده است (عملکرد آن پیش‌تر بیان شد). برای دسترسی به این سیستم در ابتدا داده‌ها از سیستم ERP با فرمت مناسب وارد و ارزیابی می‌شوند تا اطلاعات مخرب یا نادرست نباشند. سپس داده‌ها با داده‌های قبلی و قوانین قبلی ترکیب و تبدیل به نمودارها و جدول‌ها می‌شوند. این بخش مسئول بازرسی و ارزیابی است. سپس اطلاعات به بخش تصمیم‌گیری و بهینه‌سازی می‌روند؛ و نتایج آن‌ها مجدداً به شکل گرافیکی و داده ای درآمده و توسط کاربر بازبینی می‌شود و علت این بازبینی، تصمیم گیری نهایی است. زیرا این سیستم عملاً یک سیستم تصمیم یار است، نه تصمیم‌گیرنده و عملاً تیم مدیریت یا تصمیم گیرنده را تصمیم‌گیری‌ها یاری می‌کند. اما تصمیم گیرنده نهایی مدیران و مسئولین ارشد بخش‌ها و یا سازمان هستند. سپس نتایج مجدداً به سیستم باز می‌گردد و در بخش‌های فرایندهای اصلی و کنترلی اعمال می‌شوند و در نهایت برای استفاده‌های بعدی در پایگاه داده ذخیره می‌گردند.

شکل (3-22) معماری سازمان تولیدی و معماری سیستم پشتیبان تصمیم خصوصی

3-9 معماری DSS عمومی:
آنچه که تا کنون بیان شد معماری در هر بخش از سازمان بود. در سازمان‌های تجمیعی همان طور که بیان شد، ارتباطات مبتنی بر سرویس هم وجود دارد که به نوعی عملکرد کلیه سیستم‌ها را تجمیع و هماهنگ می‌کند. برای ایجاد چنین هماهنگی نیازمند یک پایگاه تصمیم گیری مرکزی هستیم. این پایگاه در وب سرور قرار دارد.

شکل (3-23) – Public web server DSS برای تجمیع و هماهنگ کردن عملکرد کلیه سیستم‌ها

عملکرد آن به این شکل است که در ابتدا اطلاعات و تصمیمات از هر DSS وارد یک regulation base که ارزیابی اولیه یا نرمال سازی نامیده شده است، می‌شود. این بخش به سیستم نرمال ساز معروف است و عملاً نقطه ورودی public DSS است. همچنین این پایگاه ارتباطی برای جلوگیری از نفوذ و تخریب و دست کاری کنترل نشده هم قرار داده شده است. از طرفی در این قسمت یک حافظه (cache) وجود دارد که در صورت استفاده قبلی از اطلاعات، در دسترس تر باشند؛ و با این کار سرعت ارائه سرویس و جستجو را بالا ببرند.
در صورت نیاز اطلاعات از سایر DSSها هم درخواست و وارد سیستم نرمال ساز می‌شود. این DSS در خود انباره‌ای از متدها، مدل‌ها و اطلاعات و قوانین پایه دارد و از طرفی جهت جلوگیری از ریسک از بین رفتن اطلاعات individual DSS ها، یک پشتیبان از آن‌ها در وب سرور موجود است که به آن انباره اصلی گفته می‌شود. این بخش، بخش مرکزی public DSS است؛ و هم اطلاعات وارد شده از DSSهای خصوصی، هم متدها و مدل‌ها و داده‌ها و قوانین مورد نیاز استخراج شده و هم تصمیمات اتخاذ شده، همگی به این بخش وارد می‌شوند. در نهایت نیز در همین قسمت نسخه پشتیبان تصمیم ذخیره می‌شود. این بخش حتی تصمیم‌های DSSهای خصوصی را نیز در خود ذخیره می‌کند و عملاً منبع داده و تصمیم کلی محسوب می‌شود.
همواره این پایگاه‌هاupdate می‌شوند و مدل‌ها و ماژول‌های سیستمی داده‌ها و تصمیمات از هر سیستم به آن‌ها وارد می‌گردند. بنابراین اطلاعات و مدل‌های مورد نیاز از این پایگاه‌ها وارد بخش بازیابی می‌شود.
پس از استخراج، داده‌ها و اطلاعات مورد نیاز از انباره عمومی و ورود به بخش بازیابی، ترکیب داد های جدید با داده‌های قبلی و بررسی و تحلیل‌ها انجام می‌شود. روش تصمیم‌گیری و تحلیل در ابتدا مشابه DSS

پایان نامه
Previous Entries منابع و ماخذ مقاله نیازمندی‌ها، منابع سازمان، سیستم پشتیبان تصمیم Next Entries منابع و ماخذ مقاله سرویس گرا، سطح تحصیلات، اعتبار سنجی