معماری کاربردی ERP صنعتی استاندارد

معماری کاربردی ERP استاندارد

توسط admin | گروه مهندسی نرم افزار | 1405/05/14

نظرات 0

معماری کاربردی یک سیستم ERP برای عصر صنعت ۴.۰

منتشرشده در: Gesellschaft für Informatik (ویراستار)، مجموعه INFORMATIK 2021، Lecture Notes in Informatics (LNI)، بن، ۲۰۲۱

معماری کاربردی یک سیستم ERP برای عصر صنعت ۴.۰

معماری یک سیستم ERP جدید برای صنعت ۴.۰ بر پایه مفهوم «دوقلوی کنترلی دیجیتال»

ویلم‌یاقوب یوهانس هرلین (Wilmjakob Johannes Herlyn)

دانشگاه اتو فون گوریکه ماگدبورگ، مؤسسه سامانه‌های لجستیک و جابه‌جایی مواد، Universitätsplatz 2، 39106 Magdeburg — ایمیل: wilm.herlyn@ovgu.de — شناسه ORCID: 0000-0003-4522-5417

چکیده

در این مقاله، معماری یک سیستم برنامه‌ریزی منابع سازمانی آینده طراحی می‌شود که هسته آن بر مفهوم دوقلوی کنترلی دیجیتال استوار است. منظور از «معماری» در این مقاله، شیوه همکاری برنامه‌های کاربردی مختلف یک سیستم ERP با یکدیگر و با سامانه کنترل عملیات رایانه است. معماری به‌گونه‌ای طراحی شده است که تعداد زیادی از برنامه‌های ERP در یک سامانه واحد یکپارچه شوند. در وضعیت متداول امروز، برنامه‌های ERP به‌صورت ماژول‌های جداگانه‌ای مانند زمان‌بندی اصلی تولید و اجرای تولید، برنامه‌ریزی نیازمندی مواد، مدیریت انبار، کنترل حمل‌ونقل یا فراخوان‌های تولید به‌هنگام اجرا می‌شوند. این جدایی، به کاهش سازگاری و دقت داده‌ها و نیز ضعف در زمان پاسخ و هماهنگ‌سازی منجر می‌شود. سیستم‌های کلاسیک ERP بر مدل آبشاری متکی‌اند و نتایج یک ماژول به‌طور مستقیم به ماژول قبلی بازخورد داده نمی‌شود. چنین معماری‌ای دیگر با ظرفیت‌های صنعت ۴.۰ سازگار نیست؛ از جمله توان بهره‌برداری از حجم عظیم داده‌های دائماً در دسترس و واکنش فوری به اختلالات تولید، حمل‌ونقل، انبارش یا جابه‌جایی. معماری پیشنهادی نوعی رویکرد پژوهش علم طراحی است که بر دانش و تجربه به‌دست‌آمده در یکی از بزرگ‌ترین سازندگان اصلی خودرو، در واحدهای فناوری اطلاعات، خرید، تولید، لجستیک و فروش، تکیه دارد.

واژگان کلیدی

برنامه‌ریزی منابع سازمانی؛ دوقلوی کنترلی دیجیتال؛ تولید و جریان مواد؛ مرکز گرانش داده؛ شبکه داده؛ نقطه شمارش؛ محرک دیجیتال؛ سایه دیجیتال.

ساختار مقاله

  1. مقدمه
  2. مفهوم دوقلوی کنترلی دیجیتال؛ زیربنای سیستم ERP
  3. مخزن مشترک برای همه برنامه‌های عملیاتی و لجستیکی ERP
  4. جمع‌بندی و چشم‌انداز کوتاه
  5. منابع و کتاب‌شناسی

۱. مقدمه

نوآوری‌های صنعت ۴.۰ فرصت‌های تازه‌ای برای دگرگون‌کردن سیستم کلاسیک ERP و ماژول‌های کاربردی آن ایجاد می‌کنند. سیستم‌های ERP موجود قادر نیستند از حجم بالای داده‌هایی که به‌وسیله فناوری‌ها و ابزارهای جدیدی مانند RFID، کد QR و اشیای سایبرفیزیکی (CPO) گردآوری می‌شوند، به‌طور کامل استفاده کنند. سرعت بسیار بالای پردازش و انتقال داده، با شبکه‌های ۵G و در آینده ۶G، به نوعی معماری جدید برای خود سیستم ERP نیاز دارد.

رویکرد این مقاله بر مفهوم دوقلوی کنترلی دیجیتال (Digital Control Twin — DCT) مبتنی است. این مفهوم از ایده دوقلوی دیجیتال گریوز و ویکرز الهام گرفته است [Gr14]؛ با این تفاوت که صرفاً به معنای یک بازنمایی دیجیتال ساده از یک شیء یا فرایند فیزیکی نیست [Di17]. در اینجا، تعامل میان دوقلوی واقعی و دوقلوی مجازی مطرح است؛ به‌گونه‌ای که دوقلوی مجازی، دوقلوی واقعی را هدایت می‌کند. این موضوع یک تغییر پارادایم در انفورماتیک کسب‌وکار محسوب می‌شود. برای تحقق آن، به یک مخزن مشترک برای همه برنامه‌های ERP نیاز داریم؛ برنامه‌هایی که امروزه جدا از یکدیگر هستند و از طریق واسط‌ها و فرایندهای تبادل داده به هم متصل می‌شوند [LL07, He11, Ku13, Lh13, Sc16, KT18].

۲. مفهوم دوقلوی کنترلی دیجیتال؛ زیربنای سیستم ERP

بیشتر دوقلوهای دیجیتال موجود در لجستیک، بر جنبه‌های فنی کنترل تولید و جریان مواد تمرکز دارند [Di19]. مفهوم دوقلوی کنترلی دیجیتال، نه مهندسی‌محور، بلکه سفارش‌محور است و از داده‌های فرایندی اشیای فنی استفاده می‌کند [SAP]. با وجود این، هنوز در پژوهش و توسعه مفهوم‌های دوقلوی دیجیتال برای فرایندهای کسب‌وکار و به‌ویژه زنجیره‌های ارزش‌افزا کمبود جدی وجود دارد [Mi18, ZH20, ZH21, Pl20, Pl21].

۲.۱. معماری کاربردی دوقلوی کنترلی دیجیتال

معماری کاربردی دوقلوی کنترلی دیجیتال بر سه ستون اصلی استوار است: ۱) واقعیت، ۲) مخزن داده و ۳) تنظیم و کنترل. افزون بر این سه ستون، یک ستون چهارم با عنوان کنترل‌گر سامانه کاربردی (Application System Controller — ASC) برای کنترل همه برنامه‌های ERP لازم است (شکل ۲.۱).

معماری یک سیستم ERP برای صنعت ۴.۰ نمای برداری و فارسی‌شده معماری دوقلوی کنترلی دیجیتال شامل واقعیت، مخزن داده، تنظیم و کنترل، کنترل‌گر سامانه کاربردی، کابین لجستیک، مرکز گرانش داده، محرک دیجیتال و سایه دیجیتال.
شکل ۲.۱ — معماری یک سیستم ERP برای صنعت ۴.۰؛ بازطراحی برداری و فارسی‌شده بر اساس شکل اصلی مقاله.

ابتدا عناصر سازنده به‌اختصار تشریح می‌شوند و سپس تمرکز بر بخش تنظیم و کنترل، به‌عنوان مغز سیستم ERP، قرار می‌گیرد. این بخش شامل کابین لجستیک برای نظارت و مرکز گرانش داده برای تحلیل داده، پیش‌بینی فرایند و پیکربندی‌های آزمایشی است.

۱. واقعیت

واقعیت، فرایند واقعی تولید و جریان مواد (Production and Material Flow — PMF) است که باید به‌وسیله سیستم ERP برنامه‌ریزی، کنترل و پایش شود. این قلمرو همه فعالیت‌های ساخت، حمل‌ونقل، انبارش و جابه‌جایی محصولات نهایی و قطعات موردنیاز را دربر می‌گیرد. واقعیت به‌وسیله نقاط شمارش نگاشت می‌شود؛ نقاطی که برای کنترل سفارش‌محور فرایند به کار می‌روند. اشیای اصلی کنترل، محصولات نهایی و قطعات موردنیاز هستند، اما دامنه می‌تواند همه انواع اقلام جریان مواد (Material Flow Items — MFI) را نیز شامل شود؛ از جمله وسایل حمل و بارگیری مانند کامیون، قطار، سبد، مخزن و کانتینر که از تجهیزات و زیرساخت‌های جابه‌جایی مواد مانند جاده، راه‌آهن، خطوط مونتاژ و انبارها استفاده می‌کنند.

۷. سایه دیجیتال

سایه‌های دیجیتال (Digital Shadows — DS) داده‌های واقعی اخذشده از فرایندهای حقیقی‌اند که وضعیت، زمان، مکان و مقدار یک قلم جریان مواد شناسایی‌شده را بازتاب می‌دهند. این داده‌ها ممکن است به روش‌های مختلف و با ابزارها و فناوری‌های گوناگون دریافت شوند: ورود دستی، اسکن بارکد یا کد QR، دریافت از تراشه RFID فعال یا غیرفعال، یا انتقال از طریق یک شیء سایبرفیزیکی که خود می‌تواند داده را ذخیره، پردازش، به‌اشتراک‌گذاری و ارسال کند. برای دوقلوی کنترلی دیجیتال، نوع فناوری یا ابزار اخذ داده تعیین‌کننده نیست؛ نکته اصلی آن است که داده فرایندی در زمانی که برنامه کاربردی برای هدف و وظیفه مشخص خود به آن نیاز دارد، در دسترس باشد. داده فرایندی توسط ابزارهای فیزیکی یا انسان تولید می‌شود، اما تنها آن دسته از داده‌ها «سایه دیجیتال» محسوب می‌شوند که در نقاط شمارش تعریف‌شده و برای زمان چرخه فرایندی از پیش تعیین‌شده اخذ شده باشند.

۸. دریافت سفارش‌ها و برنامه‌های تحقق‌یافته

سایه‌های دیجیتال از فرایندها و ابزارهای متفاوت می‌آیند و اغلب با سرعت بسیار زیاد و در حجم عظیم تولید می‌شوند. پردازش فوری همه داده‌های اخذشده برای یک برنامه ERP منطقی نیست، زیرا زمان و شیوه پردازش به وظیفه مشخص برنامه و زمان پاسخ آن وابسته است. بنابراین به نوعی «فیلتر» نیاز است تا داده‌های جاری را متراکم کند و آن‌ها را به‌شیوه مناسب، تحت کنترل زمان چرخه فرایند مربوط، به برنامه ERP تحویل دهد.

۲. مخزن مشترک داده

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

۳. تنظیم و کنترل

تنظیم و کنترل، همه فعالیت‌های برنامه‌ریزی، زمان‌بندی، پایش و متعادل‌سازی اقلام جریان مواد را شامل می‌شود؛ به‌ویژه تولید برنامه‌ها و محاسبه سفارش‌ها. وظیفه اصلی آن تضمین این است که قلم جریان مواد درست، با مقدار درست، در زمان درست و مکان درست در دسترس باشد. مقادیر دقیق سفارش محصولات و قطعات باید برای کل شبکه تعیین شود. روش اصلی بر اصل کنترل حلقه‌بسته استوار است؛ به‌گونه‌ای که سفارش‌ها و برنامه‌های ثبت‌شده، مقدار هدف و سفارش‌ها و برنامه‌های تحقق‌یافته، مقدار واقعی محسوب می‌شوند. انحراف میان مقادیر هدف و واقعی توسط نرم‌افزار کنترل ارزیابی و متعادل می‌شود. اجرای برنامه‌ها به‌وسیله کنترل‌گر سامانه کاربردی انجام می‌گیرد؛ جایی که قواعد و دستورالعمل‌ها به‌صراحت تعریف و ذخیره می‌شوند. این قابلیت، یک کارکرد کاملاً جدید برای ERP است. اجرای هر برنامه با یک زمان چرخه به‌روزرسانی خاص کنترل می‌شود که به هدف و وظیفه برنامه و سطح ساختار PMF وابسته است.

۵. صدور سفارش‌ها و برنامه‌های ثبت‌شده

خروجی یک برنامه ERP، سفارش‌های ثبت‌شده و برنامه‌های زمان‌بندی‌شده است؛ اما همیشه امکان یا ضرورت ندارد که این نتایج فوراً به ابزارها، مکان‌ها یا شرکای نیازمند ارسال شوند. سفارش‌ها و برنامه‌ها باید در زمان‌ها و روش‌های متفاوت صادر شوند و این صدور توسط زمان چرخه پاسخِ فرایند مشخص، همراه با شرایط فنی و سازمانی، کنترل می‌شود. یک ابزار اختصاصی باید ارسال نتایج را مدیریت کند تا برای فرایندهای فیزیکی و شرکای درگیر مشکل ایجاد نشود. اگر سفارش‌ها بیش از حد زود صادر شوند، فرایند و شرکا ممکن است بیش‌واکنشی نشان دهند؛ و اگر بیش از حد دیر صادر شوند، فرایند به تأخیر می‌افتد و واکنش شرکا نیز دیرهنگام و نامناسب خواهد بود.

۶. محرک دیجیتال

محرک‌های دیجیتال، سفارش‌ها و برنامه‌هایی هستند که واقعاً به یک ابزار یا شریک مشخص ارسال شده‌اند. این محرک‌ها فرایند واقعی ساخت، حمل‌ونقل، انبارش و جابه‌جایی اقلام جریان مواد را کنترل می‌کنند. در نهایت، محرک دیجیتال باید توسط ابزار فیزیکی یا انسان اجرا شود و ورودی دوقلوهای دیجیتال مهندسی‌محور را تشکیل دهد.

۴. کنترل‌گر سامانه کاربردی

چون همه برنامه‌های ERP در یک سامانه واحد اجرا می‌شوند، کنترل‌گر سامانه کاربردی (ASC) برای کنترل اجرای نرم‌افزارهای کاربردی بر پایه مجموعه قواعد کنترلیِ صریح لازم است. هر برنامه به قواعد مخصوص خود نیاز دارد، زیرا اجرای آن به وظیفه و محیط فرایندی مشخص، سلسله‌مراتب غلبه تعریف‌شده برای فرایند، و زمان‌های چرخه تعریف‌شده برای به‌روزرسانی کنترل و پردازش محرک‌های دیجیتال و سایه‌های دیجیتال وابسته است. ازاین‌رو ASC پلی ضروری میان سیستم ERP و سامانه کنترل عملیات رایانه (OCS) است.

۹. کابین لجستیک

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

۱۰. مرکز گرانش داده

مرکز گرانش داده (Data Gravity Centre — DGC) شبیه یک «دریاچه داده» است که تاریخچه کامل داده‌های واقعیت، مخزن و نتایج تنظیم و کنترل را نگهداری می‌کند؛ یعنی همه محرک‌های دیجیتال، سایه‌های دیجیتال و انحراف‌های شناسایی‌شده. این مرکز همچنین همه داده‌های مربوط به وضعیت خود سامانه را دربر می‌گیرد و می‌تواند با کلان‌داده‌های خارجی غنی شود تا ابزارهای تحلیل داده، فرایندها و کنترل سفارش در سازمان را در آینده تاب‌آورتر کنند.

تحلیل داده

تحلیل داده (Data Analytics — DA) همه ابزارهای تحلیل و بهره‌برداری از داده‌های مرکز گرانش داده را شامل می‌شود. از DGC می‌توان برای سناریوهای آزمایشی و تصویرسازی آینده نیز استفاده کرد؛ به این صورت که مجموعه‌های متفاوتی از داده‌های کنترلی به کار گرفته شوند تا از پیش مشخص شود در صورت وقوع حادثه یا رویداد غیرعادی چه اتفاقی می‌افتد یا چه رخدادی محتمل است. ابزارهای بهینه‌سازی و شبیه‌سازی نیز می‌توانند برخی مسائل زیربنایی را در زمانی کوتاه‌تر از ابزار برنامه‌ریزی حل کنند، یا مسائلی را حل کنند که ابزار برنامه‌ریزی قادر به حل آن‌ها نیست؛ برای نمونه، محاسبه توالی واقعی وسایل حمل‌ونقل در یک فرایند JIT برای تأمین‌کنندگان بسیار دور. کارکرد تازه دیگر، پیش‌بینی رفتار آینده فرایند است. با لجستیک پیش‌بینانه می‌توان مشکلات را پیش از وقوع شناسایی کرد تا در صورت نیاز، فرایند و یا داده‌های پایه و کنترلی نگهداری و اصلاح شوند.

۳. مخزن مشترک برای همه برنامه‌های عملیاتی و لجستیکی ERP

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

۳.۱. پایگاه‌های داده مخزن؛ دنیای مجازی سیستم ERP

مخزن از تعداد زیادی پایگاه داده مرتبط با یکدیگر تشکیل می‌شود. در اینجا واژه «پایگاه داده» لزوماً به یک پایگاه داده فیزیکی واحد اشاره ندارد؛ بلکه نامی عمومی برای یک محتوای اطلاعاتی مشخص است که می‌تواند در چند پایگاه داده یا فهرست متصل نگهداری شود.

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

پایگاه داده ساختار تولید و جریان مواد، پایگاه مرکزی مخزن است و نگاشت کامل شبکه تأمین، تولید و توزیع محصولات گسسته را پوشش می‌دهد. این ساختار یک سیستم بسته است؛ همه اقلام جریان مواد فقط در مسیرهای تعریف‌شده آن حرکت می‌کنند و تنها زمانی دقیق عمل می‌کند که دنیای واقعی لجستیک به‌طور کامل و سازگار نگاشت شده باشد. در سیستم‌های کلاسیک ERP چنین شبکه‌ای به‌صورت صریح تعریف نشده است. اطلاعات تولید و جریان مواد معمولاً تنها در قالب یک شماره شناسایی ساده برای کارخانه یا تأمین‌کننده، و در داخل کارخانه برای کارگاه‌ها، مراکز هزینه، خطوط مونتاژ، انبارها، محل‌های ذخیره‌سازی یا بافرها استفاده می‌شود. فقط در بعضی برنامه‌های سطح کارگاه، اطلاعات محدودی درباره ساختار جریان مواد برای اجرای عملیات وجود دارد. بنابراین چیزی که همچنان در سیستم‌های کلاسیک ERP کم است، یک ساختار PMF صریح برای همه فرایندها، مسیرها، مکان‌ها و دیگر اجزاست؛ ساختاری که بتواند به‌طور مشترک توسط برنامه‌های مختلف ERP استفاده شود.

ساختار PMF ارتباط نزدیکی با ساختار محصول در سمت چپ و ساختار بسته‌بندی، حمل‌ونقل و جابه‌جایی در سمت راست دارد. این سه پایگاه داده در کنار هم اسکلت سیستم ERP را تشکیل می‌دهند. ساختار محصول همه قطعات لازم برای تولید محصول نهایی را شامل می‌شود که معمولاً در قالب فهرست مواد (Bill of Material — BoM) ذخیره می‌شوند. برای حوزه‌های تولیدی مختلف می‌توان از انواع و قالب‌های متفاوت فهرست مواد استفاده کرد که شرح تفصیلی آن در محدوده این مقاله نیست [He20]. برای حوزه‌های مختلف ارسال نیز باید مشخص باشد که یک شیء چگونه جابه‌جا شود: به‌صورت تکی یا در یک بچ، داخل کانتینر ویژه یا به‌صورت آزاد، و با چه وسیله‌ای مانند کامیون یا کشتی حمل شود.

در کنار این موارد، پایگاه داده اطلاعات ابزارها و دارایی‌های تولید، حمل‌ونقل و جابه‌جایی قرار دارد. این پایگاه، پارامترهای مهندسی مانند ابعاد و وزن یک شیء، سرعت وسایل حمل‌ونقل، نرخ تَکت تجهیزات یا خط مونتاژ، ظرفیت دارایی‌ها و محدودیت‌هایی را که باید در محاسبات لحاظ شوند، نگهداری می‌کند.

پایگاه داده‌های کنترلی اشیا و فرایندها همه پارامترهای لازم برای تنظیم کمی PMF و به‌ویژه محاسبه برنامه‌ها و سفارش‌های همه اقلام جریان مواد را شامل می‌شود. تنظیم دقیق داده‌های کنترلی، متغیری بسیار اثرگذار است و باید برای هر بازه و هر MFI با دقت انجام شود. تمرکز این مقاله فقط بر زمان پیشبرد (Lead Time — LT) است که مهم‌ترین پارامتر کنترل محسوب می‌شود؛ بااین‌حال محاسبه سفارش و زمان‌بندی بدون اندازه لات، اندازه بچ و سایر داده‌های کنترلی امکان‌پذیر نیست.

۳.۲. ساختار PMF؛ شبکه داده مرتب برای همه نرم‌افزارهای کنترلی ERP

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

برای نگاشت تولید و جریان مواد از نظریه ریاضی جبر بولی، به‌ویژه رده‌هایی مانند بازه‌های بولی و درخت‌های بولی، استفاده می‌شود [Ko89]. فرض می‌شود PMF یک زنجیره مرتب خطی با تعریف بسته-باز است که مرز چپ و راست دارد و الزامات یک شبکه ایده‌آل بازه بولی را برآورده می‌کند. میان بازه‌های متوالی هیچ پرش یا هم‌پوشانی وجود ندارد؛ هیچ بازه‌ای از زنجیره حذف نشده و هیچ بازه‌ای خارج از بازه کل قرار نمی‌گیرد. آغاز هر بازه با یک نقطه ورود (Entry Point — EP) تعریف می‌شود که داخل بازه قرار دارد. پایان بازه نیز با EP دیگری تعیین می‌شود که خارج از بازه است و باید نقطه آغاز بازه بعدی باشد.

تعریف جبری کامل بازه‌ها و زیربازه‌ها به‌دلیل محدودیت فضا در مقاله حذف شده است؛ اطلاعات تفصیلی در [He12, He20] آمده است. برای توضیح کوتاه در صنعت خودرو، بازه Int-PP برای کل فرایند ساخت و ارسال تعریف می‌شود که فضای مجازی تولید و جریان مواد را مشخص می‌کند (شکل ۳.۴). این بازه از نقطه ورود PE آغاز می‌شود که شروع کل فرایند مورد مشاهده را نشان می‌دهد و در نقطه ورود UE پایان می‌یابد که پایان فرایند را علامت‌گذاری می‌کند. نقطه UE باید آغاز بازه بعدی باشد؛ بازه‌ای که کاربرد محصولات نهایی را نشان می‌دهد.

Int-PP = [PE < UE);   PE and UE are EPs of the entire production process   (1)

بازه بالادست به چهار زیربازه کاملاً مرتب تقسیم می‌شود: تولید قطعه منفرد Int-SP، تولید گروه مونتاژی Int-AP، تولید ماژول Int-MP و تولید محصول نهایی Int-FP. این زیربازه‌ها از یکدیگر مجزا و در عین حال مکمل‌اند و به‌صورت ایده‌آل در بازه بالادست Int-PP قرار می‌گیرند. هر زیربازه نماینده یک بخش معمول از فرایند تولید محصولات پیچیده، مانند صنعت خودرو، است. ساختار ایده‌آل PMF به‌صورت زیر تعریف می‌شود:

Int-PP = {Int-SP, Int-AP, Int-MP, Int-FP}   Int-PP is the entire interval   (2)

هر زیربازه با دو نقطه ورود تعریف می‌شود و نقطه ورود پایانی یک بازه باید نقطه ورود آغازین بازه بعدی باشد. در ادامه فقط تعریف زیربازه تولید محصول نهایی ارائه می‌شود:

Int-FP = [FP < FU);   FP and FU are the two bounding Counting Points   (3)
Int-FP = {Int-FF, Int-FS};   Int-FA: Final Assembling, Int-FS: Final Shipping   (4)
Int-FF = [MH < FF);   MH and FF are the two bounding CPs of the interval   (5)
Int-FF = {Int-FA, Int-FI};   Int-FA: Final Assembly; Int-FI: Final Inspection   (6)
Int-FA = {takt-1, …, takt-y};   all intervals of the Final Assembly Line   (7)
Int-FA = [t1 < ti < tn < tz);   all successive CPs of the Final Assembly Line   (8)

اگر یک نقطه ورود به یک نقطه اخذ داده موجود (Data Acquisition Point — DAP) ارجاع داده شود، آن را نقطه شمارش (Counting Point — CP) می‌نامیم. این فرایند ارجاع‌دهی، جدید اما الزامی است؛ در غیر این صورت نتایج محاسبات صحیح نخواهند بود. بدین ترتیب، کل فرایند تولید محصولات نهایی و قطعات آن‌ها بر یک بنیان ریاضی سازگار نگاشت می‌شود. این نگاشت به‌ویژه برای DCT اهمیت دارد. هرچه ساختار PMF گسترده‌تر و عمیق‌تر تعریف شود، برنامه ERP دقیق‌تر عمل می‌کند؛ زیرا ریزدانگی سلسله‌مراتب و نقاط شمارش پیاده‌سازی‌شده برای کنترل همه فرایندها استفاده می‌شوند. هر CP یک گره در شبکه داده مرتب است که همه برنامه‌های ERP از آن استفاده می‌کنند. محاسبه از CP با شناسه FF و با تجزیه سفارش‌های مشتری به نیازمندی مواد آغاز می‌شود، سپس از یک CP به CP قبلی به‌صورت معکوس ادامه می‌یابد و در CP با شناسه SP پایان می‌گیرد؛ نقطه‌ای که معمولاً محل دریافت کالا در کارخانه است (شکل ۳.۴).

۳.۳. معیار هم‌فاصله در ساختار PMF

ساختار ایده‌آل PMF فقط یک نگاشت منطقی است و معنای کمی ندارد؛ بنابراین برای محاسبات عددی مناسب نیست. بااین‌حال زمان‌بندی و پایش فرایندها به یک معیار کمی نیاز دارد که برای همه بازه‌ها معتبر باشد. در نگاه اول، فاصله فیزیکی میان دو CP متوالی می‌تواند معیار مناسبی باشد، اما یک فاصله یکسان ممکن است توسط حامل‌های بار مختلف و با سرعت‌های متفاوت طی شود؛ حمل‌ونقل به نوع وسیله و مسیر مورد استفاده وابسته است. برای هدف این مقاله، زمان پیشبرد (LT) معیار مناسب‌تری است، زیرا می‌توان آن را برای هر بازه و هر فرایند، نه‌فقط ساخت و حمل‌ونقل بلکه انبارش و جابه‌جایی، به کار گرفت.

واحد اندازه‌گیری باید برای همه بازه‌ها برابر، قابل اعمال و قابل شمارش باشد. به بیان دیگر، برای همه بازه‌ها و فرایندها به یک معیار هم‌فاصله نیاز داریم؛ در غیر این صورت نتایج محاسبات نادرست خواهند بود. همچنین برای نرمال‌سازی بازه‌ها با این واحد هم‌فاصله، به یک «تقویم» مشخص نیاز است. برای نمونه، اگر فرایند تولید یک خودرو از نظر فیزیکی سه شیفت زمان ببرد، در کارخانه‌ای با سه شیفت در روز طی یک روز پایان می‌یابد، اما در کارخانه‌ای با یک شیفت در روز سه روز طول می‌کشد. اگر در این میان آخر هفته با دو روز توقف وجود داشته باشد، کل فرایند پنج روز زمان خواهد برد. این مثال نشان می‌دهد که برای محاسبه LT باید تقویم میلادی معمولی را به یک تقویم فرایندی با واحدهای هم‌فاصله نرمال‌سازی کرد.

این کار را می‌توان با تقویمی انجام داد که واحدهای زمان توقف در آن علامت‌گذاری شده‌اند تا در محاسبه نادیده گرفته شوند؛ زیرا پارامتر LT فقط زمان خالص پردازش را نشان می‌دهد. کوچک‌ترین واحد زمانی می‌تواند ثانیه باشد و همه واحدهای دیگر مانند ساعت، شیفت، روز، هفته، دهه، ماه یا سال باید به این معیار ارجاع داده شوند. بدون چنین تقویم فرایندی نرمال‌شده‌ای، محاسبه زمان صحیح برای مقادیر سفارش ممکن نیست.

۳.۴. کنترل نمونه برنامه‌های ERP در سطوح مختلف PMF

در این بخش، کنترل چند برنامه معمول ERP شامل برنامه‌ریزی فروش، زمان‌بندی اصلی تولید، متعادل‌سازی خط مونتاژ و فراخوان‌های JiT/JiS با مثال صنعت خودرو تشریح می‌شود (شکل ۳.۴). فرایند ERP با کنترل برنامه‌ریزی فروش محصولات نهایی، یعنی خودروها، در بالاترین سطح PMF آغاز می‌شود. این سطح کل بازه فرایند FP → UE را پوشش می‌دهد و CP مرجع برای برنامه فروش در بازارهای مختلف FU است. واحد زمانی برنامه‌ریزی فروش معمولاً سال است که به فصل و یا ماه تقسیم می‌شود. چرخه برنامه‌ریزی یا بازبرنامه‌ریزی با شروع سال جدید انجام می‌شود و برای سال جاری می‌توان در هر فصل به‌روزرسانی غلتان داشت.

بر پایه نتایج برنامه‌ریزی فروش، برنامه اصلی تولید MPS برای نمونه برای سه ماه از سال جاری و برای کارخانه محصول نهایی تولید می‌شود. MPS به هفته و روز تقسیم می‌شود و CP مرجع آن FF است که پایان تولید محصول نهایی را نشان می‌دهد. به‌روزرسانی غلتان MPS در آغاز هر ماه انجام می‌شود و دو هفته آخر به‌صورت روزانه به‌روزرسانی می‌شوند. برای کنترل بیشتر می‌توان از زیربازه‌های اصلی تولید قطعات پرسی، تولید شاسی، تولید بدنه خودرو و تولید محصول نهایی استفاده کرد؛ به‌گونه‌ای که روزهای چهار هفته آخر به شیفت تقسیم شوند.

تمرکز بعدی بر خط مونتاژ نهایی است که در آن توالی محصولات نهایی برای هر خط مونتاژ تعیین می‌شود. در اینجا از سطح بعدی PMF، یعنی بازه Int-FA (MH → FF)، استفاده می‌شود. متعادل‌سازی خط مونتاژ برای دو هفته آخر به‌صورت روزانه یا در هر شیفت به‌روزرسانی می‌شود و می‌توان برای چند روز یک افق منجمد تعریف کرد. بازه Int-FA (takt-1 → takt-y) برای برنامه‌های JiT/JiS به کار می‌رود که از پیش بر پایه مفهوم «زنجیره مرواریدی» ایجاد می‌شوند. داده فرایندی نیز در زمان واقعی یا بر اساس زمان چرخه فرایند خط مونتاژ نهایی منتقل می‌شود.

ساختار PMF و کنترل برنامه‌های مختلف ERP نمای برداری و فارسی‌شده سطوح فرایند تولید خودرو، نقاط شمارش، برنامه فروش، برنامه اصلی تولید، برنامه مونتاژ نهایی، فراخوان JiT/JiS و کنترل‌گر سامانه کاربردی.
شکل ۳.۴ — ساختار تولید و جریان مواد و کنترل برنامه‌های مختلف ERP؛ بازطراحی برداری و فارسی‌شده بر اساس شکل اصلی مقاله.

با شناخت ارتباط میان فرایندها، ساختار PMF و برنامه کاربردی، می‌توان فرایند را با یک زمان چرخه تعریف‌شده برای هر بازه کنترل کرد. این زمان برای به‌روزرسانی، پردازش داده و در نتیجه سامانه کنترل عملیات سخت‌افزار اهمیت حیاتی دارد. محاسبه همه داده‌های همه برنامه‌ها در هر ثانیه منطقی نیست. همین موضوع درباره پردازش داده‌های گردآوری‌شده نیز صدق می‌کند. در پایین‌ترین سطح PMF به جدیدترین داده واقعی نیاز داریم، اما داده نباید الزاماً در زمان واقعی پردازش شود؛ بلکه باید در زمان چرخه فرایند پردازش گردد. دلیل این موضوع، زمان پیشبرد جریان مواد در یک بازه و زمان پاسخ فرایند به یک رویداد جدید است. اگر زمان چرخه پردازش بیش از حد کند باشد، واکنش یا محرک دیجیتال دیر صادر می‌شود. اگر بیش از حد سریع باشد، واکنش یا محرک دیجیتال زودتر از موعد می‌رسد و فرایند «عصبی» شده و بیش‌ازحد کنترل می‌شود.

در ارتباط با LT، زمان واکنش یا پاسخ (Response Time — RT) اقلام جریان مواد و زمان چرخه (Cycle Time — CT) برای مقادیر هدف جدید نقش مهمی دارند. از یک سو CT به LT موردنیاز وابسته است و از سوی دیگر RT تحت تأثیر عواملی مانند اندازه بچ و زمان حرکت قرار می‌گیرد. اگر CT بسیار کمتر از RT باشد، فرایند واقعی نمی‌تواند با فرایند مجازی همگام شود؛ در نتیجه سامانه بیش از حد سریع واکنش نشان می‌دهد و واکنش‌های شتاب‌زده و نادرست ایجاد می‌شود. اگر CT بسیار بیشتر از LT باشد، سامانه DCT بیش از حد کند واکنش نشان می‌دهد که می‌تواند کمبود مواد و هزینه‌های اضافی قابل اجتناب ایجاد کند.

ساختار ایده‌آل PMF چند ویژگی مفید برای برنامه‌های ERP دارد. یکی از این ویژگی‌ها آن است که داده واقعی فرایند فقط باید در پایین‌ترین سطح PMF اخذ شود. داده واقعی همه سطوح بالاتر، حاصل جمع داده‌های واقعی پایین‌ترین سطح است؛ بنابراین همه برنامه‌های ERP از یک داده مشترک استفاده می‌کنند. علت این است که نخستین CP یک بازه پایین‌تر همان معنای نخستین CP بازه بالاتر متناظر را دارد. اگر یک MFI از نخستین CP یک بازه پایین‌تر عبور کند، همزمان از CP همه بازه‌های بالاتر متناظر نیز عبور کرده است. برای نمونه، با عبور از t1، نقاط FE، MH و FP نیز در همان لحظه عبور داده‌شده محسوب می‌شوند (شکل ۳.۴). بنابراین داده‌های واقعی فرایند در سطوح مختلف PMF در این CPها سازگارند، هرچند زمان فرایند و زمان پاسخ برنامه‌ها متفاوت است.

سفارش ثبت‌شده، یعنی مقدار هدف، برای یک CP مشخص در سطح بالاتر PMF با همه CPهای متناظر در سطوح پایین‌تر برابر است. این ویژگی‌های ایده‌آل شبکه داده، هماهنگ‌سازی برنامه‌های مختلف ERP در سطوح گوناگون PMF را سرعت می‌دهد؛ زیرا به انتقال داده نیاز نیست و بازخورد مستقیم داده میان برنامه‌های مختلف ERP تضمین می‌شود.

از آنجا که سیستم ERP بر DCT عمل می‌کند، به یک پل ارتباطی کاملاً جدید میان برنامه‌های ERP و سامانه کنترل عملیات رایانه نیاز است. چون سیستم ERP همواره در حال اجراست، یک ابزار داخلی ویژه باید به‌طور دائمی برنامه‌های مختلف ERP را کنترل و داده‌ها و وظایف را هماهنگ کند. این پل همان کنترل‌گر سامانه کاربردی (ASC) است؛ ابزاری نرم‌افزاری و جدید که قواعد کنترل را به‌صراحت در خود نگهداری می‌کند، درحالی‌که این قواعد در سیستم‌های کلاسیک ERP به‌صورت ضمنی درون برنامه‌ها قرار دارند.

در سیستم‌های کلاسیک ERP، برنامه‌های مختلف بر اساس مفهوم آبشاری و به‌صورت «کار به کار» اجرا می‌شوند. کارها با رویه‌های کنترل کار به یکدیگر متصل‌اند و داده‌ها از طریق واسط‌ها انتقال می‌یابند. اما هنگامی که همه برنامه‌های ERP در یک سامانه فناوری اطلاعات واحد اجرا می‌شوند، لازم است همه قواعد کنترل و زمان‌های چرخه به‌صورت صریح در یک سامانه اختصاصی کنترل برنامه تعریف شوند (شکل ۲.۱).

۴. جمع‌بندی و چشم‌انداز کوتاه

معماری کاربردی طراحی‌شده برای سیستم ERP از ظرفیت‌های صنعت ۴.۰ و منابع داده‌ای دائماً در دسترس سازمان بهره می‌گیرد. این هدف از طریق مفهوم دوقلوی کنترلی دیجیتال محقق می‌شود. DCT بر یک مخزن مشترک استوار است که در آن ساختار تولید و جریان مواد به‌صورت صریح و دقیق تعریف شده و با ساختار محصول و ساختار حمل‌ونقل ارتباط دارد. هر نقطه شمارش در ساختار PMF یک گره از شبکه داده مرتب است. این شبکه برای محاسبه محرک‌های دیجیتال جهت کنترل فرایند و دریافت سایه‌های دیجیتال فرایند استفاده می‌شود. خود کنترل نیز برای هدایت و متعادل‌سازی فرایندها بر اصل کنترل حلقه‌بسته مبتنی است.

در حال حاضر فقط یک نمونه نمایشی کوچک برای پژوهش بیشتر و اثبات مفهوم وجود دارد. پیش از پیاده‌سازی عملی، این نمونه باید به یک سامانه حرفه‌ای فناوری اطلاعات توسعه داده شود.

بر پایه مقادیر هدف و واقعی شبکه داده مرتب، همه برنامه‌های ERP در یک سامانه واحد اجرا می‌شوند. بنابراین به واسط و انتقال داده میان برنامه‌های مختلف نیازی نیست و اتلاف دقت داده و تأخیر زمانی نیز حذف می‌شود. افزون بر این، قواعد و ابزارهای کنترلی هر برنامه ERP باید به‌صورت صریح در یک سامانه کنترل برنامه جداگانه تعریف شوند. این سامانه زمان‌های چرخه لازم برای به‌روزرسانی برنامه، صدور محرک‌های دیجیتال و دریافت سایه‌های دیجیتال را نیز نگهداری می‌کند.

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

در نهایت، به نظر می‌رسد سیستم ERP آینده از جهاتی با کنترل یک خودروی خودران شباهت دارد. در این قیاس، خودرو همان کارخانه است که توسط نرم‌افزارهای کاربردی ERP هدایت می‌شود و داده فرایندی را از ابزارهای فنی کارخانه، وسایل حمل‌ونقل و تجهیزات جابه‌جایی دریافت می‌کند.

۵. منابع و کتاب‌شناسی

مطابق درخواست، نشانی‌های اینترنتی و پیوندهای خارجی حذف شده‌اند. نام نویسندگان، عنوان منابع، اطلاعات انتشار، تاریخ دسترسی و شناسه‌های DOI موجود در متن اصلی حفظ شده‌اند.
  1. [BBG21] Bender, B.; Bertheau, C.; Gronau, N. “Future ERP Systems: A Research Agenda.” In: Proceedings of the 23rd International Conference on Enterprise Information Systems (ICEIS 2021), Volume 2, pp. 776–778. DOI: 10.5220/001047730776078.
  2. [De19] Deutsche Post DHL Group. “Digital Twins in Logistics — A DHL Perspective on the Impact of Digital Twins on the Logistics Industry.” 2019. Accessed 24/4/2021.
  3. [Di17] Gesellschaft für Informatik. “Digitaler Zwilling.” In: Informatik-Lexikon, 2017.
  4. [Di19] Deutsche Post DHL Group. “Digital Twins in Logistics — A DHL Perspective on the Impact of Digital Twins on the Logistics Industry.” 2019. Accessed 24/4/2021.
  5. [Di20] Wissenschaftliche Gesellschaft für Produktion. “Digitaler Zwilling.” 2020. Accessed 20/4/2021.
  6. [Gr14] Grieves, M. “Digital Twin — Manufacturing Excellence through Virtual Factory Replication.” Whitepaper, LLC, 2014. Accessed 20/4/2021.
  7. [He11] Heizer et al. Operations Management — Sustainability and Supply Chain Management. 12th ed., Pearson Education Ltd., Essex, England, 2017.
  8. [He12] Herlyn, W. PPS im Automobilbau — Produktionsprogrammplanung und -steuerung von Fahrzeugen und Aggregaten. Hanser Verlag, München, 2012.
  9. [He19] Herlyn, W. “ERP und Industrie 4.0.” Industriemanagement 15 (2019), no. 4, pp. 26–29.
  10. [HE20] Herlyn, W. “Comprehensive MRP-Concept for Complex Products in Global Production and Supplying Networks.” 2020. DOI: 10.13140/RG.2.2.31478.14404.
  11. [Ko89] Koppelberg, S. “Special Classes of Boolean Algebra.” In: Monk, J. D.; Bonnet, R. (eds.), Handbook of Boolean Algebra, Vol. 1. North-Holland, Amsterdam, 1989.
  12. [KT18] Khan, A.; Turowski, K. “A Perspective on Industry 4.0: From Challenges to Opportunities in Production Systems.” In: Proceedings of the International Conference on Internet of Things and Big Data (IoTBD 2016), pp. 441–448.
  13. [Ku13] Kurbel, K. E. Enterprise Resource Planning and Supply Chain Management Functions, Business Processes and Software for Manufacturing Companies. Springer, Berlin, 2013.
  14. [LL07] Laudon, K. C.; Laudon, J. P. Management Information Systems. 10th ed., Pearson International Edition, New Jersey, 2007.
  15. [Lh13] Lödding, H. Handbook of Manufacturing — Fundamentals, Description, Configuration. Springer, Berlin Heidelberg, 2013.
  16. [Mi18] SAP. Mit der SAP Digital Supply Chain zum intelligenten Unternehmen. 2018.
  17. [Pl20] Bundesministerium für Bildung und Forschung. Plattform Industrie 4.0 — Innovationen im Zeitalter der Digitalisierung. Berlin, 2020. Accessed 23/4/2021.
  18. [Pl21] Bundesministerium für Wirtschaft und Energie. Plattform Industrie 4.0: Industrie 4.0 gestalten. Souverän. Interoperabel. Nachhaltig — Fortschrittsbericht 2020. Berlin, 2020. Accessed 23/4/2021.
  19. [Sc16] Schönsleben, P. Integral Logistics Management: Operations and Supply Chain Management Within and Across Companies. 5th ed., CRC Press, Boca Raton, 2016.
  20. [SKF20] Schryen, G.; Kliewer, N.; Fink, M. “High Performance Business Computing.” 2017. Accessed 20/4/2021.
  21. [ZH20] Zadek, H.; Herlyn, W. “Der Digitale Steuerungs-Zwilling.” Zeitschrift für wirtschaftliche Fertigung (ZwF), vol. 115, special issue “Digitaler Zwilling”, 2020, pp. 70–73. DOI: 10.3139/104.112338.
  22. [ZH21] Zadek, H.; Herlyn, W. “Mastering the Supply Chain by a Concept of a Digital Control-Twin.” In: Proceedings of Hamburg International Conference of Logistics (HICL), vol. 29, 2020, pp. 661–697. Accessed 20/4/2021. DOI: 10.15480/882.3120.
ترجمه کامل فارسی و بازطراحی برداری نمودارها برای انتشار مستقیم در وب. فایل کاملاً مستقل است و به هیچ تصویر، فونت یا پیوند خارجی وابسته نیست.

امتیاز کاربران به این مقاله

☆☆☆☆☆

0 نفر امتیاز داده اند. میانگین: 0.0 از 5

برچسبها : ERP معماری ERP

 

0 نظر

نظر محترم شما در مورد مقاله های وب سایت برنامه نویسی و پایگاه داده

نظرات محترم شما در خدمات رسانی بهتر ما را یاری می نمایند. لطفا اگر مایل بودید یک نظر ما را مهمان فرمائید. آدرس ایمیل و وب سایت شما نمایش داده نخواهد شد.

0 / 500

اطلاعات تماس

  • آدرس:اصفهان-خیابان ام کلثوم غربی - بعد خیابان تخم چی - بیست متر بعد از پیتزا ننه شب - کوچه تعمیر گاه سمار زغالی - پلاک 354 - درب مشکی - طبقه هفتم
  • آدرس ایمیل:najafzade@gmail.com
  • وب سایت:http://www.a00b.com/
  • تلفن ثابت:(+98)9131253620
  • تلفن همراه:09131253620