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