نقش‌ها و مسئولیت‌ها در استقرار مدل ۳۴۰۰۰

تعریف نقش‌ها و مسئولیت‌ها در استقرار مدل ۳۴۰۰۰ باید همین گره را باز کند. هدف، افزودن عنوان‌های سازمانی نیست؛ باید روشن شود چه کسی کار را انجام می‌دهد، چه کسی نتیجه را می‌پذیرد و وقتی مانعی خارج از اختیار تیم ایجاد می‌شود، تصمیم از کجا می‌آید.

نقش را با عنوان شغلی اشتباه نگیرید

عنوان «مدیر منابع انسانی» به‌تنهایی تمام مسئولیت‌های پروژه را مشخص نمی‌کند. یک نفر ممکن است هم مدیر پروژه و هم مالک یک فرایند باشد، اما باید بداند در هر نقش چه تصمیمی می‌گیرد. در سازمان بزرگ نیز ممکن است چند فرد، نقش‌های متفاوتی را بر عهده داشته باشند.

ساختار پیشنهادی این مقاله، الگوی حکمرانی پروژه است؛ تعداد پست‌ها یا کمیته‌های الزامی مدل نیست. در نسخه معتبر اسناد مدل باید مسئولیت‌ها و تأییدهای مورد نیاز همان ارزیابی بررسی شود. برای طراحی برنامه کلی، مقاله نقشه راه استقرار مدل ۳۴۰۰۰ مکمل این بحث است.

حامی پروژه؛ پاسخ‌گویی به چرایی و پشتیبانی تغییر

حامی پروژه (Project Sponsor) باید بتواند ارتباط پروژه با اولویت سازمان را توضیح دهد و برای موانع فراتر از اختیار تیم، تصمیم یا حمایت فراهم کند. این نقش با حضور تشریفاتی در جلسه آغاز پایان نمی‌یابد.

• هدف و حدود اختیار پروژه را تأیید می‌کند.
• درباره تعارض اولویت‌ها و منابع، در حدود اختیار خود تصمیم می‌گیرد.
• همکاری مدیران کلیدی را پیگیری می‌کند.
• در نقاط مهم، ادامه، اصلاح دامنه یا توقف را بررسی می‌کند.
• اطمینان می‌یابد نتیجه مورد انتظار، مالک پیگیری دارد.

حامی لازم نیست همه جزئیات اجرایی را مدیریت کند؛ اما اگر هیچ تصمیم مؤثری در اختیار او نیست، انتخاب این عنوان مشکل پروژه را حل نمی‌کند.

مدیر پروژه؛ مسئول هماهنگی تحویل

مدیر پروژه (Project Manager) برنامه، وابستگی‌ها، مسائل باز و تحویل خروجی‌ها را هماهنگ می‌کند. او باید وضعیت واقعی را گزارش دهد؛ نه فقط درصدی از فعالیت‌های انجام‌شده را.

برای مثال، اگر راهنمای مصاحبه آماده شده اما مدیران هنوز برای اجرای آن آموزش ندیده‌اند، مدیر پروژه نباید کل بسته اجرا را تمام‌شده اعلام کند. او موضوع را ثبت، اثر آن را روشن و تصمیم لازم را پیگیری می‌کند. اختیار هزینه، تغییر دامنه و جابه‌جایی افراد نیز باید صریح باشد؛ عنوان مدیر پروژه، این اختیارها را خودکار ایجاد نمی‌کند.

مالک فرایند؛ مسئول ادامه کار پس از پروژه

مالک فرایند (Process Owner) باید درباره طراحی، کیفیت اجرا و بهبود مستمر فرایند پاسخ‌گو باشد. مدیر پروژه ممکن است پس از تحویل کنار برود، اما مالک فرایند باید ادامه کار را اداره کند.

در مدیریت عملکرد، مالک فرایند درباره قواعد، تقویم، کیفیت اطلاعات و سازوکار بازبینی مسئولیت دارد؛ مدیران صف نیز مسئول اجرای درست گفت‌وگو و تصمیم‌های مربوط به کارکنان خود هستند. واگذاری همه این مسئولیت‌ها به یک کارشناس ستادی، نقش مدیران را حذف نمی‌کند.

مدیران اجرایی و کارکنان چه نقشی دارند؟

مدیران اجرایی باید محدودیت‌های کار واقعی را وارد طراحی کنند، زمان مشارکت را فراهم سازند و مسئولیت اجرای توافق‌شده را بپذیرند. کارکنان نیز صرفاً منبع اطلاعات یا مخاطب اطلاعیه نیستند؛ تجربه آن‌ها می‌تواند نارسایی طراحی را آشکار کند.

مشارکت به معنای واگذاری همه تصمیم‌ها به همه افراد نیست. باید روشن باشد کجا نظرخواهی می‌شود، کجا طراحی مشترک انجام می‌گیرد و کدام مرجع تصمیم نهایی را دارد. اگر نظر افراد تغییری در تصمیم ایجاد نکرد، توضیح محترمانه درباره دلیل انتخاب نیز بخشی از ارتباط حرفه‌ای است.

در فرایندهای خاص، نقش‌ها باید دقیق‌تر شوند. برای نمونه، در مدیریت عملکرد در مدل ۳۴۰۰۰، مسئولیت مدیر مستقیم با مسئولیت متولی نظام عملکرد یکسان نیست.

جدول تقسیم مسئولیت چه کمکی می‌کند؟

ماتریس تقسیم مسئولیت (RACI) چهار نوع مشارکت را تفکیک می‌کند:

• مجری مسئول (Responsible): کار یا خروجی را انجام می‌دهد.
• پاسخ‌گوی نهایی (Accountable): درباره تکمیل و نتیجه آن پاسخ‌گوست و اختیار متناسب دارد.
• طرف مشورت (Consulted): پیش از تکمیل یا تصمیم، نظر تخصصی یا اجرایی می‌دهد.
• مطلع (Informed): اطلاعات لازم را دریافت می‌کند.

برای هر خروجی، یک پاسخ‌گوی نهایی مشخص کنید. اگر چند مرجع باید تصویب‌های متفاوت بدهند، آن‌ها را به تصمیم‌های جداگانه با حدود اختیار روشن تبدیل کنید. نوشتن چند حرف در خانه‌های جدول، جای توافق واقعی را نمی‌گیرد.

نمونه پیشنهادی تقسیم کار در پروژه

در جدول زیر، عنوان نقش‌ها باید به افراد مشخص و دارای اختیار متصل شود. این نمونه، نسخه رسمی تقسیم کار مدل نیست.

اگر در یک سازمان کوچک، یک فرد چند نقش دارد، این موضوع را شفاف ثبت کنید. برای بازبینی خروجی‌های حساس نیز تا حد امکان از فرد دیگری با صلاحیت متناسب کمک بگیرید تا تهیه و تأیید، صرفاً به بازبینی کار خود محدود نماند.

نقش داده و فناوری را از ابتدا روشن کنید

مسئول استخراج داده، تعریف شاخص، تأیید عدد و مدیریت دسترسی ممکن است افراد متفاوتی باشند. اگر همه این کارها با عبارت «واحد فناوری انجام دهد» واگذار شوند، احتمال ابهام زیاد است. فناوری می‌تواند گزارش بسازد؛ اما تعریف مدیریتی شاخص باید صاحب مشخص داشته باشد.

برای این بخش، شناسنامه شاخص‌ها و کنترل کیفیت داده منابع انسانی را به جدول مسئولیت متصل کنید. دسترسی به اطلاعات کارکنان نیز باید متناسب با نیاز واقعی نقش باشد.

مشاور چه کاری انجام دهد و چه چیزی را جایگزین نکند؟

مشاور می‌تواند در تشخیص، تسهیل گفت‌وگو، طراحی، آموزش و بازبینی کمک کند. اما پذیرش تغییر، تصمیم سازمانی و اداره پایدار فرایند همچنان به نقش‌های داخلی نیاز دارد. تحویل مجموعه‌ای از فایل‌ها، به‌تنهایی انتقال قابلیت نیست.

در تعریف همکاری، خروجی قابل پذیرش، مشارکت تیم داخلی، نحوه انتقال دانش و تحویل مستندات را روشن کنید. همچنین کسی که راه‌حل را طراحی کرده، نباید صرفاً با اتکا به نظر خودش، موفقیت آن را قطعی اعلام کند؛ شواهد اجرا و بازبینی مناسب لازم است.

وقتی کار متوقف شد، مسیر ارجاع چیست؟

برای مسئله‌های خارج از اختیار مجری، مسیر ارجاع (Escalation) تعریف کنید: چه اطلاعاتی ارائه می‌شود، موضوع به چه کسی می‌رسد و چه تصمیمی لازم است. حدود زمان، هزینه و دامنه باید با قواعد همان سازمان تعیین شوند؛ عدد یکسانی برای همه پروژه‌ها مناسب نیست.

نکتهگزارش مانع را با درخواست تصمیم همراه کنید: «دو واحد درباره تعریف شاخص اختلاف دارند؛ این دو گزینه، این پیامدها و این مرجع پیشنهادی تصمیم است.» انتقال صرف مشکل به جلسه بعد، مسیر ارجاع مؤثر نیست.

تجربه خانه منابع انسانی

در نگاه خانه منابع انسانی، یکی از پرسش‌های مهم آغاز پروژه این است: «بعد از رفتن تیم پروژه، چه کسی این تصمیم را هر روز اجرا می‌کند؟» در یک سناریوی فرضی، مشاور فرم ارزیابی را طراحی کرده، منابع انسانی آن را ابلاغ می‌کند و مدیران تصور می‌کنند تکمیل اطلاعات وظیفه کارشناس منابع انسانی است.

مسئله با یادآوری بیشتر حل نمی‌شود. باید مسئولیت گفت‌وگو، ثبت شواهد، بازبینی و رسیدگی به اختلاف‌ها روشن شود و مدیران برای انجام نقش خود آماده باشند. طراحی نقش‌ها، بخشی از طراحی فرایند است؛ نه پیوستی که در پایان پروژه تکمیل شود.