الجهات المانحة.. تحديات بناء الأنظمة التقنية وتشغيلها

خلاصة المقال

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

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

والاشتراك في منتج متخصص ينقل عبء التقنية، وتبقى للجهة قراراتها وإجراءاتها.

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

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

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

المرحلة الأولى: البناء

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

وفي كلٍّ من صورتي البناء تغيب إحدى الخبرتين:

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

لماذا تحتاج المتطلبات إلى الخبرتين معًا؟

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

أولًا: الشكل المستقبلي للبيانات

تُقرَّر قيمة بيانات المنح يوم كتابة المتطلبات، وتُكتشف بعد سنوات، فالمتطلبات تحدد ما يُسجَّل، وبأي بنية، وفي أي لحظة من دورة المنحة، والخبير الفني يعرف الأسئلة التي ستُطرح على الجهة بعد ثلاث سنوات: كم صُرف في كل مجال وكل منطقة؟ ما الذي تحقق بما صُرف؟ كم مرة دُعمت الجمعية نفسها، وبأي نتيجة؟ والخبير التقني يعرف كيف تُبنى البيانات لتجيب عنها: حقول موحدة بدل النص الحر، وقوائم تصنيف ثابتة، وربط بين الجمعية والمشروع والعقد والدفعات والتقارير، وحفظ لتاريخ كل تعديل.

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

على سبيل المثال :

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

ثانيًا: حوكمة القرارات

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

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

ثالثًا: تقليل الخطأ البشري

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

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

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

المرحلة الثانية: الإطلاق

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

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

فمن يتحمّل هذا الضغط؟

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

المرحلة الثالثة: التشغيل

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

والإجابة ليست واحدة:

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

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

المرحلة الرابعة: الصيانة والاستقرار

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

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

وهنا تُختبر سرعة الاستجابة:

• مزود خدمة: تحكمها بنودُ عقد الصيانة وأولوياتُ المزود بين عملائه.
• بناء ذاتي: تحكمها جاهزيةُ مطوّر أو اثنين في تلك الأيام نفسها.

المرحلة الخامسة: حماية البيانات

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

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

وتحمل الجهة عبئها في الحالتين:

• مزود خدمة: تبقى المسؤولية على الجهة وإن استضاف المزود النظام لديه، وعليها متابعة التزامه بالضوابط.
• بناء ذاتي: تحتاج الجهة إلى خبرة أمنية متخصصة قلّما تتوفر في فريق صغير.

المرحلة السادسة: التطوير

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

ولكل تعديل منها طريق طويل إلى النظام:

• مزود خدمة: يتطلب كل تعديل طلبَ تغيير جديدًا، وعقدًا جديدًا، وميزانية جديدة، وانتظارًا.
• بناء ذاتي: يدخل كل تعديل في قائمة تتنافس على وقت فريق صغير.

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

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

المرحلة السابعة: الارتباط بالأشخاص

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

ويأخذ هذا الارتباط صورتين:

• مزود خدمة: يرتبط النظام بمزود بعينه، ويغيب المزود بانتهاء العقد أو بتوقفه عن العمل، وقد لا يُسلَّم الكود البرمجي المصدري كاملًا.
• بناء ذاتي: يرتبط النظام بمطوّر واحد أو موظف تقني فهم تفاصيله، ويغيب حين يغادر الجهة.

والنتيجة أن تتجمد إجراءات الجهة عند آخر صورة للنظام، فتعمل الجهة بطريقة النظام، وقد بُني النظام ليعمل بطريقتها.

التكلفة الحقيقية للنظام الخاص

تظهر تكلفة البناء في قرار المشروع، وتتوزع بقية التكاليف على السنوات بعده، فلا تُرى مجتمعة.

ألا يكفي الذكاء الاصطناعي لبناء النظام اليوم؟

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

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

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

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

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

ويبيّن الجدول الآتي أين يُسهم الذكاء الاصطناعي في كل مرحلة من مراحل النظام، وما الذي يبقى على الجهة رغم ذلك:

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

متى يكون النظام الخاص خيارًا صحيحًا؟

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

الحل: الاشتراك في منتج متخصص

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

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

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

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

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

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

توزيع المسؤولية بين الجهة والشريك

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

قرارات الجهة ومهام الشريك

أعمال تبقى على الجهة

ينقل الاشتراك عبء التقنية إلى الشريك، وتبقى على الجهة أعمال لا ينجح النظام دونها:

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

والشريك المتخصص يعين على هذه الأعمال بخبرته، ويبقى إنجازها قرارًا داخليًا لا يُفوَّض.

أدوات الذكاء الاصطناعي في المنح

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

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

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

بعد الاعتماد: متابعة التنفيذ، وقياس الأثر، وسجل أداء الجمعية.

على مستوى المحفظة: إمكان التحدث مع البيانات والإجابة عن أسئلة الجهة بالعربية، وقراءة توزيع الصرف، ومقارنة الأثر بما صُرف.

ومن أمثلة الأسئلة التي يمكن أن تطرحها الجهة على بياناتها:

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

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

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

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

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

مقارنة بين النظام الخاص والاشتراك في منتج متخصص

ما يحتاج إلى الحذر في الاشتراك أيضًا

ولا يخلو الاشتراك من مخاطر، والفرق أنها معروفة مسبقًا، ويمكن ضبطها في العقد قبل التوقيع:

كيف تختار الشريك المتخصص؟

الخبرة

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

الحماية والخروج

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

الاستمرار

9. يقدم أدوات ذكاء اصطناعي قابلة للتفسير، مع تعليل كل نتيجة وإسنادها بشاهد.
10. يطوّر منتجه باستمرار، ويواكب تحديث الأنظمة والممارسات.
11. يرافق الجهة بدعم مستمر بعد التشغيل.
12. يُبقي القرار للجهة في كل مرحلة.

سبعة أسئلة قبل قرار البناء

1. من يملك النظام داخل الجهة بعد إطلاقه؟
2. من يضمن استقراره في ذروة موسم التقديم؟
3. كيف سيُحدَّث حين تتغير الأنظمة أو إجراءات الجهة؟
4. من يحمي بيانات الجمعيات والمستفيدين، وكيف؟
5. هل ستجيب البيانات بعد ثلاث سنوات عن أسئلة الأثر والتوزيع والمقارنة؟
6. ماذا يحدث إن غادر من بناه، أو انتهى عقد مزود الخدمة؟
7. إن بُني النظام بمساعدة الذكاء الاصطناعي، فمن يحدّث وثيقة متطلباته، ويتحقق من كل تعديل فيه، ويُسأل عنه؟

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

ختامًا: التقنية في خدمة الرسالة

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

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