DSS منفرد
ERP منفرد
DSS منفرد
ERP منفرد
DSS منفرد
عمومی DSS
مکانیزمها و مدلهای مورد نیاز جهت همکاری
شکل (۳-۲۱) – چارچوب CoERP – چارچوب سرویس گرا از collaborative ERP
چارچوب CoERP در شکل (۳-۲۱) , یک چارچوب سرویس گرا از collaborative ERP است که در آن DSS برای بهبود دانش سازمانی و کارایی بیشتر به شکل کاملاً توزیع شده و سرویس گرا با ERP تجمیع شده است. برای نیل به این هدف، در ابتدا در هر بخش از سازمان توزیع شده، نیاز به ERP و DSS به شکل مجزا است (شکل تعامل DSS و ERP) . دلیل اصلی آن، بهره گیری از تمرکز روی اطلاعات و کارایی بیشتر است. زیرا عملکرد هر بخش با بخش دیگر متفاوت است و تصمیمات مدیریتی و اجرایی در هر بخش ممکن است نتایج متفاوتی را از بخش دیگر ایجاد کند. از طرفی به این شکل تصمیمات تخصصیتر و کارا تر خواهد بود زیرا با تمرکز بیشتر و با آشنایی بیشتری با بخشهای مختلف انجام خواهد شد.
اما در سطح کلانتر نیاز به یک نگاه از بالا به پایین داریم. تا هماهنگی بین بخشها و تصمیمات کلیتر و حیاتیتر را برای سازمان تأمین کند. منابع و دانش و اطلاعات در سطح کلان با ترکیب کردن و توجه به تک تک بخشهای خرد (زیر سیستمها) انجام میشود. بنابراین، در هر زیر بخش ERP ،DSS مختص آن بخش را خواهیم داشت و در کل سازمان نیاز به یک DSS عمومی است، که عملاً نقش ترکیب کننده و نرمال کننده کلیه اطلاعات و تصمیمات سازمانی را بر عهده دارد. برای فراهم سازی چنین بستری نیاز به مکانیزمها و ماژولهای خاصی است که این همکاریها را ممکن و عملی سازد. این بسترها و زیر ساختها از طریق ابزارها، مدلها و تکنولوژیها تأمین میشوند.
۳-۷ ساختار ERP در زنجیره تأمین :
SCM
CRM
Enterprise
ERP DSS
تصمیم گیری
تصمیم گیری
تصمیم گیری
ERP DSS
ERP DSS
زیر ساخت فناوری و تکنولوژی
زیر ساخت فناوری و تکنولوژی
تجمیع
زیر ساخت فناوری و تکنولوژی
شکل (۳-۲۲) چارچوب DE (DSS-ERP ) بستر مناسب جهت تجمیع ERP و DSS در سیستم توزیع شده
برای تجمیع DSS و ERP، یک چارچوب DE (DSS-ERP) تخصیص داده شده است. همان طور که در شکل (۳-۲۲) میبینیم این چارچوب بستر مناسب را جهت تجمیع ERP و DSS در سیستم توزیع شده، فراهم میکند. این چارچوب بر روی زنجیره تأمین (supply chain) ایجاد شده است اما در کنار آن بستر سیستم و تکنولوژی را به آن افزوده است. در مرکز، یک سیستم مرکزی است که تجمیع کننده و واسط بین کلیه برنامهها، ERP ها,DSS ها و تکنولوژیها است. هر بخش میتواند در هر زمان با سازمان مرکزی (هسته سیستم مرکزی، که در اینجا قسمت integration از enterprise است)، ارتباط و همچنین با سایر بخشهای مربوط به تأمین یا مشتری، همکاری و تعامل داشته باشد. در هر زیر بخش تصمیم گیرندگان به سیستم مرکزی دسترسی دارند تا بتوانند تصمیمات را دستکاری و یا تصمیمات جدید اتخاذ کنند. تصمیم گیرندگان با بهره گرفتن از محیط داخل سازمان و یا از طریق زنجیره تأمین، میتوانند به دادهها از طریق ارتباطات دسترسی پیدا کنند و با بهره گرفتن از زیر ساختهای IT از تکنولوژیهای ارتباطی در جهت ایجاد و بهبود تصمیمات خود استفاده کنند.
در گام بعدی نیاز به بیان اجزا، پیش نیازها و ورودی و خروجیهای هر کدام از DSS ها و ERP ها در درون چارچوب CoERP ، برای یک سازمان تولیدی میباشد.
در یک سازمان تولیدی، پیش نیاز اولیه، ایجاد یک کانال تبادل اطلاعاتی بین سیستم برنامه ریزی و بخش تولید و ایجاد یک سیستم تجمیعی real-time برای تولید است و از بین بردن گپهای اطلاعاتی یک نکته کلیدی در دست یابی به این اهداف و ایجاد یک محیط عملیاتی و تولید چابک است. بنابراین باید به دنبال ساده سازی و حذف لایه های مختلف نرم افزاری و حذف لایه های نرم افزاری غیر ضروری و در نظر گرفتن استاندارد های سیستمی در کسب و کار بود. ۳ عنصر مهم در استراتژی این معماری موارد زیر میباشند.
۱٫ سرمایه گذاری روی تکنولوژی ساخت برنامه های کاربردی
۲٫ تجمیع و همکاری بهینه برنامه های کاربردی
۳٫ وب سرویس و شبکه جهت پیاده سازی پروژهها و برنامه های کاربردی تولید
۳-۸ معماری داخلی ERP بخشهای سازمانی
معماری سازمان تولیدی در شکل (۳-۲۲) نشان داده شده است. برای نیل به استراتژیهای مذکور XML ,OPC یک راه بسیار ساده جهت ایجاد تبادل اطلاعات استاندارد است. OPC، یک فرمت ساده از بیان فرایندی بوده و به تبادل اطلاعات بین برنامهها، سخت افزارها و فرایندها تمرکز دارد و XML، یک فرمت داده استاندارد بوده و به نگه داری و تبادل اطلاعات بین برنامهها تمرکز دارد. بنابراین کاربران به راحتی میتوانند تبادلات مختلف را انجام دهند. به همین جهت یک لایه میانی که شامل XML , OPC و سایر مدلها و زیرساختهای میانجی و بینابینی است، وجود دارد. این چارچوب از یک بخش فرایندی اصلی و از یک بخش پشتیبانی و مدیریتی تشکیل شده است. از دلایل اصلی استفاده از این فرمتهای استاندارد پیادهسازی سرویسهاست که برای دست یابی به اطلاعات و تصمیمات real time نیازمند این تبدیلات میباشیم.
قسمت فرایندی، شامل فرایندهای عام تولیدی است، که شامل، انبار مواد اولیه، فرایند تولید، فرایندهای کنترل کیفی و لجستیک که اصولاً به صورت همگام و یا مرتبط با تولید انجام میشوند و فرایند انبار محصول نهایی است. اطلاعات این فرایندها در مدیریت اطلاعات فرایندها استخراج و در قسمت لایه میانی به شکل نرمال و استاندارد تبدیل میشود تا در بخشهای دیگر مورد استفاده قرار گیرد.
بخشهای کنترلی و پشتیبانی که در قسمت بالای این معماری قرار دارند، شامل: مدیریت انبار، برنامهریزی، مدیریت و برنامه ریزی تولید، بهینه سازی فرایند، مدیریت مواد و برنامه ریزی منابع انسانی است. این فرایندهای کنترل و پشتیبانی به صورت کاملاً همکار با هم و با فرایندهای اصلی کار میکنند. برای مثال مدیریت انبار با توجه به برنامه ریزی تولید، به میزان مورد نیاز از مواد اولیه پی میبرد و با توجه به فضای در دسترس انبار به مدیریت آن میپردازد و اطلاعات و تصمیمات آن به مدیریت مواد میرود. مدیرت انبار، به برنامه ریزی و کنترل موجودی انبار میپردازد. اطلاعات مربوط به این بخش از اطلاعات مهمی است که کلیه فرایندهای تولید را تحت تاثیر قرار میدهد.
برنامه ریزی، به کلیه فرایندهای برنامهریزی در زمینه مواد اولیه، میزان تولید، کیفیت مورد نیاز، نحوه انجام فرایندها و سایر برنامهریزیها میپردازد و یک پایگاه هماهنگی بین سایر فرایندهای کنترلی است. برنامهریزی تولید، به برنامهریزی در زمینه میزان تولید، نحوه تولید و کیفیت تولید نیز میپردازد. بهینهسازی فرایند، به برنامهریزی و توسعه و بهبود فرایندها در جهت بهبود و دستیابی به یک فرایند بهینه و ناب میپردازد. این بهبود شامل: کاهش زمان تولید، کاهش هزینه تولید، چابک سازی فرایند و غیره میباشد. مدیریت مواد، , به مدیریت مواد اولیه مورد نیاز با توجه به مدیریت و برنامهریزی انبار و برنامهریزی تولید میپردازد. نهایتاً برنامهریزی منابع انسانی که مربوط به تخصیص فرایندها به افراد و واحدهای کاری است. همواره این معماری به دنبال فرایند گرایی و اصالت فرایند است. به همین دلیل از افراد به شکل پویا و با توجه به کارکرد و روند فرایند استفاده میکند.
در این معماری دو بخش سیستمی دیگر وجود دارد. که اطلاعات مربوط به بخش فرایندهای تولیدی را دریافت و آن ها را بررسی و ارزیابی میکند. بخش مدیریت کیفیت، شاخصهای مورد نیاز خود را از لایه میانی و با فرمت استاندارد دریافت میکند و بررسیها را انجام میدهد. نهایتاً این پارامترهای ارزیابی در تصمیمات و برنامه ریزیهای بخش کنترلی موثر خواهد بود. بخش مدیریت مهندسی به مدیریت و ارزیابی کیفیت و نحوه کارکرد سیستمها، برنامهها و زیرساختها میپردازد. این معماری سازمان تولیدی مورد نظر است که در آن به برنامهریزی منابع سازمان پرداخته شده است؛ و یا به بیان بهتر معماری داخلی individual ERP است.
بخش بعدی که در تعامل با هر individual ERP میباشد و عملکرد آن نیز در مطالب قبلی بیان شد، individual DSS است. معماری داخلی آن مطابق شکل (۳-۲۲) است. این سیستم پشتیبان تصمیم مختص هر ERP خاص است. خوراک اولیه آن از اطلاعات مربوط به آن سیستم (ERP آن سیستم یا زیر سیستم) است. همان طور که بیان شد در هر سیستم و یا زیرسیستم اطلاعات به شکل نرمال و استاندارد تبدیل میشوند تا امکان انتقال آن ها بین سیستمهای مختلف و وب سرور به راحتی انجام شود. بنابراین اطلاعات اولیه وارد سیستم پشتیبان تصمیم میشود. این سیستم از یک پایگاه داده (شامل دادهها و قوانین اولیه)، و یک موتور استنتاج تشکیل شده است (عملکرد آن پیشتر بیان شد). برای دسترسی به این سیستم در ابتدا دادهها از سیستم ERP با فرمت مناسب وارد و ارزیابی میشوند تا اطلاعات مخرب یا نادرست نباشند. سپس دادهها با دادههای قبلی و قوانین قبلی ترکیب و تبدیل به نمودارها و جدولها میشوند. این بخش مسئول بازرسی و ارزیابی است. سپس اطلاعات به بخش تصمیمگیری و بهینهسازی میروند؛ و نتایج آن ها مجدداً به شکل گرافیکی و داده ای درآمده و توسط کاربر بازبینی میشود و علت این بازبینی، تصمیم گیری نهایی است. زیرا این سیستم عملاً یک سیستم تصمیم یار است، نه تصمیمگیرنده و عملاً تیم مدیریت یا تصمیم گیرنده را تصمیمگیریها یاری میکند. اما تصمیم گیرنده نهایی مدیران و مسئولین ارشد بخشها و یا سازمان هستند. سپس نتایج مجدداً به سیستم باز میگردد و در بخشهای فرایندهای اصلی و کنترلی اعمال میشوند و در نهایت برای استفادههای بعدی در پایگاه داده ذخیره میگردند.
Original MES architecture
Individual DSS
Individual ERP
شکل (۳-۲۲) معماری سازمان تولیدی و معماری سیستم پشتیبان تصمیم خصوصی
۳-۹ معماری DSS عمومی:
آنچه که تا کنون بیان شد معماری در هر بخش از سازمان بود. در سازمانهای تجمیعی همان طور که بیان شد، ارتباطات مبتنی بر سرویس هم وجود دارد که به نوعی عملکرد کلیه سیستمها را تجمیع و هماهنگ میکند. برای ایجاد چنین هماهنگی نیازمند یک پایگاه تصمیم گیری مرکزی هستیم. این پایگاه در وب سرور قرار دارد.
Public web server DSS
شکل (۳-۲۳) – Public web server DSS برای تجمیع و هماهنگ کردن عملکرد کلیه سیستمها
عملکرد آن به این شکل است که در ابتدا اطلاعات و تصمیمات از هر DSS وارد یک regulation base که ارزیابی اولیه یا نرمال سازی نامیده شده است، میشود. این بخش به سیستم نرمال ساز معروف است و عملاً نقطه ورودی public DSS است. همچنین این پایگاه ارتباطی برای جلوگیری از نفوذ و تخریب و دست کاری کنترل نشده هم قرار داده شده است. از طرفی در این قسمت یک حافظه (cache) وجود دارد که در صورت استفاده قبلی از اطلاعات، در دسترس تر باشند؛ و با این کار سرعت ارائه سرویس و جستجو را بالا ببرند.
در صورت نیاز اطلاعات از سایر DSSها هم درخواست و وارد سیستم نرمال ساز میشود. این DSS در خود انبارهای از متدها، مدلها و اطلاعات و قوانین پایه دارد و از طرفی جهت جلوگیری از ریسک از بین رفتن اطلاعات individual DSS ها، یک پشتیبان از آن ها در وب سرور موجود است که به آن انباره اصلی گفته میشود. این بخش، بخش مرکزی public DSS است؛ و هم اطلاعات وارد شده از DSSهای خصوصی، هم متدها و مدلها و دادهها و قوانین مورد نیاز استخراج شده و هم تصمیمات اتخاذ شده، همگی به این بخش وارد میشوند. در نهایت نیز در همین قسمت نسخه پشتیبان تصمیم ذخیره میشود. این بخش حتی تصمیمهای DSSهای خصوصی را نیز در خود ذخیره میکند و عملاً منبع داده و تصمیم کلی محسوب میشود.
همواره این پایگاههاupdate میشوند و مدلها و ماژولهای سیستمی دادهها و تصمیمات از هر سیستم به آن ها وارد میگردند. بنابراین اطلاعات و مدلهای مورد نیاز از این پایگاهها وارد بخش بازیابی میشود.
پس از استخراج، دادهها و اطلاعات مورد نیاز از انباره عمومی و ورود به بخش بازیابی، ترکیب داد های جدید با دادههای قبلی و بررسی و تحلیلها انجام میشود. روش تصمیمگیری و تحلیل در ابتدا مشابه DSS خصوصی است. اما این DSS علاوه بر آن روش، متدها و ماژولهای دیگری نیز دارد که مختص این DSS است و در صورت نیاز انتخاب و تحلیل و تصمیمگیری انجام میگیرد. لازم به ذکر است که تصمیمگیری مشابه DSS خصوصی و با نظارت مدیریت و یا کاربران یا ناظران انجام میگیرد. به همین دلیل بخشی تحت عنوان مدیریت کاربر اختصاص داده شده است که پس از تحلیلهای اولیه و ذخیره اولیه در انباره عمومی، با بهره گرفتن از واسط کاربر به نمایشگر کنترل برود؛ و با این کار، نظارت و تصمیم گیری انجام شود. این کار فقط مختص مدیران و تصمیم گیرندگان سازمان است. پس از تصمیمگیری نهایی، اطلاعات اصلی مجدداً به بخش بازیابی رفته و به فرمت عمومی در آمده و در انباره اصلی که یک حافظه دائمی است ذخیره میگردد؛ و سپس میتواند به DSS مربوطه ارسال گردد.
علاوه بر اینها یک نمایشگر عمومی نیز فعال است تا بعد از تصمیم نهایی، کاربران مجاز به تصمیمات موجود در انباره اصلی دسترسی داشته باشند؛ و با بهره گرفتن از کاتالوگ آن میتوانند اطلاعات مورد نیاز را از انباره استخراج کنند.
۳-۱۰ بستر ارتباطی :
برای ایجاد بستر مناسب ارتباطی، نیاز به مکانیزمها و ماژولهایی است که بتوان با بهره گرفتن از بستر شبکه و بهکارگیری این مکانیزمها و ماژولها سیستم ERP توزیع شده را پیادهسازی کنیم. این مکانیزمها و ماژولها در شکل (۳-۲۴) بیان شدهاند.
مکانیزمها و مدلهای تعامل
Communication base
Reasoning machine
Coordination and control mechanism
Interface and display
Regulation base
Mutual base
شکل (۳-۲۴) – مکانیزمها و ماژولهای مورد نیاز برای پیاده سازی سیستم ERP توزیع شده
این مکانیزمها و ماژولها برای DSS ها و ERP ها قابل استفادهاند. این مکانیزمها و مدلها شامل، پایگاه ارتباطی و تبادلی[۳۰]، مکانیزمهای کنترل و هماهنگی[۳۱]، نمایشگرها و تجهیزات نمایشی[۳۲]، بخش نرمال ساز[۳۳]، مکانیزمهای نتیجهگیری و هوشمند[۳۴] و پایگاههای مشترک میباشند.
همان طور که میدانیم، یک ERP تجمیعی در ابتدای کار، نیاز به یک زیر ساخت قوی از شبکه و تبادلات نرمافزاری و سختافزاری دارد. زیرا در غیر این صورت ERP تجمیعی در یک سازمان گسترده معنی نخواهد داشت. با وجود چنین تبادلاتی، وجود مکانیزمهای کنترل و نظارتی بر این همکاریها و تبادلات، الزامی و غیر قابل انکار خواهد بود. از طرفی وجود ارتباطات، نیاز به یک زبان مشترک دارد. که اصولاً امروزه از زبانهای مشترکی چون XML و سایر روشهای مشترک همزمانی استفاده میکنند. همچنین تبدیلات دیگری نیز ممکن است نیاز باشد که در بخش نرمال ساز انجام میشود و ERP آن را در خود دارد تا بتواند در کل سازمان ارتباطات را ایجاد نماید. همچنین نرم افزارها، سختافزارها و اطلاعات مشترک هم در این تبادلات ERP تجمیعی وجود دارد. به دلایل مختلف از جمله، کاهش هزینه خرید و صرفهجویی در زمان و انرژی و غیره میتواند باشد. جهت نظارت عمومی، نظارت مدیران، ناظران و کاربران، بخشهای نمایشگر هم در این سیستمها تعبیه شده میشود. بخشهای هوشمند دیگری تحت عنوان مکانیزمهای نتیجهگیری وجود دارد که به کمک بخشهای دیگر آمده و با بهره گرفتن از هوش مصنوعی، نظارت، کنترل، هماهنگی و بهبود را ارائه میکند.
۳-۱۱ نحوه اجرا :
پس از بیان جزئیات و عملکرد چارچوب، مراحل پیاده سازی آن هم حائز اهمیت است که در ادامه بیان میشود.
مراحل پیادهسازی به ترتیب زیر خواهد بود:
جهت