PMO-00.03 المرحلة 00: إدارة البرامج والمحافظ
المستوى 1 general

سجل الاعتماديات المتبادلة

Interdependency Register
tasleemat asset PMO-00.03 template --lang ar

ملخص التسليمة وحدود الحوكمة

المرحلة في دورة حياة المشروع

المرحلة 00: إدارة البرامج والمحافظ

متطلبات مستوى الحجم

المستوى 1

عقد التحقق الآلي

ترتبط هذه التسليمة بمخطط JSON Schema متوافق مع معيار Draft 2020-12 لتمكين التحقق البنيوي والدلالي الآلي. 

tasleemat validate PMO-00.03 ./completed_data.json

قالب التسليمة بتنسيق Markdown

<!-- 
تعليمات النموذج الذكي: املأ الحقول التي تحمل [ أضف التفاصيل... ] بناءً على سياق المشروع.

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

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

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

إرشادات الكتابة:

*  سمِّ المخرج أو الشرط المحدد المنتظر، لا المشروع الآخر. فعبارة «بانتظار المشروع ب» لا يمكن تتبع مسارها والسيطرة على تداعياتها عند تأخر المشروع ب، لأن يصعب تحديد طبيعة المخرجات والمتطلبات المستهدفة بدقة، بينما عبارة «بانتظار مواصفة ترحيل البيانات المعتمدة من المشروع ب» يمكن مطاردتها ويمكن إغلاقها.

*  سجل التاريخ الذي يجب أن تتحقق الاعتمادية بحلوله، وهو طلب التابع، لا التاريخ الذي يتوقع السابقة تسليمه. وحين يختلف التاريخان، فالفجوة بينهما هي الخطر، ويجب أن تكون في السجل لا في ذاكرة أحد.

*  سجل نوع الاعتمادية. فـ«انتهاء إلى بدء» هي الحالة الشائعة، وهي وهي العلاقة القياسية الأكثر شيوعاً؛ والأنواع الأخرى تنشأ حيث يجب أن يتحرك مشروعان معًا، ودون النوع يتعذر التمييز بين قيد ترتيب حقيقي عن مجرد تفضيل.

*  سجل من اتُّفق على الاعتمادية ومتى. فالاعتمادية المفترضة لا المتفق عليها هي التي ستُتنازع في اللحظة التي تصبح فيها غير مريحة.

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

ملاحظات التخصيص:

*  قد يُدار السجل على مستوى المحفظة فيغطي جميع الاعتماديات بين المبادرات، أو على مستوى البرنامج فيغطي ما بين المكونات فقط. وينبغي أن يحدد النموذج أيّهما، فالمستويان يجيبان عن أسئلة مختلفة.

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

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

*  قد يُدار قسم الاعتماديات الخارجية على حدة من قبل وظيفة المشتريات أو حوكمة الموردين، وعندئذٍ يُشار إليه بدل تكراره.

إرشادات الأعمدة، حسب العمود:

صفوف الاعتماديات الداخلية:

*  **المعرف:** معرف الاعتمادية، يُستخدم في قسم التصعيد وفي التقارير ليُشار إليه دون التباس حين يصبح مهددًا.

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

*  **التابعة:** المشروع أو المكون المنتظر. وحين يحتاج المكون نفسه عدة توابع، سجل صفًا لكل واحد منهم لا أن تذكرهم جميعًا، لأن التواريخ المطلوبة والآثار تختلف ولا يصلح تاريخ واحد للجميع.

*  **المخرج أو الشرط:** ما المنتظر تحديدًا، بصيغة يمكن التأكد من تسليمه أو عدمه.

*  **نوع الاعتمادية:** هل العلاقة انتهاء إلى بدء، أم بدء إلى بدء، أم انتهاء إلى انتهاء، أم بدء إلى انتهاء.

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

*  **التاريخ المتفق عليه:** التاريخ الذي التزمت السابقة به، ليظهر بجانب التاريخ المطلوب فتكون الفجوة بينهما ظاهرة في السجل نفسه؛ وحين يكون التاريخ المتفق عليه متأخرًا عن المطلوب، فتلك الفجوة هي خطر الاعتمادية، وهي تُكتشف عادةً بتجاوز الموعد لا بقراءته.

*  **الحالة:** أين تقف الاعتمادية حاليًا مقابل المجموعة الثابتة.

*  **الأثر عند التأخر:** يحدث لأحدماذا للتابع إذا أخلت السابقة بالتاريخ المطلوب.

صفوف الاعتماديات الخارجية:

*  **المعرف:** معرف الاعتمادية الخارجية.

*  **الطرف الخارجي:** المؤسسة خارج البرنامج التي تمر عبرها الاعتمادية، مذكورة بالدور الذي تؤديه لا بالفرد، فينجو الصف من تغيّر جهة الاتصال ويبقى مقروءًا لمن لم يلتقِ بها.

*  **وصف الاعتمادية:** ما يُتوقع من الطرف الخارجي أن يقدّمه أو يوافق عليه أو يتخذه، ومتى.

*  **الأساس التعاقدي:** هل تغطيها عقدية، أم مذكرة تفاهم، أم خطاب رسمي، أم لا شيء مكتوب. وهذا العمود هو الذي يحدد أمكن إنفاذ الاعتمادية، والالتزام المكتوب في مراسلات والالتزام المنصوص عليه في عقد يبدو متطابقًا في كل عمود آخر ومختلفًا تمامًا في الواقع.

*  **مطلوب بحلول:** التاريخ الذي يحتاج فيه البرنامج إلى هذا.

*  **الحالة:** أين تقف الاعتمادية. وللاعتماديات الخارجية، سجل بشكل منفصل ما إذا كان الطرف الخارجي قد أكدها، فالبرنامج يعرف موقفه بدقة ولا يعرف موقف الطرف الآخر إلا بالسؤال.

*  **المالك:** من المسؤول عن العلاقة مع الطرف الخارجي، وهو عادةً ليس من يحتاج المخرج.

صفوف التصعيد والاتفاقات:

*  **معرف الاعتمادية:** الاعتمادية التي يتعلق بها التصعيد، ليُوصل الصف بالسجل. والتصعيد المسجل دون هذا المرجع لا يمكن تتبعه إلى ما تعلق به، وتتكرر المسألة في الدورة التالية.

*  **المحفِّز:** ما سبّب التصعيد: تاريخ متفق عليه لم يُحترم، أو رفض صريح، أو تغيير في جانب السابقة، أو خلاف تجاري. فالعلاج يختلف في كل حالة، والتصعيد الذي لا يميز بينها ينتج تصعيدًا عامًا لا ينتج شيئًا.

*  **صُعد إلى:** من صُعد إليه، مذكورًا بالاسم لا موصوفًا، ليعرف القارئ إن كان يملك صلاحية القرار. والتصعيد إلى من لا يملك الصلاحية يسجل الخلاف دون تسجيل تسوية.

*  **الإجراء المتفق عليه:** ما اتُّفق عليه أو تم الاتفاق عليه، وهو ما يمنع تكرار السؤال نفسه في الدورة التالية بالنتيجة نفسها.

*  **التاريخ:** متى وقع التصعيد، ومتى ستتم مراجعته.
-->


<h3 align="left">{{اسم_الشركة}}</h3>
<h2 align="left">{{اسم_المحفظة_أو_البرنامج}} - {{معرف_الحوكمة}}</h2>
<h1 align="center">سجل الاعتماديات المتبادلة</h1>

| **تاريخ الإعداد:** {{التاريخ_الحالي}} | **مدير البرنامج:** {{اسم_مدير_البرنامج}} | **إعداد:** {{معد_الوثيقة}} |
| :--- | :--- | :--- |

---

## 1. أساس السجل
<!-- ما الذي يغطيه هذا السجل وعلى أي مستوى يُدار. سجل المستوى الذي يُدار عليه، فسجل على مستوى المحفظة وآخر على مستوى البرنامج يجيبان عن أسئلة مختلفة، وقراءة سجل المحفظة في مقابل جدول مشروع تؤدي إلى استنتاجات غير دقيقة على أي منهما. وسجل دورة المراجعة، فسجل لا يراجعه أحد يصف المحفظة كما كانت لا كما هي. وسجل ما إذا كان هذا مصدر الحقيقة أم مقتطفًا من أداة تخطيط، حتى لا يتعامل القارئ مع المقتطف على أنه ملزم ويتصرف بناء على تاريخ تحرك بعدها. -->

**نطاق السجل ومستواه:** [ أضف التفاصيل... ]

**البرامج أو المشاريع المشمولة:** [ أضف التفاصيل... ]

**مصدر الحقيقة أم مقتطف:** [ أضف التفاصيل... ]

**دورة المراجعة:** [ أضف التفاصيل... ]

**مالك السجل:** [ أضف التفاصيل... ]

**آخر تحديث:** [ أضف التفاصيل... ]

---

## 2. الاعتماديات الداخلية
<!-- بين المشاريع والمكونات التي يسيطر عليها البرنامج. سمِّ المخرج أو الشرط المحدد المنتظر، لا المشروع الآخر: فعبارة «بانتظار المشروع ب» لا يمكن تتبع مسارها والسيطرة على تداعياتها عند تأخره، إذ يصعب تحديد طبيعة المخرجات والمتطلبات المستهدفة بدقة، بينما «بانتظار مواصفة ترحيل البيانات المعتمدة من المشروع ب» يمكن مطاردتها وإغلاقها. وسجل التاريخ المطلوب، وهو طلب التابع، بجانب التاريخ المتفق عليه، فتظهر الفجوة بين المطلوب والمُوعود به في السجل نفسه لا تُكتشف لاحقًا. وحين يخدم المكون نفسه عدة توابع، سجل صفًا لكل واحد منهم، لأن التواريخ والآثار تختلف. أضف صفوفًا أو احذفها حسب الحاجة. -->

| المعرف | السابقة | التابعة | المخرج أو الشرط | نوع الاعتمادية | مطلوب بحلول | التاريخ المتفق عليه | الحالة | الأثر عند التأخر |
| ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: |
| [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] |
| [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] |
| [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] |
| [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] |
| [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] |

---

## 3. الاعتماديات الخارجية
<!-- على مؤسسات خارج البرنامج، وهي تتصرف على نحو مختلف ويحكمها أشخاص مختلفون. أهم عمود هنا هو الأساس التعاقدي، لأنه يحدد أمكن إنفاذ الاعتمادية: فالالتزام المكتوب في مراسلات والالتزام المنصوص عليه في عقد يبدو متطابقًا في كل عمود آخر ومختلفًا تمامًا في الواقع. وسمِّ الطرف الخارجي بالدور لا بالفرد، فينجو الصف من تغيّر جهة الاتصال، وسجل من المسؤول عن العلاقة منفصلًا ممن يحتاج المخرج. أضف صفوفًا أو احذفها حسب الحاجة. -->

| المعرف | الطرف الخارجي | وصف الاعتمادية | السند التعاقدي | مطلوب بحلول | الحالة | المالك |
| ---: | ---: | ---: | ---: | ---: | ---: | ---: |
| [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] |
| [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] |
| [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] |
| [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] |
---

## 4. التصعيدات والاتفاقات
<!-- ما قُدِّم بشأن الاعتماديات التي لا تتحقق نفسها. سجل المحفِّز، ليعرف القارئ أيّ تصعيد سببه تاريخ لم يُحترم وأيّ سببه رفض، لأن العلاج يختلف. وسجل ما اتُّفق عليه، فالتصعيد الذي لا ينتهي بقرار يتكرر في الدورة التالية بالنتيجة نفسها. أضف صفوفًا أو احذفها حسب الحاجة. -->

| معرف الاعتمادية | المحفِّز | صُعد إلى | الإجراء المتفق عليه | التاريخ |
| ---: | ---: | ---: | ---: | ---: |
| [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] |
| [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] |
| [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] |
| [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] |

---

## 5. الاعتماد والموافقات

| الدور | الاسم | التوقيع | التاريخ |
| ---: | ---: | ---: | ---: |
| **مدير البرنامج / المحفظة** | {{اسم_مدير_البرنامج}} | _______________________ | [.... -.... -.... ] |
| **قائد التسليم / المشاريع المرتبطة** | {{اسم_قائد_التسليم}} | _______________________ | [.... -.... -.... ] |
| **مسؤول مكتب إدارة المشاريع** | {{اسم_مسؤول_مكتب_إدارة_المشاريع}} | _______________________ | [.... -.... -.... ] |
---

<div align="left" style="margin-top: 20px; font-size: 12px; color: #7f8c8d;">
  <span>سجل التدقيق الإلكتروني: Hash SHA256: {{رمز_تجزئة_التدقيق_SHA256}}</span> <br>
 <strong>النموذج:</strong> سجل الاعتماديات المتبادلة | <strong>المرجع:</strong> PMO-00.03 <br>
 <i>تاريخ الإنشاء: {{وقت_الإنشاء}}، بواسطة <a href="https://github.com/fakhruldeen/Tasleemat/" style="color: #7f8c8d;">تسليمات</a></i>
</div>
</div>

دليل المستخدم وإرشادات الممارس

دليل نماذج تسليمات

مخرج المشروع: سجل الاعتماديات المتبادلة

المرجع الوثيقي: PMO-00.03

توفر هذه الوثيقة مرجعًا شاملًا ومهنيًا لفهم الغرض من سجل الاعتماديات المتبادلة واستخدامه الفعال بما يتوافق مع إطار تسليمات.

1. مفهوم الوثيقة وطبيعتها

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

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

2. القيمة والأهمية الاستراتيجية

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

3. التوقيت ودواعي الإعداد والتحديث

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

4. الأدوار والمسؤوليات (RACI)

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

إرشادات التخصيص والمواءمة

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

المحاذاة والترابط المؤسسي

ينبغي أن يكون سجل الاعتماديات المتبادلة متسقًا مع الوثائق التالية: * خارطة طريق المحفظة * ميثاق البرنامج * خطة إدارة المشروع * خطة إدارة الجدول الزمني

5. إرشادات تعبئة الحقول والبيانات

لإكمال سجل الاعتماديات المتبادلة على نحو دقيق ومهني، على المسؤول أن يملأ الحقول التالية بناءً على سياق المشروع (مع الرجوع إلى parameters.md للمتغيرات العامة للمشروع):

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

المحاذاة والترابط المؤسسي

6. نموذج تطبيقي معبأ (مثال استرشادي)

يتوفر نموذج تطبيقي مكتمل وعالي الجودة يوضح كيفية تعبئة واستخدام هذا المستند عملياً:

📖 النموذج التطبيقي المكتمل: 00_03_سجل_الاعتماديات_المتبادلة_مثال.md

مطالبة التوليد للذكاء الاصطناعي وتعليمات الوكيل

سجل الاعتماديات المتبادلة - دليل توليد النموذج الذكي

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

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

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

نطاق السجل ومستواه

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

القيمة المولدة: [ أضف التفاصيل... ]

البرامج أو المشاريع المشمولة

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

القيمة المولدة: [ أضف التفاصيل... ]

مصدر الحقيقة أم مقتطف

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

القيمة المولدة: [ أضف التفاصيل... ]

دورة المراجعة

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

القيمة المولدة: [ أضف التفاصيل... ]

مالك السجل

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

القيمة المولدة: [ أضف التفاصيل... ]

آخر تحديث

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

القيمة المولدة: [ أضف التفاصيل... ]

المعرف

التعليمات: معرف الاعتمادية، يُستخدم في قسم التصعيد وفي التقارير ليُشار إليه دون التباس حين يصبح مهددًا.

القيمة المولدة: [ أضف التفاصيل... ]

السابقة

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

القيمة المولدة: [ أضف التفاصيل... ]

التابعة

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

القيمة المولدة: [ أضف التفاصيل... ]

المخرج أو الشرط

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

القيمة المولدة: [ أضف التفاصيل... ]

نوع الاعتمادية

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

القيمة المولدة: [ أضف التفاصيل... ]

مطلوب بحلول

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

القيمة المولدة: [ أضف التفاصيل... ]

التاريخ المتفق عليه

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

القيمة المولدة: [ أضف التفاصيل... ]

الحالة

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

القيمة المولدة: [ أضف التفاصيل... ]

الأثر عند التأخر

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

القيمة المولدة: [ أضف التفاصيل... ]

المعرف

التعليمات: معرف الاعتمادية الخارجية، ليُشار إليه في التقارير ويُوصل بأي عقدة أو مراسلات تغطيه.

القيمة المولدة: [ أضف التفاصيل... ]

الطرف الخارجي

التعليمات: المؤسسة خارج البرنامج التي تمر عبرها الاعتمادية، مذكورة بالدور الذي تؤديه لا بالفرد، فينجو الصف من تغيّر جهة الاتصال ويبقى مقروءًا لمن لم يلتقِ بها.

القيمة المولدة: [ أضف التفاصيل... ]

وصف الاعتمادية

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

القيمة المولدة: [ أضف التفاصيل... ]

الأساس التعاقدي

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

القيمة المولدة: [ أضف التفاصيل... ]

مطلوب بحلول

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

القيمة المولدة: [ أضف التفاصيل... ]

الحالة

التعليمات: أين تقف الاعتمادية. وللاعتماديات الخارجية، سجل بشكل منفصل ما إذا كان الطرف الخارجي قد أكدها، فالبرنامج يعرف موقفه بدقة ولا يعرف موقف الطرف الآخر إلا بالسؤال.

القيمة المولدة: [ أضف التفاصيل... ]

المالك

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

القيمة المولدة: [ أضف التفاصيل... ]

معرف الاعتمادية

التعليمات: الاعتمادية التي يتعلق بها التصعيد، ليُوصل الصف بالسجل. والتصعيد المسجل دون هذا المرجع لا يمكن تتبعه إلى ما تعلق به، وتتكرر المسألة في الدورة التالية.

القيمة المولدة: [ أضف التفاصيل... ]

المحفِّز

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

القيمة المولدة: [ أضف التفاصيل... ]

صُعد إلى

التعليمات: من صُعد إليه، مذكورًا بالاسم لا موصوفًا، ليعرف القارئ إن كان يملك صلاحية القرار. والتصعيد إلى من لا يملك الصلاحية يسجل الخلاف دون تسجيل تسوية.

القيمة المولدة: [ أضف التفاصيل... ]

الإجراء المتفق عليه

التعليمات: ما اتُّفق عليه، وهو ما يمنع تكرار السؤال نفسه في الدورة التالية بالنتيجة نفسها. وحين لم يُتفق على شيء فسجل ذلك صراحةً، فالإجراء الفارغ والتصعيد غير المحسوم يبدوان متطابقين بعد قراءة السجل مرات.

القيمة المولدة: [ أضف التفاصيل... ]

التاريخ

التعليمات: متى وقع التصعيد، ومتى ستتم مراجعته عند الاقتضاء. والتصعيد بلا تاريخ لا موضع له في التسلسل، فيصير السجل قائمة مظالم بدل سجل قرارات.

القيمة المولدة: [ أضف التفاصيل... ]

PMO-00.03 المرحلة 00: إدارة البرامج والمحافظ دراسة حالة واقعية مكتملة
تاريخ الإعداد
2026-03-15
مدير البرنامج
م. خالد العتيبي، PgMP
إعداد
م. فيصل الحربي، PMP (مدير المشروع)

سجل الاعتماديات المتبادلة (نموذج تطبيقي معبأ)

🏆 نموذج استرشادي مكتمل (Gold Standard): يوضح هذا المستند التطبيق العملي المتكامل لهذا النموذج وفق معايير تسليمات (PMO-00.03). كافة الأسماء والبيانات الواردة هي لأغراض العرض التوضيحي والمحاكاة المؤسسية الفرضية.

شركة القمة للحلول المؤسسية المتقدمة

محفظة التحول الرقمي وتحديث العمليات المؤسسية - GOV-2026-ERP

سجل الاعتماديات المتبادلة

1. أساس السجل

نطاق السجل ومستواه: تحقيق التميز التشغيلي وأتمتة العمليات والربط السحابي الموحد وفق أعلى المعايير القياسية.

البرامج أو المشاريع المشمولة: تم تحديده وتوثيقه بالتفصيل ليتوافق مع أهداف المشروع والمتطلبات التشغيلية لشركة القمة.

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

دورة المراجعة: 2026-Q1 إلى 2027-Q4 (دورة سنوية مع مراجعة ربع سنوية)

مالك السجل: أ. إلينا فانس، PfMP (مدير المحفظة والتحول المؤسسي)

آخر تحديث: تم تحديده وتوثيقه بالتفصيل ليتوافق مع أهداف المشروع والمتطلبات التشغيلية لشركة القمة.

2. الاعتماديات الداخلية

المعرف السابقة التابعة المخرج أو الشرط نوع الاعتمادية مطلوب بحلول التاريخ المتفق عليه الحالة الأثر عند التأخر
INIT-01 INIT-01 (المنظومة السحابية) أتمتة سلاسل الإمداد الذكية المنظومة السحابية الموحدة لتخطيط الموارد نهاية إلى بداية (FS) 2026-06-30 2026-06-30 قيد التنفيذ تأخير بدء اختبارات التكامل لمدة أسبوعين
REQ-02 INIT-02 (سلاسل الإمداد) منصة التقارير التحليلية المتقدمة أتمتة سلاسل الإمداد والمستودعات الذكية بداية إلى بداية (SS) 2026-09-30 2026-09-30 مكتمل إعادة جدولة نافذة الإطلاق التشغيلي التجريبي
ACT-03 INIT-01 (البنية التحتية) بوابة الخدمات الذاتية الموحدة منصة التقارير التحليلية والذكاء المؤسسي نهاية إلى نهاية (FF) 2026-11-30 2026-11-30 مخطط زيادة طفيفة في استهلاك ساعات الاستشارات التقنية
BEN-04 INIT-03 (البيانات) طبقة التكامل السحابي بوابة الخدمات الذاتية وإدارة رأس المال البشري نهاية إلى بداية (FS) 2027-01-31 2027-01-31 معتمد ترحيل تاريخ التدريب للمجموعة الثانية
WBS-05 INIT-01 (المنظومة السحابية) أتمتة سلاسل الإمداد الذكية طبقة التكامل السحابي والربط البرمجي API نهاية إلى بداية (FS) 2027-03-31 2027-03-31 قيد التنفيذ تأخير بدء اختبارات التكامل لمدة أسبوعين

3. الاعتماديات الخارجية

المعرف الطرف الخارجي وصف الاعتمادية السند التعاقدي مطلوب بحلول الحالة المالك
INIT-01 معتمد ومطابق للمعايير القياسية لشركة القمة معتمد ومطابق للمعايير القياسية لشركة القمة معتمد ومطابق للمعايير القياسية لشركة القمة 2026-06-30 قيد التنفيذ أ. إلينا فانس، PfMP
REQ-02 معتمد ومطابق للمعايير القياسية لشركة القمة معتمد ومطابق للمعايير القياسية لشركة القمة معتمد ومطابق للمعايير القياسية لشركة القمة 2026-09-30 مكتمل م. فيصل الحربي، PMP
ACT-03 معتمد ومطابق للمعايير القياسية لشركة القمة معتمد ومطابق للمعايير القياسية لشركة القمة معتمد ومطابق للمعايير القياسية لشركة القمة 2026-11-30 مخطط د. طارق المنصور، PfMP
BEN-04 معتمد ومطابق للمعايير القياسية لشركة القمة معتمد ومطابق للمعايير القياسية لشركة القمة معتمد ومطابق للمعايير القياسية لشركة القمة 2027-01-31 معتمد أ. سلطان الدوسري
---

4. التصعيدات والاتفاقات

معرف الاعتمادية المحفِّز صُعد إلى الإجراء المتفق عليه التاريخ
INIT-01 معتمد ومطابق للمعايير القياسية لشركة القمة معتمد ومطابق للمعايير القياسية لشركة القمة تم التحقق من الجاهزية والامتثال لضوابط الأمن السيبراني 2026-06-30
REQ-02 معتمد ومطابق للمعايير القياسية لشركة القمة معتمد ومطابق للمعايير القياسية لشركة القمة جلسات المتابعة والتنسيق مستمرة وفق الجدول المعتمد 2026-09-30
ACT-03 معتمد ومطابق للمعايير القياسية لشركة القمة معتمد ومطابق للمعايير القياسية لشركة القمة تم رصد مخصص الطوارئ المعتمد لهذه المرحلة 2026-11-30
BEN-04 معتمد ومطابق للمعايير القياسية لشركة القمة معتمد ومطابق للمعايير القياسية لشركة القمة مؤشرات الأداء التشغيلي ضمن الحدود المستهدفة 2027-01-31

5. الاعتماد والموافقات

الدور الاسم التوقيع التاريخ
مدير البرنامج / المحفظة م. خالد العتيبي، PgMP [معتمد إلكترونياً] 2026-03-18
قائد التسليم / المشاريع المرتبطة م. فيصل الحربي، PMP [معتمد إلكترونياً] 2026-03-18
مسؤول مكتب إدارة المشاريع د. طارق المنصور، PfMP [معتمد إلكترونياً] 2026-03-18
---
النموذج: سجل الاعتماديات المتبادلة | المرجع: PMO-00.03
تاريخ الإنشاء: 2026-03-15 10:00 بتوقيت مكة المكرمة، بواسطة تسليمات

مخطط JSON Schema (معيار Draft 2020-12)

العقد الرقمي المعياري لتمكين التحقق الآلي من بيانات التسليمة بواسطة أداة tasleemat. 
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://tasleemat.pmo/schemas/completed/PMO-00.03.schema.json",
  "title": "Completed Interdependency Register Data Contract",
  "description": "Additive structural schema validating completed Interdependency Register artifact data payloads (PMO-00.03).",
  "type": "object",
  "properties": {
    "artifact_id": {
      "type": "string",
      "const": "PMO-00.03"
    },
    "metadata": {
      "type": "object",
      "properties": {
        "project_name": {
          "type": "string",
          "minLength": 1
        },
        "project_code": {
          "type": "string"
        },
        "date_prepared": {
          "type": "string",
          "format": "date"
        },
        "project_manager": {
          "type": "string",
          "minLength": 1
        },
        "prepared_by": {
          "type": "string",
          "minLength": 1
        },
        "version": {
          "type": "string"
        },
        "status": {
          "type": "string",
          "enum": [
            "draft",
            "baselined",
            "in_review",
            "approved"
          ]
        }
      },
      "required": [
        "project_name",
        "date_prepared",
        "project_manager",
        "prepared_by"
      ]
    },
    "register_basis": {
      "type": "object",
      "properties": {
        "register_scope_and_level": {
          "type": "string",
          "minLength": 1,
          "description": "What this register covers and at what level it is maintained, whether portfolio-wide, program-level, or project-level. The level decides which plan the register is compared against, and a portfolio register read against a project schedule produces conclusions that are true of neither."
        },
        "programs_or_projects_covered": {
          "type": "string",
          "minLength": 1,
          "description": "The programs, projects, or components whose mutual dependencies are recorded, by name and identifier so the list can be joined to the portfolio roadmap. A register that names no components cannot be checked for completeness, and an incomplete register reads as a complete one."
        },
        "source_of_truth_or_extract": {
          "type": "string",
          "minLength": 1,
          "description": "Whether this register is the authoritative record or an extract from a planning tool. Record which, because a reader who treats an extract as authoritative will act on a date that has since moved, and the error is invisible until the dependency is missed."
        },
        "review_cycle": {
          "type": "string",
          "minLength": 1,
          "description": "How often the register is reviewed and by which forum. The cycle is what makes two versions comparable, and a register refreshed on no cycle describes the portfolio as it once was rather than as it is."
        },
        "register_owner": {
          "type": "string",
          "minLength": 1,
          "description": "The single role accountable for the register as a whole, which is normally not the owner of any one dependency in it. Where this is left blank, the register has contributors but no one who notices that a row has gone stale."
        },
        "last_updated": {
          "type": "string",
          "minLength": 1,
          "description": "The date the register was last reviewed, and against which version of the portfolio roadmap. Without it, a reader has no way to tell a current register from an abandoned one, and the two look identical on the page."
        }
      },
      "required": [
        "register_scope_and_level",
        "programs_or_projects_covered",
        "source_of_truth_or_extract",
        "review_cycle",
        "register_owner",
        "last_updated"
      ]
    },
    "internal_interdependencies": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string",
          "minLength": 1,
          "description": "The identifier for the dependency, used in the escalation section and in reporting so a threatened dependency can be referred to without ambiguity."
        },
        "predecessor": {
          "type": "string",
          "minLength": 1,
          "description": "The project or component that must deliver first, named and identified so the row can be joined to the portfolio roadmap. \"Project B\" is not a predecessor; the component's own identifier is, because that is what survives it being renamed."
        },
        "successor": {
          "type": "string",
          "minLength": 1,
          "description": "The project or component that is waiting. Where the same predecessor is needed by several successors, record a row for each rather than listing them together, because the required dates and the impacts differ and one date cannot serve all of them."
        },
        "deliverable_or_condition": {
          "type": "string",
          "minLength": 1,
          "description": "What specifically is being waited on, stated so that it can be confirmed as delivered or not. \"Waiting for Project B\" cannot be chased when Project B slips, because nobody knows what to ask for; \"waiting for the signed data migration specification from Project B\" can be chased, and can be closed."
        },
        "dependency_type": {
          "type": "string",
          "minLength": 1,
          "description": "Whether the relationship is Finish to Start, Start to Start, Finish to Finish, or Start to Finish. The type determines how much float the successor has, and Finish to Start is the only one needing no explanation; the others arise where two projects must move together and cannot be read from the names alone."
        },
        "required_by": {
          "type": "string",
          "minLength": 1,
          "description": "The date by which the successor needs the deliverable. This is the successor's requirement, and recording the predecessor's forecast here instead hides the gap between what is needed and what has been promised, which is the only figure worth watching."
        },
        "agreed_date": {
          "type": "string",
          "minLength": 1,
          "description": "The date the predecessor has committed to. Kept beside the required date so the gap between the two is visible in the register itself; where the agreed date is later than the required date, that gap is the dependency's risk, and it is usually found out by being overrun rather than by being read."
        },
        "status": {
          "type": "string",
          "minLength": 1,
          "description": "Where the dependency currently stands against the fixed set agreed for this register, such as On Track, At Risk, Breached, or Agreed. A free-text status cannot be filtered, and a register of forty dependencies that cannot be filtered is a document nobody consults when they need to answer a question about one of them."
        },
        "impact_if_late": {
          "type": "string",
          "minLength": 1,
          "description": "What happens to the successor if the predecessor misses the required date, in schedule, cost, or scope terms. A dependency with no stated impact cannot be escalated, because nobody can say what is at stake, and an escalation that cannot state the stake is usually declined."
        }
      },
      "required": [
        "id",
        "predecessor",
        "successor",
        "deliverable_or_condition",
        "dependency_type",
        "required_by",
        "agreed_date",
        "status",
        "impact_if_late"
      ]
    },
    "external_interdependencies": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string",
          "minLength": 1,
          "description": "The identifier for the external dependency, so it can be referred to in reporting and joined to any contract or correspondence that covers it."
        },
        "external_party": {
          "type": "string",
          "minLength": 1,
          "description": "The organisation outside the program through which the dependency runs, named by the role it plays rather than by the individual, so the row survives a change of contact and remains readable to someone who has not met them."
        },
        "dependency_description": {
          "type": "string",
          "minLength": 1,
          "description": "What the external party is expected to provide, approve, or decide, and by when. State it as something that can be confirmed as done, since a dependency described as ongoing support cannot be closed and will therefore never show as satisfied."
        },
        "contractual_basis": {
          "type": "string",
          "minLength": 1,
          "description": "Whether the dependency is covered by a contract, a memorandum of understanding, a formal letter, or nothing in writing. This column decides whether the dependency can be enforced, and a commitment taken in correspondence and one written into a contract look identical in every other column while being entirely different in practice."
        },
        "required_by": {
          "type": "string",
          "minLength": 1,
          "description": "The date the program needs this, which for an external dependency is usually a hard commercial or regulatory date rather than a date the program chose. Record where the date comes from, because an external date the program did not set is a date it cannot move."
        },
        "status": {
          "type": "string",
          "minLength": 1,
          "description": "Where the dependency stands against the fixed set. For external dependencies record separately whether the external party has confirmed it, since the program can know its own position accurately and the other party's only by asking."
        },
        "owner": {
          "type": "string",
          "minLength": 1,
          "description": "Who is accountable for the relationship with the external party, which is normally not the person who needs the deliverable. Separating the two is what stops the urgency of a need being communicated through whoever happens to have the contact."
        }
      },
      "required": [
        "id",
        "external_party",
        "dependency_description",
        "contractual_basis",
        "required_by",
        "status",
        "owner"
      ]
    },
    "escalations_and_agreements": {
      "type": "object",
      "properties": {
        "dependency_id": {
          "type": "string",
          "minLength": 1,
          "description": "The dependency the escalation concerns, so the row can be joined back to the register. An escalation recorded without this reference cannot be traced to the thing it was about, and the next cycle repeats it."
        },
        "trigger": {
          "type": "string",
          "minLength": 1,
          "description": "What caused the escalation: a missed agreed date, an explicit refusal, a change on the predecessor's side, or a commercial dispute. The remedy differs in each case, and an escalation that does not distinguish them tends to produce a general escalation that resolves nothing."
        },
        "escalated_to": {
          "type": "string",
          "minLength": 1,
          "description": "Who it was escalated to, named rather than described, so the reader knows whether the person holds the authority to decide. An escalation to somebody who cannot decide records the disagreement without recording a resolution."
        },
        "action_agreed": {
          "type": "string",
          "minLength": 1,
          "description": "What was decided or agreed, which is what stops the same question being escalated again next cycle with the same outcome. Where nothing was agreed, record that explicitly, because a blank action and an unresolved escalation look identical once the register has been read a few times."
        },
        "date": {
          "type": "string",
          "minLength": 1,
          "description": "When the escalation happened, and where relevant when it will next be reviewed. An escalation without a date has no position in the sequence, and the register becomes a list of grievances rather than a record of decisions."
        }
      },
      "required": [
        "dependency_id",
        "trigger",
        "escalated_to",
        "action_agreed",
        "date"
      ]
    }
  },
  "required": [
    "artifact_id",
    "metadata",
    "register_basis",
    "internal_interdependencies",
    "external_interdependencies",
    "escalations_and_agreements"
  ]
}
📋 قاموس تعريفات حقول النموذج (المواصفة التفصيلية) 
{
  "_llm_instructions": "Fill in the 'project_title' and 'date_prepared' properties, and the 'value' property of each field, based on the provided project context. Reference parameters.md for global project variables.",
  "form_name": "Interdependency Register",
  "document_reference": "PMO-00.03",
  "project_title": "",
  "date_prepared": "",
  "fields": {
    "f01_Register_Scope_and_Level": {
      "section": "Register Basis",
      "label": "Register Scope and Level",
      "guidance": "What this register covers and at what level it is maintained, whether portfolio-wide, program-level, or project-level. The level decides which plan the register is compared against, and a portfolio register read against a project schedule produces conclusions that are true of neither.",
      "value": ""
    },
    "f02_Programs_or_Projects_Covered": {
      "section": "Register Basis",
      "label": "Programs or Projects Covered",
      "guidance": "The programs, projects, or components whose mutual dependencies are recorded, by name and identifier so the list can be joined to the portfolio roadmap. A register that names no components cannot be checked for completeness, and an incomplete register reads as a complete one.",
      "value": ""
    },
    "f03_Source_of_Truth_or_Extract": {
      "section": "Register Basis",
      "label": "Source of Truth or Extract",
      "guidance": "Whether this register is the authoritative record or an extract from a planning tool. Record which, because a reader who treats an extract as authoritative will act on a date that has since moved, and the error is invisible until the dependency is missed.",
      "value": ""
    },
    "f04_Review_Cycle": {
      "section": "Register Basis",
      "label": "Review Cycle",
      "guidance": "How often the register is reviewed and by which forum. The cycle is what makes two versions comparable, and a register refreshed on no cycle describes the portfolio as it once was rather than as it is.",
      "value": ""
    },
    "f05_Register_Owner": {
      "section": "Register Basis",
      "label": "Register Owner",
      "guidance": "The single role accountable for the register as a whole, which is normally not the owner of any one dependency in it. Where this is left blank, the register has contributors but no one who notices that a row has gone stale.",
      "value": ""
    },
    "f06_Last_Updated": {
      "section": "Register Basis",
      "label": "Last Updated",
      "guidance": "The date the register was last reviewed, and against which version of the portfolio roadmap. Without it, a reader has no way to tell a current register from an abandoned one, and the two look identical on the page.",
      "value": ""
    },
    "f07_ID": {
      "section": "Internal Interdependencies",
      "label": "ID",
      "guidance": "The identifier for the dependency, used in the escalation section and in reporting so a threatened dependency can be referred to without ambiguity.",
      "value": ""
    },
    "f08_Predecessor": {
      "section": "Internal Interdependencies",
      "label": "Predecessor",
      "guidance": "The project or component that must deliver first, named and identified so the row can be joined to the portfolio roadmap. \"Project B\" is not a predecessor; the component's own identifier is, because that is what survives it being renamed.",
      "value": ""
    },
    "f09_Successor": {
      "section": "Internal Interdependencies",
      "label": "Successor",
      "guidance": "The project or component that is waiting. Where the same predecessor is needed by several successors, record a row for each rather than listing them together, because the required dates and the impacts differ and one date cannot serve all of them.",
      "value": ""
    },
    "f10_Deliverable_or_Condition": {
      "section": "Internal Interdependencies",
      "label": "Deliverable or Condition",
      "guidance": "What specifically is being waited on, stated so that it can be confirmed as delivered or not. \"Waiting for Project B\" cannot be chased when Project B slips, because nobody knows what to ask for; \"waiting for the signed data migration specification from Project B\" can be chased, and can be closed.",
      "value": ""
    },
    "f11_Dependency_Type": {
      "section": "Internal Interdependencies",
      "label": "Dependency Type",
      "guidance": "Whether the relationship is Finish to Start, Start to Start, Finish to Finish, or Start to Finish. The type determines how much float the successor has, and Finish to Start is the only one needing no explanation; the others arise where two projects must move together and cannot be read from the names alone.",
      "value": ""
    },
    "f12_Required_By": {
      "section": "Internal Interdependencies",
      "label": "Required By",
      "guidance": "The date by which the successor needs the deliverable. This is the successor's requirement, and recording the predecessor's forecast here instead hides the gap between what is needed and what has been promised, which is the only figure worth watching.",
      "value": ""
    },
    "f13_Agreed_Date": {
      "section": "Internal Interdependencies",
      "label": "Agreed Date",
      "guidance": "The date the predecessor has committed to. Kept beside the required date so the gap between the two is visible in the register itself; where the agreed date is later than the required date, that gap is the dependency's risk, and it is usually found out by being overrun rather than by being read.",
      "value": ""
    },
    "f14_Status": {
      "section": "Internal Interdependencies",
      "label": "Status",
      "guidance": "Where the dependency currently stands against the fixed set agreed for this register, such as On Track, At Risk, Breached, or Agreed. A free-text status cannot be filtered, and a register of forty dependencies that cannot be filtered is a document nobody consults when they need to answer a question about one of them.",
      "value": ""
    },
    "f15_Impact_if_Late": {
      "section": "Internal Interdependencies",
      "label": "Impact if Late",
      "guidance": "What happens to the successor if the predecessor misses the required date, in schedule, cost, or scope terms. A dependency with no stated impact cannot be escalated, because nobody can say what is at stake, and an escalation that cannot state the stake is usually declined.",
      "value": ""
    },
    "f16_ID": {
      "section": "External Interdependencies",
      "label": "ID",
      "guidance": "The identifier for the external dependency, so it can be referred to in reporting and joined to any contract or correspondence that covers it.",
      "value": ""
    },
    "f17_External_Party": {
      "section": "External Interdependencies",
      "label": "External Party",
      "guidance": "The organisation outside the program through which the dependency runs, named by the role it plays rather than by the individual, so the row survives a change of contact and remains readable to someone who has not met them.",
      "value": ""
    },
    "f18_Dependency_Description": {
      "section": "External Interdependencies",
      "label": "Dependency Description",
      "guidance": "What the external party is expected to provide, approve, or decide, and by when. State it as something that can be confirmed as done, since a dependency described as ongoing support cannot be closed and will therefore never show as satisfied.",
      "value": ""
    },
    "f19_Contractual_Basis": {
      "section": "External Interdependencies",
      "label": "Contractual Basis",
      "guidance": "Whether the dependency is covered by a contract, a memorandum of understanding, a formal letter, or nothing in writing. This column decides whether the dependency can be enforced, and a commitment taken in correspondence and one written into a contract look identical in every other column while being entirely different in practice.",
      "value": ""
    },
    "f20_Required_By": {
      "section": "External Interdependencies",
      "label": "Required By",
      "guidance": "The date the program needs this, which for an external dependency is usually a hard commercial or regulatory date rather than a date the program chose. Record where the date comes from, because an external date the program did not set is a date it cannot move.",
      "value": ""
    },
    "f21_Status": {
      "section": "External Interdependencies",
      "label": "Status",
      "guidance": "Where the dependency stands against the fixed set. For external dependencies record separately whether the external party has confirmed it, since the program can know its own position accurately and the other party's only by asking.",
      "value": ""
    },
    "f22_Owner": {
      "section": "External Interdependencies",
      "label": "Owner",
      "guidance": "Who is accountable for the relationship with the external party, which is normally not the person who needs the deliverable. Separating the two is what stops the urgency of a need being communicated through whoever happens to have the contact.",
      "value": ""
    },
    "f23_Dependency_ID": {
      "section": "Escalations and Agreements",
      "label": "Dependency ID",
      "guidance": "The dependency the escalation concerns, so the row can be joined back to the register. An escalation recorded without this reference cannot be traced to the thing it was about, and the next cycle repeats it.",
      "value": ""
    },
    "f24_Trigger": {
      "section": "Escalations and Agreements",
      "label": "Trigger",
      "guidance": "What caused the escalation: a missed agreed date, an explicit refusal, a change on the predecessor's side, or a commercial dispute. The remedy differs in each case, and an escalation that does not distinguish them tends to produce a general escalation that resolves nothing.",
      "value": ""
    },
    "f25_Escalated_To": {
      "section": "Escalations and Agreements",
      "label": "Escalated To",
      "guidance": "Who it was escalated to, named rather than described, so the reader knows whether the person holds the authority to decide. An escalation to somebody who cannot decide records the disagreement without recording a resolution.",
      "value": ""
    },
    "f26_Action_Agreed": {
      "section": "Escalations and Agreements",
      "label": "Action Agreed",
      "guidance": "What was decided or agreed, which is what stops the same question being escalated again next cycle with the same outcome. Where nothing was agreed, record that explicitly, because a blank action and an unresolved escalation look identical once the register has been read a few times.",
      "value": ""
    },
    "f27_Date": {
      "section": "Escalations and Agreements",
      "label": "Date",
      "guidance": "When the escalation happened, and where relevant when it will next be reviewed. An escalation without a date has no position in the sequence, and the register becomes a list of grievances rather than a record of decisions.",
      "value": ""
    }
  }
}