سیستم قدیمی ما رابط برنامه‌نویسی ندارد؛ دانابات را چطور به آن وصل کنیم؟

سوالی که قبل از هر جلسه‌ی فنی پرسیده می‌شود

اولین چیزی که مدیر فناوری یک سازمان بعد از شنیدن معرفی دانابات می‌پرسد، معمولاً درباره‌ی هوش مصنوعی نیست؛ درباره‌ی سیستم‌های خودش است. «اتوماسیون اداری ما ده سال پیش نوشته شده، مستندات درستی ندارد و برنامه‌نویسش هم دیگر با ما کار نمی‌کند. این وسط دانابات کجا می‌نشیند؟» این پرسش جدی است و جواب «نگران نباشید» جواب خوبی برایش نیست.

در مقاله‌ی اسمارت‌کانکت توضیح دادیم ادعای اصلی این بخش چیست: هر سیستمی در سازمان، قدیمی یا جدید، بدون بازنویسی یک دستیار گفتگویی می‌گیرد و دانابات کنار سیستم می‌نشیند، فقط می‌خواند و پاسخ می‌دهد. این مقاله همان ادعا را روی سخت‌ترین حالت آزمون می‌کند: سیستمی که رابط برنامه‌نویسی ندارد. هدف این نیست که بگوییم همه‌چیز ساده است. هدف این است که دقیق بگوییم چه راه‌هایی وجود دارد، هر کدام برای چه وضعیتی مناسب است و کجا باید انتظارتان را تنظیم کنید.

چرا «رابط ندارد» معمولاً پایان گفتگو نیست

دانابات برای کار کردن لازم نیست وارد دل سیستم شما شود. دو چیز می‌خواهد: داده‌ای که قرار است درباره‌اش پاسخ بدهد، و در صورت امکان، پاسخ خود سیستم به این پرسش که «این کاربر اجازه‌ی دیدن این سند را دارد یا نه؟». یعنی مسئله «ورود به سیستم» نیست؛ مسئله «رساندن داده به دانابات» است، و برای این کار بیش از یک مسیر وجود دارد.

اصل دیگری هم این وضعیت را ساده‌تر می‌کند: دانابات چیزی درباره‌ی «نامه» یا «قرارداد» یا «فاکتور» از پیش نمی‌داند. نوع سند در هر اتصال تعریف می‌شود و معنای آن با تنظیمات و نگاشت فیلدها مشخص می‌شود، نه با برنامه‌نویسی تازه. به همین دلیل وصل کردن سیستم دوم و سوم، کاری از جنس تنظیم است و از صفر شروع نمی‌شود. این یعنی هزینه‌ی اتصال اولین سیستم، تقریباً همه‌ی هزینه‌ی یادگیری است.

سازمان‌ها معمولاً چهار وضعیت دارند و برای هر کدام یک مسیر هست. سه مسیر اول برای سیستم‌هایی است که به شکلی با بیرون حرف می‌زنند. مسیر چهارم برای سیستم قدیمی است و بخش اصلی این مقاله به آن می‌پردازد.

مسیر اول: سیستم رابط دارد

اگر سیستم شما یک رابط برنامه‌نویسی دارد، ساده‌ترین حالت همین است. داده به‌صورت خودکار وارد دانابات می‌شود و همیشه به‌روز می‌ماند. سیستم هر سند تازه را می‌فرستد، دانابات آن را می‌خواند و از لحظه‌ی بعد درباره‌اش پاسخ می‌دهد.

در این مسیر، قابلیت‌هایی که از خود سیستم سؤال می‌پرسند هم بیشترین کارایی را دارند: استعلام زنده‌ی مجوز پیش از نمایش هر سند، و پاسخ به پرسش‌هایی مثل «الان این نامه کجای کارتابل است؟». چون سیستم می‌تواند به این پرسش‌ها جواب بدهد، دانابات هم می‌تواند از آن بپرسد.

مسیر دوم: ظاهر سیستم نباید تغییر کند

گاهی مشکل فنی نیست، مشکل سیاسی یا سازمانی است. کاربران به ظاهر فعلی سیستم عادت کرده‌اند، یا تغییر صفحه‌های سیستم نیاز به تأیید چند واحد دارد. در این حالت دانابات فقط پاسخ را در اختیار می‌گذارد و شما آن را در صفحه‌ی خودتان و با ظاهر خودتان نشان می‌دهید. دانابات در این مسیر مثل یک موتور پاسخ‌گویی پشت صحنه کار می‌کند و کاربر چیز تازه‌ای در رابط نمی‌بیند.

مسیر سوم: تیم فنی فرصت ندارد

شاید رابط برنامه‌نویسی وجود دارد، اما تیم فنی شما سه ماه آینده را پر کرده است. برای این وضعیت، دانابات یک ویجت در گوشه‌ی صفحه می‌دهد. با افزودن یک خط به صفحه، دستیار در همان سیستم ظاهر می‌شود. این ساده‌ترین مسیر برای شروع است و برای آزمایش اولیه هم بسیار مناسب است، چون هیچ تغییر عمیقی در سیستم ایجاد نمی‌کند و هر زمان بخواهید می‌توانید برش دارید.

مسیر چهارم: سیستم قدیمی، بدون رابط

این همان سوالی است که عنوان مقاله از آن آمده. وقتی سیستم هیچ رابطی ندارد، سه راه عملی وجود دارد.

راه اول، پایگاه داده‌ی گزارش‌گیری است. بسیاری از سیستم‌های قدیمی هرچند رابط برنامه‌نویسی ندارند، یک پایگاه داده‌ی گزارش‌گیری دارند که مدیران از آن برای گزارش‌های دوره‌ای استفاده می‌کنند. دانابات می‌تواند از همین منبع بخواند.

راه دوم، خروجی زمان‌بندی‌شده است. سیستم هر شب یا هر هفته یک خروجی از اسناد می‌دهد و دانابات آن را وارد می‌کند. این روش اگر سیستم تنها توانایی «خروجی گرفتن» دارد، کاملاً کافی است.

راه سوم، خواندن صفحه‌های داخلی است. اگر سیستم صفحه‌هایی دارد که اطلاعات در آن‌ها نمایش داده می‌شود، دانابات می‌تواند صفحه‌های پرتال و سایت‌های داخل شبکه را بخواند، حتی اگر با جاوااسکریپت ساخته شده باشند. این راه آخرین چاره است، چون به ظاهر صفحه‌ها وابسته است و باید همراه با تغییر آن‌ها پایش شود.

هیچ‌کدام از این سه راه نیاز به دست زدن به کد سیستم قدیمی ندارند. و چون دانابات فقط می‌خواند و چیزی در سیستم شما تغییر نمی‌دهد، ریسک این اتصال برای سیستم اصلی عملاً صفر است.

سه سناریوی واقعی‌نما

این سناریوها فرضی‌اند و نمونه‌ی مشتری مشخصی نیستند. هدفشان نشان دادن این است که انتخاب مسیر در عمل چطور انجام می‌شود.

سناریوی اول، دبیرخانه‌ی یک سازمان دولتی. اتوماسیون اداری ده سال قدمت دارد و رابطی ندارد، اما یک پایگاه داده‌ی گزارش‌گیری دارد که واحد آمار از آن استفاده می‌کند. مسیر انتخابی، همان پایگاه گزارش‌گیری است. نتیجه این می‌شود که کارشناس می‌پرسد «آخرین مکاتبات با فلان شرکت درباره‌ی قرارداد نگهداری چه بود؟» و دانابات کل زنجیره‌ی نامه‌ها، شامل عطف و پیرو، را با نتیجه‌ی نهایی نشان می‌دهد. محدودیتش این است که تازگی پاسخ به نحوه‌ی به‌روزرسانی آن پایگاه وابسته است.

سناریوی دوم، واحد مالی یک شرکت. قراردادها در یک سیستم قدیمی نگهداری می‌شوند که هر شب یک خروجی از اسناد می‌دهد. مسیر انتخابی، خروجی زمان‌بندی‌شده است. کارشناس مالی می‌پرسد «شرایط پرداخت و جریمه‌ی تأخیر در قرارداد فلان تأمین‌کننده چیست؟» و جواب را با ارجاع به بند دقیق می‌گیرد، به‌جای ورق زدن قراردادی سی‌صفحه‌ای. محدودیتش روشن است: اصلاحیه‌ای که امروز ثبت شده، تا خروجی بعدی دیده نمی‌شود.

سناریوی سوم، پشتیبانی مشتری. سیستم پشتیبانی رابط دارد، اما تیم فنی تا انتهای فصل درگیر پروژه‌ی دیگری است. مسیر انتخابی، ویجت گوشه‌ی صفحه با یک خط افزودن است. در یک هفته تیم پشتیبانی می‌تواند آزمایش کند که آیا جمع‌کردن سابقه‌ی یک مشتری از چند سیستم، در چند ثانیه ممکن می‌شود یا نه، بی‌آنکه قدمی از برنامه‌ی تیم فنی عقب بیفتد.

محدودیت‌هایی که باید پیش از تصمیم بدانید

اگر این مقاله فقط خوبی‌ها را می‌گفت، به شما خدمت نکرده بود. چند محدودیت واقعی هست.

اول، دانابات از داده‌ای که به او می‌رسد پاسخ می‌سازد. اگر نامه‌های سیستم قدیمی شما موضوع ندارند، شماره‌ی ثبت درست نیست یا بخشی از اسناد فقط تصویر اسکن‌شده است، پاسخ‌ها هم همین کیفیت را منعکس می‌کنند. برای اسناد اسکن‌شده، متن استخراج‌شده می‌تواند پیش از استفاده توسط انسان بازبینی شود، اما این بازبینی کار و زمان می‌خواهد.

دوم، تازگی پاسخ به مسیر انتخابی وابسته است. در مسیر خروجی زمان‌بندی‌شده، پاسخ همیشه کمی عقب‌تر از سیستم اصلی است. اگر برای کاری که انجام می‌دهید «همین الان» اهمیت دارد، این مسیر کافی نیست.

سوم، قابلیت‌هایی که از خود سیستم می‌پرسند، مثل استعلام زنده‌ی مجوز و وضعیت لحظه‌ای نامه، به این بستگی دارند که سیستم بتواند به آن پرسش‌ها جواب بدهد. اگر سیستم قدیمی شما راهی برای پاسخ دادن ندارد، طبیعتاً این دو قابلیت برای آن سیستم محدود می‌شوند و قواعد دسترسی باید خود سازمان تعریف کند. این موضوع را باید در همان جلسه‌ی اول روشن کنید، نه بعد از امضای قرارداد.

چهارم، دانابات جایگزین اصلاح سیستم قدیمی نیست. اگر خود سیستم داده‌ی نادرست تولید می‌کند، دانابات آن را بهتر نمی‌کند. فقط پیدا کردنش را آسان‌تر می‌کند، و گاهی همین آسان‌تر شدن نشان می‌دهد داده کجا مشکل دارد.

چطور مسیر درست را انتخاب کنیم

برای انتخاب مسیر معمولاً چهار پرسش کافی است. اول، آیا سیستم به هر شکلی می‌تواند داده بدهد؟ اگر بله، مسیر اول بهترین است. دوم، آیا ظاهر سیستم نباید تغییر کند؟ اگر بله، مسیر دوم. سوم، آیا تیم فنی فرصت ندارد؟ اگر بله، مسیر سوم برای شروع. چهارم، اگر هیچ‌کدام از این‌ها صدق نمی‌کند، به مسیر چهارم برمی‌گردید و سه راهش را از نظر تازگی داده، هزینه‌ی نگهداری و پایداری مقایسه می‌کنید.

پرسش پنجمی هم هست که بیشتر فراموش می‌شود: داده چقدر تازه باید باشد؟ پاسخ این سؤال، بیش از هر چیز دیگری، تعیین می‌کند کدام مسیر برای شما کافی است.

مسیر پیشنهادی شروع کار

روش پیشنهادی دانابات برای شروع، پنج مرحله است. مرحله‌ی اول یک جلسه‌ی شناخت است، حدود یک جلسه، که در آن سیستمی را انتخاب می‌کنید که بیشترین مراجعه را دارد. مرحله‌ی دوم اثبات مفهوم روی بخشی از داده‌ی واقعی شماست، یک تا دو هفته. مرحله‌ی سوم ارزیابی با سؤال‌های واقعی کاربران است، حدود یک هفته، تا دقت به یک عدد مشخص تبدیل شود و حدس نماند؛ توضیح بیشتر این کار در مقاله‌ی سنجش دقت با سؤال‌های واقعی آمده است. مرحله‌ی چهارم بهره‌برداری آزمایشی در یک واحد است، حدود دو هفته. مرحله‌ی پنجم گسترش تدریجی به سیستم‌ها و واحدهای دیگر است.

این ترتیب عمداً از «کوچک» شروع می‌شود. اگر سیستم شما قدیمی و بدون رابط است، همین مسیر پنج‌مرحله‌ای بهترین ابزار برای فهمیدن این است که کدام یک از چهار مسیر برای شما جواب می‌دهد، پیش از آنکه هزینه‌ی بزرگی کرده باشید. برای سازمان‌هایی که ساختار چندسیستمی دارند، توضیح بیشتر در مقاله‌ی تعریف بخش سازمان‌های بزرگ آمده است.

اشتباهی که در این مرحله رایج است

رایج‌ترین اشتباه، صبر کردن است. سازمان تصمیم می‌گیرد اول سیستم قدیمی را نوسازی کند و بعد سراغ هوش مصنوعی برود. اما نوسازی یک سیستم اداری ریشه‌دار، سال‌ها طول می‌کشد، و در این سال‌ها کارکنان همچنان ساعت‌ها دنبال یک نامه می‌گردند. چون دانابات کنار سیستم می‌نشیند و بازنویسی نمی‌خواهد، لازم نیست منتظر نوسازی بمانید.

اشتباه دوم، انتخاب پیچیده‌ترین سیستم برای شروع است. مرحله‌ی اول مسیر پیشنهادی همین را می‌گوید: سراغ سیستمی بروید که بیشترین مراجعه را دارد، نه سیستمی که فنی‌ترین چالش را دارد. موفقیت در اولین سیستم باید برای کاربران محسوس باشد، چون اعتماد برای اتصال سیستم دوم و سوم از همین‌جا ساخته می‌شود. و این همان اشتباهی است که معمولاً در مرحله‌ی «جلسه‌ی شناخت» جلوی آن گرفته می‌شود.

جمع‌بندی

«رابط برنامه‌نویسی ندارد» برای دانابات یک مانع نیست، یک وضعیت است. اگر سیستم رابط دارد، داده خودکار و به‌روز وارد می‌شود. اگر ظاهر نباید تغییر کند، فقط پاسخ را می‌گیرید. اگر تیم فنی فرصت ندارد، یک ویجت با یک خط کافی است. و اگر سیستم قدیمی و بدون رابط است، پایگاه گزارش‌گیری، خروجی زمان‌بندی‌شده یا خواندن صفحه‌های داخلی راه‌های عملی‌اند. محدودیت‌ها هم واقعی‌اند: کیفیت پاسخ به کیفیت داده وابسته است، تازگی به مسیر انتخابی بستگی دارد و برخی قابلیت‌ها به این نیاز دارند که سیستم بتواند به پرسش‌ها پاسخ بدهد. برای اینکه ببینید سیستم شما در کدام وضعیت است، به دانابات سر بزنید و جلسه‌ی شناخت را شروع کنید.