بعد الاستقرار: كيف تدير طلبات التعديل وتحديثات النظام

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

لماذا يحتاج التغيير الى ادارة؟

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

ثلاثة انواع من الطلبات

قبل ان تقرر، صنف الطلب. اغلب ما يصل اليك يقع في واحد من ثلاثة:

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

مثال ملموس

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

مسار بسيط لادارة الطلبات

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

تحديثات المزود شيء اخر

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

قائمة تحقق قبل اعتماد اي تعديل

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