منبع مقاله با موضوع سیستم اطلاعاتی، سرویس گرا، سیستم های اطلاعات

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

تدارکات بر موجودی انبار (مواد اولیه)، شکل 3 – 12 نمودار کاربری درخواست قطعه از انبار، شکل 3-13 نمودار مورد کاربری اجرای محصول درخواستی مشتری، شکل 3- 14نمودار مورد کاربری پرداخت مشتریان، شکل 3-15 نمودار مورد کاربری تحویل سفارشات به مشتری، شکل 3 – 16 نمودار کاربری پشتیبانی مشتریان در راستای سفارشی دریافتی، نمایش داده شده است.

همانطور که در شکل 3-10 نیز مشخص است، به منظور مدیریت ورود کاربر، سیستم بایستی قادر به احراز هویت آن ها باشد. بدین صورت که چنانچه اطلاعات کاربر، قبلا در سیستم مورد نظر وجود داشته باشد، باید امکان وارد کردن نام کاربری و رمز عبور توسط کاربر فراهم شود، تا سیستم قادر به بررسی صحت/ عدم صحت اطلاعات وارد شده باشد. چنانچه کاربر در زمان وارد کردن نام کاربری و رمز عبور، رمز خود را فراموش کرده باشد، در سیستم فوق امکاناتی برای یادآوری آن به کاربر، ایجاد شده است (سرویس رفع مشکل فراموش کردن رمز عبور).در صورتی که اطلاعات کاربر قبلا در سیستم مورد نظر وجود نداشته باشد، سرویسی عملیات ثبت و ذخیره سازی این عملیات را فراهم می سازد. سرویس احراز هویت کاربر به همراه سرویس دانه ریز آن، در شکل نمایش داده شده است.

شکل 3-10 .نمودار use case احراز هویت و مدیریت ورود کاربران به سیستم اطلاعاتی

همانطور که در شکل 3-11 مشاهده می شود، سیستم توسط سرویسی بررسی می کند که آیا اجناس مورد نیاز واحد تولید در انبار مواد اولیه وجود دارد یا نه. در صورت عدم وجود محصول موردنیاز به واحد تدارکات اطلاع می دهد. واحد تدارکات کالای موردنیاز را خریداری کرده و پس از کنترل توسط واحد کنترل کیفیت به انبار تحویل داده شده و قبض صادر می گردد.(سرویس خرید مواد اولیه مورد نیاز)

شکل 3 – 11. نمودار use case نظارت واحد تدارکات بر موجودی انبار

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

شکل 3-12 نمودار use case درخواست قطعات مورد نیاز واحد تولید از انبار(مواد اولیه)

پس از انتخاب سفارش آماده به اجرا، به منظور بررسی وضعیت موجودی/ عدم وجودی محصول درخواستی، اطلاعات به بخش انبار فرستاده می شوند. (به عبارتی عاملی مسئول بررسی وضعیت موجودی انبار به واسطه ی سیستم می باشد). چنانچه مشتری در هر مرحله از سفارش خواستار کنسل کردن سفارش درخواستی باشد، سرویسی عملیات حذف اطلاعات مربوطه را انجام می دهد. همچنین، در صورتی که مشتری خواستار هرگونه تغییراتی در سفارش مورد نظرش باشد، اطلاعات ویرایش شده جهت اعمال تغییرات به بخش انبار ارسال می شود. در غیر این صورت، این سرویس وضعیت را به حالت سفارش اجرا شده، ثبت می کند.

شکل 3-13. نمودار use case اجرای محصول درخواستی مشتری

به منظور پرداخت سفارش اجرا شده مطابق شکل 3-14 ابتدا به واسطه ی سرویسی عملیات صدور صورتحساب انجام می شود. بدین صورت که چنانچه مشتری مشمول تخفیف باشد، در محاسبه ی صورتحساب به اندازه ی میزان تخفیف از کل هزینه کسر می گردد. پس از صدور صورتحساب و ارسال آن برای مشتری، مشتری بایستی اقدام به پرداخت هزینه کند. بدین منظور سرویسی مسئولیت پرداخت آنلاین هزینه ها را بر عهده دارد. تا در صورتی سفارش به مشتری تحویل داده می شود که پرداخت صورتحساب به صورت کامل انجام گرفته باشد. از این رو پس از ثبت میزان هزینه پرداختی توسط مشتری، عاملی مسئول کنترل وضعیت پرداختی مشتریان می باشد به نحوی که در صورت پرداخت کامل صورتحساب، وضعیت پرداخت به حالت وضعیت کامل بروز رسانی شده و در غیر این صورت ضمن ثبت وضعیت ناکامل به منظور پرداخت میزان هزینه ی باقی مانده، گزارشی از وضعیت پرداخت به بخش فروش ارسال می شود تا پرداخت میزان هزینه باقی مانده را پیگیری کند. با این تفاسیر می توان گفت که مدیریت اجرای میزان هزینه ی سفارشات پرداختی مستلزم اجرای 3 سرویس ریز دانه ی صدور صورتحساب، پرداخت آنلاین و بررسی وضعیت پرداخت صورتحساب می باشد.

شکل 3 – 14. نمودار use case مدیریت هزینه ی سفارشات اجرا شده

با توجه به شکل 3-15سفارش اجرا شده باید به مشتری تحویل داده شود، در صورتی که مشتری محصول خود را در زمان تعیین شده، دریافت نکرده باشد، با اعلام عدم دریافت، پیگیری های لازم توسط بخش فروش انجام می گیرد و با دریافت تائیدیه دریافت وضعیت دریافت محصول در data storeتحت عنوان سفارش تحویل داده شده به روز رسانی می شود.

شکل 3 – 15. نمودار use case تحویل محصول به مشتری

با توجه به نمودار کاربری 3 –16 مشتری به واسطه ی این سیستم، بایستی قادر به ثبت گزارشات بازخوردهایی از سفارشات دریافت شده باشد. در راستای این بازخوردهای ثبت شده، بخش پشتیبانی، به واسطه ی سرویسی، قادر به بررسی وضعیت رفع/ عدم رفع شکایت مشتری از سفارش دریافتی خواهد بود. که به منظور اجرای این سرویس بایستی عاملی، عملیات مربوط به بررسی وجود / عدم وجود شکایت مشتری از سفارش را انجام دهد.

شکل 3 – 16. نمودار use case پشتیبانی مشتری

3-7 الگوی راه حل پیشنهادی متدولوژی SOMAبرای استفاده در سیستم های اطلاعاتی
با توجه به این مسئله که بسیاری از سازمانهای بزرگ چندین سیستم اطلاعاتی را برای ارائه سیستم های مختلفی که از سازمان انتظار می رود نصب کرده اند، برخی از سرویس های قابل استخراج از سیستم اطلاعاتی به عنوان یکی از این سیستم ها نمایش دادیم. سرویس های این سیستم اطلاعاتی می توانند با ارسال یک پیام درخواست که معمولا مبتنی بر فایل XML می باشند، در دسترس قرار بگیرند. از آنجاییکه هریک از سرویس های سیستم و هر برنامه کاربردی دیگر، می توانند در هر جایی مستقر شده، و پروتکل ها و فرمت ها ی داده مختلفی را به کار ببرند، به منظور استفاده از سرویس های این سیستم، درخواست کننده های این سیستم اطلاعاتی در داخل و یا خارج از سازمان، در انتقال یا یکپارچه سازی نقطه به نقطه با مشکلاتی از جمله عدم دسترس پذیری و استفاده مجدد از یک سرویس در میان چندین مصرف کننده مواجه می شوند.
برای رفع این گونه مشکلات می توان، یکی از الگوهای راه حل پیشنهادیSOMA و معماری سرویس گرا، یعنی مولفه ی میان افزار باس سرویس سازمان12 را به کار برد. از دیدگاه مصرف کنندگان برنامه های کاربردی و سرویس ها، یک سرویس می تواند به سادگی، پیرامون یک ESB و با استفاده از انتقال پیام، درخواست شده و در دسترس قرار بگیرد. همچنینESB ، امکان انتقال فرمت های داده را، با تبدیل فرمت برنامه ی کاربردی درخواست کننده سرویس به یک استاندارد باز و تبدیل استاندارد باز به فرمت متعلق به برنامه کاربردی، و بالعکس را فراهم می کند.
به طور کلی ESBاقدامات زیر را انجام می دهد:
• امکان ایجاد اتصال سست بین سرویس ها را فراهم می کند.
• امکان این را فراهم می کند تا سرویس ها با یکدیگر براساس ملزومات QOS و طی تراکنش های خاص نظیر سنکرون، آسنکرون، دائمی و غیر دائمی، اتصال سست و اتصال ضعیف، ارتباط برقرار می کنند.
• به عنوان زیر ساختی متداول برای معماری سرویس گرا، رخدادها و پیغام های آن می باشد، به نحوی که پلت فرم های ناهمگون را به صورت شفاف به هم متصل می سازد.
• نقش میانجی را بین درخواست ها و پاسخ های سرویس گرا ایجاد می کند.
ESBهای opensourceازجمله Mule ، قابلیت همکاری و انعطاف پذیری بی نظیری را با مکان سازی استفاده مجدد مولفه های سرویس از هر نوع، و تبادل پیغام ها با هر فرمتی هم در داخل و هم بیرون از سازمان را فراهم کرده، و پلت فرمی را ارائه می دهد که یکپارچه سازی app ها و تکنولوژی ها را آسان می کند.
با به کارگیری این الگوی پیشنهادی SOMA، اطلاعات و قابلیت های سیستم اطلاعاتی (سرویس های قابل ارائه)، صرف نظر از پروتکل وفرمت های داده ی آن ها، به منظور پاسخگویی به نیازمندی های درحال تغییر، مجددا به یک روش جدید ایجاد شده، و مورد استفاده قرار می گیرند. برخی از سرویس های اصلی سیستم اطلاعاتی، به همراهESB که گذرگاهی برای حمل این سرویس ها می باشد، در شکل شماره 3-17 نشان داده اند.
همانطور که در شکل نیز مشخص است، یک سرویس دانه درشت ممکن است از یک یا چند سرویس دانه ریز تشکیل شده باشد. به عنوان مثال اجرای سرویس مدیریت هزینه ی سفارشات، که مستلزم اجرای سرویس های ریز دانه صدور صورتحساب، پرداخت آنلاین و بررسی وضعیت پرداخت هزینه ها می باشد.

شکل 3–17 سرویس های سیستم اطلاعاتی سرویس گرایspx

ESBمانند یک هابی مشترک عمل می کند که سیستم های اطلاعاتی ناهمگون (با پلتفرم های مختلف) در واحدهای مختلف کسب و کار و همچنین درخواست کنندگان در خارج از سازمان می توانند به آن متصل شوند تا با مشارکت با یکدیگر، نیازمندی های مشتریان را با سرعت بیشتری پاسخگو باشند. در واقع از این راه حل می توان، برای یکپارچه سازی انواع مختلفی از سرویس های سیستم اطلاعاتی، از طریق انتقال پیام، استفاده کرد. در حقیقت این زیر ساختار امکان این را فراهم می کند، تا سرویس هایی از برنامه های کاربردی درخواست شده، توسط دیگر برنامه های کاربردی، مستقل از پلت فرم های آن ها، مورد استفاده ی مجدد قرار بگیرند. در این صورت همانطور که در شکل 3 – 18 قابل مشاهده است، هر یک از سیستم های اطلاعاتی می توانند درخواست کننده و یا فراهم کننده سرویس باشند. درخواست کننده ی سرویس برای استفاده از سرویس هر یک از برنامه های کاربردی، به باس، که مسئول تحویل درخواست به فراهم کننده ی سرویس می باشد، متصل می شود.
ESBبه عنوان یک زیر ساختار برای بهم پیوستن سرویس ها، برای دستیابی به انعطاف پذیری بالاتر، درخواست ها را به صورت پیغام هایی می پذیرد، سپس روی آنها عملیات را انجام می دهد و از آنجایی که این پیام ها سرتاسر باس جریان پیدا می کنند، میان آن ها نقش میانجی را ایفا می کند. به طور کلی مسئولیت تحویل، درخواست های سرویس، و روت کردن (مسیریابی) آن ها به باس سرویس سازمان محول شده است.
به طور کلی راه حلESB، قابلیت همکاری بین سیستم های اطلاعاتی و مولفه های دیگر را از طریق آداپترهای مبتنی بر استاندارد و واسط ها فراهم کرده است. و از طرفی مسئول کنترل، جریان مناسب، و تفسیر کلیه ی پیغام ها در میان سرویس ها با به کارگیری تعدادی از پروتکل های سرویس گرایی می باشد. در این میان افزار ابعاد زیر ساختار مجازی باس، می تواند به اندازه ی بار کاری ای که پشتیبانی می کند، بزرگ و یا کوچک شود.

شکل 3-18.الگوی راه حل ESB برای استفاده از سرویس های سیستم اطلاعاتی در سازمان

3-8 برنامه ریزی استراتژیک سیستم اطلاعاتی
همانطور که می دانیم اطلاعات، یک منبع سازمانی است، و همچون هر منبع سازمانی دیگر، باید به طرز مناسبی، در سطح سازمان توزیع و به اشتراک گذاشته شود. این توزیع و به کارگیری مناسب اطلاعات، مستلزم یک برنامه استراتژیک است. فرایندی که در آن سازمان ها محیط های داخلی و خارجی خود را تحلیل کرده، و بر اساس آن استراتژی هایی را خلق می کنند که آن ها را در راستای رسیدن به اهداف تعیین شده (حرکت از وضع موجود به وضع مطلوب ) یاری می کند. به طور کلی منظور از استراتژی یک سازمان، تدوین برنامه ای در جهت هدایت عملیات سازمان، تعیین اهدافی که باید تحقق یابند، و بالاخره تعیین خط

پایان نامه
Previous Entries منبع مقاله با موضوع سیستم اطلاعاتی، ارتباط با مشتری، مدیریت هزینه Next Entries منبع مقاله با موضوع سیستم های اطلاعاتی، سیستم های اطلاعات، برنامه ریزی استراتژیک