أنظمة معلومات العملاء: دراسة حالة في قطاع الدفاع بالشرق الأوسط

هذه دراسة حالة عن كيف أصلحت شركة تصنيع دفاعية متوسطة الحجم في الشرق الأوسط أنظمة معلومات عملائها. كانت بيانات العملاء موزعة على ثلاثة أماكن، وكانت عروض الأسعار تخرج بتسعير غير متسق، وكانت الموافقات تضيع في البريد الإلكتروني. وجاء الحل في سجل عميل واحد في Microsoft Dynamics، وتسعير قائم على القواعد في Experlogix CPQ، وتسليم آلي لعروض الأسعار المعتمدة إلى المبيعات والتوزيع (SD) في SAP عبر SAP Cloud Integration. وانخفض زمن إصدار عروض الأسعار 35% في المتوسط. وهي مكتوبة لقادة عمليات المبيعات وتقنية المعلومات والمالية في شركات التصنيع ذات دورات البيع الطويلة والقابلة للتهيئة والمثقلة بالامتثال. وتسلسل الإطلاق والدروس قرب النهاية هما ما يستحق إعادة الاستخدام.

حين تطلب فرق الدفاع أنظمة معلومات العملاء، فإنها تعني عادةً أكثر من نظام CRM. إنها تريد بنية: مكاناً تجتمع فيه القرارات المعقدة في سياقها، عبر دورات بيع طويلة وسير عمل مثقل بالامتثال ومجموعات متغيرة من صناع القرار.

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

شركة تصنيع دفاعية متوسطة الحجم في الشرق الأوسط. كانت تعمل خلف الكواليس: ليست علامة عامة، ولم تكن الشهرة هي الغاية. تُستخدم مكوناتها في الطيران العسكري والاتصالات الآمنة.

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

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

وهذا ما كان معطلاً وما كلّفه:

ما كان معطلاً	الأثر
لا نظام CRM لتدفق الفرص أو رؤية صناع القرار	لا صورة مشتركة عن موقع كل صفقة
التسعير يُدار يدوياً دون سجل متسق	عروض الأسعار تخرج بأرقام قديمة أو متضاربة
الموافقات عبر البريد الإلكتروني، وكثيراً ما تضيع أو تتأخر	مسارات تدقيق الامتثال ناقصة
سجلات العملاء مكررة عبر الأنظمة بتفاصيل مختلفة قليلاً	لا أحد يستطيع أن يقول أي النسخ دقيقة

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

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

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

وخرجت من تلك الجلسات ثلاث أولويات:

1. سجل عميل مشترك واحد، تراه المبيعات والدعم والعمليات بالصيغة نفسها. لا نسخ موازية بعد الآن.
2. تسعير منظم، يتبع قواعد متسقة للتهيئة والتسعير بدلاً من العادات الفردية والقوالب القديمة.
3. تنفيذ طلبات متصل، بتسليم نظيف من عرض السعر المعتمد إلى SAP SD ودون إعادة إدخال يدوي.

النظام	ما حلّه
Microsoft Dynamics CRM	سجل عميل واحد، مرتبط بنشاط المبيعات والفرص
Experlogix Configure Price Quote (CPQ)	قواعد تهيئة المنتجات ومنطق التسعير وإصدارات عروض الأسعار
المبيعات والتوزيع (SD) في SAP	تنفيذ الطلبات والوفاء بها
SAP Cloud Integration (CPI)	طبقة التكامل التي تربط CPQ وCRM بـ SAP SD

Microsoft Dynamics أساساً. احتجنا إلى مكان واحد تكون فيه معلومات العملاء دقيقة ومرئية في سياقها الكامل. منحنا Dynamics مكاناً نبدأ منه فك تشابك البيانات. وأفادت ألفة الفريق بالمنصة، وكذلك تكاملها مع Outlook وTeams. لم تتطلب من الناس أن يبدؤوا من جديد؛ بل احتاجت إلى تعديلات لتلائم طريقة عمل المؤسسة. وحين رأت الفرق البيانات نفسها بالصيغة نفسها عبر الوظائف، بدأت الثقة تتكوّن.

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

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

1. 01سجل العميلMicrosoft Dynamics، نسخة واحدة لكل الفرق
2. 02التهيئة والتسعيرقواعد Experlogix CPQ للتركيبات والتسعير
3. 03الموافقةتوجيه بحسب نوع الصفقة وقيمتها
4. 04إنشاء الطلبيدفع SAP CPI عرض السعر المعتمد إلى SAP SD
5. 05التنفيذSAP SD، مع إبقاء بيانات العملاء متزامنة

لا إعادة إدخال، ومسار تدقيق من الموافقة إلى الطلب

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

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

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

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

النتيجة	ما الذي تغيّر
زمن إصدار عروض الأسعار	انخفض 35% في المتوسط؛ وُفّرت ساعات في صفقات كثيرة وعدة أيام في المعقدة منها
دقة التهيئة	منعت قواعد التحقق الأخطاء قبل وصولها إلى القسم الهندسي
الجاهزية للتدقيق	لم تعد فحوص الامتثال تحتاج إلى استعجال في اللحظة الأخيرة
المواءمة بين الفرق	عملت المبيعات والدعم والعمليات من سجل العميل نفسه

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

المواءمة أهم من التقنية. كان البناء التقني هو الجزء الأسهل. أما جعل الفرق تثق بمصدر واحد للحقيقة وتتوقف عن صيانة سجلاتها الخاصة فكان أصعب. وقد استلزم أن أُري الناس أن البيانات موثوقة قبل أن أطلب منهم الاعتماد عليها.

تفاصيل التكامل أهم من الميزات. تكامل CPQ مع SAP SD هو ما جعل النظام كله ذا قيمة. فنظام CRM قائم بذاته وتسعير قائم بذاته مع إدخال يدوي للطلبات كان كل منهما سيفيد قليلاً. والوصلة بينهما هي حيث اختفى الاحتكاك.

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

لا تزال البنية صامدة: CRM لسجل العميل، وCPQ للتسعير المنظم، وتكامل ERP لتنفيذ الطلبات. وثلاثة أمور كانت ستتغير لو بدأت المهمة نفسها الآن.

منصة التكامل. صار SAP CPI الآن هو قدرة Cloud Integration داخل SAP Integration Suite، إلى جانب إدارة واجهات البرمجة والتكامل القائم على الأحداث ومحتوى التكامل الجاهز. وسيستغرق تدفق من Dynamics إلى CPQ إلى SAP SD وقتاً أقل في التصميم اليوم. ويغطي دليلي لـ SAP Cloud Integration المنصة.

سيكون نظام CRM من SAP نفسها في القائمة المختصرة. مع خلفية SAP SD، ينبغي لمهمة جديدة أن تقارن SAP Sales Cloud، الذي يضم الآن Joule، مع Microsoft Dynamics. وكان Dynamics الخيار الصحيح هنا بسبب الألفة القائمة. وما زالت الإجابة تتوقف على القدرات وتفضيلات التكامل، لكن الخيار الأصيل من SAP صار منافساً أكثر مصداقية مما كان. وتغطي مقارنتي لأنظمة CRM مع SAP الخيارات.

النطاق الاتحادي الأمريكي يحتاج إلى نموذج استضافة مختلف. لم يحتج هذا العميل إلى ذلك، لكن شركة دفاعية لها عمليات اتحادية أمريكية كانت ستنظر في SAP National Security Services (SAP NS2). وفي 2025 حصلت على تفويض مؤقت لتشغيل S/4HANA Cloud Private Edition وSAP BTP عند FedRAMP+ Impact Level 5، بعمليات داخل الولايات المتحدة حصراً.

تنطبق المتطلبات الخاصة بالدفاع (مسارات التدقيق والوصول القائم على الأدوار وضبط الإصدارات في عروض الأسعار وإقامة البيانات) أياً كان جيل المنصة. وللصورة الأوسع للامتثال، راجع دليلي عن امتثال SAP في القطاع العام.

لماذا اختير Microsoft Dynamics على منصات CRM الأخرى؟

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

وكان التحكم في الوصول وتسجيل التدقيق والمرونة ومجال التوسع هي العوامل الحاسمة الأخرى لعميل مثقل بالامتثال.

ما الدور الذي أداه Experlogix CPQ، ولماذا CPQ أصلاً؟

للمنتجات الدفاعية قواعد تهيئة معقدة. ولا تستطيع قائمة أسعار أن تلتقط التفاعل بين متغيرات المنتج ومتطلبات الامتثال والشروط الخاصة بكل عميل. وبدون CPQ، كان كل عرض سعر يعتمد على أن يعرف من بناه القواعد.

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

كيف جرى دمج SAP SD مع CRM وCPQ؟

عمل SAP CPI كبرمجية وسيطة. فعرض السعر المعتمد في Experlogix أطلق تدفقاً أنشأ الطلب في SAP SD ببنود وتسعير وبيانات عميل صحيحة. وأبقى CPI كذلك بيانات العملاء والطلبات متزامنة بين Dynamics وSAP، مع قواعد تحقق لمنع البيانات غير المتطابقة.

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

ما أكبر التحديات أثناء التنفيذ؟

جودة البيانات أولاً. كانت بيانات العملاء غير متسقة عبر الإدارات، بتكرارات وحقول ناقصة، وكان لا بد من تنظيفها قبل أن يصير Dynamics مصدر الحقيقة.

وجاءت مطابقة التكامل ثانياً، خاصة لتهيئات المنتجات والتسعير عبر ثلاثة أنظمة. وثالثاً كان مواءمة المبيعات والهندسة وتقنية المعلومات والمالية، خاصة حين تغيرت ملكية أجزاء من العملية.

كيف جرى التعامل مع الأمن والامتثال؟

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

ولأن التصميم بدأ من تلك المتطلبات، كانت البيانات في الشكل الصحيح أصلاً حين جاءت مراجعات الامتثال.

كم استغرق الإطلاق؟

نحو ستة إلى ثمانية أشهر، على مراحل. بدأ بتجربة تركز على CRM وCPQ، وتوسع عبر الإدارات بعد الملاحظات، وأضاف تكامل SAP SD في المنتصف بعد أن استقرت الأنظمة السابقة له. واستمر التدريب والدعم والضبط طوال المدة.

هل يمكن تطبيق هذا النموذج على شركات دفاعية أو تصنيعية أخرى؟

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

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