راهنمافرم و گردش کار
تحلیل فرایند وضع موجود و مطلوب (As-Is / To-Be): راهنمای برگزاری کارگاه با کارشناسان
تحلیل فرایند در دو مرحله انجام میشود: شناخت وضع موجود همانطور که واقعاً اجرا میشود و طراحی وضع مطلوب با رفع مشکلات. برای این کار دامنه را روشن کنید، کارشناسان واقعی را دعوت کنید، در کارگاهی دوساعته با نمونه واقعی و قاعده بدون سرزنش As-Is را ترسیم و مشکلات را با عدد دسته‌بندی کنید، To-Be را با اصول حذف مرحله بی‌ارزش و کنترل اولیه طراحی کنید و خروجی‌ها را ظرف دو روز تحویل دهید.
خلاصه در چند نکته
- As-Is وضع «هست» است و نباید از روی آییننامه نوشته شود.
- بدون As-Is نمی‌دانید To-Be چه مشکلی را حل می‌کند.
- کسانی را دعوت کنید که کار را واقعاً انجام میدهند.
- با نمونه واقعی و قاعده بدون سرزنش، کار پنهان کشف میشود.
- مشکلات را با دسته و اثر عددی اولویت‌بندی کنید.
- To-Be را اول بدون نرم‌افزار طراحی کنید.
- خروجی کارگاه شامل نقشه، مشکلات، To-Be، پرسشهای باز و شاخص‌هاست.
فهرست مطالب
بیشتر پروژه‌های مکانیزه‌سازی که شکست می‌خورند، در مرحله نرم‌افزار شکست نمی‌خورند؛ در مرحله شناخت شکست می‌خورند. تیم فناوری اطلاعات فرایند را از روی آییننامه یا توضیح یک مدیر طراحی می‌کند، سامانه راه می‌افتد و چند هفته بعد معلوم میشود کار واقعی جور دیگری انجام می‌شد: یک امضای غیررسمی وجود داشت، یک فایل اکسل نقش اصلی را بازی می‌کرد یا نیمی از درخواست‌ها از مسیر استثنا می‌رفتند.
راه جلوگیری از این اتفاق، تحلیل فرایند در دو مرحله است: شناخت وضع موجود (As-Is) همانطور که واقعاً اجرا میشود و طراحی وضع مطلوب (To-Be) با رفع مشکلات شناخته‌شده. این راهنما نشان میدهد چطور یک کارگاه دوساعته با کارشناسان برگزار کنید، چه پرسش‌هایی بپرسید و چه خروجی‌هایی تحویل بگیرید. به نمادهای مدل‌سازی و نوشتن دستورالعمل در این مقاله نمی‌پردازیم؛ تمرکز روی روش شناخت و کارگاه است.
As-Is و To-Be یعنی چه؟
| مفهوم | پرسش اصلی | خروجی |
|---|---|---|
| وضع موجود (As-Is) | کار امروز واقعاً چطور انجام میشود؟ | نقشه مراحل واقعی، نقش‌ها، ابزارها، زمان‌ها و مشکلات |
| وضع مطلوب (To-Be) | کار پس از اصلاح چطور باید انجام شود؟ | نقشه مراحل اصلاح‌شده، نقش‌ها، قواعد و شاخص‌ها |
اشتباه رایج این است که مستقیم سراغ To-Be بروند. بدون As-Is، نمی‌دانید چه مشکلی را حل می‌کنید و کدام عادت‌های پنهان باید در طراحی جدید لحاظ شوند. اشتباه دوم این است که As-Is را از روی آییننامه بنویسند؛ آییننامه وضع «باید» است، نه وضع «هست».
پیش از کارگاه: آماده‌سازی
۱. دامنه فرایند را مشخص کنید
نقطه شروع و پایان فرایند را دقیق بنویسید. مثلاً: «فرایند درخواست خرید از لحظه‌ای که کارمند نیاز را اعلام می‌کند تا تحویل کالا به انبار». بدون مرز روشن، کارگاه به بحث درباره همه‌چیز تبدیل میشود.
۲. شرکت‌کنندگان را درست انتخاب کنید
بهترین ترکیب، پنج تا هشت نفر است:
- کسانی که کار را واقعاً انجام میدهند، نه فقط مدیرانشان؛
- نماینده هر واحدی که فرایند از آن عبور می‌کند؛
- مالک فرایند، یعنی کسی که درباره تغییر تصمیم می‌گیرد؛
- یک تسهیلگر که بیطرف است و جلسه را هدایت می‌کند؛
- یک ثبتکننده که نقشه و یادداشت‌ها را می‌نویسد.
۳. نمونه واقعی جمع کنید
از هر واحد بخواهید دو یا سه نمونه واقعی از درخواست‌های اخیر را بیاورد: فرم پرشده، ایمیل‌ها، فایلهای اکسل و نامه‌ها. نمونه واقعی بحث را از «معمولاً این‌طور است» به «این دفعه این‌طور شد» می‌برد.
۴. داده زمانی را از پیش بگیرید
اگر سامانه‌ای وجود دارد، زمان‌های ثبت و تأیید چند ده درخواست اخیر را استخراج کنید. اگر نه، از واحدها بخواهید تخمین بزنند و بعد با نمونه‌ها مقایسه کنید.
قالب کارگاه دوساعته
| زمان | بخش | هدف |
|---|---|---|
| ۰ تا ۱۰ دقیقه | معرفی و قواعد | دامنه، هدف و قاعده «بدون سرزنش» |
| ۱۰ تا ۴۵ دقیقه | ترسیم As-Is | مراحل واقعی با نمونه‌ها |
| ۴۵ تا ۷۰ دقیقه | شناسایی مشکلات | معطلی، دوباره‌کاری، استثنا، خطا |
| ۷۰ تا ۸۰ دقیقه | استراحت کوتاه | — |
| ۸۰ تا ۱۱۰ دقیقه | طرح اولیه To-Be | مراحل اصلاح‌شده و قواعد |
| ۱۱۰ تا ۱۲۰ دقیقه | جمع‌بندی و گام بعد | تصمیم‌ها، پرسشهای باز، مسئولان |
قاعده «بدون سرزنش»
در ابتدای کارگاه روشن کنید که هدف، شناخت فرایند است، نه پیدا کردن مقصر. اگر کارشناسی بترسد که گفتن «ما این مرحله را دور می‌زنیم» برایش دردسر شود، As-Is واقعی هرگز روی تخته نمی‌آید.
ترسیم As-Is: پرسش‌هایی که باید بپرسید
با یک نمونه واقعی شروع کنید و قدم‌به‌قدم جلو بروید. برای هر مرحله این پرسش‌ها را بپرسید:
- چه کسی این مرحله را انجام میدهد؟
- چه چیزی دریافت می‌کند و از کجا؟ (فرم، ایمیل، تماس، نامه)
- چه کاری انجام میدهد؟
- با چه ابزاری؟ (سامانه، اکسل، کاغذ، پیام‌رسان)
- چقدر طول می‌کشد و چقدر منتظر می‌ماند؟
- خروجی را به چه کسی و از چه راهی تحویل میدهد؟
- چه وقت این مرحله تکرار یا برگشت می‌خورد؟
- استثناها کدام‌اند؟ چه درصدی از موارد از مسیر عادی نمی‌روند؟
پرسشهای طلایی برای کشف کار پنهان:
- «اگر فلانی نباشد، چه کسی این کار را می‌کند؟»
- «پیش از اینکه فرم را بفرستید، آیا تلفنی هماهنگ می‌کنید؟»
- «کدام فایل یا دفتر را خودتان نگه می‌دارید که در هیچ سامانه‌ای نیست؟»
- «آخرین باری که یک درخواست گیر کرد، چه اتفاقی افتاد؟»
شناسایی و دسته‌بندی مشکلات
پس از ترسیم، مشکلات را روی نقشه علامت بزنید و دسته‌بندی کنید:
| دسته | نشانه | مثال |
|---|---|---|
| معطلی | زمان انتظار بیش از زمان کار | درخواست سه روز روی میز مدیر مالی |
| دوباره‌کاری | ورود یک داده در چند جا | ورود مشخصات کالا در فرم و اکسل و نامه |
| برگشت | درخواست ناقص برمی‌گردد | نبود پیش‌فاکتور، برگشت از مالی |
| استثنای پرتکرار | موارد زیاد خارج از مسیر | ۳۰٪ خریدها «فوری» ثبت میشوند |
| نبود دید | کسی نمی‌داند کار کجاست | تماس‌های پیگیری روزانه |
| ابهام نقش | معلوم نیست چه کسی تصمیم می‌گیرد | دو مدیر هر دو منتظر یکدیگرند |
برای هر مشکل، اثر آن را با یک عدد تقریبی بنویسید: چند بار در ماه رخ میدهد و چقدر زمان یا هزینه دارد. این عددها اولویت‌بندی را ممکن می‌کنند. روش‌های کمّی پیدا کردن گلوگاه را در مقاله پیدا کردن گلوگاه فرایند توضیح داده‌ایم.
طراحی To-Be: اصول راهنما
برای هر مشکل، یک راه اصلاح پیشنهاد دهید. چند اصل کمک می‌کند:
- مرحله‌ای که ارزش اضافه نمی‌کند حذف شود، مثل امضای «جهت اطلاع» که تصمیمی در آن نیست.
- داده یک‌بار وارد شود و در مراحل بعد از همان رکورد خوانده شود.
- کنترل کامل بودن در ابتدای مسیر باشد؛ فیلدها و پیوست‌های اجباری مانع برگشت میشوند.
- تأییدهای مستقل موازی شوند، نه ترتیبی.
- مهلت و تشدید برای هر ایستگاه تعریف شود.
- استثنا قاعده داشته باشد؛ اگر ۳۰٪ موارد فوری‌اند، تعریف «فوری» را روشن کنید.
- نقش‌ها روشن باشند؛ برای این کار ماتریس RACI را به کار ببرید.
To-Be را ابتدا بدون فکر کردن به نرم‌افزار طراحی کنید. وقتی منطق درست شد، ببینید کدام بخش‌ها با سامانه اجرا میشوند.
خروجی‌های کارگاه
در پایان کارگاه و حداکثر تا دو روز بعد، این خروجی‌ها را برای شرکت‌کنندگان بفرستید:
- نقشه As-Is: مراحل، نقش‌ها، ابزارها و زمان‌ها.
- فهرست مشکلات: با دسته، اثر تقریبی و اولویت.
- طرح اولیه To-Be: مراحل اصلاح‌شده، قواعد و نقش‌ها.
- فهرست پرسشهای باز: مواردی که تصمیم مدیریت یا داده بیشتر لازم دارند.
- شاخصهای پیشنهادی: مثل میانگین زمان چرخه، نرخ برگشت و درصد استثنا.
- گامهای بعد: با مسئول و مهلت.
صورتجلسه کارگاه را مثل هر جلسه رسمی ثبت کنید و پرسشهای باز را به وظیفه با مسئول تبدیل کنید.
اشتباهات رایج
- کارگاه با حضور فقط مدیران: As-Is ایدئال و غیرواقعی میشود.
- دامنه بی‌مرز: کارگاه دوساعته به چهار جلسه بی‌نتیجه تبدیل میشود.
- پریدن به To-Be در دقیقه دهم: مشکلات ریشه‌ای کشف نمی‌شوند.
- طراحی To-Be بر اساس امکانات یک نرم‌افزار: منطق کار قربانی ابزار میشود.
- نبود عدد: همه مشکلات مهم به نظر می‌رسند و اولویت‌بندی ممکن نیست.
سناریوی نمونه: کارگاه فرایند تنخواه
در یک شرکت مهندسی، تسویه تنخواه هر ماه هفته‌ها طول می‌کشید. در کارگاه با حضور دو کارشناس پروژه، یک کارشناس مالی، مدیر یک پروژه و معاون مالی، As-Is با سه نمونه واقعی ترسیم شد. معلوم شد ۴۰٪ تسویه‌ها به‌خاطر نبود فاکتور معتبر برمی‌گردند و هر برگشت دست‌کم سه روز معطلی دارد؛ همچنین کارشناس مالی یک اکسل شخصی برای پیگیری داشت که هیچ‌کس دیگری نمی‌دید. در To-Be، فهرست مدارک معتبر در فرم تسویه اجباری شد، بررسی اولیه مدارک به ابتدای مسیر منتقل شد و وضعیت هر تسویه برای درخواست‌کننده قابل مشاهده شد. شاخص پیشنهادی «نرخ برگشت تسویه» برای پایش سه ماه بعد تعریف شد.
تحلیل فرایند با آریا آی‌تی
BPMS آریا آی‌تی برای تحلیل‌گر و معمار فرایند طراحی شده و نسخه‌بندی، زیرفرایند، مهلت خدمت، شاخص فرایند، فرایندکاوی و تحلیل گلوگاه را در اختیار می‌گذارد؛ بنابراین پس از استقرار To-Be می‌توانید زمان واقعی ایستگاه‌ها را با پیش‌بینی کارگاه مقایسه کنید. در راهکار سفارشی هوش فرایند، مسیر واقعی سازمان با شرط، نقش و مدرک الزامی ابتدا روی کاغذ می‌آید و سپس پیکربندی و با یک درخواست واقعی پایلوت میشود. مدیریت فرایند در پلن سازمانی ارائه میشود. برای انتخاب اولین فرایند، مقاله کدام فرایندها را اول مکانیزه کنیم؟ را ببینید.
جمع‌بندی
تحلیل As-Is و To-Be پیش‌شرط هر مکانیزه‌سازی موفق است. دامنه را روشن کنید، کسانی را دعوت کنید که کار را واقعاً انجام میدهند، با نمونه واقعی و قاعده بدون سرزنش As-Is را ترسیم کنید، مشکلات را با عدد دسته‌بندی کنید و To-Be را بر اساس اصول حذف مرحله بی‌ارزش، ورود یک‌باره داده، کنترل اولیه و نقش روشن طراحی کنید. خروجی‌ها را ظرف دو روز تحویل دهید و پرسشهای باز را به وظیفه تبدیل کنید.
پیش از مکانیزه‌کردن، فرایند را بشناسید: برای برگزاری کارگاه تحلیل فرایند و بررسی BPMS آریا آی‌تی مشاوره رایگان بگیرید یا ۷ روز رایگان شروع کنید.
مراحل انجام کار
دامنه فرایند را مشخص کنید
نقطه شروع و پایان فرایند را دقیق بنویسید.
شرکت‌کنندگان را انتخاب کنید
کارشناسان واقعی، نمایندگان واحدها، مالک فرایند، تسهیلگر و ثبتکننده را دعوت کنید.
نمونه و داده جمع کنید
نمونه‌های واقعی درخواست و داده زمانی را پیش از کارگاه آماده کنید.
As-Is را ترسیم کنید
با نمونه واقعی و پرسشهای هر مرحله، مسیر واقعی را ترسیم کنید.
مشکلات را دسته‌بندی کنید
معطلی، دوباره‌کاری، برگشت، استثنا، نبود دید و ابهام نقش را با اثر عددی ثبت کنید.
To-Be را طراحی کنید
با اصول حذف مرحله بی‌ارزش، ورود یک‌باره داده و کنترل اولیه، مسیر مطلوب را طراحی کنید.
خروجی‌ها را تحویل دهید
نقشه، مشکلات، To-Be، پرسشهای باز، شاخص‌ها و گامهای بعد را ظرف دو روز بفرستید.
پرسشهای متداول
As-Is و To-Be در تحلیل فرایند چیست؟
+
As-Is شناخت وضع موجود فرایند همانطور که واقعاً اجرا میشود و To-Be طراحی وضع مطلوب پس از رفع مشکلات است.
چه کسانی باید در کارگاه تحلیل فرایند شرکت کنند؟
+
پنج تا هشت نفر شامل کارشناسانی که کار را انجام میدهند، نماینده واحدهای درگیر، مالک فرایند، یک تسهیلگر بیطرف و یک ثبتکننده.
چرا نباید As-Is را از آییننامه نوشت؟
+
آییننامه وضع «باید» را نشان میدهد. کار واقعی معمولاً امضاهای غیررسمی، فایلهای شخصی و استثناهایی دارد که فقط با نمونه واقعی و گفتگو با کارشناسان کشف میشوند.
خروجی کارگاه تحلیل فرایند چیست؟
+
نقشه As-Is، فهرست مشکلات با اولویت، طرح اولیه To-Be، پرسشهای باز، شاخصهای پیشنهادی و گامهای بعد با مسئول و مهلت.