The Rawi Experience

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

هذه الأخطاء وإن كنت تذكر أودو Odoo تحديداً، إلا أنها تنطبق على غيره من التطبيقات والبرمجيات أيضاً.

الأخطاء الشائعة

حدود المشروع

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

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

كما يأتي مصطلح “تطبيق النظام” أو “تطبيق الموديول” ليكون كارثة أخرى في حجم التوقعات من طرف العميل، فهل هذا المصطلح يعني ضبط الإعدادات العامة فقط، مثل العملات وأنواع الضرائب؟ أم تراه يشمل الدليل المحاسبي والحسابات البنكية واليوميات؟ هل سيشمل المشروع استيراد البيانات التاريخية أو تهجيرها من نظم أخرى؟ هل هذه النظم الآخرى رقمية أم ورقية؟ هل النظم الأخرى مجرد ملفات إكسيل أم هي نظام إدارة وتخطيط موارد مؤسسات آخر؟

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

الإطار الزمني للمشروع

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

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

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

القيمة المالية

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

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

السداد واشتراطاته

أغلب ما رأيت من عقود وتعاقدات كان مبهماً في شروط السداد وتوقيتاتها أكثر من غيرها من الشروط والبنود والأحكام. فتجد النص القانوني يسرد “يتم سداد 50% مع التعاقد، 25% مع التشغيل، و25% مع التسليم” ببساطة وكل غموض الدنيا. إذا كان البند الأول في السداد واضحاً، فأي تشغيل هذا؟ أيعني تثبيت النظام على كمبيوتر أو سيرفر ما؟ أم استخدام العميل للنظام؟ أم انتهاء التدريب وافتراض بدء استخدامه وتشغيله؟ إذا كنت قد أوفيت بالتزاماتك فلم انتظار التشغيل أياً كانت ماهيته؟ وإن كان غير ذلك، فما هو ذاك؟ والأمر نفسه ينطبق على التسليم!

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

إنهاء العقد

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

البدائل الأنسب

العقود الثابتة

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

العقود الديناميكية

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

الخلاصة

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