فرایندماینینگ چیست و چطور گلوگاه فرایندهای دفتر را پیدا می‌کند؟

سوابق سیستمی شما معمولاً بیشتر از جلسه‌های هفتگی می‌گویند. اگر یک فرایند اداری مدام دیر می‌شود، حدس‌زدنِ «احتمالاً در تأییدها گیر کرده» کافی نیست؛ باید ببینید واقعاً کجا توقف می‌کند، چند بار برمی‌گردد، و کدام مسیرها بیشترین صف را می‌سازند.

فرایندماینینگ دقیقاً برای همین ساخته شده است: به‌جای تکیه بر برداشت ذهنی افراد، از ردپای واقعی سیستم‌ها فرایند را بازسازی می‌کند و نشان می‌دهد گلوگاه کجاست ^{[۱، ۲، ۳]}.

چرا گلوگاه فرایند در سازمان ایرانی دیر دیده می‌شود

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

این مسئله در ایران یک لایه‌ی اضافه هم دارد: کیفیت داده‌ها همیشه یکدست نیست، نام‌گذاری وضعیت‌ها در سیستم‌ها استاندارد نیست، و بخشی از کارها خارج از سیستم ثبت می‌شود. اگر این واقعیت را نادیده بگیرید، هر تحلیل فرایندی می‌تواند ناقص یا گمراه‌کننده شود ^{[۲، ۳]}.

هزینه‌ی نادیده‌گرفتن گلوگاه فقط تأخیر نیست. صف‌های طولانی، دوباره‌کاری، نارضایتی مشتری، و فشار روی تیم‌های عملیاتی هم به‌دنبال می‌آید. برای همین، سؤال اصلی مدیر عملیات این نیست که «آیا فرایندماینینگ جذاب است؟» سؤال این است که «آیا داده و دامنه‌ی من برای این روش آماده است یا نه؟»

فرایندماینینگ چه می‌کند و چه نمی‌کند

فرایندماینینگ از لاگ رویدادها شروع می‌کند؛ یعنی از ردپای دیجیتالِ واقعیِ کارها در سیستم‌ها. هر رویداد معمولاً یک شناسه‌ی پرونده، یک فعالیت، و یک زمان دارد. از کنار هم گذاشتن این رویدادها می‌شود مسیر واقعی فرایند را دید، نه مسیرِ فرضیِ روی تخته‌ی جلسه ^{[۱، ۲، ۳]}.

این روش می‌تواند مسیرهای پرتکرار، انحراف‌ها، بازگشت‌ها، و جاهایی را که کارها در آن می‌مانند آشکار کند ^{[۱، ۳]}. اما یک نکته مهم است: فرایندماینینگ خودش مشکل را حل نمی‌کند. اگر داده ناقص، نویزی یا ناسازگار باشد، خروجی هم می‌تواند تصویر نادرستی از گلوگاه بدهد یا شدت آن را بیش‌برآورد کند ^{[۲، ۳]}.

پس این ابزار برای «دیدن» و «اولویت‌بندی» مناسب است، نه برای حذف خودکار همه‌ی مشکلات. تصمیم نهایی درباره‌ی تغییر فرایند، حذف مرحله، یا جابه‌جایی مسئولیت هنوز با انسان است.

برای تیم فنی

از نظر فنی، فرایندماینینگ روی event log اجرا می‌شود و با process discovery و drift detection کار می‌کند؛ یعنی فرایند as-is را از روی رویدادها بازسازی می‌کند و تغییر رفتار فرایند را در طول زمان می‌سنجد ^{[۲، ۳]}. اگر لاگ‌ها تمیز نباشند، این تحلیل هم آسیب می‌بیند ^[۲].

سناریوی فرضی: از کدام فرایند شروع کنیم

فرض کنید یک سازمان خدماتی دارید و شکایت اصلی این است که «پرونده‌ها دیر بسته می‌شوند». سه فرایند روی میز است: ثبت درخواست مشتری، تأیید داخلی، و صدور فاکتور.

اگر این سه فرایند را با جدول بالا بسنجید، ممکن است ببینید ثبت درخواست در دو سیستم ثبت می‌شود و بخشی از آن دستی است؛ تأیید داخلی در اتوماسیون اداری کامل‌تر لاگ دارد؛ و صدور فاکتور در ERP بومی با شناسه‌ی یکتا ثبت می‌شود. در این حالت، فرایندی که داده‌ی کامل‌تر و دامنه‌ی روشن‌تری دارد، برای شروع مناسب‌تر است؛ نه لزوماً فرایندی که همه درباره‌اش بیشتر شکایت می‌کنند.

اینجا فرایندماینینگ به شما کمک می‌کند اولویت را از روی شواهد بچینید: کدام فرایند قابل‌ردیابی‌تر است، کدام گلوگاه اثر عملیاتی بیشتری دارد، و کجا مداخله واقعاً ممکن است. اگر فقط زمان انتظار را ببینید، ممکن است فرایندی را انتخاب کنید که پر سر و صداست اما داده‌ی کافی ندارد ^{[۳، ۴]}.

پیشنهاد دو نمودار برای میز اجرا:

• نمودار ۱: نقشه‌ی مسیر فرایند — نشان می‌دهد پرونده‌ها از چه مسیرهایی عبور می‌کنند و در کدام مرحله بیشترین بازگشت یا توقف رخ می‌دهد.
• نمودار ۲: مقایسه‌ی زمان چرخه و حجم پرونده — نشان می‌دهد کدام فرایند هم پرتکرار است و هم بیشترین زمان را می‌گیرد؛ این برای اولویت‌بندی شروع مفید است.

چه داده و چه آمادگی‌ای لازم دارید

برای یک پایلوت کوچک، به لاگ رویدادهای قابل‌اعتماد نیاز دارید: شناسه‌ی پرونده، نام فعالیت، زمان ثبت، و اگر ممکن است کاربر یا واحد انجام‌دهنده. اگر این داده‌ها در چند سیستم پخش‌اند، باید بتوانید آن‌ها را به یک شناسه‌ی مشترک وصل کنید ^{[۱، ۳]}.

اگر داده‌ها تمیز نباشند، بخش اصلی زمان صرف پاک‌سازی و اعتبارسنجی می‌شود ^{[۲، ۳]}. تیم لازم هم معمولاً کوچک است: یک مالک فرایند، یک تحلیل‌گر داده یا BI، یک نفر از IT یا ERP، و یک نماینده از واحد عملیاتی.

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

ریسک‌ها و اشتباه‌هایی که نتیجه را خراب می‌کنند

• داده‌ی ناقص یا نویزی: اگر رویدادها گمشده، تکراری یا ناسازگار باشند، تحلیل می‌تواند گلوگاه را اشتباه نشان دهد. پیشگیری: مالک داده را مشخص کنید، فهرست فیلدهای اجباری را بنویسید، و قبل از تحلیل، لاگ‌ها را پاک‌سازی و اعتبارسنجی کنید ^{[۲، ۳]}.
• دامنه‌ی مبهم: اگر ندانید فرایند از کجا شروع و کجا تمام می‌شود، خروجی پراکنده می‌شود. پیشگیری: مرز فرایند را از ابتدا روی کاغذ مشخص کنید، فهرست رویدادهای آغاز و پایان را بنویسید، و فقط همان را تحلیل کنید ^{[۳، ۴]}.
• انتخاب فرایند اشتباه برای شروع: بعضی فرایندها مهم‌اند، اما داده‌ی کافی ندارند یا تغییرشان در اختیار شما نیست. پیشگیری: با جدول تصمیم، فرایندی را انتخاب کنید که هم داده‌ی بهتر دارد و هم امکان مداخله در آن وجود دارد.
• نادیده‌گرفتن امنیت و حریم داده: لاگ‌های فرایندی ممکن است شامل اطلاعات مشتری، شماره پرونده، یا جزئیات عملیاتی حساس باشند. پیشگیری: دسترسی را محدود کنید، داده‌ی غیرضروری را حذف یا ناشناس‌سازی کنید، و قبل از خروج داده از سازمان، سیاست روشن داشته باشید.
• تفسیر شتاب‌زده‌ی نتیجه: یک مسیر پرتکرار لزوماً بد نیست؛ گاهی فقط مسیر غالب است. پیشگیری: نتیجه را با مالک فرایند و واحد عملیاتی بازبینی کنید و قبل از تغییر، علت را بررسی کنید.

چک‌لیست شروع: پنج قدم از فردا

1. مدیر عملیات یک فرایند پرمسئله را انتخاب کند. فرایندی را بردارید که هم شکایت درباره‌اش زیاد است و هم اثرش روی مشتری یا عملیات روشن است.
2. مالک فرایند مرز کار را بنویسد. مشخص کنید از کدام رویداد شروع می‌شود و با کدام رویداد تمام می‌شود.
3. تیم IT یا BI فهرست لاگ‌های موجود را جمع کند. ببینید کدام سیستم‌ها شناسه‌ی پرونده، فعالیت و زمان را ثبت می‌کنند.
4. تحلیل‌گر داده کیفیت داده را سریع بررسی کند. چند پرونده‌ی نمونه را دستی دنبال کنید و ببینید آیا مسیرشان در سیستم قابل‌ردیابی است یا نه.
5. مدیر عملیات معیار موفقیت را تعریف کند. تصمیم بگیرید که موفقیت پایلوت با کاهش زمان چرخه، کاهش دوباره‌کاری، یا شفاف‌شدن گلوگاه سنجیده می‌شود.
6. مالک فرایند مسئول تغییر را مشخص کند. بدون کسی که اختیار تغییر داشته باشد، تحلیل به گزارش تبدیل می‌شود.
7. یک پایلوت کوچک و محدود اجرا کنید. از یک فرایند شروع کنید، نه از کل سازمان؛ بعد از دیدن نتیجه، دامنه را بزرگ‌تر کنید.

جمع‌بندی: چه زمانی فرایندماینینگ انتخاب درست است

اگر سوابق سیستمیِ قابل‌اعتماد دارید، دامنه‌ی فرایند را می‌شناسید، و می‌خواهید از بین چند گلوگاه، اولویت عملی انتخاب کنید، فرایندماینینگ برای شما مناسب است. اگر داده‌ها پراکنده‌اند، بخشی از کار بیرون از سیستم انجام می‌شود، یا هنوز مالک فرایند مشخص نیست، بهتر است اول سراغ آماده‌سازی داده و تعریف دامنه بروید.

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