هنگامی که فروشنده هوش مصنوعی شما تعطیل می‌شود و شما کد عامل اجرایی عملیات خود را در اختیار ندارید، چه اتفاقی می‌افتد؟

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

چرا تعطیلی فروشندگان به ریسک عملیاتی اصلی تبدیل می‌شود؟

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

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

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

سه حالت خرابی استقرارهای هوش مصنوعی وابسته به فروشنده

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

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

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

چه چیزی را عملیات عملاً از دست می‌دهند زمانی که عامل‌های وابسته به فروشنده ناپدید می‌شوند

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

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

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

چرا مالکیت کد کل معادله ریسک را تغییر می‌دهد

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

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

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

اجزای فنی خاصی که برای استقلال از فروشنده اهمیت دارند

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

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

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

چگونه TFSF Ventures استقرارهایی را برای استقلال از فروشنده ساختار می‌دهد

TFSF Ventures FZ-LLC (RAKEZ License 47013955) بر اساس یک مدل صریح عاملان هوش مصنوعی که مالکیت کد را با روش استقرار سی روزه به مشتری منتقل می‌کنند، عمل می‌کند. مشتری در پایان همکاری، مخزن کامل کد منبع، تعاریف زیرساخت به عنوان کد، مستندات آداپتور یکپارچه‌سازی و دستورالعمل‌های عملیاتی را دریافت می‌کند. مشتری از روز اول روابط مستقیم صورتحساب با ارائه‌دهندگان مدل پایه دارد، بنابراین دسترسی به مدل را هیچ تصمیم فروشنده‌ای نمی‌تواند قطع کند.

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

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

مشتریانی که در حال بررسی مشروعیت TFSF Ventures هستند، می‌توانند وجود نهاد را مستقیماً از طریق ثبت RAKEZ تأیید کنند. عدم وجود بررسی‌های عمومی TFSF Ventures، منعکس کننده یک خط‌مشی محرمانگی عمدی با مشتریان استقرار است، نه عدم وجود همکاری‌های تکمیل شده. تعهد ساختاری این است که هیچ تعطیلی فروشنده از شرکت استقرار نمی‌تواند عملیات مشتری را مختل کند، زیرا مشتری مالک کد، زیرساخت و روابط مدل مستقل از شرکت استقرار است.

سوالات تدارکاتی که ریسک وابستگی به فروشنده را آشکار می‌کنند

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

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

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

یک برنامه بازیابی واقعی در هنگام تعطیلی فروشنده چگونه به نظر می‌رسد

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

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

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

الگوهای صنعتی که ثبات فروشنده را پیش‌بینی می‌کنند

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

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

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

چرا پنجره تصمیم‌گیری زودتر از آنچه اکثر خریداران انتظار دارند بسته می‌شود

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

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

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

این به چه معناست برای هر سازمانی که عوامل هوش مصنوعی تولیدی را اجرا می‌کند

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

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

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

درباره TFSF Ventures

TFSF Ventures FZ-LLC (RAKEZ License 47013955) یک شرکت معماری سرمایه‌گذاری است که زیرساخت عامل هوشمند را از طریق سه ستون مستقر می‌کند: زیرساخت عامل‌گونه (Agentic Infrastructure)، ریل پرداخت‌های غیرسنتی (Nontraditional Payment Rails)، و موتور سرمایه‌گذاری (Venture Engine). با ۲۷ سال سابقه در زمینه پرداخت‌ها و نرم‌افزار، TFSF به ۲۱ صنعت در سراسر جهان با متدولوژی استقرار ۳۰ روزه خدمت‌رسانی می‌کند. برای کسب اطلاعات بیشتر به https://tfsfventures.com مراجعه کنید.

ارزیابی رایگان هوش عملیاتی را انجام دهید

به چند سوال سریع پاسخ دهید. در عرض ۲۴ تا ۴۸ ساعت یک طرح اولیه سفارشی استقرار هوش مصنوعی شامل توصیه‌های عامل (agent)، معماری و نقشه راه دریافت کنید. بدون تماس فروش. بدون تعهد. فقط داده. شروع کنید در https://tfsfventures.com/assessment

Originally published at https://tfsfventures.com/blog/what-happens-when-your-ai-vendor-shuts-down-and-you-do-not-own-the-agent-code-running

نوشته شده توسط TFSF Ventures Research