سلامة العاملين المنفردين كجزء من استراتيجية لقوة عمل متصلة

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

في هذا المقال، سنرى كيف يمكن للتتبع الشخصي أن يتجاوز مجرد إظهار الموقع ليصبح جزءًا من سير عمل أوسع، بدءًا من SOS وسياق الموقع وصولًا إلى عمليات الاستجابة، وجاهزية الأجهزة، والتكاملات، والتحليل التاريخي. وسنرى أيضًا كيف يندرج جهاز التتبع الشخصي Jimi IoT PL601، الذي تمت إضافته مؤخرًا إلى Navixy، ضمن هذا النهج وما يمكن أن يضيفه إلى خدمة لسلامة العاملين المنفردين مبنية باستخدام Navixy.

العامل في الميدان يحتاج إلى أكثر من مجرد نقطة على الخريطة

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

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

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

ما الذي ينبغي أن تغطيه منظومة سلامة العاملين المنفردين

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

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

بالنسبة إلى منظومة عملية لسلامة العاملين المنفردين، يمكن اختصار المطلوب في قائمة قصيرة نسبيًا:

1. الموقع من أجل معرفة مكان العامل عندما يحتاج إلى المساعدة
2. وسيلة لطلب المساعدة من أجل منح العامل طريقة مباشرة لإطلاق الإنذار
3. اتصال موثوق من أجل التأكد من أن الجهاز قادر على التواصل طوال مدة المهمة
4. جاهزية الجهاز من أجل معرفة أن جهاز التتبع لديه شحن كافٍ وجاهز قبل خروج العامل
5. مسار استجابة من أجل إيصال التنبيه، مع السياق المفيد، إلى شخص قادر على اتخاذ إجراء

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

والآن، كيف نحول هذه المتطلبات إلى جهاز يمكن للعامل حمله

يُعد PL601 من أحدث أجهزة Jimi IoT المدمجة مع Navixy، وهو يلبي عددًا كبيرًا من عناصر هذه القائمة.

بوزن لا يتجاوز 33 غرامًا، فإن PL601 صغير بما يكفي ليبقى مع العامل طوال فترة العمل. وهو يجمع بين تحديد الموقع عبر GNSS وWi-Fi وLBS، والاتصال عبر LTE Cat 1، وزر SOS فعلي، والاتصال الصوتي ثنائي الاتجاه، ما يغطي عدة عناصر من قائمتنا في جهاز واحد. وتوفر بطاريته القابلة لإعادة الشحن بسعة 650 mAh ما يصل إلى أربعة أيام من التشغيل وفق سيناريو الوضع الذكي الذي تذكره Jimi، بينما تساعد تقارير انخفاض البطارية في التأكد من أن جهاز التتبع جاهز للمهمة التالية.

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

استكشف جميع الأجهزة المدمجة مع Navixy

شخص ما ضغط على SOS. ماذا يحدث بعد ذلك؟

لنبقَ مع الفني نفسه. إنه يعمل في الموقع B في وقت متأخر من المساء ويضغط على زر SOS.

لقد قام PL601 بدوره. فهو يرسل لنا الحدث وموقع العامل. ومن هنا يمكن لـ Navixy إضافة السياق والمنطق اللذين يحددان ما الذي سيفعله العميل فعليًا بهذه المعلومات.

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

لنقل إن القاعدة بسيطة بالنسبة إلى الفني لدينا. SOS صادر من الموقع B خلال ساعات العمل العادية يتبع الإجراء المعتاد. أما SOS نفسه خارج ساعات العمل فيجب أن يصل إلى نظام الاستجابة للطوارئ لدى العميل.

بشكل مبسط:

PL601 SOS → Site B + after hours → emergency response

أضف بعض سياق الأعمال إلى بيانات الجهاز

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

بدلًا من التعامل مع:

SOS → 44.812... / 20.46...

يمكن لعملية الاستجابة التعامل مع شيء أقرب إلى:

Technician 14 → SOS → Site B → 22:13

لكن الموقع ليس سوى جزء من القاعدة. نحتاج أيضًا إلى معرفة ما إذا كانت الساعة 22:13 تُعد خارج ساعات العمل.

يمكن لعقدة Initiate Attribute حساب سمة after_hours من وقت الحدث وفق جدول العمل لدى العميل. في مثالنا، ساعات العمل العادية من الاثنين إلى الجمعة من 08:00 إلى 18:00. أي شيء خارج هذه الفترة يحصل على after_hours = true.

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

أنشئ قاعدة الاستجابة الخاصة بالعميل في IoT Logic

أصبح لدى التدفق الآن ما يكفي لاتخاذ القرار.

في مثالنا، القاعدة هي في الأساس:

SOS + inside Site B + after_hours = true

يبدأ التدفق بـ PL601 Data Source. تقوم عقدة Initiate Attribute بحساب after_hours. ثم تتحقق عقدة Logic من هذه السمة مع حدث SOS وشرط الموقع B.

إذا تحققت الشروط الثلاثة، ترسل فرع THEN الحدث إلى Emergency response Webhook. ويمكن للـ webhook تمرير معرّف جهاز التتبع، ونوع الحدث، والطابع الزمني، والإحداثيات، ومعلومات الموقع، وأي سياق آخر مطلوب إلى نظام الاستجابة للطوارئ لدى العميل.

إذا لم تتحقق الشروط، يبقي فرع ELSE البيانات في مسار الإخراج العادي.

ويبقى التدفق كاملًا صغيرًا بشكل ملحوظ:

PL601 → Calculate after_hours → Check SOS + Site B + after_hours → Emergency webhook / Normal output

يرسل PL601 حدث SOS نفسه بغض النظر عن العميل الذي يستخدمه. بالنسبة إلى عميل آخر، قد يتحول الموقع B إلى موقع بناء. وقد تختلف ساعات العمل. وقد يشير webhook للطوارئ إلى منصة أمنية بدلًا من نظام لإدارة الحوادث.

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

ولا تحتاج إلى بناء التدفق الأولي عقدة بعقدة

يمكن لمنشئ الحلول أيضًا وصف سير العمل المطلوب إلى Navixy AI Assistant باللغة الطبيعية.

في مثالنا، طلبنا منه إنشاء تدفق يكتشف حدث SOS من PL601، ويحسب ما إذا كان الحدث قد وقع خارج ساعات العمل، ويتحقق مما إذا كان العامل داخل الموقع B، ويرسل الأحداث المطابقة إلى webhook للاستجابة للطوارئ.

ومن هذا الوصف، أنشأ المساعد الهيكل الأولي:

PL601 Data Source → Initiate Attribute → Logic → Webhook / Normal output

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

ويجب أيضًا التأكد من المطابقة الدقيقة لأحداث وسمات PL601 بالنسبة إلى التكامل قبل نشر سير العمل.

لا يجب أن يكون زر SOS أول علامة على وجود مشكلة

يبدأ التدفق الأول لدينا من SOS. لكن لا يوجد ما يفرض أن يكون SOS هو المشغّل.

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

بعض الاستثناءات تظهر في طريقة تحرك الأشخاص

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

يمكن أن تتحول هذه الحالة إلى قاعدة أخرى في IoT Logic:

Assigned-area exit + night shift → supervisor workflow

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

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

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

أحيانًا تبدأ المشكلة قبل بداية المناوبة

ليست كل التدفقات المفيدة مرتبطة بحادث.

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

Battery below threshold before assignment → charging/replacement workflow

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

بالنسبة إلى العمليات التي توزع أجهزة التتبع في بداية المناوبة وتستعيدها بعد انتهائها، تصبح جاهزية الجهاز جزءًا من عملية السلامة بدلًا من مشكلة يتم اكتشافها في منتصف المهمة.

يجب ألا يعمل سير عمل السلامة بشكل معزول

هذا هو الجانب الآخر من فكرة قوة العمل المتصلة.

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

ولهذا السبب يهم وجود webhook في نهاية تدفق IoT Logic.

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

دع أنظمة العميل تكمل المهمة

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

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

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

مع مرور الوقت، تبدأ الحوادث في كشف أنماط

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

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

ابحث عن الأماكن والمواقف التي تتكرر

يوفر IoT Query لمنشئي الحلول وصولًا عبر SQL إلى بيانات Navixy التليماتية وبيانات الأعمال، بحيث يمكن تحليل هذه الأنماط عبر الأجهزة والمواقع والفترات الزمنية.

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

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

بالنسبة إلى مزود الخدمة، يمكن أن يكون هذا أكثر من خدمة سلامة واحدة

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

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

يمكن أن يظل الجهاز وبيئة Navixy كما هما، بينما تتغير السياسات المحيطة بهما.

لا يجب أن يكون التميز موجودًا داخل جهاز التتبع نفسه.

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

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

تعمل سلامة العاملين المنفردين بشكل أفضل عندما تكون جزءًا من العمل اليومي

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

مع دمج Jimi IoT PL601 الآن مع Navixy، أصبح لدى مزودي الخدمة ومتكاملي الحلول خيار إضافي من الأجهزة للجزء الميداني من خدمة سلامة العاملين المنفردين. وتوفر Navixy السياق والأتمتة والتكاملات والبيانات التاريخية التي تسمح لهذا الجهاز بالعمل داخل البيئة الفعلية للعميل.

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