مهاجرت اطلاعات CRM: نگاشت، تکرارزدایی و تطبیق

مهاجرت به CRM جدید معمولاً با یک فایل CSV شروع می‌شود و با یک هفته شکایت فروشنده‌ها تمام می‌شود: «مشتری‌ها تکراری‌اند»، «سابقهٔ تماس‌ها نیست»، «مالک رکوردها اشتباه است». دلیل: مهاجرت را «انتقال فایل» دیده‌اند، نه یک کار با نگاشت، تکرارزدایی، تمرین و تطبیق. این مقاله یک چرخهٔ کم‌ریسک را مرحله‌به‌مرحله می‌دهد.

مرز منابع: توالی و چک‌لیست را از راهنمای NETLINKS، Linserv، Exactlly و Oracle (مشاوران و فروشنده‌ها) گرفته‌ایم؛ از آن‌ها فقط ساختار روش نقل شده است، نه آمار. قواعد تکرارزدایی و آستانه‌ها (مثلاً شباهت نام) توصیهٔ نویسنده‌اند. قوانین نگه‌داری و حذف داده‌های شخصی در ایران بررسی نشده است. برای مفهوم CRM راهنمای CRM را ببینید.

دامنه: چه چیزی منتقل شود؟

Oracle (در برنامهٔ پیاده‌سازی ERP) یادآوری می‌کند همه داده لازم نیست منتقل شود و مواردی مانند مشتریانی که سال‌هاست سفارش نداده‌اند را می‌توان کنار گذاشت. برای CRM همین منطق را به این پرسش‌ها ترجمه کنید (توصیهٔ نویسنده):

• کدام مخاطب‌ها و حساب‌ها فعال‌اند؟ (فعالیت یا خرید در بازهٔ مورد توافق.)
• سابقه‌ای که فقط برای مرجع لازم است در بایگانی جدا بماند یا منتقل شود؟
• سرنخ‌های بسیار قدیمی چه می‌شوند؟ (بایگانی یا حذف، با بررسی الزامات محلی.)
• کدام فیلدهای قدیمی بی‌استفاده‌اند و منتقل نمی‌شوند؟

Exactlly تأکید می‌کند صحت داده با کسب‌وکار است؛ مجری ممکن است فروشنده باشد، ولی «مالک داده» نباید او باشد. برای هر شیء نام یک مالک بنویسید.

نگاشت فیلد به فیلد

NETLINKS و Linserv هر دو نگاشت فیلد به فیلد را الزامی می‌دانند. جدول را نه فقط تیم فنی، که مالک داده امضا کند. نرمال‌سازی ارقام فارسی و ی/ک عربی نکتهٔ محلی است و توصیهٔ نویسنده؛ آن را قبل از هر تکرارزدایی انجام دهید، وگرنه «۰۹۱۲…» و «0912…» دو مخاطب جدا می‌شوند.

تکرارزدایی

HubSpot مخاطب‌ها را با ایمیل و شرکت‌ها را با دامنه یکتا می‌کند؛ Odoo هنگام ادغام سرنخ‌ها اولویت را به رکورد زودتر ساخته‌شده می‌دهد. الگوی ما (توصیهٔ نویسنده):

1. کلید قطعی: موبایل نرمال، ایمیل یا شناسهٔ سازمانی؛ هر دو رکورد با کلید یکسان ← ادغام.
2. کلید احتمالی: نام نرمال + شهر مشابه؛ فقط فهرست «کاندید ادغام» بسازید و انسان تأیید کند.
3. قاعدهٔ برنده: کدام رکورد پایه می‌ماند؟ فیلد به فیلد مشخص کنید: جدیدترین مقدار، قدیمی‌ترین رکورد، یا مقدار غیرخالی.
4. ثبت ادغام: شناسهٔ رکوردهای ادغام‌شده را نگه دارید تا برگشت ممکن باشد.

ادغام خودکار بر پایهٔ شباهت نام بدون تأیید انسان ریسک بالایی دارد؛ دو شرکت متفاوت با نام شبیه را به‌اشتباه یکی نکنید.

اجرای آزمایشی (dry run) و تطبیق

پیش از اجرای واقعی، حداقل دو بار کل مهاجرت را در محیط staging اجرا کنید. بعد از هر اجرا:

• تعداد: رکوردهای مبدأ، رد شده، ادغام شده و ایجاد شده با هم جمع می‌شوند؟ (مبدأ = ایجاد + ادغام + رد.)
• مجموع‌های کنترلی: تعداد فرصت‌ها در هر مرحله و مجموع مبلغ فرصت‌های باز؛ مبدأ و مقصد برابر باشند.
• نمونه دستی: ۲۰ تا ۵۰ رکورد تصادفی را دستی بررسی کنید (عدد نمونه توصیهٔ نویسنده است).
• مشکلات: هر مورد با مالک و تاریخ ثبت شود.

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

نمونهٔ گزارش تطبیق

گزارش را به شکل یک جدول ثابت بسازید که بعد از هر اجرا همان ستون‌ها را داشته باشد؛ مقایسهٔ اجراها آسان می‌شود (اعداد فرضی و فقط برای شکل):

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

قاعدهٔ نرمال‌سازی موبایل (نمونه)

برای اینکه یک شماره فقط یک شکل داشته باشد، قاعدهٔ مکتوب بنویسید و روی نمونه‌ها تست کنید (توصیهٔ نویسنده):

1. ارقام فارسی و عربی را به لاتین تبدیل کنید.
2. همهٔ کاراکترهای غیررقمی (فاصله، خط تیره، پرانتز، «+») را حذف کنید.
3. پیش‌شمارهٔ کشور و صفر ابتدایی را طبق یک قالب ثابت یکسان کنید (مثلاً همیشه با پیش‌شمارهٔ کشور ذخیره شود).
4. شماره‌ای که پس از این قواعد طول معتبر ندارد در فهرست «نامعتبر» برود، نه حذف.

همین منطق را برای ایمیل (حروف کوچک، حذف فاصله) و نام (یکسان‌سازی «ي» و «ك» عربی با «ی» و «ک») اجرا کنید و برای هر قاعده ۱۰ نمونهٔ آزمایشی مکتوب نگه دارید. اگر این قواعد در ورودی فرم‌ها هم اجرا شوند، داده جدید دوباره کثیف نمی‌شود؛ این یک درس طراحی برای ورودی‌هاست، نه فقط برای مهاجرت.

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

NETLINKS برای cutover این‌ها را لازم می‌داند: runbook، تمرین کامل در staging، تمرین rollback، دلتای نهایی دادهٔ تغییرکرده از آخرین بارگذاری و فریز تغییرات مبدأ. برای CRM:

1. فریز ورود داده در CRM قدیم (ساعت مشخص، اعلام به تیم).
2. بارگذاری دلتای نهایی.
3. تطبیق نهایی تعداد و مجموع‌ها.
4. آزمون دودی: یک فروشنده یک سرنخ را تبدیل می‌کند، فعالیت ثبت می‌کند، فرصت را جابه‌جا می‌کند.
5. تصمیم go/no-go با نام تصمیم‌گیرنده.
6. CRM قدیم را فقط‌خواندنی نگه دارید (نه حذف) تا پایان دورهٔ بازبینی.

Rollback یعنی «همه به CRM قدیم برگردند و ورودی‌های جدید دستی منتقل شوند». آن را پیش از اجرای واقعی تمرین کنید. برای عملیات پس از راه‌اندازی، پایش سیستم با متریک و هشدار و آمادگی تولید نرم‌افزار را ببینید.

اشتباهات رایج

• انتقال همه چیز بدون تصمیم دربارهٔ دامنه.
• تکرارزدایی پیش از نرمال‌سازی ارقام و حروف.
• ادغام خودکار بر پایهٔ شباهت نام.
• یک بار مهاجرت و بدون تطبیق.
• حذف CRM قدیم در روز راه‌اندازی.
• مالک داده نامشخص؛ هر مشکل «مشکل فنی» دیده می‌شود.

چک‌لیست

1. دامنه و مالک هر شیء مشخص است.
2. نگاشت فیلد به فیلد با قاعدهٔ تبدیل و مدیریت خطا امضا شده است.
3. نرمال‌سازی ارقام، ی/ک و موبایل پیش از تکرارزدایی انجام می‌شود.
4. کلید قطعی و فهرست کاندید با تأیید انسان تعریف شده است.
5. دست‌کم دو اجرای آزمایشی با گزارش تطبیق انجام شده است.
6. runbook، فریز، دلتا و rollback تمرین شده‌اند.
7. CRM قدیم فقط‌خواندنی می‌ماند.
8. الزامات نگه‌داری و حذف داده‌های شخصی ایران از منبع رسمی روز بررسی شده است.

منابع و مراجع

• Odoo Implementation Checklist (Phase 4: Data migration; Phase 7: Cutover) — NETLINKS.
• 3.0 — Project Methodology — Linserv.
• Creating an ERP Implementation Project Plan — Oracle.
• How to use objects for business processes — HubSpot، 2026-10-02.
• Convert leads into opportunities (Odoo 20.0) — Odoo S.A..
• ERP Implementation, Data Migration & Go-Live — Exactlly.