چرا فرایند در بیزاجی جلو نمی‌رود؟ راهنمای عیب‌یابی
یکی از مشکلاتی که ممکن است در زمان استفاده از Bizagi پیش بیاید، متوقف‌شدن یک نمونه فرایند در یک مرحله است؛ درحالی‌که انتظار داریم فعالیت بعدی آغاز شود یا کاربر بتواند وظیفه بعدی را انجام دهد.
این وضعیت همیشه به معنی خرابی موتور فرایند نیست. گاهی یک وظیفه هنوز انجام نشده، گاهی تخصیص کاربر به‌درستی انجام نگرفته و گاهی نیز یک قانون کسب‌وکار، تایمر یا سرویس خارجی مانع ادامه اجرای فرایند شده است.
در این مقاله، گام‌به‌گام بررسی می‌کنیم که چگونه علت جلو نرفتن یک فرایند در بیزاجی را پیدا کنیم.
۱. ابتدا مشخص کنید فرایند دقیقاً در چه وضعیتی قرار دارد
قبل از تغییر مدل فرایند یا دست‌کاری تنظیمات، باید مشخص کنیم مشکل در کدام مرحله رخ داده است.
برای بررسی اولیه، به این پرسش‌ها پاسخ دهید:
- آیا نمونه فرایند ایجاد شده است؟
- آیا فعالیت فعلی هنوز در انتظار انجام کار توسط کاربر است؟
- آیا فعالیت قبلی تکمیل شده، اما فعالیت بعدی آغاز نشده است؟
- آیا فرایند منتظر زمان مشخص، پیام یا پاسخ یک سرویس خارجی است؟
- آیا مشکل فقط برای یک نمونه فرایند رخ داده یا چندین نمونه را درگیر کرده است؟
این تفکیک اهمیت زیادی دارد؛ زیرا فرایندی که منتظر اقدام کاربر است، الزاماً متوقف نشده است. ممکن است دقیقاً مطابق مدل طراحی‌شده در حال انتظار باشد.
۲. وضعیت فعالیت جاری و وظایف معوق را بررسی کنید
اگر فرایند در یک فعالیت کاربری متوقف به نظر می‌رسد، ابتدا بررسی کنید که آیا وظیفه مربوط به آن فعالیت ایجاد شده و در اختیار کاربر مناسب قرار گرفته است یا خیر.
موارد زیر را بررسی کنید:
- آیا وظیفه در فهرست کارهای کاربر مورد انتظار وجود دارد؟
- آیا وظیفه به کاربر، نقش یا گروه صحیح تخصیص داده شده است؟
- آیا شرایط لازم برای نمایش یا انجام وظیفه برقرار است؟
- آیا کاربر مجوز لازم برای دسترسی به وظیفه را دارد؟
- آیا وظیفه به دلیل قواعد تخصیص یا تغییرات سازمانی در اختیار شخص دیگری قرار گرفته است؟
نکته: اگر وظیفه ایجاد شده اما کاربر آن را مشاهده نمی‌کند، مشکل ممکن است به تخصیص، مجوزها یا نحوه دسترسی مربوط باشد؛ نه به اجرای مدل فرایند.
۳. قوانین کسب‌وکار و شرایط انتقال را بررسی کنید
گاهی فعالیت قبلی تکمیل می‌شود، اما مسیر بعدی فرایند به دلیل برقرارنبودن یک شرط انتخاب نمی‌شود.
برای مثال، فرض کنید در فرایند تأیید درخواست خرید، دو مسیر وجود دارد:
- اگر مبلغ درخواست بیشتر از حد تعیین‌شده باشد، درخواست به مدیر ارشد ارسال شود.
- در غیر این صورت، درخواست به مرحله بعد برود.
اگر داده مبلغ به‌درستی ثبت نشده باشد یا شرط انتقال با مقادیر واقعی سازگار نباشد، ممکن است مسیر مورد انتظار انتخاب نشود.
در این شرایط:
- مقدار داده‌های مرتبط با شرط را در نمونه واقعی بررسی کنید.
- منطق شرط و مسیرهای خروجی فعالیت را بررسی کنید.
- حالت‌های مرزی، مانند مقدار خالی یا مقدار صفر، را در نظر بگیرید.
- بررسی کنید که همه حالت‌های مورد انتظار در طراحی فرایند پوشش داده شده باشند.
تغییر مستقیم قوانین در محیط عملیاتی، بدون بررسی اثر آن بر نمونه‌های در حال اجرا، می‌تواند مشکلات دیگری ایجاد کند. ابتدا علت را در محیط توسعه یا آزمایش بازتولید کنید.
۴. تایمرها و رویدادهای انتظار را بررسی کنید
اگر فرایند پس از یک فعالیت وارد مرحله انتظار شده است، مشخص کنید که این انتظار بر اساس چه رویدادی تعریف شده است.
برای نمونه، یک فرایند ممکن است منتظر بماند تا:
- زمان مشخصی سپری شود؛
- یک پیام یا رویداد دریافت شود؛
- یک فعالیت دیگر تکمیل شود؛
- پاسخ یک سیستم خارجی دریافت شود.
در چنین وضعیتی، باید تنظیمات رویداد، زمان‌بندی، شرایط فعال‌شدن و شواهد اجرای آن را بررسی کنید.
اگر از رویدادهای زمانی استفاده می‌کنید، مطمئن شوید که تعریف زمان مورد انتظار با رفتار واقعی فرایند سازگار است. همچنین در صورت وجود محدودیت‌های محیطی یا خطاهای زمان‌بندی، گزارش‌های مرتبط را بررسی کنید.
صرف اینکه فعالیت قبلی تکمیل شده است، به این معنی نیست که فعالیت بعدی باید بلافاصله اجرا شود.
۵. یکپارچه‌سازی‌ها و سرویس‌های خارجی را بررسی کنید
اگر فرایند برای ادامه اجرا به یک سرویس خارجی وابسته است، خطای ارتباطی یا پاسخ نامعتبر می‌تواند مانع تکمیل مرحله شود.
این موارد را بررسی کنید:
- آیا سرویس مقصد در دسترس است؟
- آیا درخواست با داده‌های مورد انتظار ارسال می‌شود؟
- آیا سرویس پاسخ موفق برمی‌گرداند؟
- آیا خطای احراز هویت، مجوز یا شبکه وجود دارد؟
- آیا زمان انتظار درخواست تمام شده است؟
- آیا خطا در گزارش‌های برنامه یا سرویس قابل مشاهده است؟
برای مثال، اگر فرایند ثبت سفارش باید اطلاعات مشتری را از یک سامانه دیگر دریافت کند، در دسترس نبودن آن سامانه ممکن است بر ادامه فرایند اثر بگذارد.
در این حالت، صرفاً تکرار اجرای فرایند راهکار مناسبی نیست. ابتدا باید علت خطا و نحوه مدیریت آن در طراحی مشخص شود.
۶. گزارش‌های اجرا و خطا را بررسی کنید
اگر وضعیت فرایند با بررسی فعالیت‌ها مشخص نشد، باید شواهد فنی را بررسی کنید.
بسته به نسخه و معماری نصب‌شده، منابع بررسی می‌توانند شامل گزارش‌های برنامه، گزارش‌های سرویس‌های مرتبط، خطاهای یکپارچه‌سازی و اطلاعات قابل مشاهده در ابزارهای مدیریتی بیزاجی باشند.
به دنبال این نشانه‌ها بگردید:
- خطاهایی که در زمان اجرای فعالیت ثبت شده‌اند؛
- خطاهای مربوط به دسترسی به پایگاه داده یا سرویس خارجی؛
- استثناهای مرتبط با قوانین یا کدهای سفارشی؛
- خطاهای زمان‌بندی یا اجرای وظایف پس‌زمینه؛
- تفاوت رفتار میان محیط توسعه و محیط عملیاتی.
بهتر است زمان وقوع مشکل، شناسه نمونه فرایند و فعالیت مربوطه را ثبت کنید تا بتوانید گزارش‌ها را به همان رخداد مرتبط کنید.
مسیر دقیق گزارش‌ها و ابزارهای بررسی به نسخه بیزاجی و شیوه استقرار بستگی دارد؛ بنابراین نباید بدون مشخص‌کردن محیط، یک مسیر ثابت را برای همه نصب‌ها در نظر گرفت.
۷. اگر مشکل فقط در محیط عملیاتی رخ می‌دهد، چه کنیم؟
اگر فرایند در محیط توسعه به‌درستی کار می‌کند اما در محیط عملیاتی متوقف می‌شود، تفاوت‌های دو محیط را بررسی کنید.
موارد مهم عبارت‌اند از:
- نسخه نرم‌افزار و بسته منتشرشده؛
- تنظیمات اتصال به سرویس‌ها؛
- دسترسی حساب‌های سرویس؛
- تنظیمات امنیتی و مجوزها؛
- داده‌های واقعی و شرایطی که در آزمون پوشش داده نشده‌اند؛
- تفاوت تنظیمات زمان‌بندی و زیرساخت.
در محیط عملیاتی، قبل از تغییر تنظیمات یا دست‌کاری داده‌های فرایند، از اطلاعات موردنیاز برای بررسی و بازیابی نسخه پشتیبان مناسب تهیه کنید. تغییر وضعیت نمونه‌های در حال اجرا باید مطابق رویه پشتیبانی و با درک اثر آن انجام شود.
۸. چک‌لیست سریع عیب‌یابی فرایند در بیزاجی
پیش از آنکه مدل فرایند را تغییر دهید، این چک‌لیست را تکمیل کنید:
- وضعیت نمونه فرایند و فعالیت جاری مشخص شده است.
- وظایف معوق و تخصیص آن‌ها بررسی شده‌اند.
- شرایط انتقال و قوانین کسب‌وکار بررسی شده‌اند.
- تایمرها و رویدادهای انتظار بررسی شده‌اند.
- ارتباط با سرویس‌های خارجی آزمایش شده است.
- گزارش‌های خطا در بازه زمانی رخداد بررسی شده‌اند.
- تفاوت محیط توسعه و عملیاتی مشخص شده است.
- علت اصلی مشکل پیش از اعمال تغییر اصلاحی شناسایی شده است.
جمع‌بندی
جلو نرفتن یک فرایند در بیزاجی می‌تواند دلایل متفاوتی داشته باشد؛ از یک وظیفه معوق یا شرط انتقال نادرست گرفته تا مشکل تایمر، دسترسی یا یکپارچه‌سازی.
بهترین روش این است که از وضعیت نمونه فرایند شروع کنیم، فعالیت جاری و شرایط ادامه اجرا را بررسی کنیم و سپس سراغ گزارش‌های فنی برویم. تغییر مدل یا تنظیمات پیش از شناسایی علت اصلی، ممکن است مشکل را پنهان کند یا وضعیت نمونه‌های دیگر را تحت تأثیر قرار دهد.
اگر این مشکل در چندین فرایند یا به‌صورت تکرارشونده رخ می‌دهد، بهتر است علاوه بر رفع موردی، الگوی خطا و طراحی مدیریت خطا در فرایندها نیز بررسی شود.
آیا در سازمان شما فرایندهای بیزاجی بیشتر به دلیل تخصیص وظایف، قوانین کسب‌وکار یا یکپارچه‌سازی با سامانه‌های دیگر دچار مشکل می‌شوند؟ شناسایی الگوی پرتکرار، نقطه شروع مناسبی برای بهبود پایداری فرایندهاست.
بدون دیدگاه