نعم، يمكن ربط نظام الأرشفة بأنظمة ERP وCRM، لكن «التكامل» ثلاث درجات مختلفة في الجهد والمدة والتكلفة. في وثيقة: تكاملات جاهزة مع Microsoft 365 وSAP ERP وOracle والبريد الإلكتروني وActive Directory / LDAP؛ وربط عبر REST API لأنظمة مثل Microsoft Dynamics وOdoo وأنظمة الموارد البشرية وCRM، يُحدَّد نطاقه في العرض الفني؛ وتخصيص لمنطق خاص بإجراءاتك.
قبل طلب العرض، صنّف كل نظام تريد ربطه في إحدى الدرجات الثلاث، واكتب لكل ربط: الحدث الذي يطلق الأرشفة، والحقول التي تنتقل، والاتجاه.
هذا المقال لمدير تقنية المعلومات ومدير الأنظمة المؤسسية ومالكي أنظمة ERP وCRM الذين يسألون قبل شراء نظام أرشفة: هل سيعمل مع ما لدينا؟ الجواب المختصر «نعم» لا يكفي لكتابة كراسة أو مقارنة عرضين؛ ما يلزمك هو معرفة أي نوع من الربط تحتاج، وما الذي يدخل فيه، وكيف تختبره.
ثلاث درجات للتكامل
| الدرجة | الأنظمة | ما يعنيه للنطاق |
|---|---|---|
| تكامل جاهز | Microsoft 365 (مع SharePoint وOneDrive)، SAP ERP، Oracle، البريد الإلكتروني، Active Directory / LDAP | نطاقه معروف ويُهيأ ضمن التنفيذ. تكامل Microsoft 365 مشمول في الباقة الاحترافية، وتكامل SAP وOracle ضمن الباقة المؤسسية |
| ربط عبر REST API | Microsoft Dynamics، Odoo، أنظمة الموارد البشرية، أنظمة CRM، أنظمة الاتصالات الإدارية، أنظمة التوقيع الإلكتروني، وأي نظام يملك واجهة برمجية | يُكتب له نطاق: الأحداث، والحقول، والاتجاه، ومعالجة الأخطاء. يُحدَّد في العرض الفني بعد معرفة النظام وإصداره وواجهته |
| تخصيص | منطق خاص بإجراءاتك: شاشات أو حقول محسوبة من نظام آخر أو قواعد أو تقارير غير متوفرة في الإعداد القياسي | يحتاج تحليلًا مسبقًا واختبارًا مشتركًا، ويُسعَّر بحسب التصميم المتفق عليه |
كلما انتقل الربط من الدرجة الأولى إلى الثالثة، زادت الحاجة إلى مشاركة مالك النظام الآخر ومورده، وزاد أثره على الجدول الزمني. لذلك لا تكتب في الكراسة «تكامل مع ERP» فقط؛ اكتب اسم النظام وإصداره وما تريده منه.
ولاحظ أن اسم النظام وحده لا يحدد الدرجة: ربط SAP لأرشفة مستندات المعاملات تكامل جاهز، لكن طلب شاشة خاصة داخل SAP تعرض حقولًا محسوبة من الأرشيف قد يدخل في التخصيص. التصنيف يكون للاستخدام المطلوب لا للنظام فقط.
ما الذي يتغير فعلًا عند الربط؟
بدون ربط: يُدخل الموظف الفاتورة في النظام المحاسبي، ثم يمسحها، ثم يرفعها يدويًا في الأرشيف، ثم يكتب رقمها مرة ثالثة ليجدها لاحقًا. المعلومة نفسها تُدخل مرات، وكل إدخال فرصة لخطأ أو لنسيان.
مع الربط: تُدخل المعلومة مرة واحدة في النظام المصدر، وتصل الوثيقة إلى الأرشيف مع رقم المعاملة وتاريخها وجهتها، فيجدها صاحب الصلاحية من الأرشيف أو من سياق المعاملة. والأهم أن الوثيقة المعتمدة تحصل على ما لا توفره مرفقات ERP عادة: إصدارات، وبحث داخل النص، وسجل تدقيق، وصلاحيات لمستخدمين من خارج ERP.
مرفقات ERP مصممة لربط ملف بسجل تجاري، وتختلف قدراتها بين الأنظمة. SAP مثلًا يحتاج نظام تخزين أو Content Server لخدمة ArchiveLink، وOracle Fusion يعتمد على بيئة WebCenter Content منفصلة للمرفقات المدارة. هذا من أسباب ربط ERP بمستودع وثائق مستقل؛ ناقشنا الخيارين في مرفقات ERP أم أرشيف مركزي مستقل.
سيناريوهات ERP الأكثر طلبًا
أوامر الشراء وسلسلة التوريد
قبل: أمر الشراء في ERP، ووثيقة الموافقة وعرض السعر في مجلد منفصل. بعد: عند اعتماد أمر الشراء تُؤرشف مستنداته الداعمة في ملف المعاملة، برقم الأمر والمورد والمشروع، ويصل إليها المراجع دون بحث في المجلدات. لـ SAP تحديدًا راجع ربط مرفقات معاملات SAP بنظام وثائق مركزي.
ملفات الموظفين
قبل: بيانات الموظف في نظام الموارد البشرية، وعقده وشهاداته ومؤهلاته في مجلد. بعد: ملف الموظف في الأرشيف مرتبط برقمه الوظيفي، بصلاحيات الموارد البشرية وحدها، وتنبيهات لانتهاء الوثائق المرتبطة. الربط مع نظام الموارد البشرية يُنفَّذ عبر API ويُحدَّد نطاقه في العرض الفني.
التقارير المالية المعتمدة
قبل: التقرير يُصدَّر من ERP ويُحفظ يدويًا. بعد: النسخة المعتمدة تُؤرشف بتاريخ اعتمادها ومستوى صلاحيتها، ويُحفظ كل إصدار لاحق.
CRM والمحاسبة: الوثيقة في سياق العميل والفاتورة
في CRM الهدف أن تجد كل وثائق العميل من مكان واحد: العقد، والعروض، والمراسلات، والشكاوى ومرفقاتها. سيناريوهات شائعة:
- صفحة العميل في CRM تعرض رابطًا إلى ملفه في الأرشيف، لمن يملك الصلاحية في الأرشيف.
- عند إغلاق صفقة يُنشأ ملف عقد في الأرشيف ليبدأ مسار مراجعته واعتماده.
- الشكوى تُربط بالفاتورة أو العقد المعني دون نسخ المستند.
كل هذه تُنفَّذ عبر واجهة REST API، ويُحدَّد في العرض الفني أيها يدخل في النطاق. نفصّل متطلباتها في تكامل CRM مع الأرشفة لتجميع وثائق العميل في مسار واحد.
وفي المحاسبة، يتيح وثيقة OCR للفواتير الممسوحة واستخراج البيانات الرئيسية من المستندات، ومسارات موافقة للمستندات المالية. أما ترحيل البيانات المستخرجة آليًا إلى النظام المحاسبي، أو أرشفة أمر الدفع تلقائيًا عند اعتماده في المحاسبة، فربط عبر API يُحدَّد نطاقه في العرض الفني بحسب النظام المحاسبي وواجهته.
الافتراضات: شركة توزيع تستخدم Odoo للمبيعات والمشتريات، وتريد أن تصل فواتير الموردين المعتمدة إلى الأرشيف دون رفع يدوي. هذا ربط عبر API، وهذه صيغة مختصرة لنطاقه كما تُكتب قبل العرض:
- الحدث: تغيّر حالة فاتورة المورد في Odoo إلى «معتمدة».
- المستند: ملف الفاتورة المرفق في Odoo (PDF أو صورة ممسوحة).
- الحقول: رقم الفاتورة، والمورد، والتاريخ، والمبلغ، ورقم أمر الشراء، والفرع.
- الوجهة: نوع وثيقة «فاتورة مورد» في مجلد المورد، بصلاحيات المالية والمشتريات فقط.
- الاتجاه: من Odoo إلى الأرشيف، مع حفظ رابط الوثيقة المؤرشفة في سجل الفاتورة إن سمحت واجهة Odoo بذلك.
- الأخطاء: إعادة المحاولة عند انقطاع الاتصال، ومنع إنشاء نسخة ثانية إن أُعيد الإرسال، وسجل للأخطاء يراجعه مسؤول النظام.
- الحجم: عدد الفواتير الشهري التقريبي لتقدير الحمل.
- الحساب التقني: حساب ربط بصلاحية كتابة في مجلدات الفواتير فقط، تظهر عملياته في سجل التدقيق باسمه.
بهذه الصفحة الواحدة يستطيع أي مورد أن يقدّر الجهد بدقة، وتستطيع أنت مقارنة عرضين على النطاق نفسه.
كيف يُبنى الربط تقنيًا؟ وأي الطرق تتجنب
عبر واجهة برمجية (API)
الطريقة المفضلة: النظامان يتبادلان الأحداث والبيانات عبر واجهات موثقة، بحساب تقني بصلاحيات محددة، وتُسجل العمليات في سجل التدقيق. يتيح وثيقة REST API لهذا الغرض.
تبادل ملفات مجدول
يصدّر النظام القديم ملفات وبيانات بصيغة متفق عليها، وتُستورد دوريًا. مفيد لأنظمة قديمة بلا واجهات، لكنه أبطأ وأضعف في معالجة الأخطاء. إن احتجته فهو تخصيص يُحدَّد في النطاق.
الوصول المباشر لقاعدة البيانات
القراءة أو الكتابة في جداول نظام آخر مباشرة. تتجنبها معظم الجهات لأنها تتجاوز منطق النظام وصلاحياته، وتنكسر مع أي تحديث. لا تعتمدها إلا باستثناء موثق وموافقة مالك النظام.
ثلاثة مستويات عمق: ابدأ بأبسط ما يحقق الهدف
| المستوى | ما يحدث | متى يكفي |
|---|---|---|
| روابط ووصول | من سجل المعاملة رابط إلى وثائقها في الأرشيف | بداية جيدة حين يكون الهدف الوصول لا الأتمتة |
| أرشفة في اتجاه واحد | حدث في النظام المصدر يرسل الوثيقة وحقولها إلى الأرشيف | معظم حالات الفواتير وأوامر الشراء وملفات الموظفين |
| تزامن في الاتجاهين | تغيّر الحالة أو الحقول في أي طرف ينعكس في الآخر | حين تعتمد الإجراءات في النظامين على الحالة نفسها، مع تحليل دقيق لحل التعارض |
المستوى الأعمق ليس الأفضل دائمًا. التزامن في الاتجاهين يضيف حالات تعارض يجب تصميم حلها واختبارها. ابدأ بأبسط مستوى يحقق هدفك، ووسّع بعد أن يستقر.
أخطاء تتكرر في مشاريع الربط: كتابة «تكامل مع ERP» دون تحديد الحدث والحقول؛ نسيان صلاحيات الأرشيف فيرى مستخدم ERP وثيقة لا يحق له رؤيتها؛ غياب منع التكرار فتتضاعف الوثائق مع كل إعادة إرسال؛ عدم إشراك مورد النظام الآخر حتى مرحلة الاختبار؛ وترك صيانة الربط بلا مالك عند تحديث أحد النظامين. كل واحد من هذه يظهر بعد الإطلاق لا قبله، فاكتب معالجته في النطاق.
ما تسأله وتختبره قبل التعاقد
أسئلة لكل ربط مطلوب
- هل هذا الربط تكامل جاهز أم عبر API أم تخصيص؟ اكتبوا التصنيف في العرض.
- ما الحدث الذي يطلق الأرشفة، وما الحقول التي تنتقل مع الوثيقة؟
- ماذا يحدث إذا أُرسلت الوثيقة نفسها مرتين؟ وإذا انقطع الاتصال أثناء الإرسال؟
- ما الحساب التقني المستخدم وصلاحياته، وهل تظهر عملياته في سجل التدقيق؟
- هل يرى مستخدم ERP الوثيقة في الأرشيف إن لم تكن له صلاحية عليها؟
- من يصون الربط عند تحديث أي من النظامين؟
- ما المطلوب من مالك النظام الآخر أو مورده؟
ولمعايير تقييم الواجهة البرمجية نفسها (الأخطاء، وإعادة المحاولة، ومنع التكرار، وحدود الاستخدام) راجع تقييم API الأرشفة قبل الاعتماد.
الخطوة التالية
أرسل لفريق وثيقة قائمة الأنظمة التي تريد ربطها، ولكل منها: الاسم والإصدار، وطريقة الاستضافة، ووجود واجهة برمجية موثقة، والمستندات المعنية، والحدث الذي يطلق الأرشفة، والحجم التقريبي. نعود إليك في العرض الفني بتصنيف كل ربط ونطاقه. نموذج المتطلبات الكامل وطريقة الاختبار في صفحة التكاملات: Microsoft 365 وSAP وOracle والبريد وREST API. وللفرق بين أنواع الأنظمة نفسها راجع ما الفرق بين DMS وECM وCRM.
أرسل متطلبات التكامل للحصول على عرض فني
حدّد النظام المطلوب ربطه، واتجاه البيانات، والحقول، وعدد المعاملات التقريبي؛ لنميّز ما هو تكامل منشور وما يُنفّذ عبر API ضمن نطاق.
- عدد المستخدمين المتوقع والإدارات المشاركة
- حجم الأرشيف الحالي تقريباً (عدد الملفات أو الصفحات أو الحجم بالجيجابايت) ونسبة الورقي منه
- نموذج الاستضافة المفضل: سحابة داخل المملكة أو خوادم الجهة
- النظام الحالي للملفات والأنظمة المطلوب التكامل معها
الهاتف وواتساب: +966 56 533 0501 — الأحد إلى الخميس 9 صباحاً حتى 6 مساءً.