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