نظامان وعميل واحد: من يملك السجل الصحيح؟

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

ماذا يحدث حين يكون النظامان على حق؟

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

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

من يملك كل سجل؟

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

السجل	المالك	الطرف الآخر
هوية العميل	نظام إدارة العلاقات (CRM)	يقرأ ولا يعدل
سقف الدين	المحاسبة	يقرأ قبل البيع
كمية المخزون	دفتر المخزن	يقرأ ويطلب تحويلا
قائمة الأسعار	المبيعات	يقرأ ويحفظ نسخة

والملكية لكل حقل، لا لكل نظام. يمكن أن يملك نظام الاسم القانوني وآخر عنوان التوصيل، وهذا ترتيب سليم ما دام مكتوبا. الحقول التي لا مالك لها هي التي تنحرف.

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

هل يكفي الربط في اتجاه واحد؟

الاتجاه الواحد تصميم، والاتجاهان تفاوض يجري بسرعة الآلة. اختر اتجاها واحدا لكل حقل، ودع الطرف الآخر يقرأ.

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

قاعدة «آخر كتابة تفوز» ليست قاعدة، بل قرار بضياع البيانات بهدوء. وإن لم تستطع تسمية الفائز، فأرسل الخلاف إلى قائمة يفرغها إنسان. البطيء الظاهر أفضل من السريع الصامت.

لماذا تظهر التكرارات والربط يعمل؟

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

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

ماذا يحدث حين يفشل الربط في منتصف الطريق؟

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

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

والفشل الذي يجب التصميم ضده هو الصمت. قائمة توقفت عن العمل تشبه قائمة لا عمل لها، وأول من يلاحظ عادة عميل.

لماذا «سنربطهما» ليس تصميما؟

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

وهناك اختبار مضمون: اسأل من يدير العمل اليوم ماذا يفعل حين يختلف النظامان. إن كان الجواب «أعرف أيهما أثق به»، فالقرار موجود، لكنه في رأس واحد لا في البرنامج.

بأي ترتيب تفعل هذا؟

1. اكتب أنواع السجلات التي تعبر الحد. عميل، منتج، سعر، طلب، فاتورة، مخزون.
2. لكل نوع، حدد أين ينشأ وأين تقع كلفة الخطأ. ذلك النظام يملكه.
3. ابن جدول الحقول، وأشر إلى ما لا مالك له. تلك هي الحقول المتنازع عليها، وهي تفسر معظم الفوضى الحالية.
4. اختر اتجاها لكل حقل. معظمها يحتاج اتجاها واحدا، وقليلها يحتاج قائمة خلافات.
5. احسم قاعدة الفشل والشخص الذي يبلغ، قبل الكود. شخص باسمه، لا قناة.
6. أضف مطابقة عددية يومية لكل نوع سجل. رقم واحد يجب أن يتساوى في الجهتين.
7. ابن الربط، ثم احذف التصدير اليدوي. إن بقي التصدير، فالربط غير موثوق بعد.

أين يخطئ هذا؟

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

ما لا يغطيه هذا المقال

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

نبني الوصلة بين الأنظمة التي تملكها بالفعل: مالك لكل سجل، واتجاه واحد لكل حقل، وفشل يعلن نفسه بدل أن ينتظر من يكتشفه.