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

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

أين يختبئ الإدخال المزدوج

نادراً ما يكون لحظة واحدة كبيرة. إنه سلسلة من الحركات الصغيرة، ومن يقومون بها لم يعودوا يلاحظونها.

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

العلامة بسيطة: إذا استطعت أن تسمّي معلومة — رقم هاتف، مبلغ، تاريخ — يكتبها إنسان في أكثر من شاشة خلال الأسبوع نفسه، فهناك ربط ينتظر أن يُبنى.

والعلامة الثانية هي التصحيح. يغيّر أحدهم عنوان توصيل في نظام واحد، ثم عليه أن يتذكّر النظامين الآخرين. في نصف الحالات يتذكّر. والنصف الآخر هو مصدر التوصيلات الخاطئة ومكالمات «لم تصلنا هذه الفاتورة أبداً».

ما هو الربط؟ في سطر واحد

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

عملياً هناك ثلاثة مستويات، من الأرخص إلى الأغلى.

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

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

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

أي ربط تبني أولاً

لا تربط كل شيء. اربط شيئاً واحداً بإتقان.

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

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

حدّد من صاحب القرار في كل معلومة

هذا هو الجزء الذي يختلّ عادةً، وهو ليس جزءاً تقنياً.

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

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

الربط بلا مالك يتدهور بصمت. هذا هو سبب الفشل الحقيقي، وليس البرمجة.

ما يُفعل هذا الأسبوع

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

وإن فضّلت أن ينظر أحدهم في نظاميك ويقول لك بوضوح هل يكفي رابط جاهز أم يلزم تطوير حقيقي، فهذا حديث يسرّنا في ITSysPro أن نجريه معك، دون التزام.