WEBVTT

00:00:00.000 --> 00:00:02.360
عندما ينقل العميل على زر الشراء في موقعك الإلكتروني

00:00:02.360 --> 00:00:04.220
قد يكون المنتج المطلوب موجوداً في مستودع

00:00:04.220 --> 00:00:06.360
أو في متجر بالمدينة أو لدى شريك توصيل

00:00:06.360 --> 00:00:09.040
لكن كل ما يتوقعه العميل حقاً هو أمران فقط

00:00:09.040 --> 00:00:11.440
وعد واضح ووصول الطرد إلى باب منزله

00:00:11.440 --> 00:00:13.000
مرحباً بكم في حلقة أخرى من برنامج

00:00:13.000 --> 00:00:15.300
Microsoft Knowledge Nuggets على M365FM

00:00:15.300 --> 00:00:15.940
أنا مو بيترز

00:00:15.940 --> 00:00:18.000
واليوم نلقي نظرة على نظام إدارة الطلبات الذكي

00:00:18.000 --> 00:00:19.960
ديناميكس 365 بلغة بسيطة

00:00:19.960 --> 00:00:23.960
سنتتبع ذلك الطلب من لحظة النقر على الدفع وصولاً إلى العمل الذي يوصله فعلياً

00:00:23.960 --> 00:00:26.900
فكر فيه كأنه مكتب التنسيق المركزي في مبنى مكاتب مزدحم

00:00:26.900 --> 00:00:28.660
إنه ليس متجراً إلكترونياً آخر

00:00:28.660 --> 00:00:30.120
ولا يقوم بتغليف الصناديق

00:00:30.120 --> 00:00:34.320
إنه يوجه الأشخاص والأنظمة المناسبة فقط ليتم العمل في المكان الصحيح

00:00:34.320 --> 00:00:36.900
لماذا تصبح الطلبات فوضويةً؟

00:00:36.900 --> 00:00:39.740
تخيل أنك تبيع نفس سماعات الرأس عبر موقعك الإلكتروني

00:00:39.740 --> 00:00:43.180
ومتاجرك الفعلية وسوق إلكتروني ومركز اتصالات

00:00:43.180 --> 00:00:46.520
بالنسبة للعميل كل هذه مجرد طرق لشراء سماعات الرأس

00:00:46.520 --> 00:00:50.680
لكن خلف الكواليس ترسل كل قناة تفاصيل الطلب إلى نظام مختلف تماماً

00:00:50.680 --> 00:00:53.800
موقعك يحتفظ بسجل ونظام نقاط البيع في المتجر يحتفظ بآخر

00:00:53.800 --> 00:00:55.760
والسوق الإلكتروني يرسل بتنسيقه الخاص

00:00:55.760 --> 00:00:58.800
وموظف مركز الاتصال ينشئ طلباً في مكان مختلف تماماً

00:00:58.800 --> 00:01:03.120
ينقسم وعد بسيط للعميل إلى أجزاء متحركة متعددة لا تتواصل مع بعضها البعض

00:01:03.120 --> 00:01:05.400
ويضيف المخزون طبقة أخرى من التعقيد

00:01:05.400 --> 00:01:07.860
قد يحتوي المستودع الرئيسي على عشرون زوجاً

00:01:07.860 --> 00:01:11.280
ولدى متجر في المدينة خمسة ومستودع آخر لديه مخزون أيضاً

00:01:11.280 --> 00:01:13.460
لكنه أبعد ومعه تكاليف شحن أعلى

00:01:13.460 --> 00:01:17.440
بعض المخزون محجوز بالفعل لطلبات أخرى أو أصناف مرتجعة أو لعملاء المتجر

00:01:17.440 --> 00:01:20.640
لذا فإن رؤية رقمي بجانب منتج لا يحل المشكلة فعلياً

00:01:20.640 --> 00:01:22.520
ثم يتعين عليك تحديد كيفية التوصيل

00:01:22.520 --> 00:01:24.180
هل يجب أن يشحنها المستودع؟

00:01:24.180 --> 00:01:25.640
هل يجب أن يشحنها المتجر؟

00:01:25.640 --> 00:01:27.500
أم يمكن للعميل استلامها محلياً؟

00:01:27.500 --> 00:01:29.880
وإذا اشترى شخص ما منتجيني ولم يمتلك موقع واحد كلاهما

00:01:29.880 --> 00:01:32.800
هل تقسم الطلب إلى طردين أن تنتظر حتى يمكن شحن كل شيء معاً؟

00:01:32.800 --> 00:01:36.140
كل خيار يؤثر على التكلفة ووقت التوصيل والوعد الذي قطعته للعميل

00:01:36.140 --> 00:01:40.180
قبل عقدين من الزمن كانت الشركات تدير هذه المهامة في أنظمة منفصلة بفرق عمل منفصلة

00:01:40.180 --> 00:01:41.640
قسم المبيعات يتلقى الطلبة

00:01:41.640 --> 00:01:42.860
شخص ما يتحقق من المخزون

00:01:42.860 --> 00:01:44.320
المستودع يتلقى طلباً

00:01:44.320 --> 00:01:45.720
شريك الشحن يتلقى طلباً آخر

00:01:45.720 --> 00:01:47.720
قسم الفواتير يتعامل مع جزئه الخاص لاحقاً

00:01:47.720 --> 00:01:50.720
كان ذلك يعمل بشكل جيد عندما كانت الطلبات بسيطة والأحجام منخفضة

00:01:50.720 --> 00:01:51.800
ولكن إليك الأمر

00:01:51.800 --> 00:01:53.560
عندما تنتقل التحديثات ببطء بين الأنظمة

00:01:53.560 --> 00:01:54.820
يبدأ البشر في سد الفجوات

00:01:54.820 --> 00:01:56.980
يتحقق موظف خدمة العملاء من شاشة واحدة

00:01:56.980 --> 00:01:58.800
ويرسل بريداً إلكترونياً لفريق المستودع

00:01:58.800 --> 00:02:00.020
ثم يتصل بشركة النقل

00:02:00.020 --> 00:02:02.680
وفي هذه الأثناء يمكن أن يباع المنتج عبر قناة أخرى

00:02:02.680 --> 00:02:04.340
قبل وصول تحديث المخزون للموقع الإلكتروني

00:02:04.340 --> 00:02:06.400
الآن لديك طلب لشيء لا يمكنك إرساله

00:02:06.400 --> 00:02:07.760
هكذا يحدث البيع الزائد

00:02:07.760 --> 00:02:10.160
وهكذا تستغرق خيارات التوصيل وقتاً طويلاً جداً

00:02:10.160 --> 00:02:11.940
تستمر الفرق في نسخ التفاصيل من مكان لآخر

00:02:11.940 --> 00:02:14.620
ويحصل العملاء على تحديثات غامضة بدلاً من إجابات حاسمة

00:02:14.620 --> 00:02:15.880
من وجهة نظر العميل

00:02:15.880 --> 00:02:19.280
لا يهم كل هذا التعقيد لأنهم يطرحون سؤالاً واحداً فقط

00:02:19.280 --> 00:02:20.300
أين طلابي؟

00:02:20.300 --> 00:02:23.300
ما تحتاجه الشركة حقاً هو مكان واحد يمكنه رؤية رحلة الطلب

00:02:23.300 --> 00:02:24.880
عبر كل تطبيقات الأعمال المتصلة

00:02:24.880 --> 00:02:27.120
بينما يواصل كل تطبيق القيام بما يتقنه

00:02:27.120 --> 00:02:28.900
المبيعات تسجل عملية البيع

00:02:28.900 --> 00:02:30.980
المستودع يدير عمليات الانتقاء والتعبئة

00:02:30.980 --> 00:02:32.220
الشحن يتولى التوصيل

00:02:32.220 --> 00:02:33.780
الفواتير تتعامل مع الأموال

00:02:33.780 --> 00:02:35.780
لا أحد بحاجة للتخلص من كل الأنظمة

00:02:35.780 --> 00:02:37.620
ما ينقصنا هو المنسق بينها

00:02:37.620 --> 00:02:38.160
أوه

00:02:38.160 --> 00:02:39.440
مكان يمكنه تلقي طلب

00:02:39.440 --> 00:02:41.540
ومعرفة ما يجب القيام به تالياً

00:02:41.540 --> 00:02:44.300
وتوجيه العمل دون الاعتماد على سلسلة من التسليمات اليدوية

00:02:44.300 --> 00:02:45.640
تلك هي المشكلة

00:02:45.640 --> 00:02:49.040
يعالج نظام إدارة الطلبات الذكي من ديناميكس 365

00:02:49.040 --> 00:02:50.520
هذا التعريف البسيط

00:02:50.520 --> 00:02:51.140
إذن

00:02:51.140 --> 00:02:54.180
ما هو نظام إدارة الطلبات الذكي من ديناميكس 365

00:02:54.180 --> 00:02:55.040
بالضبط

00:02:55.040 --> 00:02:58.720
سوف نقوم اليوم بتبسيط الأمر وشرحه بلغة واضحة

00:02:58.720 --> 00:03:00.260
إليك التعريف الأبسط

00:03:00.260 --> 00:03:02.400
إنه تطبيق سحابي يأخذ الطلب

00:03:02.400 --> 00:03:05.900
ويوجهه عبر كل الأنظمة التي تستخدمها الشركة بالفعل

00:03:05.900 --> 00:03:09.020
من لحظة وصول الطلب حتى إتمام التنفيذ والفواتير

00:03:09.020 --> 00:03:11.200
فكر في محطة قطارات مزدحمة

00:03:11.200 --> 00:03:13.340
القطارات تصل من اتجاهات مختلفة

00:03:13.340 --> 00:03:15.300
يحتاج الركاب إلى أرصفة مختلفة

00:03:15.300 --> 00:03:17.600
بعض الرحلات سريعة وأخرى تضطر للانتظار

00:03:17.600 --> 00:03:20.560
يعمل نظام إدارة الطلبات الذكي مثل غرفة التحكم في المحطة

00:03:20.560 --> 00:03:22.240
إنه لا يقود القطار ولا يبيع التذكرة

00:03:22.240 --> 00:03:25.540
لكنه يرى المسار بأكمله ويخبر كل نظام بما يجب فعله تالياً

00:03:25.540 --> 00:03:28.680
قامت مايكروسوفت ببناء نظام إدارة الطلبات الذكي فوق ديتافرس

00:03:28.680 --> 00:03:33.720
ديتافرس هو أساس البيانات المشترك وراء العديد من تطبيقات ديناميكس 365 وPower Platform

00:03:33.720 --> 00:03:34.440
ببساطة

00:03:34.440 --> 00:03:39.120
هو يمنح تطبيقات الأعمال مكاناً وحداً مشتركاً وتنسقاً وحداً لتخزين المعلومات

00:03:39.120 --> 00:03:43.060
وهذا يعني أن الطلب لا يعني شيئاً مختلفاً تماماً في كل شاشة ونظام

00:03:43.060 --> 00:03:44.280
هذا الأساس المشترك مفيد

00:03:44.280 --> 00:03:47.200
لكنك لا تحتاج لشراء كل تطبيق آخر من ديناميكس 365

00:03:47.200 --> 00:03:48.980
لاستخدام نظام إدارة الطلبات الذكي

00:03:48.980 --> 00:03:53.000
قد تدير شركة ما نظام ديناميكس 365 للكمويل أو لإدارة سلاسل الإمداد

00:03:53.000 --> 00:03:57.140
وقد تستخدم شركة أخرى نظام مستودعة مختلفاً أو متجراً إلكترونياً مختلفاً

00:03:57.140 --> 00:03:58.420
أو خدمة شحن من مورد آخر

00:03:58.420 --> 00:04:01.860
يمكن لهذا التطبيق العمل مع تطبيقات الأعمال من مايكروسوفت وغيرها

00:04:01.860 --> 00:04:04.160
تسمى نقاط الاتصال هذه بالمزودات

00:04:04.160 --> 00:04:08.760
ينقل المزود معلومات الطلب والتنفيذ بين نظام إدارة الطلبات الذكي ونظام آخر

00:04:08.760 --> 00:04:11.040
فكر في المزود كمترجم عند الباب

00:04:11.040 --> 00:04:13.340
يرسل نظام ما طلباً بتنسيقه الخاص

00:04:13.340 --> 00:04:17.360
يفهم المزود هذا التنسيق ويمرر المعلومات إلى نظام إدارة الطلبات الذكي

00:04:17.360 --> 00:04:20.740
ويمكنه إرسال الطلب التالي للخارج بتنسيق يفهمه النظام الآخر

00:04:20.740 --> 00:04:24.700
إذن يقوم التطبيق بتجميع معلومات الطلبات معاً حتى لو بدأ الطلب من مكان آخر

00:04:24.700 --> 00:04:27.700
قد يشتري عميل ما من خلال موقع تجارة إلكترونية موحدة

00:04:27.700 --> 00:04:30.180
وقد يضع آخر طلباً عبر نظام نقاط البيع

00:04:30.180 --> 00:04:34.240
بإمكان عميل انتجاري إرسال طلب إلكتروني عبر عملية تبادل انتجاري بين الشركات

00:04:34.240 --> 00:04:37.360
تمنح إدارة الطلبات الذكية شركة مكاناً وحداً لمشاهدة تلك الطلبات

00:04:37.360 --> 00:04:39.320
ومعرفة موقع كل منها في عملية التنفيذ

00:04:39.320 --> 00:04:41.340
ليست كل الطلبات تتبجع نفس المسار

00:04:41.340 --> 00:04:43.060
قد ينتظر أحدها توفر المخزون

00:04:43.060 --> 00:04:45.060
وقد يكون آخر موجوداً بالفعل في المستودع

00:04:45.060 --> 00:04:47.520
وقد يحتاج طلب ثالث إلى خطوة فترة بعد التسليم

00:04:47.520 --> 00:04:51.200
يتتبع التطبيق هذه الحالة ليرى الفريق أكثر من مجرد تم استلام الطلب

00:04:51.200 --> 00:04:53.860
يمكنهم معرفة مكان الطلب بالضبط في رحلته

00:04:53.860 --> 00:04:56.460
هنا الجزء الذي قد يغفله الناس أحياناً

00:04:56.460 --> 00:04:59.080
إدارة الطلبات الذكية لا تتولى كل المهام

00:04:59.080 --> 00:05:01.980
فهي لا تتحول فجأة إلى شاشة انتقاء عمال المستودع

00:05:01.980 --> 00:05:05.080
أو شبكة تسليم ناقل أو نظام فواتير الفريق المالي

00:05:05.080 --> 00:05:08.020
تلك التطبيقات المتصلة لا تزال تقوم بعملها المتخصص

00:05:08.020 --> 00:05:11.240
تقوم إدارة الطلبات الذكية بتوجيه عمليات التسليم بينها

00:05:11.240 --> 00:05:13.620
فهي تستقبل الطلبة وتتحقق من المسار

00:05:13.620 --> 00:05:16.140
وتمرر العمل ثم تنتظر التحديث التالي

00:05:16.140 --> 00:05:18.760
الآن دعونا نتابع طلباً وحداً عبر هذا المسار

00:05:18.760 --> 00:05:21.800
لأن رحلة الطلب تجعل الفكرة بأكملها أسهل في الفهم

00:05:21.800 --> 00:05:24.740
قواعد رحلة الطلب هي التي توجه العمل

00:05:24.740 --> 00:05:29.440
تخيل أن عميلاً طلب عنصرين من موقعك في وقت متأخر من بعض الظهر

00:05:29.440 --> 00:05:31.140
ويريد تسليمهما غداً

00:05:31.140 --> 00:05:32.840
يلتقط المتجر الإلكتروني الطلب

00:05:32.840 --> 00:05:33.760
اسم العميل

00:05:33.760 --> 00:05:34.920
عنوان التسليم

00:05:34.920 --> 00:05:35.740
سطري الطلب

00:05:35.740 --> 00:05:36.960
وخيار التسليم

00:05:36.960 --> 00:05:40.360
يقوم مزود بإدخال هذا الطلب إلى نظام إدارة الطلبات الذكية

00:05:40.360 --> 00:05:41.380
لتبدأ رحلة الطلب

00:05:41.380 --> 00:05:43.180
قبل أن يحاول أي شخص تنفيذه

00:05:43.180 --> 00:05:46.960
يتحقق النظام من الطلب لضمان وجود كافة المعلومات اللازمة للرحلة

00:05:46.960 --> 00:05:48.400
واتباعها لقواعد الشركة

00:05:48.400 --> 00:05:51.560
يتحقق النظام من ترويسة الطلب للحصول على تفاصيل العميل والتسليم

00:05:51.560 --> 00:05:54.100
ويتحقق من كل سطر للتأكد من المنتج والكمية

00:05:54.100 --> 00:05:56.380
ويؤكد أن العنوان يحتوي على معلومات كافية للتسليم

00:05:57.000 --> 00:05:59.220
ويضمن مطابقة الطلب لقواعد قناة البيع تلك

00:05:59.220 --> 00:06:02.800
هذا الفحص الأول يمنع المعلومات الخاطئة من الانتقال إلى المراحل التالية

00:06:02.800 --> 00:06:03.900
قبل أن تسبب مشاكل

00:06:03.900 --> 00:06:06.160
تخيل طلبا يفتقد لرقم الشقة

00:06:06.160 --> 00:06:08.800
إذا ذهب الطلب مباشرة إلى المستودع ثم إلى الناقل

00:06:08.800 --> 00:06:11.780
قد يكتشف شخص ما المشكلة فقط بعد تعذل تسليم الطرد

00:06:11.780 --> 00:06:14.140
تعمل خطوة التحقق على كشف المشكلة مبكرا

00:06:14.140 --> 00:06:17.080
بينما لا يزال هناك وقت للاتصال بالعميل أو تعليق الطلب

00:06:17.080 --> 00:06:19.700
أساس هذا العمل يكمن في تدفق التنظيم

00:06:19.700 --> 00:06:22.600
هذه العبارة تبدو تقنية لكنها بسيطة

00:06:22.600 --> 00:06:26.120
تدفق التنظيم هو خريطة مرئية تخبر نظام إدارة الطلبات الذكية

00:06:26.120 --> 00:06:29.960
بما يجب فعله عند وصول معلومات الطلب وعودة الأحداث من الأنظمة المتصلة

00:06:29.960 --> 00:06:32.720
أن تنشئ تلك الخريطة حول عمليات عملك الخاصة

00:06:32.720 --> 00:06:35.380
قد يبدأ تدفق الطلب الأساسي عند وصول طلب جديد

00:06:35.380 --> 00:06:37.360
يقوم بالتحقق من العنوان والأسطر

00:06:37.360 --> 00:06:39.460
يرسل الطلب لاتخاذ قرارات التنفيذ

00:06:39.460 --> 00:06:42.480
بعد ذلك يرسل أمر التنفيذ إلى النظام المتصل المناسب

00:06:42.480 --> 00:06:44.340
بمجرد وصول العمل إلى المرحلة الصحيحة

00:06:44.340 --> 00:06:46.400
يمكنه إرسال معلومات الطلب إلى مزود الفواتير

00:06:46.400 --> 00:06:48.240
كل إجراء له مهمة واضحة

00:06:48.240 --> 00:06:51.080
التحقق من رأس الطلب يفحص تفاصيل الطلب الرئيسية

00:06:51.080 --> 00:06:54.340
التحقق من سطر الطلب يفحص المنتجات الفردية والكميات

00:06:54.340 --> 00:06:58.520
الإرسال للتنفيذ يمرر أمر التنفيذ إلى المزود الذي يتولى تلك المهمة

00:06:58.520 --> 00:07:01.860
الإرسال للفاتورة يمرر معلومات الطلب إلى مزود الفواتير

00:07:01.860 --> 00:07:04.340
تبدو الأسماء كأنها ملصقات على لوحة تحكم مصنع

00:07:04.340 --> 00:07:08.280
وهذا مفيد لأن كل ملصق يخبرك بالضبط بما يحدث في تلك النقطة من المسار

00:07:08.280 --> 00:07:11.640
لكن الأعمال الواقعية تحتاج غالبا إلى أكثر من مسار مستقيم واحد

00:07:11.640 --> 00:07:15.920
ربما تتبع الطلبات الواردة من الموقع الإلكتروني مسارا وحدا بينما يتبع عملاء الأعمال مسارا آخر

00:07:15.920 --> 00:07:18.500
ربما يحتاج نوع معين من المنتجات إلى موافقة خاصة

00:07:18.500 --> 00:07:21.440
ربما لا يمكن للطلب المضي قدما إلا إذا نجحت الخطوة الأولى

00:07:21.440 --> 00:07:24.400
تتضمن الإدارة الذكية للطلبات شروطا لهذا النوع من الخيارات

00:07:24.400 --> 00:07:27.000
ينشئ الشرط مسارا للموافقة ومسارا للرفض

00:07:27.000 --> 00:07:30.600
إذا نجح الإجراء السابق يمكن للطلب الاستمرار عبر مسار الموافقة

00:07:30.600 --> 00:07:33.920
وإذا فشل يمكن للتدفق توجيه الطلب إلى مسار مختلف

00:07:33.920 --> 00:07:36.020
هذا لا يحل كل مشكلة بحد ذاته

00:07:36.020 --> 00:07:40.420
لكنه يمنح العملية استجابة مخططة بدلا من ترك الفريق يكتشف الخطأ بالصدفة

00:07:40.420 --> 00:07:42.120
توجد أيضا أدوات التقسيم

00:07:42.120 --> 00:07:45.720
تقوم أداة التقسيم بإرسال التدفق إلى أكثر من مسار بناء على قواعد تحددها

00:07:45.720 --> 00:07:49.100
قد تستخدم واحدة عندما تحتاج الطلبات من مصادر منفصلة إلى فحوصات مختلفة

00:07:49.100 --> 00:07:51.540
أو عندما تحتاج أجزاء مختلفة من العمل إلى مسارات مختلفة

00:07:51.540 --> 00:07:53.840
بعض المسارات المنقسمة يمكن أن تعود للارتقاء لاحقا

00:07:53.840 --> 00:07:55.360
بينما يستمر البعض الآخر بمفرده

00:07:55.360 --> 00:07:58.320
تغطي الإجراءات المخصصة المهام الفريدة لكل عمل تجاري

00:07:58.320 --> 00:08:02.960
ربما تمتلك الشركة نظام تصنيع خاص بها أو نظام شريك لا يغطيه إجراء قياسي

00:08:02.960 --> 00:08:05.180
يمكن لإجراء مخصص ربط تلك الخطوة بتدفق الطلب

00:08:05.180 --> 00:08:09.560
بحيث يظل المسار يعرض العملية الكاملة بدلا من إخفاء جزء منها في رسائل البريد الإلكتروني أو العمل اليدوي

00:08:09.560 --> 00:08:11.800
دعونا نعد إلى طلبنا المكون من عنصرين

00:08:11.800 --> 00:08:16.000
يستقبل النظام الطلب من الموقع الإلكتروني ويتحقق من تفاصيل العميل والعنوان وخطوط المنتجات

00:08:16.000 --> 00:08:18.600
يصل الطلب بعد ذلك إلى خطوة قرار التنفيذ

00:08:18.600 --> 00:08:20.800
إذا كان بإمكان كلا العنصرين اتباع نفس المسار

00:08:20.800 --> 00:08:23.940
يمكن للتدفق إرسال طلب التنفيذ إلى الأمام كوحدة واحدة

00:08:23.940 --> 00:08:26.300
إذا كانت قواعد الشركة تتطلب نتيجة مختلفة

00:08:26.300 --> 00:08:27.840
يمكن للطلب اتخاذ مسار آخر

00:08:27.840 --> 00:08:30.060
ربما يحتاج العنصران إلى طلبات تنفيذ منفصلة

00:08:30.060 --> 00:08:32.060
أو ربما يحتاج الطلب إلى خيار توصيل مختلف

00:08:32.060 --> 00:08:33.900
التدفق لا يعتمد على التخمين

00:08:33.900 --> 00:08:37.820
إنه يتبع القواعد التي أنشأتها الشركة والأحداث التي تعيدها الأنظمة المتصلة

00:08:37.820 --> 00:08:39.220
هذا الجزء الأخير مهم

00:08:39.220 --> 00:08:41.480
يمكن للإدارة الذكية للطلبات توجيه العمل

00:08:41.480 --> 00:08:44.240
لكن الأنظمة المتصلة تقدم تقاريرها مع تقدم العمل

00:08:44.240 --> 00:08:46.600
يمكن لمزود خدمات التنفيذ استلام الطلب

00:08:46.600 --> 00:08:49.360
يمكن لمزود خدمات الفترة استلام تفاصيل الطلب

00:08:49.360 --> 00:08:52.340
تحافظ هذه الأحداث على استمرار مسار الطلب خلال التدفق

00:08:52.340 --> 00:08:55.180
إذن التطبيق ليس نظاماً بديلاً ضخماً وحداً

00:08:55.180 --> 00:08:57.180
إنه مجموعة من القواعد التي تربط المتخصصين

00:08:57.180 --> 00:08:59.380
وتمنح كل نظام العمل الذي يحتاجه في الوقت المناسب

00:08:59.380 --> 00:09:01.180
يسجل المتجر الإلكتروني الطلب

00:09:01.180 --> 00:09:03.280
يتولى نظام التنفيذ عملية التنفيذ

00:09:03.280 --> 00:09:05.340
يتولى نظام الفوترة عملية الفوترة

00:09:05.340 --> 00:09:08.380
تتولى الإدارة الذكية للطلبات إدارة المسار بين تلك المهام

00:09:08.380 --> 00:09:10.400
يمكن للأشخاص المسؤولين عن عملية الطلب

00:09:10.400 --> 00:09:12.480
تصميم هذه التدفقات مباشرة في التطبيق

00:09:12.480 --> 00:09:15.180
لا يحتاجنا إلى كتابة كل مسار ككود برمجي تقليدي

00:09:15.180 --> 00:09:18.580
ولا يحتاجنا لطلب تغيير كل قاعدة عمل من مسؤول تكنولوجيا المعلومات

00:09:18.580 --> 00:09:22.100
يمنح ذلك فريق سلسلة التوريد طريقة لنمذجة العملية التي يحتاجنها بالفعل

00:09:22.100 --> 00:09:24.220
مع ذلك تتطلب هذه التغييرات عناية

00:09:24.220 --> 00:09:27.620
يظل تدفق التنسيق غير منشور أثناء قيامك ببنائه واختباره

00:09:27.620 --> 00:09:30.800
خلال هذه المرحلة لا تمر البيانات الواردة عبر التدفق

00:09:30.800 --> 00:09:34.720
بمجرد نشره يعمل التدفق وإجراءاته عند دخول البيانات إلى النظام

00:09:34.720 --> 00:09:37.920
بعد النشر لا يمكنك تعديل ذلك التدفق المنشور مباشرة

00:09:37.920 --> 00:09:41.060
إذا احتاج العمل إلى تغيير يمكن للفريق إيقاف التدفق المنشور

00:09:41.060 --> 00:09:42.900
مما يعيده إلى حالة غير منشورة

00:09:42.900 --> 00:09:46.140
يمكنهم تعديل التدفق ثم نشر الإصدار الجديد عندما يصبح جاهزا

00:09:46.140 --> 00:09:49.920
يدفع هذا الإعداد الفرق لاختبار المسار قبل أن تمر عبره الطلبات الحقيقية

00:09:49.920 --> 00:09:53.140
لا يعمل المسار إلا إذا كان يعرف المخزون المتاح بالفعل

00:09:53.140 --> 00:09:57.240
يقودنا هذا إلى معلومات المخزون المباشرة وراء كل قرار تنفيذ

00:09:57.240 --> 00:10:00.780
رؤية المخزون معرفة ما يمكنك بيعه فعليا

00:10:00.780 --> 00:10:03.100
إليك حقيقة واضحة وبسيطة

00:10:03.100 --> 00:10:05.900
لا يمكنك تنفيذ طلب إذا كنت لا تعرف أن لديك المخزون

00:10:05.900 --> 00:10:06.820
يبدو الأمر بديهينا

00:10:06.820 --> 00:10:12.320
لكن المخزون قد يختبئ في مستودع أو متجر أو موقع شريك أو عبر كينات قانونية مختلفة داخل الشركة نفسها

00:10:12.320 --> 00:10:15.760
عندما يحتفظ كل موقع بسجله الخاص لا يمكنك الإجابة على السؤال الأساسي

00:10:15.760 --> 00:10:17.640
ما الذي يمكنني وعد هذا العميل به الآن؟

00:10:17.640 --> 00:10:22.420
تمنح رؤية المخزون الإدارة الذكية للطلبات نظرة مباشرة على كل ذلك المخزون عبر شبكة التوريد الخاصة بك

00:10:22.420 --> 00:10:25.140
فكر في الأمر كلوحة مخزون في مركز توزيعي

00:10:25.140 --> 00:10:27.700
بدلا من الاتصال بكل رفن وطلب التحقق من شخص ما

00:10:27.700 --> 00:10:31.100
تنظر عملية الطلب إلى عرض مشترك واحد تغذيه جميع أنظمتك

00:10:31.100 --> 00:10:35.540
الآن مجرد ظهور عنصر كمخزون في مكان ما لا يعني أنه يمكنه تلبية كل طلب

00:10:35.540 --> 00:10:38.400
قد يكون المنتج موجودا في مستودع ولكنه محجوز بالفعل

00:10:38.400 --> 00:10:41.140
أو في متجر يمكنه البيع محليا لكنه لا يستطيع الشحن

00:10:41.140 --> 00:10:44.300
أو ببساطة بعيد جدا عن الوفاء بوعد التسليم الذي اختاره العميل

00:10:44.300 --> 00:10:49.380
هناك فرق كبير بين مخزون موجود في مكان ما ومخزون يمكنه تلبية هذا الطلب في الوقت الحالي

00:10:49.380 --> 00:10:52.560
تخيل أن عميلا اشترى سترة عبر الإنترنت ويريدها غدا

00:10:52.560 --> 00:10:55.120
مستودعك الرئيسي لا يملك أي مخزون منها

00:10:55.120 --> 00:10:59.080
بدون بيانات مخزون محدثة قد يقبل موقعك الطلب بناء على أرقام قديمة

00:10:59.080 --> 00:11:01.860
ثم يتلقى المستودع طلبا لشيء لا يمكنه إرساله

00:11:01.860 --> 00:11:04.220
ليكتشف العميل ذلك بعد إتمام عملية الشراء

00:11:04.220 --> 00:11:06.340
هذا يخلق عملا إضافيا للجميع

00:11:06.340 --> 00:11:08.040
مع معلومات المخزون المترابطة

00:11:08.040 --> 00:11:11.480
يرى نظام إدارة الطلبات الذكي أن المستودع الرئيسي ليس لديه السترة

00:11:11.480 --> 00:11:13.100
لكن متجرا قريبا يملكها

00:11:13.100 --> 00:11:14.740
إذا كان ذلك المتجر يدعم الشحن

00:11:14.740 --> 00:11:16.000
فيمكنه تنفيذ الطلب

00:11:16.000 --> 00:11:17.220
إذا اختار العميل الاستلام

00:11:17.220 --> 00:11:19.560
يصبح ذلك المتجر نفسه هو موقع الاستلام

00:11:19.560 --> 00:11:21.820
يبدأ القرار برؤية أفضل للمخزون

00:11:21.820 --> 00:11:24.180
بالنسبة لشركة لديها كيانات قانونية متعددة

00:11:24.180 --> 00:11:26.480
تغطي هذه الرؤية المخزون عبر جميع تلك الكيانات

00:11:26.480 --> 00:11:29.600
هذا مهم عندما تعمل في أكثر من بلد أو منطقة أو وحدة أعمال

00:11:29.600 --> 00:11:32.020
حيث لا يقتصر المخزون على سجلات واحدة فقط

00:11:32.020 --> 00:11:34.600
تستخدم عملية الطلب بيانات المخزون في الوقت الفعلي

00:11:34.600 --> 00:11:36.340
عند تحديد المسار الواجب أتخاذه

00:11:36.340 --> 00:11:39.320
لا يزال المستودع أو المتجر أو أي مصدر مخزون آخر

00:11:39.320 --> 00:11:41.000
يدير سجلات مخزونه الخاصة

00:11:41.000 --> 00:11:43.000
توفر رؤية المخزون الأرقام الحالية

00:11:43.000 --> 00:11:44.560
تضمن عملية الطلبات الأوسع

00:11:44.560 --> 00:11:46.600
حيث يمكن لقواعد التنفيذ استخدامها

00:11:46.600 --> 00:11:49.260
هذا يساعدك على تجنب الوعود بناء على بيانات الأمس

00:11:49.260 --> 00:11:51.120
ويمنح خدمة العملاء إجابة واضحة

00:11:51.120 --> 00:11:54.020
عندما يسأل شخص ما عما إذا كان المنتج سيصل في الوقت المحدد

00:11:54.020 --> 00:11:57.180
بدلا من البحث في عدة أنظمة والاعتماد على تطابق المعلومات

00:11:57.180 --> 00:12:00.240
يرى فريق الطلبات حالة المخزون التي وجهت اختيار التنفيذ

00:12:00.240 --> 00:12:03.800
بالطبع رؤية جميع المواقع الممكنة لا تجيب على كل الأسئلة

00:12:03.800 --> 00:12:06.360
قد تجد المنتج في خمسة مواقع مختلفة

00:12:06.360 --> 00:12:07.540
واحد الأقرب للعميل

00:12:07.540 --> 00:12:09.080
وآخر لديه مخزون أكبر

00:12:09.080 --> 00:12:11.220
وثالث يتيح لك شحن المنتجين معا

00:12:11.220 --> 00:12:14.040
لا يزال هناك حاجة لشخص أو شيء ما لاتخاذ القرار

00:12:14.040 --> 00:12:17.020
تلك المهمة تقع على عاتق تحسين التنفيذ

00:12:17.020 --> 00:12:19.220
التنفيذ

00:12:19.220 --> 00:12:21.000
التحسين

00:12:21.000 --> 00:12:24.080
اختيار أفضل مكان للشحن من أجل التنفيذ

00:12:24.080 --> 00:12:26.540
يقوم التحسين بمقارنة المواقع الممكنة للطلب

00:12:26.540 --> 00:12:29.800
واختيار موقع واحد بناء على القواعد التي تضعها شركتك

00:12:29.800 --> 00:12:30.440
ببساطة

00:12:30.440 --> 00:12:31.640
هو يجيب على سؤال

00:12:31.640 --> 00:12:33.600
من أين يجب أن يأتي هذا الطلب؟

00:12:33.600 --> 00:12:35.620
الأفضل لا يعني دائما الأقرب

00:12:35.620 --> 00:12:37.140
قد يمتلك المتجر الأقرب المنتج

00:12:37.140 --> 00:12:39.200
لكن الشحن منه قد يكون أكثر تكلفة

00:12:39.200 --> 00:12:41.780
قد يمتلك مستودع أبعد المنتجين جاهزين للتعبئة معا

00:12:41.780 --> 00:12:43.260
وقد يمتلك موقع آخر مخزونا

00:12:43.260 --> 00:12:45.880
لكنه لا يستطيع الالتزام بتاريخ التسليم الذي اختاره العميل

00:12:45.880 --> 00:12:49.020
يجب على كل شركة أن تقرر ما تريد أن تفضله في قواعدها

00:12:49.020 --> 00:12:51.480
تضع بعض الشركات سرعة التسليم في المقام الأول

00:12:51.480 --> 00:12:53.440
أخرى تريد خفض تكاليف الشحن

00:12:53.440 --> 00:12:57.100
قد ترغب شركة أيضا في حماية مخزون المتجر للعملاء الذين يزورونه فعليا

00:12:57.100 --> 00:13:00.500
أو تجنب تقسيم الطلب إلى عدة طرود ما لم يكن هناك خيار آخر

00:13:00.500 --> 00:13:04.520
تستخدم إدارة الطلبات الذكية استراتيجيات تنفيذ تعكس تلك الخيارات

00:13:04.520 --> 00:13:07.040
فكر في الأمر كاختيار مسار لشاحنة توصيل

00:13:07.040 --> 00:13:12.200
قد لا يكون أقصر طريق هو الأسرع لوجود ازدحام مرور أو أعمال طرق أو توقف يستغرق وقتا أطول

00:13:12.200 --> 00:13:17.300
وبالمثل قد لا يكون المبنى الأقرب هو الأفضل للتنفيذ عند الأخذ في الاعتبار تكلفة المخزون

00:13:17.300 --> 00:13:19.540
ووعود الخدمة وخيارات التوصيل

00:13:19.540 --> 00:13:22.460
لنعد إلى العميل الذي اشترى غرضين عبر الإنترنت

00:13:22.460 --> 00:13:25.180
يوجد الغرض الأول في متجر يبعد عشر دقائق فقط

00:13:25.180 --> 00:13:28.420
يحتوي المستودع على الغرضين معا لكنه يقع في مكان أبعد

00:13:28.420 --> 00:13:31.260
إذا شحن المتجر الغرض الأول والمستودع الغرض الثاني

00:13:31.260 --> 00:13:34.160
فقد يتلقى العميل طردين يصلان في الموعد المحدد

00:13:34.160 --> 00:13:36.020
لكن هذا يرفع تكاليف الشحن

00:13:36.020 --> 00:13:38.640
قد يتمكن المستودع من إرسال الغرضين معا

00:13:38.640 --> 00:13:41.040
إذا كان بإمكانه الالتزام بموعد التوصيل الموعودي

00:13:41.040 --> 00:13:43.460
فقد يكون طرد واحد من ذلك الموقع هو الخيار الأفضل

00:13:43.460 --> 00:13:46.740
يمكن للقاعدة أن تفضل شحنات أقل وتكلفة شحن أدنى

00:13:46.740 --> 00:13:49.460
لكن إذا كان التوصيل غدا أهم من شحن الغرضين معا

00:13:49.460 --> 00:13:52.160
فقد يختار النظام المتجر لغرض والمستودع للآخر

00:13:52.160 --> 00:13:53.980
وهذا ما يسمى بطلب مجزأ

00:13:53.980 --> 00:13:56.160
الطلب المجزأ لا يعني فشل النظام

00:13:56.160 --> 00:14:00.880
قد يكون هذا هو الخيار المخطط له عندما لا يستطيع أي موقع بمفرده تنفيذ الطلب بالكامل بطريقة صحيحة

00:14:00.880 --> 00:14:04.960
تقرر الشركة متى يكون التجزئة منطقيا من خلال استراتيجية التنفيذ التي تضعها

00:14:04.960 --> 00:14:07.840
نفس المنطق يدعم الشراء عبر الإنترنت والشحن من المتجر

00:14:07.840 --> 00:14:09.540
يضع العميل طلبا على الموقع الإلكتروني

00:14:09.540 --> 00:14:12.720
لكن متجرا قريبا منه يمتلك المخزون المناسب ويمكنه إرساله بسرعة

00:14:12.720 --> 00:14:16.460
لذا يصبح ذلك المتجر مصدر التنفيذ رغم أن العميل لم يزره قط

00:14:16.460 --> 00:14:19.720
كما يدعم الشراء عبر الإنترنت والاستلام من المتجر

00:14:19.720 --> 00:14:24.960
يستخدم النظام معلومات المخزون والموقع للعثور على متجر يمكنه تجهيز الطلب للاستلام

00:14:24.960 --> 00:14:30.120
فيحصل العميل على خيار الاستلام المحلي بينما توجه الشركة الطلب للمكان الصحيح

00:14:30.120 --> 00:14:34.200
لا يجب أن تكون هذه الخيارات منفصلة داخل كل قناة مبيعات

00:14:34.200 --> 00:14:41.060
بدون عملية قرار تنفيذ مشتركة قد تحتاج كل من المواقع الإلكترونية والأسواق ومراكز الاتصال إلى قواعد توجيه خاصة بها

00:14:41.060 --> 00:14:45.180
عندما تغير الشركة سياسة الشحن الخاصة بها أو تبدأ في استخدام المتاجر للتنفيذ

00:14:45.180 --> 00:14:47.240
قد تحتاج الفرق لتحديث عدة أنظمة

00:14:47.240 --> 00:14:51.340
يعمل تحسين التنفيذ على وضع عملية القرار تلك في مكان واحد ضمن رحلة الطلب

00:14:51.340 --> 00:14:56.740
يستمر الموقع الإلكتروني في استقبال الطلبات وتستمر الأسواق في استقبال الطلبات ويستمر المتجر في بيع المنتجات

00:14:56.740 --> 00:15:01.500
لكن يمكن للشركة تغيير كيفية اختيار موقع التنفيذ دون إعادة بناء القواعد داخل كل قناة

00:15:01.500 --> 00:15:07.040
مما يمنحك تحكماً أكبر عند تحرك المخزون أو تغير وعود التوصيل أو توفر خيار تنفيذ جديد

00:15:07.040 --> 00:15:13.380
ومع ذلك لا يمكن لاستراتيجية التنفيذ مقارنة المواقع إلا إذا وصلت المعلومات المطلوبة من الأنظمة المسؤولة عنها

00:15:13.380 --> 00:15:19.840
يجب أن تصل الطلبات وتحديثات المخزون وأن يتلقى شركاء التنفيذ مهمهم ويقدم تقارير عن التقدم المحرز

00:15:19.840 --> 00:15:22.500
يعتمد عمل ذلك الاتصال على الموفرين

00:15:22.500 --> 00:15:26.160
الموفرون والاتصالات هي الأبواب المؤدية إلى المبنى

00:15:26.160 --> 00:15:28.220
لكي يقوم نظام إدارة الطلبات الذكي بعمله

00:15:28.220 --> 00:15:30.960
يحتاج إلى طريقة موثوقة للتواصل مع كل ما يحيط به

00:15:30.960 --> 00:15:33.340
الموفرون هم من يجعلون ذلك ممكناً

00:15:33.340 --> 00:15:39.080
الموفر هو ببساطة اتصال ينقل تفاصيل الطلب وتحديثات التنفيذ بين نظام إدارة الطلبات الذكي ونظام آخر

00:15:39.080 --> 00:15:43.040
تتدفق المعلومات في كلا الاتجاهين حتى لا يضطر أحد لنسخ أي شيء يدوياً

00:15:43.040 --> 00:15:45.140
تخيل مبنىً به العديد من أبواب التوصيل

00:15:45.140 --> 00:15:47.840
باب واحد يستقبل الطلبات من متجرك عبر الإنترنت

00:15:47.840 --> 00:15:50.020
آخر يتصل بنظام المخزون الخاص بك

00:15:50.020 --> 00:15:52.860
وثالث يرسل المهام إلى مستودع أو شريك توصيل

00:15:52.860 --> 00:15:54.340
كل باب له غرض واضح

00:15:54.340 --> 00:15:57.520
ويدير الموفرون المعلومات التي تمر عبر كل باب منها

00:15:57.520 --> 00:16:00.180
تبني مايكروسوفت بعض هذه الموصلات بنفسها

00:16:00.180 --> 00:16:02.240
يسمونها موفر الطرف الأولى

00:16:02.240 --> 00:16:04.440
وهي تربط نظام إدارة الطلبات الذكي بتطبيقات مثل

00:16:04.440 --> 00:16:05.360
ديناميكس 365

00:16:05.360 --> 00:16:07.200
سو بليت شين ماناجمنت أو ديناميكس 365

00:16:07.200 --> 00:16:13.240
تستخدم خدمات المخزون والتنفيذ داخل نظام إدارة الطلبات الذكي

00:16:13.240 --> 00:16:15.280
هؤلاء الموفرين أيضاً لتبادل البيانات

00:16:15.280 --> 00:16:17.840
والآن من المحتمل أن لديك أنظمة أخرى بالفعل

00:16:17.840 --> 00:16:19.740
وهنا يأتي دور موفر الطرف الثالث

00:16:19.740 --> 00:16:21.720
إنهم يربطون الخدمات التي لا تبنيها مايكروسوفت

00:16:21.720 --> 00:16:24.040
ربما تكون منصة التجارة الإلكترونية الحالية الخاصة بك

00:16:24.040 --> 00:16:26.540
أو سقناً أو شركة لوجستية أو نظام مستودعة

00:16:26.540 --> 00:16:29.080
الهدف ليس إجبارك على استخدام مجموعة واحدة من التطبيقات

00:16:29.080 --> 00:16:29.580
أوه

00:16:29.580 --> 00:16:32.480
الهدف هو السماح لك بربط الأنظمة التي تناسب عملك بالفعل

00:16:32.480 --> 00:16:35.960
خلف الكواليس يستخدم هؤلاء الموفرون مواصلات Power Automate

00:16:35.960 --> 00:16:38.660
تمتلك منصة Power Platform أكثر من 200 موصل جاهز

00:16:38.660 --> 00:16:40.400
لذا لديك الكثير من نقاط البداية

00:16:40.400 --> 00:16:41.720
وإذا لم يناسبك أي منها

00:16:41.720 --> 00:16:43.880
يمكنك أنت أو شريكك بناء المفر الخاص بك

00:16:43.880 --> 00:16:46.100
يستمر كل تطبيق متصل في القيام بعمله الخاص

00:16:46.100 --> 00:16:48.160
متجرك عبر الإنترنت يسجل عملية الشراء

00:16:48.160 --> 00:16:50.180
نظام المخزون يتتبع مستويات المخزون

00:16:50.180 --> 00:16:52.520
شريك التنفيذ يقوم بتعبئة الطلب وتوصيله

00:16:52.520 --> 00:16:54.640
نظام الفواتير يتعامل مع الشؤون المالية

00:16:54.640 --> 00:16:56.260
يقوم نظام إدارة الطلبات الذكي

00:16:56.260 --> 00:16:58.440
بتنسيق الرسائل والخطوات التالية بينها جميعا

00:16:58.440 --> 00:17:00.320
بمجرد مشاركة تلك الأنظمة للتحديثات

00:17:00.320 --> 00:17:03.020
يمكن لشركتك رؤية ما يحدث عبر عملية الطلب بأكملها

00:17:03.020 --> 00:17:05.960
لا مزيد من مطاردة المعلومات عبر شاشات منفصلة

00:17:05.960 --> 00:17:07.160
أو رؤى متفرقة

00:17:07.160 --> 00:17:09.020
بل صورة أكبر للمشهد

00:17:09.020 --> 00:17:12.840
تمنحك هذه المعلومات المشتركة صورة أوضحة بكثير لعملية طلباتك

00:17:12.840 --> 00:17:14.500
يتضمن نظام إدارة الطلبات الذكي

00:17:14.500 --> 00:17:17.900
لوحات معلومات باور بي التي تجمع مقاييس الطلبات والتنفيذ في مكان واحد

00:17:17.900 --> 00:17:21.000
يمكن لخدمة العملاء العثور على الطلبات التي توقفت عن الحركة

00:17:21.000 --> 00:17:24.040
يمكن للعمليات تحديد المسارات المسدودة أو تأخيرات التنفيذ

00:17:24.040 --> 00:17:27.240
ويمكن لقادة الأعمال البحث عن أنماط عبر العملية بأكملها

00:17:27.240 --> 00:17:30.480
بدون تلك الرؤية قد يبدو التأخير مشكلة معزولة

00:17:30.480 --> 00:17:35.880
ولكن عندما تجتمع البيانات قد يلاحظ فريقك أن العديد من الطلبات تتبطأ لدى شريك تنفيذ معين

00:17:35.880 --> 00:17:38.960
أو أنخيار توصيل معين يخلق استثناءات أكثر من المتوقع

00:17:38.960 --> 00:17:41.140
لا تقوم لوحة المعلومات بحل المشكلة بمفردها

00:17:41.140 --> 00:17:43.600
لكنها تساعد الأشخاص على معرفة أين يبحثون بالضبط

00:17:43.600 --> 00:17:45.740
لنعدى بذاكرتنا إلى مبنى المكاتب

00:17:45.740 --> 00:17:49.140
تجمع إدارة الطلبات الذكية بين مكتب الاستقبال الذي يتلقى الطلبات

00:17:49.140 --> 00:17:51.380
ولوحة المخزون التي توضح المتاحة

00:17:51.380 --> 00:17:53.520
ومخطط المسار الذي يحدد موقع التنفيذ

00:17:53.520 --> 00:17:56.320
وغرفة التقارير حيث يمكن للفرق متابعة سير العمل

00:17:56.320 --> 00:17:58.220
لكل جزء وظيفة مختلفة

00:17:58.220 --> 00:18:00.580
لكن الطلبة هو ما يربط بينها جميعا

00:18:00.580 --> 00:18:04.280
الخلاصة طلب واحد ورحلة واحدة منسقة

00:18:04.280 --> 00:18:07.040
شكرا لانضمامكم إلي في هذه المعلومة السريعة

00:18:07.040 --> 00:18:10.320
ترسم إدارة الطلبات الذكية مسارا مباشرا وحدا عبر عمليتك بالكامل

00:18:10.320 --> 00:18:12.560
من الاستلام الأولي حتى إرسال الفواتير النهائية

00:18:12.560 --> 00:18:14.720
اشتركوا عبر منصة البودكاست المفضلة لديكم

00:18:14.720 --> 00:18:15.800
وتابعوا الحلقة القادمة

00:18:15.800 --> 00:18:19.020
سترون بالضبط كيف تتعامل ديناميكس 365 و باور بلاتفورم

00:18:19.020 --> 00:18:19.900
مع العمل خلف الكواليس
