مدیر فروش می‌خواهد بداند فروش این ماه چقدر بوده، کدام مشتری هنوز پیگیری نشده و برای یک سفارش مشخص پیش‌فاکتور بسازد. اگر برای هرکدام مجبور باشد بین چند صفحه جست‌وجو کند، بخشی از کار به حافظه و دقت افراد وابسته می‌ماند. اتصال هوش مصنوعی به ERP این مسیر را کوتاه می‌کند؛ به‌شرطی که مدل فقط پاسخ متنی ندهد و بتواند با دسترسی کنترل‌شده، داده بخواند و عملیات مشخصی انجام دهد. در این نوشته می‌بینیم MCP چگونه چنین ارتباطی را برقرار می‌کند و در مایان چه کاربردهایی دارد.
MCP چه چیزی به یک دستیار متنی اضافه می‌کند؟
یک دستیار متنی معمولی می‌تواند درباره فروش، انبار یا حسابداری توضیح بدهد، اما خودش به اطلاعات واقعی کسب‌وکار دسترسی ندارد. اگر از آن بپرسید «فروش هفته گذشته چقدر بود؟»، بدون اتصال به سامانه فقط یک روش کلی برای تهیه گزارش پیشنهاد می‌کند. عدد واقعی را نمی‌بیند و سندی هم ثبت نمی‌کند.
MCP کوتاه‌شدهٔ «پروتکل زمینهٔ مدل» است. این پروتکل یک روش استاندارد برای وصل کردن مدل زبانی به ابزارها، داده‌ها و عملیات مشخص فراهم می‌کند. مدل می‌فهمد چه ابزارهایی در اختیارش است، هر ابزار چه ورودی‌ای می‌خواهد و نتیجه را با چه ساختاری دریافت می‌کند.
تفاوت اصلی اینجاست: مدل از حالت گفت‌وگوی جدا از کسب‌وکار بیرون می‌آید و می‌تواند در چارچوبی مشخص با نرم‌افزار کار کند. برای نمونه، به جای اینکه فقط بگوید «برای صدور پیش‌فاکتور به بخش فروش بروید»، می‌تواند اطلاعات مشتری و کالا را از مایان بخواند، پیش‌نویس سند را بسازد و جزئیات آن را برای بررسی نشان دهد.
MCP خودش مجوز نامحدود ایجاد نمی‌کند و قرار نیست مدل را مستقیما به پایگاه داده بسپارد. این پروتکل فقط زبان مشترک ارتباط است. اینکه مدل چه چیزی ببیند یا چه کاری انجام دهد، به ابزارهای تعریف‌شده، سطح دسترسی کاربر و قوانین سامانه بستگی دارد.
مدل زبانی چگونه از راه MCP با داده‌های مایان کار می‌کند؟
ارتباط معمولا از چند بخش تشکیل می‌شود. کاربر درخواستش را به زبان طبیعی می‌نویسد. مدل هدف درخواست را تشخیص می‌دهد و بررسی می‌کند کدام ابزار برای انجام آن مناسب است. سپس ابزار مربوط، درخواست را با ساختار مشخص به سامانه می‌فرستد.
در مایان، این ابزارها می‌توانند به بخش‌هایی مانند مشتریان، فروش، کالاها و خدمات، مالی و حسابداری یا انبار مربوط باشند. مدل لازم نیست ساختار داخلی پایگاه داده را بداند. برای آن، هر ابزار مانند یک قابلیت روشن تعریف می‌شود: گرفتن فهرست مشتریان، بررسی موجودی، ساخت پیش‌فاکتور یا تهیه گزارش فروش.
مسیر کار را می‌توان این‌طور دید:
- کاربر درخواستش را می‌نویسد: «فروش 30 روز گذشته را بر اساس دستهٔ کالا گزارش کن.»
- مدل تشخیص می‌دهد که این درخواست به گزارش فروش و دادهٔ کالاها نیاز دارد.
- سامانه بررسی می‌کند کاربر اجازهٔ دیدن این داده‌ها را دارد یا نه.
- ابزار، اطلاعات لازم را از بخش مربوط در مایان می‌گیرد.
- مدل نتیجهٔ ساختاریافته را به زبان ساده توضیح می‌دهد.
- اگر درخواست شامل ثبت یا تغییر باشد، عملیات طبق قانون تأیید و دسترسی انجام می‌شود.
در این میان، مدل نباید حدس بزند. اگر نام مشتری مبهم باشد، تاریخ گزارش مشخص نباشد یا کالایی با چند مورد مشابه پیدا شود، باید سؤال تکمیلی بپرسد. گزارش مالی هم باید بر اساس اسناد ثبت‌شده ساخته شود، نه بر اساس برداشت احتمالی از متن کاربر.
برای آشنایی با جایگاه این نوع ارتباط در معماری مایان، می‌توانید صفحهٔ مایان، هوش مصنوعی کسب‌وکار را ببینید. نکتهٔ مهم این است که اتصال هوشمند، جای ساختارهای اصلی کسب‌وکار را نمی‌گیرد. داده‌ها همچنان در بخش‌های مربوط ثبت می‌شوند و مدل از همان اطلاعات استفاده می‌کند.
یک درخواست ساده چگونه به پیش‌فاکتور و گزارش تبدیل می‌شود؟
برای درک بهتر، دو نمونه را بررسی کنیم. این نمونه‌ها نشان می‌دهند درخواست باید چه اطلاعاتی داشته باشد و سیستم در هر مرحله چه کاری انجام می‌دهد.
نمونهٔ اول: ساخت پیش‌فاکتور
فرض کنید یک فروشگاه از مایان برای مدیریت مشتری، کالاها و خدمات و فروش استفاده می‌کند. مدیر می‌تواند چنین درخواستی بنویسد:
«برای مشتری فروشگاه آفتاب، 12 عدد از کالای مدل X و 3 عدد از خدمت نصب را در یک پیش‌فاکتور قرار بده. قیمت‌ها را از فهرست فعلی مایان بخوان و قبل از ثبت، ردیف‌ها و مبلغ نهایی را نشان بده.»
این درخواست چند بخش روشن دارد: مشتری، کالا، خدمت، تعداد، قیمت و مرحلهٔ بررسی. مدل ابتدا مشتری و اقلام را پیدا می‌کند. اگر یک نام چند نتیجه داشته باشد، همان‌جا باید ابهام را اعلام کند. سپس قیمت‌های موجود را می‌خواند و پیش‌نویس را می‌سازد.
در مرحلهٔ بعد، نتیجه باید قابل بررسی باشد. برای مثال، نام مشتری، نام هر قلم، تعداد، قیمت واحد، مبلغ هر ردیف و مبلغ نهایی نشان داده می‌شود. اگر تخفیف یا مالیات در درخواست مشخص نشده باشد، مدل نباید عددی از خودش اضافه کند. باید از کاربر بپرسد یا طبق قانون از پیش تعریف‌شدهٔ سامانه عمل کند.
پس از تأیید، ابزار مربوط می‌تواند پیش‌فاکتور را در مایان ثبت کند. اگر فقط ساخت پیش‌نویس مجاز باشد، سند ذخیره نمی‌شود و نتیجه همان پیش‌نویس باقی می‌ماند. این تفاوت برای اسناد مالی مهم است، چون یک جملهٔ ساده می‌تواند اثر واقعی روی فروش و حساب‌ها داشته باشد.
نمونهٔ دوم: استخراج گزارش مالی
درخواست دوم می‌تواند چنین باشد:
«گزارش فروش ماه گذشته را بر اساس روز و روش پرداخت آماده کن و سه روزی را که بیشترین مبلغ فروش داشته‌اند نشان بده.»
برای پاسخ درست، سیستم باید بازهٔ زمانی را مشخص کند. «ماه گذشته» باید بر اساس تقویم و منطقهٔ زمانی تعریف‌شدهٔ حساب تفسیر شود. سپس داده‌های فروش و روش‌های پرداخت خوانده می‌شوند و گزارش بر اساس همان اسناد ثبت‌شده ساخته می‌شود.
مدل می‌تواند نتیجه را خلاصه کند، اما نباید عدد تازه‌ای تولید کند. اگر بخشی از فروش بدون روش پرداخت ثبت شده باشد، باید آن را جدا نشان دهد. اگر سندی ناقص یا برگشت‌خورده باشد، اثر آن باید مطابق قواعد گزارش مشخص شود. در چنین گزارشی، توضیح محدودیت داده‌ها به اندازهٔ خود عددها اهمیت دارد.
مدیر می‌تواند بعد از گزارش اولیه سؤال دیگری بپرسد: «همین گزارش را فقط برای مشتریان جدید جدا کن.» اگر ارتباط ابزارها درست طراحی شده باشد، مدل زمینهٔ گفت‌وگو را حفظ می‌کند و درخواست دوم را به گزارش قبلی مرتبط می‌سازد. با این حال، هر گزارش باید همچنان از دادهٔ واقعی و مجاز سامانه ساخته شود.
درخواست خوب چه شکلی دارد؟
درخواست مبهم، نتیجهٔ مبهم می‌سازد. برای کارهای اجرایی، این چهار مورد را تا جای ممکن مشخص کنید:
- موضوع کار، مانند فروش، مشتری، موجودی یا پرداخت
- بازهٔ زمانی یا نام دقیق سند
- خروجی مورد انتظار، مانند گزارش، پیش‌نویس یا ثبت نهایی
- شرط تأیید، مثل «قبل از ثبت جزئیات را نشان بده»
برای مثال، جملهٔ «وضعیت فروش را بررسی کن» کوتاه است، اما معلوم نیست کدام بازه، کدام شعبه یا کدام نوع فروش مدنظر است. جملهٔ «فروش ثبت‌شده از اول تا پانزدهم مهر را بر اساس کالا مرتب کن و موارد برگشتی را جدا نشان بده» مسیر روشن‌تری دارد.
اجرای عملیات با خواندن داده فرق دارد
گزارش‌گیری معمولا یک عملیات خواندنی است. سامانه داده را می‌خواند و نتیجه را نمایش می‌دهد. اما ساخت پیش‌فاکتور، ثبت پرداخت، تغییر موجودی یا ارسال پیام، دادهٔ کسب‌وکار را تغییر می‌دهد. این دو نوع عملیات نباید با یک سطح آزادی انجام شوند.
برای عملیات تغییردهنده، چند مرحلهٔ کنترل لازم است:
- مدل هدف عملیات را توضیح دهد.
- اطلاعاتی را که قرار است ثبت شود نشان دهد.
- موارد مبهم را مشخص کند.
- سطح دسترسی کاربر بررسی شود.
- ثبت نهایی فقط طبق سیاست تعریف‌شده انجام شود.
- نتیجهٔ عملیات و شناسهٔ سند به کاربر برگردد.
این روند کمک می‌کند کاربر بداند دقیقا چه چیزی در حال ثبت شدن است. اگر مدل به جای «ساخت پیش‌نویس» مستقیما سند نهایی بسازد، احتمال خطای انسانی حذف نشده است؛ فقط محل خطا از ورود دستی به تفسیر درخواست منتقل شده است.
به همین دلیل، طراحی درخواست و ابزار اهمیت زیادی دارد. یک ابزار بهتر است فقط همان کاری را انجام دهد که نام و توضیحش می‌گوید. ابزاری با عنوان مبهم مانند «مدیریت داده‌ها» کنترل کمی ایجاد می‌کند. ابزارهای جدا برای خواندن فروش، ساخت پیش‌فاکتور و ثبت پرداخت، امکان نظارت و محدود کردن دسترسی را بیشتر می‌کنند.
دسترسی و امنیت اطلاعات حساس چگونه کنترل می‌شود؟
اتصال مدل زبانی به اطلاعات کسب‌وکار بدون قانون دسترسی، خطرناک است. اطلاعات مشتریان، قیمت خرید، گزارش سود، حقوق کارکنان و اسناد مالی ارزش یکسانی ندارند و همهٔ کاربران نباید همهٔ آن‌ها را ببینند.
اولین اصل، کمترین دسترسی لازم است. اگر کاربر فقط گزارش فروش می‌خواهد، ابزار نباید به اطلاعات حقوق یا اسناد پرداخت دسترسی داشته باشد. اگر کارشناس فروش می‌تواند پیش‌فاکتور بسازد، این موضوع لزوما به او اجازهٔ تغییر قیمت پایه یا حذف سند نمی‌دهد.
اصل دوم، تفکیک خواندن و نوشتن است. ابزار گزارش‌گیری باید از ابزار ثبت سند جدا باشد. با این کار می‌توان برای گزارش دسترسی گسترده‌تر و برای ثبت مالی محدودیت بیشتری گذاشت.
اصل سوم، ثبت سابقهٔ عملیات است. باید مشخص باشد چه کسی، در چه زمانی، با چه درخواستی، چه داده‌ای خوانده یا چه سندی ساخته است. این سابقه برای بررسی خطا، اصلاح فرآیند و پاسخ‌گویی داخلی کاربرد دارد.
همچنین نباید رمز عبور، کد تأیید یا کلیدهای دسترسی را در گفت‌وگو وارد کرد. اطلاعات محرمانه باید از مسیرهای امن و تعریف‌شده مدیریت شوند. مدل زبانی هم نباید پاسخ را با داده‌هایی بیشتر از نیاز کاربر پر کند. برای مثال، در گزارش فروش یک مشتری، نمایش نشانی یا اطلاعات تماس او ضرورتی ندارد؛ مگر اینکه کاربر مجاز و درخواست مشخصی داشته باشد.
MCP به تنهایی همهٔ این موارد را حل نمی‌کند. این پروتکل ارتباط را منظم می‌کند، اما سیاست دسترسی، ثبت رویدادها، ناشناس‌سازی و تأیید عملیات باید در سامانه و محیط سازمان طراحی شود. اگر بخشی از این زنجیره ضعیف باشد، اتصال مدل به ابزارها هم امن نخواهد بود.
این ارتباط چه نقشی در سیستم‌عامل خودمختار کسب‌وکار دارد؟
در یک نرم‌افزار معمولی، کاربر بین صفحه‌ها حرکت می‌کند و هر عملیات را جدا انجام می‌دهد. در یک سیستم‌عامل خودمختار کسب‌وکار، کاربر بیشتر هدفش را بیان می‌کند و سامانه بخشی از مسیر رسیدن به آن هدف را اجرا می‌کند. البته این خودکار بودن باید در محدودهٔ قانون، داده و دسترسی تعریف‌شده باشد.
در مایان، این ایده می‌تواند بخش‌های مختلفی را به هم مرتبط کند. یک درخواست دربارهٔ سفارش، ممکن است به مشتری، کالا، موجودی، فروش و مالی مربوط باشد. مدل زبانی نقش هماهنگ‌کننده را دارد و از ابزارهای مجاز برای گرفتن اطلاعات یا شروع عملیات استفاده می‌کند. نتیجه، گفت‌وگویی می‌شود که به دادهٔ واقعی کسب‌وکار متصل است.
این رویکرد با مفهوم ABOS یا «سیستم‌عامل خودکار کسب‌وکار» ارتباط دارد. منظور از خودکار بودن، حذف کامل انسان نیست. تصمیم‌های حساس همچنان به بررسی مدیر نیاز دارند. هدف این است که جست‌وجوی اطلاعات، انتقال دستی عددها و تکرار کارهای ساده کمتر شود تا انسان روی تصمیمی تمرکز کند که به قضاوت نیاز دارد.
در تفاوت ERP سنتی با سیستم‌عامل کسب‌وکار (ABOS) این تفاوت از زاویهٔ دیگری بررسی شده است. در عمل، ارزش این مدل زمانی مشخص می‌شود که درخواست‌های متنی به جریان‌های واقعی داده و عملیات متصل باشند، نه اینکه فقط پاسخ‌هایی شبیه متن‌های آموزشی تولید کنند.
از فردا چگونه این قابلیت را درست آزمایش کنیم؟
برای شروع، سراغ حساس‌ترین عملیات نروید. یک کار خواندنی و محدود انتخاب کنید؛ مثلا گزارش فروش یک بازهٔ مشخص یا فهرست مشتریانی که در یک مدت پیگیری نشده‌اند. درخواست را با بازهٔ زمانی، نوع خروجی و شرایط لازم بنویسید. سپس نتیجه را با گزارش معمول سامانه مقایسه کنید.
در مرحلهٔ بعد، یک عملیات پیش‌نویسی را آزمایش کنید. ساخت پیش‌فاکتور نمونه مناسب‌تر از ثبت مستقیم پرداخت است، چون قبل از نهایی شدن می‌توان ردیف‌ها و مبلغ را بررسی کرد. مواردی را که مدل اشتباه فهمیده یادداشت کنید و برای نام‌گذاری مشتریان، کالاها و قوانین تأیید، دستور روشن‌تری بسازید.
در آخر، فهرستی از دسترسی‌ها تهیه کنید. مشخص کنید چه کسی فقط گزارش می‌بیند، چه کسی پیش‌نویس می‌سازد و چه کسی اجازهٔ ثبت نهایی دارد. این فهرست، پایهٔ استفادهٔ امن از ابزارهای متصل به مایان است. با همین مسیر محدود و قابل بررسی، می‌توان فهمید کدام کار واقعا ارزش خودکار شدن دارد و کدام تصمیم هنوز به بررسی انسانی نیاز دارد.