المشكلةكانت الشركة تشغّل مستودعين، مورّدًا سحابيًا قديمًا رئيسيًا وBigQuery ثانويًا، وتكلفة الاثنين في ازدياد. كان لا بد من نقل كل لوحة معلومات وخدمة وعرض دون انقطاع في التقارير.

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

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

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

ما فعلتهبنيت البوابة من الصفر: خدمات FastAPI/Python، وواجهة React وTypeScript، وتخزين مؤقت في Redis مع تحميل مسبق ليلي، وGoogle OAuth مع صلاحيات على مستوى المجموعات تُفرض من جهة الخادم، وإدارة مستخدمين وعرض بصفة مستخدم آخر، وتصدير Excel/PDF من كل لوحة. أضفت تطبيقًا لمؤشرات الاستراتيجية خلف تسجيل الدخول الموحّد للبوابة، وحصّنت الخدمة والجهاز الذي تعمل عليه.

النتيجةمكان واحد لكل لوحات المعلومات عبر الشركة، بصلاحيات تُدار على مستوى المجموعات؛ وجرى الاستغناء عن الأدوات المتفرقة السابقة.

المشكلةكانت لوحات المالية والتقنية المالية تقرأ من شتات من العروض المجزّأة لكل منها منطقه الخاص؛ فتتعارض الأرقام بين التقارير ولا يمكن ربط دفتر الأستاذ بالفواتير.

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

النتيجةنموذج مالي واحد يقرأ منه الجميع؛ ودفتر أستاذ يُربط بالفواتير؛ وفروقات وأخطاء حسابية تُكتشف قبل النشر لا بعده.

المشكلةكانت منصتان موجّهتان للعملاء تُعاد بناؤهما على PostgreSQL؛ وكان لا بد من نقل بياناتهما، بما فيها أرصدة العملاء، من MySQL القديمة دون أي فروقات ودون توقف يلاحظه العملاء.

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

النتيجةاكتمل التحويلان في الإنتاج دون أخطاء، مع نجاح كل فحوصات التحقق ومطابقة كل رصيد واحدًا لواحد.

المشكلةلم يكن لمنظومات قواعد البيانات الإنتاجية، MySQL وPostgreSQL، مالك واحد؛ وكانت عمليات التنظيف المقترحة تهدد بحذف فهارس يعتمد عليها الإنتاج، وتكاليف BigQuery ترتفع بسبب المسح غير المقسَّم.

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

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

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

ما فعلتهنقلت التحكم في الإصدارات إلى GitHub والنشر إلى Google Cloud Build عبر نفق IAP؛ وأعددت بوابات مراجعة لطلبات الدمج تشمل فحص الأنواع والتدقيق اللغوي للكود والاختبارات الشاملة والتحليل الساكن، مع تحديثات آلية للاعتماديات؛ وصفّيت سجل التنبيهات وأنهيت استخدام الأدوات السابقة.

النتيجةمن الدمج إلى الإنتاج في دقائق؛ وسجل أمان نظيف؛ وكل تغيير محكوم ببوابات وقابل للتتبّع.

المشكلةلم يكن لدى فريق نجاح العملاء إنذار مبكر بالحسابات المرجّح أن تغادر.

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

النتيجةتحقق خارج العينة قبل الاستخدام: الحسابات المحددة تسرّبت فعلًا مع إنذار بأسابيع. ويعمل فريق نجاح العملاء من هذه القائمة اليوم.

المشكلةأدوات البرمجة الوكيلية يمكنها مضاعفة إنتاج فريق صغير أو مضاعفة أخطائه؛ وأرادت الشركة الأول مع سجل تدقيق.

ما فعلتهأعددت جلسات وكيلية متوازية (Claude Code وCursor وWindsurf) تحت ضوابط مكتوبة وبوابات مراجعة إلزامية وتقارير مساهمة لكل جلسة تغذّي العرض التقني الشهري للمدير التنفيذي للتقنية؛ وشاركت في لجنة الذكاء الاصطناعي الداخلية التي وسّعت الممارسة إلى فرق أخرى.

النتيجةكل تغيير قابل للتتبّع عبر Jira وConfluence؛ وهذه الممارسة هي ما أتاح لفريق صغير تسليم الأعمال أعلاه في عام واحد.

المشكلةكان مقاول كبير يدير التحكم في المشروعات عبر جداول البيانات وPrimavera، وبيانات ERP محبوسة في Oracle.

ما فعلتهبصفتي مدير التحكم في المشروعات (2019) بنيت قاعدة بيانات PostgreSQL لأتمتة تتبّع إيرادات القطاع ونقديته وربطت ERP بالمستودع وPower BI. انتقلت إلى البيانات بدوام كامل في 2020: خوادم محلية، وAirflow وSpark، وETL بلغة PL/SQL من Oracle ERP؛ ودمجت Oracle Unifier وCRM وPrimavera P6 EPPM وأنظمة الموارد البشرية في مستودع مركزي؛ وأتمتت عمليات وفّرت أكثر من 200 ساعة شهريًا. بنيت نماذج التنبؤ بالتدفقات النقدية بصفتي عالم بيانات وأدرت عملية Scrum. وبصفتي قائد هندسة البيانات أسست فريقًا من 10 وقدته (ستة مهندسي ومحللي بيانات، ومهندسا تعلّم آلة، ومهندسا مكتب فني)، بخطوط بيانات على AWS وAzure وGCP، وبث Kafka/Spark بأكثر من 10 ملايين سجل يوميًا، ومستودع Snowflake/Databricks خفّض زمن الاستعلامات بنسبة 75%. وفي 2025 بصفتي قائد هندسة البيانات وتعلّم الآلة قدت فريق البيانات والذكاء الاصطناعي من 10: روبوت محادثة RAG إنتاجي، ومنصة تحليلات متكاملة على Oracle ERP، ونماذج تعلّم عميق، وأدوات وكلاء معجَّلة بوحدات GPU خفّضت وقت التصحيح بنسبة 60%.

النتيجةوظيفة هندسة بيانات حيث لم يكن هناك شيء، وإنجاز 95% من السبرنتات، وتحسّن الوصول إلى المعرفة الداخلية بنسبة 60%.