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