گاهی یک سفارش بیشتر از آنکه در سازمان پردازش شود، بین واحدها منتظر میماند؛ فروش منتظر مالی است، مالی منتظر تکمیل اطلاعات و عملیات منتظر تصمیمی که هیچکس مسئول نهایی آن نیست.
همه از وضعیت ناراضیاند، اما وقتی پیشنهاد اصلاح فرآیند مطرح میشود، همان افراد نگران میشوند:
- «یعنی از این به بعد باید کار واحد دیگری را هم انجام بدهیم؟»
- «قرار است اطلاعات عملکرد ما در اختیار همه قرار بگیرد؟»
- «اگر این کنترل حذف شود، مسئول خطای بعدی چه کسی است؟»
اینجاست که مسئله واقعی خودش را نشان میدهد: اصلاح فرآیندهای بینواحدی فقط تغییر ترتیب فعالیتها نیست؛ تغییر در مسئولیت، اختیار، حجم کار و شیوه پاسخگویی افراد است.
بنابراین، اگر منظورتان از «بدون ایجاد مقاومت» این است که هیچکس هیچ مخالفتی نکند، چنین تضمینی واقعبینانه نیست. اما میتوان تغییر را طوری طراحی کرد که مقاومت غیرضروری کمتر شود، نگرانیهای معتبر شنیده شوند و کارکنان بهجای دریافتکننده دستور، در طراحی راهحل نقش داشته باشند.
پیشنهاد من این است: بهجای شروع از نمودار فرآیند، از مسئله مشترک و نگرانی آدمها شروع کنید.
چرا اصلاح فرآیندهای بینواحدی حساسیت ایجاد میکند؟
فرآیند بینواحدی، مانند «از دریافت سفارش تا تحویل» یا «از درخواست خرید تا پرداخت»، از مرز چند واحد عبور میکند. بااینحال، افراد معمولاً بر اساس عملکرد واحد خودشان ارزیابی میشوند، نه نتیجه کل فرآیند.
- فروش به دنبال ثبت سریع سفارش است.
- مالی باید ریسک وصول مطالبات را کنترل کند.
- عملیات به برنامهای قابل اتکا برای اجرا نیاز دارد.
هیچکدام از این خواستهها ذاتاً اشتباه نیستند. تعارض وقتی شکل میگیرد که سازمان از هر واحد بخواهد هدف خودش را بهینه کند، بدون اینکه درباره نتیجه مشترک توافقی وجود داشته باشد.
مقاومت همیشه مخالفت با بهبود نیست
پشت جمله «این روش در سازمان ما جواب نمیدهد»، ممکن است یکی از این نگرانیها پنهان باشد:
| رفتار مشاهدهشده | نگرانی احتمالی | پاسخ مناسب |
|---|---|---|
| مخالفت با شفافشدن زمان فعالیتها | ترس از مقصر شناختهشدن | توافق درباره استفاده اصلاحی از دادهها |
| اصرار بر حفظ تأییدهای متعدد | نگرانی از مسئولیت خطا | روشنکردن کنترل جایگزین و حدود اختیار |
| همکارینکردن در جلسات | کمبود ظرفیت یا بی مشخص | اختصاص زمان و تعریف خروجی مشخص |
| اعتراض به فرم جدید | افزایش قبلی | حذف ثبت موازی و بررسی بار کاری |
| اعتراض به فرم جدید | افزایش ثبت اطلاعات و دوبارهکاری | مشارکت واقعی در طراحی و آزمون |
| دفاع شدید از روش فعلی | نگرانی از نادیدهگرفتن تجربه کارکنان |
در راهنمای مدیریت مقاومت Prosci، شنیدن و فهم اعتراضها و مشارکتدادن افراد در چگونگی اجرای تغییر، از اقدامات مهم مدیریت مقاومت معرفی شدهاند.
نتیجه عملی روشن است: قبل از پاسخدادن به مخالفت، بفهمید مخالفت دقیقاً درباره چیست.
گام اول: مسئله را مشترک تعریف کنید، نه مقصر را
شروع جلسه با جمله «واحد مالی گلوگاه فرآیند است» احتمالاً بحث را از همان ابتدا دفاعی میکند. جمله مناسبتر این است:
«میخواهیم زمان بین ثبت سفارش و اعلام نتیجه بررسی مالی را کاهش دهیم، بدون اینکه ریسک اعتباری افزایش پیدا کند.»
در این صورت، هم نیاز فروش دیده میشود و هم دغدغه مالی.
یک صورتمسئله قابل توافق بنویسید
صورتمسئله بهتر است چهار جزء داشته باشد:
- محدوده: کدام بخش از فرآیند را بررسی میکنیم؟
- نشانه مسئله: چه تأخیر، خطا یا دوبارهکاری رخ میدهد؟
- پیامد: مشتری یا سازمان چه آسیبی میبیند؟
- قید: در مسیر اصلاح، چه چیزی نباید آسیب ببیند؟
برای مثال:
«در بررسی سفارشهای اعتباری، نقص اطلاعات و رفتوبرگشت بین فروش و مالی باعث تأخیر در اعلام نتیجه میشود. هدف، کاهش زمان انتظار با حفظ کنترل اعتباری و بدون افزایش ناموجه بار کاری واحدهاست.»
این تعریف، مسئله را از «ضعف یک واحد» به «نقص در سازوکار همکاری» تبدیل میکند.
گام دوم: فرآیند واقعی را با مجریان ترسیم کنید
رویه رسمی معمولاً تمام اتفاقات واقعی را نشان نمیدهد. بخشی از کار ممکن است در تماس تلفنی، پیامرسان، فایل اکسل یا پیگیری شخصی انجام شود. اگر فقط مدیران درباره فرآیند توضیح بدهند، احتمال دارد همین بخشهای پنهان دیده نشوند. برای ترسیم وضع موجود، از افرادی دعوت کنید که واقعاً کار را انجام میدهند. چند پرونده اخیر را هم بررسی کنید تا بحث صرفاً بر خاطره و برداشت شخصی متکی نباشد.
روی نقاط تحویل بین واحدها تمرکز کنید
در بسیاری از فرآیندهای بینواحدی، مشکل اصلی در خود فعالیت نیست؛ در تحویل کار از یک واحد به واحد بعدی است.
برای هر نقطه تحویل بپرسید:
- چه چیزی تحویل داده میشود؟
- اطلاعات کامل دقیقاً یعنی چه؟
- از کجا معلوم میشود کار آماده بررسی است؟
- واحد دریافتکننده چگونه دریافت را تأیید میکند؟
- اگر اطلاعات ناقص باشد، کار با چه توضیحی برمیگردد؟
- در صورت اختلاف یا تأخیر، چه کسی تصمیم میگیرد؟
گاهی خروجی این بررسی، نه یک نرمافزار جدید، بلکه یک توافق ساده درباره «شرایط پذیرش درخواست» است.
ابتدا ابهام همکاری را برطرف کنید؛ سپس درباره ابزار تصمیم بگیرید.
گام سوم: اختیار طراحی را واقعی تقسیم کنید
دعوت از کارکنان به جلسه، لزوماً به معنای مشارکت نیست. اگر راهحل از قبل قطعی شده باشد و جلسه صرفاً برای تأیید آن برگزار شود، افراد خیلی زود متوجه میشوند.
مشارکت واقعی یعنی کارکنان بتوانند بر بخشی از تصمیم اثر بگذارند.
مشخص کنید چه چیزهایی ثابت و چه چیزهایی قابل مذاکرهاند
برای نمونه:
قیود ثابت:
- رعایت الزامات قانونی؛
- حفظ کنترلهای ضروری؛
- حفاظت از اطلاعات مشتری؛
- ثبت تصمیمهای حساس.
موارد قابل طراحی:
- ترتیب بعضی فعالیتها؛
- قالب دریافت اطلاعات؛
- نحوه اعلام نقص؛
- مسیر رسیدگی به استثناها؛
- شیوه اجرای آزمایشی.
وقتی این مرزها روشن باشند، هم انتظار غیرواقعی ایجاد نمیشود و هم مشارکت به تعارف سازمانی تبدیل نمیشود.
پرسش مفید در جلسه این است:
«با حفظ این محدودیتها، چه روشی کار شما و واحد بعدی را سادهتر میکند؟»
گام چهارم: شاخص مشترک بسازید تا واحدها علیه هم بهینه نشوند
اگر فروش فقط با تعداد سفارش ثبتشده سنجیده شود، ممکن است ثبت سریع سفارش ناقص برایش جذابتر از تکمیل درست اطلاعات باشد.
اگر مالی فقط با کاهش خطای اعتباری سنجیده شود، ممکن است افزایش کنترلها را به سرعت پاسخگویی ترجیح دهد.
برای اصلاح فرآیندهای بینواحدی، باید کنار شاخصهای تخصصی، معیارهایی برای نتیجه سرتاسری فرآیند داشته باشید.
| نوع شاخص | نمونه | کاربرد |
|---|---|---|
| نتیجه سرتاسری | زمان از ثبت درخواست تا اعلام نتیجه | سنجش تجربه کل فرآیند |
| کیفیت تحویل | درصد درخواستهای پذیرفتهشده بدون برگشت | آشکارکردن نقص در نقاط تحویل |
| شاخص ریسک | تعداد یا شدت خطاهای ناشی از تغییر | جلوگیری از بهبود ظاهری |
| شاخص بار کاری | زمان صرفشده برای ثبت و پیگیری هر پرونده | شناسایی انتقال کار به واحد دیگر |
قبل از اندازهگیری، قواعد استفاده از داده را روشن کنید
فقط گفتن «هدف ما مقصریابی نیست» کافی نیست. باید معلوم باشد:
- چه کسانی به داده دسترسی دارند؟
- تأخیر ناشی از انتظار چگونه از زمان انجام کار تفکیک میشود؟
- پروندههای استثنایی چگونه تحلیل میشوند؟
- دادههای دوره آزمایشی چه کاربردی در ارزیابی افراد دارند؟
شفافیت فرآیندی وقتی اعتماد ایجاد میکند که قواعد استفاده از آن هم شفاف باشد.
گام پنجم: بهجای تغییر سراسری، آزمایش محدود اجرا کنید
اعلام اینکه «از شنبه همه واحدها با روش جدید کار کنند»، هزینه روانی و اجرایی تغییر را بالا میبرد.
راه کمریسکتر، اجرای آزمایشی روی دامنهای محدود است؛ مثلاً:
- یک نوع سفارش؛
- یک گروه مشتری؛
- یک شعبه؛
- یا یک دسته درخواست کمریسک.
این رویکرد با منطق مدیریت فرآیندهای چابک هماهنگ است: تغییر کوچک، بازخورد سریع و اصلاح تدریجی.
مؤسسه IHI نیز در راهنمای آزمودن تغییرات با مدل بهبود، شروع آزمونهای PDSA در مقیاس کوچک را توصیه میکند و کاهش مقاومت هنگام اجرا را یکی از دلایل آزمودن تغییر میداند.
برای آزمایش، قرارداد روشن داشته باشید
قبل از شروع، این موارد را مشخص کنید:
- فرضیه: انتظار داریم چه اتفاقی بیفتد؟
- دامنه: تغییر روی چه پروندههایی اعمال میشود؟
- مدت: تا چه زمانی یا تا بررسی چه تعداد پرونده ادامه دارد؟
- مسئول: چه کسی اجرا و ثبت بازخورد را پیگیری میکند؟
- معیار موفقیت: چه نتیجهای ادامه کار را توجیه میکند؟
- معیار توقف: چه خطا یا پیامدی باعث توقف میشود؟
- مسیر بازگشت: اگر روش مناسب نبود، چگونه به وضعیت امن برمیگردیم؟
وجود امکان توقف و بازگشت، نگرانی افراد را کمتر میکند؛ چون آزمایش با یک تصمیم دائمی و غیرقابلاصلاح تفاوت دارد.
گام ششم: مسئولیت هماهنگی و تصمیمگیری را روشن کنید
وقتی اختلافی بین دو واحد رخ میدهد، چه کسی باید آن را حل کند؟
اگر پاسخ مشخص نباشد، فرآیند دوباره به پیگیری شخصی و مذاکره موردی وابسته میشود.
لازم است یک مسئول هماهنگی سرتاسری، مانند مالک فرآیند با اختیار مشخص، تعیین شود. این نقش جای مدیران واحدها را نمیگیرد؛ مسئول پیگیری نتیجه کل فرآیند و حل مسائل بینواحدی در محدوده اختیارات توافقشده است.
درباره این موضوع میتوانید به مقاله نقش و وظایف مدیر فرآیندهای کسبوکار در ساختار Agile BPM مراجعه کنید.
«مسئول مشخص» بدون «اختیار مشخص» کافی نیست
حداقل باید معلوم باشد:
- چه کسی تغییر پیشنهادی را تصویب میکند؟
- چه کسی درباره استثناها تصمیم میگیرد؟
- اختلاف حلنشده به چه سطحی ارجاع میشود؟
- چه کسی میتواند آزمایش را متوقف کند؟
- چه کسی مسئول اطلاعرسانی تصمیم نهایی است؟
قرار نیست همه تصمیمها با اجماع گرفته شوند. اما لازم است افراد بدانند نظرشان چگونه بررسی میشود و تصمیم نهایی بر چه مبنایی گرفته خواهد شد.
گام هفتم: نتیجه را با مشارکت کارکنان بررسی کنید
پس از اجرای آزمایشی، فقط نپرس
پس از اجرای آزمایشی، فقط نپرسید «زمان فرآیند کمتر آیا دوبارهکاری واقعاً حذف شد یا به واحد دیگری منتقل شد؟
- آیا کار خارج از سامانه افزایش پیدا کرد؟
- آیا کارکنان مجبور به ثبت موازی اطلاعات شدند؟
- آیا کیفیت کنترل حفظ شد؟
- آیا روش جدید برای پروندههای غیرعادی هم مسیر مشخصی دارد؟
یک جلسه بازبینی کوتاه میتواند سه خروجی داشته باشد:
- چه چیزی حفظ شود؟
- چه چیزی اصلاح شود؟
- چه چیزی متوقف شود؟
برای تبدیل این بازبینی به یک روال مستمر، مقاله حاکمیت فرآیند و مدل جلسات هفتگی در Agile BPM مطالعه مکمل مناسبی است.
مثال کاربردی: اصلاح تعامل فروش و مالی
فرض کنید در یک شرکت توزیعی، فروش از تأخیر در بررسی سفارشهای اعتباری شکایت دارد. مالی نیز میگوید درخواستها ناقص ارسال میشوند.
این مثال آموزشی و فرضی است و گزارش یک پروژه واقعی نیست.
روش پرتنش
مدیریت اعلام میکند:
«از این پس مالی موظف است تمام سفارشها را حداکثر ظرف دو ساعت تأیید کند.»
این تصمیم چند ابهام دارد: آیا رد درخواست هم نتیجه محسوب میشود؟ زمان از لحظه ثبت درخواست ناقص شروع میشود؟ تکلیف پرونده پرریسک چیست؟ آیا ظرفیت بررسی وجود دارد؟
روش مشارکتی
نمایندگان فروش و مالی چند پرونده اخیر را بررسی میکنند و به این توافق میرسند:
- اطلاعات ضروری درخواست مشخص شود.
- دریافت اولیه درخواست ثبت شود.
- زمان بررسی تخصصی از زمان تکمیل اطلاعات تفکیک شود.
- نقصها تا حد امکان یکجا اعلام شوند.
- سفارشهای عادی و استثنایی مسیر یکسان نداشته باشند.
- هدف، «اعلام نتیجه بررسی» باشد، نه الزام به تأیید.
- روش جدید ابتدا روی یک گروه محدود اجرا شود.
در این طراحی، فروش پاسخ روشنتری میگیرد و مالی هم مجبور به کنارگذاشتن کنترل ضروری نمیشود.
نکته مهم این است که زمان تکمیل اطلاعات نباید از گزارش عملکرد سرتاسری حذف شود؛ وگرنه سازمان فقط نقطه شروع اندازهگیری را جابهجا کرده، نه اینکه مسئله مشتری را حل کرده باشد.
پنج اشتباه که مقاومت را بیشتر میکند
۱. شروع از اتوماسیون
اگر مسئولیتها و قواعد تحویل مبهم باشند، سامانه جدید همان ابهام را دیجیتالی میکند.
۲. حذف کنترل بدون شناخت کارکرد آن
قبل از حذف هر تأیید، مشخص کنید چه ریسکی را پوشش میدهد و جایگزینش چیست.
۳. اضافهکردن وظیفه بدون آزادکردن ظرفیت
مشارکت آزادکردن ظرفیت
مشارکت، ثبت داده و آموزش زمان میخواهندمره اضافه کرد و انتظار همراهی کامل داشت.
۴. برچسبزدن به مخالفان
فردی که مخالفت میکند ممکن است یک استثنای مهم یا خطر اجرایی را ببیند که تیم طراحی ندیده است.
۵. اعلام موفقیت فقط با میانگین زمان
میانگین بهتر ممکن است پروندههای بسیار معطل، افت کیفیت یا افزایش بار کاری یک واحد را پنهان کند.
جمعبندی: تغییر را با افراد طراحی کنید، نه صرفاً برای آنها
اصلاح فرآیندهای بینواحدی، بیش از آنکه مسئله ترسیم یک نمودار بهتر باشد، مسئله ساختن توافقی عملی درباره همکاری است.
برای کاهش مقاومت:
- مسئله را بدون مقصریابی تعریف کنید.
- نقاط تحویل را با مجریان بررسی کنید.
- نگرانیهای معتبر را وارد طراحی کنید.
- نتیجه کل فرآیند را بسنجید.
- تغییر را در مقیاس محدود بیازمایید.
- مسئولیت و اختیار تصمیمگیری را روشن کنید.
- بر اساس داده و بازخورد، اصلاح را ادامه دهید.
هدف، حذف صدای مخالفت نیست؛ تبدیل نگرانیها به ورودی طراحی بهتر است.
برای شروع، لازم نیست کل فرآیند سازمان را بازطراحی کنید. یک نقطه تحویل پرمسئله بین دو واحد را انتخاب کنید و بپرسید:
«چه توافق کوچکی میتواند همین هفته، کار هر دو طرف و تجربه مشتری را بهتر کند؟»
پرسشهای متداول پیشنهادی برای اسکیما FAQ
آیا میتوان فرآیندهای بینواحدی را کاملاً بدون مقاومت اصلاح کرد؟
تضمینی برای حذف کامل مقاومت وجود ندارد. با مشارکت زودهنگام کارکنان، توضیح دلیل تغییر، روشنکردن مسئولیتها و اجرای آزمایشی میتوان مقاومت غیرضروری را کاهش داد و نگرانیهای معتبر را مدیریت کرد.
اولین قدم در اصلاح فرآیندهای بینواحدی چیست؟
تعریف یک مسئله مشترک و قابلاندازهگیری، بدون مقصر دانستن یک واحد. سپس باید فرآیند واقعی و نقاط تحویل کار با مشارکت مجریان بررسی شوند.
اگر دو واحد بر سر روش جدید توافق نکنند، چه کنیم؟
ابتدا مشخص کنید اختلاف درباره هدف، داده، ریسک، منابع یا اختیار است. سپس گزینهها را با معیار مشترک مقایسه کنید. اگر توافق حاصل نشد، تصمیم باید از مسیر حاکمیتی ازپیشتعیینشده گرفته شود.
آیا قبل از اصلاح فرآیند باید نرمافزار جدید بخریم؟
لزوماً خیر. ابتدا قواعد همکاری، اطلاعات موردنیاز، مسئولیتها و مسیر استثناها را روشن کنید. سپس بررسی کنید کدام ابزار اجرای طراحی توافقشده را بهتر پشتیبانی میکند.
موفقیت تغییر را با چه شاخصهایی بسنجیم؟
ترکیبی از زمان سرتاسری فرآیند، کیفیت تحویل بین واحدها، خطا و ریسک و بار کاری کارکنان مناسب است. کاهش زمان بهتنهایی برای اثبات موفقیت کافی نیست.
فهرست لینکهای داخلی
- مدیریت فرآیندهای چابک چیست؟
- نقش و وظایف مدیر فرآیندهای کسبوکار در ساختار Agile BPM
- حاکمیت فرآیند؛ مدل جلسات هفتگی در Agile BPM