انتقل إلى المحتوى

لماذا يفشل تكامل ERP مع Salesforce وكيف تصلحه

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

موظفو خدمة عملاء بسماعات رأس يعملون على حواسيب محمولة على مكتب مشترك
المحتويات
  1. لماذا تنهار عمليات التكامل بين SAP وSalesforce
  2. تردد مزامنة لا يناسب القرار
  3. عدم تطابق جودة البيانات
  4. بنية معمارية لا تناسب الحجم
  5. غياب حوكمة التكامل
  6. خيارات التكامل
  7. ما الذي يحتاجه التكامل الموثوق
  8. مواصفات تكامل من صفحة واحدة
  9. سيناريوهات الفشل الشائعة وما ينبغي فعله
  10. الأسئلة الشائعة

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

هذا المقال موجّه إلى مديري تقنية المعلومات (CIO) وقادة عمليات المبيعات والتكامل الذين يربطون Salesforce بـ SAP. ويتناول أنماط الفشل الأربعة، وخيارات التكامل، وما يحتاجه التكامل الموثوق، وقالباً للمواصفات.

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

قد يعمل التكامل تقنياً ويكون معطوباً تجارياً. ومن هذا التمييز تبدأ.

تردد مزامنة لا يناسب القرار

المزامنة على دفعات مقبولة لبعض البيانات. وليست مقبولة للمخزون المتاح للوعد (Available-to-Promise) أو التسعير أو حالة الطلب حيث يتوقع العملاء إجابة الآن.

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

اطرح سؤالاً واحداً قبل أن يُحدَّد أي شيء: ما أقدم عمر يمكن أن تبلغه البيانات وتبقى مفيدة؟ قد يكفي التحديث اليومي لتحديثات البيانات الرئيسية للعملاء. أما لتوافر المخزون في مبيعات B2B فإن أي شيء يتجاوز خمس عشرة دقيقة مشكلة.

مدى حداثة كل تدفق المطلوبةقيم توضيحية من قالب المواصفات أدناه. اتفق على قيمك أنت مع من يستخدمون البيانات.
  1. البيانات الرئيسية للعملاءمن SAP إلى Salesforce، 24 ساعة
  2. قوائم الأسعارمن SAP إلى Salesforce، ساعة واحدة
  3. توافر المخزونمن SAP إلى Salesforce، 15 دقيقة
  4. الفرصة المربوحةمن Salesforce إلى SAP، فوراً
  5. حالة الطلبمن SAP إلى Salesforce، 15 دقيقة
  6. الفاتورة والدفعمن SAP إلى Salesforce، 24 ساعة

يتطابق عرض السعر والطلب والفاتورة

عدم تطابق جودة البيانات

إذا كان اسم الشركة في Salesforce مكتوباً بصيغة تختلف عن البيانات الرئيسية للعميل في SAP، فإن كل مزامنة تخلق حالات عدم تطابق تحتاج إلى إصلاح يدوي.

عملت مع فرق كانت تقضي ساعات كل أسبوع في مطابقة معلومات العملاء الأساسية بين Salesforce ونظام ERP، ورأيت مشاريع استغرق فيها رسم خرائط هرميات العملاء وحدها أسابيع لأن النظامين عرّفا «الحساب» (Account) تعريفين مختلفين. فقد ظل النظامان يُصانان بمعزل عن بعضهما سنوات وتباعدا بطرق لم يرسمها أحد.

نظّف البيانات قبل أن تُجري التكامل. يبدو ذلك بديهياً. لكنه الخطوة الأكثر تجاوزاً باستمرار.

بنية معمارية لا تناسب الحجم

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

لكنه لا يتسع. أضف وحدة SAP أو وحدة أعمال جديدة في Salesforce أو نظاماً ثالثاً، فتتضاعف الاتصالات. وكل واحد منها يحتاج إلى صيانة واختبار ومعالجة أعطال على حدة.

توفر البرمجيات الوسيطة (SAP Integration Suite أو MuleSoft أو Boomi أو ما يشبهها) طبقة واحدة محكومة مع مراقبة مركزية ومعالجة للأخطاء. والمقايضة هي استثمار مسبق في البنية والحوكمة. أما الشركات التي تنشر برمجية وسيطة دون أن تسمّي لها مالكاً فتنتهي بالمشكلات نفسها التي في الربط من نقطة إلى نقطة، إضافةً إلى منصة لا يفهمها أحد.

غياب حوكمة التكامل

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

SAP Integration Suite. منصة التكامل من SAP على SAP BTP، والخيار الطبيعي في المنظومات التي تتمحور حول SAP. وهي تتعامل جيداً مع IDocs وBAPIs وOData وصيغ رسائل SAP، وتتضمن محتوى جاهزاً لسيناريوهات SAP الشائعة. ومع ذلك تحتاج العمليات التجارية المعقدة إلى تدفقات تكامل مخصصة ومهارات تكامل حقيقية. وإذا كنت لا تزال على SAP PI/PO، فاعلم أن صيانته الأساسية تنتهي بنهاية 2027، فلا ينبغي بناء تدفقات Salesforce جديدة عليه. وعلى RISE، تحقق مما يتضمنه عقدك أصلاً من استحقاق SAP BTP قبل أن تشتري المزيد.

MuleSoft. مملوكة لـ Salesforce منذ 2018، بمكتبة موصّلات واسعة وموصّل رسمي لـ SAP S/4HANA وقوالب تسريع لدورة الطلب إلى النقد (Order-to-Cash) في SAP. وهي مناسبة إذا كنت تملكها أصلاً. والمأخذ بالنسبة إلى المؤسسات التي يغلب عليها SAP: أن MuleSoft مجموعة مهارات منفصلة، وأن الفريق الذي يدير برنامج SAP لديك ربما لا يكون الفريق الذي ينبغي أن يصمم بنية MuleSoft.

Boomi. منصة تكامل سحابية (مستقلة عن Dell منذ 2021) تضم موصّلات لـ SAP وSalesforce وعتبة دخول أدنى من MuleSoft. وهي معقولة للمؤسسات المتوسطة التي تريد برمجية وسيطة محكومة دون كلفة MuleSoft أو تعقيدها.

واجهات API من نقطة إلى نقطة. استدعاءات REST أو SOAP المباشرة بين Salesforce وSAP تتفادى كلفة البرمجية الوسيطة. وتحتاج إلى إدارة منضبطة لإصدارات API، واختبار انحدار عند كل إصدار، وفريق يفهم النظامين. لا بأس بها للحالات البسيطة المستقرة. لكنها آلة لتراكم الديون لكل ما هو معقد.

ويتناول دليلي عن SAP CPI وIntegration Suite المنصة في جانب SAP بمزيد من العمق، وتقارن الخيارات الخمسة لأنظمة CRM مع SAP أنظمة CRM نفسها.

  1. مواصفات لكل تدفق: الحقول والاتجاه والتردد وربط المفاتيح، وما يحدث حين يختلف النظامان.
  2. تصميم صريح للفشل. حين تفشل مزامنة، ماذا يحدث للبيانات قيد النقل؟ وكم محاولة إعادة؟ ومن يتلقى التنبيه؟ وما التعافي اليدوي؟ معظم التكاملات ضعيفة التصميم هنا.
  3. اختبارات انحدار قبل كل ترقية. تصدر Salesforce ثلاثة إصدارات رئيسية في السنة، وتصدر SAP حزم دعم وتحديثات خاصة بها. وينبغي تشغيل مجموعة اختبارات آلية تغطي التدفقات الحرجة قبل كل منها.
  4. مراقبة مع تنبيهات. الفشل الصامت أسوأ من الفشل الصاخب. والأخطاء التي تتراكم أياماً أصعب بكثير في الإصلاح من الأخطاء التي تُرصد في دقائق.
  5. مالك. شخص واحد يعرف ما يفعله التكامل، ويرى متى ينكسر، ويملك الصلاحية والسلطة لإصلاحه.

أن يعمل التكامل تقنياً لا يعني أنه يؤدي وظيفته تجارياً. حتى تأخر ساعة واحدة بين النظامين قد يسبب أخطاء في عروض الأسعار تضيّع صفقات.

املأ صفاً واحداً لكل تدفق قبل أن يكتب أحد وثيقة مواصفات. فإذا كانت خانة فارغة، فالتدفق ليس جاهزاً للبناء. والقيم أدناه توضيحية؛ فاتفق على قيمك أنت مع من يستخدمون البيانات.

التدفقالاتجاهالمحفّز والترددأقدم بيانات مقبولةالنظام المرجعيعند الفشلالمالك
البيانات الرئيسية للعملاءمن SAP إلى Salesforceعند التغيير24 ساعةSAPإعادة المحاولة، ثم تنبيه أمين البياناتمالك البيانات الرئيسية للعملاء
توافر المخزونمن SAP إلى Salesforceعند الطلب أو شبه فوري15 دقيقةSAPإظهار علامة «راجع العمليات»قائد أنظمة سلسلة الإمداد
قوائم الأسعار والشروطمن SAP إلى Salesforceعند التغييرساعة واحدةSAPمنع عرض السعر إذا كان السعر قديماًمدير التسعير
من الفرصة المربوحة إلى أمر المبيعاتمن Salesforce إلى SAPعند الإغلاقفوريSalesforce حتى إنشاء الأمر، ثم SAPوضع في الطابور وتنبيه عمليات المبيعاتقائد عمليات المبيعات
حالة الطلب والتسليممن SAP إلى Salesforceعند كل مرحلة15 دقيقةSAPإعادة المحاولة، ثم تنبيه دعم التكاملقائد التكامل
حالة الفاتورة والدفعمن SAP إلى Salesforceيومياً24 ساعةSAPتنبيه أنظمة الماليةقائد أنظمة المالية

عمود «أقدم بيانات مقبولة» هو الذي لا تملؤه معظم الفرق أبداً. اتفق عليه مع المستخدمين الذين يتخذون القرارات، لا مع فريق التكامل وحده. وإذا كنت متأخراً أصلاً، فإن تأخيرات تسليم SAP Integration Suite يتناول الأسباب الشائعة.

سجلات العملاء غير متطابقة. السبب: لم تتم مواءمة البيانات الرئيسية للعملاء في النظامين قط. الحل: سوِّ الفروق قبل التشغيل الفعلي، واجعل SAP النظام المرجعي لبيانات العملاء، وافرض الربط داخل التكامل.

حالة الطلب لا تتحدث في Salesforce. السبب: التكامل يغطي من عرض السعر إلى الطلب لكنه لا يغطي استدعاءات الحالة المرتدة. الحل: أرسل تحديثات الحالة من SAP SD إلى Salesforce عند كل مرحلة من مراحل الطلب.

أسعار عروض الأسعار تختلف عن أسعار الفواتير. السبب: تُصان الأسعار يدوياً في Salesforce وتنجرف عن شروط التسعير في SAP. الحل: اجعل SAP هو المصدر الرئيسي للأسعار واسحب الأسعار إلى Salesforce عبر التكامل.

ينكسر التكامل بعد تحديث SAP. السبب: لا يوجد اختبار انحدار للتكامل في خطة الترقية. الحل: أدرج اختبار انحدار التكامل في نطاق كل تحديث لـ SAP.

هل يمكن لـ Salesforce أن يتكامل مع SAP؟

نعم، عبر SAP Integration Suite أو MuleSoft أو Boomi أو منصات تكامل أخرى أو واجهات API مباشرة. والتدفقات المعتادة هي مزامنة البيانات الرئيسية للعملاء، ومن الفرصة المربوحة إلى أمر المبيعات، وحالة الطلب والتسليم العائدة إلى Salesforce، والتسعير إلى Salesforce لعروض الأسعار، وحالة الفاتورة والدفع. ومزامنة البيانات الرئيسية للعملاء مباشرة. أما دورة عرض السعر إلى النقد (Quote-to-Cash) الكاملة مع تسعير معقد وعدد كبير من رموز الشركات ومخزون في الوقت الفعلي فمشروع كبير.

هل Salesforce نظام ERP أم CRM؟

نظام CRM. يدير مسار المبيعات والفرص وتفاعلات العملاء والتسويق والخدمة. ولا يرحّل قيوداً محاسبية ولا يدير المخزون. وSAP هو نظام ERP للمالية والمشتريات والمخزون والإنتاج. وعند التكامل الجيد يرى مندوب المبيعات المخزون وحالة الدفع في Salesforce، وترى المالية قيمة الصفقة في SAP.

ما السبب الرئيسي لفشل التكامل بين ERP وCRM؟

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

كيف تصون التكامل بين ERP وSalesforce مع الوقت؟

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

متى تستخدم SAP Integration Suite للتكامل مع Salesforce؟

حين يكون SAP هو النظام المهيمن، وحين تتوافر لك إمكانية الوصول إلى SAP BTP، وحين تتضمن التدفقات محتوى خاصاً بـ SAP مثل IDocs أو BAPIs أو صيغ رسائل SAP. وهو خيار أضعف إذا كنت قد استثمرت كثيراً في MuleSoft أو Boomi، أو إذا كان فريقك يفتقر إلى مهارات تكامل SAP، أو إذا كان SAP طرفاً ثانوياً في تدفقات معظمها غير SAP. وفي برامج RISE الجديدة التي يدخل Salesforce في نطاقها، هو نقطة البداية الطبيعية.

كم يستغرق مشروع التكامل بين ERP وSalesforce؟

النطاق القياسي (مزامنة البيانات الرئيسية للعملاء، ومن عرض السعر إلى الطلب، وحالة الطلب الأساسية) باستخدام محتوى جاهز يستغرق عادةً من 8 إلى 16 أسبوعاً من تحديد النطاق إلى التشغيل الفعلي، بافتراض بيانات نظيفة ومطور تكامل متفرغ. أما دورة عرض السعر إلى النقد الكاملة مع تسعير معقد وكيانات متعددة وإدارة ائتمان ومخزون في الوقت الفعلي فتستغرق عادةً من 4 إلى 9 أشهر. ومشكلات البيانات التي تُكتشف في منتصف المشروع والتدفقات المضافة أثناء البناء هي الأسباب المعتادة للتجاوز، لذا أجرِ تقييماً لجودة البيانات قبل أن يبدأ البناء.

Noel D'Costa

بقلم

Noel D'Costa

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

الخطوة التالية

هل تدير برنامج ERP الآن؟

إذا مسّ هذا المقال برنامجاً أنت في خضمه الآن، فإن حديثاً مدته 30 دقيقة يوصلك عادةً أبعد من أسبوع آخر من التحليل الداخلي.