انتقل إلى نظام CRM جديد دون أن تفقد ما تعرفه عن عملائك

يصبح الترحيل خطراً حين يُعامل كعملية نسخ. وهو أسلم حين يكون تسلسلاً. نبدأ بتدقيق: كم عدد السجلات، وكم منها مكرر، وأي الحقول الإلزامية فارغة، وأي العلاقات (جهة الاتصال بالشركة، الصفقة بجهة الاتصال) سليمة. ويحدد هذا التدقيق ما ننظفه وما نؤرشفه وما نتركه. ليس كل سجل قديم جديراً بمكان في النظام الجديد.

ثم تأتي المطابقة. نادراً ما تطابق حقول المصدر حقول الهدف واحداً لواحد. قد يحتاج حقل نصي حر إلى تقسيم، وقائمة حالات إلى دمج، ومساران قديمان إلى مسار واحد. نوثق كل قرار في جدول مطابقة تقرؤونه دون مساعدة تقنية.

بعدها نجري تحميلاً تجريبياً في بيئة اختبار، وتفحصونه، ونصحح، ونحمّل مرة أخرى. وعندها فقط يجري تحميل الإنتاج، عادة في عطلة نهاية الأسبوع أو وقت هادئ، مع تجميد النظام القديم عن التعديل. أغلب عمليات الترحيل تستغرق من 3 إلى 8 أسابيع، والبيئات الكبيرة ذات المصادر المتعددة تحتاج أكثر، ويحدد التدقيق مقدار ذلك.

تثير العربية مشكلات لا تظهر في البيانات الإنجليزية. فالشركة الواحدة قد تظهر باسم عربي ونسخة بحروف لاتينية واختصار. وتعطّل المطابقة البسيطة للتكرار صور الألف والهمزة، واختلاف كتابة الاسم نفسه، وخلط الأرقام الهندية والغربية. نوحّد النص لأغراض المطابقة دون الكتابة فوق الأصل، فيرى الناس الاسم كما كُتب بينما يظل النظام قادراً على كشف التكرار.

ترحيل CRM ينقل بيانات شخصية، فينطبق نظام حماية البيانات الشخصية على النقل نفسه. نقصر المنسوخ على ما لديكم سبب للاحتفاظ به، ونقيّد من يصل إلى الملفات المصدَّرة، ونحذف النسخ العاملة عند انتهاء المشروع، ونسجل وجهة البيانات. وإذا اشتمل الترحيل على معالج خارج المملكة، فيجب فحص قواعد النقل في النظام مع مستشاركم القانوني قبل أن نبدأ.

الموافقة تستحق عناية خاصة. إذا كان نظامكم القديم يسجل من رفض الرسائل التسويقية، فيجب أن ينتقل هذا الإعداد مع جهة الاتصال. وفقدانه هو ما يجعل شركة تراسل أناساً طلبوا ألا يُراسَلوا.

التكامل قرار تصميمي لا مجرد توصيل. السؤال الأول: أي نظام يملك أي بيانات. عادة يملك CRM العميل المحتمل والفرصة وجهة اتصال المبيعات، بينما يملك ERP أو نظام المحاسبة الفاتورة والمعالجة الضريبية وسجل الدفع. وفي المملكة يجب أن تستوفي الفواتير متطلبات الفوترة الإلكترونية لدى زاتكا، فينبغي أن يقرأ CRM حالة الفاتورة من النظام الذي يصدرها لا أن ينشئ نسخته الخاصة.

ثم الأسلوب. تناسب إشعارات Webhook اللحظية أحداثاً مثل صفقة رابحة، وتناسب المزامنات المجدولة بيانات كبيرة مثل قائمة الأسعار. وحيث يناسب موصل أصلي من المورد نستخدمه، وحيث لا يناسب نبني على واجهة API الموثقة، ونجعل كل استدعاء آمناً عند إعادة المحاولة فلا ينشئ انقطاع الاتصال طلبية مكررة، ونسجل كل فشل بتفصيل يكفي لإصلاحه.

نختبر بالحالات الصعبة: عميل غُيّر اسمه بعد طلبية، وصفقة أُعيد فتحها بعد الفوترة، وإشعار دائن. هذه هي المواقف التي تنكسر فيها التكاملات في الشهر الأول، واكتشافها في الاختبار أرخص بكثير.