السؤال يصلني عادة بهذه الصيغة: «هل نحتاج مديرا تقنيا؟». وهو سؤال عن وظيفة وراتب وهيكل إداري، بينما المشكلة التي دفعت صاحبه إلى طرحه ليست وظيفة أصلا. المشكلة أن قرارا واحدا اتخذ قبل سنتين، في اجتماع لم يحضره أحد يفهم أثره، وما زالت الشركة تدفع ثمنه كل شهر.
السؤال الأدق: كم قرارا لا يمكن التراجع عنه تواجهه شركتك في الاثني عشر شهرا القادمة؟ إن كان الجواب صفرا فأنت لا تحتاج أحدا. وإن كان ثلاثة أو أربعة، فأنت تحتاج رأيا تقنيا كبيرا في تلك اللحظات بالذات — لا كل يوم، ولا على كشف الرواتب.
بابان: واحد يفتح في اتجاهين، وواحد لا يفتح إلا مرة
أوضح تفريق قرأته في هذا الباب جاء في رسالة أمازون إلى المساهمين لعام 2015. القرارات نوعان: نوع لا رجعة فيه أو يكاد، وصفه بأنه باب يفتح في اتجاه واحد؛ ونوع يمكن التراجع عنه، وهو باب يفتح في اتجاهين. والخطأ الشائع في المؤسسات أن تعامل النوع الثاني بثقل النوع الأول، فيصبح كل شيء بطيئا.
وفي الشركات الكويتية التي أعمل معها أرى الخطأ المعاكس أكثر: النوع الأول يعامل بخفة النوع الثاني. تناقش هوية الألوان أربعة اجتماعات، ثم يوقع عقد التطوير في خمس دقائق لأن السعر مناسب. والعقد هو الباب الذي لا يفتح إلا مرة.
الأبواب أحادية الاتجاه في شركة كويتية متوسطة
القائمة أقصر مما يتوقع الناس. أغلب ما يقلق الإدارة قابل للتغيير في أسبوع بتكلفة محدودة، والقليل فقط هو الذي يثبت مسارك لسنوات:
لاحظ أن العمود الأيسر كله قابل للقياس والتجربة والتراجع، وأن العمود الآخر كله يتعلق بالملكية والبنية والالتزام. هذا هو الفرق العملي: القرار أحادي الاتجاه ليس بالضرورة الأكبر ميزانية، بل هو الذي يغير كلفة كل قرار يأتي بعده. ومثاله الأوضح بنية العناوين واللغات: قرار يتخذ في يوم واحد قبل الإطلاق، وتغييره بعد سنتين يكلف ترتيبك في نتائج البحث — وهو ما شرحته في مقالة الموقع العربي ليس ترجمة.
لماذا تخفق مشاريع التقنية بالشكل الذي تخفق به
هناك بحث أحيل إليه كثيرا في هذا السياق، لأنه يصحح فهما خاطئا للمخاطرة. في دراسة نشرت في هارفارد بزنس ريفيو في سبتمبر 2011 على 1,471 مشروع تقنية معلومات، بلغ متوسط تجاوز التكلفة 27% — وهو رقم يبدو محتملا. لكن المهم ليس المتوسط: واحد من كل ستة مشاريع كان تجاوزه في التكلفة 200% في المتوسط، وفي الجدول الزمني نحو 70%.
معنى هذا أن المخاطرة في مشاريع التقنية ليست موزعة بالتساوي. أغلب المشاريع تنتهي قريبا مما خطط له، وقلة منها تنهار انهيارا يهدد الشركة نفسها. ولذلك فإن قياس المخاطرة بالسؤال «كم عادة تتجاوز المشاريع ميزانيتها؟» سؤال مضلل. السؤال الصحيح: ما الذي يجعل مشروعا يقع في السدس الخطر؟ وفي كل حالة رأيتها كان الجواب في قرار بنيوي اتخذ في الأسابيع الأولى، لا في التنفيذ.
البند الذي يكلف أكثر من النظام: من يملك ما دفعت ثمنه
هذه أكثر نقطة أراها تفاجئ أصحاب الشركات. القاعدة العامة في تطوير البرمجيات، كما تشرحها المنظمة العالمية للملكية الفكرية، أن المطور يحتفظ بملكية ما طوره ما لم ينص العقد صراحة على نقل الملكية إلى العميل. أي أن دفع الفاتورة كاملة لا يعني بالضرورة أنك تملك النظام.
والبنود التي تحسم هذا ثلاثة، وكلها تكتب قبل التوقيع لا بعده: نص صريح بنقل الملكية ولحظة انتقالها بالضبط، وتوضيح ما يبقى ملكا للمطور من أدوات ومكتبات سابقة لتعاقدك معه، وبند إنهاء يسلمك الكود المصدري والتوثيق وكلمات المرور. ذلك البند الأخير هو الفرق بين شركة تستطيع تغيير موردها في شهر وشركة لا تستطيع مغادرته أبدا.
الاستضافة والتصنيف: باب كويتي يفتح مرة واحدة
القرار الثاني الذي يصعب التراجع عنه هو أين تعيش بياناتك. الهيئة العامة للاتصالات وتقنية المعلومات أصدرت إطار تنظيم الحوسبة السحابية بالقرار رقم 112 لسنة 2021، ودخل حيز التنفيذ في الرابع من يوليو 2021، ومن متطلباته سياسة تصنيف بيانات تضع ما تحتفظ به الشركة في مستويات، وتربط إجراءات الحماية بحساسية كل مستوى.
الخلاصة الهندسية بسيطة: التصنيف يسبق اختيار الاستضافة، لا العكس. وقد فصلت هذا الجانب وما يعنيه عمليا في مقالة حماية البيانات في الكويت. ما يخص موضوعنا هنا أن هذا قرار يتخذ مرة، ونقل البيانات بعد سنتين من التشغيل مشروع كامل لا تعديل إعداد. وهو أيضا قرار لا يملك المورد أن يتخذه عنك، لأن المسؤولية النظامية تبقى عليك أنت.
لماذا لا يحل التوظيف بدوام كامل هذه المشكلة
افترض أن الشركة اقتنعت وقررت التوظيف. تظهر هنا ثلاث عقبات عملية. الأولى أنك تختار لمنصب لا تستطيع تقييم المرشحين فيه — فمن سيجري المقابلة التقنية إن كان سبب التوظيف أصلا غياب من يفهم؟ الثانية أن الأبواب أحادية الاتجاه لا تصل بوتيرة منتظمة: تواجه أربعة منها في ربع سنة، ثم لا شيء لعام. والثالثة أن الراتب الذي يجذب هذا المستوى في السوق الخليجي يقارن بميزانية المشروع نفسه.
النتيجة المعتادة أن الشركة توظف من تستطيع تقييمه بدل من تحتاجه: مطورا جيدا يعطى لقبا إداريا. وهذا يحل مشكلة التنفيذ ولا يحل مشكلة القرار، لأن الشخص نفسه يصبح طرفا في القرارات التي يفترض أن يراجعها. الشكل الصحيح هنا ليس بدوام كامل، وهو تحديدا ما تعنيه خدمة مدير تقني تنفيذي بدوام جزئي: شراء الحكم التقني في اللحظات التي يقرر فيها، لا شراء وجود دائم.
ولماذا لا يحلها المورد أيضا، مهما كان جيدا
الاعتراض الطبيعي: لماذا لا نسأل الشركة المطورة؟ لأنك تطلب منها أن تقيم عملها هي. وهذه ليست تهمة سوء نية، بل وصف لموقع: كل مورد يوصي بما يجيده، والمنصة التي بنى عليها عشرين مشروعا ستكون توصيته في المشروع الحادي والعشرين. توصيته قد تكون صحيحة، لكنها ليست مراجعة.
الوظائف الثلاث في هذا الجدول هي كل ما نتحدث عنه فعلا. من يؤديها لا يحتاج أن يكون موظفا عندك، لكنه يحتاج أن يكون في صفك وحدك، وألا يكون طرفا في أي عقد تنفيذ. وحين تفوض الثلاث معا إلى الجهة المنفذة تكون قد اشتريت نظاما لا تعرف كيف يعمل ولا تستطيع مغادرته.
علامات تقول إن القرار تأخر
خمس علامات أعتبرها كافية وحدها. الأولى أن أي تعديل صغير يحتاج المورد الأصلي وأسبوعين انتظارا. الثانية أن بيانات العملاء موزعة على ثلاثة أنظمة لا يعرف أحد أيها الصحيح. الثالثة أن أحدا في الشركة لا يعرف أين النطاق مسجل ومن يملك حساب الاستضافة. الرابعة أن كل عرض تقني يصل يبدو مقنعا ولا تملك طريقة للمقارنة. والخامسة أن التقنية صارت بندا يؤجل في كل اجتماع لأن لا أحد يستطيع الحسم فيه.
هذه الخمس ليست مشكلات تقنية، بل أعراض غياب مالك للقرار. ولذلك لا يعالجها نظام جديد — وهي بالضبط الحلقة التي تحول مشاريع التحول الرقمي إلى سلسلة مشتريات متفرقة بدل أن تكون مسارا واحدا.
الجرعة: كم يوما في الشهر فعلا
في أغلب الشركات المتوسطة التي عملت معها، الحجم الواقعي يومان إلى أربعة أيام في الشهر في الأوقات العادية، ترتفع في شهر اتخاذ قرار كبير أو تقييم عروض، ثم تعود. وما يحدث في هذه الأيام ليس اجتماعات: مراجعة عرض أو عقد قبل التوقيع، وكتابة قرار في صفحة واحدة تشرح ما اختير ولماذا وما استبعد، ومقابلة تقنية مع مرشح أو مورد، ومتابعة ما التزم به المنفذ في الشهر السابق.
ومن هذه الأيام تخرج الوثيقة الأهم: سجل قرارات مكتوب. قيمته أنه يبقى بعد رحيل الجميع، فحين يسأل أحدهم بعد سنتين «لماذا اخترنا هذا؟» يوجد جواب مكتوب بدل إعادة النقاش من الصفر. وأغلب دورات إعادة البناء التي أراها سببها فقدان هذا السجل، لا فشل النظام.
كيف تقيس عائد شيء لم يحدث
هذه الصعوبة الحقيقية في تسويق هذا الدور: نتيجته الأساسية أخطاء لم تقع، وهي لا تظهر في أي تقرير. لكن أربعة أرقام تقاس فعلا. الأول عدد البنود التي تغيرت في العقود قبل التوقيع. الثاني نسبة العمل المعاد في المشروع الجاري مقارنة بالمشروع السابق. الثالث الزمن بين طلب تعديل صغير وتنفيذه فعليا. والرابع عدد الأنظمة التي تستطيع تغيير موردها خلال شهر دون خسارة بيانات.
والسياق يجعل هذا القياس أهم لا أقل. تتوقع جارتنر أن يبلغ الإنفاق على تقنية المعلومات في الشرق الأوسط وشمال أفريقيا 169 مليار دولار في 2026، بنمو 8.9% عن 2025، منها نحو 36.9 مليار دولار على خدمات تقنية المعلومات و20.5 مليار على البرمجيات. الإنفاق يتسارع، وحوكمة هذا الإنفاق داخل الشركة المتوسطة لا تتسارع معه بالوتيرة نفسها.
الأسئلة التي يجب أن يسألك هو
حين تقابل من ستتعاقد معه على هذا الدور، لا تحكم عليه بإجاباته بل بأسئلته. من يفهم هذا العمل يسأل عن أشياء غير تقنية أولا: ما القرار الذي أمامك الآن ومتى موعده، ومن يوقع فعلا في هذه الشركة، وما الذي جرب سابقا وفشل ولماذا، وكم شخصا سيتغير عمله اليومي إن نجح هذا المشروع، وما الذي يحدث إن لم تفعل شيئا هذه السنة.
ومن يبدأ بعرض تقنيات ومنصات قبل أن يسأل أيا من هذه، فهو يبيع تنفيذا لا حكما. والفرق بينهما هو كل موضوع هذه المقالة، وهو جوهر ما أقدمه بصفتي استشاري إنترنت في الكويت. وينطبق المنطق نفسه على قرارات الذكاء الاصطناعي التي تصل الإدارة اليوم، وقد فصلتها في مقالة أين يفيد الذكاء الاصطناعي في الشركات الكويتية.
الأسئلة الشائعة
متى لا تحتاج مديرا تقنيا أصلا؟
حين لا يكون أمامك في السنة القادمة أي قرار من النوع أحادي الاتجاه. شركة تعمل بموقع مستقر ونظام محاسبة جاهز ولا تخطط لتغيير منصة ولا لربط أنظمة ولا لتغيير مورد، لا تحتاج هذا الدور — تحتاج عقد صيانة ومن يتابعه. وكذلك الشركة التي تملك بالفعل مسؤولا تقنيا داخليا يستطيع رفض عرض من مورد وشرح سبب رفضه. اختبر بالقرارات لا بحجم الشركة.
ما الفرق بينه وبين مدير تقنية المعلومات؟
مدير تقنية المعلومات يشغل ما هو قائم: الشبكة والأجهزة والدعم والصلاحيات والنسخ الاحتياطية، وهذا عمل يومي ضروري. أما هذا الدور فيقرر ما الذي يبنى أصلا وعلى أي أساس، ويراجع العقود والبنية قبل أن توجد. الشركة قد تحتاج الاثنين، لكن أحدهما لا يغني عن الآخر، وتكليف مدير تقنية المعلومات باختيار بنية نظام جديد هو أشهر صور الخلط بينهما.
هل يستطيع مراجعة عقد مع مورد قائم بالفعل؟
نعم، وهذه من أكثر الحالات التي أدخل فيها. المراجعة اللاحقة أضيق أثرا من السابقة لأن بعض الأبواب أغلق، لكنها ما زالت مجدية: يمكن عادة تصحيح ملكية النطاق والحسابات، والحصول على نسخة من الكود والتوثيق، وإضافة بند إنهاء واضح عند أول تجديد. ابدأ بالنطاق وحسابات الاستضافة تحديدا — هذان أسرع ما يسترد وأخطر ما يترك بيد غيرك.
ألا يخلق هذا تعارضا مع فريقنا الحالي؟
يحدث حين يقدم الدور على أنه رقابة، ولا يحدث حين يقدم على أنه غطاء. الفريق الداخلي في أغلب ما رأيت يرتاح لوجود من يوقع معه على قرار كبير، لأن البديل أن يتحمل مبرمج واحد مسؤولية اختيار بنية ستعيش خمس سنوات. الشرط أن تكون الحدود مكتوبة من اليوم الأول: من يقرر، ومن يراجع، ومن ينفذ — وألا يكون الشخص نفسه في خانتين.
كم يستمر التعاقد عادة؟
يبدأ عادة بثلاثة أشهر تغطي القرارات المفتوحة الآن، وينتهي عند نقطة واضحة: قرارات مكتوبة، وعقود مصححة، ومالك داخلي معروف بالاسم. بعدها إما ينتهي التعاقد أو يستمر بجرعة أصغر تراجع ما يستجد. واحذر الترتيب المفتوح بلا نهاية معرفة — هذا الدور ناجح حين يقلل حاجتك إليه، لا حين يثبتها.
هذه المقالة رأي مهني مبني على مصادر منشورة مشار إليها في متنها، وليست استشارة قانونية. راجع مستشارك القانوني قبل توقيع أي عقد تطوير أو استضافة.