توثيق عمليات الأعمال: الخرائط والإجراءات وتعليمات العمل

ابدأ بالعمل الذي يحتاج إلى توضيح

العملية (Process) مجموعة أنشطة مترابطة تحول مدخلات إلى نتائج. قد تبدأ عملية الشراء بطلب معتمد وتنتهي باستلام مواد مقبولة وتسوية المعاملة. وهي قد تمر بعدة إدارات؛ لذلك لا يكفي وصف ما تفعله إدارة المشتريات وحدها، مع تجاهل ما تستلمه من طالب الشراء وما تسلمه للمستودع والمالية.

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

النموذج يجمع المعلومات، والسجل يحتفظ بالدليل

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

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

مثال افتراضي: توثيق طلب شراء دون تكرار

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

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

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

اختبر الفائدة ثم اضبط التحديث

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

في مثال حسابي افتراضي، إعادة 12 طلبًا من أصل 100 طلب تعني نسبة 12%. وإذا أصبحت 5 من أصل 100 خلال فترة مقارنة مماثلة، فالانخفاض 7 نقاط مئوية، وليس 7%. لكن هذا الفرق وحده لا يثبت أن التوثيق سببه؛ فقد تغير حجم التعقيد أو التدريب أو طريقة الفرز. استخدم النتائج مع الملاحظات التشغيلية لتحديد ما يحتاج إلى تحسين.

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