تشغّل معظم المؤسسات المتوسطة والكبيرة عدة أنظمة أساسية اشترتها في أوقات مختلفة من موردين مختلفين. يحتفظ نظام ERP بالبيانات المالية وبيانات الإمداد، ويحتفظ نظام CRM بتفاعلات العملاء، وفي القطاع الصحي يحتفظ نظام معلومات المستشفى، المعروف اختصارًا بـ HIS، بسجلات المرضى والطلبات والفوترة. ربط هذه الأنظمة نادرًا ما يكون الجزء الأكثر ظهورًا في المشروع، لكنه كثيرًا ما يحدد ما إذا كان المشروع سينتهي في موعده. يتناول هذا المقال أكثر المشكلات تكرارًا والممارسات التي تقلل منها.
لماذا تتأخر مشاريع التكامل
تميل تقديرات التكامل إلى التفاؤل لأن العمل يبقى خفيًا إلى أن يبدأ. وتتكرر أربعة أسباب.
- حقول غير موثقة. في الجدول عمود يُستخدم لغرض لا يتذكره أحد، والطريقة الوحيدة لمعرفة معناه هي سؤال من أعدّه قبل سنوات.
- مصدران للحقيقة. بيانات العملاء أو المنتجات موجودة في النظامين، والنسختان غير متطابقتين. يجب أن يقرر أحدهم أيهما يُعتمد وفق أي قواعد.
- توقعات متباينة بين المعالجة الدفعية والزمن الحقيقي. يطلب مستخدم الأعمال بيانات حديثة، ولا يستطيع النظام المصدر إلا التصدير ليلًا، ويُكتشف هذا الفارق متأخرًا.
- واجهات يتحكم بها المورّد. يحدد المورّد الواجهات المتاحة وتكلفتها وموعد تغييرها، فيصبح فريق التكامل معتمدًا على جداول زمنية خارجية.
خيارات الواجهات
يعتمد اختيار الواجهة على ما يدعمه النظام المصدر ومدى حداثة البيانات المطلوبة. خدمات الويب REST وSOAP هي الطريق الأكثر شيوعًا لمنتجات ERP وCRM الحديثة. فهي تدعم تبادل الطلب والاستجابة وسهلة المراقبة، لكنها تتطلب أن يتيح النظام المصدر العمليات المناسبة.
ما زال تبادل الملفات واسع الانتشار. التصديرات المجدولة بصيغة CSV أو XML بسيطة ومتينة، وتناسب التقارير والمزامنة الليلية. أما طوابير الرسائل فتفصل المرسل عن المستقبل، فيمكن أن يتعطل أحد الطرفين لفترة دون فقدان بيانات. وهي مناسبة للتدفقات المعتمدة على الأحداث التي يهم فيها الترتيب وضمان التسليم.
في البيانات الصحية ما زالت رسائل HL7 الإصدار 2 شائعة في الإدخال والطلبات والنتائج، ويتزايد استخدام FHIR للتبادل عبر واجهات API. استخدام هذه المعايير يقلل من الربط المخصص، وإن بقي لزامًا الاتفاق مع كل مورّد على الملفات التعريفية والامتدادات المحلية.
ربط الحقول وجودة البيانات
ربط الحقول هو جوهر العمل. يسجل الفريق لكل حقل مصدره وهدفه والتحويل المطلوب وقاعدة حل التعارضات. وتستحق قوائم الرموز والوحدات وصيغ التواريخ وترميزات الأحرف والمعرّفات عناية خاصة، فقد يحمل المريض أو العميل أو المنتج معرّفًا مختلفًا في كل نظام.
تظهر مشكلات جودة البيانات عادة في هذه المرحلة، مثل السجلات المكررة والقيم الإلزامية المفقودة والحقول النصية الحرة المستخدمة كرموز. ومن الأفضل معالجتها عند المصدر بقواعد تنظيف يُتفق عليها مع مالكي البيانات، لا ترقيعها داخل الواجهة حيث تصبح غير مرئية.
الأمن والتدقيق
ينبغي أن تتبع حسابات التكامل مبدأ أقل الصلاحيات، فتقتصر على العمليات التي تحتاجها الواجهة. وكل استدعاء يقرأ بيانات شخصية أو يعدّلها يجب تسجيله مع بيان من أجراه وماذا وفي أي وقت، وأن تُحمى السجلات وتُحفظ وفق السياسة المعتمدة.
تخضع البيانات الشخصية لقانون KVKK في تركيا ولائحة GDPR في الاتحاد الأوروبي. وفي البيانات الصحية تكون المتطلبات أشد. ويجب أن يحدد تصميم التكامل البيانات المنقولة والغرض من نقلها وكيفية حمايتها أثناء النقل وفي التخزين ومدة الاحتفاظ بالنسخ.
الاختبار والتراجع
ينبغي اختبار الواجهات ببيانات واقعية، تشمل الحالات الحدية مثل الأسماء الطويلة والأحرف الخاصة والطلبات الملغاة والنتائج المصححة. وتفيد بيئات الاختبار التي تطابق إصدارات الإنتاج في النظامين، لأن السلوك يختلف غالبًا بين الإصدارات. وعلى خطة الانتقال أن تحدد ترتيب الخطوات والفحوص بعد كل خطوة والشروط التي يعود فيها الفريق إلى الحالة السابقة.
التشغيل بعد الإطلاق
الواجهة خدمة قيد التشغيل. تحتاج إلى مراقبة للأعطال والتأخيرات، وطابور أخطاء تُفحص فيه الرسائل المرفوضة وتُعاد معالجتها، وتنبيهات تصل إلى شخص محدد بالاسم. ويجب أن يكون لكل واجهة مالك من جهة الأعمال وآخر من الجهة التقنية، مع توثيق يصف غرضها وجدولها والربط فيها وحدودها المعروفة. وبغير ذلك تتراكم الأعطال الصغيرة حتى تتوقف بيانات النظامين عن التطابق.