CIPS L4M2: إزاي تحدد احتياج البيزنس وتمنع الـ Specification الغلط؟

في Procurement، فيه موقف بيتكرر كتير:

الشركة تطلب منتج أو خدمة من مورد.

المورد يسلّم في الميعاد.

المستندات سليمة.

الفاتورة مطابقة.

والبضاعة “زي ما اتطلبت”.

لكن أول ما المنتج يدخل الاستخدام، تبدأ المشكلة.

القسم المستخدم يقول:

“دي مش الحاجة اللي إحنا محتاجينها.”

Procurement يرد:

“إحنا اشترينا بناءً على الطلب اللي وصلنا.”

والمورد يقول:

“أنا سلمت طبقًا للـ Specification.”

في الحالة دي، المورد ممكن يكون فعلًا نفّذ المطلوب بشكل صحيح من الناحية الورقية.

لكن المشكلة إن المطلوب نفسه ما كانش بيعبر بدقة عن احتياج البيزنس الحقيقي.

وده يوضح ليه Defining Business Need من أهم المراحل في Procurement.

قبل ما تطلب Quotation، أو تعمل Tender، أو تبدأ تفاوض مع المورد، لازم تكون فاهم:

• إحنا محتاجين نحقق إيه؟
• مين المستخدم النهائي؟
• إيه النتيجة المطلوبة؟
• إيه المواصفات الضرورية؟
• إيه المواصفات اللي تعتبر Preference فقط؟
• هل الأفضل نستخدم Technical Specification ولا Performance Specification؟
• وإزاي هنعرف إن المورد سلّم حاجة مناسبة فعلًا؟

وده بالضبط من الموضوعات الأساسية في CIPS L4M2 – Defining Business Need ضمن CIPS Level 4.

لأن الشراء الصح مش بيبدأ بطلب السعر.

الشراء الصح بيبدأ بتعريف الاحتياج بشكل واضح.

ابدأ دراسة CIPS بنظام Self Study من TASK

يعني إيه Defining Business Need؟

Defining Business Need معناه إنك ما تبدأش من سؤال:

“إحنا عايزين نشتري إيه؟”

لكن تبدأ من سؤال أعمق:

“إحنا عايزين نحقق إيه؟”

في فرق كبير بين السؤالين.

لما تبدأ باسم المنتج، ممكن تقفل تفكيرك على حل معين من البداية.

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

مثلًا، بدل ما تقول:

“عايزين نشتري جهاز بمواصفات معينة.”

اسأل:

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

الهدف من Defining Business Need مش إنك تكتب طلب شراء طويل.

الهدف إنك تكتب طلب صحيح، قابل للفهم، وقابل للتقييم والتنفيذ.

ليه تحديد احتياج البيزنس مهم؟

لأن أي خطأ في تعريف الاحتياج بيتنقل لباقي مراحل الشراء.

لو الاحتياج غلط، الـ Specification هتكون غلط.

ولو الـ Specification غلط، الموردين هيقدموا عروض مبنية على فهم غير دقيق.

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

وده يؤدي إلى:

• Waste.
• Rework.
• Delays.
• Supplier Disputes.
• تكلفة إضافية.
• أو توقف في التشغيل.

يعني مشكلة صغيرة في أول العملية ممكن تتحول لخسارة كبيرة بعد التوريد.

مين لازم يشارك في تحديد الاحتياج؟

Procurement ما ينفعش يحدد الاحتياج لوحده.

لازم يشارك الأطراف اللي عندها معرفة فعلية بالاستخدام.

حسب طبيعة الطلب، ممكن تحتاج مشاركة:

• End Users.
• Operations.
• Maintenance.
• Quality.
• Engineering.
• Finance.
• IT.
• Health and Safety.
• أو Management.

Procurement دوره إنه ينظم العملية، ويسأل الأسئلة الصح، ويتأكد إن الاحتياج متحول لمواصفات قابلة للشراء.

أما المستخدم النهائي، فهو اللي يعرف:

• المشكلة الحالية.
• ظروف الاستخدام.
• مستوى الأداء المطلوب.
• والمشاكل اللي لازم الحل يتجنبها.

لو أحد الطرفين اشتغل لوحده، فرص الخطأ بتزيد.

الفرق بين Business Need وUser Request

مش كل طلب يوصلك من المستخدم يعتبر Business Need مكتمل.

ممكن المستخدم يقول:

“عايزين نشتري نفس الموديل القديم.”

لكن Procurement المحترف يسأل:

• ليه نفس الموديل؟
• هل لسه مناسب؟
• هل السوق فيه بدائل أحدث؟
• هل الاستخدام اتغير؟
• هل المشكلة في الجهاز نفسه ولا في Process؟
• وهل الشركة فعلًا محتاجة شراء جديد؟

الـ User Request هو اللي القسم طلبه.

أما الـ Business Need فهو النتيجة الحقيقية اللي الشركة محتاجة تحققها.

ممكن الاتنين يكونوا نفس الحاجة، وممكن يكون بينهم فرق كبير.

يعني إيه Specification؟

الـ Specification هي الوصف اللي بيحدد للمورد المطلوب منه.

المواصفة ممكن توضح:

• الخصائص.
• الأداء.
• الجودة.
• الأبعاد.
• الخامات.
• طريقة الاستخدام.
• معايير القبول.
• الاختبارات.
• التسليم.
• أو أي Requirement أساسي.

المورد هيبني عرضه وتسعيره وتنفيذه على المواصفة اللي استلمها.

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

الفرق بين Technical Specification وPerformance Specification

من أهم النقاط في CIPS L4M2 فهم الفرق بين:

• Technical Specifications.
• Performance Specifications.

Technical Specification

الـ Technical Specification بتحدد التفاصيل الفنية الدقيقة للمنتج أو الخدمة.

ممكن تشمل:

• الخامة.
• المقاس.
• الأبعاد.
• القدرة.
• السرعة.
• المكونات.
• طريقة التصنيع.
• المعيار الفني.
• أو Model معين.

مثلًا:

• Motor بقدرة معينة.
• Stainless Steel بدرجة محددة.
• أبعاد دقيقة.
• أو Software لازم يتوافق مع نظام معين.

النوع ده مناسب لما التفاصيل الفنية ضرورية جدًا.

زي الحالات اللي فيها:

• Safety Requirements.
• Compatibility.
• Engineering Constraints.
• أو Standards إلزامية.

مميزات Technical Specifications

بتساعد في:

• تحديد المطلوب بدقة.
• تقليل الاختلاف في التفسير.
• ضمان التوافق.
• وتسهيل مقارنة العروض لو كل الموردين بيقدموا نفس الحل.

مخاطر Technical Specifications

لو المواصفات الفنية زادت عن اللزوم، ممكن:

• تقفل المنافسة.
• توجه الطلب لمورد معين.
• تمنع حلول أفضل.
• ترفع التكلفة.
• أو تكرر Design قديم لمجرد إنه مستخدم قبل كده.

يعني الدقة مهمة، لكن Over-Specification ممكن تضر الشركة.

Performance Specification

الـ Performance Specification بتركز على النتيجة المطلوبة، مش الطريقة اللي المورد هيحققها بيها.

بدل ما تقول للمورد:

“نفذ الحل بالمكونات والطريقة دي.”

بتقوله:

“الحل لازم يحقق مستوى الأداء ده.”

مثلًا:

• المعدة تنتج عدد معين في الساعة.
• النظام يخدم عدد محدد من المستخدمين.
• الخدمة تحقق Response Time معين.
• المنتج يتحمل ظروف تشغيل محددة.
• أو الحل يقلل وقت العملية بنسبة معينة.

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

مميزات Performance Specifications

بتساعد في:

• تشجيع Innovation.
• زيادة المنافسة.
• الاستفادة من خبرة المورد.
• التركيز على النتيجة.
• وتقييم القيمة بدل الشكل فقط.

مخاطر Performance Specifications

لو معايير الأداء مش واضحة، ممكن المورد يقدم حل أقل من المتوقع.

عشان كده لازم Performance Specification يكون فيها:

• Performance Measures.
• Testing Method.
• Acceptance Criteria.
• Operating Conditions.
• وحدود واضحة للنتيجة المطلوبة.

إمتى تستخدم Technical Specs؟

استخدم Technical Specifications لما:

• التفاصيل الفنية ضرورية.
• التوافق مع نظام موجود مهم.
• فيه Standard لازم يتطبق.
• الفشل الفني يعمل Risk كبير.
• أو المستخدم النهائي عارف المتطلبات بشكل دقيق.

مثلًا، Spare Part لازم يكون متوافق تمامًا مع Equipment موجودة.

هنا ما ينفعش تسيب كل التفاصيل مفتوحة.

إمتى تستخدم Performance Specs؟

استخدم Performance Specifications لما:

• الأهم هو النتيجة.
• السوق فيه حلول مختلفة.
• عايز تشجع الموردين يقدموا Innovation.
• مش فارق معاك طريقة التنفيذ طالما الأداء متحقق.
• أو عايز تستفيد من خبرة المورد الفنية.

وفي حالات كتير، الأفضل يكون عندك Hybrid Specification:

جزء Technical للمتطلبات الإلزامية.

وجزء Performance للنتيجة والأداء المطلوب.

يعني إيه Functional Requirements؟

الـ Functional Requirements بتوضح الوظائف اللي المنتج أو النظام لازم يعملها.

مثلًا، في Software:

• النظام يستقبل Orders.
• يطلع Reports.
• يسمح بمستويات صلاحيات مختلفة.
• يرسل Notifications.
• ويرتبط بنظام تاني.

هي مش بالضرورة بتقول النظام يتبني إزاي.

لكن بتقول لازم يعمل إيه.

وده مهم جدًا في شراء Services أو Systems أو Technology Solutions.

يعني إيه Acceptance Criteria؟

Acceptance Criteria هي المعايير اللي الشركة هتستخدمها عشان تقرر إن التوريد مقبول.

يعني بعد ما المورد يسلّم، هنختبر إيه؟

لازم تحدد:

• مين مسؤول عن القبول؟
• إيه الاختبارات المطلوبة؟
• إيه مستوى الجودة المقبول؟
• إيه المستندات المطلوبة؟
• هل فيه Trial Period؟
• هل فيه Performance Test؟
• وإيه اللي يحصل لو النتيجة غير مطابقة؟

من غير Acceptance Criteria، ممكن يحصل خلاف:

المورد يقول إنه سلّم.

والشركة تقول إن المنتج غير مناسب.

لكن مفيش معيار واضح يحكم بينهم.

إزاي Specification الغلط تسبب هالك؟

Specification الغلط ممكن تسبب أكتر من نوع خسارة.

1. شراء منتج غير مناسب

المنتج يكون مطابق للمكتوب، لكنه مش مناسب للتشغيل الفعلي.

ساعتها الشركة ممكن:

• تخزنه.
• ترفضه.
• تستخدمه جزئيًا.
• أو تشتري بديل.

2. Rework

ممكن الشركة تضطر تعدل المنتج أو تعيد تصنيعه أو تجهيزه.

وده يستهلك:

• وقت.
• عمالة.
• تكلفة.
• ويأخر الاستخدام.

3. توقف التشغيل

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

4. خلاف مع المورد

المورد يتمسك بالمواصفة.

والشركة تتمسك بالاحتياج الفعلي.

لو المواصفة غير واضحة، حل النزاع بيكون أصعب.

5. شراء مرتين

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

يعني تكلفة مضاعفة بسبب خطأ في البداية.

أشهر أسباب المواصفات الغلط

المواصفات ممكن تطلع غلط لأسباب كتير، منها:

• الطلب جاي في سطر واحد من المستخدم.
• نسخ Specification قديمة.
• عدم إشراك End User.
• الاعتماد على مورد في كتابة المواصفة.
• عدم تحديد Acceptance Criteria.
• خلط Must-Have مع Nice-to-Have.
• استخدام كلمات عامة.
• أو التركيز على المنتج بدل النتيجة.

خطر نسخ Specification قديمة

من السهل إن الشركة تستخدم مواصفات طلب قديم.

لكن المشكلة إن:

• السوق اتغير.
• Technology اتطورت.
• احتياج التشغيل اتغير.
• المنتج القديم ممكن يكون بقى Outdated.
• أو المواصفة القديمة أصلًا كان فيها مشاكل.

عشان كده أي Specification لازم تتراجع، مش تتنسخ تلقائيًا.

خطر إن المورد يكتب المواصفات

ممكن المورد يساعد بمعلومات فنية، وده طبيعي.

لكن الاعتماد الكامل عليه في كتابة المواصفة ممكن يسبب Bias.

حتى لو المورد مش متعمد، طبيعي يكتب مواصفات قريبة من الحل اللي هو بيبيعه.

عشان كده لازم الشركة:

• تجمع معلومات من أكتر من مصدر.
• تعمل Market Research.
• وتراجع هل المواصفة عادلة ومفتوحة للمنافسة.

Must-Have ولا Nice-to-Have؟

واحدة من أهم الخطوات إنك تفرق بين:

Must-Have

Requirement أساسي، من غيره المنتج أو الخدمة مش هتكون مناسبة.

Nice-to-Have

ميزة مفيدة، لكن مش ضرورية لتحقيق الاحتياج.

لو الشركة حولت كل Nice-to-Have لـ Mandatory Requirement، السعر هيزيد والمنافسة هتقل.

لازم كل شرط إلزامي يكون له سبب Business واضح.

دور Market Research قبل كتابة المواصفات

قبل ما تكتب Specification نهائية، مهم تفهم السوق.

Market Research يساعدك تعرف:

• إيه الحلول الموجودة؟
• إيه المواصفات القياسية؟
• إيه Technology الجديدة؟
• إيه الموردين القادرين؟
• إيه متوسط الأسعار؟
• وهل الطلب واقعي؟

ممكن تكتشف إن السوق عنده حل أفضل من اللي الشركة كانت متخيلاه.

دور Procurement في مراجعة الطلب

Procurement مش دوره ياخد Requisition وينفذه من غير أسئلة.

لو الطلب غير واضح، لازم يسأل:

• إيه الغرض؟
• مين المستخدم؟
• هل المواصفات قابلة للقياس؟
• هل فيه بدائل؟
• هل الشروط هتقلل المنافسة؟
• هل Budget واقعي؟
• وهل Acceptance Criteria واضحة؟

الأسئلة دي مش تعطيل.

هي جزء من Professional Procurement.

دور CIPS L4M2 في تطوير Procurement Professional

موديول L4M2 Defining Business Need ضمن CIPS Level 4 بيركز على مرحلة أساسية قبل الـ Sourcing والتعاقد.

الموديول بيساعدك تفهم:

• إزاي الاحتياج بيتحدد.
• إزاي Stakeholders يشاركوا.
• إزاي تكتب Requirements.
• الفرق بين أنواع Specifications.
• إزاي تمنع Over-Specification.
• وإزاي تربط الاحتياج بالتقييم والتوريد.

الفكرة مش إنك تحفظ تعريفات فقط.

الفكرة إنك تعرف تمنع المشكلة قبل ما تتحول لـ Purchase Order أو Contract.

مين أكتر ناس تستفيد من L4M2؟

الموديول مهم جدًا لو أنت شغال في:

• Procurement.
• Purchasing.
• Strategic Sourcing.
• Tendering.
• Contracting.
• Category Management.
• Supplier Management.
• أو Project Procurement.

ومفيد كمان للناس اللي بتستلم طلبات من الأقسام وبتحولها لمناقصات أو RFQs.

مثال عملي: شراء معدة إنتاج

افترض إن الشركة عايزة تشتري Production Machine.

لو المستخدم كتب:

“عايزين نفس Model القديم.”

الشركة ممكن تشتري معدة قديمة في Technology أو غير مناسبة لحجم الإنتاج الجديد.

لكن لو بدأت من Business Need، هتراجع:

• Production Rate المطلوب.
• نوع المنتج.
• مساحة التشغيل.
• استهلاك الطاقة.
• Safety.
• Maintenance Requirements.
• Spare Parts.
• Integration مع الخط الحالي.
• وAcceptance Test.

بعدها تقدر تكتب Specification تجمع بين Technical وPerformance Requirements.

مثال عملي: شراء خدمة تنظيف

لو الشركة كتبت:

“مطلوب 5 عمال نظافة.”

فهي حددت الوسيلة.

لكن هل الاحتياج الحقيقي هو عدد العمال؟

ولا الحفاظ على مستوى نظافة معين؟

Performance Specification ممكن تقول:

“الحفاظ على مستوى نظافة محدد في المناطق المطلوبة خلال ساعات التشغيل، وفق Inspection Checklist وService Levels واضحة.”

المورد هنا ممكن يقترح:

• عدد عمال مختلف.
• معدات أحسن.
• أو Process أكثر كفاءة.

الشركة اشترت النتيجة، مش مجرد Headcount.

مثال عملي: شراء Software

كتير من شركات بتطلب Software وتكتب قائمة Features طويلة جدًا.

لكن ما تحددش:

• المستخدمين.
• الـ Workflow.
• Integration.
• حجم البيانات.
• Security.
• Reporting.
• أو Performance.

النتيجة ممكن تكون System فيه Features كتير، لكنه مش مناسب لطريقة العمل.

الأفضل تبدأ بـ:

• Business Processes.
• User Requirements.
• Functional Requirements.
• Performance Requirements.
• Security Requirements.
• وAcceptance Testing.

إزاي تكتب Specification أفضل؟

1. ابدأ بالمشكلة

اكتب بوضوح إيه المشكلة اللي الطلب هيحلها.

2. حدد المستخدمين

مين هيستخدم المنتج أو الخدمة؟

3. حدد Operating Conditions

فين وإزاي المنتج هيستخدم؟

4. فرق بين Requirements

قسمها إلى:

• Mandatory.
• Desirable.
• Optional.

5. استخدم لغة قابلة للقياس

بدل:

“جودة عالية.”

اكتب معيار أو Test أو Performance Level واضح.

6. حدد Acceptance Criteria

اكتب من البداية إزاي الاستلام والقبول هيتموا.

7. راجع المخاطر

إيه اللي يحصل لو المنتج فشل؟

هل فيه Safety أو Business Continuity Risk؟

8. راجع Total Cost of Ownership

ما تبصش لسعر الشراء بس.

راجع:

• التشغيل.
• الصيانة.
• الطاقة.
• التدريب.
• قطع الغيار.
• العمر الافتراضي.
• والتخلص النهائي.

9. اعمل Review مع Stakeholders

قبل إرسال الطلب للموردين، اعمل مراجعة نهائية مع الأطراف المعنية.

10. اختبر وضوح المواصفة

اسأل:

هل أكتر من مورد ممكن يفهم المطلوب بنفس الطريقة؟

لو الإجابة لأ، يبقى المواصفة محتاجة تعديل.

دور المواصفات في تقييم الموردين

لو الـ Specification واضحة، تقييم الموردين بيكون أسهل وأعدل.

تقدر تبني Evaluation Criteria على:

• Compliance.
• Performance.
• Quality.
• Cost.
• Delivery.
• Support.
• Risk.
• وTotal Value.

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

المواصفات وعلاقتها بالعقد

الـ Specification غالبًا بتكون جزء من Contract Documents.

يعني أي غموض فيها ممكن يتحول بعدين لمشكلة تعاقدية.

عشان كده لازم يكون فيه توافق بين:

• Scope.
• Specification.
• Deliverables.
• Acceptance Criteria.
• Payment.
• Warranty.
• وChange Control.

يعني إيه Case-style Questions في CIPS؟

امتحانات CIPS مش كلها حفظ مباشر.

في أسئلة بتحتاج تطبق المفهوم على Scenario أو Case.

يعني بدل ما السؤال يسألك تعريف Technical Specification فقط، ممكن يديك حالة شركة عندها منتج غير مناسب ويطلب منك تحلل السبب أو تقترح طريقة أفضل لتحديد الاحتياج.

عشان كده التدريب على Case-style Questions مهم.

أهمية Practice Questions

Practice Questions تساعدك:

• تفهم شكل الامتحان.
• تراجع المفاهيم.
• تتدرب على تحليل السيناريو.
• تعرف نقاط ضعفك.
• وتحسن Exam Technique.

المهم ما تحفظش الإجابة فقط.

راجع ليه الإجابة صح، وليه الاختيارات التانية غلط.

دراسة CIPS Module by Module

من خلال TASK Self Study، تقدر تدرس CIPS Module منفصل أو الدبلومة كاملة.

دراسة Module منفصل ممكن تكون مناسبة لو:

• بتحضر لامتحان معين.
• محتاج تقوي موضوع محدد.
• درست قبل كده وعايز مراجعة.
• أو جدولك ما يسمحش تبدأ الدبلومة كلها مرة واحدة.

أما الدبلومة الكاملة، فمناسبة لو عايز Career Path متكامل في Procurement and Supply.

دراسة CIPS بنظام Self Study

نظام Self Study بيديك مرونة تذاكر حسب وقتك.

ومسارات Exam Preparation تساعدك تركز على:

• Practice Questions.
• Case-style Questions.
• Exam Techniques.
• ومراجعة المفاهيم.

ابدأ CIPS Level 4 Self Study من TASK

خطوات تبدأ بيها من بكرة

1. راجع آخر 5 Purchase Requisitions.
2. شوف هل الاحتياج مكتوب بوضوح ولا مجرد اسم منتج.
3. حدد End User لكل طلب.
4. راجع Must-Have وNice-to-Have.
5. تأكد إن Acceptance Criteria موجودة.
6. راجع هل المواصفات Technical زيادة عن اللزوم.
7. اعمل Market Research قبل التثبيت النهائي.
8. اشرك Quality أو Operations حسب الحاجة.
9. راجع Total Cost of Ownership.
10. اعمل Lessons Learned من أي شراء فشل قبل كده.

أخطاء شائعة في Defining Business Need

البدء بالمنتج بدل الاحتياج

ده ممكن يقفل الباب على حلول أحسن.

اعتبار طلب المستخدم مواصفة نهائية

الطلب الأولي محتاج Clarification ومراجعة.

نسخ مواصفات قديمة

الاحتياج والسوق بيتغيروا.

استخدام كلمات غير قابلة للقياس

زي “أفضل جودة” أو “مناسب”.

عدم تحديد القبول

وده يخلق نزاع وقت التسليم.

Over-Specification

بتقلل المنافسة وبتزود السعر.

Under-Specification

بتخلي المورد يقدم أقل مستوى ممكن.

تجاهل Total Cost of Ownership

ممكن تشتري الأرخص وتدفع أكتر بعدين.

الخلاصة: الشراء الصح يبدأ قبل طلب السعر

المورد اللي سلّم “زي ما طلبت” ممكن يكون نفذ المطلوب فعلًا.

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

عشان كده Defining Business Need خطوة أساسية في Procurement.

لازم:

• تفهم الاحتياج الحقيقي.
• تشرك المستخدم النهائي.
• تفرق بين Technical وPerformance Specifications.
• تحدد Acceptance Criteria.
• تراجع Total Cost of Ownership.
• وتتأكد إن المواصفات واضحة وعادلة.

موديول CIPS L4M2 بيساعدك تبني المهارة دي بشكل منهجي، وتمنع الهالك والمشاكل قبل ما تبدأ.

لأن الـ Procurement المحترف مش بس بيشتري اللي اتكتب.

هو بيتأكد إن اللي اتكتب هو فعلًا اللي البيزنس محتاجه.

ابدأ دراسة CIPS بنظام Self Study من TASK