پایان نامه با واژگان کلیدی سیستم اطلاعاتی، ارتباط با مشتری، مدیریت هزینه

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

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

شکل 3 –5. فلوچارت روند جریان اطلاعات درخواست قطعه از انبار

Receive beginning message;
While (true)
{
SELECT Production_Line;
WHETHER line_feeding system?
OBSERVATION smithereens moment_inventory;
Calculation The number of required_ smithereensforline_feedingaccording to Define formul;
REPRESENTATION required_ smithereens;
SEND requesttorepository by Production_Lineoperator;
//first block;
OBSERVATION request by Inventory;
CONFIRMATIONandPrint request by Inventory;
DISASSEMBLY;
DELIVER smithereens to responsible forproduction_Line;
READ barcode on the package and smithereens by barcode reader;
REGISTRATION Information;
//second block;
WHETHER required_ smithereenshas changed?
SEND changes insend_requests by production_Line operator;
EDIT or add request;
{
شبه کد روند جریان اطلاعات درخواست مواد از انبار (مواد اولیه)

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

شکل 3-6. فلوچارت روند جریان اطلاعات اجرای محصول درخواستی

Receive beginning message;
While (true)
{
PRIORITIZATION saved _ order and SELECT for implementation by sale_department;
SEND selective _ order information to repository by sale_department;
IF requsest_product are available in repository?
//first block;
IF the customer has to cancel the requsest_product;
DELETE order_information by sale_department;
IF customer demanding product_change?
REGISTRATION and edit ordering_information and existing_product services;
FINAL approval by customer;
SEND ordering_information to financial_department by repository;
PAYMENT order by financial_department;
SEND ordering_information to repository by financial_department;
PREPARATION requsest_productand send tosale_departmentfor decalartion to customer by repository;
IF another orders are available;
DELIVER sale_invoice to repository;
//second block;
DELARATION non-existent to sale_department by repository;
}
شبه کد روند جریان اطلاعات اجرای محصول درخواستی

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

شکل 3 – 7. فلوچارت روند جریان اطلاعات پرداخت مشتری

Receive beginning message;
While (true)
{
SEND ordering_information tofinancial_department;
DOES the customerhaveextenuating circumstances?
CALCULATE thecost ofis executedcustomerorders.
SENDinvoiceto customer.
PAYCost by the customer.
WHETHERthe customerhas paidthe billperfect?
CONTACTCustomer and Tracking.
PAYMENT of cost by customer.
{

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

شکل 3 – 8 . فلوچارت روند جریان اطلاعات تحویل محصول به مشتری

Receive beginning message;
While (true)
{

DO Required Administrative_Actions for deliver Implemented_order to customer;
DELIVER product to customer by sale_department;
WHETHER deliver Received_order is Successful?
//first block;
DECLARATIONto relevant_part for Follow up;
//second block;
RECEIVED product by customer;
}
شبه کد روند جریان اطلاعات تحویل سفارش به مشتری

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

شکل 3 – 9. فلوچارت روند جریان اطلاعات پشتیبانی مشتری

Receive beginning message;
While (true)
{
GET feedback Of customer;
WHETHERCustomerfeedback_messageIn line with receive_order is Complaint;
SEND relevant_information to support_department for fix the problem;
ANNOUNCE Follow-up to customer;
WHETHER the problem was resolved;
COMMUNICATION with customer;
FOLLOW UP fix the problem by support_department;
}
شبه کد روند جریان اطلاعات پشتیبانی مشتری

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

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