BP / 01منصة أعمال موحدة (تخطيط موارد المؤسسات · إدارة علاقات العملاء · إدارة الموارد البشرية · إدارة سلسلة الإمداد في نظام واحد)
العميل: شركة تدير مبيعاتها ومخزونها ومشترياتها وسجلات موظفيها عبر جداول إكسل، ومحادثات واتساب، ومجموعة من الأدوات التي لا تترابط مع بعضها. أرادت مكاناً واحداً يجمع ذلك كله، ويُبنى وحدة تلو الأخرى، دون إيقاف العمل للانتقال إليه.
التفاصيل
ما بنيناه: منصة واحدة تعتمد عليها الشركة فعلياً في عملها. مسار المبيعات وسجلات العملاء (CRM) يغذي الطلبات والفوترة (ERP)؛ وتتدفق بيانات المخزون والمشتريات والموردين (SCM) لتُحدّث في الوقت الفعلي؛ وتستقر سجلات الموظفين والإجازات ومُدخلات الرواتب (HRM) في النظام ذاته بصلاحيات مبنية على الأدوار. تسجيل دخول واحد، وقاعدة بيانات واحدة، ونسخة واحدة من الحقيقة — بُنيت بحيث يمكن إطلاق كل وحدة على حدة، لتنضم إليها الوحدات الأخرى لاحقاً دون عناء الانتقال.
القرارات التي اتخذناها: نظام واحد جُمع من أجزاء قابلة للفصل، ليظل تشغيله منخفض التكلفة ويمكن تقسيمه لاحقاً إن تطلّب حجم العمل ذلك؛ وسجل أحداث يقف خلف كل إجراء تجاري، لتنتهي المراجعات والخلافات بسجل موثق بدلاً من الجدال؛ وسلاسل موافقات يضبطها العميل بنفسه دون الرجوع إلينا؛ ودعم كامل للغات متعددة؛ ولوحات معلومات تفتحها الإدارة فعلياً — تعرض أرقاماً قابلة للتفصيل، لا رسوماً بيانية للزينة.
ما شمله العمل: لوحة تحكم مخصصة · صلاحيات دقيقة · إنشاء المستندات (عروض الأسعار، وطلبات الشراء، وقسائم الرواتب) · مركز إشعارات (بريد إلكتروني/واتساب) · وواجهة برمجة تطبيقات (API) لتستوعب ما قد يُستجد لاحقاً.
BP / 02سوق متعدد البائعين مع خدمات لوجستية وتقسيم للمدفوعات
العميل: نشاط تجاري يحتاج إلى عرض منتجات بائعين كُثُر أمام مشترين كُثُر واقتطاع عمولة على كل طلب — مع أنظمة لانضمام البائعين، ودفع المستحقات، وتتبع التوصيل، لا تعتمد على شخص يطابقها يدوياً.
التفاصيل
ما بنيناه: آلة متكاملة الأطراف الثلاثة. تجربة شراء مبنية لرفع معدل التحويل — على الويب، والهواتف، والقنوات الأخرى التي يجب أن تبيع من الكتالوج ذاته. وبوابات للبائعين يديرون منها الكتالوج، والمخزون، والأسعار، والطلبات دون الاتصال بأحد. ولوحة معلومات تشغيلية للتحكم الكامل بالقوائم، والعمولات، والمدفوعات، والخلافات. تُقسم المدفوعات من المصدر: تُفصل عمولة المنصة وحصة البائع تلقائياً، مع تقارير تسوية يمكن للطرفين مراجعتها. ودُمجت الخدمات اللوجستية في الإصدار الأول — شركات الشحن، وتتبع التوصيل، وتسوية مبالغ الدفع عند الاستلام للأسواق التي تعتمد على هذا الخيار.
القرارات التي اتخذناها: عوملت عملية انضمام البائعين كمنتج مستقل، بمسارات للموافقة وفحص المستندات، لأن هذا هو الموضع الذي تتوقف فيه الأسواق؛ وبُني محرك البحث ليبقى سريعاً مع كبر حجم الكتالوج بدلاً من ضبطه مرة واحدة لكتالوج صغير؛ ووُضعت ضوابط الاحتيال والمراجعة قبل الحاجة إليها؛ وصُممت البنية التقنية لتحمل عبء يفوق بكثير ما بدأت به، حتى لا يعني النمو إعادة بناء النظام.
BP / 03نظام لعمليات العيادات والرعاية الصحية
العميل: مجموعة رعاية صحية تُدار بالملفات الورقية وجدولة المواعيد عبر الهاتف، حيث يتوقف السجل الطبي للمريض عند الفرع الذي أنشأه.
التفاصيل
ما بنيناه: نظام لجدولة المواعيد يستخدمه المرضى فعلياً — حجز عبر الويب مع تذكيرات عبر واتساب قبل كل موعد — إلى جانب سجلات طبية إلكترونية بصلاحيات صارمة مبنية على الأدوار، ووصفات طبية إلكترونية، وإرسال لنتائج التحاليل، وتتبع لمطالبات التأمين، والفوترة، وكل ذلك ضمن واجهة إدارة تعرض معدل الإشغال لكل طبيب، ولكل غرفة، ولكل ساعة. كانت السرية قيداً تصميمياً منذ السطر الأول في الكود المصدري وليست إضافة لاحقة: تشفير البيانات أثناء الحفظ والنقل، وسجل مراجعة كامل لكل وصول إلى السجلات، ومعالجة للبيانات مطابقة لمعايير الامتثال الخاصة بـ GDPR وKVKK وPDPL. وطُبقت أنماط بمستوى HIPAA حيثما استدعى العمل ذلك.
القرارات التي اتخذناها: صُممت شاشة الطبيب لتناسب الدقائق القليلة التي تستغرقها الاستشارة فعلياً، لا لتكون مجرد نموذج قاعدة بيانات؛ ووُحدت هوية المريض عبر الفروع، ليرافقه سجله أينما ذهب بدلاً من أن يرتبط بالمبنى؛ ولا تخرج أي معلومة عن المريض من النظام دون سبب مُسجّل.
BP / 04منصة حجوزات وضيافة مع نظام لإدارة المحتوى
العميل: مُشغّل في قطاع الضيافة يبيع الوقت والسعة — فترات تُباع أو تُهدر — ويتلقى الحجوزات عبر عدة قنوات، مع فريق تسويق لا يستطيع تعديل أي صفحة دون الاستعانة بمطور.
التفاصيل
ما بنيناه: نظام آني لعرض التوفر والحجز — على الويب، والهواتف، والقنوات الأخرى التي يبيع النشاط التجاري عبرها — مع تطبيق سياسات العربون والإلغاء تلقائياً، وإدارة أسعار آمنة للقنوات، ونظام لإدارة المحتوى (CMS) يديره فريق التسويق دون مطور (لإدارة الصفحات، والعروض، والحملات الموسمية بكل اللغات التي ينشر بها)، وواجهة خلفية تغطي السعة، وتقويم الأسعار، وجداول الموظفين، والإيرادات اليومية. ودُمجت التكاملات مع النظام: بوابات الدفع، وتأكيدات واتساب، وتصدير البيانات المحاسبية، ومراقبة منصات التقييم.
القرارات التي اتخذناها: جُعل الحجز المزدوج مستحيلاً في البنية بدلاً من منعه بالإجراءات — فالقاعدة تسكن في نموذج البيانات، لا في تعليمات الموظفين؛ ويُسجّل كل تغيير في السعر؛ ووُضع جانب المحتوى وجانب الحجز على نظام تصميم واحد، لكي لا تنكسر الهوية البصرية أبداً بين مرحلتي "القراءة" و"الشراء".
BP / 05منصة للعمليات الميدانية وفرق العمل
العميل: شركة يُنجز عملها في مواقع العملاء وليس على المكاتب — تُرسل المهام في الصباح، والسجل الوحيد لما حدث يصل في تقارير تُكتب نهاية الشهر.
التفاصيل
ما بنيناه: غرفة تحكم لمسؤول توزيع المهام — خريطة حية، وإسناد للمهام، ومؤقتات لاتفاقية مستوى الخدمة (SLA) — ترتبط بتطبيق ميداني يعمل بلا اتصال بالإنترنت ويزامن البيانات عند عودة التغطية: تفاصيل المهمة، وقوائم التحقق، وصور الإثبات، وتواقيع العملاء، وقطع الغيار المستخدمة. يحصل العملاء على رابط تتبع خاص بهم ورسالة للتقييم. وتحصل الإدارة على الحقيقة: معدلات الإصلاح من الزيارة الأولى، ونسبة استغلال وقت الفنيين، وتوزع أوقات الاستجابة — تُحسب من المهام نفسها، لا مما يكتبه شخص ما نهاية الشهر.
القرارات التي اتخذناها: بنية تقنية تعمل بلا اتصال أولاً، لأن الميدان ليس مكاناً يضمن اتصالاً مستقراً بالإنترنت، والتطبيق الذي يتعطل عند انقطاع التغطية هو تطبيق لن يفتحه أحد مرتين؛ وعوملت الصور والتواقيع كأدلة، وأُرفقت بها طوابع زمنية وعلامات جغرافية؛ وبُني نظام تتبع الوقت ليكون دقيقاً لدرجة اعتماده في الرواتب، لأن هذا هو الرقم الذي يجادل الناس حوله.
BP / 06محرك للمحتوى والتجارة (نظام إدارة محتوى منفصل + واجهة متجر)
العميل: علامة تجارية تطلّب موقعها أن يكون منصة نشر ومتجراً في آن واحد — محتوى إعلامي يكسب الزيارة، ومسار دفع لا يبدو وكأنه لشركة مختلفة.
التفاصيل
ما بنيناه: نظام إدارة محتوى منفصل (Headless CMS) يغذي واجهة متجر سريعة بكلا اللغتين: تشترك المقالات ومقاطع الفيديو وصفحات المنتجات في نظام تصميم واحد؛ وتدعم عربات التسوق، والاشتراكات، والتسليم الرقمي؛ ودُمجت التهيئة لمحركات البحث في البنية الأساسية (البيانات المنظمة، وروابط hreflang، وميزانيات الأداء)؛ ومسار عمل للتحرير يتضمن المسودات والموافقات والجدولة. ينشر فريق التسويق يومياً دون المساس بالكود المصدري، ويبيع المتجر دون إخراج الزائر من تجربة المحتوى.
القرارات التي اتخذناها: عومل الأداء كميزة أساسية وليس كمهمة نهائية، لأن الصفحة البطيئة تعني مبيعات مفقودة؛ واعتُبرت الخطوط قيداً تصميمياً رئيسياً، لأن المنتج هنا هو القراءة؛ ورُبطت التحليلات لتجيب عن "أي محتوى يحقق المبيعات" — وليس فقط "أي محتوى يحصد النقرات".
BP / 07منصة آنية ودائمة العمل (حالة حية مشتركة · طفرات في الزيارات · قابلية المراقبة)
العميل: نشاط تجاري يدير منتجاً يعمل فيه كثيرون على نفس البيانات الحية في اللحظة ذاتها — حيث تعتبر الإجابة التي تأخرت ثانية واحدة إجابة خاطئة، وتصل الأحمال على شكل موجات وليس في خط مستقيم.
التفاصيل
ما بنيناه: نظام موزع صُمم حول حالة حية مشتركة واحدة تبقى كما هي على كل جهاز، وحول حقيقة أن زياراته تصل على شكل موجات. تنمو السعة وتتقلص مع الحمل بدلاً من أن تُحدد ليوم إطلاق قد لا يتكرر أبداً. وتُؤتمت عملية التسليم من البداية للنهاية، ليكون ما في المستودع هو ما في بيئة الإنتاج، وليكون التراجع أمراً يُنفذ بأمر واحد وليس بعملية تستغرق أمسية كاملة. ودُمجت قابلية المراقبة مع الإصدار الأول، وليس بعد أول انقطاع: تتبعات تلاحق إجراء مستخدم واحد عبر كل خدمة، ومقاييس للأرقام التي تتنبأ فعلياً بالمتاعب، ولوحات معلومات يمكن للمناوب قراءتها في الثالثة فجراً. وعومل جانب العميل كجزء من النظام وليس كملحق به — فصُمم ليتعامل مع إعادة الاتصال، والرسائل المتأخرة، والهاتف الذي يدخل في نفق، لأن ذلك هو المكان الذي يبدو فيه المنتج الحي معطلاً لأول مرة.
القرارات التي اتخذناها: صُمم النظام بناءً على كيفية تشغيله، وليس فقط على كيفية برمجته — فالجزء الصعب من المنتج الحي يبدأ في اليوم الذي يصل فيه المستخدمون الفعليون؛ وقُسمت الحالة بحيث يؤدي العقد العالق إلى تراجع أداء غرفة واحدة وليس المنتج بأكمله؛ ورُبطت الإنذارات قبل الإطلاق، لتصل المشكلة إلى مهندس قبل أن تصل إلى عميل.
BP / 08محرك البيانات والتكامل (جمع · توحيد · قنوات مراقبة)
العميل: نشاط تجاري تعتمد قراراته على بيانات موجودة خارج أنظمته الخاصة — أسعار موردين ومنافسين، وكتالوجات وقوائم، وسجلات عامة، وشريك لم يُصمم نظامه أصلاً ليُربط به.
التفاصيل
ما بنيناه: مسار بيانات يحول المصادر المتفرقة إلى مجموعة بيانات واحدة يمكن لفرق العميل وأنظمته الأخرى الاستعلام عنها. وفُصلت عمليات الجمع، والتنظيف، والتخزين كمراحل مستقلة، لكي لا يؤدي أي مصدر يغير هيكليته إلى تعطل المسار بأكمله بل إلى تعطل أداة جمع واحدة. وتُوحّد السجلات التي تصل بأشكال مختلفة لتطابق مخطط بيانات واحداً، ليصبح العنصر ذاته قابلاً للمقارنة بغض النظر عن مصدره، ويُحتفظ بالتاريخ بدلاً من الكتابة فوقه — فكيف تحرك الرقم أصبح مرئياً، وليس فقط ما هو عليه الآن. وتعمل عملية الجمع وفق جدول زمني يحدده العميل، وتتجه المخرجات إلى مكان اتخاذ القرار: لوحة معلومات، أو تصدير، أو واجهة برمجة تطبيقات (API)، أو مباشرة إلى النظام الذي يدير العمل أصلاً. وأصبحت إضافة مصدر لاحقاً مجرد عملية إعداد وليست عملية معمارية تقنية.
القرارات التي اتخذناها: بُني مخطط البيانات ليتحمل المصادر غير المنظّمة، لأن مسار البيانات الذي لا يقبل إلا البيانات النظيفة سيتوقف في أول يوم سيء له؛ وتقوم المراقبة بالإبلاغ عن أي قناة بيانات قديمة أو معطلة بوضوح، لأن الفشل المكلف ليس مسار بيانات يتوقف، بل مسار يستمر بهدوء في تقديم أرقام الأمس؛ ولم تُجمع إلا البيانات المتاحة للعموم، ضمن شروط كل مصدر — وتم التحقق من ذلك أثناء تحديد نطاق مسار البيانات، وليس بعد تشغيله.
BP / 09وكلاء ذكاء اصطناعي مخصصون (تنسيق · تنفيذ دون تدخل بشري مباشر · نقاط مراجعة بشرية)
العميل: نشاط تجاري كان عمله شديد التنوع بحيث لا يمكن ضبطه بقاعدة ثابتة، وشديد التكرار بحيث لا يمكن تخصيص شخص لمتابعته — في إحدى الحالات كان عملية طويلة تنتقل عبر مراحل، وفي حالة أخرى تدفقاً حياً للأحداث كان يجب التصرف حيالها لحظة وصولها.
التفاصيل
ما بنيناه: نظام وكلاء يقوم بالعمل فعلياً بدلاً من الحديث عنه. حيثما كان العمل عملية مجزأة لمراحل، خُصص لكل مرحلة وكيل بمهمة محددة، ومُدخل محدد، ومُخرج محدد، ونُسقت عمليات التسليم بينهم بدلاً من مجرد أمل بحدوثها — مع نقطة مراجعة بشرية في المراحل التي تكون فيها الإجابة الخاطئة مكلفة. وحيثما كان العمل تدفقاً حياً، يعمل الوكيل تلقائياً دون تدخل بشري مباشر، ووُضعت قواعده وحدوده في الإعدادات بدلاً من الكود المصدري، ليُمكن تغيير ما يفعله دون إعادة بناء النظام. وتضمّن كلا النموذجين الأجزاء الثلاثة نفسها: واجهة توضح ما يفعله الوكيل ولماذا، وسجل مراجعة لكل إجراء اتخذه، وإنذارات تعيد تدخّل شخص في العمل لحظة الحاجة إليه. وتعمل هذه الأنظمة في حاويات، بمفاتيح العميل وحساباته الخاصة، لكي تتصرف في بيئة الاختبار كما تتصرف في بيئة الإنتاج وتبقى ملكاً له.
القرارات التي اتخذناها: كُتبت صلاحيات الوكيل قبل بنائه — أين يتصرف وحده، وأين يقترح وينتظر، وما الذي لا يجوز له فعله أبداً دون إشراف؛ والسلوك موجود في الإعدادات، لذا فإن تغيير القاعدة هو مجرد تعديل وليس عملية إطلاق للنظام؛ وكانت لوحة المعلومات جزءاً من الإصدار الأول، لأن الوكيل الذي لا يمكن لأحد مراقبته هو وكيل لن يأتمنه أحد على أي شيء مهم.