ورش المتطلبات: العمليات والمالية وتقنية المعلومات في غرفة واحدة

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

لماذا تتعارض المتطلبات حين تُجمع في مقابلات منفصلة

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

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

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

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

من يجب أن يحضر الورشة

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

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

جدول أعمال يخرج بنتائج قابلة للاستخدام

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

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

كيف تدير الخلاف دون أن تخسر الحاضرين

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

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

من مخرجات الجلسة إلى متطلبات يستطيع المزوّد العمل بها

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

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

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

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

الأنظمة الأفضل تبدأ بصورة مشتركة

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

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