- القرار ليس بين خيارين بل ثلاثة: نظام جاهز بالتهيئة فقط، ونظام جاهز مع تطوير إضافي محدد، وتطوير نظام كامل بفريق داخلي أو عبر مقاول.
- التطوير الكامل يكون مبررًا حين تجتمع ثلاثة شروط: الأرشفة جزء لا ينفصل عن منصة أساسية تملكها الجهة وتطورها، ولدى الجهة فريق دائم سيصونها سنوات، ومتطلباتها الجوهرية الفريدة كثيرة ولا تحققها التهيئة ولا الإضافات.
- أغلب الجهات تجد أن ما تراه «فريدًا» يتحقق بالتهيئة أو بإضافات محدودة، وأن ما يُستهان به في تقدير البناء هو الطبقات غير المرئية: قراءة النصوص العربية والبحث، والإصدارات، وسجل التدقيق، والاحتفاظ، والصلاحيات في نتائج البحث، والصيانة الأمنية.
- افرز متطلباتك قبل القرار: كم منها يتحقق بالتهيئة، وكم بتطوير إضافي، وكم فريد وجوهري فعلًا. هذا الفرز يحسم أغلب الحالات دون جدل.
هذه المقالة للإدارة العليا وصاحب قرار المشروع، حين يُطرح في الاجتماع: «لدينا فريق تقنية، فلماذا لا نبني نظامنا؟» أو العكس: «لماذا نطوّر شيئًا موجودًا في السوق؟». نعرض فيها الخيارات الثلاثة بمعايير الوقت والتكلفة الكلية والصيانة والمعرفة والمخاطر والملكية والأمن، ونحدد متى يكون كل خيار هو الأنسب، بما في ذلك الحالات التي يكون فيها التطوير الكامل قرارًا صحيحًا.
ما الذي نقارنه بالضبط؟
كثير من نقاشات «نشتري أم نطوّر» تتعثر لأن كل طرف يقصد شيئًا مختلفًا. عرّف الخيارات أولًا:
- جاهز بالتهيئة فقط: نظام قائم تضبط فيه الجهة أنواع الوثائق وحقولها والتصنيف والصلاحيات والمسارات والتنبيهات والتقارير من الإعدادات، دون برمجة. ما لا تحققه الإعدادات إما يُتنازل عنه أو يُعالج بإجراء إداري.
- جاهز مع تطوير إضافي: النظام نفسه، مع تطوير خاص بنطاق محدد لما لا تغطيه التهيئة: تكامل مع نظام داخلي، أو تقرير بمعادلة خاصة، أو شاشة لإجراء فريد. القلب جاهز ومُختبر، والإضافات محدودة ومعروفة.
- تطوير كامل: بناء النظام من البداية، بفريق الجهة أو عبر شركة برمجيات بعقد تطوير. قد يستخدم مكتبات أو منصات مفتوحة المصدر، لكن الجهة تتحمل تصميم النظام وبناءه واختباره وصيانته.
والتمييز بين التهيئة والتطوير الإضافي مهم لأنه يغيّر حسابات التكلفة والتحديثات، ويوضحه الفرق بين التهيئة والتطوير الخاص بأمثلة.
المقارنة بالمعايير السبعة
| المعيار | جاهز بالتهيئة | جاهز مع تطوير إضافي | تطوير كامل |
|---|---|---|---|
| الوقت حتى أول استخدام فعلي | الأقصر؛ يحدده التصنيف والترحيل والتدريب لا البرمجة | قصير للقلب، والإضافات تُطلق معه أو في مرحلة لاحقة | الأطول؛ بناء القلب نفسه قبل أي قيمة، ثم الترحيل والتدريب |
| التكلفة الأولية | الأقل عادة: ترخيص وتنفيذ | أعلى بقدر الإضافات، وكل إضافة بند مستقل | قد تبدو أقل إن احتُسبت رواتب قائمة، وهي في الواقع الأعلى عند احتساب كل الطبقات |
| التكلفة الكلية لعدة سنوات | متوقعة: رسوم دعم أو اشتراك | متوقعة مع بند لصيانة الإضافات مع التحديثات | فريق صيانة دائم، وبنية، واختبارات أمن، وإحلال من يغادر؛ ويصعب تقديرها مسبقًا |
| الصيانة والتحديثات | على المورد، والإعدادات تنتقل مع التحديثات | على المورد، مع اختبار الإضافات في كل تحديث | على الجهة بالكامل، بما فيها مواكبة أنظمة التشغيل وقواعد البيانات والثغرات |
| المعرفة والاعتماد على أفراد | تعتمد على المورد، ويخففها تدريب مسؤول النظام والتوثيق | كالسابق، مع توثيق الإضافات | تتركز في المطورين الذين بنوه؛ مغادرة واحد منهم خطر تشغيلي |
| المخاطر | ألا يغطي النظام متطلبًا مهمًا؛ تُكشف في العرض التوضيحي والقبول | اتساع الإضافات حتى تثقل التحديثات | تجاوز المدة والميزانية، ونقص وظائف مؤسسية لم تُقدّر، وتوقف المشروع قبل اكتماله |
| الملكية | البيانات للجهة بنص العقد، والمنتج للمورد | كالسابق، وملكية الإضافات أو حق استخدامها يُحدد تعاقديًا | الشفرة كاملة للجهة، إن نص عقد المقاول على ذلك |
| الأمن | يعتمد على نضج المنتج وتحديثاته، ويمكن تشغيله داخل شبكة الجهة | كالسابق، مع مراجعة أمن الإضافات | تحكم كامل، ومسؤولية كاملة: تطوير آمن، واختبار اختراق، وتصحيح مستمر |
لاحظ أن الجدول لا يقول إن التطوير الكامل خطأ. يقول إنه يشتري الملكية الكاملة والتحكم الكامل بثمن في الوقت والتكلفة المستمرة والاعتماد على الأفراد. السؤال إذن: هل تحتاج جهتك هذه الملكية بما يبرر هذا الثمن؟
ما لا يظهر في تقدير «سنبنيه بأنفسنا»
أغلب تقديرات التطوير الداخلي تُبنى على ما يراه المستخدم: رفع ملف، وتعبئة حقول، وبحث، وشجرة مجلدات. هذا الجزء فعلًا يُبنى بسرعة. لكن نظام الأرشفة المؤسسي طبقات تحت هذه الواجهة، وكل طبقة مشروع بذاته.
- الواجهة والإدخالرفع الملفات، وبطاقات الفهرسة، والمجلدات، والبحث بالحقول. هذا ما تتضمنه أغلب التقديرات الأولية.
- المحتوى العربي والبحثقراءة النصوص العربية من الوثائق الممسوحة، وتوحيد صيغ الكلمة (الهمزات والتاء المربوطة والألف المقصورة)، والبحث داخل المحتوى، والمعاينة لصيغ كثيرة.
- الضبط والحوكمةالإصدارات والحجز للتحرير، والصلاحيات حتى مستوى الوثيقة وأثرها في نتائج البحث، وسجل تدقيق لا يُعدّل، والاحتفاظ والإتلاف بموافقات، والأرشيف الورقي.
- الإدارة دون برمجةشاشات يضيف منها مسؤول النظام نوع وثيقة أو حقلًا أو مسارًا. بدونها يصبح كل تغيير طلب تطوير.
- التشغيل والأمنالأداء مع ملايين الصفحات، والاستيراد الجماعي، والنسخ الاحتياطي والاستعادة، والتحديثات الأمنية، واختبارات الاختراق، والتوثيق.
هذا لا يعني أن بناء هذه الطبقات مستحيل، بل أن تقديرها يجب أن يكون صريحًا. تقدير لا يذكر قراءة النصوص العربية وسجل التدقيق والاحتفاظ وشاشات الإدارة، هو تقدير لنظام آخر أبسط من الذي تحتاجه. وللمقارنة، تجد مكونات نظام الأرشفة وطبقاته في النظرة الشاملة على النظام.
افرز متطلباتك قبل أن تقرر
أكثر ما يحسم القرار ليس النقاش العام، بل قائمة المتطلبات نفسها. خذ قائمة متطلباتك، وصنّف كل متطلب في واحدة من أربع خانات، مع ممثل من إدارة الوثائق وآخر من تقنية المعلومات، ويُفضل أن تتحقق من التصنيف في عرض توضيحي على وثائقكم:
| الخانة | معناها | مثال |
|---|---|---|
| أ. تهيئة | يتحقق من إعدادات نظام جاهز | حقل «رقم المنافسة» إلزامي في عقود المشتريات، أو مسار يتغير بحسب قيمة العقد |
| ب. تكامل | يتحقق بالربط مع نظام آخر لدى الجهة | إنشاء ملف الموظف تلقائيًا من نظام الموارد البشرية |
| ج. إضافة محددة | غير موجود، لكنه طرفي ويمكن بناؤه حول القلب | تقرير يحسب التزام الإدارات بمعادلة خاصة بالجهة، أو تصدير بصيغة يطلبها نظام خارجي |
| د. فريد وجوهري | يمس طريقة عمل النظام نفسه، ولا يستقيم العمل بدونه، ولا يوجد في الأنظمة الجاهزة | نموذج بيانات لا يشبه «وثيقة وبياناتها» أصلًا، أو منصة تبيعها الجهة لعملائها والأرشفة جزء من منتجها |
ثم اقرأ النتيجة:
- أغلب المتطلبات في (أ) و(ب): الجاهز بالتهيئة يكفي، وأي تطوير كامل هنا إعادة بناء لما هو موجود.
- عدد محدود في (ج): الجاهز مع تطوير إضافي. اطلب أن تُسعّر كل إضافة منفصلة، ورتّبها: ما لا بد منه عند الإطلاق، وما يؤجل.
- متطلبات كثيرة في (د) تمس القلب: هنا يستحق التطوير الكامل دراسة جادة، بشرط الفريق الدائم.
تنبيه: كثير من المتطلبات تبدأ في الخانة (د) ثم تنتقل إلى (أ) أو (ج) بعد أن يُسأل: «ما الذي تحتاجه فعلًا؟». «نريد شاشة مثل شاشتنا الحالية» غالبًا متطلب عادة لا متطلب عمل. اسأل عن النتيجة المطلوبة، لا عن الشكل المألوف.
التكلفة الكلية: ما يُحسب في كل خيار
المقارنة المالية العادلة تكون على أفق عدة سنوات، وبالبنود نفسها لكل خيار، بما فيها التكاليف الداخلية التي لا تظهر في أي فاتورة. وطريقة جمعها وتوحيدها تجدها في مقالة حساب التكلفة الكلية لمشروع الأرشفة خلال عدة سنوات. وعوامل تكلفة الخيار الجاهز موضحة في العوامل العشرة لتكلفة مشروع الأرشفة. ما يخص قرارنا هنا هو البنود التي تُنسى في كل خيار:
- في التطوير الكامل: وقت الفريق طوال البناء لا بعد الإطلاق فقط، وفريق صيانة دائم بعده، والبنية والبيئات، واختبارات الأمن الدورية، ومحركات قراءة النصوص أو البحث إن كانت مرخصة، وتكلفة إحلال من يغادر وتسليم معرفته، وتكلفة التأخير: الأشهر التي تستمر فيها المشكلة الحالية حتى يكتمل البناء.
- في الجاهز مع تطوير إضافي: صيانة الإضافات واختبارها مع التحديثات، وطلبات التغيير اللاحقة، ورسوم الدعم أو الاشتراك طوال الأفق لا السنة الأولى.
- في الجاهز بالتهيئة: كلفة التنازل عن متطلب لم يتحقق: إجراء يدوي يستمر، أو وقت موظف، أو خطر رقابي. هذه تكلفة حقيقية وإن لم تظهر في العرض.
وتذكّر أن الرواتب القائمة ليست «مجانية». المطورون الذين سيبنون نظام الأرشفة لن يعملوا في هذه الأثناء على مشروعات أخرى تنتظرهم.
الملكية والأمن: الحجتان الأقوى للتطوير الكامل
«نريد أن نملك النظام»
اسأل: ماذا تحمي هذه الملكية تحديدًا؟ إن كان الخوف من أن تصبح الوثائق رهينة مورد، فالحماية في ملكية البيانات وحق تصديرها كاملة بصيغة محددة، لا في ملكية الشفرة. وإن كان الخوف من توقف المورد، فالحماية في التصدير، ووثائق الإعدادات، وحقوق التطوير الخاص، وقد تشمل إيداع الشفرة لدى طرف ثالث بشروط محددة. خيارات هذا البند وحدوده تجدها في مقالة تسليم الشفرة المصدرية لنظام الأرشفة. أما إن كانت الجهة تريد أن تطوّر النظام بنفسها باستمرار كجزء من منتجها، فهذه حاجة حقيقية للملكية تدعم خيار التطوير الكامل.
«الأمن يقتضي أن يكون النظام من صنعنا»
الشفرة الداخلية ليست أكثر أمنًا لأنها داخلية. هي آمنة بقدر ممارسات التطوير الآمن، ومراجعة الشفرة، واختبارات الاختراق، وسرعة تصحيح الثغرات. والمتطلبات الأمنية الشائعة، مثل بقاء البيانات داخل شبكة الجهة وعدم اتصال النظام بالإنترنت، يحققها نظام جاهز يعمل على خوادم الجهة، بما في ذلك التشغيل في الشبكات المقيدة. ما يبرر البناء الداخلي أمنيًا هو قيد لا يسمح بأي منتج خارجي أصلًا، وهذا نادر ويُثبت بسياسة مكتوبة لا بانطباع.
مثالان: قرار مختلف لكل حالة
مثال توضيحيجامعة افتراضية تريد أرشفة ملفات الطلاب والموظفين والمجالس، ولديها فريق تطوير يقترح البناء لأن «إجراءات الجامعة خاصة». فرزت المتطلبات فوجدت أغلبها تهيئة: أنواع وثائق، وتصنيف حسب الكليات، ومسارات لمحاضر المجالس. واثنان تكامل: نظام شؤون الطلاب ونظام الموارد البشرية. وثلاثة إضافات: تقرير اكتمال ملفات الخريجين بمعادلة خاصة، وتصدير لجهة خارجية، وشاشة لطلبات معادلة المقررات. لم يبقَ في الخانة (د) شيء. القرار: نظام جاهز مع ثلاث إضافات مسعّرة منفصلة، ووُجّه فريق التطوير إلى التكاملين من جهة أنظمة الجامعة.
شركة افتراضية تبني منصة رقمية تبيعها لعملائها، والوثائق وحفظها وتدقيقها جزء من المنتج نفسه الذي تطوره أسبوعيًا، ولديها فريق هندسي دائم. متطلبات الوثائق مندمجة في نموذج بيانات المنصة، ولا تنفصل عنه. القرار: تطوير مكون الوثائق ضمن المنصة، مع شراء مكونات متخصصة جاهزة حيث يصعب البناء، مثل قراءة النصوص العربية. ولأرشيفها الإداري الداخلي، من عقود وموارد بشرية، اختارت نظامًا جاهزًا.
لاحظ أن الحالة الثانية لم تقرر «نبني كل شيء». حتى حين يكون البناء مبررًا، يبقى الشراء أنسب لما ليس جزءًا من جوهر المنتج.
اعتراضات تتكرر في الاجتماع، وما يُرد به
- «النظام الجاهز لن يناسب إجراءاتنا»: اطلب عرضًا توضيحيًا على ثلاثة من إجراءاتكم الأكثر خصوصية، بوثائقكم. ما لا يتحقق بالتهيئة يظهر هناك، ويُصنف إضافة أو يُعاد النظر فيه.
- «لدينا مبرمجون، فالتطوير أرخص»: قارن على أفق عدة سنوات بكل طبقات النظام، واحسب فريق الصيانة الدائم، وتكلفة التأخير. إن بقي أرخص بعد ذلك، فالحجة قوية.
- «لا نريد الاعتماد على مورد»: التطوير الكامل يستبدل الاعتماد على مورد بالاعتماد على أفراد داخل الجهة أو على مقاول. الاعتماد لا يختفي، بل يتغير شكله. قارن أي الاعتمادين تستطيع ضبطه بالعقد والتوثيق.
- «سنبني نسخة بسيطة ثم نطورها»: النسخة البسيطة غالبًا هي الطبقة الأولى فقط في المخطط أعلاه. اسأل متى ستُبنى الطبقات الأخرى، ومن سيعمل بالنظام الناقص في الأثناء، وكيف ستُرحّل وثائقه لاحقًا.
- «سنتبنى منصة مفتوحة المصدر»: خيار وسط معقول لبعض الجهات، لكنه أقرب إلى التطوير الكامل في عبء التهيئة والصيانة والأمن، ما لم يكن معه عقد دعم يتحمل هذا العبء. قيّمه كذلك.
الخطوة التالية: فرز المتطلبات في جلسة واحدة
قبل أن يتحول النقاش إلى مواقف، اجمع قائمة متطلباتكم وافرزها في الخانات الأربع. إن أردت أن نشارككم هذا الفرز، فنحن نصنّف كل متطلب في مرحلة الدراسة إلى تهيئة أو تكامل أو تطوير خاص، ويظهر التصنيف مسعّرًا في العرض، كما في أمثلة طلبات التخصيص وتصنيفها. والتصنيف نفسه يفيدكم حتى لو قررتم البناء. جهّز القائمة ونماذج من الوثائق والإجراءات، ثم اطلب جلسة تقييم احتياج نخرج منها بفرز مكتوب لمتطلباتكم.
أسئلة شائعة
هل يمكن أن نبدأ بنظام جاهز ثم ننتقل إلى نظام مطوّر داخليًا لاحقًا؟
يمكن، بشرط أن يضمن العقد تصدير الوثائق وبياناتها الوصفية وإصداراتها وسجلاتها بصيغة محددة. وفي الغالب يحدث العكس: الجهة التي تبدأ بنظام جاهز تكتشف بعد التشغيل أن احتياجها الفعلي أوضح مما ظنت، وأن ما يستحق البناء إضافات محددة لا نظام كامل.
من يملك التطوير الإضافي الذي نطلبه على نظام جاهز؟
يُحدد تعاقديًا. قد تُنقل ملكيته للجهة، أو يبقى للمورد مع حق استخدام دائم، أو يُضم إلى المنتج إن كان مفيدًا لغيركم مقابل صيانته ضمن التحديثات. لكل خيار أثر على التكلفة والصيانة، فاطلب أن يُذكر في العرض لكل إضافة.
هل يغيّر التشغيل على خوادم الجهة معادلة القرار؟
يزيل أحد أسباب التطوير الكامل، وهو بقاء البيانات داخل الشبكة، لأن النظام الجاهز يعمل على خوادم الجهة. لكنه يضيف على الجهة مسؤولية البنية والتشغيل في الخيارين، فلا يرجّح أيًا منهما وحده.
ماذا لو كان جزء من متطلباتنا تكاملات كثيرة مع أنظمة داخلية؟
كثرة التكاملات لا تعني تطويرًا كاملًا، بل تعني أن تتحقق من واجهات النظام الجاهز وطرق الربط التي يدعمها. وقد يتولى فريقكم التقني الجزء الذي يخص أنظمتكم، بينما يتولى المورد جهة نظام الأرشفة. هذا تقسيم عمل يستفيد من فريقكم دون أن يحمّله نظامًا كاملًا.