التحليل: حوّل requirement مُعتمَدًا إلى gap، وسجلّ مخاطر، وتوصية قابلة للدفاع عنها

لدى فريقك بالفعل playbooks Gap-analysis وSWOT-risk-register swot-risk-register وOptions-analysis options-analysis — الوصفات المُجرَّبة لمقارنة الحالة الحالية بالمستقبلية، وتصنيف المخاوف المتفرِّقة في SWOT، وتقييم جدول من الحلول المرشَّحة. كلّ منها حركة جيدة، تُنفَّذ مرة واحدة. هذه الوحدة هي الطبقة التي تحوّل تلك الحركات المنفصلة إلى التحليل الذي يستطيع فريق التنفيذ العمل عليه فعلًا: gaps ترتبط بسببها الحقيقي بدلًا من أعلى عرَض صوتًا، وسجلّ مخاطر لا يزال صحيحًا الشهر القادم، وتحليل خيارات ينتهي بتوصية يستطيع أحدهم اعتمادها فعلًا.

إنها الوحدة الثانية من مسار محلّل الأعمال القابل للاعتماد، وترث كل ما بنيته في الوحدة الأولى. ملف requirements-doc.md ليس قراءة خلفية هنا — إنه الهدف الذي يُقاس به كل gap في هذه الوحدة، والمصدر الذي يُحكَم بموجبه على كل خيار. الوحدة الأولى أتقنت ماذا تحتاج الأعمال فعلًا، من مَن، ولماذا؛ الوحدة الثانية تبني التحليل الذي يقرّر ما ينبغي فعله حيال المسافة بين ذلك واليوم — وتُقيِّم التحليل، لا مسودّة أولى تبدو معقولة.

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

تحديد السبب الجذري لـ gap بشكل صحيح

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

• اسأل لماذا مرتين على الأقل بعد الإجابة الأولى. «لا يوجد مسار مرتجعات ذاتي الخدمة» (لماذا #1: لم يبنِ أحد واحدًا) اكتشاف حقيقي، لكن ادفع مرة أخرى: لماذا لم يُبنَ واحد — لأن أحدًا لم يملك القرار، لأنه أُجِّل مرتين، لأن السياسة الكامنة خلفه لم تُنهَ قط؟ الـ«لماذا» الثانية والثالثة هي عادة حيث يقيم السبب القابل للإصلاح، لا الأولى.
• ميِّز بين مشكلة بناء ومشكلة سياسة ومشكلة ملكية. «لا توجد أداة ذاتية الخدمة» يحتاج مشروع هندسة. «لا يوجد معتمِد بديل لاسترداد الأموال بعد ساعات العمل» يحتاج قرار سياسة هذا الأسبوع. الخلط بين الاثنين هو كيف يتحوّل gap analysis من إصلاح في اليوم نفسه إلى طلب مُتضخِّم — وكيف تُرفض حاجة بناء حقيقية باعتبارها «فقط حدِّث السياسة».
• ادعم كل سبب جذري بشيء حقيقي. سبب جذري مدعوم بعدد تذاكر، أو خطوة في خريطة عملية، أو رواية صاحب مصلحة مُسمًّى هو اكتشاف. سبب جذري هو في الحقيقة تخمينك الأفضل مُقنَّعًا كتحليل هو التزام في اللحظة التي يسأل فيها أحدهم «كيف تعرف؟» — قل ذلك صراحة حين تستنتج بدلًا من أن تستشهد.
• اعرف متى تتوقّف. الحفر بأسلوب الأسئلة الخمسة لماذا انضباط، لا تفويض للوصول إلى استنتاجات وجودية. «لماذا لا يوجد مسار مرتجعات ذاتي الخدمة» ← «لأن أحدًا لم يملك بناءه» ← «لأن ملكية أدوات الخدمة الذاتية لم تُسنَد قط بعد إعادة الهيكلة الأخيرة» نقطة توقّف جيدة — سبب حقيقي، قابل للإصلاح، وقابل للاستشهاد به. متابعته أبعد نحو «لماذا حدثت إعادة الهيكلة» مشروع مختلف، لا هذا الـ gap.

إبقاء سجلّ المخاطر حيًّا، لا مكتوبًا فحسب

الـ SWOT وسجلّ المخاطر هما القطعتان الأكثر عرضة لأن تُنتَجا مرة واحدة، وتُعرَضا في اجتماع، ولا تُفتَحا مجددًا أبدًا — ما يجعلهما مفيدتين بالضبط بقدر المخاوف المتفرِّقة اللتين حلّتا محلّهما. الانضباط الذي يجعل سجلّ المخاطر يستحقّ الوقت الذي استغرقه كتابته هو معاملته كشيء له نبض، لا كقطعة تُنجَز وتُشطَب.

• سجلّ المخاطر ليس عصفًا ذهنيًا — لا تُحشِه. الدافع تحت الضغط هو سرد كل شيء يمكن تصوّره أنه قد يسوء، لأن القائمة الطويلة تبدو شاملة. ليست كذلك — إنها ضجيج يدفن الخطرين أو الثلاثة التي تهمّ فعلًا تحت كومة من الخطر النظري. كل إدخال ينبغي أن يرتبط بشيء حقيقي: ملاحظة من صاحب مصلحة فعلي، نمط في بيانات التذاكر، مبادرة مماثلة واجهت هذه المشكلة بعينها. إن لم تستطع تحديد مصدر خطر، فلا مكان له في السجلّ بعد.
• كل خطر يحتاج الحقول الأربعة كلّها، وإلا فهو غير مُتابَع. likelihood وimpact دون مالك ملاحظة. مالك دون معالجة اسم مُلصَق بشيء من الكتفين. الحقول الأربعة — likelihood وimpact ومالك ومعالجة — هي ما يحوّل «نحن قلقون قليلًا حيال هذا» إلى شيء يُحاسَب عليه شخص فعلًا لمراقبته.
• الخطر بلا مالك هو أكثر سطر إلحاحًا في الصفحة، لا الأقل. الدافع هو ملء كل فراغ باسم فريق معقول ليبدو المستند كاملًا. قاوم ذلك — مالك مُخمَّن أسوأ من فراغ مرئي، لأن الفراغ يُلاحَق بينما التخمين يُتجاهَل بهدوء من أُسنِد إليه.
• ابنِ المراجعة داخل المستند، لا كإضافة لاحقة. تاريخ «موعد المراجعة القادم» في أعلى المستند هو ما يفصل سجلّ مخاطر عن شريحة عُرضت مرة واحدة. حين تعود إليه، المهمّة هي diff مقابل آخر نسخة محفوظة — ما انتهى، ما تغيَّر، ما استجدّ — لا SWOT جديد من صفحة فارغة. سجلّ لا يعيد أحد فتحه ميت بالضبط كالملاحظات المتفرِّقة التي حلّ محلّها.
• الـ likelihood والـ impact فرضيات، لا قياسات. سيقترح Claude درجات تبدو واثقة ودقيقة. عاملها كمسودّة أولى تُختبَر منطقيًا مقابل مَن عاش العملية فعلًا — درجة خاطئة تمرّ دون تحدٍّ هي كيف يُصنَّف خطر حقيقي بهدوء إلى «مراقبة فقط».

تحليل الخيارات كأداة حسم، لا قائمة إيجابيات وسلبيات

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

• المعايير نفسها، الأعمدة نفسها، كل خيار — بلا استثناءات. التكلفة، الجهد، الخطر، الوقت-حتى-القيمة (إضافة إلى أي شيء يُلمِّح ملف الـ requirements أنه مهم هنا) تنطبق على كل صفّ بالطريقة نفسها. في اللحظة التي يُوصَف فيها خيار بالنثر بينما يحصل آخر على أرقام صلبة، تكون المقارنة منحازة بالفعل لصالح أيّهما يبدو أكثر اكتمالًا.
• ضع علامة على كل تقدير كتقدير. رقم تكلفة أو جهد مُستنتَج من السياق تخمين حتى يتحقّق منه أحد. تقديم تقدير بالثقة نفسها التي يُقدَّم بها رقم موثَّق هو كيف يبدو الجدول دقيقًا ويتبيّن أنه مبنيّ على رمل — الإصلاح رخيص: فقط ضع علامة على أيّ الخلايا حقيقية وأيّها مُستنتَجة.
• سمِّ ما لا يحلّه كل خيار — في كل مرة. التكلفة والجهد يخبرانك بما يأخذه خيار؛ هذا يخبرك بما يتركه معطَّلًا. خيار بناء كامل يحلّ كل شيء وترقيع سريع يحلّ أعلى 20% صوتًا من المشكلة يبدوان مختلفَين جدًا بمجرّد أن يجلس «لا يحلّ» بجانب كل درجة — وهو عادة السطر الذي يقود القرار فعلًا.
• سمِّ مَن يوقِّع، بالدور أو بالاسم — لا «القيادة» فحسب أبدًا. خيار بلا معتمِد فعلي مُرفَق هو الذي يتوقَّف بهدوء في لجنة لشهر قبل أن يلاحظ أحد أنه لا أحد يملك القرار. إن لم تعرف فعلًا، اترك الحقل فارغًا وطارد الاسم — القاعدة نفسها لـ gap أو خطر بلا مالك.
• التوصية تستحق مكانتها بتسمية ما الذي يُغيّرها. «نوصي بالخيار ب» رأي. «نوصي بالخيار ب لأنه يُشحَن هذا الربع بخطر متوسط؛ يتحوّل هذا إلى الخيار ج إذا تحوّلت الأولوية من ‹اشحن هذا الربع› إلى ‹حلّ الـ gap كاملًا›، أو إذا فُتحت الميزانية» أداة حسم — تخبر صاحب مصلحة متشكِّك بالضبط أيّ افتراض يجادل فيه بدلًا من إعادة النقاش حول الجدول كلّه.
• تحقّق مما إذا كانت المعايير حُدِّدت قبل رؤية الدرجات أم بعدها. إذا صادف أن التكلفة والجهد والخطر والوقت-حتى-القيمة تُرتَّب بالضبط بالترتيب الذي يُفضِّل الخيار الذي دخلت وأنت تريده، يستحقّ ذلك نظرة ثانية قبل تعميمه — معايير اختيرت لتناسب مُفضَّلًا ليست مقارنة، إنها تبرير.

مهمّتك

نفِّذ التحليل الكامل لمبادرتك الخاصة (مُوصى به — الناتج يصبح gap analysis وسجلّ مخاطر وتوصية خيارات حقيقية يستخدمها فريقك فعلًا) أو للعلامة التجريبية Mizan، منصّة المحاسبة الخليجية التي تُدير محلّلة أعمالها، نور السويدي، هذا المسار بأكمله. كل ما هنا يرث requirements-doc.md من الوحدة الأولى؛ إن لم يكن لديك بعد، أنجز الوحدة الأولى أوّلًا. افتح مجلّد BA الخاص بك في Claude Desktop، ووافق على كل قراءة في نافذة Ask permissions، واعمل في المحادثة — لا حاجة إلى Terminal.

تسليم الوحدة الثانية — التحليل

يرث من الوحدة الأولى: requirements-doc.md (+ stakeholder-map.md للمالكين)

١. gap-analysis.md
   - الحالة المستقبلية مُعادة صياغتها كقائمة مرقّمة قصيرة من requirements-doc.md
   - الحالة الحالية مُقارنة بندًا ببند: مُستوفاة كاملًا / جزئيًا / غير مُستوفاة
   - كل gap مُسمًّى، بسبب جذري حُفِر مستويين على الأقل من "لماذا" بعد
     أول إجابة معقولة — مصدره ملاحظات/تذاكر حقيقية، لا تخمين
   - جدول impact/effort، مُرتَّب، التبعيات مُعلَّمة
   - مالك لكل gap — مُسمًّى أو مُعلَّم صراحة كمفقود، لا مُخمَّن أبدًا

٢. risk-register.md   (مع الـ SWOT الذي أنتجه، للسياق)
   - SWOT مصدره requirements-doc.md وملاحظات حقيقية — لا إدخالات
     عامة غير قابلة للتتبّع
   - كل ضعف/تهديد قد يُعطِّل المبادرة مُحوَّل إلى خطر: likelihood وimpact
     ومالك ومعالجة — الأربعة كلّها، كل صفّ
   - مُرتَّب بـ likelihood × impact، أعلى المخاطر مُعلَّمة كقرار-الآن مقابل
     مراقبة-فقط
   - تاريخ مراجعة في الأعلى، وتعليمات ثابتة لكيفية عمل المراجعة القادمة
     (diff مقابل هذه النسخة، لا إعادة كتابة)

٣. options-analysis.md
   - ٢-٤ خيارات مُعادة صياغتها في جملة واحدة لكل منها، المعايير مُؤكَّدة
   - كل خيار مُقيَّم بمعايير مطابقة (التكلفة، الجهد، الخطر، الوقت-حتى-القيمة)؛
     كل تقدير مُعلَّم بوضوح كتقدير
   - ما لا يحلّه كل خيار، مُسمًّى صراحة
   - مَن يوقِّع على كل خيار — دور أو اسم حقيقي، فارغ إن كان مجهولًا
   - توصية: لماذا تفوز بناءً على الأولويات المُصرَّح بها، ما الذي يُتخلَّى عنه،
     وما الذي يجب أن يتغيَّر لتنقلب التوصية

كل عمود مالك وتوقيع اسم/دور حقيقي أو فراغ صريح —
لا اسم فريق مُخمَّن يقف مكان المحاسبة أبدًا.

يحمل الـ Foundation toolkit الذي ثبّته في الوحدة الأولى بالفعل CLAUDE.md وrequirements-doc.md. إضافات الـ toolkit في نهاية هذه الوحدة تمنحك قوالب الـ gap وسجلّ المخاطر والخيارات، فأنت تملأ بنية، لا تبدأ من صفحة فارغة.

كيف يُقيَّم — المعيار

هذا هو الجزء الذي لا تملكه الـ playbooks المجانية، والجزء الذي يجعل الاعتماد ذا معنى. تُقيَّم قطعك الثلاث بموجب خمسة معايير. كل واحد يستوفي / يقترب / لم يستوفِ بعد، و«يقترب» في أيّ واحد هو مراجعة، لا نجاح.

معيار التحليل

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

٢. كل خطر مُحدَّد بالكامل       الـ likelihood والـ impact والمالك والمعالجة
                                حاضرة لكل إدخال في سجلّ المخاطر. لا حقل
                                فارغ يقف مكان "لم نقرّر بعد" — المخاطر
                                بلا مالك مُعلَّمة، لا مُسقَطة بهدوء.

٣. الخيارات مُقيَّمة بشكل مطابق   كل خيار مُحكوم عليه بالمعايير نفسها
                                المُسمّاة في الجدول نفسه. التقديرات مُعلَّمة
                                بوضوح كتقديرات. لا خيار يُوصَف بنثر
                                مُتملِّق بينما يحصل آخر على أرقام صلبة.

٤. التوصية قابلة للدفاع
   عنها وقابلة للانقلاب          التوصية تُصرِّح لماذا تفوز بناءً على الأولويات
                                المُصرَّح بها، وما تتخلّى عنه، وبالضبط ما
                                الذي يجب أن يتغيَّر لتنقلب إلى خيار مختلف.

٥. لا شيء مُخمَّن في عمود
   مالك أو توقيع                كل gap وخطر وخيار يحمل اسمًا/دورًا حقيقيًا
                                أو فراغًا صريحًا ومرئيًا — لا نائبًا يبدو
                                معقولًا أبدًا.

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

المعيار، مُجسَّدًا — نموذج إجابة مُنجَز (Mizan)

لست بحاجة إلى تخمين ما يبدو عليه «يستوفي». إليك مقتطفات ناجحة من ملفّات محلّلة الأعمال نور السويدي الفعلية، مبنيّة بعد حادثة الفوترة المزدوجة في ١ مارس ٢٠٢٦، حين طلبت الشريكة المؤسِّسة دانة القاسمي منها تشغيل عملية الـ requirements الرسمية لميزة «وضع علامة نزاع على رسوم» تواجه العملاء. ملف requirements-doc.md (الوحدة الأولى) الخاص بنور سمّى بالفعل الحالة المستقبلية وأصحاب المصلحة المتأثِّرين — الدعم والمالية والبيانات والهندسة. هذه الوحدة هي حيث تقرّر ماذا تبني فعلًا.

gap-analysis.md — Mizan: علامة نزاع ذاتية الخدمة (مقتطف)

الحالة المستقبلية (من requirements-doc.md، مُعادة الصياغة):
  ١. العميل يستطيع وضع علامة نزاع على رسوم دون مراسلة الدعم
  ٢. النزاع يُصنَّف ويُحلّ أو يُصعَّد خلال ٤٨ ساعة
  ٣. العميل يرى حالة النزاع دون أن يسأل مجددًا
  ٤. النزاعات الاحتيالية/المُسيئة قابلة للتمييز عن أخطاء الفوترة الحقيقية
     قبل إصدار استرداد

الحالة الحالية، بندًا ببند:
  ١. غير مُستوفاة — كل نزاع اليوم يبدأ ببريد إلكتروني للدعم؛ لا مسار
     داخل التطبيق موجود (support-tickets.csv، فبراير-مارس ٢٠٢٦)
  ٢. مُستوفاة جزئيًا — فريق ليلى (الدعم) يُصنِّف خلال يوم في المتوسّط،
     لكن «الحلّ» يعني أن إنسانًا يتحقّق يدويًا من سجلّ المالية؛ لا SLA
     مكتوب في أيّ مكان
  ٣. غير مُستوفاة — العميل يجب أن يُراسل مجددًا للتحقّق من الحالة؛ ٤٠٪
     من تذاكر الفوترة المزدوجة الإحدى عشرة تضمّنت متابعة «أيّ تحديث؟»
  ٤. غير مُستوفاة — لا تمييز موجود اليوم؛ كل نزاع يحصل على المراجعة
     اليدوية نفسها بغضّ النظر عن النمط

الـ Gaps، السبب الجذري (مستويان "لماذا" بعد أول إجابة معقولة):
  Gap ١ — لا مسار علامة ذاتية الخدمة.
    لماذا: لا أداة موجودة للعميل ليضع علامة على رسوم بنفسه.
    لماذا (أعمق): أدوات الفوترة ذاتية الخدمة لم تُحدَّد أولوية لها قط
    لأن النزاعات افتُرِض أنها نادرة — صحيح حتى أنتج bug الفوترة
    المزدوجة في ١ مارس أحد عشر نزاعًا في أسبوع واحد. السبب الجذري:
    الافتراض «النزاعات نادرة» لم يُعاد النظر فيه قط بعد الحادثة التي
    فنّدته.
  Gap ٢ — لا SLA مكتوب للتصنيف.
    لماذا: التصنيف يحدث بشكل غير رسمي عبر حُكم فريق ليلى.
    لماذا (أعمق): لا أحد يملك كتابة SLA دعم لنزاعات الفوترة تحديدًا
    (يوجد SLA عام للتذاكر، لا لهذا). السبب الجذري: نزاعات الفوترة
    لم تُفصَل قط كنوع تذكرة خاصّ بها، فترث SLA عامًا لا يناسب حالة
    تلمس سجلّ المالية، لا مجرّد ردّ.
  Gap ٣ — لا رؤية للحالة.
    السبب الجذري: نفسه كـ Gap ١ — لا سطح خدمة ذاتية موجود إطلاقًا،
    فلا مكان لعرض حالة حتى لو كان التصنيف فوريًا.
  Gap ٤ — لا تمييز احتيال/خطأ حقيقي.
    لماذا: كل نزاع يُراجَع يدويًا بالطريقة نفسها بغضّ النظر عن النمط.
    لماذا (أعمق): لم ينظر أحد بعد فيما إذا كانت النزاعات تتجمّع
    بنمط يسمح لقاعدة بوضع علامة احتيال محتمل تلقائيًا — البيانات
    (مايا حداد) لم تُسأل هذا السؤال بعد. السبب الجذري: منطق تصنيف
    الاحتيال غير موجود لأن أحدًا لم يُحدِّد نطاقه كمتطلَّب حتى الآن.

الأثر / الجهد / الأولوية:
  Gap  الأثر    الجهد            الأولوية  التبعية
  ١    مرتفع   كبير (بناء)        ١        Gap ٣ يعتمد على شحن Gap ١
  ٢    متوسط   سريع (سياسة)       ٢        مستقلّ — يُغلَق هذا الأسبوع
  ٤    مرتفع   متوسط              ٣        يحتاج بيانات Gap ١ قبل التحديد
  ٣    مرتفع   (انظر Gap ١)       —        غير قابل للبناء بشكل منفصل

المالكون:
  Gap ١ — قائد الهندسة (بلال المنصوري)، للتأكيد على النطاق — مُعلَّق
  Gap ٢ — قائدة الدعم (ليلى الناصر) — مُؤكَّد، تستطيع الكتابة هذا الأسبوع
  Gap ٤ — [فارغ — يحتاج البيانات والمالية لتحديد النطاق معًا؛ لم يُسمَّ بعد]

risk-register.md — Mizan: علامة نزاع ذاتية الخدمة
(رُوجِع في ٢٠٢٦-٠٧-٠١، المراجعة القادمة ٢٠٢٦-٠٨-٠١)

الـ SWOT الذي أنتج هذا السجلّ (مصدره حقيقي، لا عام):
  ضعف: لا SLA لنزاعات الفوترة (gap-analysis.md، Gap ٢)
  ضعف: لا تمييز احتيال/خطأ حقيقي (Gap ٤)
  تهديد: زرّ «نزاع» ذاتي الخدمة عام قد يُستَغَلّ لنزاعات احتيالية
    أو نزاعات ندم-المشتري، لا أخطاء فوترة حقيقية — طرحته دانة في
    اجتماع تحديد النطاق في ٢٨ يونيو، لم يُحدَّد كمًّا بعد
  فرصة: بيانات العلامة نفسها يمكن أن تُغذّي نموذج مخاطر التسرّب لدى
    البيانات (لوحة مايا) إن بُنيت بشكل موحَّد منذ اليوم الأول

سجلّ المخاطر:
  خطر: زرّ «نزاع» ذاتي الخدمة عام يُستخدَم لاسترداد احتيالي أو نزاعات
    ندم-المشتري، لا أخطاء فوترة حقيقية.
    الاحتمال: متوسط (لا نمط احتيال موجود بعد للمقارنة به).
    الأثر: مرتفع (كل نزاع خاطئ يُكلِّف مراجعة يدوية + استردادًا محتملًا
    خاطئًا).
    المالك: قائد المالية — [تأكيد مع يوسف حمدان].
    المعالجة: أطلق العلامة ببوابة مراجعة يدوية قبل أن يُصدِر أيّ استرداد
    تلقائيًا؛ أعد النظر في الموافقة التلقائية فقط بعد ربع سنة من بيانات
    النمط.

  خطر: حجم تذاكر الدعم يرتفع إن جعلت العلامة النزاع أسهل دون أن تجعل
    التصنيف أسرع أيضًا.
    الاحتمال: مرتفع (جعل نقطة احتكاك أسهل الوصول إليها يزيد الحجم عادة
    قبل أن تلحق العملية).
    الأثر: متوسط (تأخير، لا إيراد ضائع، إن واكب التصنيف).
    المالك: ليلى الناصر (قائدة الدعم).
    المعالجة: اشحن SLA المكتوب من Gap ٢ قبل أو مع العلامة، لا بعدها —
    الـ gap-ان مرتبطان أكثر مما يُرتِّبهما جدول الأولوية.

  خطر: غياب تمييز الاحتيال/الخطأ الحقيقي يعني أن الإطلاق يجب أن يعمل
    يدويًا بالكامل، ما يُقوِّض هدف «تقليل حِمل الدعم» الذي بُنيت المبادرة
    عليه.
    الاحتمال: مرتفع (السبب الجذري لـ Gap ٤ يؤكِّد عدم وجود قاعدة اليوم).
    الأثر: متوسط (الميزة لا تزال تُشحَن، لكن لا تحقّق حالة العائد الكاملة
    في الإصدار الأول).
    المالك: [فارغ — يحتاج البيانات والمالية معًا؛ طارِد قبل المراجعة القادمة].
    المعالجة: حدِّد نطاق إصدار أول بمراجعة يدوية؛ كلِّف مايا (البيانات)
    بتحليل نمط احتيال بالتوازي حتى يستطيع الإصدار الثاني الأتمتة.

أهمّ خطر يحتاج قرارًا الآن: خطر إساءة استخدام الاحتيال — المالية تحتاج
تأكيد بوابة المراجعة اليدوية قبل أن يُحدَّد نطاق هذا في الهندسة، لا بعده.
خطر ارتفاع الحجم بند مراقبة بمجرّد شحن SLA من Gap ٢. Gap ٤ غير المملوك
هو أكثر فراغ إلحاحًا لإغلاقه قبل اعتبار هذا السجلّ مكتملًا.

options-analysis.md — Mizan: إغلاق فجوة علامة النزاع (مقتطف)

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

المعايير المُؤكَّدة: التكلفة، الجهد، الخطر، الوقت-حتى-القيمة، التعرّض
للاحتيال (مُضاف — قلق دانة في ٢٨ يونيو يجعله حاسمًا هنا).

التقييم:
  الخيار  التكلفة       الجهد               الخطر      الوقت-حتى-القيمة   التعرّض للاحتيال
  أ       ~٩٥ ألف $      كبير (ربع سنة)      متوسط-      بطيء (يُشحَن     يحتاج المعالجة
          (تقدير)                            مرتفع       نهاية الربع ٣)   أعلاه قبل أيّ
                                              (منطق                        تعليق تلقائي
                                              التعليق
                                              التلقائي)
  ب       ~٣٠ ألف $      متوسط               متوسط      أسرع (يُشحَن     أقلّ — لا تعليق
          (تقدير)        (٦ أسابيع)                      منتصف الربع ٣)   تلقائي، مراجعة
                                                                           يدوية لا تزال
  ج       ~٤ آلاف $      سريع (أسبوعان)      منخفض      فوري             بلا تغيير — لا
          (تقدير،                                                          سطح عملاء
          معظمه وقت                                                        جديد لإساءة
          ليلى)                                                            الاستخدام

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

التوقيع المطلوب:
  أ — قائد الهندسة (بلال المنصوري) + المالية (يوسف حمدان، الميزانية +
      معالجة التعرّض للاحتيال) + دانة (قرار التعرّض للاحتيال).
  ب — قائد الهندسة + قائدة الدعم (ليلى الناصر).
  ج — قائدة الدعم فقط — [تأكيد أن دانة لا تريد توقيعًا لأنه أصغر تغيير].

التوصية: الخيار ب — زرّ العلامة-للمراجعة الخفيف.
يُغلق أعلى فجوتين أولوية وأكثرهما ظهورًا (العلامة الذاتية الخدمة ورؤية
الحالة) خلال الربع، بخطر متوسط، دون تحمُّل تعرّض الاحتيال في الخيار أ
قبل أن تثبت معالجة جدواها. يتخلّى عن التعليق التلقائي — رسوم مُتنازَع
عليها قد لا تزال تُقاصّ قبل مراجعة المالية، وهو ما ينبغي أن تزنه المالية
مقابل بيانات الاحتيال التي تُنتِجها مايا بالتوازي. ينقلب هذا إلى الخيار
أ إن أظهر تحليل نمط الاحتيال لدى مايا (يعمل بالتوازي مع هذا الإطلاق) أن
النزاعات تتجمّع بشكل قابل للتنبّؤ بما يكفي لتبرير منطق التعليق التلقائي
في إصدار ثانٍ، أو إن أثبت خطر الحجم في risk-register.md أنه أسوأ من
النموذج المُتوقَّع ولم يستطع التصنيف اليدوي مواكبته حتى مع SLA من
Gap ٢. ينقلب إلى الخيار ج فقط إن اختفت طاقة الهندسة كليًا هذا الربع —
عندها SLA وحده هو الخيار الاحتياطي، لا الهدف.

ما أثبتّه — وما التالي

اجتز المعيار وتكون قد أثبتّ شيئًا لا تستطيع مسودّة أولى تبدو معقولة إثباته أبدًا: أن fجواتك ترتبط بأسباب حقيقية، أن مخاطرك مُتابَعة فعلًا لا مكتوبة فحسب، وأن توصيتك شيء يستطيع صاحب مصلحة متشكِّك تحدّيه بشروطها الخاصّة بدلًا من تفكيكها لغياب الدقة. تلك هي مرحلة التحليل من “محلّل أعمال معتمد مع Claude”.

من هنا يحوّل المسار تحليلًا قابلًا للدفاع عنه إلى مبادرة مُموَّلة ومُرتَّبة، كل وحدة مُقيَّمة بالطريقة نفسها:

• الوحدة الثالثة — القرار: تحويل الخيار المُوصى به إلى business case مُكلَّفة بحسابات العائد، وتوليف (SWOT إضافة إلى التوقيعات التي سمّيتها بالفعل) يضعها أمام صانع القرار الصحيح.
• الوحدة الرابعة — من القرار إلى التسليم، الوحدة الخامسة — الحوكمة والإحاطة التنفيذية، ثم المشروع الختامي — حزمة كاملة من requirements إلى توصية لمبادرة واحدة، من البداية للنهاية، مُقيَّمة في الشهادة.

أولًا، اجعل التحليل قابلًا لإعادة الاستخدام: قوالب الـ gap وسجلّ المخاطر والخيارات أدناه تُوسِّع الـ Foundation toolkit الذي ثبَّته بالفعل. وحين ينتقل الخيار ب (أو أيًّا كان الخيار الذي تصل إليه مبادرتك) إلى business case، أسماء التوقيع وسطر «ما الذي يُغيّرها» في options-analysis.md هما بالضبط ما تبدأ منه تكلفة الوحدة التالية — لا تدع ذلك المنطق يضيع بين المستندات.

# gap-analysis.md — [المبادرة]

## الحالة المستقبلية   (مُعادة الصياغة من requirements-doc.md، مرقّمة)
١. [قدرة/نتيجة]   ٢. [قدرة/نتيجة]   ...

## الحالة الحالية، بندًا ببند
[#] — مُستوفاة كاملًا / جزئيًا / غير مُستوفاة — [ماذا يوجد فعلًا اليوم]

## الـ Gaps والأسباب الجذرية   (مستويان+ "لماذا" بعد أول إجابة معقولة)
Gap [#] — [سمّه]
  لماذا: [الإجابة الأولى]     لماذا (أعمق): [السبب الجذري، مُوثَّق]

## الأثر / الجهد / الأولوية
Gap | الأثر | الجهد | الأولوية | التبعية

## المالكون
Gap [#] — [اسم/دور، أو "فارغ — أُطارِد [مَن]"]

# risk-register.md — [المبادرة]
رُوجِع: [التاريخ]   المراجعة القادمة: [التاريخ]

## SWOT   (مصدره requirements-doc.md + ملاحظات حقيقية فقط)
نقاط القوة / الضعف / الفرص / التهديدات

## السجلّ
خطر: [البيان]
  الاحتمال: منخفض/متوسط/مرتفع    الأثر: منخفض/متوسط/مرتفع
  المالك: [اسم/دور، أو فارغ]    المعالجة: [إجراء ملموس]

## قرار هذه المراجعة
أهمّ خطر يحتاج قرارًا الآن: [...]
مراقبة فقط: [...]
غير مملوك — الأكثر إلحاحًا لإغلاقه: [...]

# options-analysis.md — [المبادرة]

## الخيارات   (٢-٤، جملة واحدة لكل منها)
أ — [...]    ب — [...]    ج — [...]

## المعايير
[التكلفة، الجهد، الخطر، الوقت-حتى-القيمة، + أي شيء يُلمِّح requirements.md أنه مهم]

## التقييم   (الجدول نفسه، الأعمدة نفسها، كل خيار)
الخيار | التكلفة | الجهد | الخطر | الوقت-حتى-القيمة | [معيار إضافي]

## ما لا يحلّه كل خيار
أ — [...]    ب — [...]    ج — [...]

## التوقيع المطلوب
أ — [اسم/دور]    ب — [اسم/دور]    ج — [اسم/دور، أو فارغ]

## التوصية
الاختيار: [الخيار]. يفوز لأن: [...]. يتخلّى عن: [...].
ينقلب إلى [الخيار] إن: [...].

مكتبة الـ prompts المحفوظة (التحليل) — أضِفها لمجموعة الـ Foundation

تحديد السبب الجذري لـ gap
  "اقرأ requirements-doc.md و[ملاحظات العملية/التذاكر]. لكل بند من
   الحالة المستقبلية، أخبرني إن كان مُستوفًى كاملًا أو جزئيًا أو غير
   مُستوفًى اليوم. لكل gap، احفر في السبب الجذري — اسأل لماذا مرتين على
   الأقل بعد أول إجابة معقولة، وتوقّف عند شيء محدَّد وموثَّق، لا تخمين.
   ضع علامة أينما كنت تخمِّن بدلًا من الاستشهاد بشيء حقيقي."

اختبار SWOT قبل أن يصبح سجلّ مخاطر
  "راجع هذا الـ SWOT بشكل نقدي. أيّ نقاط القوة هي في الحقيقة افتراضات
   غير مُتحقَّق منها؟ هل توجد تهديدات يُلمِّح إليها requirements-doc.md
   أو gap-analysis.md لم يرفعها أحد بعد؟ ضع علامة على أي شيء يتناقض مع
   شيء آخر في الملاحظات. ثم حوِّل كل ضعف وتهديد قد يُعطِّل هذا إلى إدخال
   سجلّ مخاطر بـ likelihood وimpact ومالك ومعالجة — اترك المالك فارغًا
   بدلًا من تخمين اسم."

تقييم الخيارات بأمانة
  "قيِّم هذه الخيارات على [المعايير] في جدول واحد، صفّ واحد لكل خيار.
   ضع علامة على كل رقم مُقدَّر بوضوح كتقدير. لكل خيار، سمِّ ما لا يحلّه
   صراحة من gap-analysis.md، ومَن يحتاج التوقيع قبل أن ينتقل للبناء —
   اسم أو دور حقيقي، فارغ إن كنت لا تعرف. لا تُسوِّ الفروقات لتجعل
   الخيارات تبدو أكثر تشابهًا مما هي عليه."

الحصول على توصية تُسمّي ما الذي يُغيّرها
  "بناءً على هذه الدرجات وأولوياتنا المُصرَّح بها [اذكرها]، أوصِ بخيار
   واحد. اشرح لماذا يفوز، وما نتخلّى عنه، وبالضبط ما الذي يجب أن يتغيَّر
   لتنقلب التوصية إلى خيار مختلف."