ربط CRM بنظام ERP: ما البيانات التي تنتقل بين النظامين؟

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

المبدأ الحاكم: لكل حقل مالك واحد

أكثر مشكلات ربط CRM بـERP لا تأتي من التقنية، بل من سؤال لم يُحسم: إذا اختلفت القيمة بين النظامين، فأيهما الصحيح؟ مثال ذلك عنوان عميل عدّله المندوب في CRM بعد زيارة، وعدّلته المحاسبة في ERP بعد مراسلة من العميل. الجواب لا يُترك للمزامنة الأخيرة، بل يُقرر مسبقًا لكل حقل.

والتقسيم على مستوى الكائن كله («العميل ملك ERP») لا يكفي، لأن سجل العميل يحمل بيانات تهم إدارتين:

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

خريطة البيانات: ماذا ينتقل، وإلى أين، ومتى؟

الجدول التالي نقطة بداية لمنشأة تبيع منتجات أو خدمات بفواتير من ERP. عدّلوه حسب نشاطكم، ثم اجعلوه مرجع بطاقات التكامل.

ثلاث ملاحظات على الخريطة تتكرر في المشاريع:

• عرض السعر لا ينتقل غالبًا: تبقى إصدارات العرض وتعديلاتها في CRM، وينتقل إلى ERP الإصدار المعتمد فقط، في صورة أمر بيع. وبعض المنشآت تنقل العرض المعتمد كـ«عرض مبيعات» في ERP إن كان الإجراء المالي يشترطه.
• الأسعار قد تُدار في CRM: في شركات الخدمات والبرمجيات تُبنى الباقات والتسعير في CRM، ويكتفي ERP بصنف عام لكل خدمة. في هذه الحالة يصبح CRM مرجع السعر، ويُكتب ذلك صراحة.
• الفواتير تعود للعرض لا للتعديل: المندوب يرى الفاتورة وحالة تحصيلها في ملف العميل، لكن أي تصحيح يتم في النظام المالي. وقواعد استخدام هذه البيانات في البيع، مثل منع عرض جديد لعميل متأخر، تتناولها مقالة ربط حالة الفواتير والتحصيل بملف العميل.

المفاتيح المشتركة: كيف يعرف كل نظام أن السجلين لشيء واحد؟

المطابقة بالاسم تفشل عند أول اختلاف في كتابة «مؤسسة» أو «شركة» أو في همزة. لذلك يحفظ كل سجل منقول معرّفه في النظام الآخر: رقم الحساب المالي داخل سجل العميل في CRM، ومعرّف CRM داخل حساب العميل في ERP. وبعدها تتم كل مزامنة لاحقة بالمعرّف لا بالاسم.

وإلى جانب معرّفات السجلات، توجد جداول ترميز يجب أن تتطابق في النظامين قبل انتقال أول طلب:

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

تسلسل الأحداث من العرض المعتمد إلى التحصيل

الخريطة تجيب عن سؤال «ماذا ينتقل؟». أما الترتيب فيجيب عن سؤال «بأي تسلسل؟»، وهو ما يحدد نقاط الفشل وما يراه كل طرف في كل لحظة.

شركة توزيع اعتمدت عرضًا بقيمة 120,000 ريال شاملة الضريبة. انتقل أمر البيع إلى ERP وعاد رقمه إلى الفرصة. سُلّمت الدفعة الأولى وفوترت بـ70,000 ريال، وبقي 50,000 ريال غير مفوتر بانتظار التسليم الثاني. ثم سدد العميل 40,000 ريال من الفاتورة الأولى. ما يراه مسؤول الحساب في CRM بعد المزامنة: أمر بيع مسلَّم جزئيًا، وفاتورة واحدة بقيمة 70,000 ريال، ورصيد مستحق عليها 30,000 ريال (70,000 − 40,000)، وقيمة غير مفوترة 50,000 ريال. المجموع يطابق قيمة الأمر: 70,000 + 50,000 = 120,000 ريال. وإن لم تتطابق هذه الأرقام بين النظامين في أي يوم، فتقرير المطابقة الموضح لاحقًا هو ما يكشف السبب.

فوري أم دوري أم عند الطلب؟

ليس كل بيان يحتاج انتقالًا فوريًا، والمزامنة الفورية لكل شيء تزيد الحمل على ERP وتعقّد معالجة الأخطاء. اختاروا التوقيت حسب السؤال: متى يحتاج المستخدم هذه المعلومة، وما كلفة أن تكون قديمة بساعات؟

والنمط الذي يحدد كل ذلك عمليًا هو ما يتيحه ERP نفسه: هل يوفر واجهة برمجية للقراءة والكتابة، أو أحداثًا يرسلها عند التغيير، أو لا يتيح إلا تبادل الملفات المجدول؟ الأنظمة القديمة التي لا تتيح إلا الملفات تفرض النمط الدوري حتى على ما يُفضَّل أن يكون فوريًا. وأسئلة فحص جودة الواجهات البرمجية نفسها تجدها في مقالة أسئلة فريق تقنية المعلومات عن API وWebhooks في CRM.

قواعد التعارض والحالات الصعبة

المسار السعيد يعمل في أول عرض تجريبي. ما يحدد جودة التكامل هو ما يحدث في الحالات التالية، ولكل منها قاعدة تُكتب وتُختبر:

القاعدة الأخيرة تستحق اختبارًا صريحًا: ما يمنع التكرار عند إعادة المحاولة هو أن يحمل الطلب المرسل معرّفًا فريدًا من CRM يرفض ERP تكراره. اسألوا عن ذلك تحديدًا، ولا تكتفوا بعبارة «النظام يعيد المحاولة».

البدء: المطابقة الأولى، والاختبار، والمراقبة

1. مطابقة العملاء القائمين

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

   المالية ومسؤول CRM
2. توحيد جداول الترميز

   الأصناف ووحدات القياس والضريبة والمندوبون والفروع وشروط السداد، في جدول مقابلة معتمد من الطرفين.

   تقنية المعلومات ومالكو البيانات
3. اختبار الحالات لا المسار السعيد فقط

   كل صف في جدول الحالات الصعبة يصبح حالة اختبار في بيئة تجريبية لـERP، لا في بيئة الإنتاج.

   فريق التنفيذ والمالية
4. تقرير مطابقة دوري

   عدد الأوامر المعتمدة في CRM مقابل الأوامر المنشأة في ERP، ومجموع الأرصدة في النظامين، وقائمة السجلات التي فشلت مزامنتها. يُراجع يوميًا في الأسابيع الأولى ثم أسبوعيًا.

   مسؤول CRM

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

إذا كان لديكم ERP محدد وتريدون معرفة ما يمكن ربطه فيه فعلًا، فأرسلوا اسمه وإصداره وطريقة الربط المتاحة فيه، ونعد معكم مسودة خريطة البيانات وبطاقات التكامل ضمن تصميم التكامل مع فريقنا قبل أي التزام.

أسئلة شائعة