قدردانی از کارکنان پس از تصویب Strategy و Design هنوز «اجرا» نشده است. Policy ممکن است کامل باشد اما Eligibility به HRIS نرسد، مدیر آموزش ندیده باشد، هدیه دوبار صادر شود، شیفت شب مسیر دسترسی نداشته باشد یا روز Launch کسی نداند اعتراض را کجا ثبت کند.
این راهنما یک Recognition Program Implementation Runbook است: Approved design را از Readiness Gate، Pilot و Rehearsal به Launch، Hypercare و BAU Handover میبرد. تمرکز آن عملیات است—Owner، Test، Evidence، Incident، Reconciliation و Exit criterion—نه تکرار مزایای کلی برنامه.
خلاصه اجرایی
- Design approved با implementation ready یکسان نیست؛ commitment و capability هر دو لازماند.
- Pilot یک Launch کوچک نیست؛ باید سؤال، population، threshold، guardrail و تصمیم بعدی داشته باشد.
- Go-live بدون source of truth، support rota، rollback و communication matrix مجاز نیست.
- Eligibility، identity، channel، consent، finance، vendor و data path باید end-to-end آزموده شوند.
- Adoption، fidelity و reach outcomeهای اجرا هستند؛ engagement یا retention را ثابت نمیکنند.
- Hypercare باید Incident، queue، correction و reconciliation را با SLO اداره کند.
- BAU زمانی تحویل میگیرد که runbook، owner، capacity، access، dashboard و open risk پذیرفته شدهاند.
- اگر stop threshold رد شد، Launch را عقب بیندازید؛ هزینه تأخیر از آسیب اعتماد کمتر است.
مرز این صفحه با راهنماهای نزدیک
| پرسش | مرجع |
|---|---|
| Purpose، use case، governance، reward و measurement چگونه طراحی شوند؟ | Pillar برنامه قدردانی ۶۲۷ |
| Failure modeهای طراحی پیش از Release چگونه کشف شوند؟ | FMEA و Design Review در ۷۱ |
| برنامه موجود چگونه Migration/Transformation شود؟ | راهنمای تحول برنامه ۴۸۴ |
| Approved design چگونه Pilot، Launch و به BAU تحویل شود؟ | همین صفحه |
Implementation Scope را قفل کنید
| فیلد | نمونه |
|---|---|
| Version | v1.۰ approved در تاریخ مشخص |
| Population | کارمند رسمی/پیمانکار/شیفت/Remote |
| Moment | Peer message، milestone، award |
| Channel | web، mobile، offline، private/public |
| Reward | بدون پاداش/Point/Gift/Cash boundary |
| Systems | HRIS، IAM، payroll، vendor، BI |
| Locations | سایت/کشور/شعبه/زبان |
| Non-goal | Performance rating یا درمان Retention |
| Launch window | freeze، blackout، support hours |
پژوهش پیادهسازی چه مرزی میگذارد؟
| منبع | بینش | حد استفاده |
|---|---|---|
| Weiner 2009 | Readiness شامل shared resolve و shared capability است | نظریه سازمانی در Context سلامت؛ score آماده نیست |
| Proctor et al. 2011 | هشت implementation outcome متمایزند | Taxonomy خدمات سلامت؛ adaptation لازم است |
| Nilsen 2015 | Process، determinant، theory و evaluation framework هدفهای متفاوت دارند | Framework بهتنهایی مکانیزم/اثر نمیدهد |
| Aarons et al. 2014 | رهبری اجرا proactive، knowledgeable، supportive و perseverant قابل بررسی است | نمونه سلامت روان آمریکا؛ Benchmark Recognition نیست |
| Klein et al. 2001 | Policy/practice و implementation climate در اجرای فناوری مهم بودند | ۳۹ کارخانه و فناوری؛ تعمیم محتاط |
منابع و روش استفاده
- Weiner، ۲۰۰۹: برای Readiness دوگانه؛ نه آزمون آماده یا ادعای موفقیت.
- Proctor و همکاران، ۲۰۱۱: برای تفکیک implementation outcomeها از employee/business outcome.
- Nilsen، ۲۰۱۵: برای انتخاب نوع مدل/چارچوب متناسب با سؤال.
- Aarons، Ehrhart و Farahnak، ۲۰۱۴: برای رفتارهای رهبری اجرا با محدودیت Context.
- Klein، Conn و Sorra، ۲۰۰۱: برای implementation policy/climate؛ Recognition موضوع مطالعه نبود.
Readiness Gate؛ Commit و Capability
| بعد | Evidence | No-go نمونه |
|---|---|---|
| Value/commitment | sponsor/manager/user reason | فقط دستور HR |
| Task clarity | process map/RACI/runbook | owner مبهم |
| Resource | budget/capacity/support | کار اضافه بدون ظرفیت |
| Capability | skill/system/access/vendor | Training یا integration ناقص |
| Policy/legal | approved rule/local review | Pay/tax/privacy باز |
| Data | identity/eligibility/quality | denominator نامعتبر |
| Operations | SLO/escalation/rollback | پشتیبان ندارد |
Readiness evidence نه اعلام آمادگی
«مدیران موافقاند» یا «سامانه آماده است» Evidence کافی نیست. یک مدیر باید سناریوی واقعی را اجرا کند؛ حساب تست باید joiner/mover/leaver و shift را عبور دهد؛ Finance باید reconciliation dry run را امضا کند.
Decision Rights و RACI
| تصمیم | Accountable | Responsible/Consulted |
|---|---|---|
| Go/No-go | program sponsor | program/risk/IT/Finance/HR |
| Eligibility | policy owner | HRIS/HRBP |
| Data/access | data/system owner | IAM/privacy/vendor |
| Reward/ledger | Finance/HR owner | payroll/vendor |
| Communication | program owner | Comms/managers/support |
| Incident severity | service owner | support/risk/affected owner |
| BAU acceptance | operations owner | project/program team |
Pilot Charter
| فیلد | سؤال |
|---|---|
| Question | چه چیزی را میخواهیم یاد بگیریم؟ |
| Population | چه گروهی و چرا نماینده/محدود است؟ |
| Version | کدام Rule/Workflow؟ |
| Duration | زمان کافی برای چه Eventی؟ |
| Baseline | وضع موجود چیست؟ |
| Threshold | Go، adapt و stop چیست؟ |
| Guardrail | عدالت، بار، privacy، finance، safety |
| Support | کانال، hours، SLA و owner |
| Evidence | log، sample، interview، reconciliation |
| Decision date | چه کسی نتیجه را میپذیرد؟ |
Pilot population را راحتترین تیم انتخاب نکنید
تیم مشتاق و دیجیتالمحور friction واقعی را پنهان میکند. Pilot باید حداقل یک edge قابلکنترل داشته باشد: شیفت، Remote، manager capacity محدود، زبان/دسترسی یا workflow بینواحدی. گروه پرریسک را بدون حفاظت به آزمایش تبدیل نکنید.
Test Matrix end-to-end
| مسیر | Case | Expected |
|---|---|---|
| Identity | joiner/mover/leaver/duplicate | access درست/قطع/merge |
| Eligibility | contract/leave/shift/site | rule version/alternate path |
| Nomination | self/conflict/manager/peer | block/recusal/reason |
| Content | sensitive/harassment/wrong name | moderate/hide/correct |
| Consent | private/public/photo/story | preference/event confirm |
| Reward | issue/retry/cancel/expire | idempotent/reversal/notice |
| Finance | ledger/budget/tax/payroll | reconcile/approve |
| Data | report/filter/small-N/delete | RBAC/suppress/retention |
| Support | appeal/outage/wrong recipient | SLO/escalate/remedy |
Negative Test و Tabletop
- اگر vendor قطع شد، پیام/Reward کجا میماند و چگونه replay میشود؟
- اگر Gift دوبار صادر شد، چه کسی reversal و اطلاع را انجام میدهد؟
- اگر نام فرد جا افتاد یا اشتباه منتشر شد، Hide/Correction SLA چیست؟
- اگر مدیر ارشد Rule را override کرد، recusal/audit چگونه است؟
- اگر بودجه وسط ماه تمام شد، promise و queue چه میشوند؟
- اگر داده حساس export شد، containment و notification مسیر چیست؟
Environment و Test Data
| اصل | کنترل |
|---|---|
| Production data حداقلی | synthetic/masked data برای test |
| Role separation | admin/reviewer/finance/support account |
| Config version | export/hash/change log |
| Secret/access | vault/expiry/review |
| Notification | suppressed/sandbox domain |
| Reward | non-redeemable test catalog |
| Cleanup | test identity/ledger deletion |
Manager Enablement؛ Attendance کافی نیست
مدیر باید در Scenario رفتار کند: Evidence پیام، انتخاب کانال، shared credit، رد Nomination، escalation و correction. برای proficiency و transfer از راهنمای آموزش مدیران ۱۸۷ استفاده کنید.
Communication Matrix و Truth Source
| مخاطب | چه میداند؟ | کانال/Owner |
|---|---|---|
| کارمند | purpose، eligibility، privacy، appeal | truth page/manager |
| مدیر | criteria، evidence، escalation | playbook/office hour |
| Support | case type، SLO، remedy | runbook/queue |
| Finance | budget، ledger، liability | control pack |
| Executive | status، risk، decision | governance brief |
| Vendor | severity، access، escalation | SLA/contact tree |
Version، correction و appeal کامل در راهنمای ارتباطات داخلی برنامه ۲۰۲ آمده است.
Launch Plan T−۱۴ تا T+۱۴
| زمان | کار | Evidence |
|---|---|---|
| T−14 | scope/config freeze، final data extract | version/sign-off |
| T−10 | end-to-end/reconciliation/tabletop | test pack |
| T−7 | manager/support rehearsal، truth page | proficiency/URL |
| T−3 | access/roster/vendor/budget verify | readiness dashboard |
| T−1 | Go/No-go، backup، contact tree | decision record |
| T0 | controlled enablement/status watch | event/health log |
| T+1–3 | incident/queue/reach/reconcile | daily review |
| T+7 | quality/equity/feedback review | adapt decision |
| T+14 | Hypercare exit or extend | acceptance |
Go/No-go Gate
| Gate | Go evidence | No-go |
|---|---|---|
| Policy | version/approval/local review | open critical term |
| Population | denominator/reconciliation | unknown eligibility gap |
| System | critical path tests pass | security/duplicate/data loss |
| Finance | budget/ledger/fallback | unfunded promise |
| People | owner/rota/proficiency | single unavailable hero |
| Support | queue/SLO/escalation/remedy | appeal nowhere |
| Risk | residual risk accepted | severity gate open |
Launch را Big Bang نکنید مگر مجبور باشید
Feature flag، site wave، population wave یا use-case wave امکان rollback و یادگیری میدهند. Big Bang فقط وقتی توجیه دارد که dependency/contract آن را الزام کند و rehearsal/contingency قویتر باشد.
Hypercare Operating Rhythm
| Cadence | مرور | Owner |
|---|---|---|
| Real-time | availability/security/duplicate | system/service |
| روزانه | queue، eligibility، reward، finance | war room lead |
| ۲–۳روزه | message quality، consent، credit | program/HR |
| هفتگی | reach/equity/adoption/feedback | governance |
| Exit review | open risk/runbook/capacity | BAU owner |
Incident Severity
| Severity | نمونه | واکنش |
|---|---|---|
| S1 Critical | data exposure، pay error گسترده، discrimination | stop/contain/executive/local review |
| S2 High | duplicate reward، wrong audience، access gap | feature disable/remedy/priority |
| S3 Medium | delay، content correction، limited eligibility | queue/SLO/notify |
| S4 Low | UX/help typo | backlog/next release |
Severity تعریف محلی است. Incident انسانی/انصافی را فقط با uptime نسنجید؛ یک Public exposure کوچک میتواند برای فرد شدید باشد.
Incident Record
| فیلد | محتوا |
|---|---|
| ID/time/version | traceability |
| Population/exposure | چه کسی/چه داده/چه ارزش |
| Containment | چه چیزی متوقف/پنهان شد |
| Owner/status | accountability |
| Communication | affected/manager/vendor |
| Correction/remedy | credit/payment/access/apology |
| Root cause/control | system/process/incentive |
| Closure/evidence | test/reconcile/follow-up |
Finance و Reconciliation
| کنترل | سؤال |
|---|---|
| Event-to-ledger | هر issuance یک event/key دارد؟ |
| Ledger-to-vendor | مقدار/وضعیت/لغو برابر است؟ |
| Ledger-to-budget | commitment/spend/liability چیست؟ |
| Exception | duplicate/failed/expired کجاست؟ |
| Payroll/tax | review محلی و timing چیست؟ |
| Close | sign-off، evidence و retention؟ |
Forecast، Cash flow و کنترل مالی ایران در راهنمای Budget و Finance در ۲۹۲ پوشش داده شده است.
Implementation Outcomeها را جدا بسنجید
| Outcome | سؤال Recognition |
|---|---|
| Acceptability | ذینفع تجربه را قابل قبول میداند؟ |
| Appropriateness | برای use case/Context مناسب است؟ |
| Feasibility | در جریان کار قابل اجراست؟ |
| Adoption | Population هدف شروع به استفاده کرد؟ |
| Fidelity | اجزای critical طبق design اجرا شدند؟ |
| Penetration/Reach | چه سهمی از محل/نقش پوشش یافت؟ |
| Cost | implementation/admin/full cost چیست؟ |
| Sustainability | Practice در BAU و تغییر Context دوام دارد؟ |
Adoption بالا اثر بر انگیزه یا نگهداشت را ثابت نمیکند. KPI contract و کیفیت داده در راهنمای سنجش برنامه ۱۹۶ آمده است.
Dashboard سهلایه
| لایه | شاخص | تصمیم |
|---|---|---|
| Service health | error/latency/queue/duplicate | incident/capacity |
| Implementation | reach/adoption/fidelity/cost | adapt/support |
| Guardrail | equity/consent/appeal/overwork | stop/remedy |
BAU Handover Contract
| دارایی | Acceptance evidence |
|---|---|
| Policy/config/version | truth source/change control |
| Runbook | operator اجرا و تأیید کرده |
| Service/SLO | queue، severity، escalation |
| Access | RBAC/admin/vendor review |
| Finance | ledger/reconciliation/close |
| Data | dictionary/quality/retention |
| Capacity | named owner/backup/load |
| Risk | open item/expiry/acceptor |
| Roadmap | backlog/priority/release |
| Exit | vendor/feature/program shutdown |
Hypercare Exit Criteria
- S1/S2 باز وجود ندارد یا residual risk رسماً پذیرفته شده است.
- Queue و SLO چند چرخه در محدوده محلی ماندهاند.
- Eligibility و financial reconciliation بسته شده است.
- Critical workflowها با evidence پایدارند.
- BAU owner و backup دسترسی و proficiency دارند.
- Communication/FAQ/runbook با رخدادهای واقعی بهروز شدهاند.
- Guardrail equity، consent و workload breach حل یا کنترل شده است.
پایداری پس از Handover
BAU بهمعنای رهاکردن نیست. تغییر مدیر، بودجه، ابزار، جمعیت یا Vendor میتواند Drift بسازد. Ownership، re-baseline و culture debt در راهنمای پایداری فرهنگ قدردانی ۲۷۴ آمده است.
Software readiness
اگر برنامه دیجیتال است، selection، integration، IAM، accessibility، vendor risk، export و exit در راهنمای نرمافزار قدردانی ۵۶۳ پوشش داده شدهاند. Tool نباید پیش از Process/owner/source-of-truth Launch شود.
Scenario ایران: شرکت ۲۵۰نفره چندسایتی
Scope و Pilot
برنامه Peer Recognition بدون Reward برای دفتر تهران و یک شعبه صنعتی Pilot میشود. سؤال Pilot: آیا کارکنان شیفت و کارکنان بدون ایمیل سازمانی مسیر برابر دارند؟ kiosk/QR و مسیر supervisor-assisted با privacy guardrail آزموده میشوند.
Launch و Hypercare
در T−۷ فهرست HRIS با roster شعبه reconcile میشود. T0 فقط دو use case فعال است. Hypercare روزانه access، wrong audience و credit correction را مرور میکند. چون reach شیفت شب پایین است، Rollout سراسری متوقف و alternate path اصلاح میشود.
Scenario ایران: برنامه دارای کارت هدیه
Dry run
Finance ده event تست با issue، retry، cancel و expire را از سیستم تا vendor تطبیق میدهد. idempotency key، budget hold، substitute policy و contact tree آزموده میشوند؛ کارت واقعی به حساب تست صادر نمیشود.
Incident و Remedy
در روز دوم دو کارت Duplicate میشوند. issuance متوقف، ledger/vendor reconcile و افراد متأثر مطلع میشوند. مبلغ از کارکنان پس گرفته نمیشود تا review محلی انجام شود. Root cause retry و control جدید پیش از restart آزموده میشود.
برنامه ۳۰/۶۰/۹۰روزه
| بازه | کار | Gate |
|---|---|---|
| روز ۱–۳۰ | scope freeze، readiness، RACI، Pilot charter، test matrix | Pilot Go/No-go |
| روز ۳۱–۶۰ | Pilot، feedback، reconciliation، FMEA update، rehearsal | Launch Go/No-go |
| روز ۶۱–۹۰ | wave launch، hypercare، incident، implementation review | BAU accept/extend/rollback |
چکلیست روز Go-live
- Version، Scope و population نهایی کدام است؟
- Go/No-go چه کسی و با چه Evidenceی امضا کرد؟
- Truth source و status message کجاست؟
- Support rota، severity و contact tree فعال است؟
- Feature disable/rollback چگونه اجرا میشود؟
- Budget، ledger، vendor و reconciliation آمادهاند؟
- Consent، privacy، small-N و correction path تست شدهاند؟
- Joiner/mover/leaver/shift/offline چه وضعی دارند؟
- Dashboard service/implementation/guardrail چه baselineی دارد؟
- Hypercare exit و BAU acceptor چه کسی است؟
نتیجهگیری
اجرای برنامه قدردانی، انتشار یک ایمیل یا فعالکردن نرمافزار نیست. Design باید به Rule، Workflow، Access، Ledger، Support، Incident و Runbook تبدیل شود و در سناریوهای واقعی آزموده شود. Pilot باید یادگیری بسازد و Go-live باید قابل توقف و اصلاح باشد.
شروع عملی: Scope و version را قفل کنید، Readiness دوگانه commit/capability را با Evidence بسنجید، یک Pilot دارای edge واقعی اجرا کنید و تنها وقتی Hypercare و BAU owner آمادهاند Rollout کنید. اگر Guardrail شکست خورد، توقف برنامه بخشی از اجرای حرفهای است.
سؤالات متداول
برنامه قدردانی کارکنان را از کجا شروع کنیم؟
پس از تصویب Purpose، Design و Governance، Scope/version را قفل، Readiness را با Evidence بررسی و Pilot charter بسازید. مستقیم از خرید ابزار یا اعلام سراسری شروع نکنید.
Pilot برنامه قدردانی چقدر طول بکشد؟
عدد ثابت ندارد؛ باید آنقدر طول بکشد که Eventهای اصلی، edge case، support queue و reconciliation دیده شوند. Duration، threshold و decision date را پیشاپیش در Charter بنویسید.
چه زمانی Go-live را عقب بیندازیم؟
وقتی Policy/eligibility نامعلوم، تست critical ناموفق، بودجه یا ledger حلنشده، support/appeal بدون owner یا ریسک شدید privacy، pay، discrimination و safety باز است.
Hypercare چیست؟
دوره کنترل فشرده پس از Launch است که service health، queue، eligibility، finance، message quality و guardrailها را با cadence و owner مشخص میسنجد تا برنامه پایدار یا rollback شود.
چه وقت برنامه به BAU تحویل میشود؟
وقتی runbook، SLO، owner/backup، access، reconciliation، data، open risk و roadmap پذیرفته شده و S1/S2 باز یا guardrail breach بدون Treatment وجود ندارد.
