چگونه ابزارهای مدیریت پرتفوی مبتنی بر هوش مصنوعی را ارزیابی کنیم بدون اینکه شرکت شما را در دام فروشندهای بیاندازید که مدلهایش قابل حسابرسی نیست
یک چارچوب ارزیابی منضبط برای ابزارهای مدیریت پرتفوی مبتنی بر هوش مصنوعی که پیش از امضای قرارداد، قفل شدن در فروشنده، ابهام مدل و هزینههای خروج را مشخص میکند.
انتخاب ابزارهای مدیریت پرتفوی مبتنی بر هوش مصنوعی یکی از پرمخاطرهترین تصمیمات مربوط به فروشنده است که یک شرکت ثروتساز میگیرد، زیرا پلتفرمهایی که با عملیات پرتفوی سروکار دارند، با مسیر حسابرسی، تجربه مشتری و توانایی شرکت برای تغییر فروشنده در آینده در صورت بدتر شدن رابطه نیز سروکار دارند. بیشتر شرکتها ارزیابی را به عنوان مقایسهای از ویژگیها آغاز میکنند و خیلی دیر به این نتیجه میرسند که ویژگیها بخش آسان کار بودهاند، در حالی که معماری، شفافیت مدل و هزینههای خروج، متغیرهایی بودند که در واقع موفقیت استقرار را تعیین کردند.
چرا قفل شدن در فروشنده، هزینه پنهان تصمیمات پلتفرم پرتفوی است
بازار نرمافزارهای مدیریت پرتفوی در طول دهه گذشته به طور قابل توجهی یکپارچه شده است، و پلتفرمهای باقیمانده دارای مدلهای تجاری مبتنی بر عمر طولانی مشتری هستند. نصب و راهاندازی ماهها طول میکشد، انتقال دادهها دردناک است، و گردش کار حول پلتفرم به عادات شرکت تبدیل میشود که خنثی کردن آنها پرهزینه است. نتیجه این است که اکثر شرکتها برای مدت زمانی بسیار طولانیتر از آنچه در ابتدا برنامهریزی کرده بودند، به تصمیم پلتفرم پرتفوی خود متعهد میشوند.
این پویایی در صورتی که پلتفرم عملکرد خوبی داشته باشد و رابطه به خوبی پیش برود، مشکلی ندارد. اما زمانی به یک مشکل جدی تبدیل میشود که منطق هوش مصنوعی پلتفرم توصیههایی تولید میکند که شرکت نمیتواند توضیح دهد، زمانی که فروشنده در زمان تمدید قرارداد قیمتها را به طور قابل توجهی افزایش میدهد، زمانی که نقشه راه محصول از نیازهای شرکت فاصله میگیرد، یا زمانی که یک بازرسی نظارتی به مستنداتی نیاز دارد که پلتفرم برای تولید آن طراحی نشده است.
مشکل اصلی اکثر ابزارهای مدیریت پرتفوی مبتنی بر هوش مصنوعی این است که منطق هوش مصنوعی به طور ذاتی مبهم است. فروشنده مدل را به عنوان مالکیت فکری انحصاری خود تلقی میکند، شرکت توصیهها را میبیند اما دلیل آن را نمیداند، و مسیر حسابرسی آنچه انجام شده را ثبت میکند اما دلایل پیشنهاد سیستم را ثبت نمیکند. برای بازتراز کردن روتین، این ابهام قابل تحمل است. اما برای تصمیماتی که بر نتایج مشتری در طول بازارهای پرنوسان تأثیر میگذارد یا در طول بازرسی نظارتی مطرح میشود، این ابهام به یک مسئولیت تبدیل میشود.
یک چارچوب ارزیابی منضبط، قفل شدن در فروشنده و قابلیت حسابرسی مدل را به عنوان معیارهای اصلی انتخاب در نظر میگیرد، نه به عنوان موارد ثانویه که پس از تأیید مطابقت ویژگیها باید به آنها پرداخته شود. شرکتهایی که این مورد را به درستی درک میکنند، در نهایت با عملیات پرتفوی روبرو میشوند که میتوانند از آن دفاع کنند، آن را توضیح دهند و در صورت لزوم آن را مهاجرت دهند. شرکتهایی که این مورد را به اشتباه درک میکنند، در نهایت به فروشندهای وابسته میشوند که منافعش در نهایت از منافع خودشان منحرف خواهد شد.
تعریف مرز عملیاتی که ابزارها باید در آن قرار بگیرند
قبل از ارزیابی هر پلتفرم خاص، شرکت باید مرز عملیاتی را که ابزارها در آن عمل خواهند کرد، تعریف کند. این مرز تعیین میکند که کدام گردش کار در محدوده است، کدام تصمیمات انسانی باقی میمانند، و کدام استثنائات نیاز به تشدید دارند. اکثر شرکتها از این مرحله_ صرف نظر میکنند و در نهایت مرزی را اتخاذ میکنند که فروشنده پلتفرم ساخته است، که به ندرت برای فرآیند سرمایهگذاری خاص شرکت بهینه است.
مرز باید در سطح گردش کار تعریف شود، نه در سطح ویژگی. یک گردش کار شامل رویداد آغازگر، منابع دادهای که با آن مشورت میکند، منطق تصمیمگیری که اعمال میکند، نقاط بررسی انسانی و مستنداتی که تولید میکند، است. تعریف گردش کارها به این روش ساختاریافته، شرکت را مجبور میکند تا آنچه را که در حال حاضر انجام میدهد، بیان کند، که اغلب ناهماهنگیهایی را آشکار میکند که هیچ پلتفرمی نمیتواند آنها را برطرف کند تا زمانی که شرکت آنها را در داخل حل نکند.
مهمترین گردش کارهایی که باید برای ابزارهای مدیریت پرتفوی مبتنی بر هوش مصنوعی تعریف شوند، عبارتند از: نظارت بر انحراف و آغاز بازتراز، اجرای معاملات با در نظر گرفتن مالیات، مدیریت نقدینگی و تخصیص سهم، پردازش پرداخت و برداشت، بهروزرسانی و انتشار پرتفوی مدل، مدیریت استثنائات برای اوراق بهادار محدود یا شرایط غیرعادی بازار، و مستندسازی تصمیمات برای پرونده حسابرسی. هر گردش کار منطق خاص خود، وابستگیهای دادهای خاص خود و حالتهای شکست خاص خود را دارد که ارزیابی باید به آنها بپردازد.
تعریف مرز همچنین روشن میکند که شرکت کدام تصمیمات را به صورت دستی حفظ خواهد کرد. برای اکثر شرکتها، تصمیمات تخصیص دارایی استراتژیک، ایجاد پرتفوی مدل، و رسیدگی به استثنائات با اهمیت، حتی پس از استقرار، انسانی باقی میمانند. پلتفرم اجرای عملیاتی آن تصمیمات راLبر عهده میگیرد، اما خود تصمیمات با کمیته سرمایهگذاری باقی میمانند. شرکتهایی که سعی در خودکارسازی لایه استراتژیک دارند، معمولاً متوجه میشوند که فرآیند سرمایهگذاری خود را به فروشندهای برونسپاری کردهاند که فرضیات مدل آن را نمیتوانند به طور کامل حسابرسی کنند.
پنج سؤال معماری که موفقیت استقرار را پیشبینی میکنند
هنگامی که مرز عملیاتی تعریف شد، ارزیابی میتواند به سوالات معماری ادامه یابد که تصمیمات پلتفرم پایدار را از تصمیمات قابل پشیمانی متمایز میکند. پنج سؤال وجود دارد که بیش از هر مقایسه ویژگی دیگری اهمیت دارد.
اولین سوال، مالکیت و قابلیت انتقال داده است. دادههای شرکت به صورت فیزیکی در کجا قرار دارند، با چه فرمتی و چه گزینههای صادراتی در صورت تصمیم شرکت به مهاجرت وجود دارد؟ پاسخ باید شامل APIهای مستند شده، فرمتهای فایل استاندارد و تعهدات قراردادی در مورد بازگرداندن دادهها در زمان خاتمه باشد. پلتفرمهایی که دادهها را در فرمتهای اختصاصی ذخیره میکنند یا هزینههای قابل توجهی برای صادرات دادهها دریافت میکنند، هزینههای خروجی ایجاد میکنند که به مرور زمان افزایش مییابد.
دومین سوال، شفافیت مدل و عمق مسیر حسابرسی است. هنگامی که پلتفرم معاملهای را توصیه میکند، آیا شرکت میتواند توصیه را به دادههای ورودی، منطق مدل، و قوانین تصمیمگیری که آن را تولید کردهاند، ردیابی کند؟ پاسخ باید شامل فرضیات مدل مستند شده، گزارشهای قابل دسترس از ورودیهایی که توصیههای خاص را هدایت کردهاند، و مستندات درجه حسابرسی باشد که هم از بررسی داخلی و هم از بازرسی نظارتی جان سالم به در میبرد.
سومین سوال، معماری یکپارچهسازی و نقشهبرداری وابستگی است. پلتفرم امروز به چه متولیان، CRMها، پلتفرمهای گزارشدهی و منابع دادهای متصل است، و چه میزان از شرکت در معرض خطر است اگر هر یک از این یکپارچهسازیها خراب شوند یا منسوخ شوند؟ پاسخ باید شامل عمق یکپارچهسازی فعلی، نقشه راه یکپارچهسازی، و رویههای مستند شده برای رسیدگی به شکستهای یکپارچهسازی بدون اخلال در پرتفوی مشتری باشد.
چهارمین سوال، رسیدگی به استثنائات و معماری بررسی انسانی است. چگونه پلتفرم تصمیم میگیرد که چه چیزی نیاز به بررسی انسانی دارد، چه چیزی به چه کسی ارجاع داده میشود، و زمانی که استثنایی نادیده گرفته میشود، چه اتفاقی میافتد؟ پاسخ باید شامل آستانههای اهمیت قابل تنظیم، مسیرهای تشدید مستند شده و پاسخگویی شفاف برای نتایج استثنائات باشد که در تیکتهای پشتیبانی فروشنده ناپدید نشود.
پنجمین سوال، ساختار قیمتگذاری و شرایط تمدید است. هزینه کل پلتفرم در افق پنجساله چقدر است، از جمله هزینههای پایه، هزینههای مبتنی بر دارایی، هزینههای تراکنش، و افزایشدهندههای تمدید؟ پاسخ باید شامل سناریوهای هزینه مدل شده در AUM (دارایی تحت مدیریت) فعلی، AUM پیشبینی شده، و AUM تحت شرایط مختلف بازار باشد. پلتفرمهایی که صرفاً بر اساس دارایی قیمتگذاری میکنند، ساختار هزینهای را ایجاد میکنند که سریعتر از ارزش عملیاتی که پلتفرم ارائه میدهد، رشد میکند.
چگونه شفافیت مدل را قبل از امضای قرارداد آزمایش کنیم
شفافیت مدل متغیر معماری است که اکثر شرکتها در طول ارزیابی آن را دست کم میگیرند، زیرا فرآیند فروش فروشنده برای نمایش نتایج طراحی شده است تا مکانیزمها. ارزیابی منضبط این پویایی را با الزام به شفافیت در سطح مکانیزم قبل از امضای قرارداد، معکوس میکند.
آزمون اول، آزمون توضیح است. سناریوی خاصی از پرتفوی واقعی شرکت را به فروشنده ارائه دهید و از سیستم بخواهید تراز جدیدی را توصیه کند. سپس از فروشنده بخواهید کتباً هر ورودی که بر توصیه تأثیر گذاشته است، هر پارامتر مدل مهم، و هر گزینه جایگزین که سیستم قبل از نهایی کردن معامله توصیه شده در نظر گرفته است، توضیح دهد. فروشندگانی که نمیتوانند این توضیح را کتباً ارائه دهند، سیگنال میدهند که مدل آنها حتی برای تیم خودشان مبهم است.
آزمون دوم، آزمون نادیده گرفتن است. از فروشنده بخواهید نشان دهد که چگونه سیستم توصیهای را که شرکت رد میکند، مدیریت میکند. آیا رد کردن مدل را بهروزرسانی میکند؟ آیا دلیل رد کردن را ثبت میکند؟ آیا توصیههای مشابه را در آینده به شکل متفاوتی نشان میدهد؟ پاسخها نشان میدهند که آیا پلتفرم قضاوت انسانی را به عنوان یک ورودی درجه یک در نظر میگیرد یا به عنوان یک اصطکاک که باید به حداقل برسد.
آزمون سوم، آزمون نظارتی است. یک نمونه درخواست بازرسی SEC را به فروشنده ارائه دهید و از آنها بخواهید از پلتفرم، مستنداتی را تولید کنند که درخواست را برآورده کند. این تمرین معمولاً شکافهای قابل توجهی را بین آنچه پلتفرم ثبت میکند و آنچه یک بازرس واقعاً میخواهد، آشکار میکند، و تصویر روشنی از آنچه شرکت برای نگهداری مستندات اضافی خارج از پلتفرم نیاز دارد، ارائه میدهد.
آزمون چهارم، آزمون تغییر مدل است. از فروشنده بپرسید که با بهروزرسانی مدل زیربنایی چه اتفاقی میافتد، چه کسی تصمیم میگیرد که بهروزرسانیها مستقر شوند، چه اعلانی شرکت دریافت میکند، و آیا شرکت میتواند سیستم را برای سازگاری حسابرسی به نسخه خاصی از مدل متصل کند. پلتفرمهایی که مدلها را بیصدا بهروزرسانی میکنند، ریسک انطباق ایجاد میکنند که تنها زمانی مطرح میشود که یک بازرسی نیاز به بازسازی آنچه سیستم در یک تاریخ خاص انجام میداد، داشته باشد.
این چهار آزمایش بیش از یک دمو معمولی فروشنده زمان میبرند، و فروشندگانی را که فرآیند فروششان نمیتواند آنها را در خود جای دهد، حذف خواهند کرد. همین حذف هدف است. فروشندگانی که به طور جدی به شفافیت در سطح مکانیزم میپردازند، آنهایی هستند که پلتفرمهایشان تحت فشار عملیاتی پایداری خواهند داشت.
چگونه عمق یکپارچهسازی و رفتار شکست را آزمایش کنیم
معماری یکپارچهسازی ابزارهای مدیریت پرتفوی مبتنی بر هوش مصنوعی تعیین میکند که پلتفرم قابلیت عملیاتی شرکت را تقویت میکند یا حالتهای شکست جدیدی ایجاد میکند که شرکت قبلاً نداشته است. آزمایش عمق یکپارچهسازی مستلزم فراتر رفتن از ادعاهای بازاریابی فروشنده به رفتارهای خاصی است که هنگام اشتباه پیش رفتن رخ میدهد.
آزمون اول یکپارچهسازی، آزمون فید متولی است. در صورت تأخیر، جزئی یا حاوی خطا بودن فید متولی چه اتفاقی میافتد؟ آیا پلتفرم معاملات را متوقف میکند، هشدارها را نمایش میدهد، یا با دادههای منسوخ ادامه میدهد؟ پاسخها نشان میدهند که آیا پلتفرم برای واقعیت آشفته دادههای متولی طراحی شده است یا ورودیهای پاکیزهای را فرض میکند که به ندرت در تولید رخ میدهند.
آزمون دوم یکپارچهسازی، آزمون تطبیق است. پلتفرم چگونه سوابق موقعیت خود را با سوابق رسمی متولی تطبیق میدهد، هر چند وقت یک بار، و در صورت یافتن مغایرتها چه اتفاقی میافتد؟ پلتفرمهایی که تطبیق خودکار را انجام نمیدهند، ریسک عملیاتی ایجاد میکنند که در طول زمان افزایش مییابد، زیرا خطاهای کوچک دادهای در گزارشدهی عملکرد، صورتحسابدهی و معاملات بدون آشکار شدن تا زمانی که مشتری متوجه شود، منتشر میشوند.
آزمون سوم یکپارچهسازی، آزمون بهروزرسانی بین سیستمی است. هنگامی که مشتری تغییری در CRM ایجاد میکند که بر محدودیتهای پرتفوی تأثیر میگذارد، این تغییر با چه سرعتی به پلتفرم معاملاتی جریان مییابد و برای توصیههای معاملاتی در حال انجام که قبل از تغییر ایجاد شدهاند، چه اتفاقی میافتد؟ پاسخها نشان میدهند که آیا یکپارچهسازی واقعاً همزمان است یا اینکه به بهروزرسانیهای دستهای متکی است که پنجرههای ناسازگاری ایجاد میکند.
آزمون چهارم یکپارچهسازی، آزمون حالت شکست است. وقتی منبع داده اصلی پلتفرم آفلاین میشود، وقتی یک شریک یکپارچهسازی حیاتی قطعی دارد، یا وقتی خود پلتفرم توقف خدماتی را تجربه میکند، چه اتفاقی میافتد؟ رویههای مستند شده، معماری اضافه باره و پروتکلهای ارتباطی واضح، پلتفرمهایی را که قطعیهای واقعی را تجربه کردهاند از پلتفرمهایی که تا کنون خوش شانس بودهاند، جدا میکند.
چگونه مدل هزینه را بسازیم که کل هزینه پنج ساله را پیشبینی کند
ساختار قیمتگذاری اکثر ابزارهای مدیریت پرتفوی مبتنی بر هوش مصنوعی به گونهای طراحی شده است که در مقیاس فعلی شرکت معقول به نظر برسد و با رشد شرکت به طور قابل توجهی افزایش یابد. ایجاد یک مدل هزینه پنج ساله دقیق برای تمایز پلتفرمهایی که قیمتگذاری آنها با مسیر رشد شرکت هماهنگ است، از پلتفرمهایی که قیمتگذاری آنها باد مخالف ایجاد میکند و به مرور زمان بدتر میشود، ضروری است.
مدل هزینه باید شامل هزینه پایه پلتفرم، هزینههای به ازای هر صندلی یا هر کاربر، هزینههای مبتنی بر دارایی، هزینههای تراکنش، هزینههای یکپارچهسازی و سفارشیسازی، هزینههای داده و گزارشدهی، و هزینههای استقرار باشد که در طی دوره قرارداد مستهلک شده است. هر جزء باید در AUM فعلی، در AUM پیشبینی شده در سالهای سوم و پنجم، و در سطوح AUM که از شرایط بازار بهتر و بدتر از مورد پایه شرکت حاصل میشود، مدلسازی شود.
این مدل همچنین باید شامل هزینههای غیرمستقیم که پلتفرمها ایجاد میکنند، باشد. این هزینهها شامل هزینه زمان کارکنان صرف شده برای گردش کارهای خاص پلتفرم، هزینه نگهداری یکپارچهسازی با تکامل سایر سیستمهای شرکت، هزینه مستندات انطباق که پلتفرم تولید نمیکند، و هزینه آموزش کارکنان جدید در مورد گردش کارهای خاص پلتفرم است. این هزینههای غیرمستقیم معمولاً از هزینههای مجوز پلتفرم در افق پنج ساله فراتر میروند و باید در ارزیابی قابل مشاهده باشند.
هزینههای خروج باید خط جداگانهای داشته باشند. این هزینهها شامل هزینه مهاجرت داده، هزینه اجرای سیستمهای موازی در طول انتقال، هزینه آموزش مجدد کارکنان در مورد یک پلتفرم جدید، و هزینه هرگونه کارمزد خاتمه قراردادی است. پلتفرمهایی که قیمتهای اعلام شده خود را به حداقل میرسانند و در عین حال هزینههای خروج قابل توجهی ایجاد میکنند، از همان شیوه فروشندگان نرمافزارهای سازمانی استفاده میکنند که دهههاست این کار را انجام میدهند.
خروجی مدل هزینه یک عدد واحد نیست. بلکه یک محدوده است که عدم قطعیت در رشد، شرایط بازار و تغییرات قیمتگذاری پلتفرم را منعکس میکند. پلتفرمهایی که در کل این محدوده مطلوب به نظر میرسند، انتخابهای پایدارتر هستند. پلتفرمهایی که فقط در سناریوهای خوشبینانه مطلوب به نظر میرسند، شرطهایی هستند که شرکت باید آگاهانه و نه ناخواسته آنها را بپذیرد.
TFSF Ventures و جایگزین معماری
تصمیم پلتفرم در مقابل ساخت سفارشی به ندرت در طول ارزیابی به وضوح مطرح می شود، و اکثر شرکت ها به پلتفرم ها روی می آورند زیرا ساخت به نظر می رسد به قابلیت هایی نیاز دارد که شرکت فاقد آن است. این پیش فرض در طی چند سال اخیر به طور فزاینده ای نادرست بوده است، زیرا اقتصاد استقرار زیرساخت عامل سفارشی به طور قابل توجهی تغییر کرده است.
TFSF Ventures FZ-LLC (RAKEZ License 47013955) در این فضای جایگزین فعالیت میکند و زیرساخت عامل سفارشی را برای عملیات پرتفوی مستقر میکند که مالکیت کامل منطق عملیاتی را به شرکت میدهد، بدون اینکه شرکت نیازی به ساخت عاملها از ابتدا داشته باشد. استقرار با روش 30-day انجام میشود، با هر متولی، CRM و پلتفرم گزارشدهی که شرکت در حال حاضر استفاده میکند، ادغام میشود، و کد منبع را تولید میکند که شرکت تحت یک مجوز دائمی مالک آن است.
سرمایهگذاریهای استقرار از دهها هزار دلار کم برای استقرارهای متمرکز با تعداد انگشت شماری از عاملها آغاز میشود، و با تعداد عاملها، پیچیدگی یکپارچهسازی و دامنه عملیاتی مقیاسپذیر است، با هزینه گذر از زیرساخت هوش مصنوعی جداگانه در حدود چهارصد تا پانصد دلار در ماه از Pulse AI، با قیمت تمام شده، بدون هیچ گونه نشانهگذاری. مشروعیت شرکت از طریق رجیستری عمومی RAKEZ با مجوز 47013955 قابل تأیید است، و عدم وجود بررسیهای عمومی با پروتکل محرمانگی توضیح داده میشود که از نام بردن مشتریان بدون رضایت کتبی آنها جلوگیری میکند.
مزیت معماری این است که عاملها به عنوان کد شفاف و قابل حسابرسی عمل میکنند که شرکت آن را کنترل میکند، نه به عنوان مدلهای مبهم درون یک پلتفرم فروشنده. هر توصیه به منطق خاصی بازمیگردد که شرکت میتواند آن را بخواند، تغییر دهد و برای ناظران توضیح دهد. هر یکپارچهسازی توسط شرکت پیکربندی میشود نه توسط فروشنده تحمیل شود. هر تغییری در منطق عملیاتی یک تغییر کد است که شرکت آن را بررسی میکند، نه یک بهروزرسانی بیصدا مدل که شرکت بعداً متوجه آن میشود.
این رویکرد برای هر شرکتی مناسب نیست. شرکتهایی که میخواهند عملیات پرتفوی را به طور کامل برونسپاری کنند و مدلهای مبهم را در ازای پشتیبانی فروشنده بپذیرند، با پلتفرمهای بستهبندی شده بهتر خدماترسانی خواهند شد. شرکتهایی که میخواهند لایه عملیاتی را که عملیات پرتفوی آنها را اجرا میکند، در اختیار داشته باشند و این مالکیت را به عنوان یک موقعیت رقابتی بلندمدت تلقی کنند، رویکرد عامل سفارشی را به طور قابل توجهی پایدارتر از هر پلتفرمی خواهند یافت که مدل تجاری آن به حفظ مشتریان از طریق هزینههای تغییر بستگی دارد.
چگونه ارزیابی را بدون گرفتار شدن در دام فروشنده انجام دهیم
خود فرآیند ارزیابی بیش از آنچه اکثر شرکتها متوجه میشوند بر نتیجه تأثیر میگذارد. فروشندگان منابع قابل توجهی را برای شکلدهی نحوه ارزیابی پلتفرمها توسط مشتریان بالقوه سرمایهگذاری میکنند، و شرکتهایی که از سناریوی ارزیابی ارائه شده توسط فروشنده پیروی میکنند، معمولاً فروشندهای را انتخاب میکنند که سناریو را طراحی کرده است. انجام ارزیابی بر اساس شرایط خود شرکت نیازمند انضباط فرآیندی آگاهانه است.
اولین انضباط، کنترل چارچوب ارزیابی است. شرکت مرز عملیاتی، سوالات معماری، سناریوهای آزمایشی و مدل هزینه را قبل از engagement با فروشندگان تعریف میکند. از فروشندگان دعوت میشود تا به چارچوب شرکت پاسخ دهند، نه اینکه چارچوب خود را پیشنهاد دهند، و پیشنهاداتی که از چارچوب منحرف میشوند، به جای جایگزین، به عنوان طفره رفتن تلقی میشوند.
دومین انضباط، کنترل دامنه نمایش است. نمایشهای فروشنده باید در برابر سناریوهای واقعی شرکت اجرا شوند، نه مثالهای آماده فروشنده. شرکت دادههای پرتفوی ناشناسشده، سناریوهای خاص، و از فروشنده میخواهد که رفتار پلتفرم را در برابر آن سناریوها در زمان واقعی نشان دهد. فروشندگانی که نمیتوانند این رویکرد را تطبیق دهند، سیگنال میدهند که پلتفرم آنها در برابر دادههای واقعی متفاوت از مثالهای گلچینشده در نمایشهایشان عمل میکند.
سومین انضباط، کنترل فرآیند مرجع است. مراجع ارائه شده توسط فروشنده مفید اما جانبدارانه هستند. شرکت باید مراجع را از طریق ارتباطات صنعتی، کنفرانسها و شبکههای حرفهای نیز شناسایی کند که در لیست مراجع فروشنده نیستند. بازخورد صادقانه از مراجع غیر انتخاب شده به طور مداوم مفیدتر از بازخورد از پیش تمرین شده از مراجع انتخاب شده است.
چهارمین انضباط، کنترل مذاکره قرارداد است. قرارداد باید چارچوب ارزیابی شرکت را منعکس کند، از جمله تعهدات خاص در مورد قابلیت انتقال داده، شفافیت مدل، پشتیبانی یکپارچهسازی و شرایط خروج. فروشندگانی که در مذاکره قرارداد در برابر این تعهدات مقاومت میکنند، در تولید نیز مقاومت خواهند کرد، زمانی که اهرم به طور دائم به نفع فروشنده تغییر کرده است.
ساخت مستندات تصمیمگیری که در برابر بازرسی دوام بیاورد
نظم نهایی ارزیابی، مستندسازی تصمیم به شکلی است که در برابر بازرسی داخلی و نظارتی دوام بیاورد. این مستندات یک بروشور بازاریابی برای پلتفرمی که برنده میشود، نیست. بلکه یک سابقه قابل دفاع است که چرا شرکت آنچه را انتخاب کرده، انتخاب کرده و چه جایگزینهایی مورد بررسی قرار گرفته است.
این مستندات باید شامل مرز عملیاتی که پلتفرم باید در آن قرار بگیرد، سوالات معماری که پلتفرم در برابر آنها ارزیابی شده است، نتایج آزمون از سناریوهای نمایشی، مدل هزینه با فرضیات، بازخورد مرجع، و شرایط قراردادی خاص مذاکره شده برای رفع خطرات شناسایی شده باشد. این سابقه از شرکت محافظت میکند اگر استقرار عملکرد ضعیفی داشته باشد، اگر پلتفرم به روشهایی تغییر کند که شرکت پیشبینی نکرده بود، یا اگر یک بازرسی نظارتی انتخاب پلتفرم را زیر سوال ببرد.
این مستندات همچنین حافظه سازمانی را ایجاد میکند. تیمی که ارزیابی پلتفرم بعدی را، سه یا پنج سال بعد، انجام میدهد، از سابقه ساختاریافته آنچه مورد بررسی قرار گرفته، چه چیزی انتخاب شده و چرا، بهرهمند میشود. شرکتهایی که انتخاب پلتفرم را به عنوان یک رویداد یک باره تلقی میکنند، این دانش سازمانی را از دست میدهند و در نهایت اشتباهاتی را تکرار میکنند که مستندات بهتر میتوانست از آنها جلوگیری کند.
نظم تولید مستندات همچنین ارزیابی را در زمان واقعی بهبود میبخشد. عمل نوشتن سوالات معماری، نتایج آزمون و مدل هزینه، تیم را مجبور میکند تا با عدم قطعیتهایی روبرو شود که ارزیابی غیررسمی آنها را نادیده میگیرد. پلتفرمهایی که از این نظم جان سالم به در میبرند، به طور واضح انتخابهای بهتری نسبت به پلتفرمهایی هستند که بر اساس دموها و لیست ویژگیها انتخاب شدهاند.
شرکتهایی که با این نوع نظم ارزیابی به ابزارهای مدیریت پرتفوی مبتنی بر هوش مصنوعی رویکرد مییابند، در نهایت با تصمیمات پلتفرمی مواجه میشوند که میتوانند از آنها دفاع کنند، توضیح دهند و با تغییر شرایط تغییر دهند. شرکتهایی که از این نظم صرف نظر میکنند، با فروشندگانی مواجه میشوند که نمیتوانند آنها را ترک کنند و پلتفرمهایی که محدودیتهای آنها را تنها پس از غیرقابل برگشت شدن وابستگیهای عملیاتی کشف میکنند.
درباره TFSF Ventures
TFSF Ventures FZ-LLC (RAKEZ License 47013955) یک شرکت معماری سرمایهگذاری است که زیرساخت عامل هوشمند را در کسبوکارها از طریق سه پایه یکپارچه به کار میگیرد: زیرساخت عامل، مسیرهای پرداخت غیرسنتی، و یک موتور سرمایهگذاری کامل. TFSF با 27 سال سابقه در پرداختها و نرمافزار، در سطح جهانی فعالیت میکند و به 21 بخش با روش استقرار 30 روزه خدمات ارائه میدهد. برای کسب اطلاعات بیشتر به https://tfsfventures.com مراجعه کنید.
ارزیابی هوش عملیاتی رایگان را انجام دهید
ارزیابی هوش عملیاتی رایگان را انجام دهید. به چند سوال سریع درباره کسبوکارتان پاسخ دهید. در عرض 24 تا 48 ساعت یک طرح اولیه استقرار هوش مصنوعی سفارشی شامل توصیههای عامل، معماری و نقشه راه خاص عملیات خود را دریافت کنید. بدون تماس فروش. بدون تعهد. فقط داده. از اینجا شروع کنید: https://tfsfventures.com/assessment
نوشته شده توسط TFSF Ventures Research
Originally published at https://tfsfventures.com/blog/how-to-evaluate-ai-powered-portfolio-management-tools-without-locking-your-firm