خطاهای برنامه قدردانی کارکنان؛ FMEA و Design Review پیش از اجرا

قدردانی از کارکنان فقط با نیت خوب ایمن یا مؤثر نمی‌شود. یک برنامه ممکن است دقیقاً طبق طراحی کار کند و باز هم Popularity، تبعیض دسترسی، افشای اطلاعات، بدهی مالی، پیام تکراری یا رقابت ناسالم بسازد. پیش از Go-live باید بپرسید: «این فرایند از چه راه‌هایی می‌تواند وظیفه‌اش را انجام ندهد یا آسیب دیگری ایجاد کند؟»

این راهنما یک Recognition Program FMEA عملی می‌سازد: Function، Failure mode، Cause، Effect، Control، Detection، Owner و Residual risk را ثبت می‌کند و با Test case، Tabletop و Go/No-go gate جلوی خطاهای قابل‌پیش‌بینی را می‌گیرد.

خلاصه اجرایی

• FMEA جای طراحی Program نیست؛ Design review ریسک همان طراحی است.
• از Function شروع کنید، نه فهرست «اشتباهات رایج».
• Failure mode را قابل‌مشاهده بنویسید: چه چیزی کار نمی‌کند، نه «فرهنگ بد است».
• Cause، Local effect و Downstream effect را جدا کنید.
• Severity، Occurrence و Detectability رتبه محلی‌اند، نه Benchmark علمی.
• RPN پایین نمی‌تواند ریسک شدید Privacy، Pay، Safety یا Discrimination را مجاز کند.
• Preventive، Detective و Corrective control هر سه لازم‌اند.
• Residual risk فقط با Owner، Expiry، Trigger و Compensating control پذیرفته می‌شود.

مرز این صفحه با راهنماهای نزدیک

پرسش	مرجع
برنامه قدردانی از صفر چگونه طراحی شود؟	Pillar برنامه قدردانی ۶۲۷
برنامه موجود با بازخورد چگونه بازطراحی شود؟	Feedback redesign در ۵۲۷
Migration، Cutover و Transformation چگونه انجام شود؟	تحول برنامه ۴۸۴
Failure modeهای طراحی پیش از Release چگونه کشف شوند؟	همین صفحه

FMEA برنامه قدردانی چیست؟

FMEA روشی ساختاریافته برای پرسیدن این است که یک Item یا Process چگونه ممکن است Function خود را انجام ندهد، علت و اثر چیست و چه Treatmentی لازم است. IEC ۶۰۸۱۲:۲۰۱۸ کاربرد عمومی آن را برای Process، Software و Human action هم توضیح می‌دهد.

در این صفحه، FMEA به‌صورت کیفی و متناسب با Recognition اقتباس می‌شود. این کار ادعای انطباق با استاندارد، Audit رسمی یا جایگزینی بررسی حقوقی/مالی/امنیتی ایران نیست.

FMEA چه چیزی نیست؟

نیست	چرا	جایگزین درست
Brainstorm خطاهای کلی	Function/Scope ندارد	Process-function map
Risk register تک‌ستونی	Cause/Effect/Control گم می‌شود	Failure-mode record
اثبات ایمنی	Unknown/interaction باقی می‌ماند	Evidence + residual risk
امتیاز RPN	عدد، تصمیم را جایگزین می‌کند	Severity gate + judgment
مقصرسازی کاربر	Design condition را پنهان می‌کند	System/process cause
Go-live checklist عمومی	سناریوی شکست ندارد	Negative test/tabletop

پژوهش و استانداردها چه مرزی می‌گذارند؟

منبع	بینش	حد استفاده
IEC 60812:2018	برنامه‌ریزی، اجرا، مستندسازی و نگهداری FMEA/FMECA	راهنمای عمومی؛ نسخه Recognition آماده نیست
ISO 31000:2018	شناسایی، تحلیل، ارزیابی، Treatment، Monitoring و Communication ریسک	Certifiable نیست؛ نسخه بعدی در توسعه بود
Colquitt et al. 2001	چهار بعد عدالت متمایز و مرتبط‌اند	Threshold Program نمی‌دهد
Firk et al. 2024	Public feed/Leaderboard می‌تواند Comparison و افت Feeling appreciated بسازد	Feature/Context مهم است؛ حکم عمومی همه برنامه‌ها نیست
Bradler et al. 2016	Recognition عمومی/Selection در Task کوتاه پاسخ‌های متفاوت ساخت	Retention، برنامه بلندمدت یا ایران را ثابت نمی‌کند

Scope را پیش از تحلیل ببندید

فیلد Scope	نمونه
Objective	ثبت و رساندن Recognition منصفانه برای Contribution مشخص
Population	کارمند، پیمانکار، شیفت، Remote، مدیر
Moment	Peer message، Award، milestone، redemption
Channel	Private، team، public، offline
Reward boundary	پیام، Point، هدیه، Cash، Growth
System	Policy، form، workflow، vendor، finance
Interfaces	HRIS، IAM، payroll، BI، supplier
Non-goal	Performance scoring یا درمان Engagement

Function Map از Eligibility تا Exit

Function	وظیفه	Definition of done
Define	Purpose/criteria/version	قابل‌فهم و قابل‌دسترسی
Access	Opportunity برای جمعیت واجد	Alternate path آزموده
Capture	Context/contribution/evidence	کافی، حداقلی، قابل‌اصلاح
Nominate	ارسال بدون تعارض/اجبار	Identity/eligibility معتبر
Decide	اعمال Rule/Review	ثابت، مستند، قابل اعتراض
Deliver	Audience/channel/timing	Preference/consent رعایت
Fulfill	Point/gift/payment	صحیح، به‌موقع، قابل reconcile
Record	Ledger/audit/retention	Purpose/access/version روشن
Resolve	Correction/appeal/incident	SLA و remedy بسته
Exit	Expiry/export/delete/close	تعهد و داده تسویه

Failure Mode Record سیزده‌فیلدی

فیلد	سؤال
ID/Version	کدام رکورد/نسخه؟
Function	چه وظیفه‌ای باید انجام شود؟
Failure mode	وظیفه چگونه انجام نمی‌شود؟
Cause	چه Conditionی آن را ممکن می‌کند؟
Local effect	در همان مرحله چه رخ می‌دهد؟
Downstream effect	برای فرد/تیم/مالی/داده چه پیامدی دارد؟
Existing control	اکنون چه چیزی پیشگیری/کشف/اصلاح می‌کند؟
Severity	شدت اثر در Context چیست؟
Occurrence	با Evidence محلی چقدر محتمل است؟
Detectability	پیش از آسیب چقدر کشف‌پذیر است؟
Action/Owner/Date	چه Treatmentی، توسط چه کسی، تا کی؟
Test evidence	کنترل چگونه آزموده شد؟
Residual risk	چه ریسکی باقی ماند و چه کسی پذیرفت؟

Failure Mode را خوب بنویسید

ضعیف	قابل‌آزمون
برنامه ناعادلانه است	کارکنان شیفت شب نمی‌توانند Nomination ثبت کنند
پیام بد است	پیام بدون Behavior/Evidence منتشر می‌شود
مدیر Bias دارد	Reviewer می‌تواند Award مستقیم خود را بدون Recusal تأیید کند
سیستم امن نیست	لینک Public بدون Login نام/پیام را نمایش می‌دهد
پاداش اشتباه می‌شود	Retry پرداخت، Gift را دوبار صادر می‌کند
کارکنان اعتماد ندارند	Appeal ثبت می‌شود اما Status/Owner ندارد

Cause را با Blame یکی نگیرید

لایه Cause	نمونه
Policy	Eligibility مبهم
Process	Separation of duties ندارد
Interface	HRIS update با تأخیر
Capacity	Reviewer queue بدون Backup
UX/Access	Form فقط Desktop/Email
Incentive	Count پیام KPI مدیر است
Data	Duplicate identity/source conflict
Vendor	Catalog inventory sync نمی‌شود
Human action	Override بدون Reason/expiry

Effect را چندسطحی ثبت کنید

سطح	اثر نمونه
Recipient	شرم، فشار Public، Gift نامتناسب
Contributor	Credit جاافتاده/نقش اشتباه
Team	Comparison، رقابت، بار اضافی
Program	Duplicate، queue، trust loss
Financial	Liability، fraud، budget overrun
Data/Privacy	Secondary use، exposure، retention
Legal/Employee relations	شکایت، اختلاف، تعهد پرداخت
Reputation	ادعای عمومی غلط/غیرقابل‌اصلاح

رتبه‌بندی ۱ تا ۵؛ محلی و مستند

رتبه	Severity نمونه	Occurrence evidence	Detectability
۱	اصطکاک جزئی و برگشت‌پذیر	نادر در داده معتبر	پیش از اثر خودکار
۲	اثر محدود/اصلاح ساده	گاه‌به‌گاه	در همان مرحله
۳	تجربه/عملیات قابل‌توجه	Pattern محلی	پس از تماس کاربر
۴	آسیب جدی مالی/عدالت/داده	تکرار محتمل	پس از چند Case
۵	شدید/غیرقابل‌برگشت/حق اساسی	Exposure گسترده یا کنترل‌نشده	دیر یا تصادفی

تعریف‌ها باید برای Context سازمان تصویب شوند. Occurrence بدون داده را با عدد دقیق جعل نکنید؛ «نامعلوم» و برنامه جمع‌آوری Evidence گزینه معتبر است.

دام RPN

ضرب Severity × Occurrence × Detectability یک ابزار اولویت‌بندی است، نه حکم. ترکیب‌های متفاوت می‌توانند RPN یکسان بسازند: ریسک شدید اما نادر با خطای متوسط و پرتکرار برابر دیده می‌شود. بنابراین:

• Severity ۵ همیشه Review تخصصی و Gate مستقل دارد.
• Privacy، Discrimination، Pay، Safety، Fraud و Public irreversible harm Gate موضوعی دارند.
• Unknown occurrence امتیاز پایین نمی‌گیرد.
• چند Failure mode وابسته جدا و در سناریوی ترکیبی هم آزموده می‌شوند.
• تصمیم و دلیل کنار عدد ثبت می‌شود.

Severity Gateهای غیرقابل‌مذاکره

Gate	Trigger	مرجع تصمیم
Privacy/Data	داده حساس، انتشار، secondary use	Data/Privacy owner
Pay/Tax	Cash، benefit، recurring promise	Finance/Payroll/بررسی محلی
Discrimination/Justice	Eligibility/Outcome gap	HR/ER/Legal محلی
Safety/Wellbeing	Overwork، unsafe behavior	Operations/HSE/HR
Fraud/Conflict	Self-dealing، collusion، override	Finance/Audit
Public/Reputation	نام/تصویر/Story/award	Comms/Privacy/Recipient
AI/Automation	Eligibility، content، scoring	Accountable business owner/Risk

Preventive، Detective و Corrective Control

نوع	کار	نمونه
Preventive	احتمال/Exposure را کم می‌کند	Private default، RBAC، criteria
Detective	Failure را سریع آشکار می‌کند	Duplicate alert، fairness review
Corrective	اثر را Repair می‌کند	Hide، reversal، correction، appeal
Compensating	وقتی کنترل اصلی ممکن نیست	Manual review تا fix vendor

کنترل فقط «آموزش مدیر» نیست. اگر Incentive، Permission یا Workflow خطا را آسان می‌کند، Training تنها کنترل ضعیفی است.

Failure mode: Eligibility مبهم

جزء	نمونه
Failure	پیمانکار/مرخصی/شیفت نادرست حذف یا وارد می‌شود
Cause	تعریف جمعیت و Effective date مبهم
Effect	عدالت، تعهد مالی، شکایت
Prevent	Eligibility matrix + version
Detect	Denominator reconciliation
Correct	Backdated access/remedy و اطلاع
Test	Joiner/mover/leaver/leave/contract cases

Failure mode: معیار کلی و تفسیر سلیقه‌ای

جزء	نمونه
Failure	«تعهد» با Face time/Overwork تفسیر می‌شود
Cause	Value بدون behavior/anti-example
Effect	Bias، unsafe norm، consistency gap
Prevent	Behavior rubric + prohibited signals
Detect	Sample calibration
Correct	پیام/award review و criteria revision

Failure mode: Popularity و Visibility

Public feed و Nomination ممکن است افراد پرشبکه را بیشتر نمایان کند. Count بالاتر لزوماً Contribution بیشتر نیست. برای عدالت چهاربعدی و Remedy به راهنمای Justice Audit در ۴۷۶ رجوع کنید.

کنترل	آزمون
Opportunity denominator	Shift/site/role/network exposure
Private path	بدون افت eligibility/value
Shared credit	نام جاافتاده قابل اصلاح
No count target	مدیر با کمیت ارزیابی نشود
Concentration alert	Signal review، نه punishment

Failure mode: Publicity بدون Consent

جزء	کنترل
Audience unknown	Private default
Standing preference قدیمی	Event-specific confirm حساس
Photo/story	Consent جدا، scope/expiry
Power pressure	No-response = no؛ decline بدون جریمه
Wrong public post	Hide SLA + correction log

Preference Contract کامل در راهنمای ۸۲ آمده است.

Failure mode: Leaderboard و Gaming

Failure	Cause	Control/Test
تبادل امتیاز	Reciprocity incentive	Pattern review + no auto-punish
Self-dealing	Conflict rule ندارد	Recusal/blocked relation
Split پیام	Count target	حذف quota/leaderboard
Popularity rank	Public total	خاموش‌به‌صورت پیش‌فرض
Unsafe competition	Scarcity/award pressure	Guardrail/stop threshold

اقتصاد امتیاز و Anti-gaming در راهنمای Gamification ۱۸۳ پوشش داده شده است.

Failure mode: تأخیر، Duplicate و Lost event

Failure	Cause	Control
پیام دیر	Approval queue	SLO/escalation/fallback
Duplicate	Retry بدون idempotency	Event key/dedupe/reversal
Lost event	Integration failure	Dead-letter/reconciliation
Wrong recipient	Identity stale	JML sync/confirmation
Out-of-hours	Timezone/default	Quiet hours/digest

Failure mode: Reward، Budget و Liability

Failure	Effect	Control
Gift unavailable	mismatch/delay	Substitution/price/stock SLA
Value unequal	justice gap	value band/total cost
Point overspend	budget/liability	ledger/limit/forecast
Expiry surprise	loss/trust	notice/version/grace
Tax/payroll error	employee/financial harm	local review/reconciliation
Vendor failure	unfulfilled promise	fallback/refund/exit plan

Budget، Cash flow و کنترل مالی ایران در راهنمای ۲۹۲ آمده است.

Failure mode: Data و Secondary Use

Failure	Control	Test
Performance use پنهان	Purpose separation	Access/report review
Retention نامحدود	Expiry/delete schedule	Aged-record sample
Small-N exposure	Suppression/minimum cell	Filter attack
Manager raw access	RBAC/need-to-know	Permission matrix
AI training	contract/non-use boundary	vendor evidence
Export leak	scope/redaction/log	export scenario

Failure mode: AI Assist

Failure	Effect	Guardrail
Hallucinated contribution	wrong credit	source-grounded draft/human verify
Inflated impact	false claim	evidence ladder
Generic sameness	low meaning	sample quality review
Sensitive inference	privacy/discrimination	no profiling
Auto-send	scale harm	human action + kill switch
Eligibility/scoring	opaque decision	prohibited use

Failure mode: Correction وجود دارد اما کار نمی‌کند

Failure	Detection	Control
مسیر پیدا نمی‌شود	task test	in-context link/help
Owner ندارد	aged queue	RACI/SLA
Public harm می‌ماند	complaint time	hide-before-investigate
فرد از اعتراض می‌ترسد	interview/non-use	no retaliation/confidential path
اصلاح در Ledger نیست	reconciliation	linked adjustment/audit

Test Case Matrix

نوع Test	سناریو	Evidence Pass
Happy path	پیام Private بدون Reward	end-to-end receipt
Boundary	آخر بودجه/آخر مهلت/حداکثر نفر	rule ثابت
Negative	فرد غیرواجد/داده ناقص	safe reject/reason
Abuse	self-dealing/collusion/public scrape	block/alert/review
Failure	vendor/API/payment down	fallback/reconcile
Accessibility	keyboard/screen reader/RTL	task completion
Privacy	decline/delete/export	scope/log/SLA
Recovery	wrong public award	hide/correct/notify

Tabletop پیش از Go-live

یک جلسه ۶۰ تا ۹۰دقیقه‌ای با HR، Finance، IT، Manager، Employee representative و Support برگزار کنید. سناریو را دقیقه‌به‌دقیقه پیش ببرید و فقط درباره Policy حرف نزنید؛ از ابزار/فرم واقعی استفاده کنید.

1. کارمند شیفت بدون ایمیل Nomination می‌گیرد.
2. پیام Public نام اشتباه و Health detail دارد.
3. Retry دو Gift صادر می‌کند.
4. Reviewer، Direct report خود را تأیید می‌کند.
5. Vendor سه روز در دسترس نیست.
6. Recipient درخواست Hide/Delete/Correction می‌دهد.
7. Finance پایان ماه اختلاف Ledger پیدا می‌کند.

Evidence Pack برای Design Review

• Scope، Function map و Version؛
• FMEA register و Severity definition؛
• Policy/eligibility/decision rights؛
• Data flow، access و retention؛
• Reward ledger/budget/finance evidence؛
• Test case result و Defect log؛
• Tabletop action و Owner؛
• Residual risk acceptance؛
• Rollback/fallback/runbook؛
• Go/No-go decision memo.

Go/No-go Gate

Gate	Go وقتی	No-go وقتی
Critical risk	بسته/Compensating control معتبر	Severity gate بی‌Owner
Core journey	Happy/negative/recovery pass	Correction یا fallback fail
Access/equity	Population نماینده pass	Shift/contract/remote حذف
Finance	Ledger/reconcile/budget pass	تعهد نامعلوم
Privacy	purpose/access/retention tested	public/secondary use مبهم
Operations	Owner/SLA/support/alert	queue بی‌مالک
Rollback	تمرین و داده قابل بازیابی	فقط «خاموش می‌کنیم»

Residual Risk Acceptance

فیلد	الزام
Risk	Failure/effect باقیمانده
Why not fix now	محدودیت واقعی، نه «وقت نداریم»
Compensating control	اقدام موقت آزموده
Exposure	Population/time/scope محدود
Owner	فرد Accountable مجاز
Expiry/review	تاریخ پایان/بازبینی
Trigger	چه Signalی توقف می‌دهد؟
Communication	چه کسی باید بداند؟

FMEA یک فایل مرده نباشد

Trigger	بازبینی لازم
Policy/version change	Function/Failure/Control
Vendor/Integration	Interface/fallback/data
New reward/tier	finance/equity/fraud
Incident/complaint	Cause/detection/corrective
Population change	eligibility/access
AI feature	use-case/model/kill switch
Quarterly review	occurrence/evidence/residual

KPI برای کنترل، نه اثبات موفقیت

نما	Metric	Guardrail
Control	% control test pass	نمونه نماینده
Failure	rate by opportunity	underreporting
Detection	time-to-detect	اثر واقعی
Correction	time-to-contain/resolve	quality remedy
Residual	aged acceptance	expiry breach
Equity	access/outcome gap	denominator/privacy
Financial	ledger variance/liability	full cost
Experience	complaint/preference mismatch	silence ≠ safety

Data contract و کیفیت Dashboard در راهنمای ۱۹۶ آمده است.

سناریوی ایران: برنامه امتیازی شرکت ۳۲۰نفره

یک شرکت خدماتی قصد داشت برنامه Point و Gift card را هم‌زمان برای دفتر تهران و چهار شعبه عرضه کند. Demo موفق بود، اما FMEA سه ریسک بحرانی نشان داد:

1. کارکنان شعبه بدون ایمیل در HRIS واجد بودند اما Access نداشتند.
2. Retry Vendor بعد از Timeout می‌توانست Gift را دوبار صادر کند.
3. Public feed نام و متن را بدون Preference منتشر می‌کرد.

Go-live سراسری متوقف شد. Pilot فقط با Private default، Kiosk محدود، Event key، Daily reconciliation و Manual fulfillment آغاز شد. Residual risk موجودی Vendor برای ۳۰ روز با سقف مالی، Owner و Trigger توقف پذیرفته شد. رشد Count پیام به‌عنوان موفقیت اعلام نشد؛ Control pass، access parity، duplicate و correction سنجیده شدند.

برنامه ۳۰روزه Design Review

روز	خروجی	Gate
۱–۵	Scope، function map، team	Bounded system
۶–۱۰	Failure mode workshop	Coverage
۱۱–۱۵	Rating، severity gate، action	Priority
۱۶–۲۰	Control design و test cases	Test readiness
۲۱–۲۵	Tabletop، defects، retest	Evidence
۲۶–۳۰	Residual acceptance و Go/No-go	Accountability

RACI Design Review

تصمیم	A	R/C
Scope/function	Program owner	HR/Ops/users
Risk rating	Risk owner	cross-functional team
Financial gate	Finance owner	Payroll/HR/Audit
Privacy/data gate	Data owner	Privacy/IT/HR
Justice/remedy	HR/ER owner	employee reps/managers
Control test	Control owner	QA/users/support
Residual acceptance	authorized business owner	Risk/subject owner
Go/No-go	Executive sponsor	all gate owners

Anti-patternها

• FMEA پس از Go-live برای تکمیل پرونده؛
• شروع با فهرست خطا بدون Function؛
• Cause = بی‌دقتی کارمند؛
• RPN به‌عنوان تصمیم خودکار؛
• Occurrence ساختگی بدون داده؛
• Training به‌عنوان تنها Control؛
• وجود Policy به‌عنوان Evidence کارکرد؛
• تست فقط Happy path؛
• نادیده‌گرفتن Interface/Vendor/Finance؛
• پذیرش ریسک بدون Expiry؛
• Complaint کم به‌عنوان Safety؛
• بستن Action بدون Retest.

چک‌لیست نهایی

• Scope، Objective، Population، Interface و Non-goal بسته‌اند.
• Function map End-to-end وجود دارد.
• Failure mode قابل‌مشاهده و Cause سیستمی است.
• Local/Downstream effect ثبت شده‌اند.
• Severity/Occurrence/Detectability تعریف محلی دارند.
• Severity gate بر RPN مقدم است.
• Preventive/Detective/Corrective control جدا هستند.
• Negative، abuse، failure و recovery test اجرا شده‌اند.
• Access، Privacy، Justice، Finance و AI review شده‌اند.
• Defect پس از Fix دوباره آزموده شده است.
• Residual risk Owner/Expiry/Trigger دارد.
• Go/No-go memo و Review trigger ثبت شده است.

پرسش‌های متداول

FMEA برنامه قدردانی کارکنان چیست؟

تحلیل ساختاریافته Functionها و راه‌های شکست آن‌هاست. برای هر Failure mode، Cause، Effect، Control، Detection، Action، Owner، Test evidence و Residual risk ثبت می‌شود تا تصمیم Release قابل‌دفاع باشد.

آیا RPN بالاتر همیشه اولویت بالاتری دارد؟

خیر. تعریف محلی، کیفیت داده و ترکیب امتیازها مهم‌اند. ریسک شدید Privacy، Pay، Safety، Discrimination، Fraud یا آسیب عمومی حتی با Occurrence پایین باید Gate تخصصی مستقل داشته باشد.

مهم‌ترین خطای برنامه قدردانی چیست؟

یک خطای واحد برای همه وجود ندارد. Eligibility، Publicity، Credit، Gaming، Reward fulfillment، Data use و Correction براساس Context شدت متفاوت دارند. Function map و Evidence محلی اولویت را تعیین می‌کند.

FMEA را چه زمانی انجام دهیم؟

پیش از Go-live، سپس هنگام تغییر Policy، Population، Reward، Vendor، Integration یا AI و بعد از Incident/Complaint. رکورد باید Version و Trigger بازبینی داشته باشد، نه اینکه فایل یک‌باره بماند.

چه کسانی باید در Design Review باشند؟

Program owner، HR، کاربران نماینده، مدیر خط، Finance، IT/Data/Privacy، Support و Ownerهای ریسک مرتبط. حضور نقش‌ها مهم است؛ تصمیم Accountable و Recusal نیز باید روشن باشد.

جمع‌بندی

خطاهای برنامه قدردانی کارکنان با نیت خوب یا Checklist عمومی مهار نمی‌شوند. Function را تعریف کنید، Failure mode و اثر را قابل‌آزمون بنویسید، Severity gate را بر عدد مقدم کنید و فقط وقتی Release کنید که کنترل‌ها در سناریوی واقعی، منفی و بازیابی Evidence داشته باشند.