إدارة أسطول السكوتر الكهربائي. التوسع دون إرباك العمليات

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

تستعرض هذه الدراسة العملية كيفية قيام المشغل بإعادة تنظيم الأتمتة وفصل المجالات التشغيلية وتغيير منهجه في إدارة أسطول السكوتر الكهربائي مع استمرار نمو الأعمال.

لماذا يصبح توسيع إدارة أسطول السكوتر الكهربائي أمرًا صعبًا تشغيليًا

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

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

قد يبدو إدارة أسطول مكون من 200 وحدة من السكوتر الكهربائي، مع أنه ليس مهمة تشغيلية بسيطة، إلا أنه لا يزال قابلاً للإدارة بدرجة معقولة.

أما التوسع إلى 2000 سكوتر موزعة عبر مدن متعددة وفِرَق وقواعد تشغيلية، فيبدأ يشبه محاولة تنسيق عدة أنظمة متداخلة في حين تواصل الحوادث والتنبيهات وتحديثات تدفق العمل إشعال الحرائق من حولك.

«الأمور بخير» © KC Green

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

ولكن دعونا نقوم بتفصيل الأمر.

دراسة حالة: أتمتة عمليات السكوتر الكهربائي المشترك

بدأ مشغل للتنقل المشترك في أوروبا التعامل مع المشكلة من منظور تجربة الراكب.

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

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

قرر المشغل أتمتة عملية “الدفع للانطلاق” باستخدام IoT Logic.

Note: IoT Logic هو بيئة برمجية منخفضة التعليمات البرمجية (low-code) للتليماتيك وأتمتة إنترنت الأشياء. يمكن تكوين تدفقات العمل التي كانت تتطلب سابقًا تطويرًا متكاملًا للواجهة الخلفية وعمليات تكامل مخصصة بشكل مرئي في أقل من ساعة، اعتمادًا على التعقيد.

كان التدفق المبدئي يستمع إلى إشارة تأكيد الدفع داخل تيار التليمات الوارد. بمجرد اكتشاف المنصة أن سمة الدفع المخصصة قد تغيرت إلى حالة مؤكدة، يحفز التدفق أمر M2M GPRS عن بُعد لفتح قفل السكوتر. وفي الوقت نفسه، يستمر توجيه التليمات إلى Navixy لأغراض المراقبة والتتبع.

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

انخفض زمن تأخر بدء الرحلة. تحسنت موثوقية الفتح. انخفضت شكاوى الركاب.

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

التوسع في تدفقات الالتزام والأمان

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

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

يمكن لعقدة webhook إرسال هذه الحادثة إلى نظام الـCRM، وإنشاء سجل امتثال دون تدخل يدوي.

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

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

كل أتمتة عالجت مشكلة تشغيلية حقيقية. تمت إضافة كل أتمتة في البداية إلى التدفق الحالي.

لماذا توقفت الإعدادات الأصلية عن العمل

كما يحدث غالبًا، لم يأتِ هذا التوسع دون تعقيدات.

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

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

من الناحية التقنية، نجح الأمر. ومع ذلك، أصبح من الصعب صيانته بسرعة.

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

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

التحول نحو أتمتة عمليات تشغيلية نمطية

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

أعاد المشغل بناء الأتمتة الخاصة به في أربعة تدفقات منفصلة:

• تدفق الدفع: تأكيد الدفع يحفز أمر الفتح
• تدفق الالتزام: تجاوز السرعة المستمر يحفز حادثة في الـCRM
• تدفق الأمان: الحركة غير المصرح بها تحفز تنبيهًا وإنذارًا
• تدفق الكشف عن العبث: فتح الغطاء أو فصل الجهاز يؤدي إلى تفعيل الإنذار وتمرير الموقع

تتلقى كل تدفق التليمات نفسها من الجهاز. وكل تدفق يعمل بشكل مستقل. لم يعد تعديل منطق الالتزام يؤثر على منطق الدفع. ولم يتطلب اختبار تدفق الأمان اختبار تدفق الكشف عن العبث.

دعونا نستعرضها سريعًا.

التدفق 1: فتح قفل السكوتر بعد الدفع

المحفز: ظهور حدث تأكيد الدفع في تيار التليمات، يشير إلى أن الراكب أكمل معاملته.

الإجراء: يقوم IoT Logic بإرسال أمر إلغاء القفل عن بُعد عبر M2M GPRS. يتم تنشيط وحدة التحكم في السكوتر، فيتم تحرير القفل ماديًا. تبدأ جلسة الرحلة.

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

التدفق 2: الإبلاغ عن تجاوز حد السرعة

المحفز: تجاوز السرعة 25 كم/ساعة عبر رسائل تليمات متتالية. يشترط التتالي لتجاهل القفزات اللحظية لنظام تحديد المواقع والتسارعات القصيرة، والقبض فقط على الانتهاكات المستمرة.

الإجراء: عبر webhook، يتم إنشاء حادثة في الـCRM تتضمن الإحداثيات ووقت الحدث وقراءة السرعة ومعرف الجهاز. يتلقى فريق الامتثال سجلًا جاهزًا للتقرير إلى الجهات البلدية.

الغرض: الامتثال البلدي ومحاسبة الراكب. تشترط العديد من المدن على المشغلين توثيق انتهاكات السرعة والتعامل معها كشرط للتصاريح التشغيلية.

التدفق 3: اكتشاف الحركة غير المصرح بها

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

الإجراء: عبر webhook، يتم تنبيه فريق العمليات مع إحداثيات GPS. وفي الوقت نفسه، يرسل التدفق أمرًا عن بُعد لتفعيل إنذار السكوتر. تستمر التليمات في التوجيه إلى Navixy للتتبع.

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

التدفق 4: كشف العبث

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

الإجراء: يتم تفعيل الإنذار فورًا عن طريق أمر عن بُعد. تنتقل بيانات الموقع إلى Navixy. ويتم إنشاء حدث أمني لمركز عمليات الأمن.

الغرض: تقليل وقت التوقف الناتج عن العبث وتعزيز الحماية ضد السرقة. التنفيذ الفوري للإنذار يردع العبث المتواصل. وتمكين تتبع الموقع يعزز فرص الاستعادة.

النتائج الاستراتيجية لمشغلي التنقل المشترك

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

شملت النتائج التشغيلية الأساسية ما يلي:

• توسع أسرع في مدن جديدة
  أصبح من الممكن ضبط تدفقات الالتزام وفقًا لللوائح المحلية دون إعادة تصميم أتمتة الدفع أو الأمان أو الصيانة.

• تقليل المخاطر التشغيلية
  لم تعد المشكلات في تدفق واحد تؤثر على الأنظمة غير المرتبطة في الأسطول.

• سهولة مسؤولية تدفق العمل
  أصبح بإمكان فرق الالتزام والأمان والعمليات إدارة الأتمتة وتحديثها بشكل مستقل.

• تجربة أكثر أمانًا مع الأتمتة الجديدة
  صار بالإمكان اختبار ونشر التدفقات الجديدة بشكل تدريجي دون جعل النظام بالكامل أصعب في الصيانة.

توسيع عمليات الأسطول دون زيادة الفوضى التشغيلية

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

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

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