Use case

عملية بيع واحدة في كل القنوات

عملية البيع نفسها تتصرف بالطريقة نفسها في بوابة الشركاء وتطبيق المبيعات والخدمة الذاتية، ويخرج منطق B2B من تخصيصات الـ CRM، وتكفّ ترقية الـ CRM عن أن تكون مشروعًا.

MEF.DEV مدخل Open API وعمليات B2B بين القنوات وأنظمة السجل

ما يقدّمه MEF.DEV
قنواتكم وأنظمتكم والنتيجة

النسخة التنفيذية

إذا كانت مشكلتكم استبدال backend من نوع legacy دون إيقاف كل من يعتمد عليه، فانظروا استبدال backend من نوع legacy.

المشكلة

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

ما الذي يتغيّر

تمر كل قناة وكل شريك بعملية بيع واحدة خلف بوابة دخول TM Forum Open API.
يخرج منطق B2B من تخصيصات الـ CRM إلى عمليات BPMN؛ ويبقى الـ CRM نظام سجل.
يُقسَّم الكتالوج حسب الغرض: يحتفظ الـ CRM بالـ product offering التجاري والأسعار، ويحتفظ الـ BSS/OSS بالكتالوجات التقنية للخدمات والموارد، ويُفكَّك الطلب إلى service orders و resource orders.
يجري الإطلاق على مراحل: المبيعات الأساسية أولًا، ثم تعريف عملاء B2B والاتفاقيات، ثم عروض الأسعار و CPQ (Configure, Price, Quote)، ثم المستندات الإلكترونية والباقات ومزامنة الكتالوج متعددة القنوات.

ما القيمة

عملية أعمال واحدة بصرف النظر عن القناة.
تكفّ ترقية الـ CRM عن أن تكون مشروعًا، لأن القنوات لم تعد تتكامل مع الـ CRM مباشرة.
عمليات Lead-to-Order و Order-to-Cash مستقرة دون روابط من نقطة إلى نقطة.

ما الذي يقدّمه MEF.DEV

Enablement & Monetization Platform بوصفها بوابة دخول TM Forum Open API، مع MEF.DEV BPMN Low-code لعمليات B2B.

Architect edition — عملية بيع واحدة في كل القنوات

استبدال الـ backend من نوع legacy نفسه حالة منفصلة: استبدال backend من نوع legacy.

الموقع في ODA

على ODA Canvas تنتمي وظائف الـ CRM إلى مجال Party Management، وينتمي ما قبل البيع — العملاء المحتملون والفرص — إلى مكوّن Lead & Opportunity Management. ويبقى الـ CRM نظام السجل الرئيسي بأدنى قدر من التخصيص. ولا تصل أي قناة — بوابة الشركاء، أو تطبيق المبيعات، أو الخدمة الذاتية — إلى عمليات الـ back-end إلا عبر الواجهة (facade) على Enablement & Monetization Platform.

مكوّنات الواجهة

واجهة قياسية نقطة دخول TM Forum Open API واحدة لكل قناة.
سجل المخططات النواة والامتدادات، والإصدارات والعقود؛ وتتغير المخططات والـ mappings بالإعداد.
كتالوج منتجات البيانات نماذج Party و Sales و Quote و Agreement بوصفها منتجات، مع product owner و data steward و tech lead.
حزمة BPMN قواعد B2B خارج الـ CRM: التحقق من الشركات، والمتطلبات الضريبية المحلية، والسجلات العامة. ويشغّلها MEF.DEV BPMN Low-code بوصفها عمليات ذات إصدارات مع إعادة المحاولة والتعويض وخطوات بشرية مضبوطة.
المحوّلات يتصل الـ ERP والمستودع والـ billing عبر نقطة الدخول، لا قناةً تلو قناة.

كتالوج المنتجات الموزّع

CRM الكتالوج التجاري: ProductOffering والأسعار، تُقرأ عبر TMF620 Product Catalog.
BSS/OSS للاتصالات وغيرها الكتالوجات التقنية لـ CFS (Customer Facing Service) و RFS (Resource Facing Service)، والتنفيذ عبر TMF641 Service Order و TMF652 Resource Order Management.
التفكيك يُفكَّك الـ product order إلى service orders و resource orders وفق علاقات الكتالوج، اتباعًا لـ use case تفكيك الطلبات في TM Forum.

العقود حسب مراحل الإطلاق

المبيعات الأساسية إدارة المبيعات، من العميل المحتمل إلى الفرصة، بوصفها واجهة قائمة على BPMN؛ والسجلات في كيانات CRM القياسية؛ والقنوات عبر API gateway مع OAuth2/JWT و TLS؛ وتكامل الكتالوج التجاري للقراءة فقط.
تعريف عملاء B2B TMF632 Party، وأدوار الأطراف، والتحققات القانونية المسبقة؛ وإنشاء الحسابات وربطها عبر واجهات API القياسية للـ CRM؛ وبدء الاتفاقيات؛ والتدقيق والسجلات وإشعارات الأحداث.
الامتدادات إدارة عروض الأسعار بقواعد CPQ فوق TMF620 Product Catalog؛ والتحقق من توفر MSISDN (Mobile Station International Subscriber Directory Number) وحجزه عند الحاجة؛ ومواءمة الكتالوج مع Product و CustomerFacingService و ResourceFacingService؛ والأداء وقابلية المراقبة والأدوار والسياسات في الواجهة.
اختياري المستندات الإلكترونية والتوقيع الإلكتروني، والفاتورة الإلكترونية عبر TMF678 Customer Bill Management أو خارج TM Forum؛ والباقات وسياسات الخصم ومزامنة الكتالوج متعددة القنوات؛ والتحليلات وتنبيهات الـ SLA وتعدد المستأجرين (multi-tenancy) وواجهات API للشركاء؛ وطلب المنتجات مع التفكيك عبر TMF641 Service Order و TMF652 Resource Order Management في BSS خارجي.

إلى جانب الـ CRM والـ legacy

تعيش عمليات Lead-to-Order و Order-to-Cash بين الـ CRM والـ ERP والمستودع والـ billing خارج الـ CRM:

الموثوقية سياسات retry و rollback، وخطوات تعويضية، والـ idempotency عند المحوّلات والطوابير.
الشفافية السجلات والتتبّع والمقاييس وربط الطلبات عبر الأنظمة؛ وتدقيق الأحداث الواردة والصادرة والحمولات (payloads) والقرارات.
الأمن OAuth2/JWT، و workload identity، والتحكم في الوصول على مستوى Open API؛ ولا تُخزَّن أي أسرار في الـ CRM.
النشر في السحابة أو on-premises، مع التوسع الأفقي للمنسّق (orchestrator) والطوابير على Kubernetes.

هذا سيناريو مستهدف؛ ويُتفق على النطاق في المشروع، مرحلةً تلو مرحلة.

العمق التقني على platform.mef.dev ←

ثابت لكل القرّاء

TM Forum ODA · Open API

TM Forum ODA و Open APIs

يتيح MEF.DEV واجهات TM Forum Open APIs، ويلتزم بمبادئ ODA، وله قيد في TM Forum ODA Component Directory.

BSL 1.1

الترخيص

Business Source License 1.1: مجاني للاستخدام الإنتاجي الداخلي؛ و Enterprise Modules بمفتاح ترخيص؛ وكل إصدار يتحول إلى Apache 2.0 بعد أربع سنوات.

الاتحاد الأوروبي · on-premises · السحابة

الأمن والبيانات والولاية القضائية

شركة في الاتحاد الأوروبي؛ نشر في بنيتكم التحتية، وتسجيل دخول عبر SSO قياسي؛ تطوير وتسليم ودعم وفق نظام جودة ISO 9001:2015.

ISO 9001:2015

تطوير وأمن معتمدان

يُطوَّر WideCoup Convergent BSS و MEF.DEV ويُسلَّمان ويُدعَمان وفق نظام إدارة جودة ISO 9001:2015؛ واجتاز MEF.DEV تدقيقًا أمنيًا مستقلًا واختبار اختراق.

الشهادات والتدقيق ←