چگونه فرایند سازمانی طراحی کنیم؟
قبل از ساخت گردشکار در فضای کاری، مرز مسئولیت، ورودی/خروجی هر مرحله و معیار «تمام شد» را روی کاغذ شفاف کنید.
۱. وقتی «درخواست خرید» گم میشود
سارا از تیم فنی در گروه واتساپ مینویسد: «لطفاً دو مانیتور بخرید.» پیام در میان دهها پیام دیگر گم میشود. دو روز بعد مدیر میپرسد «وضعیت خرید چیست؟» — کسی نمیداند درخواست رسیده، رد شده، یا هنوز در صف تأیید است.
مشکل بیشتر فرایندها از ابزار شروع نمیشود؛ از این شروع میشود که معلوم نیست چه کسی، چه چیزی را، در چه زمانی، به چه کسی تحویل میدهد.
- درخواست بدون قالب ثبت میشود؛ بودجه و اولویت مشخص نیست.
- تأیید مدیر «فهمیده میشود» نه ثبت میشود.
- هیچکس نمیداند فرایند تمام شده یا نه.
۳. مرز فرایند را قبل از مرحلهبندی بکشید
برای «درخواست خرید» این چکلیست را پر کنید — حتی اگر هنوز ابزار انتخاب نکردهاید:
- شروع (Trigger)
- درخواستدهنده فرم/رکورد خرید را ثبت میکند.
- ورودی
- شرح کالا، تعداد، تخمین هزینه، مرکز هزینه.
- خروجی نهایی
- کالا تحویل شد + سند/رسید در پرونده ثبت شد.
- مالک فرایند
- واحد تدارکات (نه «هر کسی که آنلاین است»).
- شرکتکنندگان
- درخواستدهنده، مدیر مستقیم، خرید، انبار/مالی.
- تمام شد
- وضعیت «بستهشده» با تاریخ تحویل و شماره سفارش.
- استثناها
- بودجه ناکافی، رد مدیر، بازگشت برای تکمیل اطلاعات.
۴. نقشه تحویل بین نقشها
هر تحویل باید نام داشته باشد: چه چیزی از چه کسی به چه کسی میرود.
مسیر پیشنهادی: مرز فرایند → تحویل نقشها → نامگذاری مراحل → تعریف «تمام شد».
۵. نام مرحله = نتیجه، نه فعالیت مبهم
ضعیف
- در حال بررسی
- پیگیری
- انجام کار
بهتر (درخواست خرید)
- اطلاعات کامل شد
- تأیید مدیر دریافت شد
- سفارش ثبت شد
- تحویل تأیید شد
نام مرحله باید به همتیمی بعدی بگوید «الان چه چیزی آماده است» — نه اینکه «کسی دارد کار میکند».
۶. «تمام شد» را برای هر مرحله تعریف کنید
بدون معیار خروج، مرحلهها بیپایان میمانند. مثال برای مرحله «تأیید مدیر»:
| سؤال | پاسخ عملیاتی |
|---|---|
| این مرحله تمام شده؟ | بله، اگر تأیید یا رد صریح با تاریخ ثبت شده باشد. |
| خروجی قابل مشاهده | وضعیت «تأیید مدیر» + یادداشت در همان رکورد. |
| اگر نه | در «منتظر تأیید» میماند — نه «در حال بررسی» مبهم. |
۷. استثناها و حلقهها
فرایند واقعی خطی نیست. برای خرید، این شاخهها را از قبل طراحی کنید:
- اطلاعات ناقص → بازگشت به درخواستدهنده با فهرست فیلدهای لازم.
- رد مدیر → پایان با دلیل؛ بدون حذف رکورد (قابل ممیزی).
- تأخیر تأیید → یادآوری یا ارجاع به جانشین — نه پیام پراکنده.
۸. بعد از تکرارپذیری، چه را اندازه بگیرید؟
وقتی مسیر خرید چند بار در ماه تکرار میشود، زمان انتظار و گلوگاه مهمتر از «چند نفر مشغولاند» میشود.
نمونه — دادهٔ آموزشی، نه آمار مشتری Biz
| مرحله | انتظار | اجرا | جمع نمونه |
|---|---|---|---|
| ثبت درخواست | ۰٫۱ | ۰٫۱ | ۰٫۲ |
| بررسی اولیه | ۰٫۲ | ۰٫۳ | ۰٫۵ |
| انتظار تأیید مدیر | ۳٫۸ | ۰٫۲ | ۴٫۰ |
| ثبت سفارش | ۰٫۵ | ۱٫۲ | ۱٫۷ |
| بستن و تحویل | ۰٫۱ | ۰٫۲ | ۰٫۳ |
نمونهٔ آموزشی، نه آمار مشتری — اغلب گلوگاه «انتظار» است، نه «اجرا».
بازبینی مراحل (درخواست خرید)
روی هر مرحله فوکوس کنید یا کلیک کنید تا مالک، ورودی، خروج و خطای رایج را ببینید. بدون جاوااسکript، جزئیات در جدول پایین همان است.
- مالک
- درخواستدهنده
- ورودی
- نیاز کالا + تخمین هزینه
- خروج مرحله
- رکورد ثبتشده با شماره پیگیری
- خطای رایج
- ثبت در چت بدون رکورد مشترک
| مرحله | مالک | ورودی | خروج | خطای رایج |
|---|---|---|---|---|
| ثبت درخواست | درخواستدهنده | نیاز کالا + تخمین هزینه | رکورد با شماره پیگیری | ثبت در چت |
| بررسی اولیه | تدارکات | رکورد کامل | تأیید/رد اولیه + یادداشت | شروع خرید بدون بودجه |
| انتظار تأیید | مدیر مستقیم | درخواست تأیید شده اولیه | تأیید/رد با مبلغ | تأیید ضمنی در پیام |
| ثبت سفارش | تدارکات | تأیید مدیر | شماره سفارش | سفارش بدون پیوند به رکورد |
| تحویل و بستن | درخواستدهنده + مالی | کالای تحویلی | رسید + وضعیت بسته | بستن بدون رسید |
۹. وقتی وظیفه کافی است
همهٔ خریدها به گردشکار چندمرحلهای نیاز ندارند. اگر فقط یک نفر مسئول است، بودجه از قبل مجاز است، و تحویل یکباره است — یک وظیفه با مسئول و تاریخ هدف کافی است.
وقتی چند نقش، تأیید صریح، و ردوبازگشت دارید — آنگاه گردشکار در فضای کاری منطقیتر میشود.
۱۰. نقشهٔ سبک در Biz (بعد از طراحی روی کاغذ)
این جای تبلیغ نیست؛ فقط همترازی مفاهیم:
- گردشکار — مراحل نامگذاریشده، مالک هر مرحله، رد/تأیید.
- وظیفه — کار تکمسیره با مسئول مشخص.
- مرکز گزارشها — وقتی فرایند تکرار شد، زمان انتظار و نرخ بازگشت را ببینید (با دادهٔ خودتان).
۱۱. هفت سؤال قبل از ساخت گردشکار
- چه رویدادی فرایند را شروع میکند؟
- حداقل ورودی برای شروع چیست؟
- خروجی نهایی قابل مشاهده برای همهٔ ذینفعان چیست؟
- مالک فرایند (نه فقط مجری) کیست؟
- هر مرحله با چه شواهدی «تمام» میشود؟
- رد، ناقصی، و تأخیر به کجا برمیگردد؟
- آیا واقعاً چند نقش دارید — یا یک وظیفه کافی است؟