التوثيق ونقل المعرفة: أن تمتلك النظام لا أن تعتمد على مورّده

السؤال الذي يحدّد نجاح أي تطبيق ليس هل يعمل النظام يوم الإطلاق، بل هل تستطيع المؤسسة تشغيله بعد سنة — بعد أن يكون من حضروا التدريب قد غيّروا مواقعهم أو تركوا العمل. والجواب يعتمد على ما وُثّق وسُلّم فعلاً أكثر بكثير من اعتماده على البرمجيات نفسها.

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

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

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