ی به مدیریت و ارزیابی کیفیت و نحوه کارکرد سیستم‌ها، برنامه‌ها و زیرساخت‌ها می‌پردازد. این معماری سازمان تولیدی مورد نظر است که در آن به برنامه‌ریزی منابع سازمان پرداخته شده است؛ و یا به بیان بهتر معماری داخلی individual ERP است.
بخش بعدی که در تعامل با هر individual ERP می‌باشد و عملکرد آن نیز در مطالب قبلی بیان شد، individual DSS است. معماری داخلی آن مطابق شکل (۳-۲۲) است. این سیستم پشتیبان تصمیم مختص هر ERP خاص است. خوراک اولیه آن از اطلاعات مربوط به آن سیستم (ERP آن سیستم یا زیر سیستم) است. همان طور که بیان شد در هر سیستم و یا زیرسیستم اطلاعات به شکل نرمال و استاندارد تبدیل می‌شوند تا امکان انتقال آن‌ها بین سیستم‌های مختلف و وب سرور به راحتی انجام شود. بنابراین اطلاعات اولیه وارد سیستم پشتیبان تصمیم می‌شود. این سیستم از یک پایگاه داده (شامل داده‌ها و قوانین اولیه)، و یک موتور استنتاج تشکیل شده است (عملکرد آن پیش‌تر بیان شد). برای دسترسی به این سیستم در ابتدا داده‌ها از سیستم ERP با فرمت مناسب وارد و ارزیابی می‌شوند تا اطلاعات مخرب یا نادرست نباشند. سپس داده‌ها با داده‌های قبلی و قوانین قبلی ترکیب و تبدیل به نمودارها و جدول‌ها می‌شوند. این بخش مسئول بازرسی و ارزیابی است. سپس اطلاعات به بخش تصمیم‌گیری و بهینه‌سازی می‌روند؛ و نتایج آن‌ها مجدداً به شکل گرافیکی و داده ای درآمده و توسط کاربر بازبینی می‌شود و علت این بازبینی، تصمیم گیری نهایی است. زیرا این سیستم عملاً یک سیستم تصمیم یار است، نه تصمیم‌گیرنده و عملاً تیم مدیریت یا تصمیم گیرنده را تصمیم‌گیری‌ها یاری می‌کند. اما تصمیم گیرنده نهایی مدیران و مسئولین ارشد بخش‌ها و یا سازمان هستند. سپس نتایج مجدداً به سیستم باز می‌گردد و در بخش‌های فرایندهای اصلی و کنترلی اعمال می‌شوند و در نهایت برای استفاده‌های بعدی در پایگاه داده ذخیره می‌گردند.

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

۳-۹ معماری 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 توزیع شده را پیاده‌سازی کنیم. این مکانیزم‌ها و ماژول‌ها در شکل (۳-۲۴) بیان شده‌اند.

شکل (۳-۲۴) – مکانیزم‌ها و ماژول‌های مورد نیاز برای پیاده سازی سیستم ERP توزیع شده

این مکانیزم‌ها و ماژول‌ها برای DSS ها و ERP ها قابل استفاده‌اند. این مکانیزم‌ها و مدل‌ها شامل، پایگاه ارتباطی و تبادلی۳۰، مکانیزم‌های کنترل و هماهنگی۳۱، نمایشگرها و تجهیزات نمایشی۳۲، بخش نرمال ساز۳۳، مکانیزم‌های نتیجه‌گیری و هوشمند۳۴ و پایگاه‌های مشترک می‌باشند.
همان طور که می‌دانیم، یک ERP تجمیعی در ابتدای کار، نیاز به یک زیر ساخت قوی از شبکه و تبادلات نرم‌افزاری و سخت‌افزاری دارد. زیرا در غیر این صورت ERP تجمیعی در یک سازمان گسترده معنی نخواهد داشت. با وجود چنین تبادلاتی، وجود مکانیزم‌های کنترل و نظارتی بر این همکاری‌ها و تبادلات، الزامی و غیر قابل انکار خواهد بود. از طرفی وجود ارتباطات، نیاز به یک زبان مشترک دارد. که اصولاً امروزه از زبان‌های مشترکی چون XML و سایر روش‌های مشترک همزمانی استفاده می‌کنند. همچنین تبدیلات دیگری نیز ممکن است نیاز باشد که در بخش نرمال ساز انجام می‌شود و ERP آن را در خود دارد تا بتواند در کل سازمان ارتباطات را ایجاد نماید. همچنین نرم افزارها، سخت‌افزارها و اطلاعات مشترک هم در این تبادلات ERP تجمیعی وجود دارد. به دلایل مختلف از جمله، کاهش هزینه خرید و صرفه‌جویی در زمان و انرژی و غیره می‌تواند باشد. جهت نظارت عمومی، نظارت مدیران، ناظران و کاربران، بخش‌های نمایشگر هم در این سیستم‌ها تعبیه شده می‌شود. بخش‌های هوشمند دیگری تحت عنوان مکانیزم‌های نتیجه‌گیری وجود دارد که به کمک بخش‌های دیگر آمده و با استفاده از هوش مصنوعی، نظارت، کنترل، هماهنگی و بهبود را ارائه می‌کند.

۳-۱۱ نحوه اجرا :
پس از بیان جزئیات و عملکرد چارچوب، مراحل پیاده سازی آن هم حائز اهمیت است که در ادامه بیان می‌شود.
مراحل پیاده‌سازی به ترتیب زیر خواهد بود:
* شناخت سازمان، فرموله کردن استراتژی‌ها، به این شکل که چشم‌اندازها و اهداف سازمان مشخص شده و استراتژی‌های فناوری برای متناسب بودن با آن‌ها در نظر گرفته می‌شوند.
* برنامه‌ریزی فرایندها (بهبود فرایندها و مهندسی مجدد آن‌ها) و طراحی سیستم، به این ترتیب که فرایندها با شکلی باز مهندسی شوند که اهداف تجاری را محقق سازند؛ و در عین حال معماری سرویس گرا را در زمینه خود داشته باشند.
* ارزیابی و توجیه سیستم، به این ترتیب که سیستم IT مورد نظر ارزیابی و تحلیل شود.
* پیکربندی سیستم، به این ترتیب که سیستم و فرایندهای سازمانی به شکلی پیکربندی شده باشند که بتوانند با هم همتراز باشند؛ و همچنین بر پایه معماری مورد نظر باشد .
* پیاده‌سازی سیستم، به این شکل که پیاده‌سازی واقعی مد نظر انجام شود. سرویس‌ها پیاده سازی شوند و تجمیع بین بخش‌ها انجام گیرد.
* بازبینی بعد از پیاده‌سازی، به این شکل که بررسی و ارزیابی شود که مجموعه اهداف مدنظر برای سیستم، دست‌یابی شده‌اند یا خیر.

فصل چهارم
ارزیابی

۴-۱ مقدمه:
آنچه که در بخش‌های گذشته بیان شد، شرح اجمالی از چارچوب پیشنهادی جهت ایجاد حاکمیت معماری سرویس گرا برای برنامه ریزی منابع در سازمان بود، به شکلی که به بهترین نحو بتواند پاسخگوی نیاز های سازمان‌های گسترده و تجمیعی تولیدی باشد و در عین حال بتواند ویژگی‌های مورد نیاز، از جمله، چابک بودن، مدیریت دانش، هوش تجاری و تحلیل داده‌ها، بهبود تصمیم گیری‌ها و غیره را نیز تأمین کند.

۴-۲ مقایسه چارچوب با چارچوب‌های دیگر(bench marking):
چارچوب‌های متفاوتی توسط شرکت‌های ارائه کننده محصولات ERP ارائه شده است. از جمله شرکت‌های مشهور و صاحب نام در این زمینه می‌توان به SAP , Oracle , IBM , Software AG , WebMethod , نام برد. در ادامه برای بررسی چارچوب پیشنهادی به مقایسه آن با چارچوب‌های پیشنهادی توسط سایر شرکت‌ها می‌پردازیم .

۴-۲-۱ بیان پارامتر های مقایسه:
در ابتدا جهت مقایسه یک سری طبقات موضوعی را مطرح می‌کنیم و سپس بر اساس آن طبقات عناوین مطرح در شرکت‌های مختلف را بیان و با هم مقایسه می‌نماییم.
طبقات موضوعی مطرح شامل، چرخه حیات، فرایند / سیاست، فرایند، فرایند / سیاست / اشخاص۳۵ / تکنولوژی۳۶ , اشخاص / فرایند و تکنولوژی می‌باشند.
عناوینی که در این طبقات موضوعی قابل بررسی هستند شامل:
مدیریت چرخه حیات حاکمیت : یک چارچوب با حاکمیت SOA باید سیاست‌های حاکمیتی را در کلیه مراحل توسعه سیستم، از تعاریف اولیه تا عملیاتی شدن را در خود جای دهد.
مدیریت چرخه حیات سرویس : یک چارچوب با حاکمیت SOA همواره در تمامی گام‌های توسعه سیستم از تعریف تا پیاده سازی، حاکمیت سرویس و تفکر سرویس گرایی را در نظر می‌گیرد.
فرایند های مدیریت و اعتبار سنجی : همواره در یک چارچوب سرویس گرا، وجود تحلیل گر داده‌ها و فرایندها و همچنین کنترل و اعتبار سنجی آن‌ها و کنترل استاندارد های لازم برای سازمان از جمله کارایی، امنیت، قابلیت اطمینان، دسترس پذیری و غیره … که به طور کلی مدیریت و اعتبار سنجی نامیده می‌شود، جز الزامات است.

مدیریت کسب و کار : مدیریت کسب و کار در یک چارچوب سرویس گرا، به بررسی و تعی
ین پوشش نیازمندی‌های کسب و کار و اولویت بندی و تصمیم گیری‌های حوزه کسب و کار می‌پردازد.

معیارها و سنجه های ارزیابی : معیارها و شاخص‌های کلیدی کارایی از الزامات اصلی هر چارچوب به شمار می‌رود. سازمان‌ها در فرایند پیاده سازی پروژه های برنامه ریزی منابع سازمان، به ارزیابی میزان پیشرفت نیاز دارند تا بدانند در چه وضعیتی هستند و چه فرایندها و سیاست‌ها و روال‌هایی برای بهبود نیاز است. این معیار های باید مبتنی بر اهداف باشند.

ساختار حاکمیت : استقرار حاکمیت SOA در سازمان‌ها تغییراتی را در ساختار سازمانی به وجود می‌آورد و فرایندها و روال‌های جدیدی در سازمان تعریف می‌شوند که مسئولیت‌ها و نقش‌ها بایستی برای هر یک از فرایندها و مدیران واحد های مختلف سازمانی مشخص و تبیین شوند. همچنین بخش‌های بازبینی و نظارت نیز به آن‌ها افزوده می‌شود.

مدیریت ثانویه : مدیریت ثانویه شامل کلیه ابزارها، توافقات و کلیه دارایی‌های مربوط به معماری سرویس گرا است. مدیریت زیرساخت، مدیریت سیاست، مدیریت سرویس‌ها و انباره ما و غیره مثال‌هایی از این مدیریت می‌باشند.

بلوغ سازمانی : همواره چارچوب باید مبتنی بر بلوغ سازمان باشد. تحمیل یک چارچوب بهینه به سازمان لزوماً بهترین پیشنهاد نیست. چرا که صرفاً یک نظام غیر ضروری و سست را در سازمان ایجاد می‌کند و می‌تواند منجر به شکست شود. چارچوب همواره باید بلوغ سازمان و سطح سازمان را مد نظر بگیرد.

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

بهترین تجارب: ارائه مدل‌ها و چارچوب‌ها با تکیه بر بهترین تجارب بدست آمده در حوزه مشابه، اعتبار اجرایی و عملی چارچوب را افزایش می‌دهد. همواره چارچوب‌هایی که بر اساس بهترین تجارب بوده‌اند، بیشتر مورد استقبال و توجه بوده‌اند.

۴-۲-۲ مقایسه قابلیت‌های چارچوب‌ها
. جدول زیر مقایسه بین چارچوب‌های پیشنهادی توسط شرکت‌های مطرح در این زمینه و چارچوب پیشنهادی در این پروژه را انجام می‌دهد.

جدول (۴-۱) مقایسه چارچوب‌های شرکت‌های مطرح با چارچوب پیشنهادی
طبقه موضوعی
عنوان
oracle
IBM
WebMethod
Software AG
چارچوب پیشنهادی
چرخه حیات
مدیریت چرخه حیات حاکمیت
??
?
??
?
?
فرایند/ سیاست
مدیریت چرخه حیات سرویس

?
?
?
?
فرایند
فرایند های مدیریت و اعتبار سنجی
?
??
??
??
?
فرایند

Written by 

دیدگاهتان را بنویسید