تحویل کار بین واحدها؛ چه زمانی مسئولیت واقعاً منتقل شده است؟

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

برای جلوگیری از این وضعیت، تحویل کار بین واحدها به سه جزء نیاز دارد: مسئول مشخص در هر سمت، معیار روشن برای آماده‌بودن کار و ثبت پذیرش یا بازگشت آن. این چارچوب برای مدیران عملیات و مدیران واحدهاست که می‌خواهند زمان انتظار، دوباره‌کاری و اختلاف دربارهٔ مسئولیت را کاهش دهند؛ نه اینکه برای هر درخواست ساده یک فرایند سنگین بسازند.

ارسال، آماده‌بودن و پذیرش یک اتفاق نیستند

در یک تحویل بین‌واحدی، سه لحظه را باید از هم جدا کرد. نخست، واحد فرستنده اطلاعات را ارسال می‌کند. سپس کار زمانی «آمادهٔ تحویل» است که حداقل اطلاعات و تأییدهای لازم را داشته باشد. در نهایت، واحد دریافت‌کننده آن را می‌پذیرد و مسئولیت اقدام بعدی را بر عهده می‌گیرد. اگر این سه وضعیت با یک برچسب مانند «ارسال شد» نشان داده شوند، معلوم نیست کار فقط فرستاده شده یا واقعاً وارد برنامهٔ واحد بعدی شده است.

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

مالک هر مرحله و مسیر رفع اختلاف را مشخص کنید

برای هر نقطهٔ تحویل، دست‌کم سه نقش را روشن کنید:

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

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

این تفکیک با تفویض اختیار یکی نیست. تفویض اختیار می‌گوید چه کسی حق دارد دربارهٔ مبلغ، شرایط یا استثنا تصمیم بگیرد؛ تحویل بین واحدها مشخص می‌کند پرونده چه زمانی و با چه اطلاعاتی از یک مسئول به مسئول بعدی می‌رسد. اگر مرز تصمیم‌گیری هم مبهم است، راهنمای ماتریس تفویض اختیار می‌تواند مکمل این فرایند باشد.

بستهٔ تحویل را از نیاز واقعی واحد مقصد بسازید

قالب تحویل باید پرسش‌هایی را پاسخ دهد که واحد مقصد برای شروع کار دارد. در بیشتر فرایندها، این بسته می‌تواند شامل هدف درخواست، وضعیت فعلی، موعد، اولویت، تصمیم‌های قبلی، مدارک مرتبط، ریسک‌های شناخته‌شده و اقدام بعدی باشد. اما این فهرست را نباید بدون بررسی به همهٔ کارها تحمیل کرد.

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

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

مثال فرضی: تحویل سفارش ویژه از فروش به عملیات

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

برای این فرایند می‌توان معیار تحویل را چنین تعریف کرد: مشخصات نهایی کالا، مقدار، موعد تعهدشده به مشتری، وضعیت تأیید فنی، شرایط پرداخت، نتیجهٔ بررسی ظرفیت و تصمیم لازم دربارهٔ هر استثنا. مسئول فروش بسته را آماده می‌کند و مسئول عملیات یکی از سه پاسخ را ثبت می‌کند: «پذیرفته شد»، «برای تکمیل بازگشت داده شد» یا «برای تصمیم مدیریتی متوقف است». در دو حالت اخیر، دلیل و مسئول اقدام بعدی نیز باید روشن باشد.

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

وضعیت‌ها را کم اما معنادار نگه دارید

برای بسیاری از فرایندها، پنج وضعیت کافی است: «در حال آماده‌سازی»، «آمادهٔ پذیرش»، «پذیرفته‌شده»، «مسدود» و «تکمیل‌شده». هر وضعیت باید شرط مشخصی داشته باشد. برای نمونه، «آمادهٔ پذیرش» یعنی اطلاعات الزامی تکمیل شده و واحد مقصد می‌تواند دربارهٔ پذیرش تصمیم بگیرد؛ نه اینکه فقط فایلی بارگذاری شده باشد.

ثبت وضعیت وقتی ارزش دارد که مدیر بتواند از آن برای یافتن گلوگاه استفاده کند. سه سنجهٔ ساده می‌تواند مفید باشد:

• زمان از «آمادهٔ پذیرش» تا پاسخ واحد مقصد؛
• تعداد موارد بازگشتی و علت‌های پرتکرار آن‌ها؛
• تعداد کارهای مسدود که مسئول اقدام بعدی یا موعد روشن ندارند.

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

از یک نقطهٔ اصطکاک شروع کنید

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

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