مؤشر الأداء قياس مختار لمتابعة هدف. لا يشخص الرقم سبباً ولا يثبت قيمة تجارية أو أمناً.
كتابة اتفاق للقياس
وثق الهدف والصيغة والوحدة والبسط والمقام والجمهور والفترة. حدد المسؤول والقرار المقصود. تكلفة العميل المحتمل ليست تكلفة عميل جديد؛ وضح المصروفات وتعريف النتيجة في النسبة.
فحص التغير قبل التصرف
تحقق من التغطية والتكرار وتأخر الإتاحة وتغير التعريفات. متوسط النسب ليس بالضرورة النسبة الإجمالية؛ استخدم الأعداد المقابلة. يستدعي الحد تحقيقاً ولا يقدم تفسيراً تلقائياً. لا تضمن الأداة جودة الجمع.
| النقطة | ما يجب توثيقه |
|---|---|
| التعريف | صيغة ووحدة ونطاق مكتوب |
| الجودة | فحص التغطية والتكرار والإتاحة |
| القرار | مسؤول وإجراء وحدود واضحة |
المصادر والتحقق
ربط كل مؤشر أداء رئيسي بعقد وقرار.
يحدد المقياس المفيد الإجراء الذي يجب أن يبرره التغيير. قبل تحديد هدف، وثّق الصيغة، والبيانات، والمصدر، والشروط التي تجعل الرقم غير مكتمل. يمكن للوحة المعلومات أن تتبع تعريفها بشكل صحيح، ولكنها قد تفشل في الإجابة على سؤال العمل عندما تختلف الوحدة أو النطاق.
- كتابة البسط والمقام والاستثناءات.
- التحقق من حالة معروفة من الحدث إلى الرسم البياني.
- عرض آخر تحديث والفترات غير المكتملة.
المصدر الأساسي: Google SRE — Data Processing Pipelines. المنهج المرتبط: اقرأ الدليل العملي.
تحديد سياق مؤشر الأداء الرئيسي.
يحتاج مؤشر الأداء الرئيسي المئوي إلى وحدات وعدد وفترة. وإلا فقد تمثل القيم المتطابقة أحجامًا ومستويات عدم يقين مختلفة تمامًا.
- نشر البسط والمقام بجانب النسبة.
- وثّق عمليات الجمع الجزئي والبيانات المفقودة قبل التفسير.
المصدر الأساسي: NIST/SEMATECH — Confidence intervals for proportions. المنهج المرتبط: اقرأ الدليل العملي.
سلامة ربط البيانات
قد يضاعف الربط الصفوف ويشوّه المجاميع.
- يمثل صف الطلبات طلباً، ويمثل صف البنود منتجاً في ذلك الطلب. افحص المفاتيح المكررة والفارغة قبل دمج الجداول.
- جمّع البنود حسب معرّف الطلب. يمنع الربط بهذه النتيجة تكرار مبلغ الطلب لكل منتج. قارن المجموع بجدول الطلبات الأصلي.
- يحافظ LEFT JOIN على الطلبات بلا بنود، لكن شرط WHERE على الجدول الأيمن قد يحذفها. غياب المطابقة لا يعني مبلغاً صفرياً.
حالة قبول قابلة للتكرار
مثال افتراضي: البيانات لا تصف عميلاً أو نتيجة مرصودة.
عرض بيانات الحالة
{
"orders": [
{
"id": 1,
"total": 100
},
{
"id": 2,
"total": 200
}
],
"line_order_ids": [
1,
1,
2
],
"sum_before": 300,
"sum_after_raw_join": 400
}القرار المتوقع
المجموع 400 يحتسب طلباً مرتين. جمّع البنود حسب الطلب لاستعادة 300. اختبر أيضاً طلبين افتراضيين بقيمة 100 لكل منهما؛ المجموع 200. تعيد SUM(DISTINCT total) القيمة 100 فتحذف قيمة صحيحة. افحص المعرّفات وتعدد علاقات الربط بدلاً من إزالة المبالغ المتكررة.
استعلامات SQL قابلة لإعادة التنفيذ
مثال افتراضي: طلبان بمبلغي 100 و200 وثلاثة بنود للطلبات 1 و1 و2. تستخدم الاستعلامات VALUES فقط؛ نفّذها في بيئة اختبار.
WITH orders(id, total) AS (VALUES (1, 100), (2, 200)),
lines(order_id) AS (VALUES (1), (1), (2))
SELECT COUNT(*) AS rows, SUM(o.total) AS total
FROM orders o JOIN lines l ON l.order_id = o.id;WITH orders(id, total) AS (VALUES (1, 100), (2, 200)),
lines(order_id) AS (VALUES (1), (1), (2)),
per_order AS (
SELECT order_id, COUNT(*) AS line_count
FROM lines GROUP BY order_id
)
SELECT COUNT(*) AS orders, SUM(o.total) AS total
FROM orders o LEFT JOIN per_order l ON l.order_id = o.id;ينتج الربط المباشر ثلاثة صفوف ومجموعاً 400. يعيد التجميع المسبق طلبين ومجموعاً 300.
WITH orders(id, total) AS (VALUES (1, 100), (2, 100))
SELECT SUM(total) AS correct_total,
SUM(DISTINCT total) AS distinct_total
FROM orders;مع مبلغي 100 و100، المجموع الصحيح 200؛ يعيد SUM(DISTINCT total) القيمة 100.
إجراء التحقق
- حدد مستوى تفصيل الطلبات والبنود.
- اربط طلباً له بندان.
- احتفظ بالمفاتيح والأعداد والمجاميع المطابقة.
هل يكفي SUM(DISTINCT total)؟
لا. طلبان بمبلغ 100 لكل منهما مجموعهما 200، لكن SUM(DISTINCT total) يعيد 100. أصلح علاقة المفاتيح بدلاً من حذف المبالغ المتساوية.
المصدر الأساسي: PostgreSQL — Table expressions and joins. المنهج المرتبط: اقرأ الدليل العملي.