توقف و ازسرگیری اتوماسیون باید از ابتدا بخشی از طراحی فرایند باشد، نه دکمه‌ای که بعد از اولین خطا به پنل اضافه می‌شود. مدیر باید بداند توقف دقیقاً کدام کار را متوقف می‌کند، چه عملیات‌هایی هنوز در حال اجرا هستند و برای ادامه‌دادن چه چیزهایی دوباره بررسی می‌شوند. خاموش‌کردن یک سرویس یا بستن پنجره مرورگر، لزوماً کارهایی را که قبلاً به سامانه دیگر ارسال شده‌اند متوقف نمی‌کند.
این راهنما برای کسب‌وکارهایی است که پردازش اسناد، گردش درخواست‌ها یا اقدام‌های مبتنی بر هوش مصنوعی را خودکار کرده‌اند. هدف، طراحی کنترل مدیریتی روشن برای مکث و ادامه کار است؛ نه ارائه دستور توقف تجهیزات صنعتی یا سامانه‌های ایمنی. در محیط‌های حساس، کنترل نرم‌افزار اداری جایگزین روال عملیاتی تأییدشده و نقش‌های مجاز نمی‌شود.
چرا دکمه توقف به تعریف دقیق نیاز دارد؟
فرض کنید یک فرایند، درخواست‌های ورودی را دسته‌بندی می‌کند و سپس برای هر درخواست یک پرونده در سامانه پشتیبانی می‌سازد. تیم متوجه می‌شود بخشی از ورودی‌ها قالب اشتباه دارند. اگر دکمه توقف فقط دریافت ورودی جدید را ببندد، کارهای قبلاً دریافت‌شده ممکن است همچنان پرونده بسازند. اگر مدیر تصور کند همه‌چیز فوراً متوقف شده، فاصله میان انتظار و رفتار واقعی ایجاد می‌شود.
قبل از طراحی رابط، مشخص کنید واحد کنترل چیست: کل فرایند، یک مشتری، یک گروه ورودی یا فقط یک اجرای مشخص؟ توقف گسترده برای مشکل محدود می‌تواند کار سالم بقیه تیم‌ها را هم معطل کند. از طرف دیگر، کنترل بیش از حد جزئی ممکن است مهار مشکل را دشوار کند. دامنه‌های توقف باید با مسئولیت و نیاز واقعی کسب‌وکار هماهنگ باشند.
چهار مفهوم متفاوت را با یک نام نمایش ندهید
بستن پذیرش ورودی جدید
در این حالت، فرایند کار تازه‌ای را شروع نمی‌کند اما اجرای فعلی ممکن است ادامه پیدا کند. ورودی‌های تازه باید سرنوشت مشخصی داشته باشند: رد با پیام روشن، نگهداری در صف یا هدایت به مسیر دستی. ناپدیدشدن ورودی به دلیل خاموش‌بودن فرایند قابل قبول نیست. همچنین صف‌شدن بی‌نهایت بدون هشدار، مشکل را فقط به زمان دیگری منتقل می‌کند.
مکث در نقطه کنترل‌شده
مکث یعنی اجرای فرایند در مرزی تعریف‌شده منتظر بماند و اطلاعات لازم برای ادامه حفظ شود. این مرز می‌تواند پیش از ارسال پیام یا پیش از ثبت نهایی باشد. اگر عملیات فعلی نقطه توقف ندارد، رابط نباید وعده مکث فوری بدهد. عبارت «درخواست مکث ثبت شد» با «فرایند مکث کرده است» دو وضعیت جدا هستند.
درخواست لغو
لغو معمولاً به معنی درخواست پایان‌دادن به ادامه کار است، نه پاک‌کردن گذشته. در بعضی ابزارها اجرای فرایند فرصت دارد درخواست را دریافت کند و منابع موقت را آزاد کند. جزئیات به ابزار و پیاده‌سازی وابسته است. در مستند رسمی Temporal درباره لغو و خاتمه، لغو تعاملی از خاتمه اجباری تفکیک شده است؛ این نمونه نشان می‌دهد نام یک دکمه به‌تنهایی رفتار آن را توضیح نمی‌دهد.
خاتمه اجباری
پایان اجباری اجرا ممکن است فرصت تکمیل اقدامات پاک‌سازی را ندهد. بنابراین نباید آن را هم‌معنی «همه چیز به حالت قبل برگشت» معرفی کرد. سفارش ثبت‌شده، پیام ارسال‌شده یا رزرو انجام‌شده می‌تواند همچنان وجود داشته باشد. سازمان باید بداند پس از چنین اقدامی چه مواردی نیازمند بررسی و تعیین تکلیف‌اند و چه کسی مسئول این بررسی است.
وضعیت کارهای درحال‌اجرا را قابل مشاهده کنید
پس از درخواست توقف، یک خلاصه عملیاتی نشان دهید: چند مورد هنوز در حال کارند، چند مورد در مرز تعیین‌شده منتظر مانده‌اند و نتیجه چند مورد هنوز معلوم نیست. این دسته‌ها نباید با یک نشان سبز یا قرمز جایگزین شوند. وضعیت نامعلوم یک واقعیت مستقل است و پنهان‌کردن آن اعتماد مدیر به کنترل را کاهش می‌دهد.
برای هر مورد، آخرین مرحله قطعی و زمان آخرین مشاهده را ثبت کنید. دریافت پاسخ از یک سرویس با تأیید نهایی اثر تجاری همیشه یکسان نیست. اگر درخواست ارسال شده ولی پاسخ نیامده، نتیجه را به‌طور خودکار «انجام‌نشده» فرض نکنید. پیوند به سابقه اجرا و شناسه درخواست بیرونی کمک می‌کند تیم بتواند وضعیت را بدون جست‌وجوی پراکنده بررسی کند.
توقف، بازگشت خودکار به عقب نیست
یک فرایند ممکن است چند اثر مستقل داشته باشد. مثلاً ابتدا پرونده بسازد، بعد پیام بفرستد و در پایان گزارش ثبت کند. توقف میان این مراحل به معنی حذف پرونده یا پس‌گرفتن پیام نیست. در طراحی، اثرهای انجام‌شده را از مرحله‌های باقی‌مانده جدا کنید و برای هر اثر مشخص کنید آیا اصلاح آن ممکن است و به چه مجوزی نیاز دارد.
اقدام جبرانی نیز همیشه وارون دقیق اقدام اصلی نیست. ممکن است اصلاح پرونده نیازمند ثبت توضیح باشد یا لغو یک رزرو شرایط جداگانه داشته باشد. بهتر است رابط، فهرست اقدامات پیشنهادی و وضعیت تأیید آن‌ها را نمایش دهد. ادعای «بازگردانی کامل» فقط وقتی معنا دارد که دامنه و محدودیت آن برای همان فرایند آزموده شده باشد.
ازسرگیری از کدام نقطه انجام می‌شود؟
ادامه‌دادن از آخرین نقطه ثبت‌شده با اجرای دوباره از ابتدا فرق دارد. کاربر باید پیش از اقدام بداند کدام مرحله‌ها تکرار می‌شوند و کدام اثرها قبلاً ثبت شده‌اند. بازگشت به ابتدای فرایند صرفاً برای ساده‌کردن برنامه‌نویسی، ممکن است ثبت یا ارسال تکراری ایجاد کند. برای این بخش، راهنمای اجرای مجدد امن اتوماسیون موضوع جلوگیری از تکرار اثرها را جداگانه بررسی می‌کند.
در یک طراحی قابل توضیح، رکورد اجرا علاوه بر وضعیت، نسخه ورودی و مرحله قطعی را نگه می‌دارد. هنگام ادامه، نرم‌افزار باید تشخیص دهد آیا هنوز می‌تواند از همان نقطه پیش برود یا به بررسی انسانی نیاز دارد. پیام «ادامه ممکن نیست؛ اطلاعات مرجع تغییر کرده» از ادامه خاموش با فرض قدیمی بهتر است.
گذشت زمان را نادیده نگیرید
فرایندی که چند ساعت یا چند روز مکث کرده، ممکن است با اطلاعات منقضی روبه‌رو شود. مسئول درخواست عوض شده، مجوز دسترسی پایان یافته یا شرایط تجاری تغییر کرده است. بنابراین ازسرگیری فقط تغییر یک پرچم نیست؛ می‌تواند نیازمند اعتبارسنجی دوباره ورودی، دسترسی و محدودیت‌های زمانی باشد. فهرست این کنترل‌ها باید برای هر فرایند تعریف شود.
هنگام تغییر قوانین، ادامه کار باید قابل پیش‌بینی باشد
اگر تیم در زمان مکث، قانون دسته‌بندی را اصلاح کند، تکلیف اجرای قبلی چیست؟ ادامه با نسخه قبلی، انتقال به نسخه جدید یا ارجاع برای تصمیم انسانی، هرکدام پیامد متفاوتی دارند. تصمیم باید از قبل تعریف شود و در سابقه قابل مشاهده باشد. استفاده ناخواسته از ترکیب دو نسخه می‌تواند نتیجه‌ای بسازد که هیچ‌کس آن را طراحی نکرده است.
موضوع این مقاله کنترل مکث و ادامه است، اما سیاست نسخه‌ها به آن متصل می‌شود. راهنمای نسخه‌بندی قوانین اتوماسیون برای تعیین رفتار اجراهای قدیمی هنگام تغییر قانون مفید است. در پنل ادامه، نسخه‌ای که اجرا با آن پیش خواهد رفت و هر بررسی لازم را روشن نشان دهید.
یک سناریوی فرضی برای طراحی پایلوت
یک تیم خدماتی از هوش مصنوعی برای پیشنهاد گروه درخواست استفاده می‌کند و ثبت نهایی پرونده مرحله جداگانه‌ای است. پس از مشاهده ورودی نامناسب، مسئول مجاز پذیرش گروه مربوط را می‌بندد. اجرای درحال تحلیل می‌تواند تا نقطه پیش از ثبت نهایی برسد، اما اجازه عبور از آن مرز را ندارد. این رفتار باید در طراحی صریح باشد؛ مدل زبانی خودش مسئول تعیین مرز توقف نیست.
تیم سپس ورودی‌ها را بررسی می‌کند. بعضی سالم‌اند، بعضی نیازمند اصلاح‌اند و نتیجه ارسال چند مورد به سامانه مقصد هنوز معلوم نیست. موارد نامعلوم ابتدا تعیین تکلیف می‌شوند. پس از رفع علت، تعداد محدودی از موارد آماده ادامه می‌یابند تا رفتار مشاهده شود. این مثال یک طرح پیشنهادی است و ادعای اجرای واقعی یا نتیجه آماری ندارد.
اگر همان ابتدا همه صف آزاد شود، یک خطای باقی‌مانده می‌تواند دوباره در مقیاس بزرگ تکرار شود. آزادسازی مرحله‌ای به تیم امکان مشاهده می‌دهد، اما مقدار هر مرحله را باید با ظرفیت سامانه مقصد و ریسک فرایند تعیین کرد. معیار توقف دوباره و فرد پاسخ‌گو نیز باید قبل از شروع مشخص باشند.
کنترل دسترسی و سابقه تصمیم‌ها
اجازه مکث، اجازه لغو و اجازه ازسرگیری الزاماً نباید یکسان باشند. ممکن است اپراتور بتواند اجرای مشکوک را نگه دارد، ولی ادامه گروهی نیازمند تصمیم سرپرست باشد. این تفکیک نباید کار روزانه را بی‌دلیل کند کند؛ سطح کنترل باید متناسب با اثر تجاری باشد. مهم این است که اختیار هر نقش روشن و قابل بررسی باشد.
برای هر تغییر، دامنه، دلیل، درخواست‌کننده، زمان و نتیجه ثبت شود. اگر اقدام به مرحله نهایی نرسید، سابقه باید این موضوع را هم نشان دهد. ثبت فقط کلیک کاربر کافی نیست. یک درخواست توقف ممکن است پذیرفته شود اما اجرای فعال هنوز فرصت رسیدن به مرز مکث را پیدا نکرده باشد؛ این فاصله باید در گزارش باقی بماند.
چه آزمون‌هایی قبل از بهره‌برداری لازم است؟
پایلوت را فقط با صف خالی امتحان نکنید. درخواست مکث را هنگام تحلیل، پیش از ارسال و زمانی که پاسخ سرویس مقصد دیر می‌رسد آزمایش کنید. بررسی کنید که در هر حالت متن رابط با رفتار واقعی سازگار باشد. اگر سرویس بیرونی قطع شد، نرم‌افزار باید وضعیت نامعلوم را حفظ کند و ادامه را بر اساس حدس انجام ندهد.
سناریوی درخواست هم‌زمان دو مدیر، قطع اتصال پنل و راه‌اندازی مجدد پردازشگر هم ارزش آزمودن دارد. دستور توقف نباید صرفاً در حافظه یک صفحه باقی بماند. بعد از بازشدن مجدد پنل، مدیر باید وضعیت واقعی را ببیند. اگر ابزار انتخابی چنین تضمینی ندارد، محدودیت را مستند کنید و در طراحی کنترل از آن عبور نکنید.
معیار پذیرش قابل سنجش تعریف کنید
به‌جای عبارت «توقف سریع»، زمان و مرز مورد انتظار را برای هر نوع عملیات مشخص کنید. همچنین بسنجید که موارد معلق گم نمی‌شوند، اثر تکراری ایجاد نمی‌شود و مسئول بررسی موارد نامعلوم معلوم است. هیچ درصد بهبود عمومی برای همه سازمان‌ها وجود ندارد؛ خط مبنا و نتیجه پایلوت خودتان باید مبنای تصمیم باشند.
جمع‌بندی و قدم بعدی
اتوماسیون قابل کنترل فقط توان انجام کار ندارد؛ امکان مکث روشن، لغو قابل توضیح و ادامه بر اساس وضعیت معتبر هم دارد. نقطه شروع، تعریف دامنه توقف و اثرهای هر مرحله است. سپس باید رفتار صف، عملیات درحال‌اجرا، نسخه قانون و اطلاعاتی که در زمان مکث تغییر می‌کنند مشخص شود. دکمه مناسب نتیجه این طراحی است، نه جایگزین آن.
برای شروع، یک فرایند واقعی و چند موقعیتی را انتخاب کنید که در آن‌ها امروز مجبور می‌شوید دستی دخالت کنید. مرز مناسب مکث و شرط ادامه را روی همان فرایند بنویسید. برای بررسی طراحی این کنترل‌ها و اتصال آن‌ها به سامانه‌های موجود، از خدمات هوش مصنوعی و اتوماسیون ایزی‌ساز کمک بگیرید؛ هدف، خودکارسازی همراه با اختیار و پاسخ‌گویی روشن است.