لا تفشل مشاريع تقنية المعلومات لأن التقنية لم تكن متقدمة بما يكفي، بل تفشل بسبب اتفاق غير واضح وتوقعات غير متطابقة وغياب مسؤول من جانب الشركة.
تتكرر الأخطاء السبعة التالية على كل المستويات من المشاريع العائلية إلى الشركات الكبرى، والخبر الجيد أنها جميعًا قابلة للتفادي قبل التوقيع، وهي المرحلة الأرخص لتصحيح أي شيء.
اختيار أرخص عرض
السعر الأدنى يعني غالبًا أحد ثلاثة: نطاق أضيق مما تظن، أو جودة مضحّى بها، أو مورد خفّض السعر عمدًا لتعويض الهامش لاحقًا عبر طلبات التغيير.
العلاج: اطلب تفصيل كل عرض إلى مكوناته: التحليل والتصميم والتطوير والاختبار ونقل البيانات والتدريب والضمان. والعرض الذي يتعذر تفصيله لم يُدرس غالبًا، وما لم يُدرس يتحول إلى فاتورة لاحقة.
عدم كتابة تعريف الإنجاز
هذا مصدر النزاع الأول؛ فالشركة تعتبر المشروع منتهيًا حين يستخدم الفريق كله النظام بسلاسة، والمورد يعتبره منتهيًا حين سلّم قائمة المزايا، وبين التعريفين شهور أحيانًا.
اكتب هذه الجملة في العقد: «يُعد العمل منجزًا حين ينفّذ النظام العمليات س وص وع ببيانات الشركة الحقيقية أربعة عشر يومًا متتاليًا دون خطأ يوقف التشغيل». جملة كهذه تلغي تسعين بالمئة من النزاعات المحتملة.
إهمال ملكية الشفرة والبيانات
تكتشف شركات كثيرة ذلك عند رغبتها في تغيير المورد، وحينها يكون موقفها التفاوضي صفرًا. سؤالان يجب حسمهما قبل التوقيع: من يملك الشفرة المكتوبة خصيصًا لك، وكيف تسترجع كل بياناتك إن انتهت العلاقة.
عدم تعيين مالك داخلي للمشروع
لا يستطيع المورد ملء هذا الدور؛ فلا بد من شخص في شركتك يملك صلاحية القرار ويفهم العمليات ويُخصَّص له وقت فعلي. وإن بقي الدور شاغرًا تعطّلت القرارات أسابيع وحُسبت مدة الانتظار عليك.
العلاج: اذكر اسمه في العقد وعدد الساعات الأسبوعية المخصصة ومن ينوب عنه عند غيابه؛ يبدو ذلك مبالغة لكن المشاريع الناجحة تكاد لا تخلو من شخص كهذا.
شراء مزايا بدل حل مشكلات
قوائم المزايا أسهل وسيلة لمقارنة العروض ولهذا هي الأكثر تضليلًا؛ فالمزايا التي تبهر في العرض التجريبي ليست غالبًا ما يستخدمه فريقك يوميًا.
العلاج: حوّل قائمة المزايا إلى قائمة سيناريوهات؛ فبدل «نحتاج وحدة تقارير» اكتب «صباح كل اثنين يجب أن يرى مدير الفرع مبيعات الأسبوع حسب الفئة دون طلب مساعدة». السيناريو يُختبر أما الميزة فتُوعد فقط.
تخطي التجربة ببيانات حقيقية
تسير العروض التجريبية بسلاسة لأن بياناتها مرتبة وسيناريوهاتها مختارة، وتظهر المشكلات حين يلتقي النظام ببياناتك الفعلية: أسماء غير متسقة ومعاملات قديمة غريبة ووحدات مختلفة بين الفروع واستثناءات كانت تُعالج يدويًا.
اطلب هذا قبل التوقيع: تجربة محدودة بجزء من بياناتك الحقيقية ينفذها الموظفون الذين سيستخدمون النظام فعلًا؛ فإن رفض المورد بتبرير ملتوٍ فتلك معلومة بالغة القيمة.
عدم تخصيص ميزانية لما بعد الإطلاق
النظام ليس مبنى يقف وحده بعد البناء؛ فهناك خوادم تُدفع وتحديثات أمان تُطبّق وتعديلات عند تغير خدمات الأطراف الثالثة وإصلاحات صغيرة لا تتوقف.
العلاج: اتفق على تكلفة صيانة سنوية منذ البداية مع تفصيل نطاقها: ما المشمول، وما يُحتسب عملًا جديدًا، وزمن الاستجابة عند الأعطال.
قائمة تحقق سريعة قبل التوقيع
| ما يجب توفره | لماذا يهم |
|---|---|
| عرض مفصّل حسب المكونات | يمنع ظهور تكاليف خفية لاحقًا |
| تعريف إنجاز قابل للقياس | يزيل الخلاف حول موعد الانتهاء |
| بنود ملكية الشفرة والبيانات | يحمي موقفك التفاوضي مستقبلًا |
| مالك داخلي معيّن بالاسم | يضمن عدم تعليق القرارات |
| سيناريوهات استخدام بدل قوائم مزايا | قابلة للاختبار لا للوعد فقط |
| تجربة ببيانات حقيقية | تكشف المشكلات قبل صرف المال |
| ميزانية صيانة سنوية | تمنع إهمال النظام بعد التسليم |
الأسئلة الشائعة
تُطلب MDH كثيرًا لمراجعة نطاق العمل والعروض التقنية قبل اتخاذ القرار، ونشير إلى البنود المرشحة للتحول إلى تكاليف إضافية لاحقًا.
اطلب مراجعة