شبکههای اجتماعی داخلی برای قدردانی از کارکنان ردپایی از اینکه چه کسی، از چه کسی، برای چه سهمی و در چه زمانی تشکر کرده است تولید میکنند. این داده میتواند شکاف دسترسی، تمرکز دیدهشدن و جریان قدردانی بین تیمها را آشکار کند؛ اما نقشه کامل همکاری، ارزش افراد، کیفیت عملکرد یا «وفاداری» آنها نیست.
این راهنما یک Recognition Network Analysis امن و قابلتفسیر میسازد: Node و Edge را تعریف میکند، Coverage، Reciprocity، Concentration و Cross-team flow را میسنجد، داده گمشده و Opportunity to be seen را وارد تحلیل میکند و استفادههای تنبیهی را ممنوع میسازد. مثالها برای سازمان ایرانیاند و اعداد نمونه، Benchmark صنعت نیستند.
پاسخ کوتاه: از شبکه قدردانی چه میتوان فهمید؟
میتوان فهمید چه بخشی از جمعیت واجد شرایط در بازه دیده شده، پیامها بین کدام نقشها جریان داشته، آیا چند فرستنده/گیرنده سهم نامتناسب دارند و کدام واحدها کمتر با هم ارتباط Recognition دارند. نمیتوان از همین داده نتیجه گرفت چه کسی مؤثرتر، محبوبتر، متعهدتر یا آماده ارتقاست.
| پرسش | داده شبکه کمک میکند؟ | حد تفسیر |
|---|---|---|
| چه کسانی در Feed دیده نشدهاند؟ | بله، با Roster کامل | ندیدهشدن مساوی بیسهمبودن نیست |
| پیامها چقدر بین تیمیاند؟ | بله، با واحد سازمانی معتبر | همکاری خارج Platform گم است |
| چه کسی بهترین عملکرد را دارد؟ | خیر | Popularity و visibility با performance یکی نیست |
| چه کسی قصد خروج دارد؟ | خیر | استنتاج فردی پرریسک و نامعتبر است |
| آیا دسترسی منصفانه است؟ | تا حدی | نیازمند داده Access و مصاحبه است |
| آیا برنامه اثر علی داشته؟ | بهتنهایی خیر | طراحی مقایسه و Outcome جدا لازم است |
نقش این مقاله در خوشه چیست؟
برای طراحی پیام Async، Time Zone، Notification و Preference به راهنمای قدردانی آنلاین بروید. برای سیاست انتشار داخلی/عمومی، Consent و Moderation، حاکمیت شبکه اجتماعی Recognition را ببینید. برای خرید، Integration، SSO و Vendor risk نیز راهنمای نرمافزار قدردانی مرجع مناسب است. این صفحه فقط روی Measurement model شبکه و Bias آن تمرکز دارد.
شبکه قدردانی دقیقاً چیست؟
در سادهترین مدل، کارکنان Node و پیامهای قدردانی Edge جهتدارند. اگر سارا از امیر تشکر کند، Edge از سارا به امیر ثبت میشود. Weight میتواند تعداد رخداد معتبر باشد؛ نه تعداد Like، Emoji یا ارزش ریالی پاداش، مگر Use case جداگانهای تعریف شده باشد.
| جزء | تعریف پیشنهادی | تصمیم لازم |
|---|---|---|
| Node | فرد واجد شرایط با شناسه تحلیلی | رسمی/قراردادی/پیمانکار؟ |
| Edge | یک Recognition معتبر از sender به recipient | پیام تیمی چگونه شکسته شود؟ |
| Weight | تعداد رخداد پس از Deduplication | Cap برای Spam؟ |
| Attribute | تیم، نقش، Site، Shift، tenure | تاریخ اعتبار هر ویژگی؟ |
| Window | مثلاً ۹۰ روز ثابت | Rolling یا Calendar؟ |
| Layer | Manager، Peer، Cross-team یا Channel | شبکهها جدا یا ترکیبی؟ |
چه چیزی Edge نیست؟
| رخداد | پیشنهاد | دلیل |
|---|---|---|
| Like یا Emoji | Edge Recognition حساب نشود | معنای مبهم و effort بسیار کم |
| پیام انبوه خودکار | لایه جدا/حذف | رابطه انسانی را تحریف میکند |
| تبریک تولد/سالگرد | Event type جدا | سهم کاری نیست |
| پاداش تأییدشده | Ledger جدا با link ID | ارزش مالی و کنترل متفاوت |
| کامنت روی پیام | Engagement فرعی | تأیید سهم جدید نیست |
| ذکر نام در متن آزاد | فقط پس از parsing/QA | خطای هویت و Context |
| پیام خصوصی خارج سیستم | Missing channel | نباید صفر فرض شود |
چهار Affordance شبکه داخلی داده را شکل میدهند
مرور Treem و Leonardi چهار Affordance مهم رسانه اجتماعی سازمانی را Visibility، Persistence، Editability و Association میداند. این چارچوب توضیح میدهد چرا Feed فقط کانال نیست؛ شکل مشاهده و ثبت رابطه را تغییر میدهد. مقاله مرور ارتباطات است و اثر Recognition یا عدالت را مستقیماً آزمایش نمیکند.
| Affordance | فرصت تحلیلی | ریسک | کنترل |
|---|---|---|---|
| Visibility | دیدن جریان Credit | Popularity loop | Private parity و access audit |
| Persistence | تحلیل زمانی | Context قدیمی/ماندگاری ناخواسته | Retention و expiry |
| Editability | اصلاح Attribution | تغییر بیردپا | Version log |
| Association | دیدن پیوند فرد–محتوا–سازمان | ساخت پروفایل رابطهای | Purpose limitation |
Enterprise Social Media با نمودار کامل سازمان یکی نیست
Leonardi، Huysman و Steinfield Enterprise Social Media را پلتفرمی تعریف میکنند که پیام، ویرایش/اشتراک محتوا و مشاهده ارتباطات را در مرز سازمان ممکن میکند و پیامدهای مثبت و منفی دارد. استفاده از یک ابزار به معنی ثبت همه روابط کاری نیست؛ تماس تلفنی، گفتوگوی حضوری، تیکت، کار شیفت و همکاری بیرون Feed غایباند.
| لایه واقعی کار | در Feed دیده میشود؟ | Bias محتمل |
|---|---|---|
| جلسه Demo | زیاد | Visibility بالا |
| تعمیر پیشگیرانه | کم | Outcome نامرئی |
| پشتیبانی تلفنی | کم/نامنظم | ردپای خارج Platform |
| همکاری همزمان با مدیر | زیادتر | Proximity bias |
| شیفت شب | کمتر | Time/access bias |
| پیام خصوصی | بسته به Policy | Privacy و missingness |
Boundary Specification پیش از هر Metric
Network metric بدون مرز جمعیت معنا ندارد. آیا Nodeها فقط کاربران فعالاند یا همه واجدان؟ اگر فقط کاربران را بگیرید، حذفشدگان از تحلیل حذف و Coverage مصنوعی بهتر میشود.
| مرز | پرسش | نسخه قابل دفاع |
|---|---|---|
| افراد | چه کسی باید امکان حضور داشته باشد؟ | Roster واجدان + access state |
| سازمان | تیم، شرکت یا گروه شرکتها؟ | Scope ثابت و مستند |
| زمان | کدام Window؟ | شروع/پایان ISO و شمسی |
| کانال | کدام Platformها؟ | Source inventory و missing channels |
| رابطه | کدام Event یک Edge است؟ | Event taxonomy نسخهدار |
| هویت | انتقال/تغییر نام چگونه حل میشود؟ | Stable pseudonymous ID |
داده شبکه چگونه جمعآوری میشود؟
مرور Marsden درباره داده و سنجش شبکه تفاوت شبکه کامل و Egocentric، منابع Survey/Archive/Observation و مسئله دقت، زمان و خطای سنجش را توضیح میدهد. داده Log دقیقاً چیزی را ثبت میکند که سیستم اجازه داده و کاربر انجام داده است؛ نه لزوماً رابطهای که تحلیلگر در ذهن دارد.
| منبع | مزیت | محدودیت | کاربرد |
|---|---|---|---|
| Platform log | زمان و Event دقیق | فقط رفتار داخل ابزار | Edge مشاهدهشده |
| HRIS roster | Denominator و attribute | تأخیر/خطای تاریخ | Eligibility و Segment |
| Survey | رابطه ادراکشده/خارج ابزار | Recall و nonresponse | Validation |
| Interview | Context و معنا | نمونه کوچک | Root cause |
| Work system | Opportunity/وابستگی | Purpose و Privacy | Exposure denominator |
Digital Trace چه خطاهایی میسازد؟
Howison، Wiggins و Crowston ده مسئله روایی در ترکیب Social Network Analysis و Digital trace data را بررسی میکنند. ردپای سیستم با داده Survey یکسان نیست و تعریف Node، Link، Boundary، Time و فعالیت واقعی نیازمند اعتبارسنجی است.
| خطا | نمونه Recognition | کاهش ریسک |
|---|---|---|
| Construct mismatch | Kudos بهجای همکاری | نام Metric محدود و روشن |
| Missing actors | کارکنان بدون ایمیل | Roster کامل و Non-user audit |
| Missing edges | تشکر حضوری | کانالهای گمشده گزارش شوند |
| False edge | Bot یا پیام Template | Event filter و نمونهخوانی |
| Temporal mismatch | تیم امروز با Edge ماه قبل | Attribute effective date |
| Identity error | دو حساب برای یک نفر | Identity resolution کنترلشده |
Sampling و حذف داده میتواند ساختار را عوض کند
González-Bailón و همکاران در نمونههای شبکه Twitter نشان دادند اندازه نمونه و تعریف مرز میتواند برآورد شبکه را سوگیر کند و فعالیت پیرامونی کمتر دیده شود. Context مطالعه شبکه عمومی و اعتراض سیاسی است، نه محیط کار؛ درس روششناختی آن این است که Export ناقص یا فیلتر API میتواند Centrality و Periphery را تحریف کند.
| فیلتر | اثر محتمل | آزمون QA |
|---|---|---|
| فقط Public feed | کمبرآورد Private preference | مقایسه aggregate کانالها |
| فقط ۹۰ روز اخیر API | حذف Edge قدیمی | Export coverage by date |
| فقط کاربران فعال | حذف Non-user | Roster reconciliation |
| حذف حساب بسته | Survivorship bias | Snapshot تاریخی |
| Search keyword | از دستدادن متن/زبان دیگر | Event ID نه keyword |
| فقط پیام موفق | Delivery failure نامرئی | error/retry log |
Centrality یک مفهوم واحد نیست
Freeman سه برداشت متمایز از Centrality را روشن میکند و میان جایگاه فرد و Centralization کل شبکه فرق میگذارد. در Recognition feed، In-degree، Out-degree و Betweenness پاسخهای متفاوتی دارند و هیچکدام Performance score نیستند.
| Metric | معنای فنی ساده | تفسیر مجاز | تفسیر ممنوع |
|---|---|---|---|
| In-degree | تعداد فرستنده/Edge ورودی | دیدهشدن در Feed | بهترین کارمند |
| Out-degree | تعداد گیرنده/Edge خروجی | فعالیت ارسال در ابزار | همدلترین فرد |
| Betweenness | قرارگرفتن روی مسیرهای کوتاه | نقش ساختاری در همان Graph | مالک همکاری واقعی |
| Closeness | فاصله شبکهای | فقط در Graph متصل و تعریفشده | دسترسی انسانی |
| Eigenvector | پیوند با Nodeهای پرپیوند | Prominence الگوریتمی | ارزش یا اعتبار |
| Centralization | تمرکز کل شبکه حول چند Node | ساختار Feed | فرهنگ سازمان |
هشت Metric حداقلی برای Dashboard
| Metric | تعریف | Denominator | تصمیم |
|---|---|---|---|
| Eligible coverage | گیرندگان یکتا / واجدان | Roster کامل | Access/visibility gap |
| Sender coverage | فرستندگان یکتا / واجدان | Roster کامل | موانع مشارکت |
| Cross-team share | Edge بین واحد / Edge معتبر | Edgeها | مرزهای فرایند |
| Reciprocity | Dyadهای دوسویه / Dyadهای ممکن مرتبط | تعریف ثابت | الگوی تبادل، نه الزام |
| Top-share | سهم ۱۰٪ بالای گیرنده از Edge | Edgeها | تمرکز Visibility |
| New-node reach | تازهواردان دریافتکننده / تازهواردان واجد | Cohort | Onboarding gap |
| Role gap | فاصله Coverage نقشها | هر Segment | Opportunity audit |
| Edge quality pass | نمونه پیام معتبر / نمونه | Audit sample | کیفیت، نه حجم |
Coverage را چگونه محاسبه کنیم؟
Recipient coverage = unique eligible recipients / eligible population. اگر ۱۲۰ نفر واجد باشند و ۷۸ نفر حداقل یک Edge معتبر دریافت کنند، Coverage برابر ۶۵٪ است. این عدد فقط میگوید ۴۲ نفر در Feed دیده نشدهاند؛ نمیگوید آنها در کار دیده نشده یا Contribution نداشتهاند.
| عدد لازم | مثال فرضی | کنترل |
|---|---|---|
| واجدان | ۱۲۰ | Roster و policy |
| گیرندگان یکتا | ۷۸ | Deduplicate identity |
| Coverage | ۶۵٪ | Window ثابت |
| Non-user واجد | ۱۸ | جدا از صفر Edge |
| Private-only preference | ۱۲ | عدم افشای فردی |
Reciprocity را به مسابقه تبدیل نکنید
Reciprocity میتواند تبادل دوسویه را نشان دهد، اما عدم تقابل لزوماً مشکل نیست. مدیر ممکن است بیشتر ارسال کند؛ نقش خدمات داخلی ممکن است از واحدهای متعدد دریافت کند؛ یا فرد ترجیح دهد تشکر را خصوصی نگه دارد. هدف «هر کس به من داد، من هم بدهم» نیست.
| الگو | توضیح ممکن | بررسی |
|---|---|---|
| دوسویه بالا در یک گروه کوچک | همکاری واقعی یا Clique | Cross-team و متن نمونه |
| یکسویه مدیر به تیم | نقش مدیریتی یا ضعف Peer | فرصت و هنجار |
| یکسویه مشتری داخلی | Service role | Work dependency |
| Reciprocity پایین کل | شبکه بزرگ/Window کوتاه | Baseline و size |
| جهش ناگهانی دوسویه | Campaign یا coordinated exchange | timestamp/text similarity |
تمرکز دیدهشدن را با Distribution بخوانید
میانگین Edge ممکن است تمرکز را پنهان کند. Median، Percentile، سهم Top ۱۰% و تعداد صفرها را کنار هم نمایش دهید. Gini یا HHI میتواند Sense-check باشد، اما Threshold جهانی «خوب/بد» ندارد و به اندازه شبکه، نقشها و فرصت بستگی دارد.
| شاخص | چه میبیند؟ | چه چیزی را نمیبیند؟ |
|---|---|---|
| Mean | حجم متوسط | چولگی |
| Median | فرد میانی | دم توزیع |
| Zero share | سهم بدون Edge | کانال خارج ابزار |
| Top 10% share | تمرکز بالای توزیع | استحقاق/Opportunity |
| Gini | نابرابری توزیع | علت و عدالت رویه |
| HHI | تمرکز سهمها | کیفیت پیام |
Opportunity to be seen را وارد Denominator کنید
فروشندهای که ماهانه ۳۰ Demo عمومی دارد با تحلیلگر زیرساختی که دو پروژه ششماهه دارد Opportunity یکسانی برای دیدهشدن ندارد. Raw count را رتبهبندی نکنید. ابتدا Exposure opportunity را از Workflow، حجم Case یا milestoneهای معتبر تعریف و با Guardrail استفاده کنید.
| نقش | Opportunity proxy | ریسک Proxy |
|---|---|---|
| فروش | Deal stage/hand-off | تمرکز بر Revenue |
| پشتیبانی | Case/complexity | تشویق Volume |
| QA | Release/risk review | Bug count gaming |
| امنیت | Control/incident prevention | اطلاعات حساس |
| منابع انسانی | service journey | Privacy پرونده |
| عملیات شیفت | handoff/maintenance cycle | ثبت ناقص آفلاین |
Cross-team flow را با ساختار کار مقایسه کنید
Edge بین واحدی زیاد همیشه Collaboration خوب نیست و کمبودن آن همیشه Silo نیست. دو واحد ممکن است وابستگی کاری کمی داشته باشند. ماتریس Recognition را کنار Dependency map یا Service catalog بخوانید.
| Dependency | Recognition flow | فرض | اقدام |
|---|---|---|---|
| بالا | بالا | Visibility همراستا | Quality sample |
| بالا | پایین | Credit/visibility gap | Handoff interview |
| پایین | بالا | Community tie یا Campaign | Context check |
| پایین | پایین | ممکن است طبیعی باشد | بدون مداخله فوری |
اگر مسئله Handoff و اعتبار بین واحدی است، راهنمای شکستن سیلوهای سازمانی مدل عملیاتی کاملتری دارد.
Isolate برچسب انسانی نیست
Node با degree صفر فقط در Graph و Window تعریفشده Edge ندارد. ممکن است تازهوارد، در مرخصی، بدون دسترسی، Private-only، قراردادی یا در نقش کمنمایان باشد. هیچ تماس خودکار «چرا کسی از تو تشکر نکرده؟» ارسال نکنید.
| علت احتمالی صفر Edge | داده امن | پاسخ مناسب |
|---|---|---|
| عدم دسترسی | access log aggregate | کانال جایگزین |
| تازهواردی | tenure cohort | بررسی onboarding |
| مرخصی | status بدون جزئیات پزشکی | خروج از Window |
| ترجیح خصوصی | preference state | عدم نمایش عمومی |
| نقش نامرئی | workflow interview | Contribution capture |
| داده ناقص | source reconciliation | رفع pipeline |
Manager و Peer را در یک Graph مخلوط نکنید
قدرت، فرصت و انتظار رفتاری متفاوت است. Manager-to-report، peer-to-peer، upward و cross-team layers را جدا تحلیل کنید. راهنمای طراحی روابط افقی و خطر Popularity در Peer Recognition منصفانه آمده است.
| Layer | Use case | ریسک |
|---|---|---|
| Manager → team | Coverage و کیفیت مدیریت | KPI اجباری |
| Peer ↔ peer | Visibility کار همکار | Popularity/reciprocity gaming |
| Employee → manager | Upward appreciation | قدرت و impression management |
| Cross-team | Handoff/Service recognition | واحدهای پرتماس |
| Executive → employee | سیگنال سازمانی | فاصله و selection bias |
Pipeline داده حداقلی
- Purpose، Population، Window و ممنوعیت استفاده را تصویب کنید.
- Roster snapshot با تاریخ اثر ویژگیها بگیرید.
- Event export شامل event_id، sender، recipient، timestamp، channel و type بگیرید.
- حساب Bot، تست، حذفشده و Duplicate را طبق Rule ثابت جدا کنید.
- شناسهها را در لایه تحلیلی pseudonymize و mapping را محدود کنید.
- Eligibility و access state را Join و reconciliation report بسازید.
- Graphهای Manager، Peer و Cross-team را جدا تولید کنید.
- Metric، uncertainty، missing channel و QA sample را محاسبه کنید.
- فقط Aggregate لازم برای تصمیم را منتشر و داده موقت را طبق Retention حذف کنید.
Data Dictionary پیشنهادی
| Field | تعریف | نوع | کنترل |
|---|---|---|---|
| event_id | شناسه یکتای رخداد | string | Dedup key |
| sender_pid | شناسه تحلیلی فرستنده | pseudonymous | mapping restricted |
| recipient_pid | شناسه تحلیلی گیرنده | pseudonymous | team award rule |
| occurred_at | زمان رخداد | ISO timestamp | timezone stored |
| event_type | work/anniversary/system | enum | versioned taxonomy |
| visibility | private/team/org | enum | consent state |
| team_at_time | واحد در زمان رخداد | effective-dated | HRIS snapshot |
| source | platform/channel | enum | coverage note |
| valid_edge | شمول در Graph | boolean | reason code |
QA داده پیش از Dashboard
| آزمون | Threshold محلی | اگر شکست خورد |
|---|---|---|
| Roster reconciliation | از پیش تعیین شود | انتشار متوقف |
| Duplicate rate | Baseline + anomaly | Rule/Integration بررسی |
| Bot share | جداگانه گزارش | Graph انسانی پاکسازی |
| Timestamp completeness | تقریباً کامل | Window analysis متوقف |
| Team effective date | برای تغییرها معتبر | Segment suppression |
| Private consent state | کامل برای انتشار | Public metric حذف |
| API/export coverage | بازه کامل | Missingness note/repair |
Spam، Bot و Coordinated Kudos را چگونه تشخیص دهیم؟
پرچم الگوریتمی فقط برای Review است، نه مجازات. افزایش Edge میتواند نتیجه Campaign مشروع باشد. Pattern را با Context و نمونهخوانی بررسی کنید.
| Signal | توضیح بیخطر ممکن | بررسی | اقدام ممنوع |
|---|---|---|---|
| Burst زمانی | پایان پروژه | calendar/event | حذف خودکار |
| متن بسیار مشابه | Template آموزشی | quality sample | برچسب تقلب |
| Dyad پرتکرار | همکاری روزانه | dependency | کاهش امتیاز مخفی |
| Loop کوچک | تیم کوچک | team size/window | نامبردن عمومی |
| Bot sender | workflow automation | account registry | ترکیب با Peer graph |
AI برای تحلیل متن چه مرزی دارد؟
- هدف، داده ورودی، Vendor، محل پردازش و Retention را پیش از ارسال متن روشن کنید.
- اطلاعات مشتری، پزشکی، امنیتی، شکایت و تحقیقات را از Corpus خارج کنید.
- Classification رفتار/ارزش را با نمونه فارسی و Human review ارزیابی کنید.
- Sentiment یا «اصالت تشکر» را Truth فردی ننامید.
- مدل نباید Performance، Loyalty یا attrition risk فردی تولید کند.
- False positive/negative را برحسب نقش و زبان/گویش بررسی کنید.
- Kill switch، correction path و log نسخه مدل داشته باشید.
حریم خصوصی: Graph رابطهای حساستر از جدول شمارش است
حتی شناسه pseudonymous ممکن است با تیم کوچک و الگوی Edge دوباره قابلشناسایی باشد. دسترسی به Graph خام را بسیار محدودتر از Dashboard Aggregate نگه دارید.
| سطح داده | دسترسی پیشنهادی | Retention | انتشار |
|---|---|---|---|
| Raw text | عملیات محدود | حداقل لازم | خیر |
| Identity mapping | Data steward | جدا و رمزگذاریشده | خیر |
| Edge pseudonymous | تحلیلگران مجاز | Window + audit need | خیر |
| Team aggregate | مالک تصمیم | Trend period | با small-cell rule |
| Org summary | Leadership/کارکنان | گزارش نسخهدار | با Context |
استفادههای ممنوع را مکتوب کنید
- رتبهبندی فردی برای Performance، Bonus، Promotion یا اخراج
- ساخت امتیاز «محبوبیت»، «فرهنگپذیری»، «وفاداری» یا «ریسک خروج»
- تماس با فرد دارای صفر Edge بدون بررسی Access و Context
- اجبار مدیر یا کارمند به سهمیه ارسال برای سبزکردن Dashboard
- نمایش Social graph خام به مدیران یا همکاران
- ترکیب پنهانی با ایمیل، چت خصوصی یا داده سلامت
- استنتاج رابطه شخصی، دوستی، تعارض یا اتحاد سیاسی
- بازاستفاده بیرونی از پیام داخلی بدون Consent جداگانه
عدالت را در چهار سطح بسنجید
| سطح | پرسش | Metric/شاهد |
|---|---|---|
| Access | چه کسی میتواند بفرستد/بگیرد؟ | eligible vs provisioned vs active |
| Opportunity | چه کارهایی قابلیت دیدهشدن دارند؟ | workflow/dependency map |
| Distribution | Edge/quality چگونه توزیع شده؟ | coverage، zero، top-share |
| Process | قاعده، correction و appeal روشن است؟ | policy و case log |
Metric توزیعی بهتنهایی عدالت را ثابت نمیکند. برای تفکیک عدالت توزیعی، رویهای، بینفردی و اطلاعاتی، ممیزی عدالت سازمانی را ببینید.
Non-user را داده گمشده بدانید، نه فرد بیمشارکت
ممکن است کارکنان شیفت، فروشگاه، کارخانه، پیمانکار یا افراد دارای نیاز دسترسپذیری وارد ابزار نشوند. نرخ Adoption را فقط میان Loginکنندگان نسنجید. برای فهم Nonresponse و فشار مشارکت، راهنمای نرخ پاسخ کارکنان منطق مشابهی برای Denominator و محرمانگی دارد.
| State | معنا | اقدام |
|---|---|---|
| Eligible-not-provisioned | شکست دسترسی | IT/Policy repair |
| Provisioned-never-login | مانع یا عدم نیاز | مصاحبه نمونهای |
| Login-no-edge | مشاهده بدون ارسال/دریافت | Context، نه Nudging فردی |
| Private-only | ترجیح کانال | Parity و Aggregate |
| Opt-out analytics | انتخاب داده | احترام و missingness note |
تحلیل کیفی، Network metric را قابلفهم میکند
از هر Segment چند رخداد مشخص را با رضایت بررسی کنید. سؤال «چرا کمفعالید؟» دفاعی است؛ درباره آخرین سهم دیدهشده یا نامرئی بپرسید.
- آخرین کاری که در Feed دیده شد چه بود و چرا دیده شد؟
- کدام سهمهای مهم شما خارج ابزار میماند؟
- آیا کانال Public/private با ترجیحتان سازگار است؟
- چه کسی معمولاً میتواند شاهد کار شما باشد؟
- کدام وابستگی بین تیمی در پیامها گم میشود؟
- آیا متن، Reaction یا اعلان فشار اجتماعی ایجاد میکند؟
- اگر Edge اشتباه باشد، مسیر اصلاح را میشناسید؟
Metric برابر اثر برنامه نیست
افزایش Edge یا Cross-team share میتواند از Training، Campaign، تغییر Headcount، Integration جدید یا سهمیه مدیر بیاید. برای سنجش Outcome و اثر علی، راهنمای سنجش اثربخشی برنامه قدردانی را استفاده کنید.
| تغییر مشاهدهشده | فرض مطلوب | فرض رقیب | داده تکمیلی |
|---|---|---|---|
| Coverage بالا رفت | دیدهشدن گستردهتر | پیام انبوه | quality audit |
| Reciprocity بالا رفت | تبادل Peer | gaming | text/time/dependency |
| Cross-team بالا رفت | اعتبار Handoff | کمپین مرکزی | event type |
| Zero share کم شد | Access بهتر | Bot anniversary | human-edge filter |
| Concentration کم شد | توزیع بهتر | کیفیت پایین همگانی | recipient experience |
سناریوی ایرانی ۱: تیم دورکار چندشهری
مثال فرضی است. یک شرکت نرمافزاری ۱۲۰نفره در تهران، شیراز، مشهد و تبریز کانال Kudos دارد. Dashboard میگوید ۷۸ نفر در ۹۰ روز دیده شدهاند و ۶۵٪ Coverage دارد. اما ۱۸ نفر پیمانکار به Workspace دسترسی کامل ندارند و ۱۲ نفر Public recognition را نمیخواهند.
تشخیص
- Denominator کاربران فعال، شکاف پیمانکار را پنهان کرده بود.
- Public-only export، Recognition خصوصی را صفر نشان میداد.
- تیم تهران بهدلیل ساعت مشترک با مدیران Edge بیشتری داشت.
- سه فرستنده پرکار ۳۱٪ پیامها را ساخته بودند؛ کیفیت بخشی از آنها Template بود.
اصلاح
- Roster واجدان و access state به Graph اضافه میشود.
- Public و Private فقط در Aggregate و بدون افشای متن ترکیب میشوند.
- Manager، Peer و Bot layers جدا میشوند.
- Coverage، zero share، top-share و quality pass برحسب شهر/نوع قرارداد، بالای آستانه محرمانگی گزارش میشود.
- هیچ Score فردی ساخته نمیشود؛ تصمیم اول رفع دسترسی پیمانکار است.
سناریوی ایرانی ۲: سازمان چندسایتی و شیفتی
مثال فرضی است. یک شرکت پخش با دفتر مرکزی و سه انبار، قدردانی را در پیامرسان داخلی ثبت میکند. دفتر مرکزی موبایل و اینترنت پایدار دارد؛ اپراتورهای انبار فقط در کیوسک پایان شیفت دسترسی دارند. Raw count نشان میدهد دفتر مرکزی «فرهنگ قدردانی قویتری» دارد.
تشخیص
- Metric اصلی Access difference را با Culture difference اشتباه گرفته است.
- Opportunity دفتر مرکزی مبتنی بر پیام و جلسه بیشتر است.
- Recognition سرپرست شیفت شفاهی است و در Export نمیآید.
- جابجایی کارکنان بین انبارها با Team فعلی Join شده و Edge تاریخی غلط Segment شده است.
اصلاح
- کانال ثبت ساده پایان شیفت با امکان عدم انتشار عمومی اضافه میشود.
- Team_at_time با تاریخ اثر از HRIS بازسازی میشود.
- Digital coverage و total sampled recognition جدا گزارش میشوند.
- مقایسه Site فقط پس از Access parity و Window مشابه انجام میشود.
برنامه ۹۰روزه راهاندازی تحلیل شبکه
روزهای ۱ تا ۳۰: Contract و داده
- Purpose، Non-use، Population، Edge، Window و retention را تصویب کنید.
- Roster، access state، account registry و source inventory بسازید.
- Data dictionary و effective-date rule را با HR/IT تست کنید.
- یک Export نمونه را با ۲۰ رخداد دستی reconciliation کنید.
- Privacy review، small-cell threshold و نقشهای دسترسی را ثبت کنید.
روزهای ۳۱ تا ۶۰: Baseline و اعتبارسنجی
- Graphهای Human/Bot و Manager/Peer/Cross-team را جدا بسازید.
- هشت Metric حداقلی را با missingness و denominator منتشر کنید.
- نمونه Quality و مصاحبه Non-user را انجام دهید.
- Metricها را با Dependency map و Calendar رویدادها مقایسه کنید.
- سه فرض رقیب برای هر یافته مهم بنویسید.
روزهای ۶۱ تا ۹۰: تصمیم و Guardrail
- یک شکاف Access و یک شکاف Visibility را برای اصلاح محدود انتخاب کنید.
- Decision rule و owner را پیش از موج بعدی تعیین کنید.
- Dashboard Aggregate را با Context note و تاریخ داده منتشر کنید.
- Red-team برای re-identification و استفاده تنبیهی اجرا کنید.
- تصمیم Continue، Repair، Hold یا Stop و موعد review بعدی را ثبت کنید.
Decision Gate
| وضعیت | شاهد | تصمیم |
|---|---|---|
| Roster/Export منطبق و missingness محدود | QA pass | تحلیل Aggregate ادامه یابد |
| Non-user زیاد یا نامتقارن | Access gap | Metric فرهنگ منتشر نشود |
| Metric با مصاحبه ناسازگار | Construct mismatch | تعریف Edge/Scope اصلاح شود |
| شکاف با Opportunity توضیح داده میشود | Workflow evidence | Normalization/طراحی کار |
| ریسک شناسایی Small cell | Privacy review | Suppress/aggregate |
| درخواست Score فردی | Non-use breach | Stop و escalation |
RACI
| کار | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| تعریف Purpose/Non-use | People Analytics | Head of People | Privacy/نماینده کارکنان | Leadership |
| استخراج و دسترسی | Data/IT | Data owner | Security/Vendor | HR |
| تعریف Edge/Metric | Analyst | Analytics lead | People Ops/Operations | Program owner |
| Quality sample | People Ops | Program owner | کارکنان/Comms | Analyst |
| Privacy release | Privacy | Data owner | Legal/Security | Steering group |
| Decision/repair | Process owner | Executive sponsor | HRBP/employee voice | سازمان |
قالب گزارش یکصفحهای
این گزارش شبکه [نوع Recognition] را برای [Population] در بازه [تاریخ] بر پایه [Sourceها] نشان میدهد. [درصد] واجدان به ابزار دسترسی داشتند و [کانالهای گمشده] در Graph نیستند. Coverage، Concentration، Reciprocity و Cross-team flow فقط رفتار مشاهدهشده در سیستماند و برای ارزیابی فردی استفاده نمیشوند. یافته اصلی [الگو] است؛ فرضهای رقیب [موارد] و اقدام پیشنهادی [Repair/Test] با مالک [نقش] است.
چکلیست قبل از انتشار Dashboard
- Purpose و استفادههای ممنوع تصویب شدهاند.
- Roster واجدان، Non-user و access state در Denominator هستند.
- Node، Edge، Weight، Layer و Window نسخهدارند.
- Bot، Event خودکار، Duplicate و Private preference مدیریت شدهاند.
- Attributeها در زمان رخداد معتبرند.
- Manager، Peer و Cross-team جدا گزارش میشوند.
- Mean با Median، zero share و concentration همراه است.
- Opportunity و کانالهای خارج سیستم در تفسیر آمدهاند.
- Small cell و re-identification بررسی شدهاند.
- هیچ Score فردی یا تصمیم تنبیهی ساخته نشده است.
- یافته مهم با نمونه متن/مصاحبه و فرض رقیب اعتبارسنجی شده است.
- Metric بهعنوان اثر علی یا فرهنگ کامل سازمان نامگذاری نشده است.
جمعبندی
شبکه اجتماعی داخلی یک آینه کامل از سازمان نیست؛ یک سنسور محدود با میدان دید، خطا و رفتارپذیری خاص است. Recognition Network Analysis زمانی مفید است که Roster کامل، Edge روشن، Window ثابت، لایههای جدا، داده گمشده و Opportunity را همراه Metric نگه دارد.
Coverage، Reciprocity، Concentration و Cross-team flow سؤال بهتر میسازند؛ پاسخ نهایی یا ارزشگذاری افراد نیستند. با Privacy، Aggregate reporting، Validation کیفی و Decision gate میتوان از داده برای رفع شکاف دسترسی و دیدهشدن استفاده کرد، بدون اینکه Feed به سیستم نظارت و محبوبیت تبدیل شود.
سؤالات متداول
آیا تعداد تشکرهای دریافتی معیار عملکرد کارکنان است؟
خیر. تعداد Edge تحت تأثیر نقش، فرصت دیدهشدن، دسترسی، شبکه ارتباطی، ترجیح عمومی/خصوصی و رفتار Platform است. از آن برای Performance، ارتقا، پاداش یا اخراج استفاده نکنید.
بهترین Metric برای شبکه قدردانی چیست؟
یک Metric برنده وجود ندارد. حداقل Coverage فرستنده/گیرنده، zero share، concentration، cross-team share، quality sample و access gap را کنار هم و با Denominator روشن بخوانید.
Reciprocity پایین یعنی فرهنگ ضعیف است؟
نه. اندازه شبکه، Window، نقشها، وابستگی کار و ترجیح کانال بر Reciprocity اثر دارند. آن را Signal برای بررسی بدانید، نه نمره فرهنگ یا تکلیف به جبران تشکر.
با افرادی که هیچ Recognition نگرفتهاند چه کنیم؟
ابتدا دسترسی، tenure، مرخصی، نقش، Preference، کانال خارج سیستم و خطای داده را بررسی کنید. تماس فردی یا برچسب «نامرئی» بدون Context میتواند آسیبزا باشد؛ مسئله را در سطح فرایند اصلاح کنید.
آیا میتوان از AI برای کشف تبعیض در پیامهای قدردانی استفاده کرد؟
AI میتواند ابزار غربالگری محدود باشد، اما حقیقت یا تصمیمگیر نیست. Purpose، داده حساس، نمونه فارسی، خطا در گروهها، Human review، correction و ممنوعیت Score فردی باید پیشاپیش تعریف شوند.
