مشكلة إصدار التراخيص في العمليات الميدانية

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

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

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

أين تتعطل مسارات العمل المتوازية

عادةً ما تأخذ الاستجابة لهذه المشكلة أحد الأشكال الثلاثة التالية.

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

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

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

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

التصاريح كعناصر عمل

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

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

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

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

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

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

ماذا عن الأنظمة البلدية؟

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

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

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

سجل التدقيق الذي يريده المفتشون فعلاً

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

عندما يكون التصريح عبارة عن أمر عمل ضمن نفس النظام الذي تندرج فيه أعمال البناء، فإن الإجابات تكون هيكلية وليست مجرد تجميع للبيانات بعد وقوع الحدث:

يحتوي أمر عمل الترخيص على جدول زمني ثابت — تاريخ الإنشاء، وتاريخ الانتهاء، وتاريخ المصادقة — يمكن مقارنته بتاريخ بدء أمر عمل البناء. إذا بدأ العمل قبل المصادقة على الترخيص، فإن التواريخ تثبت ذلك.
يتضمن تقرير الترخيص مستند الترخيص المرفق، وتأكيد المُصادِّق، وأي شروط تم تسجيلها كنقاط ملاحظة. يصبح التقرير للقراءة فقط بعد المصادقة، وبالتالي لا يمكن تغيير الأدلة.
يتم توقيت معاملات المخزون في أوامر عمل البناء وتكون ثابتة. إذا تم استلام المواد قبل الموافقة على التصريح، فإن طوابع الوقت الخاصة بمعاملة الاستلام عبر الرمز الاستجابة السريعة (QR) تظهر ذلك.
كل شيء قابل للتصدير — CSV، PDF، سجل التدقيق — من نظام واحد، في استعلام واحد. لا توجد إحالات مرجعية بين قواعد البيانات المنفصلة.

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

ملخص

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