عرض مورد نظام الزوار يسعّر جانبه من الربط فقط. أما ما يطلبه مورد نظام الصيانة أو المستودعات، من ترخيص واجهة أو تفعيل وحدة أو ترقية إصدار أو أيام استشارة أو بيئة اختبار، فلا يظهر فيه. ومثله ما يتحمله المصنع نفسه من وسيط ومسار شبكي ووقت تقنية المعلومات ومتابعة يومية. هذه البنود تُدفع مرة عند البناء، ثم يتكرر جزء منها كل سنة وعند كل تحديث لأي من النظامين.
املأ نموذجًا من عشرة بنود موزعة على الأطراف الثلاثة قبل اعتماد ميزانية التكامل، ثم قارن مجموعه على ثلاث سنوات بكلفة البديل الإجرائي. وبعدها اختر واحدًا من ثلاثة: ميزانية تكامل كاملة، أو تأجيل الربط مع قياس الحاجة، أو ربط أبسط يتجنب أغلى البنود.
لماذا يُظهر عرض مورد الزوار نصف كلفة الربط
الربط بين نظامين عمل على طرفين. مورد نظام الزوار يستطيع تسعير ما يبنيه هو: استدعاء الواجهة، وتحويل الحقول، ومعالجة الأخطاء، واختبار جانبه. أما ما يلزم في النظام الآخر فقرار مورد ذلك النظام وسعره. لذلك تنص صفحة التكامل مع الأنظمة والأجهزة على أن الربط قد يتوقف على تعاون مورّد الجهاز أو النظام الآخر بتوثيق أو ترخيص واجهة أو تحديث إصدار. وتنص على أن ذلك خارج سيطرة مورد الزوار، ويُذكر في العرض افتراضًا معلنًا لا وعدًا. وتضع صفحة التكلفة «تراخيص أو ترقيات أنظمة طرف ثالث لتمكين الربط» ضمن ما يقع خارج العرض عادة.
هذا ليس تهربًا من الكلفة، بل حدّ لما يستطيع مورد واحد أن يعد به. المشكلة تبدأ حين تقرأ لجنة الترسية سطر «التكامل مع نظام الصيانة» في عرض مورد الزوار على أنه كلفة الربط كاملة. ثم يصل عرض مورد نظام الصيانة بعد التوقيع، ومعه رسوم سنوية لم تُحسب.
ومقال تطبيع عروض أنظمة الزوار يضع التكاملات صفًا واحدًا يُحسب بسيناريوهين. أما هذا المقال ففكّ لذلك الصف: من يدفع ماذا داخله، ومرة أم كل سنة.
ثلاثة أطراف يدفع كل منها شيئًا
- مورد نظام الزوار: الجانب البرمجي من طرفه، وتقييم التوافق، والمشاركة في الاختبار، ثم صيانة جانبه عند تحديث نظامه.
- مورد النظام الآخر: إتاحة الواجهة أو ترخيصها، وأي إعداد أو تطوير داخل نظامه، وترقية الإصدار إن لزمت، وأيام الاستشارة، وبيئة الاختبار إن كانت مرخصة، ثم صيانة جانبه عند تحديث نظامه.
- المصنع: وقت تقنية المعلومات ومالك النظام الآخر، والمسار الشبكي وقواعد الحماية، والوسيط إن لزم، ومتابعة الربط يوميًا، والإجراء البديل حين يتعطل. ومصفوفة المسؤوليات في صفحة التطبيق والدعم تضع على المنشأة التنسيق مع مورّد النظام وإتاحة الواجهات، وعلى مورد الزوار الجانب البرمجي من طرفه.
المصنع هو من يدفع في النهاية للأطراف الثلاثة. لكن التمييز مهم لسببين: لأن كل طرف يُسعّر في عرض مختلف وفي وقت مختلف، ولأن من يتعاقد مع مورد النظام الآخر هو المصنع غالبًا لا مورد الزوار.
نموذج التقدير: عشرة بنود
كلفة ربط نظام الزوار بنظام آخر في المصنع
انسخ الجدول لكل تكامل على حدة، فربط نظام الصيانة غير ربط المستودعات. ثم أضف عمودين للأرقام: مرة واحدة، وسنويًا. عمود «السؤال الكاشف» هو ما ترسله لمن يملك الرقم.
| البند | يتحمله عادة | النوع | السؤال الكاشف |
|---|---|---|---|
| ١. تقييم التوافق وتصميم الربط | مورد الزوار، ومورد النظام الآخر بالإجابات | مرة | هل يحتسب أي منكما التقييم والاجتماعات بندًا مستقلًا؟ |
| ٢. ترخيص الواجهة أو تفعيل وحدة الربط في النظام الآخر | مورد النظام الآخر | مرة أو سنوي | هل الترخيص دائم أم سنوي؟ وهل له رسوم بعدد الاستدعاءات أو المستخدمين التقنيين؟ |
| ٣. ترقية إصدار النظام الآخر | مورد النظام الآخر | مرة | هل الإصدار المركّب لدينا يوفر الواجهة؟ وإن لم يفعل، فما الذي تمسّه الترقية خارج الربط؟ |
| ٤. بناء الجانب المقابل في نظام الزوار | مورد الزوار | مرة | ما العمليات المشمولة بالسعر، وما الذي يُعد توسعة تُسعَّر لاحقًا؟ |
| ٥. الإعداد أو التطوير داخل النظام الآخر | مورد النظام الآخر أو مطوّرو المصنع | مرة | هل يحتاج الربط حقلًا أو نوعًا أو محفّزًا جديدًا في نظامكم؟ ومن يبنيه وبأي سعر؟ |
| ٦. الوسيط إن لزم | المصنع أو مكامل | مرة + سنوي | هل الربط مباشر أم عبر طبقة وسيطة؟ وما ترخيصها واستضافتها ومن يصونها؟ |
| ٧. المسار الشبكي والمراجعة الأمنية | المصنع | مرة + متكرر | ما قواعد الحماية والشهادات المطلوبة؟ ومتى تتجدد؟ ومن يراجع الربط أمنيًا؟ |
| ٨. بيئات الاختبار واختبار القبول | الأطراف الثلاثة | مرة + عند كل تحديث | هل للنظام الآخر نسخة اختبار؟ وهل ترخيصها منفصل؟ ومن يجهّز بيانات الاختبار؟ |
| ٩. صيانة الربط عند تحديث أي من النظامين | مورد الزوار ومورد النظام الآخر | متكرر | هل تعديل الربط بعد تحديثكم مشمول في اتفاق الدعم أم يُسعَّر لكل مرة؟ |
| ١٠. التشغيل اليومي للربط | المصنع | متكرر | من يراجع تقرير المطابقة؟ ومن يعالج ما فشل؟ وكم ساعة في الأسبوع؟ |
بعد ملء الأرقام اجمع ثلاثة مجاميع. الأول كلفة البناء: البنود ١ إلى ٨ في عمود «مرة». والثاني الكلفة السنوية: البنود ٢ و٦ و٧ و١٠ في عمود «سنويًا»، ومعها ترخيص بيئة الاختبار في البند ٨ إن كان سنويًا. والثالث كلفة التحديثات: البندان ٨ و٩ محسوبين كما في القسم التالي. ثم احسب كلفة ثلاث سنوات بجمع كلفة البناء وثلاثة أضعاف الكلفة السنوية وكلفة التحديثات على السنوات الثلاث.
ترقية نظام الصيانة أو المستودعات لأجل الربط قد تمس وحدات أخرى ومستخدمين آخرين، وتحتاج اختبارًا لا علاقة له بالزوار. إن ظهر هذا البند، فلا تحمّله على ميزانية نظام الزوار وحدها. وافصل قراره: هل الترقية مخطط لها أصلًا؟ إن كانت كذلك، فأجّل الربط حتى تتم.
الكلفة المتكررة: تقويما تحديث لا تقويم واحد
أكثر ما يُنسى في ميزانية التكامل أن الربط يعيش بين نظامين، لكل منهما مورده وتقويم تحديثاته. كل تحديث في أي طرف قد يستدعي إعادة اختبار الربط، وأحيانًا تعديله. لذلك لا تكفي «رسوم صيانة سنوية» دون معرفة ما تغطيه.
- اعرف عدد التحديثات المتوقعة سنويًا لكل نظام: اسأل كل مورد عن تواتر إصداراته التي قد تمس الواجهة، لا عن كل إصلاح صغير.
- قدّر كلفة دورة إعادة الاختبار الواحدة: وقت مطوّركم أو مالك النظام لتشغيل حالات قبول التكامل في بيئة الاختبار، وما قد يطلبه أي مورد لقاءها.
- اضرب ثم أضف احتمال التعديل: عدد التحديثات في كلفة الدورة، ثم أضف تقديرًا لتعديل فعلي في جزء منها. وإن لم تعرف النسبة، فاحسب الطرفين: لا تعديل، وتعديل عند كل تحديث.
- حدد من يدفع التعديل: الأصل أن يتحمل كل مورد كلفة إبقاء جانبه متوافقًا بعد تحديثه هو. اكتب ذلك في العقدين، ومعه مهلة الإشعار قبل أي تغيير يمس الواجهة.
واسأل مورد الزوار تحديدًا هل صيانة الربط بعد تحديث النظام الآخر مشمولة في اتفاق الدعم أم تُسعّر كل مرة. فدعم النظام بعد التشغيل لا يشمل التكاملات التي لم تكن في النطاق، والتكامل الذي في النطاق تحتاج حدود صيانته نصًا صريحًا.
ثلاثة قرارات بعد ملء النموذج
| القرار | يناسب حين | ما تكتبه قبل اعتماده |
|---|---|---|
| ميزانية تكامل كاملة | كلفة ثلاث سنوات أقل بوضوح من كلفة البديل الإجرائي، أو الربط شرط سياسة لا خيار | بنود الأطراف الثلاثة في عروضهم، ومن يتعاقد مع من، وحدود صيانة الربط في كل عقد |
| تأجيل الربط مع القياس | الأرقام متقاربة أو غير معروفة، وحجم التبادل الفعلي لم يُقس بعد | الإجراء اليدوي بالمرجع، وما يُقاس أسبوعيًا، وتاريخ إعادة القرار |
| ربط أبسط أو بديل إجرائي | بند أو بندان يرفعان الكلفة وحدهما، كترقية الإصدار أو الترخيص السنوي | ما يُفقد مقارنة بالربط الكامل، مثل الاكتفاء بالقراءة دون إرسال، أو تصدير دوري بدل الربط اللحظي |
البديل الإجرائي ليس فشلًا. يعمل نظام الزوار دون أي ربط، ويمكن تسجيل مرجع أمر العمل أو أمر التوريد في الزيارة يدويًا. وإن تقرر الربط، فقبل بناء أي شيء، افحص الواجهة التي سيُبنى عليها كما في مقال فحص واجهة الربط قبل الشراء، ثم حوّل القرار إلى بطاقة تكامل قابلة للاختبار.
مثال حسابي بوحدات رمزية
ربط نظام الزوار بنظام الصيانة لزيارات المقاولين
مثال توضيحي افتراضيمثال توضيحي افتراضي، وليس نتيجة تشغيل موثقة لعميل. الأرقام «وحدات كلفة» رمزية تشرح طريقة الحساب وحدها، ولا تمثل سعرًا لنا أو لغيرنا. يريد المصنع أن تُنشأ زيارات المقاولين من أوامر العمل الخارجية في نظام الصيانة. عرض مورد الزوار سعّر جانبه من الربط بعشر وحدات.
- مورد نظام الصيانةطلب ترخيص وحدة الواجهة بست وحدات سنويًا، وترقية إصدار بخمس عشرة وحدة مرة واحدة، وأربع وحدات استشارة، ووحدتين سنويًا لنسخة اختبار.
- المصنعقدّر ثلاث وحدات لعمل تقنية المعلومات على المسار الشبكي والمراجعة، ووحدتين سنويًا لمتابعة المطابقة ومعالجة ما يفشل.
- التحديثاتتحديثان سنويًا في كل نظام قد يمسان الواجهة، فأربع دورات إعادة اختبار سنويًا بثلاثة أرباع وحدة لكل منها، أي ثلاث وحدات سنويًا.
- المجموعالبناء: عشر وأربع وخمس عشرة وثلاث، أي اثنتان وثلاثون وحدة. والسنوي: ست واثنتان واثنتان وثلاث، أي ثلاث عشرة وحدة. فكلفة ثلاث سنوات إحدى وسبعون وحدة، مقابل عشر وحدات ظهرت في عرض مورد الزوار.
- القرارتأجيل الربط ثلاثة أشهر بإجراء يدوي: يُسجَّل رقم أمر العمل في الزيارة، ويُقاس عدد زيارات المقاولين المرتبطة بأوامر عمل أسبوعيًا. ثم أُعيد السؤال بخيار أبسط، هو قراءة أوامر العمل المعتمدة من تصدير دوري، فسقطت الترقية والترخيص السنوي من الحساب.
المثال لا يقول إن الربط غير مجدٍ. يقول إن القرار اتُخذ على إحدى وسبعين وحدة معروفة المصدر، لا على عشر.
أسئلة متكررة
لأنه لا يملك تسعيرها ولا يستطيع الالتزام بها. ترخيص الواجهة وترقية الإصدار قرار مورد النظام الآخر وسعره. الصحيح أن يذكرها عرض مورد الزوار افتراضاتٍ معلنة، أي ما يحتاجه من الطرف الآخر، وأن تطلب أنت سعرها من ذلك الطرف قبل الترسية.
المصنع غالبًا، لأنه صاحب العلاقة والعقد القائم مع ذلك المورد. وإن رغبتم في عقد واحد يجمع الطرفين عبر مكامل، فهذا هيكل توريد مختلف له مزاياه وكلفته الإدارية، ويقارنه مقال عقد واحد مع مكامل أم عقود منفصلة. وفي الحالتين اكتبوا من يُسأل إن تعطل الربط.
اسأل عن ذلك نصًا. دعم النظام يغطي الأعطال والاستفسارات والتحديثات، ولا يشمل التكاملات التي لم تكن في النطاق. أما تعديل ربط مشمول بعد تحديث يجريه مورد النظام الآخر، فاطلب أن يُحدد: مشمول، أو بسعر وحدة معلن.
أحيانًا. قد يغني الوسيط عن ترقية النظام الآخر أو يعزل الطرفين عن تحديثات بعضهما، لكنه يضيف ترخيصًا واستضافة وطرفًا ثالثًا يصونه. ضعه في النموذج بديلًا مستقلًا واحسب ثلاث سنواته، ولا تفترض أنه أرخص.
يحدث هذا، وخصوصًا مع الأنظمة القديمة. البدائل: الاكتفاء بربط جزئي، أو طبقة وسيطة حين تسمح بيئة النظام، أو تصدير دوري، أو تشغيل الإجراء بالمرجع اليدوي. نظام الزوار يعمل كاملًا دون الربط، فلا يتوقف المشروع على قرار طرف آخر.