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