تفاوت «مدلسازی فرآیند» با «طراحی راهکار بهبود فرآیند»
برای پاسخ، باید میان دو فعالیت مرتبط اما متفاوت تمایز بگذاریم: مدلسازی فرآیند و طراحی راهکار بهبود فرآیند. اولی به ما کمک میکند منطق انجام کار را بفهمیم و نمایش دهیم؛ دومی مشخص میکند چه تغییری، با چه سازوکاری و تحت چه شرایطی میتواند عملکرد را بهتر کند.
مدلسازی فرآیند چیست و چه مسئلهای را حل میکند؟
مدلسازی فرآیند، ساختن یک نمایش هدفمند از نحوه انجام کار است. در این نمایش، بسته به هدف تحلیل، فعالیتها، رویدادها، نقشها، قواعد تصمیمگیری، تبادل اطلاعات و ارتباط میان مشارکتکنندگان مشخص میشوند.
واژه «هدفمند» مهم است: هیچ مدلی قرار نیست تمام واقعیت سازمان را با همه جزئیات بازسازی کند. مدل خوب باید برای پرسشی که داریم، بهاندازه کافی دقیق باشد؛ نه صرفاً بزرگ، پیچیده و پرجزئیات.
مدل فرآیند فقط برای وضع موجود نیست
یک اشتباه رایج این است که مدلسازی را فقط مستندسازی وضعیت موجود بدانیم. درحالیکه میتوان هم وضعیت موجود (As-Is) و هم وضعیت مطلوب (To-Be) را مدل کرد. مدلها میتوانند برای تحلیل، گفتوگو، شبیهسازی یا آمادهسازی اجرای فرآیند استفاده شوند.
بنابراین، تفاوت این دو فعالیت را نباید به «ترسیم وضع موجود» در برابر «ترسیم وضع مطلوب» تقلیل داد. مدل وضع مطلوب میتواند بخشی از طراحی راهکار بهبود فرآیند باشد، اما تمام آن نیست.
خروجی یک مدلسازی مفید چیست؟
- درک مشترک از نقطه شروع و پایان فرآیند.
- شفافشدن مسئولیتها و نقاط تحویل کار بین واحدها.
- نمایش مسیرهای عادی، استثناها و بازگشتهای کاری.
- مشخصشدن قواعد تصمیمگیری و وابستگیهای مهم.
- ایجاد مبنایی برای تحلیل، بازطراحی یا پیادهسازی.
استاندارد BPMN متعلق به OMG زبان استانداردی برای نمایش فرآیندهای کسبوکار فراهم میکند. بااینحال، درستی یک نمودار از نظر قواعد BPMN، بهتنهایی اثبات نمیکند که فرآیند اقتصادی، سریع یا مشتریمحور است.
برای مرور مبانی این موضوع، میتوانید مطلب مدلسازی فرآیند با BPMN و کاربرد آن در BPMS را مطالعه کنید.
طراحی راهکار بهبود فرآیند یعنی چه؟
منظور من از «طراحی راهکار بهبود فرآیند» در این مقاله، طراحی آگاهانه یک تغییر یا مجموعهای از تغییرات در شیوه انجام کار است؛ با این هدف که یک نتیجه مشخص بهتر شود. این عبارت را بهعنوان یک مفهوم عملی به کار میبرم، نه نام یک استاندارد مستقل.
راهکار بهبود فرآیند میتواند تغییر در یک قاعده تأیید، اصلاح فرم، جابهجایی اختیار تصمیمگیری، تغییر ظرفیت، بازتنظیم صف کار، آموزش هدفمند یا اتوماسیون یک فعالیت باشد. مهم، جدیدبودن ابزار نیست؛ مهم این است که تغییر انتخابشده به مسئله واقعی پاسخ دهد.
یک راهکار بهبود فرآیند باید به چه پرسشهایی پاسخ دهد؟
- مسئله چیست؟ کدام نتیجه برای چه گروهی نامطلوب است؟
- شواهد چیست؟ چه دادهای وجود مسئله و علت احتمالی آن را نشان میدهد؟
- چه چیزی تغییر میکند؟ قاعده، نقش، ابزار، ظرفیت یا توالی کار؟
- سازوکار اثر چیست؟ چرا این تغییر باید نتیجه را بهتر کند؟
- چگونه اجرا میشود؟ با چه مالک
- چگونه اجرا میشود؟ با چه مالک ارزیابی میشود؟ با چه شاخص، خط مبنا و معیار تصمیمی؟
«یک تأیید را حذف کنیم» یک ایده است. «تأیید دوم درخواستهای کمریسک را در یک پایلوت محدود، با کنترل جایگزین و سنجش زمان و خطا حذف کنیم» به طراحی راهکار بهبود فرآیند نزدیک میشود.
حتی یک راهکار بهبود فرآیند که خوب طراحی شده باشد هم تضمین موفقیت نیست. طراحی راهکار، یک فرضیه مستدل درباره تغییر میسازد؛ اجرا و ارزیابی نشان میدهند این فرضیه در محیط واقعی چقدر معتبر است.
تفاوت مدلسازی فرآیند با طراحی راهکار بهبود فرآیند در یک نگاه
| بُعد مقایسه | مدلسازی فرآیند | طراحی راهکار بهبود فرآیند |
|---|---|---|
| پرسش محوری | کار چگونه انجام میشود یا باید انجام شود؟ | چه تغییری، چرا و چگونه باید عملکرد را بهتر کند؟ |
| تمرکز اصلی | نمایش ساختار و منطق فرآیند. | طراحی راهکار و توضیح سازوکار اثر آن. |
| ورودیهای مهم | مشاهده، مصاحبه، مستندات، قواعد و دادههای اجرا. | مسئله، خط مبنا، شواهد علت، محدودیتها و گزینههای تغییر. |
| خروجی معمول | مدل وضع موجود یا مطلوب و مستندات مرتبط. | بسته راهکار بهبود شامل فرضیه، دامنه، مسئول، کنترلها و برنامه سنجش. |
| معیار کیفیت | درستی، فهمپذیری و تناسب مدل با هدف استفاده. | پشتوانه شواهد، امکان اجرا، آزمونپذیری و مدیریت پیامدها. |
| ریسک متداول | مدل دقیق اما بیاستفاده در تصمیمگیری. | راهکار جذاب اما نامرتبط با علت مسئله. |
| رابطه با نتیجه | درک و تحلیل را تسهیل میکند؛ الزاماً عملکرد را تغییر نمیدهد. | مسیر تغییر را طراحی میکند؛ نتیجه باید پس از اجرا سنجیده شود. |
این مرزبندی به معنای جداکردن کامل دو فعالیت نیست. هنگام مدلسازی ممکن است ایده بهبود پیدا کنیم و هنگام طراحی راهکار بهبود فرآیند مجبور شویم مدل را اصلاح کنیم. تفاوت اصلی در پرسش و خروجی مورد انتظار است، نه لزوماً در فرد، ابزار یا جلسهای که کار را انجام میدهد.
مثال کاربردی: کاهش زمان تأیید درخواست خرید
فرض کنید یک شرکت خدماتی میخواهد زمان رسیدگی به درخواستهای خرید را کاهش دهد. بررسی اولیه نشان میدهد میانه زمان درخواست تا تصمیم نهایی، ۶ روز کاری است.
گام اول: مدل چه چیزی را نشان میدهد؟
مسیر معمول چنین است: ثبت درخواست ← بررسی سرپرست ← کنترل بودجه ← تأیید مدیر واحد ← ارسال نتیجه به تدارکات. درخواست ناقص نیز برای اصلاح به متقاضی برمیگردد.
این مدل، ساختار کار را روشن میکند. اما از روی همین نمودار نمیتوان نتیجه گرفت که تأیید مدیر واحد علت اصلی تأخیر است. برای چنین قضاوتی باید زمانهای ورود و خروج، حجم صف، نوع درخواست و الگوی بازگشت پروندهها بررسی شود.
گام دوم: شواهد چه میگویند؟
فرض کنیم بررسی دادهها و گفتوگو با کاربران نشان میدهد درخواستهای کممبلغ و دارای بودجه مصوب، پس از کنترل سرپرست و بودجه باز هم در صف تأیید مدیر میمانند؛ درحالیکه مدیر در بیشتر این موارد اطلاعات تازهای به تصمیم اضافه نمیکند.
این یافته، حذف تأیید را بهطور خودکار توجیه نمیکند. باید روشن شود آن تأیید چه ریسک یا الزام کنترلی را پوشش میدهد و آیا برای زیرگروه مشخصی از درخواستها میتوان کنترل مناسب دیگری داشت.
گام سوم: راهکار بهبود فرآیند چگونه طراحی میشود؟
- دامنه: فقط درخواستهای کممبلغ، غیرحساس و دارای بودجه مصوب در یک واحد.
- تغییر: حذف تأیید موردی مدیر برای این گروه، پس از تصویب تفویض اختیار.
- کنترل جایگزین: ثبت ردپای تصمیم، کنترل سقف مجاز و بازبینی نمونهای درخواستها.
- فرضیه: حذف انتظار برای تأیید تکراری، زمان تصمیمگیری را کاهش میدهد، بدون افزایش نامقبول مغایرتها.
- اجرا: پایلوت چهارهفتهای با مالکیت مسئول فرآیند خرید و هماهنگی مالی.
- هدف آزمایشی: کاهش میانه زمان رسیدگی درخواستهای واجد شرایط از ۶ به حداکثر ۴ روز کاری، به شرط تأیید خط مبنای همین زیرگروه.
- شرط ایمنی: نبود تخلف جدی و باقیماندن مغایرتها در محدوده مورد توافق مسئول کنترل داخلی پیش از شروع آزمون.
گام چهارم: چه چیزی موفقیت را نشان میدهد؟
فقط پایینآمدن میانگین زمان کافی نیست. میانه و صدک ۹۰ زمان رسیدگی، نرخ بازگشت درخواست، مغایرت بودجه ورت بودجه و میزان رعایت قواعد جدید باید بررسی شوند. مقایسههای همنوع انجام شود؛ نه میان همه خریدهای قبل از تغییر و چند خرید ساده پس از آن.
همچنین لازم است درخواستهای هنوز باز دیده شوند. اگر فقط پروندههای تکمیلشده را بشماریم، ممکن است پروندههای طولانی از ارزیابی حذف شوند و تصویری بیشازحد خوشبینانه بسازند.
شش گام برای تبدیل مدل فرآیند به راهکار بهبود قابلآزمون
۱. مسئله را با نتیجه نامطلوب تعریف کنید، نه با راهحل
«به سامانه جدید نیاز داریم» تعریف مسئله نیست؛ پیشنهاد راهحل است. تعریف بهتر میتواند این باشد: «بخش قابلتوجهی از درخواستها بهدلیل نقص اطلاعات برگشت میخورند و زمان رسیدگی افزایش پیدا میکند.» اکنون میتوان درباره میزان، محل و علت مسئله داده جمع کرد.
۲. مدل را به شواهد عملکرد متصل کنید
روی فعالیتها و نقاط تحویل، دادههای مرتبط را قرار دهید: زمان انتظار، زمان انجام کار، تعداد بازگشت، حجم ورودی و ظرفیت.. در صورت دسترسی به رخدادهای مناسب، فرآیکاوی میتواند مسیرهای واقعی و تفاوت آنها با مدل رسمی را آشکار کند.
بااینحال، مشاهده همزمانی یک مسیر با تأخیر، اثبات علت نیست. ممکن است پروندههای پیچیدهتر هم مسیر طولانیتری داشته باشند و هم دیرتر تمام شوند. تحلیل داده باید با شناخت قواعد و شرایط کار همراه باشد.
۳. سازوکار اثر تغییر را بنویسید
برای هر راهکار، این جمله را کامل کنید: «اگر … را تغییر دهیم، انتظار داریم … بهتر شود، زیرا … .» بخش «زیرا» کمک میکند تفاوت یک ایده جذاب با یک فرضیه قابلدفاع روشن شود.
برای مثال: «اگر اطلاعات ضروری هنگام ثبت درخواست اعتبارسنجی شوند، انتظار داریم بازگشت ناشی از نقص اطلاعات کمتر شود، زیرا خطا پیش از ورود پرونده به صف بررسی اصلاح میشود.» البته زمان تکمیل فرم و احتمال رهاکردن درخواست نیز باید سنجیده شود.
۴. گزینهها را مقایسه کنید؛ مستقیم سراغ اتوماسیون نروید
- آیا فعالیت غیرضروری را میتوان حذف کرد؟
- آیا قاعده تصمیمگیری باید ساده یا شفاف شود؟
- آیا اختیار در نقطه نامناسبی قرار گرفته است؟
- آیا مسئله ناشی از ظرفیت، مهارت یا توزیع بار است؟
- آیا استانداردسازی یا اصلاح ورودی کافی است؟
- آیا اتوماسیون واقعاً علت مسئله را هدف میگیرد؟
انتخاب گزینه باید با توجه به اثر مورد انتظار، هزینه، ریسک، زمان اجرا و امکان بازگشت انجام شود. یک فعالیت نامناسب، صرفاً با دیجیتالشدن مناسب نمیشود.
۵. سه دسته شاخص و برنامه آزمون تعریف کنید
- شاخص نتیجه: آیا مسئله اصلی بهتر شده است؟ مانند زمان کل رسیدگی یا نرخ خطا.
- شاخص اجرا: آیا تغییر طبق طراحی انجام شده است؟ مانند سهم درخواستهای واجد شرایط که واقعاً از مسیر جدید عبور کردهاند.
- شاخص موازنهای: آیا بهبود یک بخش به بخش دیگری آسیب زده است؟ مانند افزایش بار تدارکات، شکایت مشتری یا کاهش کیفیت کنترل.
پیش از اجرا، تعریف شاخصها، روش استخراج داده، خط مبنا آزمون و حدهای پذیرش را مشخص کنید. مدت آزمون نیز باید با حجم پروندهها و تنوع شرایط متناسب باشد؛ یک پایلوت کوتاه با چند پرونده برای همه تصمیمها کافی نیست.
۶. بر اساس نتیجه، تصمیم به گسترش، اصلاح یا توقف بگیرید
چرخه PDSA شامل برنامهریزی، اجرای آزمون، مطالعه نتایج و اقدام بر اساس یادگیری است. در راهنمای آزمون تغییرات IHI نیز بر شروع کوچک و یادگیری در چرخههای متوالی تأکید میشود.
اگر نتیجه مطلوب نبود، پیش از رد یا تأیید راهکار بپرسید: آیا فرضیه نادرست بود؟ آیا تغییر ناقص اجرا شد؟ آیا دادهها کافی نبودند؟ یا شرایط بیرونی تغییر کرده بود؟ مقایسه ساده قبل و بعد، همیشه اثر راهکار را از سایر عوامل جدا نمیکند. در صورت امکان، گروه مقایسه مناسب یا تحلیل روند زمانی نیز به کار بگیرید.
- آیتم مدلسازی: «مسیرهای بازگشت درخواست خرید مستند و با کاربران اعتبارسنجی شود.»
- آیتم راهکار بهبود: «اعتبارسنجی اطلاعات ضروری برای یک گروه از درخواستها آزمایش شود و اثر آن بر بازگشت پرونده و زمان ثبت سنجیده شود.»
آیتم اول میتواند پیشنیاز مهمی باشد؛ اما جای آیتم دوم را نمیگیرد. برای ساختاردهی پیشنهادهای تغییر، مطلب الگوی طراحی Backlog بهبود برای فرآیندهای سازمانی مکمل این بحث است.
معیار پیشرفت نیز باید متناسب با مرحله باشد: در مدلسازی، مدل معتبر؛ در طراحی راهکار بهبود فرآیند، تغییر قابلآزمون؛ و پس از اجرا، شواهد نتیجه و تصمیم روشن درباره ادامه مسیر. آزمونی که یک فرضیه نامناسب را زود آشکار کند، یادگیری ارزشمند تولید کرده است؛ هرچند هنوز بهبود عملکرد محقق نشده باشد.
چهار اشتباه رایج که مرز مدل و بهبود را مخدوش میکند
اشتباه اول: نمودار سادهتر را الزاماً بهتر بدانیم
کمترشدن تعداد فعالیتها همیشه مطلوب نیست. حذف یک کنترل ممکن است سرعت را افزایش دهد، اما هزینه خطا یا ریسک انطباق را بالا ببرد. معیار، نتیجه خالص و قابلقبول است؛ نه تعداد کمتر شکلهای نمودار.
اشتباه دوم: مدل را مدرک قطعی علت مسئله فرض کنیم
نمودار میتواند محل احتمالی مشکل را نشان دهد، اما تشخیص علت به داده، مشاهده و بررسی توضیحهای جایگزین نیاز دارد. طولانیبودن یک مسیر روی کاغذ، لزوماً به معنای بیشترین زمان واقعی نیست.
اشتباه سوم: ابزار را جای راهکار بهبود بنشانیم
«استقرار BPMS» یا «استفاده از هوش مصنوعی» بهتنهایی طراحی راهکار بهبود فرآیند نیست. باید مشخص شود ابزار کدام تصمیم یا فعالیت را تغییر میدهد، چگونه نتیجه را بهتر میکند و چه کنترل انسانی یا فنی لازم دارد.
اشتباه چهارم: طراحی راهکار بهبود را با اجرای موفق یکی بدانیم
سند راهکار، حتی اگر کامل باشد،واهد موفقیتیت نیست. پذیرش کاربران، کیفیت اجرا، رفتار استثناها و پایداری نتیجه باید در محیط واقعی بررسی شوند.
چکلیست: آیا از مدل به طراحی راهکار بهبود فرآیند رسیدهایم؟
پیش از ارائه یک پیشنهاد بهعنوان «طرح بهبود»، بررسی کنید پاسخ این پرسشها روشن باشد:
- مسئله و گروه تحتتأثیر آن دقیقاً مشخصاند؟
- خط مبنا و تعریف عملیاتی شاخصها ثبت شدهاند؟
- برای علت احتمالی، شواهدی فراتر از برداشت شخصی داریم؟
- تغییر پیشنهادی و سازوکار اثر آن روشناند؟
- مالک اجرا، اختیار تصمیمگیری و منابع تعیین شدهاند؟
- کنترلهای لازم و پیامدهای ناخواسته بررسی شدهاند؟
- روش آزمون و معیار گسترش، اصلاح یا توقف تعریف شدهاند؟
- برنامه پایش پس از استقرار و بهروزرسانی مدل وجود دارد؟
اگر فقط مسیر مطلوب را رسم کردهایم، احتمالاً هنوز یک مدل پیشنهادی داریم. وقتی فرضیه، سازوکار اجرا، کنترل و سنجش به آن اضافه شود، به یک طرح راهکار بهبود فرآیند قابلدفاع نزدیک میشویم.
جمعبندی: مدل، تغییر و نتیجه را جداگانه مدیریت کنید
مدلسازی فرآیند و طراحی راهکار بهبود فرآیند، رقیب یکدیگر نیستند. مدلسازی، منطق کار را قابلدیدن و قابلگفتوگو میکند؛ طراحی راهکار بهبود فرآیند، این شناخت را به یک پیشنهاد تغییر قابلآزمون تبدیل میکند و ارزیابی مشخص میکند آیا تغییر واقعاً مفید بوده است.
از روی مدل میفهمیم کار چگونه پیش میرود؛ با طراحی راهکار بهبود فرآیند روشن میکنیم چه چیزی را چرا تغییر دهیم؛ و با شواهد نتیجه می بهبود منجر شده به بهبود منجر شده است.
در جلسه بعدی بررسی فرآیند، کنار سؤال «آیا مدل درست است؟» این سؤال را هم بگذارید: «کدام تغییر مشخص را میتوانیم با ریسک قابلقبول آزمایش کنیم و از نتیجه آن یاد بگیریم؟»
پرسشهای متداول
آیا مدلسازی فرآیند فقط به وضع موجود مربوط است؟
خیر. میتوان وضع موجود، وضع مطلوب و گزینههای مختلف طراحی را مدل کرد. تفاوت مدلسازی با طراحی راهکار بهبود فرآیند در این است که طراحی راهکار علاوه بر نمایش فرآیند، فرضیه اثر، برنامه اجرا، کنترلها و روش سنجش را مشخص میکند.
آیا مدل To-Be همان طرح راهکار بهبود فرآیند است؟
خیر. مدل To-Be میتواند بخشی از طرح راهکار بهبود فرآیند باشد، اما بهتنهایی دلیل انتخاب تغییر، مالک اجرا، دامنه آزمون، معیار موفقیت و قواعد توقف یا بازگشت را پوشش نمیدهد.
آیا پیش از هر بهبود باید مدل کامل BPMN تهیه کنیم؟
خیر. میزان مدلسازی باید با پیچیدگی، ریسک و دامنه تغییر متناسب باشد. برای یک تغییر محدود، نقشه ساده و داده معتبر ممکن است کافی باشد؛ تغییرات پیچیده یا حساس به مدل و تحلیل دقیقتری نیاز دارند.
آیا هر راهکار بهبود فرآیند باید شامل اتوماسیون باشد؟
خیر. اصلاح قاعده، تفویض اختیار، حذف کار تکراری، تغییر توزیع بار و بهبود کیفیت ورودی نیز میتوانند راهکار بهبود باشند. اتوماسیون زمانی مناسب است که به علت مسئله پاسخ دهد.
چگونه بفهمیم راه بهبود شده استیند واقعاً باعث بهبود شده است؟
شاخصها را پیش از اجرا تعریف کنید، خط مبنا داشته باشید، کیفیت اجرای تغییر و پیامدهای جانبی را بسنجید و دادههای قابلمقایسه جمع کنید. مقایسه ساده قبل و بعد همیشه کافی نیست؛ در صورت امکان از گروه مقایسه یا تحلیل روند زمانی کمک بگیرید.
دیدگاه خود را ثبت کنید
تمایل دارید در گفتگوها شرکت کنید؟در گفتگو ها شرکت کنید.