ملاحظات من واقع التنفيذ.

السؤال الأول يكون دائمًا تقريبًا عن الترخيص، وهو السؤال الخطأ. نسخة Odoo المجتمعية مجانية الاستخدام وتغطي المبيعات والمشتريات والمخزون والمحاسبة ونقاط البيع. لا ينبغي لأحد هنا أن يدفع ثمن برنامج يستطيع تنزيله.

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

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

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

لذلك فالجواب الصادق عن سؤال «كم يكلّف» هو سؤال آخر: ما الذي يجب أن يتفق مع ماذا، وكم يبعد إجراؤك عن الافتراضي؟ نحدّد ذلك في قعدة تعريفية مجانية، ثم نكتب النطاق والرقم قبل أن يبدأ أي شيء.

قبول مدفوعات البطاقات والمحافظ في ليبيا يعني T-Lync، البوابة التي تقف أمام تداول وإدفعلي وسداد ومعاملات. الواجهة البرمجية نفسها صغيرة، والعناية كلها فيما لا تَعِد به.

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

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

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

لا شيء من هذا غريب بعد أن تكون قد نفّذته مرتين. وهو أيضًا غير ظاهر في أي عرض تقديمي من أي مزوّد، وتلك هي الحجة الحقيقية لتسأل من يبني متجرك إن كان قد مرّ به.

السؤال الذي يصلنا هو: هل يمكن أن يكون لدينا ذكاء اصطناعي خاص بنا؟ أما السؤال المفيد فأضيق: ما البيانات التي يحتاج النموذج إلى الاطلاع عليها، وأين يُسمح لهذه البيانات أن تكون؟

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

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

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

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

تركيب نظام موارد مسألة محلولة. ERPnext وOdoo كلاهما يُركَّب بثبات، وتوثيق المزوّد جيد. ليس هنا حيث تموت المشاريع.

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

كل واحدة من هذه الحالات تكاملٌ حُذف من النطاق ليبدو الرقم أفضل. وكل واحدة منها تعيد بهدوء إنتاج العمل اليدوي الذي اشتُري نظام الموارد لإزالته.

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

الاختبار العملي: بعد الإطلاق، هل ما زال بإمكان أي شخص في الشركة أداء عمله عبر جدول بيانات؟ إن كان الجواب نعم، فالتكامل لم يكتمل.

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

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

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

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

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

لا شيء من هذا غريب بعد أن تكون قد نفّذته. وهذه هي الحجة الحقيقية للتعامل مع من نفّذه فعلًا.

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

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

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

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

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

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

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

والثالثة هي التي تُتخطى عادة، وهي وحدها ما يحوّل المجلد إلى خطة تعافٍ. وإلى أن تُجرَّب الاستعادة فعلًا تبقى النسخة الاحتياطية اعتقادًا لا حقيقة.

لذلك فالسؤال عند تحديد النطاق ليس كم مساحة تخزين لديك، بل كم من الوقت يحتمل العمل التوقف، وكم من الجهد تحتمل خسارته. أجب عن الاثنين ويتبع التصميم - ثم نختبر الاستعادة في موعد محدد في التقويم، بينما لا شيء يحترق.

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

اشترِ حيث تكون عمليتك اعتيادية والمنتج ناضجًا. المحاسبة والبريد وتخزين الملفات والرواتب: لا شيء يُكسب من نسخة مفصّلة لمشكلة محلولة، والكثير يُخسر في صيانتها.

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

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

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

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

الموقع لمن لا يعرفك بعد. مهمته أن يشرح ما تفعله، وأن يمنحك مصداقية، وأن يفتح لشخص ما بابًا لبدء حديث. وهو أرخص الثلاثة، ويُقاس بالأسابيع، وهو بصدق الجواب كله لعدد كبير من الأعمال.

والمنظومة لمن هم داخل الشركة أصلًا. هي المكان الذي يتوقف فيه المخزون والفواتير والعملاء والمشتريات والرواتب عن العيش في ملفات متوازية ويبدأ فيه تطابقها. لا يراها أحد من خارج العمل، وهي عادة حيث يذهب المال بهدوء.

والتطبيق يستحق كلفته حين تتكرر العلاقة: عميل يطلب أو يحجز أو يتابع أو يدفع كل أسبوع، أو فريق ميداني يعمل بعيدًا عن مكتب. أما إذا حدث التعامل مرتين في السنة فموقع جوال جيد يؤدي العمل نفسه بجزء من الكلفة، ودون تثبيت أي شيء.

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

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

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

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

لذلك يشمل التسليم الأدوات غير اللامعة: تدريب للفريق كله، وفترة ضمان، وشخص محدد بالاسم للاتصال به، ومراقبة تخبرنا قبل أن يخبرنا عميلك، ونسخ احتياطي نستعيده دوريًا. وبعد ذلك تكون الصيانة ترتيبًا لا معروفًا - إيقاعًا منتظمًا من التحديثات والإصلاحات والتحسينات الصغيرة.

والبديل هو النمط الذي نُستدعى لإنقاذه مرارًا. نظام عمل يوم إطلاقه، ولم يُلمس بعدها، وبعد سنتين لا يمكن تحديثه دون إعادة كتابته. وتلك الإعادة تكلّف أضعاف ما كانت ستكلّفه المتابعة.

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

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

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

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

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