تتفق مجموعة من أدلة شراء برامج التفتيش الميداني لعام 2026 على نقطة واحدة مشتركة: هناك فرق كبير بين "العمل بدون اتصال حقيقي" و"العمل بدون اتصال زائف". هذا الفرق يظهر مرة واحدة فقط - في أسوأ لحظة ممكنة.
الخلل الذي لا يلاحظه أحد حتى فوات الأوان
يبدو العمل بدون اتصال الزائف جيدًا تمامًا في العرض التوضيحي. يتم ملء النموذج، وتُحفظ الحقول، ويستجيب التطبيق بسرعة. تظهر المشكلة بالضبط عند الإرسال: يحتاج السجل إلى اتصال حي للوصول فعليًا إلى الخادم، لذا إما أن ينتظر بصمت في قائمة الانتظار أو، الأسوأ من ذلك، يفشل دون إخطار المفتش. يغادر المفتش الموقع معتقدًا أن التفتيش قد سُجّل؛ لكنه لم يُسجَّل - إلى أن يلاحظ أحدهم هذه الفجوة أثناء التدقيق.
ما يجب أن يعمل فعليًا بدون إشارة
العمل الحقيقي بدون اتصال يعني أن جميع خطوات سير العمل - وليس النموذج فقط - تستمر في العمل بدون إشارة: إنشاء تفتيش جديد، التقاط الصور وإحداثيات GPS، البحث والرجوع إلى المعيار المعني، حفظ بند معين للرجوع إليه لاحقًا، والمزامنة التلقائية بمجرد عودة الاتصال. تم بناء Probe361 بهذا المنطق تحديدًا: يقوم service worker بتخزين هيكل التطبيق مؤقتًا، ويُخزَّن نص المعايير نفسه (بنود AWS وAPI وASME) في IndexedDB على الجهاز نفسه - أي أن البحث الكامل في النص والوصول إلى البند يعملان حتى مع وضع الطائرة، وليس مجرد "آخر صفحة تمت مشاهدتها" ثابتة.
الوصول باللغة الفارسية مشكلة عدم اتصال بحد ذاتها
البديل الفعلي لمعظم المفتشين ليس تطبيقًا آخر - بل بوابات المعايير الرسمية نفسها (IEC وBSI وISO)، وهي بوابات ويب باللغة الإنجليزية فقط وبدون أي وضع عمل بدون اتصال. بالنسبة لمفتش لحام يتحدث الفارسية في موقع بلا إشارة، هذه عقبة يومية أكبر مما تذكره معظم مقارنات الموردين حتى عند حديثهم عن "دعم العمل بدون اتصال".
لا شيء من هذا انتقاد لأدوات تخزين النماذج مؤقتًا - فهي تحل مشكلة حقيقية للكثير من العمل الميداني. لكن بالنسبة للرجوع إلى المعايير تحديدًا، حيث يجب أن يكون المحتوى نفسه (وليس مجرد نموذج) قابلاً للبحث وصحيحًا بدون أي اتصال، فإن الفرق بين تخزين صفحة مؤقتًا وإرسال البيانات نفسها فعليًا هو كل الفرق.
