چک‌لیست مهاجرت بدون از دست رفتن اطلاعات؛ راهنمای انتقال اطلاعات از نرم افزار قدیمی به ERP

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

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

چگونه اطلاعات را منتقل کنیم که هیچ داده مهمی از بین نرود، ناقص نشود یا در ساختار جدید اشتباه قرار نگیرد؟

پاسخ این سؤال، یک فرآیند مرحله‌ای و کنترل‌شده است؛ نه یک عملیات ساده Export و Import.

در واقع، انتقال اطلاعات از نرم‌افزار قدیمی به ERP باید مانند یک پروژه مستقل مدیریت شود و برای آن برنامه، مسئول، معیار کنترل، نسخه پشتیبان، انتقال آزمایشی و تأیید نهایی وجود داشته باشد.

در این راهنما یک چک‌لیست کاربردی و اجرایی ارائه می‌کنیم که می‌تواند برای شرکت‌هایی که قصد مهاجرت به Odoo یا سایر ERPها را دارند، به‌عنوان چارچوب اولیه پروژه مورد استفاده قرار گیرد.

🔹 قبل از هر چیز؛ منظور از «از دست رفتن اطلاعات» چیست؟

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

در یک پروژه مهاجرت، اطلاعات ممکن است به چند شکل دچار آسیب شوند.

❌ حذف کامل داده

برای مثال بخشی از مشتریان یا فاکتورهای قدیمی اصلاً منتقل نشوند.

❌ ناقص شدن داده

رکورد مشتری منتقل شود اما شماره تماس، آدرس یا اطلاعات مالی آن از بین برود.

❌ تغییر اشتباه داده

مثلاً مبلغ یک فاکتور یا موجودی یک کالا پس از انتقال با مقدار واقعی تفاوت داشته باشد.

❌ از بین رفتن ارتباط بین داده‌ها

ممکن است مشتری منتقل شود، فاکتور نیز منتقل شود، اما فاکتور دیگر به مشتری صحیح متصل نباشد.

❌ تغییر ساختار داده

مثلاً یک محصول در سیستم قبلی یک واحد اندازه‌گیری داشته باشد اما در ERP با واحد دیگری ثبت شود.

❌ از بین رفتن سوابق

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

بنابراین هدف واقعی پروژه فقط این نیست که:

تعداد رکوردهای قبل و بعد برابر باشد.

بلکه باید مطمئن شویم:

داده کامل، صحیح، مرتبط، قابل استفاده و قابل ردیابی منتقل شده است.

🟢 چک‌لیست کلی مهاجرت بدون از دست رفتن اطلاعات

برای اینکه مسیر پروژه روشن باشد، می‌توان فرآیند را در ۱۰ مرحله اصلی تقسیم کرد:

• تعیین محدوده اطلاعات قابل انتقال

• شناسایی تمام منابع اطلاعاتی

• تهیه نسخه پشتیبان

• تهیه Snapshot یا نسخه مرجع

• بررسی کیفیت و ساختار داده

• پاک‌سازی اطلاعات

• طراحی Data Mapping

• اجرای انتقال آزمایشی

• اعتبارسنجی داده‌های منتقل‌شده

• انتقال نهایی و کنترل پس از Go-Live

هر کدام از این مراحل باید قبل از رفتن به مرحله بعدی تا حد قابل قبول تأیید شوند.

🔹 مرحله اول؛ دقیقاً مشخص کنید چه اطلاعاتی باید منتقل شوند

یکی از اولین اشتباهات مهاجرت این است که سازمان از ابتدا تصمیم بگیرد:

«همه اطلاعات را منتقل می‌کنیم.»

این تصمیم همیشه درست نیست.

قبل از هر انتقال باید اطلاعات را دسته‌بندی کرد.

اطلاعات پایه

• مشتریان

• تأمین‌کنندگان

• محصولات

• دسته‌بندی محصولات

• واحدهای اندازه‌گیری

• کاربران

• کارکنان

• حساب‌ها

• مالیات‌ها

اطلاعات عملیاتی

• سفارش‌های فروش

• سفارش‌های خرید

• موجودی کالا

• سفارش‌های تولید

• پروژه‌های فعال

• قراردادهای فعال

• مطالبات

• بدهی‌ها

اطلاعات تاریخی

• فاکتورهای قدیمی

• اسناد مالی

• سوابق خرید

• سوابق فروش

• تراکنش‌های مشتریان

• سوابق انبار

اطلاعات آرشیوی

• فایل‌های قدیمی

• گزارش‌های سنوات قبل

• اطلاعات غیرفعال

• داده‌های مورد نیاز برای مراجعه قانونی یا حسابرسی

در این مرحله باید مشخص شود که هر دسته در یکی از این سه وضعیت قرار می‌گیرد:

انتقال به ERP

نگهداری به‌صورت آرشیو

حذف پس از تأیید و مطابق سیاست سازمان

🔹 مرحله دوم؛ تمام منابع اطلاعاتی را شناسایی کنید

اطلاعات شرکت الزاماً فقط در یک نرم‌افزار قرار ندارد.

ممکن است بخشی در نرم‌افزار حسابداری باشد، بخشی در CRM، بخشی در Excel و حتی بخشی در فایل‌های متنی یا سیستم‌های جانبی.

بنابراین باید یک فهرست کامل تهیه شود.

برای مثال:

این فهرست کمک می‌کند هیچ منبع اطلاعاتی در پروژه فراموش نشود.

🔹 مرحله سوم؛ قبل از هر کاری Backup بگیرید

این مرحله ساده به نظر می‌رسد اما از مهم‌ترین بخش‌های پروژه است.

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

اگر اطلاعات در دیتابیس قرار دارند، Backup دیتابیس تهیه شود.

اگر اطلاعات در فایل‌های Excel هستند، نسخه اصلی فایل‌ها بدون تغییر نگهداری شود.

اگر سیستم امکان تهیه Backup کامل دارد، نسخه کامل و قابل بازیابی تهیه شود.

اصل مهم این است:

نسخه اصلی اطلاعات نباید در فرآیند پاک‌سازی مستقیماً تغییر کند.

بهتر است ساختار به این شکل باشد:

Original Data

⬇️

Working Copy

⬇️

Cleaned Data

⬇️

Migration Data

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

🔹 Backup فقط گرفتن فایل نیست

بعضی شرکت‌ها Backup تهیه می‌کنند اما هرگز بررسی نمی‌کنند که آیا واقعاً قابل بازیابی است یا خیر.

این کار خطرناک است.

یک نسخه پشتیبان زمانی ارزشمند است که:

قابل بازیابی باشد.

بنابراین بهتر است قبل از شروع مهاجرت مشخص شود:

• Backup کجا نگهداری می‌شود؟

• چه کسی مسئول آن است؟

• تاریخ Backup ثبت شده است؟

• آیا Backup کامل است؟

• آیا امکان Restore آزمایشی وجود دارد؟

• آیا نسخه دوم Backup وجود دارد؟

• دسترسی به Backup محدود و امن است؟

برای پروژه‌های حساس، نگهداری چند نسخه پشتیبان در محل‌های متفاوت نیز می‌تواند ریسک را کاهش دهد.

🔹 مرحله چهارم؛ یک نسخه مرجع از اطلاعات ایجاد کنید

بعد از Backup باید یک Baseline یا نسخه مرجع ایجاد شود.

برای مثال قبل از مهاجرت ثبت کنید:

تعداد مشتریان: ۱۲,۵۰۰

تعداد محصولات: ۸,۴۰۰

تعداد فاکتورهای سال جاری: ۳۲,۸۰۰

موجودی کل: X

مانده حساب مشتریان: Y

مانده حساب تأمین‌کنندگان: Z

این اعداد بعداً برای کنترل نتیجه مهاجرت استفاده می‌شوند.

به این ترتیب، بعد از انتقال می‌توان بررسی کرد:

آیا تعداد مشتریان برابر است؟

آیا موجودی تغییر کرده؟

آیا مانده حساب‌ها قابل تطبیق هستند؟

آیا فاکتورهای ضروری منتقل شده‌اند؟

این روش بسیار بهتر از بررسی تصادفی چند رکورد است.

🔹 مرحله پنجم؛ کیفیت اطلاعات را بررسی کنید

قبل از انتقال باید کیفیت داده‌ها مشخص شود.

برای مثال در فهرست مشتریان بررسی کنید:

• مشتریان تکراری وجود دارند؟

• نام مشتریان استاندارد است؟

• شماره تلفن‌ها معتبر هستند؟

• کدهای شناسایی کامل هستند؟

• آدرس‌ها ناقص هستند؟

• مشتریان غیرفعال مشخص شده‌اند؟

• چند رکورد برای یک مشتری وجود دارد؟

برای محصولات نیز:

• کد محصول یکتا است؟

• نام محصول استاندارد است؟

• واحد اندازه‌گیری مشخص است؟

• دسته‌بندی محصول درست است؟

• محصولات غیرفعال مشخص شده‌اند؟

• محصولات تکراری وجود دارند؟

این مرحله همان جایی است که مشخص می‌شود داده‌های شرکت واقعاً چقدر برای مهاجرت آماده هستند.

🔹 مرحله ششم؛ داده‌های تکراری را پاک کنید

فرض کنید در سیستم قبلی سه مشتری وجود دارند:

شرکت بازرگانی نوین

بازرگانی نوین

شرکت نوین

اگر هر سه رکورد متعلق به یک مجموعه باشند، انتقال آنها به ERP می‌تواند باعث ایجاد چند حساب مستقل برای یک مشتری شود.

همین مسئله درباره محصولات نیز رخ می‌دهد.

برای مثال:

پیچ M10

پیچ متری M10

پیچ سایز ۱۰

ممکن است سه رکورد متفاوت برای یک محصول باشند.

بنابراین قبل از انتقال باید قوانین تشخیص رکوردهای تکراری مشخص شوند.

🔹 مرحله هفتم؛ استانداردسازی داده‌ها

پاک‌سازی فقط حذف رکوردهای تکراری نیست.

داده‌ها باید در قالبی استاندارد قرار گیرند.

مثلاً شماره تلفن‌ها ممکن است به شکل‌های مختلف ثبت شده باشند:

09121234567

0912-123-4567

+989121234567

یا حتی با فاصله و کاراکترهای اضافی.

اگر ERP به قالب استاندارد نیاز داشته باشد، باید این داده‌ها قبل از انتقال یکسان‌سازی شوند.

همین موضوع درباره:

• تاریخ

• واحد اندازه‌گیری

• کد محصول

• کد مشتری

• کد ملی

• کد اقتصادی

• شماره حساب

• شماره تماس

نیز می‌تواند مطرح باشد.

🔹 مرحله هشتم؛ Data Mapping طراحی کنید

حالا باید مشخص شود هر داده در ERP کجا قرار می‌گیرد.

این مرحله بسیار مهم است.

مثلاً:

اما Mapping واقعی بسیار پیچیده‌تر از این مثال ساده است.

برای اطلاعات مالی و تراکنش‌ها باید وابستگی‌ها نیز در نظر گرفته شوند.

برای مثال:

فاکتور → مشتری + محصول + مالیات + حساب + تاریخ + مبلغ

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

🔹 مرحله نهم؛ ترتیب انتقال اطلاعات را مشخص کنید

نمی‌توان همه اطلاعات را به هر ترتیبی وارد ERP کرد.

برخی اطلاعات به داده‌های دیگر وابسته‌اند.

به‌عنوان یک الگوی عمومی می‌توان چنین ترتیبی را در نظر گرفت:

مرحله اول

• شرکت‌ها

• کاربران

• مشتریان

• تأمین‌کنندگان

• محصولات

• دسته‌بندی‌ها

• واحدهای اندازه‌گیری

مرحله دوم

• حساب‌ها

• مالیات‌ها

• شرایط پرداخت

• انبارها

• مکان‌ها

• قیمت‌ها

مرحله سوم

• موجودی اولیه

• مانده حساب‌ها

• مطالبات

• بدهی‌ها

مرحله چهارم

• سفارش‌های باز

• قراردادهای فعال

• پروژه‌های فعال

• سفارش‌های خرید

• سفارش‌های فروش

مرحله پنجم

• اطلاعات تاریخی مورد نیاز

ترتیب واقعی باید با توجه به ساختار ERP و فرآیندهای سازمان تعیین شود.

🔹 مرحله دهم؛ انتقال آزمایشی انجام دهید

یکی از مهم‌ترین اصول:

هرگز اولین انتقال نباید انتقال نهایی باشد.

ابتدا یک نمونه کوچک منتقل کنید.

مثلاً:

• ۱۰۰ مشتری

• ۵۰۰ محصول

• ۱۰۰ فاکتور

• بخشی از موجودی

سپس کاربران کلیدی آن را بررسی کنند.

اگر مشکلی وجود دارد، Mapping یا داده‌ها اصلاح شوند.

بعد دوباره انتقال آزمایشی انجام شود.

این چرخه می‌تواند چند بار تکرار شود.

🔹 انتقال آزمایشی را چه کسانی باید بررسی کنند؟

فقط برنامه‌نویس یا تیم IT کافی نیست.

بهتر است نمایندگان واحدهای مختلف حضور داشته باشند.

مالی

صحت مانده‌ها، فاکتورها و اسناد را بررسی کند.

فروش

مشتریان، سفارش‌ها و قیمت‌ها را کنترل کند.

انبار

محصولات و موجودی را بررسی کند.

خرید

تأمین‌کنندگان و سفارش‌های خرید را بررسی کند.

مدیریت

گزارش‌های مهم را کنترل کند.

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

🔹 مرحله یازدهم؛ کنترل تعداد رکوردها

یکی از ساده‌ترین کنترل‌ها، مقایسه تعداد رکوردهاست.

برای مثال:

اما این فقط یک کنترل اولیه است.

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

🔹 مرحله دوازدهم؛ کنترل محتوای رکوردها

باید تعدادی رکورد به‌صورت نمونه انتخاب و مقایسه شوند.

مثلاً یک مشتری را انتخاب کنید و بررسی کنید:

نام

کد

شماره تماس

آدرس

اطلاعات مالی

در سیستم قدیمی و ERP برابر هستند یا خیر.

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

🔹 مرحله سیزدهم؛ کنترل جمع‌های مالی

در پروژه‌های ERP، این مرحله بسیار مهم است.

فرض کنید:

جمع مطالبات در سیستم قدیمی = ۵۰ میلیارد تومان

بعد از انتقال:

جمع مطالبات در ERP = ۴۹.۷ میلیارد تومان

این اختلاف باید قبل از Go-Live مشخص و اصلاح شود.

کنترل‌هایی مانند:

• جمع بدهکار

• جمع بستانکار

• مانده مشتریان

• مانده تأمین‌کنندگان

• موجودی کالا

• جمع فروش

• جمع خرید

• مالیات

باید بر اساس نیاز سازمان انجام شوند.

🔹 مرحله چهاردهم؛ کنترل موجودی انبار

یکی از داده‌های حساس، موجودی کالا است.

فرض کنید سیستم قبلی می‌گوید:

محصول A = ۱۲۰ عدد

اما ERP نشان می‌دهد:

محصول A = ۱۱۵ عدد

باید علت مشخص شود.

اختلاف موجودی ممکن است به دلیل:

• ثبت تراکنش جدید

• اشتباه در واحد اندازه‌گیری

• انتقال ناقص

• رکورد تکراری

• تفاوت تاریخ Snapshot

• اشتباه در Mapping

باشد.

بنابراین موجودی باید در یک نقطه زمانی مشخص Freeze یا ثبت مرجع شود.

🔹 Freeze Point چیست؟

در پروژه مهاجرت باید یک نقطه زمانی مرجع مشخص شود.

مثلاً:

پنجشنبه ساعت ۲۳:۵۹

از این زمان به بعد اطلاعات سیستم قدیمی دیگر نباید بدون ثبت در برنامه مهاجرت تغییر کنند.

به این نقطه می‌توان به‌عنوان Freeze Point نگاه کرد.

سپس:

اطلاعات تا Freeze Point → استخراج

و

تراکنش‌های بعد از آن → طبق برنامه انتقال نهایی

مدیریت می‌شوند.

این موضوع برای شرکت‌هایی که عملیات روزانه زیادی دارند بسیار مهم است.

🔹 مرحله پانزدهم؛ انتقال اطلاعات باز را فراموش نکنید

گاهی سازمان تاریخچه را منتقل می‌کند اما تراکنش‌های باز را فراموش می‌کند.

برای مثال:

• سفارش فروش هنوز تحویل نشده.

• سفارش خرید هنوز دریافت نشده.

• مشتری هنوز بدهکار است.

• پروژه هنوز تمام نشده.

• قرارداد هنوز فعال است.

این اطلاعات باید بخشی از برنامه Migration باشند.

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

🔹 مرحله شانزدهم؛ برای اطلاعات تاریخی تصمیم بگیرید

یکی از تصمیمات مهم پروژه این است که آیا تاریخچه کامل به ERP منتقل شود یا خیر.

سه روش متداول وجود دارد:

روش اول؛ انتقال کامل

تمام تاریخچه به ERP منتقل می‌شود.

مزیت:

دسترسی یکپارچه به سوابق.

عیب:

زمان و هزینه بیشتر.

روش دوم؛ انتقال خلاصه

فقط اطلاعات مورد نیاز برای ادامه عملیات منتقل می‌شود.

مزیت:

مهاجرت سریع‌تر.

عیب:

جزئیات تاریخچه ممکن است در ERP موجود نباشد.

روش سوم؛ ERP + Archive

اطلاعات عملیاتی به ERP منتقل می‌شوند و تاریخچه در سیستم قبلی به‌صورت آرشیو نگهداری می‌شود.

این روش در بسیاری از پروژه‌ها می‌تواند تعادل مناسبی بین دسترسی و پیچیدگی ایجاد کند.

🔹 مرحله هفدهم؛ اطلاعات سیستم قدیمی را بلافاصله حذف نکنید

پس از Go-Live بهتر است سیستم قدیمی برای مدتی در حالت آرشیوی باقی بماند.

اما باید مشخص باشد:

ERP سیستم عملیاتی جدید است.

سیستم قبلی صرفاً برای مراجعه به سوابق استفاده می‌شود.

اگر کاربران بعد از Go-Live همچنان اطلاعات جدید را در نرم‌افزار قبلی وارد کنند، سازمان دوباره به مشکل جزیره‌های اطلاعاتی بازمی‌گردد.

🔹 مرحله هجدهم؛ امنیت اطلاعات را جدی بگیرید

اطلاعات مهاجرت ممکن است شامل اطلاعات بسیار حساس سازمان باشد.

برای مثال:

• اطلاعات مالی

• اطلاعات مشتریان

• اطلاعات کارکنان

• قیمت‌های خرید

• قراردادها

• اطلاعات حساب‌ها

بنابراین فایل‌های انتقال نباید بدون کنترل روی سیستم‌های مختلف جابه‌جا شوند.

بهتر است:

• دسترسی افراد محدود باشد.

• فایل‌های حساس رمزگذاری یا محافظت شوند.

• دسترسی به Backup کنترل شود.

• فایل‌های موقت پس از اتمام پروژه مدیریت شوند.

• مسئولیت دسترسی‌ها مشخص باشد.

🔹 مرحله نوزدهم؛ برنامه Rollback داشته باشید

یکی از مهم‌ترین مواردی که گاهی فراموش می‌شود:

اگر Go-Live با مشکل جدی مواجه شد چه کنیم؟

برای این وضعیت باید برنامه بازگشت وجود داشته باشد.

مثلاً:

اگر در ساعات اولیه راه‌اندازی مشخص شد فرآیند حیاتی فروش یا انبار به‌درستی کار نمی‌کند، چه تصمیمی گرفته می‌شود؟

چه کسی تصمیم می‌گیرد؟

تا چه زمانی امکان بازگشت وجود دارد؟

اطلاعات ثبت‌شده در ERP چگونه حفظ می‌شوند؟

سیستم قدیمی در چه شرایطی دوباره فعال می‌شود؟

این موارد باید قبل از Go-Live مشخص باشند.

🔹 مرحله بیستم؛ بعد از انتقال هم کنترل ادامه دارد

مهاجرت با انتقال اطلاعات تمام نمی‌شود.

در روزهای اول باید وضعیت سیستم به‌صورت دقیق بررسی شود.

مثلاً:

روز اول

کنترل فروش، خرید، انبار و مالی.

روز دوم

بررسی خطاهای کاربران.

هفته اول

تطبیق گزارش‌های اصلی.

هفته دوم

بررسی فرآیندهای مشکل‌دار.

ماه اول

ارزیابی عملکرد سیستم و کاربران.

این دوره را می‌توان Post-Migration Support نامید.

🟢 چک‌لیست نهایی مهاجرت بدون از دست رفتن اطلاعات

در ادامه یک چک‌لیست فشرده و کاربردی برای مدیر پروژه ERP ارائه می‌شود:

قبل از مهاجرت

• تمام منابع اطلاعاتی شناسایی شده‌اند.

• محدوده اطلاعات قابل انتقال مشخص شده است.

• مسئول هر دسته اطلاعات مشخص شده است.

• Backup کامل تهیه شده است.

• Restore نسخه پشتیبان تست شده است.

• نسخه مرجع اطلاعات ثبت شده است.

• داده‌های تکراری شناسایی شده‌اند.

• داده‌های ناقص مشخص شده‌اند.

• داده‌ها پاک‌سازی شده‌اند.

• ساختار ERP مقصد مشخص شده است.

• Data Mapping تهیه شده است.

• ترتیب انتقال مشخص شده است.

هنگام انتقال آزمایشی

• داده‌های نمونه منتقل شده‌اند.

• تعداد رکوردها مقایسه شده است.

• محتوای رکوردها بررسی شده است.

• اطلاعات مالی کنترل شده است.

• موجودی کنترل شده است.

• روابط بین رکوردها بررسی شده‌اند.

• فرآیندهای واقعی تست شده‌اند.

• کاربران کلیدی تأیید کرده‌اند.

قبل از Go-Live

• آخرین Backup تهیه شده است.

• Freeze Point مشخص شده است.

• اطلاعات نهایی استخراج شده‌اند.

• تراکنش‌های باز شناسایی شده‌اند.

• انتقال نهایی تست شده است.

• کاربران آموزش دیده‌اند.

• دسترسی‌ها تنظیم شده‌اند.

• گزارش‌های مهم بررسی شده‌اند.

• برنامه Rollback آماده است.

• تیم پشتیبانی مشخص شده است.

بعد از Go-Live

• تعداد رکوردها کنترل شده است.

• مانده‌های مالی تطبیق داده شده‌اند.

• موجودی انبار کنترل شده است.

• سفارش‌های باز بررسی شده‌اند.

• کاربران خطاهای احتمالی را گزارش کرده‌اند.

• سیستم قدیمی به‌صورت آرشیوی حفظ شده است.

• گزارش‌های مدیریتی کنترل شده‌اند.

• مشکلات اولیه ثبت و اولویت‌بندی شده‌اند.

• فرآیندهای اصلی مجدداً ارزیابی شده‌اند.

🔹 انتقال از هلو، سپیدار، پارمیس یا همکاران سیستم؛ آیا چک‌لیست یکسان است؟

اصول کلی یکسان است، اما جزئیات انتقال برای هر نرم‌افزار متفاوت خواهد بود.

برای مثال، در مهاجرت از هلو به ERP ممکن است ساختار اطلاعات مالی، مشتریان، کالاها و فاکتورها محور اصلی پروژه باشد.

در مهاجرت از سپیدار به ERP نیز باید ساختار حسابداری و اطلاعات عملیاتی موجود در سیستم با ساختار ERP مقصد تطبیق داده شود.

در مهاجرت از پارمیس به ERP نیز کیفیت داده، کدینگ و نحوه نگاشت اطلاعات باید بررسی شود.

در پروژه‌های مهاجرت از همکاران سیستم به ERP، با توجه به ساختار سازمان و حجم داده‌ها، ممکن است فرآیند استخراج و Mapping پیچیده‌تر شود.

اما در همه این پروژه‌ها یک اصل ثابت است:

ابتدا داده را بشناسید، سپس آن را پاک‌سازی کنید، بعد Mapping انجام دهید و در نهایت انتقال دهید.

🔹 مهاجرت از Excel؛ چرا باید قبل از انتقال یک مرحله اضافه داشته باشیم؟

اگر اطلاعات فعلی شرکت بیشتر در Excel باشد، معمولاً باید زمان بیشتری برای آماده‌سازی اطلاعات در نظر گرفته شود.

زیرا Excel می‌تواند بسیار انعطاف‌پذیر باشد، اما همین انعطاف‌پذیری باعث می‌شود ساختار داده‌ها استاندارد نباشد.

ممکن است یک فایل برای هر کاربر ساختار متفاوتی داشته باشد.

بنابراین در مهاجرت از Excel به ERP بهتر است ابتدا:

Excel Files

⬇️

Data Consolidation

⬇️

Data Cleaning

⬇️

Standardization

⬇️

Mapping

⬇️

ERP Import

انجام شود.

یعنی قبل از ورود داده‌ها به ERP، اطلاعات پراکنده Excel باید به یک ساختار استاندارد و قابل کنترل تبدیل شوند.

🔹 یک نکته بسیار مهم؛ Migration ابزار نیست، فرآیند است

گاهی مدیران تصور می‌کنند اگر ابزار Import یا API مناسبی پیدا کنند، مشکل مهاجرت حل شده است.

اما ابزار فقط عملیات فنی را انجام می‌دهد.

اینکه:

چه اطلاعاتی منتقل شود؟

چگونه منتقل شود؟

کدام اطلاعات حذف شوند؟

کدام اطلاعات آرشیو شوند؟

کدام فیلد با کدام فیلد تطبیق داده شود؟

چگونه صحت انتقال را بررسی کنیم؟

پرسش‌های مدیریتی و تحلیلی هستند.

بنابراین حتی اگر انتقال اطلاعات با API، CSV، Excel یا ابزارهای اختصاصی انجام شود، همچنان به طراحی فرآیند مهاجرت نیاز داریم.

🔹 مهاجرت موفق یعنی «قابل اثبات بودن صحت اطلاعات»

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

مثلاً:

تعداد مشتریان: برابر

تعداد محصولات: برابر

موجودی: قابل تطبیق

مطالبات: قابل تطبیق

بدهی‌ها: قابل تطبیق

فروش: قابل تطبیق

سفارش‌های باز: منتقل شده

این رویکرد باعث می‌شود عبارت «اطلاعات درست منتقل شده‌اند» از یک ادعا به یک نتیجه قابل بررسی تبدیل شود.

🔗 ارتباط این مقاله با مقاله اصلی خوشه

در مقاله اصلی «راهنمای کامل مهاجرت از نرم‌افزارهای سنتی به ERP» مسیر کلی مهاجرت از سیستم‌های قدیمی به ERP را بررسی کردیم؛ از تحلیل وضعیت موجود و انتخاب ERP تا طراحی فرآیند، انتقال داده و راه‌اندازی.

این مقاله یک گام تخصصی‌تر جلو می‌رود و روی یک دغدغه بسیار مهم تمرکز دارد:

چگونه اطلاعات را بدون از دست رفتن، ناقص شدن یا تغییر اشتباه به ERP منتقل کنیم؟

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

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

از طرف دیگر، اگر نگرانی اصلی شما این است که در زمان تغییر نرم‌افزار فروش، تولید، انبار یا عملیات شرکت متوقف نشود، مقاله «چگونه بدون توقف کسب‌وکار نرم‌افزار خود را تغییر دهیم؟» ادامه طبیعی این مسیر خواهد بود.

🚀 چگونه یک مهاجرت مطمئن به Odoo انجام دهیم؟

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

ابتدا باید یک Migration Assessment انجام شود.

در این ارزیابی مشخص می‌شود:

چه اطلاعاتی دارید؟

کیفیت اطلاعات چگونه است؟

چه داده‌هایی باید منتقل شوند؟

چه داده‌هایی باید پاک‌سازی شوند؟

چه اطلاعاتی باید آرشیو شوند؟

ساختار Odoo چگونه باید طراحی شود؟

چه داده‌هایی نیاز به تبدیل دارند؟

چه فرآیندهایی باید قبل از مهاجرت اصلاح شوند؟

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

در پروژه‌های استقرار Odoo، این مرحله اهمیت زیادی دارد؛ زیرا هدف فقط این نیست که اطلاعات سیستم قبلی وارد Odoo شوند، بلکه باید مطمئن شویم اطلاعات بعد از انتقال در فرآیند واقعی کسب‌وکار قابل استفاده هستند.

🎯 خدمات مشاوره مهاجرت و استقرار Odoo

اگر قصد دارید نرم‌افزار قدیمی سازمان را با Odoo جایگزین کنید، می‌توان پروژه را از مرحله ارزیابی تا راه‌اندازی به‌صورت ساختاریافته پیش برد:

🔸 تحلیل سیستم فعلی

بررسی نرم‌افزار، بانک اطلاعاتی، فایل‌های Excel و فرآیندهای سازمان.

🔸 تدوین Migration Plan

تعیین اطلاعات قابل انتقال، روش انتقال، زمان‌بندی و مسئولیت‌ها.

🔸 Data Cleaning

پاک‌سازی، استانداردسازی و حذف داده‌های تکراری.

🔸 Data Mapping

تطبیق ساختار اطلاعات نرم‌افزار قدیمی با ساختار Odoo.

🔸 Test Migration

انتقال آزمایشی و بررسی نتیجه توسط کاربران کلیدی.

🔸 Final Migration

انتقال نهایی پس از تأیید اطلاعات.

🔸 Go-Live

راه‌اندازی Odoo و انتقال کنترل‌شده عملیات سازمان.

🔸 پشتیبانی

رفع مشکلات اولیه، آموزش تکمیلی و بهینه‌سازی فرآیندها.

🧩 جمع‌بندی؛ برای انتقال اطلاعات عجله نکنید

مهم‌ترین پیام این چک‌لیست ساده است:

اطلاعات را مستقیم از سیستم قدیمی به ERP منتقل نکنید.

ابتدا:

شناسايی → Backup → Baseline → پاک‌سازی → استانداردسازی → Mapping → انتقال آزمایشی → اعتبارسنجی → انتقال نهایی → کنترل پس از Go-Live

را اجرا کنید.

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

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

بنابراین در زمان مهاجرت از نرم‌افزارهای سنتی به ERP، باید به سه سؤال اساسی پاسخ داده شود:

۱. آیا اطلاعات منتقل شده‌اند؟

۲. آیا اطلاعات صحیح منتقل شده‌اند؟

۳. آیا اطلاعات در فرآیندهای ERP قابل استفاده هستند؟

اگر پاسخ هر سه سؤال مثبت باشد، می‌توان گفت سازمان یک قدم مهم به سمت یک مهاجرت موفق برداشته است.

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

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

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