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

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

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

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


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


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

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

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

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

---

## النطاق والتسليمات

### الغرض والصلاحية

[ أضف التفاصيل... ]

---

### نطاق العمل

[ أضف التفاصيل... ]

---

### مدة الأداء

[ أضف التفاصيل... ]

---

### التسليمات والجدول الزمني

[ أضف التفاصيل... ]

---

### المعايير المطبقة

[ أضف التفاصيل... ]

---

### معايير القبول

[ أضف التفاصيل... ]

---

## الشروط والحوكمة

### الأدوار والمسؤوليات

[ أضف التفاصيل... ]

---

### الافتراضات والاعتماديات

[ أضف التفاصيل... ]

---

### إدارة التغيير

[ أضف التفاصيل... ]

---

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

| الدور | الاسم | التوقيع | التاريخ |
| ---: | ---: | ---: | ---: |
| **مدير المشتريات** | {{اسم_مدير_المشتريات}} | _______________________ | [.... -.... -.... ] |
| **القائد الفني / مدير المشروع** | {{اسم_مدير_المشروع}} | _______________________ | [.... -.... -.... ] |
| **ممثل المورد / المقاول** | {{اسم_ممثل_المورد}} | _______________________ | [.... -.... -.... ] |
---

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

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://tasleemat.pmo/schemas/completed/PMO-04.09.04.schema.json",
  "title": "Completed Statement of Work Data Contract",
  "description": "Additive structural schema validating completed Statement of Work artifact data payloads (PMO-04.09.04).",
  "type": "object",
  "properties": {
    "artifact_id": {
      "type": "string",
      "const": "PMO-04.09.04"
    },
    "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"
      ]
    },
    "scope_and_deliverables": {
      "type": "object",
      "properties": {
        "purpose_and_authority": {
          "type": "string",
          "minLength": 1,
          "description": "What this statement of work is authorised to do, and by whom. The authority clause is the one that settles a dispute about whether something was in scope: it names the instrument that created the obligation - the contract, the charter, the minute that approved it - so that a later reader can tell an agreed obligation from a good suggestion."
        },
        "scope_of_work": {
          "type": "string",
          "minLength": 1,
          "description": "The work to be performed, described so that both parties would recognise the same work from this description alone. Boundaries are part of the description: what is explicitly excluded matters as much as what is included, because an omission read as an inclusion is the most common way a statement of work is argued about after the fact."
        },
        "period_of_performance": {
          "type": "string",
          "minLength": 1,
          "description": "The start and end dates, with any phases or extensions written in rather than left to a separate schedule. The end date is the one that carries the obligation, because it determines when acceptance becomes due and therefore when payment may fall due with it."
        },
        "deliverables_and_schedule": {
          "type": "string",
          "minLength": 1,
          "description": "What will be handed over and by when, milestone by milestone rather than as a single lump. A deliverable without a date attached to it is a topic rather than an obligation, and it is the absence of dates that lets a period of performance run past its end without anybody having to decide anything."
        },
        "applicable_standards": {
          "type": "string",
          "minLength": 1,
          "description": "The technical, quality and regulatory requirements the deliverables must satisfy, named so that conformance can be tested rather than asserted. \"Best practice\" is not a standard, because there is no test that fails it; a named standard either passes or does not."
        },
        "acceptance_criteria": {
          "type": "string",
          "minLength": 1,
          "description": "How the buyer will decide that each deliverable is accepted, who decides it, and how long they have to decide. An acceptance clause that omits the rejection route accepts the deliverable by default on silence, which removes the only leverage a buyer has over a supplier who has already been paid to try."
        }
      },
      "required": [
        "purpose_and_authority",
        "scope_of_work",
        "period_of_performance",
        "deliverables_and_schedule",
        "applicable_standards",
        "acceptance_criteria"
      ]
    },
    "terms_and_governance": {
      "type": "object",
      "properties": {
        "roles_and_responsibilities": {
          "type": "string",
          "minLength": 1,
          "description": "Who is accountable for each part of the work on each side, named by role rather than by person so the document survives a change of staff. The line that matters is the boundary of authority: who may approve a delivery, who may commit additional effort, and who may not do either without going back to the contract."
        },
        "assumptions_and_dependencies": {
          "type": "string",
          "minLength": 1,
          "description": "What both parties are taking to be true, and what the work depends on that is not under the supplier's control - access, data, decisions from third parties. This is the section that determines who carries the schedule when an assumption turns out to be false, and leaving it out converts a dependency problem into a dispute."
        },
        "change_control": {
          "type": "string",
          "minLength": 1,
          "description": "How a change to the scope, the deliverables or the dates gets into the statement of work, who approves it, and what happens to the price and the dates when it does. A change route that is described but not named is not a control: without an approver and a form, the first change of scope becomes a conversation, and the second one becomes the dispute."
        }
      },
      "required": [
        "roles_and_responsibilities",
        "assumptions_and_dependencies",
        "change_control"
      ]
    }
  },
  "required": [
    "artifact_id",
    "metadata",
    "scope_and_deliverables",
    "terms_and_governance"
  ]
}

{
  "form_name": "Statement of Work",
  "document_reference": "PMO-04.09.04",
  "_llm_instructions": "Populate the fields of 'Statement of Work' and write the value of each field under 'Generated Value', based on the project context. Context: the project carrying reference PMO-04.09.04.",
  "fields": {
    "f01_Purpose_and_Authority": {
      "section": "Scope and Deliverables",
      "label": "Purpose and Authority",
      "guidance": "What this statement of work is authorised to do, and by whom. The authority clause is the one that settles a dispute about whether something was in scope: it names the instrument that created the obligation - the contract, the charter, the minute that approved it - so that a later reader can tell an agreed obligation from a good suggestion.",
      "value": ""
    },
    "f02_Scope_of_Work": {
      "section": "Scope and Deliverables",
      "label": "Scope of Work",
      "guidance": "The work to be performed, described so that both parties would recognise the same work from this description alone. Boundaries are part of the description: what is explicitly excluded matters as much as what is included, because an omission read as an inclusion is the most common way a statement of work is argued about after the fact.",
      "value": ""
    },
    "f03_Period_of_Performance": {
      "section": "Scope and Deliverables",
      "label": "Period of Performance",
      "guidance": "The start and end dates, with any phases or extensions written in rather than left to a separate schedule. The end date is the one that carries the obligation, because it determines when acceptance becomes due and therefore when payment may fall due with it.",
      "value": ""
    },
    "f04_Deliverables_and_Schedule": {
      "section": "Scope and Deliverables",
      "label": "Deliverables and Schedule",
      "guidance": "What will be handed over and by when, milestone by milestone rather than as a single lump. A deliverable without a date attached to it is a topic rather than an obligation, and it is the absence of dates that lets a period of performance run past its end without anybody having to decide anything.",
      "value": ""
    },
    "f05_Applicable_Standards": {
      "section": "Scope and Deliverables",
      "label": "Applicable Standards",
      "guidance": "The technical, quality and regulatory requirements the deliverables must satisfy, named so that conformance can be tested rather than asserted. \"Best practice\" is not a standard, because there is no test that fails it; a named standard either passes or does not.",
      "value": ""
    },
    "f06_Acceptance_Criteria": {
      "section": "Scope and Deliverables",
      "label": "Acceptance Criteria",
      "guidance": "How the buyer will decide that each deliverable is accepted, who decides it, and how long they have to decide. An acceptance clause that omits the rejection route accepts the deliverable by default on silence, which removes the only leverage a buyer has over a supplier who has already been paid to try.",
      "value": ""
    },
    "f07_Roles_and_Responsibilities": {
      "section": "Terms and Governance",
      "label": "Roles and Responsibilities",
      "guidance": "Who is accountable for each part of the work on each side, named by role rather than by person so the document survives a change of staff. The line that matters is the boundary of authority: who may approve a delivery, who may commit additional effort, and who may not do either without going back to the contract.",
      "value": ""
    },
    "f08_Assumptions_and_Dependencies": {
      "section": "Terms and Governance",
      "label": "Assumptions and Dependencies",
      "guidance": "What both parties are taking to be true, and what the work depends on that is not under the supplier's control - access, data, decisions from third parties. This is the section that determines who carries the schedule when an assumption turns out to be false, and leaving it out converts a dependency problem into a dispute.",
      "value": ""
    },
    "f09_Change_Control": {
      "section": "Terms and Governance",
      "label": "Change Control",
      "guidance": "How a change to the scope, the deliverables or the dates gets into the statement of work, who approves it, and what happens to the price and the dates when it does. A change route that is described but not named is not a control: without an approver and a form, the first change of scope becomes a conversation, and the second one becomes the dispute.",
      "value": ""
    }
  }
}