تطوير نظام أرشفة خاص أم شراء حل قابل للتخصيص؟

«نظام أرشفة؟ فريقنا يستطيع بناءه في بضعة أشهر». تُقال هذه الجملة في كثير من اجتماعات تقنية المعلومات، وهي ليست خاطئة دائمًا. هذا المقال لصاحب القرار ومدير تقنية المعلومات الذي يوازن بين التطوير الداخلي أو عبر شركة برمجيات، وبين شراء نظام إدارة وثائق (DMS) وتخصيصه. سنفكك ما يحتويه «نظام أرشفة بسيط» فعلًا، ونعطيك بطاقة تقييم قابلة للنسخ مع مثال محسوب.

ما الذي يحتويه نظام أرشفة «بسيط»؟

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

لا يعني هذا أن البناء مستحيل. يعني أن تقدير «بضعة أشهر» يغطي عادة الصف الأول من البطاقات، وأن الصفوف التالية هي ما يستهلك السنوات.

ماذا تعني «قابلية التخصيص» عند الشراء؟

الخيار ليس «منتج جاهز كما هو» مقابل «بناء من الصفر». بينهما طيف، ومن المفيد أن تصنف كل متطلب لديك في مستوى من المستويات الأربعة التالية، وأن تطلب من المورد التصنيف نفسه:

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

متى يكون البناء خيارًا وجيهًا؟

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

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

بطاقة تقييم البناء مقابل الشراء

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

مثال محسوب

بنود المقارنة المالية على خمس سنوات

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

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

الطريق الثالث: اشترِ النواة وابنِ الأطراف

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

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

أين يخطئ من يقارن

مقارنة تكلفة البناء بسنة اشتراك

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

تقدير البحث العربي بالحدس

البحث في نص عربي ممسوح بجودة متفاوتة مسألة غير بسيطة. قبل أن تكتب «سنستخدم مكتبة OCR مفتوحة»، اختبرها على مئة وثيقة من أرشيفك وقِس النتيجة.

الاعتماد على مطور واحد

النظام المبني داخليًا يحمل معرفة من بناه. إن غادر، ورثت الجهة كودًا بلا توثيق كافٍ. اجعل التوثيق ونقل المعرفة بندًا في الخطة لا أمنية.

التخصيص الذي يمنع الترقية

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

أسئلة تطرحها على مورد الحل القابل للتخصيص

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

وثيقة كخيار شراء قابل للتخصيص

يغطي وثيقة الصفوف الثمانية من بطاقات «ما تحت السطح» بقدرات متاحة: نموذج بيانات بتصنيف هرمي ووسوم وفلاتر، وإصدارات مع العودة لأي إصدار، وOCR عربي وإنجليزي وبحث داخل النص وبحث دلالي، وصلاحيات بالأدوار على مستوى المجلد والمستند مع ربط AD وLDAP، وسجل تدقيق محمي بالتجزئة وقابل للتصدير، ومسارات موافقة متعددة المراحل بتذكيرات وتحويل تلقائي، وتشفير TLS 1.3 أثناء النقل وAES-256 أثناء التخزين مع مصادقة ثنائية، ووصول من المتصفح والجوال، وREST API للتكامل.

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

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

كيف تمضي من هنا

1. اكتب قائمة متطلباتك وصنّفها في المستويات الأربعة بنفسك أولًا.
2. املأ بطاقة التقييم بعد عرضين توضيحيين على الأقل، لا قبلهما.
3. اعرض النتيجة على الإدارة المالية مع جدول بنود الخمس سنوات، لا بطاقة التقييم وحدها.
4. اطلب من وثيقة تصنيف متطلباتك وعرض سعر يفصل الترخيص عن التخصيص عن التكامل عبر طلب عرض يفصل الترخيص عن التخصيص.