هذه هي دراسة الحالة التي، بعد أربع سنوات، تُرسي كل محادثة نخوضها مع عميل جديد. لذا تستحق أن تُروى كما ينبغي — لا كعرض ترويجي، بل كقصة الهندسة التي تقف خلفها. ما المشكلة التي كنا نحلّها فعلًا. ما الذي بنيناه. ما الذي تعطّل. وما الذي كنا سنفعله بشكل مختلف لو أطلقناها من جديد الأسبوع المقبل.
الموجز الذي لم يكن موجزًا حقًا
IGBS — المجموعة الدولية لحلول الأعمال — هي أكبر وكالة للملكية الفكرية والعلامات التجارية في مصر. تتولى التسجيلات والتجديدات والنزاعات لأكثر من ٤٬٥٠٠ عميل مؤسسي، بما في ذلك ما يقارب ١٧٬٠٠٠ سجل علامة تجارية نشط في أي لحظة. شركات متعددة الجنسيات. تكتلات محلية. شركات أدوية. بنوك. ذلك النوع من العملاء الذي لا يتسامح مع تفويت مواعيد التسجيل النهائية.
حين جلسنا مع فريقهم لأول مرة، كان الموجز: "We need a website."
المشكلة الحقيقية، بعد زيارة ميدانية واحدة، كانت شيئًا مختلفًا تمامًا. الموقع الإلكتروني كان أصغر المسائل. الوضع الفعلي كان كالتالي: twenty years of trademark operations were running on a hybrid of Excel spreadsheets, paper case files, a 12-year-old desktop database that nobody fully understood, and the memory of three or four indispensable people. كانت التجديدات تُتابَع في ثلاثة أماكن. ومراسلات العملاء تعيش في ملفات Outlook PST مشتركة. أما الرواتب وإدارة الخزينة وحالة القضايا فكانت كلها تمسّ السجلات نفسها لكنها تعيش في أدوات مختلفة لا يتحدث بعضها إلى بعض.
في اليوم السابق لدخولنا، كانت حادثة في أسبوع المواعيد النهائية قد كلّفتهم مشكلة تسوية بستة أرقام: ٣٬٠٠٠ إشعار تجديد كان يجب أن يُرسَل لم يُرسَل، لأن جدول البيانات الذي يُطلقها كان شخص آخر يحرّره في تلك اللحظة. لم يكونوا بحاجة إلى موقع إلكتروني. كانوا بحاجة إلى نظام تشغيل.
النطاق الفعلي، بالأرقام
هذا هو النظام اليوم. حين بدأنا، لم يكن أيٌّ من تلك الأرقام موجودًا بصيغة قابلة للاستعلام. كان الشهر الأول من المشروع أشبه بالتنقيب الأثري — استكشاف ما يجب أن يكون عليه نموذج البيانات الفعلي بالجلوس بجوار المشغّلين ومراقبة ما يفعلونه، ثم إعادة هندسة السجلات التي كانوا يحفظونها في رؤوسهم.
قرار البنية المعمارية الأكثر أهمية
معظم وكالات القاهرة — حين تصلها موجز مثل "نحتاج إلى نظام داخلي" — تلجأ إلى واحد من ثلاثة أمور: ووردبريس مع إضافات مخصصة، أو منصة منخفضة الكود مثل Bubble أو Webflow CMS، أو نظام Laravel/PHP أحادي مثبَّت على مستأجر واحد. كل واحد من هذه القرارات الثلاثة كان سيقتل هذا المشروع بحلول العام الثاني.
الخيار الذي جعل كل ما تبقّى ممكنًا كان: build it as a multi-tenant system from day one، مع وصول سليم قائم على الأدوار في طبقة قاعدة البيانات، على حزمة تقنية يمكننا صيانتها بأنفسنا إلى ما لا نهاية. اخترنا React + Node، مستضافًا على حافة Cloudflare للواجهة الأمامية، مع قاعدة بيانات Postgres مصممة حول عزل المستأجرين على مستوى الصف.
تلك الجملة فقرة واحدة. أما تبعاتها فكانت المشروع بأكمله.
ما الذي منحه لنا النظام متعدد المستأجرين منذ اليوم الأول
- 5 languages with no schema duplication. العربية، الإنجليزية، الفرنسية، الروسية، الصينية — السجلات نفسها، الفهارس نفسها. اللغة عمود، لا قاعدة بيانات.
- Role-based views without forking the code. يرى الفاحص المبتدئ لوحة تحكم مختلفة عن تلك التي يراها الشريك. الواجهة الخلفية نفسها. لا كابوس فرع "النسخة الاحترافية".
- Per-client data isolation that audits clean. حين يسأل عميل مؤسسي "من في IGBS وصل إلى سجلاتنا الشهر الماضي"، يكون لدينا الجواب باستعلام SQL، لا باجتماع طوارئ مذعور.
- Onboarding new clients is a database insert. لا عملية نشر.
وهذا أيضًا سبب أننا، بعد أربع سنوات، لم نُجرِ أي إعادة بناء. كان الشكل صحيحًا منذ البداية.
الجزء الصعب في النظام المخصص ليس الميزات.
It's choosing the shape that won't betray you in year three.
ما الذي بنيناه فعلًا (الوحدات الثماني)
بحلول وقت الإطلاق، كانت البوابة تضم ثماني وحدات متمايزة، تتشارك جميعها قاعدة البيانات وطبقة المصادقة نفسها:
١. العمود الفقري لإدارة القضايا
كل علامة تجارية، كل تاريخ تجديد، كل تغيير حالة — مرتبط بعميل، مرتبط بفاحص، مرتبط بدولة. ابحث بأي شيء، رشّح بأي شيء. هذا حلّ محل أربع أدوات منفصلة، وفيه يجري ٨٠٪ من العمل اليومي.
٢. بوابة العملاء
يسجّل العملاء الخارجيون الدخول ويرون علاماتهم التجارية، وتقاويم التجديد، والفواتير، وخزينة المستندات الخاصة بهم. إنها أكبر أداة احتفاظ بالعملاء تملكها IGBS. العميل الذي يستطيع رؤية محفظته في أي وقت لا يبحث عن بديل عند التجديد.
٣. محرّك التجديد
تذكيرات تلقائية عند ٩٠ و٦٠ و٣٠ و١٤ يومًا. المشكلة ذاتها التي أطلقت الموجز الأصلي — التجديدات الفائتة — لم تحدث ولو مرة واحدة منذ أن صار هذا مباشرًا. That alone paid back the build.
٤. طبقة الرواتب والعمولات
يتقاضى فاحصو IGBS راتبًا أساسيًا إضافة إلى عمولات لكل قضية عبر شرائح. يحتسب النظام التسوية الشهرية تلقائيًا. أزال نحو ٤٠ ساعة من العمل المالي شهريًا، وأنهى مشاحنات "أنا مستحَق لمزيد" في نهاية كل شهر.
٥. الخزينة
تخزين مستندات مشفّر للأصول الخاصة بالعملاء — نماذج توكيل، وإقرارات موقّعة، وترجمات معتمدة. مُؤرشف بالإصدارات، ومُسجَّل للتدقيق، وقابل للتنزيل كملف مضغوط لكل عميل لكل ربع سنة.
٦. وحدة الصرفيات
قروض للعملاء لتغطية رسوم التسجيل الأجنبية، مُتابَعة بشكل منفصل عن الفوترة المعتادة، مع تسوية كاملة مقابل كشف البنك. هذه أكثر الوحدات مللًا، وهي التي توفّر أكبر عدد من ساعات المحاسبة.
٧. طبقة التقارير
حزمة مجلس الإدارة تُولَّد تلقائيًا أسبوعيًا. تسجيلات بحسب الدولة، وتجديدات بحسب الربع، وإيرادات بحسب العميل، وتوزيع عبء الفاحصين. تُصدَّر بصيغة PDF وPowerPoint قابلة للتحرير. توقّف المدير التنفيذي للعمليات عن العمل أيام السبت في الشهر الثالث.
٨. نظام المراسلة الداخلي
استبدل فوضى Outlook بمحادثات قائمة على السلاسل مرتبطة بقضايا محددة. يقرأ الموظف الجديد سلسلة القضية فيصبح ملمًّا بها في ٢٠ دقيقة بدلًا من أسبوعين.
ما الذي تعطّل (ولماذا احتفظنا بالمكاسب رغم ذلك)
قسم صريح. لم يسر كل شيء بسلاسة. ثلاثة أمور كنا سنفعلها بشكل مختلف:
1. The first export-to-PDF system was a disaster. استخدمنا في البداية متصفحًا بلا واجهة يعمل في بيئة الإنتاج لتوليد حزم مجلس الإدارة. عمل على نطاق صغير، ثم تكدّس تحت الحمل وأسقط الـ API مرتين. استبدلناه بخدمة عرض قائمة على القوالب تعمل في عامل منفصل. الدرس: لا تضع عرض المتصفح في مسار الطلب. أبدًا.
2. We underestimated bilingual data entry. يكتب الفاحصون في القاهرة ملاحظات القضايا بالعربية. ويكتبها الفاحصون في دبي بالإنجليزية. افترض الإصدار الأول لغة واحدة لكل سجل. اضطررنا إلى إضافة وسم لغة لكل حقل لاحقًا. أسبوعان من العمل كان يمكن أن يكونا ثلاثة أسطر في المخطط منذ البداية.
3. The role permission matrix grew faster than we expected. بدأنا بأربعة أدوار. وبحلول العام الثاني صارت ١١. وبحلول العام الثالث أضفنا طبقة تجاوز لكل فريق، لأن طلب "كل الفاحصين الكبار يمكنهم رؤية كذا، باستثناء هذا الفريق" صار طلبًا معتادًا. أعدنا بناء نظام الصلاحيات مرة واحدة في العام الثاني. كان من الأرخص تصميمه كمحرّك سياسات منذ البداية.
لم يُفشل أيٌّ من ذلك المشروع. كلها كلّفت وقتًا. قرار البنية المعمارية — متعدد المستأجرين، قاعدة كود مملوكة، طبقة بيانات عامة — هو ما جعل الإصلاحات ممكنة دون إعادة بناء.
ما الذي كلّفه هذا المشروع فعلًا (بالساعات الهندسية الحقيقية)
نحو ١٬٤٠٠ ساعة هندسية على مدى ١٤ أسبوعًا. ثلاث مراحل: ٤ أسابيع من الاستكشاف ونمذجة البيانات، و٨ أسابيع من إطلاق الوحدات (وحدات تُصدَر أسبوعيًا، يستخدمها موظفو IGBS أثناء البناء)، وأسبوعان من التسليم والتدريب وترحيل البيانات من الأدوات القديمة.
ثم أربع سنوات من الصيانة — بمعدل نحو ٤ ساعات شهريًا من الإصلاحات الصغيرة وإضافات المخطط ودفعة ميزات أكبر واحدة سنويًا. لم يشهد النظام أي انقطاعات كبرى، ولا أي حوادث فقدان بيانات، ولا أي إعادة بناء. The same client today would be at year five with a system that hasn't aged into legacy. تلك هي ميزة التصميم من أجل الزمن.
ما الذي يثبته هذا للبناء التالي
بوابة IGBS هي الآن نقطة البرهان التي نستند إليها في كل محادثة عن نظام عمليات نخوضها — العيادات، ومطوّرو العقارات، وشركات الخدمات المهنية. طبقات مجال مختلفة، الهندسة نفسها. الجزء الصعب — نظام عمليات متعدد الفرق ومتعدد اللغات ومتعدد المستأجرين لا ينهار عند التوسّع — قد حُلّ. الجزء الجديد في أي بناء مستقبلي هو المجال فحسب.
إن كنت تجلس على وضع مشابه — عشرون عامًا من العمليات تعمل على Excel وتشعر أنها على وشك الانهيار — فإن البناء نفسه أقصر مما تظن (١٠–١٢ أسبوعًا لمعظم المجالات). أما القرار الأطول فهو الالتزام بالشكل الصحيح. وقد أنجزنا ذلك الجزء الآن، على مدى أربع سنوات.