وقتی از خودکارسازی فرایندهای دستی حرف می‌زنیم، تصویر ذهنی بیشتر ما یک ربات انسان‌نما نیست؛ برنامه‌ای است که کارهای تکراری را به‌جای انسان انجام می‌دهد. این برنامه‌ها با نام ربات‌های نرم‌افزاری (software robots) یا خودکارسازی فرایند رباتیک (Robotic Process Automation یا RPA) شناخته می‌شوند و بیشتر جایی به کار می‌آیند که رابط برنامه‌نویسی (Application Programming Interface یا API) مناسبی وجود ندارد یا ساختنش صرف نمی‌کند. مسئله اصلی هم انتخاب ابزار نیست؛ تشخیص این است که کدام کار دستی ارزش خودکار شدن دارد و ربات را چگونه بسازیم که با نخستین تغییر کوچک در سامانه مبدأ از کار نیفتد.
ربات نرم‌افزاری در عمل چه می‌کند؟
هر ربات نرم‌افزاری، ساده یا پیچیده، از سه جزء ساخته می‌شود: یک محرک (trigger) که اجرای ربات را آغاز می‌کند، منطقی که تصمیم می‌گیرد چه کاری درست است، و اقدامی که در نهایت روی یک یا چند سامانه انجام می‌شود.
نکته‌ای که اغلب اشتباه گرفته می‌شود این است که ربات نرم‌افزاری با خزنده وب (web crawler) یکی نیست؛ خزنده محتوای صفحات را می‌خواند و استخراج می‌کند، در حالی که ربات فرایندی را از ابتدا تا انتها به سرانجام می‌رساند. اگر این تفکیک روشن نباشد، دامنه پروژه و انتظارات از آن هر دو خراب می‌شود؛ تفکیک انواع ربات‌ها و خزنده‌ها و سیاست‌گذاری روی آن‌ها کمک می‌کند پیش از شروع، مرزها را دقیق تعیین کنید.
یک مثال روزمره
فرض کنید هر روز صبح یکی از کارشناسان، صندوق ایمیل سفارش‌ها را باز می‌کند، پیوست‌ها را ذخیره می‌کند، اطلاعات هر سفارش را در سامانه سازمانی ثبت می‌کند، برای مشتری ایمیل تأیید می‌فرستد و در یک فایل اکسل علامت می‌زند که کار انجام شده است. این زنجیره، الگوی کلاسیک یک کار دستی مناسب خودکارسازی است: پله‌های مشخص، داده‌های ساخت‌یافته و قاعده‌ای که همیشه تکرار می‌شود. ربات همان کارها را انجام می‌دهد، با این تفاوت که برای هر اجرا یک شناسه ردیابی و یک سطر لاگ برجا می‌گذارد.
کدام فرایند ارزش خودکارسازی دارد؟
پیش از نوشتن یک خط کد، فهرست زیر را روی فرایند هدف بیازمایید:
- تکرار و قاعد‌مندی: مراحل ثابت‌اند و تصمیم‌گیری انسانی در آن‌ها کم است.
- حجم و زمان‌بری: کار به‌طور روزانه یا هفتگی بارها تکرار می‌شود و وقت زیادی می‌گیرد.
- ورودی ساخت‌یافته: داده‌ها از فرم، ایمیل، فایل یا صفحه‌ای با ساختار مشخص می‌آیند.
- هزینه خطا: فراموشی یا جابه‌جایی یک رقم، پیامد جدی دارد.
- پایداری نسبی سامانه‌ها: رابط‌هایی که ربات با آن‌ها کار می‌کند، هر هفته تغییر نمی‌کنند.
در مقابل، فرایندی که هر بار استثنای تازه دارد، یا خروجی‌اش قضاوت انسانی می‌خواهد، گزینه بدی برای خودکارسازی کامل است؛ چنین فرایندی را باید «خودکارسازی جزئی» کرد و نقطه تصمیم را برای انسان نگه داشت.
چهار الگوی پیاده‌سازی که باید بشناسید
- خودکارسازی رابط کاربری (User Interface Automation): ربات مثل یک کاربر روی پنجره‌ها و مرورگر کلیک و تایپ می‌کند. سریع راه می‌افتد و به دسترسی ویژه نیاز ندارد، اما شکننده‌ترین الگو است؛ چون هر تغییر در چیدمان صفحه، آن را می‌شکند.
- یکپارچه‌سازی از راه API: پایدارترین گزینه است، اما به وجود سرویس و مجوز دسترسی وابسته است. اگر سامانه مقصد API دارد، همیشه آن را به خودکارسازی رابط کاربری ترجیح دهید.
- رویدادمحور یا زمان‌بند: ربات با رسیدن یک رویداد (مثل ایمیل تازه) یا در ساعت مشخصی بیدار می‌شود. کارهای زمان‌بند معمولاً ساده‌ترند، ولی اگر اجرای قبلی نیمه‌کاره مانده باشد، اجرای بعدی می‌تواند داده را خراب کند.
- انسان در حلقه (human in the loop): ربات کار سنگین را انجام می‌دهد و نتیجه را برای تأیید نهایی به یک نفر نشان می‌دهد. این الگو برای ماه‌های اول، هم ریسک را کم می‌کند و هم اعتماد سازمان را می‌سازد.
در فرایندهایی که خروجی، یک سند رسمی است، الگوی رابط کاربری اغلب ناگزیر می‌شود؛ نمونه‌اش ربات صدور خودکار و مدیریت بارنامه‌های شهری که باید هم با سامانه‌های بیرونی حرف بزند و هم سند نهایی را بسازد. در چنین پروژه‌هایی، بخش عمده کار نه کلیک‌ها، بلکه مدیریت خطا و بازبینی است.
دام‌های رایج در پروژه‌های خودکارسازی
- نبود لاگ و رهگیری: رباتی که کار می‌کند اما نمی‌گوید چه کرده، در نخستین خطا تبدیل به جعبه سیاه می‌شود.
- شکنندگی انتخابگرها: اگر ربات بر پایه متن یا جای دقیق یک دکمه ساخته شود، تغییر کوچک در رابط، همه‌چیز را متوقف می‌کند.
- مدیریت نامناسب اعتبارنامه‌ها: رمز سامانه‌ها را داخل کد نگذارید؛ از مخزن امن و دسترسی محدود استفاده کنید.
- اجرای تکراری و نبود تکرارپذیری ایمن (idempotency): اگر ربات وسط کار قطع شود، اجرای دوباره نباید دو فاکتور یا دو رکورد بسازد.
- خودکارسازی فرایند اشتباه: خودکار کردن یک رویه معیوب، فقط سرعت تولید خطا را بالا می‌برد. اول فرایند را اصلاح کنید، بعد ربات بنویسید.
- اتکا به دمو: رباتی که در نمایش روی داده‌های تمیز بی‌نقص کار می‌کند، با داده واقعی و ناقص رفتار دیگری دارد. عبور از دموی جذاب به فرایند قابل اتکا مرحله‌ای است که بیشتر پروژه‌ها در آن شکست می‌خورند.
نقشه راه عملی برای شروع
- فرایند فعلی را همان‌طور که هست مستند کنید؛ نه آن‌طور که فکر می‌کنید باید باشد.
- یک مورد محدود را به‌عنوان پایلوت انتخاب کنید که پرتکرار باشد و پیامد خطایش کم.
- پیش از کدنویسی، فهرست حالت‌های استثنا را بنویسید: داده ناقص، سامانه قطع، دسترسی منقضی.
- از روز اول لاگ، هشدار و شناسه ردیابی برای هر اجرا در نظر بگیرید.
- مدتی ربات و انسان را موازی اجرا کنید و خروجی‌ها را مقایسه کنید.
- پس از تثبیت، مالکیت فنی و رویه نگهداری را مشخص کنید؛ ربات بدون نگهداری، عمر کوتاهی دارد.
جمع‌بندی
خودکارسازی فرایندهای دستی، پیش از آنکه یک پروژه فنی باشد، یک تصمیم مدیریتی است: کدام کار تکراری را کنار بگذاریم و چه مقدار کنترل را برای خود نگه داریم. ربات خوب، رباتی نیست که همه‌کار انجام دهد؛ رباتی است که کار مشخصی را به‌طور قابل اتکا، قابل رهگیری و قابل بازگشت انجام دهد و وقتی مطمئن نیست، بایستد و خبر بدهد. از یک فرایند کوچک و پرتکرار شروع کنید، حالت‌های خطا را جدی بگیرید و اجازه دهید سازمان با ربات کار کردن را یاد بگیرد؛ آن‌وقت می‌توانید دامنه را گسترش دهید.
