برنامه‌ریزی منابع سازمانی (ERP) یکی از مهم‌ترین سیستم‌هایی است که سازمان‌های کوچک و بزرگ از مدت‌ها پیش آن را در سازمان خود پیاده‌سازی کرده‌اند یا به دنبال پیاده‌سازی آن هستند. ERP یک سیستم نرمافزاری است و در هنگام انتخاب و پیاده‌سازی آن به یکی از مواردی که باید توجه کرد نوع معماری و ساختار سیستم است. امروزه با توجه به وجود فضای ابری و سرویس‌هایی که در اختیار کاربران قرار می‌دهد، سیستم‌های ERP به گونه‌ای پیاده‌سازی می‌شوند که معماری آن‌ها سازگار با فضای ابری باشد و شرکت‌هایی که به تازگی می‌خواهند از ERP استفاده کنند می‌توانند از این نوع سیستم خریداری نمایند. اما سازمان‌هایی که در گذشته نسخه‌های قدیمی یک سیستم ERP مبتنی بر وب یا سرویس را خریداری و درون سازمان خود مستقر کردند برای آن که بتوانند از فضای ابری و امکانات آن بهره ببرد باید با استفاده از روش‌های مهاجرت برنامه‌ها به فضای ابر سیستم خود را به فضای ابر منتقل نمایند تا بتوانند از برخی امکانات آن استفاده کنند. روش‌های مهاجرتی، روش‌هایی هستند که به کمک آن‌ها می‌توان برنامه‌هایی که در فضای ابری مستقر نیستند و امکان استفاده از سرویس‌های ابری را ندارند به فضای ابری برد. در این مقاله هدف توضیح این روش‌ها و بررسی موردی سازمان‌هایی است که با موفقیت توانستند سیستم ERP مبتنی بر وب یا سرویس خود را با روش‌های مهاجرتی به فضای ابری منتقل کنند.
امروزه بسیار از شرکت‌ها برای کنترل و مدیریت فرایندهای خود و دسترسی به اطلاعات متمرکز به سمت استفاده از سیستم‌های برنامه‌زیری منابع سازمانی (Enterprise Resource Planning (ERP)) می‌روند. سیستم ERP را از سه دیدگاه مدیریتی، نرمافزاری و عملیاتی می‌توان تعریف و بررسی کرد. در این تحقیق هدف بررسی این سیستم از دید نرمافزاری است و معماری و زیرساخت این سیستم بررسی می‌شود. از دید نرمافزاری ERP یک مجموعه‌ای از ماژول‌های یکپارچه‌ی آماده راه‌اندازی از پیش طراحی شده و از پیش مهندسی شده است که تمام فرایندهای کسب و کار را پوشش می‌دهد. هر سیستم نرمافزاری نیز از یک معماری مشخصی پیروی می‌کند و برپایه‌ی آن توسعه می‌یابد. برای سامانه‌های ERP نیز معماری‌هایی ارائه شده است که هر سازمانی می‌تواند متناسب با نیازهایی که دارد از آن‌ها استفاده کند. از جمله نیازهای تعیین کننده در انتخاب معماری، استفاده از فناوری‌های موجود است و سازمان باید زمینه را برای استفاده از آن فناوری خاص فراهم نماید. یکی از فناوری‌های مهمی که نظرات را به سمت خود جلب کرده است و بسیاری ترقیب شده‌اند که به سمت آن بروند، محاسبات و فضای ابری است. فضای ابری این امکان را فراهم می‌کند افراد و سازمان‌ها بتوانند دسترسی آسان و نامحدودی به مجموعه‌ی مشترکی از منابع محاسباتی داشته باشند. فضای ابری برای سازمان‌ها مزایا بسیاری به همراه دارد و به کمک آن شرکت‌های ارائه دهنده‌ی فضای ابر می‌توانند در سه سطح زیرساخت، سکو و نرم‌افزار سرویس ارائه دهند و همچنین این فناوری سبب می‌شود تا در منابع مالی و انسانی و زمان سازمان‌ها صرفه جویی شود و برای سازمان‌های کوچک و متوسط (Small and Mudium Enterprises(SME)) استفاده از این فناوری بصرفه خواهد بود. بنابراین بسیاری از سازمان‌هایی که می‌خواهند از ERP استفاده کنند یا از آن در حال استفاده هستند به سمت فضای ابری باید بروند. برای آنکه یک سازمان بتواند از فضای ابری و امکاناتی که دارد استفاده نماید باید یک معماری را استفاده کند که در آن اجزای تشکیل‌دهنده‌ی سیستم ERP امکان استفاده از آن را فراهم نماید. بسیاری از شرکت‌ها که از ERP استفاده می‌کنند معماری آن سیستم‌ها مبتنی بر وب یا سرویس است و در خود سازمان به صورت محیطی (in-house) بنا شده‌اند و برای آن که بتوانند از فضای ابری استفاده نمایند باید کارهایی انجام دهند. در این تحقیق هدف بررسی راه حل‌های موجود برای سیستم‌های ERP مبتنی بر وب و سرویس است تا بتوانند از امکانات فضای ابری استفاده کنند.
ساختار این تحقیق به این صورت است: در بخش دو به معرفی و معماری‌های رایج سیستم‌های ERP پرداخته می‌شود. در بخش سه فضای ابر توضیح داده می‌شود تا با امکانات و مزایای آن و دلیل رفتن بسیاری از سازمان‌ها سمت آن مشخص شود. سپس در بخش چهار راه حل‌های موجود برای آن که بتوان سیستم‌های ERP مبتنی بر وب و سرویس را جهت استفاده از امکانات فضای ابری آماده کرد، معرفی و بررسی می‌گردند. در بخش پنج به بررسی چند مورد از سازمان‌ها پرداخته می‌شود که توانستند با موفقیت سیستم ERP خود که مبتنی بر وب یا سرویس بود را در فضای ابر مستقر نمایند. همچنین در این بخش نگاهی به یکی از شرکت‌های ارائه دهنده‌ی سیستم ERP در ایران پرداخته می‌شود تا با سرویس ERP ابری که در اختیار کاربران می‌گذار و سازمان‌هایی که به سمت این سیستم مهاجرت کردند آشنا شویم. در بخش شش نیز به جمع بندی و نتیجه‌ی حاصل از این تحقیق پرداخته می‌شود.
در هر سیستم نرمافزاری معماری یکی از مهم‌ترین کارهایی است که باید در همان ابتدای پیاده‌سازی برنامه انجام شود تا زیرساخت و اساس آن سیستم به درستی ایجاد شود و نیازهای مورد انتظار از آن سیستم را بتوان سازمانی دهی کرد. درواقع معماری در یک سیستم نرمافزاری یک دید کلی نسبت به آن سیستم و شناسایی اجزای تشکیل دهنده، ارتباط میان آن اجزا و انتخاب فناوری‌های لازم است. در یک سیستم ERP اجزای تشکیل دهنده آن می‌تواند واسط‌های کاربری، پایگاه داده جهت ذخیره سازی اطلاعات، نحوه‌ی ذخیره‌ی اطلاعات، شبکه ارتباطی و غیره دانست. معماری در سیستم ERP به ما کمک می‌کند تا تیم‌های پیاده‌سازی و مدیریت بتوانند پیچیدگی و اجزای سیستم سازمان را بفهمند، تصویری روشنی از واسط‌های پیچیده در مورد پایگاه‌های داده، سیستم‌های عامل، شبکه و برنامه‌های ERPارائه می‌دهد و باعث توسعهی بهتر برنامهی فناوری اطلاعات توسط تیم مدیریت در صورت شفاف بودن نیازمندی‌های فرایندی و ساختاری می‌شود. در ادامه به بررسی معماری‌های رایجی پرداخته می‌شود که در سیستم‌های ERPمورد استفاده قرار می‌گیرد[1].
معماری سه لایه یکی از ابتدایی‌ترین معماری‌های معرفی شده برای سیستم‌های ERP است. این معماری تعمیم یافته‌ی معماری دو لایه و یک لایه است. در معماری یک لایه از مدل یکپارچه (Monolith) استفاده شده است و تمام سیستم را به صورت یک بخش در نظر گرفته است. در این معماری اطلاعات نیز برروی یک سرور فایل مرکزی ذخیره می‌شد. در معماری دو لایه، معماری از حالت یکپارچه خارج می‌شود و عملکرد سیستم به دو لایهی پایگاه داده (یا به اختصار داده) و مشتری تقسیم می‌شود. به لایهی مشتری، لایهی نمایش نیز گفته می‌شود. از خوبی‌های این معماری آن است که بروزرسانی و دسترسی به داده راحت‌تر انجام می‌شود اما بروزرسانی منطق برنامه و توسعهی آن دشوار است و تغییرات برروی تمام سیستم کاربران به صورت تکی باید انجام شود. بنابراین به سراغ معماری سه لایه رفتند و میان لایهی داده و نمایش یک لایهی دیگر به نام حرفه اضافه شد. در لایهی حرفه درواقع منطق برنامه و کسب و کار و در لایهی نمایش تنها ظاهر برنامه است و اطلاعات به مشتری نمایش داده و دریافت می‌شود و عملیات و پردازش‌های برنامه در لایهی منطق انجام می‌شود. همچنین لایهی منطق داده‌های مورد نیاز برای پردازش را از لایهی داده می‌گیرد و در آن‌جا نیز داده‌ها را ذخیره می‌کند. از مزایای این معماری می‌توان به افزایش مقیاس‌پذیری، امنیت و اطمینان‌پذیری، نگهداری راحت‌تر از نرم‌افزار اشاره کرد. هنگامی که برنامه دچار تغییر می‌شود تنها کافی است که تغییرات انجام شده در لایهی منطق پیاده‌سازی شوند و دیگر نیازی نیست که به سراغ تمام سیستم‌های کاربران موجود در سازمان رفت. اما در این معماری به منابع زیاد، چه مالی و چه انسانی، نیاز است، محیط توسعهی پیچیده‌ای دارد و امکان ارتباط با جهان بیرون سازمان را نیز فراهم نمی‌کند. در تصویر ۱ سه معماری ذکر شده و تفاوت میانشان نشان داده شده است.
معماری مبتنی بر وب به درواقع می‌توان گفت که توسعه‌یافته‌ی معماری سه لایه است تا یکی از ضعف‌های این معماری را برطرف نماید. در این معماری دو لایهی داده و منطق همانند معماری سه لایه وجود دارد. اما لایهی نمایش، همان گونه که در تصویر ۲ نشان داده شده است، خود به دو بخش تقسیم می‌شود، سرویس‌های وب و مرورگر وب. این تقسیم بندی به منظور آن است تا کاربران از دستگاه‌های مختلف بتوانند از مکان‌های مختلفی در خارج از سازمان به سیستم ERP دسترسی داشته باشند. در این معماری ارتباط میان مشتری و لایهی منطق از طریق سرویس‌های وب موجود در لایهی نمایش صورت می‌گیرد. هدف از این معماری آن است که به کاربران اجازه دهد تا بتوانند از راه دور و بدون حضور در سازمان به سیستم ERP دسترسی داشته باشند و بدین صورت یکی از ضعف‌های معماری سه لایه که همان ارتباط با جهان بیرون بود را برطرف نماید. دسترسی راحت به اطلاعات، اختلال کمتر برای عملیات کسب و کار، یکپارچه‌سازی راحت می‌توانند از جمله مزایای این معماری باشند. همچنین در این معماری امکان استفاده از منابع خارج سازمان نیز فراهم می‌شود. به عنوان یک سازمان فضا و نیروی لازم جهت توسعهی زیرساخت و افزودن سرور وجود ندارد، به همین جهت سازمان می‌تواند از یک شرکت ارائه دهنده‌ی خدمات شبکه و میزبان استفاده کند و در مراکز داده‌ی آن شرکت سرورهای خود را قرار دهد. در کنار این مزیت‌ها، این معماری معایبی مانند وابسته بودن به پروتکل و استاندارهای وب و افزایش پیچیدگی در فرایند توسعه نیز می‌توانند را به همراه دارد.
معماری مبتنی بر سرویس روشی است که در آن هر خدمتی که توسط سیستم ارائه داده می‌شود به عنوان یک سرویس در نظر گرفته می‌شود. منظور از سرویس‌ها، اجزای کوچکی هستند که هر کدام یک وظیفه را برعهده دارند درون خود یک عملکرد کامل حرفه را دارند. همچنین سرویس‌ها می‌توانند به طور غیرمستقیم با هم در ارتباط باشند و تشکیل یک سیستم بزرگ‌تر را بدهند. اجزا نیز اتصال سست با یکدیگر دارند و ارتباط میان آن‌ها از طریق پروتکل‌ها استاندارد صورت می‌گیرد[2].
شیوه عملکرد این معماری به صورت درخواست و پاسخ است. در تصویر ۳ مشتری یک سرویسی را درخواست می‌دهد و سرویس دهنده به آن درخواست پاسخ مناسب را برمی‌گرداند. شیوه‌ی ارسال درخواست به این صورت است که گیرنده درخواست خود را ابتدا به یک درگاه از طریق سرویس‌های وب ارسال می‌کند. سپس آن درگاه بررسی می‌کند که آیا درخواست ارسال شده قانونی و ارائه دهنده‌ی چنین سرویس درخواستی وجود دارد. در صورتی که درخواست قانونی و ارائه دهنده نیز وجود داشته باشد آنگاه درخواست به سمت سرویس مورد نظر ارسال می‌گردد و ارائه دهنده نیز پس از انجام عملیات و پردازش‌های لازم پاسخ مناسب را به درگاه و آن نیز پاسخ را به گیرنده ارسال می‌کند. در این معماری گذرگاه سرویس سازمان (Enterprise Service Bus(ESB)) به عنوان درگاه تبادل داده نقش بسیار مهمی را ایفا می‌کند، به گونه‌ای که اگر وجود نداشته باشد دیگر به این معماری، یک معماری مبتنی بر سرویس نمی‌توان گفت. ESB درواقع خود یک معماری و مجموعه‌ای از قوانین و مفاهیم برای یکپارچه‌سازی چندین برنامه با یکدیگر از طریق یک زیرساخت گذرگاه است[3]. ESB امکان انتقال داده در لحظه میان سیستم‌ها را فراهم می‌کند، برای درخواست داده و تحویل آن از برنامه‌های واسط مانند SOAP یا REST استفاده می‌کند، به کمک آن می‌توان متناسب با نیاز ساختار داده‌ها را تغییر داد و دسترسی امن به سرویس‌ها و مسیریابی هوشمند داده میان مسیر‌های مورد نظر را کنترل می‌کند.
در تصاویر ۴ الف و ب کارایی و اهمیت وجود یک ESB نشان داده شده است. در این تصاویر فرض شده است که چند برنامه وجود دارند و نیاز است تا این برنامه‌ها با یکدیگر در ارتباط باشند. هر کدام از این برنامه نیز به صورت همزمان یا در فواصل زمانی کمی با یکدیگر تولید نشدند و با فناوری‌های یکسانی هم ممکن است که توسعه داده نشده باشند. در تصویر ۴-الف این شش برنامه به صورت مستقیم به یکدیگر وصل شده‌اند و ارتباط بسیار پیچیده‌ای میان آن‌ها شکل گرفته است. از طرفی برقراری ارتباط میان این برنامه کار ساده‌ای نیست زیرا ساختار یکسانی ندارند و در هر کدام نیاز به تغییرات بسیاری می‌باشد تا بتوان آن‌ها را با یکدیگر متصل کرد و به یکدیگر شناساند. بنابراین اتصال مستقیم چندین برنامه به یکدیگر کار خوب و منطقی بنظر نمی‌آید. از این رو برای ارتباط میان برنامه‌ها از ESB استفاده می‌کنند. در تصویر ۴-ب نشان داده شده است که ارتباط میان برنامه از طریق ESB بسیار منظم شکل گرفته است و همچنین قابلیت توسعه‌پذیری و نگهداری آن نیز ساده‌تر شده است.
گذرگاه سرویس سازمان توسط شرکت‌هایی ارائه می‌شود و سازمان‌ها می‌توانند از این شرکت‌ها خدمات مربوط به ESB را دریافت کنند. از جمله شرکت‌های معروف می‌توان به MuleSoft، Oracel و IBM اشاره کرد.
مزایایی که سرویس‌گرایی در ERP ایجاد می‌کند می‌توان به افزایش مقیاس‌پذیری، انعطاف‌پذیری، کاهش هزینه‌ی یکپارچه‌سازی و افزایش قابلیت استفاده‌ی مجدد سرویس‌ها اشاره کرد. همچنین هزینه‌ی بالای پیاده‌سازی و سربار اضافی برای کنترل سرویس‌ها را می‌توان از معایب آن دانست.
معماری مبتنی بر ابر را می‌توان جدید‌ترین معماری معرفی شده دانست و بسیاری از سازمان‌های ارائه دهنده‌ی ERP امروزه به سمت این معماری رفته‌اند و در کنار ارائه‌ی سیستم‌های مبتنی بر وب و سرویس، حتما یک سیستم ERP مبتنی بر ابر نیز راه اندازی کرده‌اند. در معماری مبتنی بر ابر در محیط سازمان زیرساخت سخت افزاری و نرمافزاری دیگر وجود ندارد و تمام بخش‌های مربوط به سیستم ERP برروی بستر شرکت ارائه‌دهنده‌ی خدمات ابری است و سازمان دیگر خود را درگیر راه‌اندازی یک سیستم ERP نمی‌کند و تنها کافی است که اشتراک استفاده از یک برنامهی ERP را بخرد و سپس می‌تواند از هر جا و در هر لحظه از طریق اینترنت به این سیستم دسترسی داشته باشد. مانند تصویر ۵ که کاربران درون سازمان از طریق اینترنت به یک سیستم ERP متصل هستند که تمام زیرساخت آن در خارج از سازمان می‌باشد و توسط یک شرکت ارائه دهنده‌ی سرویس‌های ابری نگهداری می‌گردد. مزایای این معماری افزایش مقیاس‌پذیری، اطمنیان و امنیت، نگهداری راحت‌تر نرم‌افزار و دسترسی راحت به اطلاعات است. اما مالکیت داده و هزینه‌ای که به صورت ماهیانه یا سالیانه باید پرداخت شود را می‌توان جز معایب این نوع معماری دانست. در بخش بعدی به آشنایی با فضای ابری پرداخته می‌شود تا مشاهده شود که چه امکاناتی را در اختیار کاربران می‌گذارد و دلیل رفتن سازمان‌های ارائه‌دهنده و استفاده کننده‌ی ERP به سمت این فناوری مشخص شود.
فضای ابری یک مدل برای ایجاد دسترسی همگانی، راحت‌تر و براساس تقاضا به یک مجموعه‌ی مشترکی از منابع محاسباتی قابل تنظیم است. طبق تعریف NISTفضای ابری دارای ۵ مشخصه‌ی اصلی است و در سه سطح سرویس می‌دهد [4]. ۵ مشخصه‌ی اصلی عبارت‌اند از:
همچنین سه سرویس که فضای ابری ارائه می‌دهد عبارت است از:
همچنین یک سطح سرویس دیگر نیز به عنوان همه چیز به عنوان سرویس(Anythin as a Service (XaaS)) نیز توسط فضای ابر ارائه می‌شود که در آن تاکید بر ارائه‌ی هر نوع سرویسی بر بستر ابر است مانند: شبکه به عنوان سرویس(Network as a Service (NaaS))، پایگاه داده به عنوان سرویس(Data Base as a Service(DBaaS)).
سازمان‌ها با خرید هر کدام از سه سرویس SaaS، PaaS و IaaS قسمتی از وظایف خود را در بخش مدیریت برنامه، زیرساخت و میان‌افزارها برعهده‌ی ارائه دهندگان سرویس‌های ابری می‌گذارند. در تصویر ۷ نشان داده شده است که اگر یک سیستم به صورت درون سازمانی پیاده‌سازی شود کنترل و مدیریت تمام بخش‌های مختلف آن برعهده‌ی خود سازمان است اما در صورتی که سازمان بخواهد از سطوح سرویس فضای ابری که توسط ارائه دهنده‌ی سرویس ابری ارائه می‌شود استفاده کند آنگاه قسمتی از وظایف خود را به آن‌ها محول می‌کند. به عنوان مثال اگر سازمان از IaaS استفاده کند آنگاه مدیریت قسمت‌های سخت افزاری برعهده‌ی ارائه دهنده‌ی سرویس قرار می‌گیرد. در سطح PaaS کنترل و مدیریت ماشین‌های مجازی و سیستم‌های عامل و میان‌افزارهای برعهده‌ی ارائه دهنده‌ی سرویس است و در نهایت در سطح SaaS نیز تمام قسمت مربوط به یک برنامه به عهده‌ی ارائه دهنده‌ی سرویس قرار می‌گیرد و سازمان تنها انجام تنظیمات و پیکربندی مربوط به برنامه را برعهده دارد.
در فضای ابری با توجه به اینکه یک محیط اشتراکی است و مالکیت داده و زیرساخت مطرح نیست، بنابراین امکان استفاده از فضای ابر برای سازمان‌هایی که اطلاعات مهم و محرمانه‌ای دارند مانند بانک‌ها وجود نخواهد داشت اما به دلیل وجود چنین سازمان‌هایی و اهمیت اطلاعات، برای فضای ابری سطوح دسترسی مختلفی نیز تعریف شده است که شامل سه سطح ابر عمومی، ابر اختصاصی و ابر ترکیبی است.
در ابر عمومی منابع ابری به یک شرکت ارائه دهنده‌ی سرویس ابری تعلق دارد و توسط آن‌ها اداره می‌شود و از طریق اینترنت سرویس ابری ارائه می‌شود و تمام سخت‌افزارها، نرم‌افزارها و زیرساخت‌ها توسط شرکت ارائه دهنده‌ی ابر نگهداری و مدیریت می‌گردد. در ابر اختصاصی، منابع ابری به صورت مشخصی فقط توسط یک کسب و کار یا سازمان استفاده می‌شود. ابر اختصاصی به صورت فیزیکی در محیط داخلی سازمان می‌تواند برپا شود یا در یک شرکت جانبی. در ابر اختصاصی سرویس‌ها و زیرساخت‌ها همیشه برروی شبکه‌ی خصوصی نگهداری می‌شود و سخت‌افزارها و نرم‌افزارها نیز مختص یک سازمان است. بنابراین سازمان‌هایی مانند بانک‌ها که با داده‌های با اهمیت و محرمانه‌ای سر و کار دارند می‌توانند از این سطح دسترسی به سرویس استفاده کنند. ابر ترکیبی را نیز می‌توان ترکیبی از دو ابر عمومی و خصوصی دانست. در این سطح از دسترسی سازمان می‌توان یک از یک ابر اختصاصی برای ذخیره داده‌هایی که از اهمیت زیادی دارند استفاده کنند و برای سایر داده‌های کم اهمیت نیز از ابر عمومی. همچنین این سطح، این امکان را فراهم می‌کند تا داده و برنامه‌ها بین این دو محیط جابجا شوند و با هم در ارتباط باشند.
بنابراین مزایای فراوانی را فضای ابری می‌توان فراهم کند. از جمله‌ی مزایای آن می‌تواند اشتراک راحت‌تر داده و دسترسی به مخاطبان بیشتری باشد، زیرا دسترسی به اطلاعات و برنامه آسان و سریع است. مزیت دیگر آن کاهش هزینه‌های مالی و صرفه‌جویی در زمان است. برای راه‌اندازی یک برنامه نیاز است که زیرساخت‌های آن را فراهم کرد و نیروی انسانی مورد نیاز را هم استخدام کرد. از این روی دیگر نیاز به صرف زمان و هزینه برای خرید سخت‌افزار مناسب و استخدام نیروی متخصص نیست زیرا تمام خدمات زیرساختی و کاربردی توسط شرکت ارائه دهنده‌ی فضای ابری تامین می‌شود. رشد و توسعهی سریع نیز دیگر مزیت این فناوری به حساب می‌آید که در صورت نیاز به راحتی می‌توان سخت‌افزاری را به سیستم موجود اضافه یا از آن حذف کرد یا نرمافزاری را در کمترین زمان بروزرسانی نمود به گونه‌ای که تغییرات اعمال شده برروی سیستم تمام کاربران انجام شود. همچنین منابع سخت‌افزاری و نرمافزاری همیشه بروز هستند زیرا بروز بودن آن‌ها یکی از نگرانی و دغدغه‌های اصلی ارائه دهندگان سرویس‌های ابری است و در صورتی عدم بروزرسانی ممکن است که دچار مشکلات امنیتی و خرابی سخت‌افزارها شوند.
پس رفتن به سمت فضای ابر را می‌توان یک امر اجتناب ناپذیر دانست. شرکت‌هایی هم که امروزه در حوزه‌ی تولید سیستم ERP فعالیت می‌کنند، ساختار سیستم‌های خود را به گونه‌ای تغییر دادند که امروزه امکان استفاده از فضای ابر را داشته باشند. به عنوان مثال شرکت SAP یکی از محصولات خود که Business Oneنام دارد و بر ترکیب دو معماری مبتنی بر سرویس با سه لایه ایجاد شده بود، نسخه‌ی مبتنی بر ابر آن را نیز تولید کرده است تا سازمان‌هایی که می‌خواهند به تازگی از سیستم‌های ERP و امکانات فضای ابر استفاده کنند محصول Business One مبتنی بر ابر را خریداری نمایند . سازمان‌هایی نیز که از نسخه‌های قدیمی سیستم‌های ERP که مبتنی بر وب یا مبتنی بر سرویس استفاده می‌کنند نیز با توجه به مزایای ذکر شده تصمیم به استفاده از سیستم‌های مبتنی بر فضای ابر شده‌اند اما نمی‌توانند به یکباره تمام سیستم قبلی و اطلاعات موجود برروی آن را کنار گذاشت و از یک سیستم جدید مبتنی بر ابر استفاده کنند. از این رو برخی از شرکت‌های ارائه دهنده‌ی خدمات ERP روش‌هایی را برای استفاده از امکانات فضای ابر به سازمان‌هایی که معماری سیستم‌های ERP آن‌ها مبتنی بر وب یا سرویس است پیشنهاد داده‌اند. در بخش بعد به معرفی روش‌هایی پرداخته می‌شود که این امکان را برای سیستم‌های ERP مبتنی بر وب و سرویس فراهم می‌کنند تا سازمان‌هایی که از این نوع سیستم‌ها استفاده می‌کنند نیز بتوانند از برخی امکانات فضای ابر استفاده نمایند.
برای سازمان‌هایی که از سیستم‌های ERP مبتنی بر وب و سرویس استفاده می‌کنند روش‌های مهاجرتی به فضای ابر پیشنهاد شده است که امکان استفاده از برخی امکانات فضای ابر را فراهم می‌سازد. ۶ روش مهاجرت توسط آمازون موسوم به 6Rs معرفی شده است[5]. این ۶ روش برگرفته از مدل 5Rs گروه گارنتر است و عبارت‌اند از [6]:
خرید مجدد: به این روش بنداز و بخر هم می‌گویند. در این روش برنامه به طور کلی کنار گذاشته می‌شود و یک نسخه‌ی مبتنی بر ابر آن خریداری می‌گردد. درواقع شما می‌توانید از برنامه مشابه به عنوان یک سرویس ابری به جای استفاده از برنامهی سنتی که درون سازمان مستقرر می‌شد استفاده نمایید. از مزایای این روش می‌توان به مهاجرت سریع و آسان به سمت فضای ابر اشاره کرد. به عنوان مثال شرکت‌هایی که از Business Oneقدیمی که مبتنی بر سرویس و معماری سه لایه بود می‌توانند نسخه‌ی جدید آن که مبتنی بر ابر است را خریداری نمایند. چون توسعه دهنده و ارائه دهنده‌ی و این محصول شرکت SAP است می‌تواند داده‌های سازمان را به نسخه‌ی جدید نرم‌افزار منتقل نماید. اما در صورتی این روش کاربرد دارد که شما به زیرساخت‌های قبلی نیازی نداشته باشید. به همین جهت برخی از سازمان‌ها ممکن است به زیرساخت‌های قبلی به دلیل هزینه‌هایی که کرده‌اند یا دلایل امنیتی نیاز داشته باشند به همین جهت روش‌های دیگری مانند میزبانی مجدد، سکوی مجدد و معمارای مجدد ارائه شده است که در ادامه این دو روش نیز معرفی می‌شوند.
میزبانی مجدد: این روش به بلند کردن و انتقال دادن نیز معروف است. در میزبانی مجدد برنامه‌ها از محیط داخلی سازمان بدون هیچ تغییری منتقل می‌شود. این روش برای مهاجرت برنامه‌های قدیمی مقیاس بزرگ خوب است و ضمن اینکه ساده‌ترین روش مهاجرت نیز به حساب می‌آید. اما در این روش چون مبتنی بر فضای ابر طراحی نشده است و صرفا برروی فضای ابر قرار می‌گیرد از بسیار امکانات فضای ابری محروم خواهد بود. به عنوان مثال در تصویر ۸ ابتدا معماری اولیه سیستم موجود در سازمان را نشان داده شده است که در محیط داخلی سازمان پیاده‌سازی شده. هنگامی که سازمان تصمیم می‌گیرد که به محیط ابری مهاجرت کند باز همان ساختار حفظ شده و بدون تغییر در فضای ابر مستقر شده است.
سکوی مجدد: این روش به بلند کردن، تعمیر کردن و انتقال دادن معروف می‌باشد و مانند روش میزبانی مجدد است با این تفاوت که در این روش برخی اجزا تغییر می‌کنند و جایگزین می‌شوند تا بتوان از امکانات فضای ابری بیشتر بهره برد. مدت زمان و هزینه‌ی مهاجرت با این روش بیشتر از میزبانی مجدد است و زحمت بیشتری دارد اما این زمینه را می‌توان به کمک این روش فراهم کرد تا از امکانات فضای ابری استفاده کرد. در تصویر ۹ ساختار سیستم ERP موجود پس از مهاجرت به محیط ابری تغییراتی در آن ایجاد شده است. درواقع یک نسخه‌ی مشابه ساختار فعلی ایجاد شده و در کنار ساختار اصلی قرار گرفته تا سیستم بتواند از امکاناتی مانند تعادل بار و پایگاه داده‌ی پشتیبان استفاده کند.
بازسازی/معماری مجدد: این روش پرهزینه و زمان‌برترین روش مهاجرت است که در آن تغییرات اساسی و کامل یک برنامه به منظور انطباق آن با فضای ابر انجام می‌گیرد تا برنامه بتواند از تمام امکانات موجود در فضای ابر استفاده کند. درواقع یک بار دیگر برنامه پیاده‌سازی می‌شود و منجر می‌شود تا برنامه به سرویس‌های مستقل شکسته شود. در این روش نیاز است تا ابتدا برنامه، میان‌افزار و نیازمندی‌های سیستم ERP و همچنین محصولات، سرویس‌ها و ابزارهای در دسترس از سمت ارائه دهنده‌ی ابر شناسایی و بررسی شوند. درواقع پروژه‌ی مهاجرت با ارزیابی برنامه شروع می‌شود سپس فازهای طراحی، معماری، استقرار و تست از دستورالعمل‌ها و اهداف تعیین شده در ارزیابی پیروی می‌کنند. در تصویر ۱۰ معماری سیستم موجود پس از آن که به فضای ابر مهاجرت کرد دیگر از پایگاه داده‌ی قبلی که یک پایگاه داده‌ی رابطه‌ای بود استفاده نکرد بلکه از سرویس پایگاه داده‌ای که توسط خود ارائه دهنده‌ی فضای ابر ارائه می‌شد استفاده نمود و آن را جایگزین پایگاه داده‌ی قبلی نمود. نکته‌ی دیگری که باید به آن اشاره کرد آن است که این روش زمانی مفید است که سازمان نیاز شدیدی به استفاده از ویژگی‌های فضای ابری احساس نماید.
بازنشستگی و نگهداشت: این دو روش به این منظور با هم ذکر شده‌اند که جزو روش‌های منفعل هستند و در آن‌ها هیچ‌گونه عملیات خاصی جهت بردن برنامه به سمت فضای ابری صورت نمی‌گیرد. برخی برنامه‌ها در زمان مهاجرت ممکن است تکراری به نظر بیایند و اضافه باشند و می‌توان کلا آن برنامه ها را حذف کرد یا یک برنامه دیگر پاسخگوی نیاز سازمان نیست و باید کامل کنار گذاشته شود و اصلاحا آن‌ها را بازنشسته کرد. همچنین برخی سازمان‌ها برای راه‌اندازی برنامه هزینه‌های بسیاری کرده‌اند، از نظر مالی، زمانی، منابع انسانی و زیرساخت یا در صورت مهاجرت مزیت رقابتی که در بازار دارند را از دست خواهند داد، از این رو ممکن است که مهاجرت به فضای ابر برای آن‌ها مفید نباشد و تصمیم به حفظ برنامه و ساختار موجود می‌کنند و اصطلاحا از آن برنامه نگهداری می‌کنند.
بنابراین سازمان‌هایی که قصد دارند تا از فضای ابر استفاده نمایند می‌توانند با استفاده از روش‌های مهاجرت میزبانی مجدد، سکوی مجدد و بازسازی مجدد سیستم فعلی خود را که مبتنی بر وب یا سرویس است برروی فضای ابر راه‌اندازی نمایند. استفاده از هر کدام از روش‌های مهاجرتی بستگی به نیازهای سازمان دارد که تا چه حد می‌خواهد از ویژگی‌های فضای ابری استفاده نماید و همچنین به هزینه‌های مالی و زمانی که سازمان در اختیار دارد نیز بستگی دارد. در ادامه به بررسی چند سازمان پرداخته می‌شود که یک سیستم ERP مبتنی بر وب یا سرویس داشته‌اند و بنا به دلیلی که ذکر خواهد شد تصمیم گرفتند که تا به فضای ابری مهاجرت کنند
در این بخش ۳ سازمان مورد بررسی قرار گرفته‌اند که دو مورد از آن‌ها با سیستم ERP مبتنی بر وب و دو دیگر با سیستم ERP مبتنی بر سرویس کار می‌کردند و با توجه به شرایط و نیازهایی که پیش آمد مجبور به مهاجرت به سمت فضای ابر شدند. در ادامه به بررسی هر کدام از سازمان‌ها پرداخته می‌شود و علت و روش مهاجرت آن‌ها توضیح داده می‌شود.
دانشگاه کانزاس در سال ۱۸۶۳ به عنوان اولین دانشگاه اعطایی زمین عملیاتی ملی و اولین مؤسسه‌ی آموزش عالی دولتی تاسیس شد. این دانشگاه بیش از ۱۵۰ سال علوم نظامی، کشاورزی و مهندسی را آموزش می‌دهد. دانشگاه کانزاس در منهتن ایالت کانزاس کشور آمریکا واقع شده است و نزدیک به ۲۴۰۰۰ دانشجو و۴۵۰۰ هیات علمی دارد. این دانشگاه برای مدیریت و کنترل امور مربوط به منابع انسانی خود از ماژول سیستم ERP استفاده می‌کند. سیستم ERP این دانشگاه PeopleSoft نام دارد که برای شرکت Oracel می‌باشد و برخی شرکت‌ها مانند Sierra-Cedar، آن را پیاده‌سازی و پشتیبانی می‌کنند و به گونه‌ای با Oracel همکاری می‌کنند. همچنین معماری این برنامه مبتنی بر وب می‌باشد ]۱۲[ و معماری آن در تصویر ۱۱ آمده است. اجزای تشکیل دهنده‌ی این سیستم مرورگر وب، سرویس‌های وب، سرور زمان‌بندی فرایند، سرور برنامه و سیستم مدیریت پایگاه داده رابطه‌ای()(Relational Data Base Management System(RDBMS)) است. عملکرد این سیستم به این صورت است که کاربر از طریق مرورگر یک درخواستی را در سیستم ثبت می‌کند. این درخواست از طریق سرویس‌های وب به سرور برنامه ارسال می‌گردد. سرور برنامه هسته‌ی مرکزی این معماری به شمار می‌رود، زیرا مسئول اجرای منطق برنامه است و پردازش‌های اصلی در آن صورت می‌گیرد. پس از آن که پردازش لازم برروی داده‌های موجود در RDBMS توسط منطق برنامه انجام شد پاسخ مناسب از طریق سرویس وب سمت مرورگر ارسال می‌گردد تا نتیجه به کاربر نمایش داده شود. سرور زمان‌بندی فرایند نیز شامل برنامه‌هایی است که مانند فایل‌های Batch عمل می‌کنند و به صورت خودکار در زمان‌های مشخصی یک عملیات را انجام می‌دهند. به عنوان مثال عملیات بررسی تراکنش‌ها توسط سرورهای بانک که به صورت خودکار در ساعتی از شب یک گزارش از تمام تراکنش‌های آن روز را بدون دستور و دخالت انسانی آماده می‌کنند.
سیستم ERP ابتدا در خود سازمان قرار گرفته بود. طی یک حادثه‌ای در تاریخ ۲۲ مِی ۲۰۱۸ کتابخانه‌ی دانشگاه دچار آتش سوزی می‌شود و از آنجایی که اتاق مرکز داده در زیرزمین کتابخانه قرار داشت این آتش سوزی سبب شد تا زیرساخت‌های آن‌جا به واسطه‌ی دود و آب زیاد آسیب ببینند و مرکز داده پس از مهار آتش به طور کامل خاموش شوند. راه‌اندازی مجدد آن بسیار زمان‌بر و هزینه‌بر بود و باید یک بار دیگر کارهایی را از اول برای راه‌اندازی مجدد سیستم‌ها انجام می‌دادند. با توجه به آن که مهلت محاسبه‌ی حقوق و دستمزدها و پرداخت آن‌ها نزدیک بود بنابراین زمان کافی و راه‌اندازی مجدد به صورت درون محیطی را نداشتند به همین جهت تصمیم گرفتند به سمت استفاده از فضای ابری بروند. به همین دلیل چون دانشگاه می‌خواست که در کمترین زمان ممکن با داده‌ها و برنامه‌های موجود سیستم خود را در فضای ابری راه‌اندازی کند از این رو متخصصین شرکت Sierra-Cedarروش مهاجرت میزبانی مجدد را پیشنهاد دادند. با استفاده از این روش به مدت ۴۸ ساعت تمام برنامه‌ها و اطلاعات با همان ساختار و معماری که داشتند به فضای ابری AWS (Amazon Web Services) متنقل شدند. این مهاجرت ضمن آن که کمک کرد تا واحد منابع انسانی دانشگاه به هدفش برسد و در مهلت‌های تعیین شده محاسبه و پراخت حقوق و دستمزد را انجام دهند، باعث شد تا امنیت افزایش پیدا کند و پردازش تراکنش برخط(Online Transaction Processing(OLTP)) نیز بهبود یافت. OLTP یک سیستم عملیاتی است که برنامه‌های مبتنی بر تراکنش را در یک معماری سه لایه پشتیبانی می‌کند. این سیستم تراکنش‌های روزانه‌‌ی سازمان را اداره می‌کند و اساسا برروی پردازش پرس‌وجو، حفظ یکپارچگی داده در محیط‌های چند دسترسی و اثر بخشی که توسط تعداد کل تراکنش‌ها در ثانیه اندازه‌گیری می‌شود، تمرکز دارد.
مورد بعدی، شرکتی است که در زمینه‌ی حمل و نقل املاک و مستغلات فعالیت می‌کند و یک رهبر جهانی در حمل و نقل املاک محسوب می‌شود. این شرکت در شهر سن فرانسیسکو کشور آمریکا واقع شده است و حدود ۱۷۰۰ کارمند دارد. همچنین دارای سرمایه‌گذاری در املاک و پروژه‌های توسعه در ۱۹ کشور است. این شرکت برای انجام کارهای مالی خود از ماژول سیستم مالی نرم‌افزار PeopleSoft استفاده می‌کند و تصمیم گرفت تا سیستم ERP موجود را برفضای ابر ببرد تا بتواند از اکثر سرویس‌های فضای ابری بهره ببرد. با توجه به آن که این شرکت هدفش استفاده از امکانات زیرساختی فضای ابر، استفاده از امکانات گزارش‌گیری و افزایش امنیت بود، شرکت Sierra-Cedar روش مهاجرت بازسازی مجدد را پیشنهاد داد و آن را پیاده‌سازی نمود. این مهاجرت نزدیک به ۷ ماه به طول انجامید تا سیستم قبلی بازسازی مجدد گردد و برروی فضای ابری قرار گیرد. پروژه‌ی مهاجرت راه‌حل معماری مجدد شده از ارائه دهنده‌ی میزبان سنتی موجود به AWS در سپتامبر ۲۰۱۹ آغاز شد و در طول بازسازی سایر برنامه‌های سازمان مانند برنامه‌های مالی کمکی شامل Canon OCR و Marketbridge می‌شدند، نیز به فضای ابر منتقل شدند. این رفتن به فضای ابر سبب شد تا قابلیت گزارش‌دهی بهبود یابد، پروتکل‌های سخت امنیتی اجرا شد و یکپارچه‌سازی فنی، امنیتی و کاربردی نیز پیاده‌سازی شد.
سازمان کشتیرانی ایران، یک شرکت ترابری دریایی و کشتیرانی ایرانی است که در سال ۱۳۴۷ تاسیس شد و هم اکنون با دراختیار داشتن ناوگانی از ۱۷۰ فروند کشتی، به عنوان بزرگ‌ترین شرکت خدمات کشتیرانی خاورمیانه محسوب می‌شود. این سازمان از ERP مبتنی بر سرویس استفاده می‌کرده و به دلیل امکان اشتراک راحت‌تر اطلاعات و دسترسی برخی ماژول‌ها برای سازمان‌های زی‌ربط و همچنین استفاده از زیرساخت‌های ابری تصمیم گرفتند که به سمت فضای ابر بروند و ERP خود را در فضای ابر مستقر کنند. در این مهاجرت مواردی مانند ارتباط سازمان با سایر محیط‌های ابری، امکان ارتباط دو طرفه با سایر سازمان‌های بیرونی مانند اداره‌ی بنادر و سازمان بین‌المللی دریانوردی و جلوگیری از پاک شدن داده‌ها بسیار اهمیت داشت که باید در نظر گرفته می‌شد. از آنجایی که سیستم ERP موجود در آن زمان مبتنی بر سرویس بود بنابراین از ESB نیز برخوردار بود. ESB کمک می‌کند تا مهاجرت راحت‌تر صورت گیرد و به دلیل ساختار سرویس‌گرایی که خود فضای ابری دارد کمی آسان‌تر بتوان یک سیستم ERP را برروی فضای ابر قرار داد. در روشی که برای مهاجرت سیستم ERP مبتنی بر سرویس پیشنهاد شد مشابه روش مهاجرت سکوی مجدد است و بیشتر تغییرات جهت سازگاری با محیط ابری برروی ESB انجام می‌گیرد. در روش پیشنهادی برای سازمان کشتیرانی، مهم‌ترین قسمت ESB واسط محاسبات ابری باز
(Open Cloud Computing Interface(OCCI)) است. این قسمت وظیفه‌ی ارزیابی و مدیریت ارتباطات ورودی اولیه از سیستم‌های خارجی به ماژول‌های ERP و بالعکس است را برعهده دارد. در اولین گام، این لایه بررسی می‌کند که درخواست ارتباطی که از سمت سازمان‌های دیگر با ماژول ERP آمده است اولین ارتباط است یا خیر. در صورتی که این درخواست ارتباط برای اولین بار بود برخی اطلاعات مانند نوع سازمان، شناسه‌ی ارتباطی، زمان ارتباط، منبع و مقصد ارتباط جمع می‌شوند. همچنین در این لایه برخی اطلاعات در مورد سازمان‌ها و نوع ارتباط اجازه داده شده برای برقراری ارتباط بعدی نگهداری خواهد شد. این کار سرعت برقراری ارتباط را افزایش می‌دهد. همچنین سطح خطر و امنیت ارتباط را نیز بهبود می‌بخشد. پس از برقراری ارتباط میان دو طرف، سازمان درخواست دهنده و ماژول ERP، داده دریافت می‌شود و بین داده‌های دریافتی و مدل داده‌ی سیستم ممکن است که ناسازگاری وجود داشته باشد. بنابراین داده‌ها به یک لایهی دیگر به نام هستان‌شناسی(Ontology) ارسال می‌گردد. این لایه اطلاعات دریافتی را با مدل داده‌ی سیستم ERP از سه جنبه‌ی ارتباطی، داده‌ای و ذخیره مطابقت می‌دهد. پس از استانداردسازی داده با توجه به استانداردهای فضای ابری و سیستم ERP اطلاعات توسط ESB به ماژول مورد نظر ارسال و سپس پاسخ مناسب سمت سازمان درخواست دهنده برگردانده می‌شود. ساختار روش پیشنهادی برای سازمان کشتیرانی در تصویر ۱۱ آمده است.
این روش مهاجرت و پیاده‌سازی ERP در فضای ابری ضمن اینکه امکان برقرار با سایر فضاهای ابری را فراهم کرد سبب شد تا از سایر امکانات موجود در فضای ابر و مزیت‌های آن استفاده کنند. یکی از این امکانات، استفاده از سرویس‌های امنیتی آن بود و آن‌ها را در ERP تعبیه نمودند. به عنوان مثال توانستند از مدل امنیتی AAA (احراز هویت (Authorization)، کنترل دسترسی(Authentication) و حسابرسی (Accounting)) استفاده کنند. مدل امنیتی AAA، درواقع یک چارچوب است که دسترسی به منابع کامپیوتری را کنترل، سیاست‌های را اجرا و استفاده را ممیزی می‌کند. این مدل نقش اصلی در مدیریت شبکه و امنیت سایبری را به وسیله‌ی نظارت کاربران و ردیابی فعالیت‌های آنان در زمانی که متصل هستند به شبکه، ایفا می‌کند.
دستاورد دیگری که در روش پیشنهادی حاصل شد مدیریت و توزیع بهتر پایگاه‌های داده است، همچنین زیرساخت را برای ایجاد سیستم پردازش تحلیلی برخط (Online Analytics Processing(OLAP)) آماده کردند. OLAP یک فناوری است که سامان دادن حجم وسیع پایگاه‌های داده‌ی حرفه استفاده می‌شود و از هوش تجاری پیشتیبانی می‌کند. یکی دیگر از مزیت‌ها افزایش دسترس‌پذیری بود که با توجه به کارهای انجام شده سایر سازمان‌ها و افراد سازمان در صورت داشتن مجوز می‌توانند به سیستم و داده‌ها سریع و آسان دسترسی داشته باشند. همچنین متخصصانی که این روش را ارائه دادند به منظور مشاهده‌ی تاثیر این کار و میزان رضایت کاربران، یک نظر سنجی نیز در سازمان انجام دادند. برای ارزیابی معماری سیستم از روش ATAM
(Architecture Tradeoff Analysis Method) استفاده نمودند. این روش برای ارزیابی ویژگی‌های کیفی معماری‌های نرمافزاری استفاده می‌شود. این روش به استخراج مجموعه‌ای از نیازمندی‌های کیفی همراه چند بعد، تحلیل اثرات هر نیازمندی به تنهایی و سپس فهم تعامل این نیازمندی‌ها با یکدیگر کمک می‌کند. در تصویر ۱۲ درختی نمایش داده می‌شود که ویژگی‌های کیفی سیستم ERPمورد نظر است. در این درخت دو ویژگی است مد نظر است: یکپارچگی و نگهداری. هر کدام از این دو ویژگی خود با چند پارامتر دیگر سنجیده می‌شوند که در تصویر آمده است. در گره‌های برگ نیز معیارهایی نمایش داده شده است هر زیرویژگی را تعریف می‌کنند. هر
معیار از دو جنبه‌ی اولویت و سختی استفاده مورد بررسی قرار می‌گیرد.
موارد موجود در درخت تصویر ۱۲، درواقع حاصل ایده‌ی متخصصان حوزه در صنعت حمل و نقل است. سپس یک پرسشنامه براساس درخت ساخته شده تهیه کردند و در اختیار متخصصان گذاشتند و نظر هر کدام را پرسیدند. پس از جمع‌آوری پرسشنامه‌ها، پاسخ‌ها را با استفاده از روش TOPSIS تحلیل کردند. نتیجه‌ی این تحلیل در تصویر ۱۳ نشان داده شده است. در این جدول ستون‌های افقی کم رنگ معیار اول و ستون‌های افقی پررنگ معیار دوم از هر زیرویژگی را نشان می‌دهند. خروجی حاصل از این تحلیل آن شد که روش پیشنهادی تاثیر زیادی بر افزایش سرعت تعامل و همکاری میان سیستم ERP سازمان کشتیرانی با سیستم‌های نرمافزاری که مستقل از این سازمان‌اند، دارد. همچنین در تعامل با آن‌ها امنیت و دسترس‌پذیری نیز افزایش می‌یابد.
در ایران نیز شرکت همکاران سیستم که در حوزه‌ی تولید سیستم ERP بسیار فعال است و مدت‌ها است که در این حوزه فعالیت می‌کند، سیستمی به نام راهکاران ابری را معرفی نموده و در حال حاضر شرکت‌هایی مانند دنا بهریز، سرام آرا در حال استفاده از این سیستم هستند. شرکت دنا بهریز در سال ۱۳۹۵ در منطقه‌ی تاکستان قزوین و با هدف تولید انواع سرسیلندر خورد به روش ریخته‌گری و ماشین‌کاری آغاز کرد. این شرکت در سال ۱۳۹۶ با توجه به رشدی که داشت و تثبیت آن در بازار تصمیم گرفت که به سمت استفاده از سیستم ERP برود و در سال ۱۳۹۷ اقدام به خرید سیستم ERP راهکاران ابری نمود و دلیل خرید چنین محصولی پوشش جغرافیایی وسیع میان کارخانه و دفتر مرکزی (واقع در تهران) و کاهش هزینه زیرساخت بود. شرکت دیگری که به سمت ERP ابری شرکت همکاران سیستم رفت شرکت سرام آرا بود. این شرکت یکی از بزرگ‌ترین شرکت‌های تولید کننده کاشی و سرامیک در کشور است و در سال ۱۳۸۲ در این زمینه فعالیت می‌کند و در حال حاضر ۱۶۰ نفر کارمند دارد. این شرکت از ماژول حسابداری همکاران استفاده می‌کند و تجربه‌ی کار با اولین نسل‌های نرم‌افزار ERP شرکت همکاران سیستم را دارد و نرمافزارهای دلفی همکاران سیستم مدت‌ها پاسخگوی نیازها این مجموعه بوده است. طبق گفته‌ی مدیر مالی شرکت، به دلیل پیچیدگی‌های نگهداری از زیرساخت و بروزرسانی آن تصمیم به استفاده از سیستم راهکاران ابری گرفتند. از مزایایی که این سیستم برای شرکت به همراه داشته است می‌توان به موضوع کاهش هزینه‌های تجهیز و نگهداری زیرساخت اشاره کرد که این مسئولیت به طور کامل به عهده‌ی شرکت همکاران سیستم قرار گرفته است. همچنین استفاده از این سیستم سبب شد تا دسترس‌پذیری بیشتری را تجربه کنند و مدیریت حتی در زمانی که مرخصی است بتواند موضوعات کاری را کنترل نماید و این ویژگی در شرایط کرونایی بسیار به این شرکت کمک کرد.
با توجه به دو شرکت بررسی شده که به سمت سیستم راهکاران ابری رفتند، بنظر می‌رسد که شرکت‌هایی که به تازگی به سمت استفاده از سیستم ERP می‌روند از همان ابتدا محصول ابری راهکاران را خریداری می‌کنند و شرکت‌هایی که از سرویس‌های قدیمی همکاران سیستم که مبتنی بر وب یا سرویس باشد نیز محصول قبلی را کنار می‌گذارند و به سراغ محصول جدید که مبتنی بر ابر است می‌روند و نسخه‌ی ابری همان محصول را استفاده می‌کنند. درواقع به نوعی از روش مهاجرت خرید مجدد استفاده می‌کنند و از آنجایی که سیستم ERP قبلی نیز برای خود همکاران سیستم می‌باشد بنابراین تمام اطلاعات و داده‌های آن شرکت بدون مشکل به سیستم جدید منتقل می‌شود و از بابت انتقال داده نگرانی نخواهند داشت. اما در موارد بررسی شده اشاره‌ای به سایر روش‌های مهاجرتی مانند روش معماری مجدد، سکوی مجدد و میزبانی مجدد دیده نشد. البته شرکت‌هایی مانند شرکت گوهر شفا هستند که از نرمافزارهای ERPخارجی استفاده می‌کردند و به دلایل شرایط تحریم مجبور به تغییر سیستم خود شدند و از این رو سیستم ERP راهکاران ابری را انتخاب نمودند و در داستان موفقیت این شرکت اشاره به روش مهاجرت به فضای ابر نشد و بنظر می‌رسد که این شرکت نیز تنها از داده‌ها و اطلاعات خود پشتیبان گرفته و در اختیار متخصصان همکاران سیستم قرار داده است تا آن‌ها را به سیستم راهکاران ابری منتقل نمایند.
بنابراین می‌توان گفت که شرکت‌های کوچک و متوسطی که از نرمافزارهای ERP مبتنی بر وب یا سرویس که در محیط داخلی سازمان قرار دارند، بخواهند به سمت فضای ابر بروند راه‌حلی که دارند تنها خرید مجدد یک محصول مبتنی بر ابر می‌باشد.
با توجه به این شرایط می‌توان شرکت‌های پشتیبانی از محصول ERP ایجاد شوند تا وظیفه‌ی مهاجرت سیستم با معماری و ساختار فعلی بر فضای ابر را برعهده‌ی آنان گذاشت. البته این کار نیازمند آماده بودن شرایط و امکانات ارائه دهنده‌ی خدمات ابری نیز می‌باشد. همانگونه که شرکت Sierra-Cedar با شرکت Oracel در پشتیبانی و توسعهی محصول PeopleSoft همکاری می‌کند و در صورت نیاز یکی از سازمان‌های این نرم‌افزار را برروی یکی از فضاهای ابری AWS یا Oracel با توجه به امکاناتی که این فضاهای ابری می‌دهد بنا کند. در ایران یک شرکت یا حتی خود مجموعه‌ی همکاران سیستم می‌تواند وظیفه‌ی پشتیبانی از محصول ERP ارائه شده را برعهده بگیرد و آن را در صورت نیاز سازمان به فضای ابری خود همکاران سیستم به یکی از روش‌های سکوی مجدد، معماری مجدد یا میزبانی مجدد انتقال دهند. البته در مورد فضای ابری شرکت ابرآروان نیز می‌تواند گزینه‌ی مناسبی باشد البته به شرط آنکه امکانات و ابزار مورد نیاز برای انتقال را فراهم نماید همانگونه که AWS به واسطه‌ی امکاناتی که در اختیار توسعه دهندگان قرار می‌دهد فرایند مهاجرت را بسیار ساده و قسمتی از کارها را خودکار کرده است.
بسیاری از سازمان‌ها به واسطه‌ی پیچیدگی فرایند‌ها موجود در سازمان، کنترل و مدیریت آن‌ها به سمت استفاده سیستم‌های ERP رفته‌اند. سیستم‌های ERPنیز، سیستم‌های نرمافزاری هستند که ساختار و معماری خاصی دارند و متناسب با نیازمندی‌ها و فناوری‌های مورد نیاز سیستم معماری آن انتخاب شود. امروزه فناوری محاسبات ابری بسیار مورد توجه قرار گرفته است و اکثر سازمان‌ها به سمت استفاده آن به واسطه‌ی مزیت‌هایی مانند کاهش هزینه‌ی‌های زیرساختی، عدم درگیر شدن با پیچیدگی‌های راه‌اندازی، توسعه و نگهداشت زیرساخت، توسعهی سریع سیستم و دسترسی سریع و آسان به نرم‌افزار و اطلاعات سوق پیدا کرده‌اند. از این رو شرکت‌های ارائه دهنده خدمات ERP نیز معماری مبتنی بر فضای ابری را برای سیستم‌های ERP خود بکار برده‌اند تا بتوانند از تمام امکانات فضای ابری استفاده کنند. اما شرکت‌هایی که از گذشته از سیستم‌های ERP استفاده می‌کردند که معماری آن‌ها مبتنی بر وب یا سرویس بود و در محیط داخلی خود سازمان آن را مستقر کرده بودند، برای آن که بخواهند از امکانات فضای ابری استفاده کنند لازم است تا از روش‌های مهاجرتی برنامه‌ها به فضای ابری استفاده کنند. این روش‌ها شامل خرید مجدد، میزبانی مجدد، سکوی مجدد و معماری مجدد می‌باشد. در خرید مجدد محصول قدیمی به طور کلی کنار گذاشته می‌شود و نسخه‌ی جدید همان محصول که مبتنی بر ابر است خریداری می‌گردد. در میزبانی مجدد، معماری برنامهی موجود حفظ می‌شود و بدون تغییر در محیط ابری مستقر می‌گردد. سکوی مجدد نیز همانند میزبانی مجدد است اما برای استفاده از برخی ویژگی‌ها و سرویس‌های ابری در معماری سیستم موجود تغییراتی انجام می‌شود. در معماری مجدد نیز معماری برنامهی موجود به طور کلی تغییر می‌کند و با توجه به نیازهای برنامه و امکاناتی که ارائه دهنده‌ی سرویس‌های ابری ارائه می‌کند معماری برنامه تبیین می‌شود. نکته‌ای که در استفاده از روش‌های مهاجرتی تعیین کننده است، میزان نیاز سازمان به امکانات فضای ابری و همچنین زمان و هزینه‌ای است که می‌خواهد صرف انتقال برنامهی موجود در سازمان به فضای ابری نماید.
در مهاجرت سیستم‌های ERP مبتنی بر وب برای آنکه بتوان آن را با امکانات فضای ابری منطبق کرد باید از روش سکوی مجدد یا معماری مجدد استفاده کرد و نسبت به مهاجرت سیستم‌های ERP مبتنی بر سرویس زحمت بیشتری می‌توان گفت که دارد. به طور کلی انتقال سیستم از یک محیط داخلی به فضای ابر بسیار پر زحمت و زمان‌بر است اما این مورد در ERP مبتنی بر وب نسبت به مبتنی بر سرویس بنظر بیشتر می‌آید. دلیل آن هم، ساختار معماری سرویس‌گرا است و ساختار فضای ابری می‌باشد. فضای ابری خود از یک معماری مانند معماری سرویس‌گرا پیروی می‌کند و در آن هر خدمت به صورت سرویس ارائه می‌شود و در ERP مبتنی بر سرویس نیز به کمک وجود ESB سرویس مورد نیاز را می‌توان از سرویس دهنده‌ی فضای ابری تقاضا کرد و آن را در سیستم خود بکار برد.
در تمامی کارهای بررسی شده که سیستم ERP مبتنی بر وب یا سرویس خود را با موفقیت در فضای ابری مستقر کردند، سازمان‌ها بسیار راضی بودند و در تمامی موارد مشاهده شد که هزینه‌ها کاهش یافته و دسترسی‌پذیری و امنیت افزایش یافته است. بنابراین به دلیل مزایا و فرصت‌هایی که فضای ابری برای کاربران و سازمان‌ها فراهم می‌کند مهاجرت به این فضا را می‌توان امری ضروری دانست.
