تخطي إلى المحتوى الرئيسي

الحوكمة والقرارات والإجراءات

البداية · الحوكمة والقرارات والإجراءات

المبادرة والملخصات والإجراءات المحكومة

الهدف​

تشرح هذه الصفحة، بطريقة بسيطة، كيف ينتقل ProPM Agent:

  1. من إشارة مكتشفة؛
  2. إلى قرار؛
  3. ثم إلى إجراء محكوم؛
  4. قد يخضع في النهاية إلى موافقة؛
  5. قبل أن يتم تنفيذه وتتبعه.

تساعدك هذه الصفحة على فهم ما يلي بوضوح:

  • ما هي سياسة الحوكمة؛
  • ما معنى allow و**require_approval** و**deny**؛
  • ما معنى observe و**draft** و**propose** و**execute**؛
  • كيفية استخدام الإجراءات والموافقات خطوة بخطوة؛
  • لماذا قد يكون إجراء ما مرئيا لكنه محظور.

نظرة مبسطة جدا على التدفق​

في ProPM Agent، يكون المسار الطبيعي كما يلي:

  1. تلفت إشارة الانتباه؛
  2. يقرأها الفريق؛
  3. تقرر الحوكمة ما يمكن لكل دور فعله؛
  4. إذا كانت هناك حاجة إلى مخرج خارجي، يتم إنشاء إجراء؛
  5. إذا تطلب المشروع ذلك، يمر الإجراء إلى الموافقة؛
  6. بعد ذلك يتم تنفيذ الإجراء أو رفضه؛
  7. يبقى الأثر مرئيا في النشاط وسجل الذكاء الاصطناعي.

الجزء 1 - فهم الإشارات​

الإشارة هي تنبيه منظم يقول: «هذا الموضوع يستحق الانتباه».

أمثلة على الإشارات​

يمكن أن تنشأ الإشارة من:

  • حداثة غير كافية للمصادر؛
  • تناقض بين عدة أدلة؛
  • عائق في المشروع؛
  • خطوة لاحقة تستحق إشعارا أو قرارا أو إجراء خارجيا.

ما يراه المستخدم عادة في بطاقة إشارة​

يمكن أن تعرض بطاقة الإشارة:

  • عنوانا؛
  • ملخصا؛
  • تفسيرا؛
  • شدة؛
  • حالة؛
  • وضعا؛
  • عددا من الأدلة أو إعادات التنشيط؛
  • إجراءات مثل Create draft أو Snooze 24h أو Dismiss حسب الدور.

الخطوات الموصى بها لمعالجة إشارة​

عندما تفتح إشارة، اتبع هذا الترتيب:

  1. اقرأ الملخص؛
  2. أعد قراءة التفسير؛
  3. تحقق من الأدلة والحداثة؛
  4. قرر ما إذا كان الموضوع يتطلب مراقبة فقط، أو مسودة، أو إجراء حقيقيا؛
  5. إذا أصبح مخرج خارجي ضروريا، فانتقل إلى الإجراءات والموافقات.

حالات مفيدة للإشارة​

الحالةما تعنيه
openلا يزال الموضوع نشطا ويحتاج إلى انتباه
snoozedالموضوع متوقف مؤقتا
dismissedأزيل الموضوع من قائمة الانتظار النشطة
resolvedيعد الموضوع معالجا

أوضاع مفيدة للإشارة​

الوضعقراءة بسيطة
informالإشارة تقدم معلومات دون طلب إجراء فوري
suggestالإشارة تقترح خطوة تالية
draftالإشارة موجهة مسبقا إلى مسودة أو تحضير
request_approvalالإشارة تطلب مراجعة محكومة أو موافقة

الجزء 2 - سياسات الحوكمة​

ما هي سياسة الحوكمة؟​

سياسة الحوكمة هي قاعدة تجيب عن السؤال:

«من يحق له فعل ماذا، على أي موصل، وبأي مستوى من التحكم؟»

بعبارة أخرى، تمنع الحوكمة خروج إجراء خارجي دون إطار واضح.

ما الذي تقرره السياسة​

تجيب السياسة عادة عن أربعة أسئلة:

  1. من؟ - أي دور معني؛
  2. على ماذا؟ - أي موصل أو نوع إجراء أو وجهة معنية؛
  3. إلى أي مدى؟ - مجرد مراقبة، أو مسودة، أو اقتراح، أو تنفيذ؛
  4. بأي أثر؟ - مصرح به، أو مصرح به مع موافقة، أو مرفوض.

مثال بسيط جدا​

يمكن أن تعني السياسة ما يلي:

  • يستطيع المساهم إعداد مسودة في Teams؛
  • يستطيع مدير المشروع اقتراح نشر في SharePoint؛
  • يجب أن يوافق مالك المشروع قبل التنفيذ؛
  • لا يمكن لأي شخص آخر تنفيذ هذا النشر مباشرة.

فهم المستويات: observe وdraft وpropose وexecute​

يصف المستوى إلى أي مدى يمكن أن يذهب دور ما في التدفق.

المستوىما يمكن للمستخدم فعلهما لا يمكنه فعله بعدمثال بسيط
observeرؤية المعلومات، متابعة الموضوع، الاطلاع على قائمة الانتظارإنشاء إجراء أو مسودةقارئ يتابع الإشارات دون إعداد مخرج
draftإعداد مسودة أو نص أو نية إجراءإرسال الإجراء رسميا إلى قائمة الانتظارمساهم يعد رسالة Teams لكنه لا يقترحها
proposeإرسال طلب إجراء حقيقي في قائمة الانتظار المحكومةتنفيذ الإجراء مباشرةمدير مشروع يقترح ticket Jira
executeإطلاق التنفيذ الحقيقي إذا تحققت الشروط الأخرىتجاوز السياسة أو الموافقات المفروضةمالك مشروع ينشر أثرا في SharePoint

قراءة بسيطة جدا​

  • observe = أراقب؛
  • draft = أعد؛
  • propose = أطلب رسميا؛
  • execute = أطلق فعليا.

فهم الآثار: allow وrequire_approval وdeny​

يصف الأثر ما تفعله المنصة عندما يبلغ دور ما ذلك المستوى.

الأثرما يعنيهالنتيجة العملية
allowالإجراء مصرح به عند ذلك المستوىيمكن للتدفق التقدم دون خطوة موافقة إضافية إذا كان الباقي جاهزا
require_approvalالإجراء ممكن، لكنه يجب أن يخضع للموافقةتصبح قائمة انتظار الموافقات إلزامية قبل التنفيذ
denyالإجراء محظور لهذا الدور أو النطاقلا يستطيع المستخدم التقدم أكثر في هذا التدفق

قراءة بسيطة جدا​

  • allow = نعم؛
  • require_approval = نعم، لكن بعد اعتماد بشري؛
  • deny = لا.

كيفية قراءة سطر سياسة​

لنأخذ هذه القراءة:

  • الدور: مدير المشروع
  • الموصل: SharePoint publish
  • المستوى: execute
  • الأثر: require_approval

هذا يعني:

  • يمكن لمدير المشروع الوصول إلى طلب التنفيذ؛
  • لكن النشر لا يخرج فورا؛
  • يلزم الحصول على موافقة قبل التنفيذ الحقيقي.

أمثلة ملموسة على السياسات​

حالة الأعمالالدورالمستوى الموصى بهالأثر الموصى بهالسبب
نشر تقرير إلى SharePointمدير المشروعexecuterequire_approvalالمخرج خارجي ويجب مراجعته
إنشاء ticket Jira من عائقمدير المشروعproposeallow أو require_approvalيمكن للمشروع طلب ticket دون فتحه تلقائيا بالضرورة
رسالة Teams داخلية منخفضة المخاطرالمساهمexecute أو proposeallowتواصل سريع بأثر منخفض
بريد Outlook إلى الرعاةالمساهمproposerequire_approvalتواصل أكثر حساسية ورسمية
webhook إلى أداة خارجيةمالك المشروعexecuterequire_approvalمخرج تقني يجب إبقاؤه تحت تحكم قوي
موصل غير جاهز أو غير مصرح بهالجميع باستثناء المسؤولobserve أو لا استخدامdenyنتجنب أي خروج عرضي

خطوات تكوين سياسة حوكمة​

اتبع هذا الترتيب البسيط.

الخطوة 1 - فتح السطح الصحيح​

من مساحة عمل المشروع، افتح سياسات الحوكمة.

الخطوة 2 - اختيار التدفق المطلوب التحكم فيه​

اسأل نفسك أولا:

  • هل يتعلق الأمر بعملية نشر؛
  • أو ticket؛
  • أو رسالة؛
  • أو webhook؛
  • أو إجراء خارجي آخر؟

الخطوة 3 - اختيار الدور المعني​

حدد بعد ذلك الدور الذي يمكنه التصرف:

  • المساهم؛
  • مدير المشروع؛
  • مالك المشروع؛
  • أو أي دور آخر موجود في تكوينك.

الخطوة 4 - اختيار مستوى الإجراء​

قرر ما إذا كان هذا الدور يجب أن يكتفي بـ:

  • المراقبة؛
  • إعداد مسودة؛
  • الاقتراح؛
  • أو التنفيذ.

الخطوة 5 - اختيار الأثر​

قرر ما إذا كان هذا المستوى يجب أن يكون:

  • مصرحا به مباشرة (allow)؛
  • مصرحا به مع موافقة (require_approval)؛
  • أو مرفوضا (deny).

الخطوة 6 - التحقق من الموصل أو الوجهة المعنية​

لا تكفي السياسة الجيدة إذا كان الموصل:

  • غير جاهز تقنيا؛
  • غير مفتوح للمشروع؛
  • أو لا يملك وجهة الأثر الصحيحة.

الخطوة 7 - الاختبار بدور غير مسؤول​

أفضل تحكم هو التحكم العملي:

  1. سجل الدخول بدور أعمال واقعي؛
  2. افتح الإجراءات والموافقات؛
  3. تحقق مما هو مرئي أو مصرح به أو محظور؛
  4. عدل السياسة إذا لم يكن السلوك كما هو متوقع.

سياسات حوكمة المشروع

قواعد بسيطة لتكوين الحوكمة بشكل جيد​

  • استخدم allow في execute فقط للتدفقات منخفضة المخاطر؛
  • استخدم require_approval بمجرد أن يخرج محتوى من المشروع أو يعدل نظاما خارجيا؛
  • استخدم deny عندما لا يكون الموصل جاهزا أو مصرحا به أو يكون حساسا جدا؛
  • حافظ على اتساق القواعد مع الأدوار المعينة فعلا؛
  • اختبر دائما حالة حقيقية قبل اعتبار السياسة جاهزة.

أخطاء شائعة يجب تجنبها​

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

الجزء 3 - الإجراءات والموافقات​

تستخدم شاشة الإجراءات والموافقات لتحويل نية إلى إجراء محكوم حقيقي.

أربع قراءات معيارية يجدر تذكرها​

في الواجهة، يمكن فهم هذا السطح بشكل أفضل عبر أربع حالات مميزة:

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

الطلب في حالة approved ليس بعد طلبا في حالة executed.

عندما يكون كل شيء جاهزا بشكل صحيح، ما الذي ينبغي رؤيته؟​

في الحالة الاسمية، يجد المستخدم المخول عادة:

  • نوع إجراء واحدا مناسبا على الأقل؛
  • خيار تنفيذ متوافقا وسليما؛
  • binding مشروع نشطا فعلا؛
  • policy تسمح بالاقتراح أو توجهه إلى الموافقة؛
  • قائمة انتظار تمر فيها الطلبات بعد ذلك عبر pending approval أو approved أو executed أو rejected حسب الحالة.

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

ما يراه المستخدم في هذه الشاشة​

يجد المستخدم عادة:

  • نموذج اقتراح إجراء محكوم؛
  • اختيار نوع الإجراء؛
  • اختيار موصل التنفيذ أو خيار التنفيذ؛
  • ملخص readiness يوضح ما هو متاح أو محظور؛
  • حقولا مثل العنوان، والتبرير، والوجهة، والرسالة، ووصف ticket؛
  • قائمة انتظار الموافقة والتنفيذ مع الطلبات المرسلة سابقا.

الخطوات - إنشاء إجراء محكوم​

الخطوة 1 - فتح الشاشة​

في مساحة العمل، افتح الإجراءات والموافقات.

الخطوة 2 - اختيار نوع الإجراء​

حدد أولا نية الأعمال. تتضمن أنواع الإجراءات المرئية:

  • Publish artifact to SharePoint؛
  • Send Teams message؛
  • Send Outlook message؛
  • Create Jira ticket؛
  • Create Azure DevOps ticket؛
  • Webhook حسب تكوين tenant.

الخطوة 3 - التحقق من خيار التنفيذ المتوافق​

تبحث الواجهة بعد ذلك عن خيارات التنفيذ المتوافقة.

اختر خيارا:

  • سليما؛
  • مصرحا به؛
  • ومفتوحا فعلا لمشروعك.

إذا لم يظهر أي خيار سليم، فيتعلق الفحص عادة بـ:

  • الموصل نفسه؛
  • حالته الصحية؛
  • binding المشروع؛
  • policy؛
  • أو إذنك.

الخطوة 4 - قراءة readiness​

تساعد منطقة Execution readiness على التحقق من أنك لا تعد إجراء نظريا فقط.

عمليا:

  • available / healthy = خيار قابل للاستخدام؛
  • blocked by health = موصل يجب التحقق منه في المنصة؛
  • blocked by entitlement = wording قديم لعائق غير مرتبط بالخطة؛ تحقق من configuration وbinding وpolicy وpermission وapproval وhealth؛
  • blocked by policy = حوكمة المشروع مقيدة؛
  • blocked by permission = دورك غير كاف؛
  • لا يوجد خيار مرئي = موصل متوافق مفقود، أو binding المشروع مفقود، أو الخيار غير مفتوح لدورك.

قراءة عملية لشاشة تبدو فارغة​

عندما لا تعرض الإجراءات والموافقات أي شيء قابل للتنفيذ، ميز أولا بين ثلاث حالات قبل أن تستنتج أن الميزة لا تعمل:

  1. تعذر تحميل توفر خيارات التنفيذ؛
  2. توجد خيارات متوافقة، لكنها لا تزال محظورة أو غير سليمة؛
  3. لم يتم بعد تكوين أي موصل متوافق لهذا النوع من الإجراءات المحكومة.

في الحالات الثلاث، يختلف هذا عن قائمة انتظار فارغة فقط لأن أحدا لم يقترح أي إجراء بعد.

ما تراهالسبب الغالب المحتملرد الفعل المفيد
لا يوجد موصل قابل للاختيارلا يوجد أي موصل متوافق وسليم جاهزراجع تكاملات المشروع ثم إدارة المنصة
إجراء مرئي لكن الزر محظورإذن غير كاف، أو policy مقيدة، أو موافقة مطلوبةراجع الدور ثم الحوكمة
قائمة انتظار مرئية لكن لا يخرج شيءلا يزال الطلب ينتظر موافقة أو تنفيذا لاحقاأعد قراءة الحالة الفعلية لقائمة الانتظار
موصل موجود لكنه غير قابل للاستخدامbinding مشروع أو health أو configuration أو policy أو permission غير كافيةتحقق من السلسلة الكاملة: المنصة -> المشروع -> السياسة

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

الخطوة 5 - ملء العنوان والتبرير​

أكمل بعد ذلك:

  • عنوانا واضحا؛
  • تبريرا قصيرا لكنه مفيد؛
  • الحقول الخاصة بنوع الإجراء المختار.

يجب أن يجيب التبرير عن سؤالين:

  1. لماذا هذا الإجراء ضروري؟
  2. على أي أدلة أو قرارات يستند؟

الخطوة 6 - إكمال حقول الأعمال​

تتغير الحقول حسب نوع الإجراء.

نوع الإجراءالحقول المطلوبة غالبا
نشر SharePointالعنوان، التبرير، artifact ID، الوجهة، ملف تعريف التصيير، التنسيق
رسالة Teamsالعنوان، التبرير، نص الرسالة
رسالة Outlookالعنوان، التبرير، المستلمون، الموضوع، نص الرسالة
ticket Jiraالعنوان، التبرير، وصف ticket، وربما مفتاح المشروع / اللوحة
ticket Azure DevOpsالعنوان، التبرير، الوصف، نوع ticket حسب الموصل
Webhookالعنوان، التبرير، والبيانات المفيدة للنظام الهدف

الخطوة 7 - اقتراح الإجراء​

بعد إكمال الحقول، أرسل الطلب.

في هذه المرحلة، لا يكون الإجراء قد خرج بالضرورة. قد يدخل أولا إلى قائمة انتظار الموافقة.

الخطوة 8 - مراجعة من الموافق​

إذا كانت السياسة تتطلب require_approval، فيجب أن يراجع الموافق:

  • العنوان؛
  • التبرير؛
  • الموصل المستخدم؛
  • الحمولة أو تفاصيل الأعمال؛
  • الأثر أو المسودة المحتملة المرتبطة.

الخطوة 9 - الموافقة أو الرفض أو التنفيذ​

حسب السياسة ودور الموافق، يمكن أن يكون الطلب:

  • موافقا عليه؛
  • مرفوضا؛
  • ثم منفذا إذا كان كل شيء جاهزا.

الخطوة 10 - التحقق من الأثر النهائي​

بعد التنفيذ، تحقق من:

  • قائمة انتظار الإجراءات؛
  • نشاط المشروع؛
  • Trace ID إذا كان معروضا؛
  • سجل الذكاء الاصطناعي إذا انعكس التدفق هناك؛
  • وجود الأثر أو ticket أو الرسالة في الأداة الهدف.

كيفية قراءة حالات الإجراء​

الحالةما تعنيه
draftلا يزال الطلب تحضيريا
pending approvalالموافقة منتظرة قبل المتابعة الحقيقية
approvedتم قبول الطلب
executedتم إطلاق الإجراء فعلا
rejectedتم رفض الطلب
failedأُطلق الإجراء لكنه لم ينجح
cancelledتم إلغاء الطلب

مثال خطوة بخطوة - نشر أثر إلى SharePoint​

الوضع​

راجع الفريق موجزا أسبوعيا ويريد نشره في SharePoint.

المسار​

  1. افتح الإجراءات والموافقات؛
  2. اختر Publish artifact to SharePoint؛
  3. حدد خيار SharePoint publish سليما؛
  4. املأ عنوان الإجراء؛
  5. أضف تبريرا، مثلا: «نسخة تمت مراجعتها واعتمادها للنشر الأسبوعي»؛
  6. املأ artifact ID؛
  7. اختر وجهة SharePoint؛
  8. اختر ملف تعريف التصيير أو التنسيق إذا طُلب ذلك؛
  9. اقترح الإجراء؛
  10. إذا تطلبت السياسة ذلك، انتظر الموافقة؛
  11. نفذ؛
  12. تحقق من أن الأثر منشور في SharePoint ومتتبع في ProPM Agent.

مثال خطوة بخطوة - إنشاء ticket Jira​

الوضع​

تشير إشارة إلى عائق متكرر له أثر على التخطيط.

المسار​

  1. افتح الإجراءات والموافقات؛
  2. اختر Create Jira ticket؛
  3. حدد موصل Jira متاحا؛
  4. أدخل عنوانا واضحا، مثلا: «عائق المورد في الحزمة الحرجة»؛
  5. أكمل وصف ticket؛
  6. أضف التبرير والأدلة المفيدة؛
  7. اقترح الطلب؛
  8. دع الموافق يراجع إذا كانت السياسة تتطلب require_approval؛
  9. نفذ؛
  10. تحقق بعد ذلك من المرجع الخارجي أو ticket الذي تم إنشاؤه.

مثال خطوة بخطوة - إرسال رسالة Teams أو Outlook​

الوضع​

يجب على المشروع إبلاغ مجموعة داخلية أو راع بأن مراجعة قد اكتملت.

مسار Teams​

  1. اختر Send Teams message؛
  2. حدد موصل Teams المصرح به؛
  3. اكتب رسالة قصيرة ومفهومة؛
  4. أضف التبرير إذا كان التدفق محكوما؛
  5. اقترح، ووافق إذا لزم الأمر، ثم نفذ.

مسار Outlook​

  1. اختر Send Outlook message؛
  2. حدد موصل Outlook؛
  3. املأ المستلمين؛
  4. أكمل الموضوع والنص للرسالة؛
  5. اقترح، ووافق إذا لزم الأمر، ثم نفذ.

الفرق العملي​

  • Teams مناسب لتواصل تعاوني داخلي؛
  • Outlook أنسب لتواصل رسمي وموجه.

مثال خطوة بخطوة - webhook إلى أداة خارجية​

الوضع​

تريد المؤسسة تشغيل تدفق داخلي إلى أداة خاصة بها.

المسار​

  1. اختر نوع الإجراء أو التدفق المرتبط بـ Webhook؛
  2. حدد خيار تنفيذ webhook متوافقا؛
  3. املأ العنوان والتبرير؛
  4. أكمل البيانات المفيدة للنظام الهدف؛
  5. اقترح الطلب؛
  6. وافق إذا تطلبت السياسة ذلك؛
  7. نفذ؛
  8. راقب النتيجة في النظام الهدف وفي تدقيق ProPM Agent.

لماذا قد يكون إجراء مرئيا لكنه غير قابل للتنفيذ​

قد يكون الإجراء مرئيا في الواجهة لكنه يبقى محظورا إذا:

  • لم يكن الموصل المتوافق سليما؛
  • لم يكن لدى المشروع binding الصحيح؛
  • حظرت policy المشروع ذلك المستوى من الإجراء؛
  • لم يسمح دورك بالاقتراح أو التنفيذ؛
  • كانت موافقة ما لا تزال معلقة؛
  • كان الموصل أو binding أو policy أو permission أو approval أو health يحظر التدفق.

ماذا تفعل إذا لم يظهر أي خيار تنفيذ​

اتبع هذا الترتيب:

  1. تحقق أولا من سياسات الحوكمة؛
  2. تحقق بعد ذلك من تكاملات المشروع؛
  3. افتح بعد ذلك إدارة المنصة؛
  4. راقب أخيرا configuration وbinding وpermission وحالة health للموصل.

سيناريو كامل - من الإشارة إلى الإجراء المنفذ​

حالة بسيطة​

  1. تشير إشارة open إلى عائق؛
  2. يقرأ الفريق الملخص والتفسير والأدلة؛
  3. يقرر أن هناك حاجة إلى ticket Jira؛
  4. تسمح السياسة لـ مدير المشروع بأن يقوم بـ propose لكنها تتطلب require_approval؛
  5. ينشئ مدير المشروع الطلب في الإجراءات والموافقات؛
  6. يوافق مالك المشروع؛
  7. ينتقل الإجراء إلى executed؛
  8. يبقى ticket الخارجي والأثر الداخلي متوافقين.

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

ممارسات جيدة​

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

التالي​