چگونه بهترین عوامل هوش مصنوعی را برای سازمانهای غیرانتفاعی انتخاب کنیم وقتی ماموریت شما شامل خدمات مستقیم، حمایت و اعطای کمک مالی میشود
روشی برای انتخاب بهترین عوامل هوش مصنوعی برای سازمانهای غیرانتفاعی با ماموریت ترکیبی: خدمات مستقیم، حمایت، و اعطای کمک مالی.
انتخاب بهترین عوامل هوش مصنوعی برای سازمانهای غیرانتفاعی زمانی به طور قابل توجهی دشوارتر میشود که سازمان مورد نظر با یک نمونه عملیاتی واحد مطابقت نداشته باشد. یک ارائهدهنده خدمات مستقیم نقاط فشار عملیاتی خود را میشناسد. یک بنیاد اعطای کمک مالی چرخههای بررسی پیشنهادات و گزارشدهی پورتفولیوی خود را میشناسد. یک سازمان حمایتی الگوهای بسیجJ ذینفعان و تحقیقات سیاستی خود را میشناسد. پیچیدگیها برای سازمانهایی پیش میآید که ماموریت آنها به طور همزمان شامل بیش از یکی از این حالتها میشود، جایی که ممکن است همان اعضای تیم صبح در حال اجرای یک برنامه خدماتی، بعد از ظهر در حال تدوین یک اظهارنظر سیاستی، و عصر در حال بررسی کمکهای مالی فرعی شرکا باشند.
این مقاله روششناسی به بررسی نحوه ارزیابی گزینههای عامل هوش مصنوعی برای سازمانهایی میپردازد که کارشان شامل خدمات مستقیم، حمایت و اعطای کمک مالی است، و در آن معماری عملیاتی باید هر سه حالت را بدون اجبار آنها به یک جریان کاری واحد در خود جای دهد. چارچوب بر اساس شش گام تحلیلی ساخته شده است که به جای انتخاب فروشنده، یک برنامه استقراری قابل دفاع تولید میکند، زیرا مهمترین تصمیمات در استقرار هوش مصنوعی در سازمانهای غیرانتفاعی عملیاتی هستند نه فناورانه.
گام اول: حالتهای عملیاتی را که سازمان شما واقعاً اجرا میکند، ترسیم کنید
بسیاری از سازمانهای غیرانتفاعی چندوجهی، تفاوتهای بین حالتهای عملیاتی خود را دست کم میگیرند. کار خدمات مستقیم شامل مدیریت پرونده با حضور مشارکتکنندگان، مستندسازی ارائه خدمات، و اندازهگیری نتایج در برابر مدلهای برنامه است. کار حمایتی شامل سنتز تحقیقات سیاستی، بسیج ذینفعان، هماهنگی ائتلاف، و ارتباطات خارجی تنظیمشده با لحظات سیاسی است. کار اعطای کمک مالی شامل بررسی پیشنهادات، بررسی دقیق، مدیریت روابط با دریافتکنندگان کمک مالی، و گزارشدهی پورتفولیو است.
اشتباهی که سازمانها در این مرحله مرتکب میشوند این است که این موارد را به عنوان تغییراتی از یک کار واحد در نظر میگیرند زیرا همه آنها توسط یک تیم انجام میشوند. اینطور نیست. جریانهای داده متفاوت هستند، معیارهای موفقیت متفاوت هستند، زمانهای چرخه متفاوت هستند، و حالتهای خرابی متفاوت هستند. یک عامل هوش مصنوعی که برای مستندسازی ارائه خدمات طراحی شده است، تحقیقات سیاستی را به خوبی انجام نخواهد داد، و یک عامل تحقیقات سیاستی خلاصههای بررسی دقیق دریافتکنندگان کمک مالی را به طور شایسته تولید نخواهد کرد.
تمرین ترسیم باید حداقل یک فهرست واضح از اینکه کدام نقشهای تیمی کدام حالتهای عملیاتی را لمس میکنند، انواع کارهای غالب در هر حالت چیست، و کجا انتقالهای عملیاتی بین حالتها رخ میدهد، تولید کند. انتقالها به ویژه مهم هستند زیرا در آنها دانش سازمانی به شکل ضمنی زندگی میکند و نه به شکل مستند.
سازمانهایی که این مرحله ترسیم را نادیده میگیرند، معمولاً عواملی را مستقر میکنند که برای یک حالت عملیاتی به خوبی کار میکنند و در بقیه اصطکاک ایجاد میکنند. عوامل مشکل نیستند. دامنه استقرار از ابتدا اشتباه بود.
خروجی این مرحله باید یک نقشه عملیاتی یک صفحهای باشد که بتوان آن را بین رهبری به اشتراک گذاشت و برای ارزیابی هر پیشنهاد فروشنده در برابر کار واقعی سازمان استفاده کرد. اگر یک پیشنهاد نتواند بیان کند که کدام یک از حالتهای عملیاتی را پشتیبانی میکند و کدام را پشتیبانی نمیکند، پیشنهاد به اندازه کافی خاص نیست که بتوان بر اساس آن عمل کرد.
گام دوم: کارهای با اهرم بالا را در هر حالت شناسایی کنید
پس از ترسیم حالتهای عملیاتی، گام بعدی شناسایی کارهایی در هر حالت است که برای استقرار عامل هوش مصنوعی اهرم بالایی دارند. اهرم بالا به این معنی است که کار حجم بالا، به اندازه کافی ساختاریافته برای xử lý الگوریتمی، و به اندازه کافی محدود است که معیارهای موفقیت واضح باشند. اهرم پایین به این معنی است که کار به شدت به قضاوت نیاز دارد، حجم کم دارد، یا به قدری به زمینه وابسته است که خودکارسازی بیش از منفعت، ریسک ایجاد میکند.
در حالت خدمات مستقیم، کارهای با اهرم بالا معمولاً شامل پردازش فرمهای پذیرش، ساختاردهی یادداشتهای پرونده، مستندسازی ارائه خدمات، و ردیابی شاخصهای نتایج است. کار با اهرم پایینتر شامل برنامهریزی پیچیده پرونده، مداخله در بحران، و ابعاد رابطهای خدمات است که به قضاوت تیم بستگی دارد.
در حالت حمایتی، کارهای با اهرم بالا شامل خلاصهسازی اسناد سیاستی، پیشنویس ارتباطات ذینفعان، آمادهسازی جلسه ائتلاف، و نظارت بر رسانهها است. کار با اهرم پایینتر شامل موقعیتیابی استراتژیک، مذاکرات حساس با متحدان و مخالفان، و لحظاتی است که یک سازمان تصمیم میگیرد موضع عمومی در مورد یک مسئله مورد مناقشه اتخاذ کند.
در حالت اعطای کمک مالی، کارهای با اهرم بالا شامل بررسی اولیه و طبقهبندی پیشنهادات، جمعآوری مستندات بررسی دقیق، تجمیع دادههای پورتفولیو، و سنتز گزارشهای دریافتکنندگان کمک مالی است. کار با اهرم پایینتر شامل قضاوت افسر برنامه در مورد اینکه کدام پیشنهادات را تامین مالی کند، چقدر تامین مالی کند، و چه شرایطی را اعمال کند.
خروجی این مرحله باید یک لیست اولویتبندی شده از فرصتهای استقرار عامل، رتبهبندی شده بر اساس اهرم و نه بر اساس اشتیاق باشد. استقرار هوش مصنوعی مبتنی بر اشتیاق یکی از رایجترین الگوها در عملیات سازمانهای غیرانتفاعی است و به طور مداوم ارزش کمتری نسبت به تحلیل اهرمی منضبط تولید میکند.
گام سوم: زیربنای دادهای هر حالت عملیاتی را بررسی کنید
عوامل هوش مصنوعی تنها به اندازه دادههایی که میتوانند به آنها دسترسی پیدا کنند خوب هستند، و بررسی داده جایی است که بسیاری از استقرار هوش مصنوعی در سازمانهای غیرانتفاعی قبل از شروع از بین میروند. هر حالت عملیاتی معمولاً سیستمهای دادهای خاص خود، مشکلات کیفیت داده خاص خود، و سابقه سازمانی خاص خود از تلاشهای بهبود را دارد که به نتیجه نرسیدهاند.
برای کار خدمات مستقیم، بررسی باید سیستم مدیریت پرونده، سوابق ارائه خدمات، ابزارهای اندازهگیری نتایج، و دادههای جمعیتی مشارکتکنندگان را پوشش دهد. سوالاتی که باید پرسیده شود شامل این است که آیا سوابق به طور مداوم وارد میشوند، آیا طبقهبندی در طول سالها ثابت است، آیا شناسههای مشارکتکنندگان قابل اعتماد هستند، و آیا ساختار داده از نوع پرس و جوهایی که یک عامل باید انجام دهد پشتیبانی میکند.
برای کار حمایتی، بررسی باید پایگاههای داده ذینفعان، سابقه ارتباطات، کتابخانههای تحقیقات سیاستی، و سیستمهای ردیابی ائتلاف را پوشش دهد. مشکلات کیفیت داده در حالت حمایتی اغلب شامل تکرار در سیستمها، سوابق ذینفعان ناسازگار، و تحقیقات سیاستی است که در اسناد بدون ساختار وجود دارد و نه در پایگاههای داده قابل جستجو.
برای کار اعطای کمک مالی، بررسی باید سیستم مدیریت کمکهای مالی، سوابق پیشنهادات، مستندات بررسی دقیق، و بایگانی گزارشهای دریافتکنندگان کمک مالی را پوشش دهد. مشکلات کیفیت داده در اینجا اغلب شامل فرادادههای ناسازگار در چرخههای کمک مالی، اسناد پیوستشدهای که قابل جستجو نیستند، و چارچوبهای گزارشدهی است که در طول زمان بدون بازنگری تغییر کردهاند.
خروجی این مرحله باید یک ارزیابی صادقانه از زیربنای داده برای هر حالت عملیاتی باشد، با اذعان صریح به اینکه کدام داده به اندازه کافی قابل اعتماد است که از عملیات عامل پشتیبانی کند و کدام داده قبل از استفاده توسط عوامل نیاز به اصلاح دارد. سازمانهایی که این مرحله را نادیده میگیرند یا آن را سطحی میگیرند، متوجه خواهند شد که عوامل آنها خروجیهای به طور مطمئن اشتباهی تولید میکنند که به سرعت اعتماد تیم را از بین میبرند.
گام چهارم: معماری مدیریت استثنا را قبل از انتخاب پلتفرم طراحی کنید
معماری مدیریت استثنا بخشی از استقرار عامل است که تعیین میکند آیا عوامل سازمان را امنتر میکنند یا شکنندهتر. استثنا هر موردی است که عامل با ابهام، محتوای حساس، موارد مرزی سیاستی، یا موقعیتهایی فراتر از الگوهای آموزشیافته خود مواجه میشود. نحوه مدیریت استثنائات تعیین میکند که آیا عوامل قضاوت تیم را گسترش میدهند یا جایگزین آن میشوند.
برای کار خدمات مستقیم، استثنائات شامل موقعیتهای مربوط به ایمنی مشارکتکنندگان، وظایف گزارشدهی اجباری، تعیین صلاحیتهای پیچیده، و هر لحظهای که ارتباط خودکار میتواند در زمینهای که نیاز به مراقبت دارد، معاملاتی و بیروح به نظر برسد. این استثنائات باید با تمام زمینه به تیم ارجاع داده شوند، نه به عنوان موارد پرچمگذاری شدهای که تیم باید از ابتدا بررسی کند.
برای کار حمایتی، استثنائات شامل هر موقعیتی است که یک پیشنویس عامل میتواند ریسک سیاسی ایجاد کند، هر ارتباطی که به مقامات منتخب یا تامینکنندگان مالی عمده میرود، و هر لحظهای که موقعیت عمومی سازمان درگیر است. معماری استثنا برای کار حمایتی به ویژه حساس است زیرا هزینه یک اقدام نادرست عامل میتواند به جای اینکه بعداً جبران شود، با آسیب به روابط اندازهگیری شود.
برای کار اعطای کمک مالی، استثنائات شامل هر موقعیتی است که شامل تضاد منافع، اطلاعات حساس دریافتکنندگان کمک مالی، روابط هیئت مدیره، و پیشنهاداتی است که به حوزههای سیاستی مورد مناقشه مربوط میشوند. مدیریت استثنا برای اعطای کمک مالی همچنین جایی است که کیفیت بررسی دقیق زندگی میکند، زیرا هدف گسترش ظرفیت افسر برنامه است و نه جایگزینی قضاوت افسر برنامه.
معماری باید قبل از انتخاب هر پلتفرمی طراحی شود، زیرا پلتفرمهای مختلف استثنائات را بسیار متفاوت مدیریت میکنند. برخی استثنائات را موارد مرزی میدانند که باید به حداقل رسانده شوند. برخی دیگر مدیریت استثنا را چالش اصلی طراحی میدانند. سازمانهایی که نیاز به دومی دارند و اولی را انتخاب میکنند، عدم تطابق را تنها پس از استقرار، زمانی که هزینه تغییر بالاترین است، کشف خواهند کرد.
گام پنجم: پلتفرمها را در برابر نقشه عملیاتی خاص خود ارزیابی کنید
با ترسیم حالتهای عملیاتی، شناسایی اهرم، بررسی داده، و طراحی معماری استثنا، ارزیابی پلتفرم بسیار محدودتر و مفیدتر میشود. بیشتر دموهای پلتفرم سعی میکنند آنچه ممکن است را نشان دهند. سوال ارزیابی این است که چه چیزی مناسب است.
سوالاتی که باید از هر پلتفرم پرسید شامل این است که چگونه حالتهای عملیاتی خاصی را که سازمان اجرا میکند، چگونه زیربنای دادهای را که سازمان واقعاً دارد و نه زیربنای دادهای که باید داشته باشد، چگونه موارد استثنائی را که سازمان شناسایی کرده است، و چگونه استقرار را در ساختار تیمی که سازمان واقعاً عمل میکند، مدیریت میکند.
برخی پلتفرمها برای سازمانهایی طراحی شدهاند که عملیات آنها عمدتاً استاندارد شده است. آنها زمانی خوب کار میکنند که سازمان با جریان کاری فرض شده پلتفرم مطابقت داشته باشد و زمانی که اینطور نیست، اصطکاک ایجاد میکنند. پلتفرمهای دیگر برای سازمانهایی طراحی شدهاند که عملیات آنها نیاز به سفارشیسازی قابل توجهی دارد. آنها زمانی خوب کار میکنند که سازمان ظرفیت لازم برای مدیریت آن سفارشیسازی را داشته باشد و زمانی که اینطور نیست، هزینههای اضافی ایجاد میکنند.
شرکای استقرار به اندازه خود پلتفرم اهمیت دارند، به ویژه برای سازمانهایی که عملیات آنها چندین حالت را در بر میگیرد. کار پیادهسازی جایی است که پلتفرم با واقعیت عملیاتی برخورد میکند، و کیفیت آن پیادهسازی اغلب تعیین میکند که استقرار موفق میشود یا شکست میخورد. یک پلتفرم قوی با پیادهسازی ضعیف همان نتیجه یک پلتفرم ضعیف با پیادهسازی قوی را دارد، که یک استقرار است که ارزشی را که قرار بود ارائه دهد، ارائه نمیدهد.
خروجی این مرحله باید یک لیست کوتاه از دو یا سه گزینه پلتفرم باشد، که هر کدام در برابر الزامات عملیاتی خاص و نه در برابر چک لیستهای ویژگیهای عمومی امتیازدهی شدهاند. سازمانهایی که در این مرحله نظم را حفظ میکنند، معمولاً به تصمیم استقرار درستی میرسند. سازمانهایی که به سمت اشتیاق فروشنده میروند، معمولاً تصمیماتی میگیرند که در دوازده ماه پشیمان میشوند.
گام ششم: توالی استقرار را در بین حالتهای عملیاتی برنامهریزی کنید
سازمانهای چندوجهی به ندرت از استقرار عوامل هوش مصنوعی در تمام حالتهای عملیاتی به طور همزمان بهره میبرند. ظرفیت جذب تغییرات عملیاتی معمولاً محدود است، و تلاش برای تغییر ارائه خدمات، عملیات حمایتی، و عملیات اعطای کمک مالی به طور همزمان تمایل دارد تیم را تحت فشار قرار دهد و فشار عقبنشینی ایجاد کند که هر سه را به خطر میاندازد.
توالی استقرار معمولاً باید با حالتی از عملیات شروع شود که زیربنای دادهای آن قویتر است، موارد استثنائی آن محدودتر هستند، و معیارهای موفقیت آن قابل اندازهگیریتر هستند. برای بسیاری از سازمانها، این کار گزارشدهی و مستندسازی در حالت خدمات مستقیم است، زیرا دادهها ساختاریافته هستند و حلقههای بازخورد تامینکننده مالی واضح هستند.
استقرار بعدی میتواند به حالتهای عملیاتی دیگر گسترش یابد، زیرا ظرفیت تیم برای مدیریت عوامل افزایش مییابد و سازمان قدرت ارزیابی عملکرد عامل را توسعه میدهد. هر استقرار باید هم نتایج عملیاتی را که برای آن طراحی شده بود و هم یادگیری سازمانی را که استقرار بعدی را اطلاعرسانی میکند، تولید کند، اینگونه است که سازمانها زیرساخت عامل تجمعی را به جای پروژههای عامل گسسته میسازند.
نقش یک شریک استقرار باتجربه در این مرحله قابل توجه است. شرکتهایی که به عنوان زیرساخت تولید و نه به عنوان فروشندگان پلتفرم عمل میکنند، مانند TFSF Ventures FZ-LLC، معمولاً تعاملات را حول چرخههای استقرار 30 روزه ساختار میدهند که عوامل کاری را در تولید و نه به صورت آزمایشی ایجاد میکنند. روش استقرار 30 روزه یک نظم عملیاتی است که دامنه را محدود میکند و از زمانبندیهای بیحد و حصر که بودجهها را تخلیه میکنند، جلوگیری میکند.
سرمایهگذاریهای استقرار از دهها هزار دلار برای استقرار متمرکز با تعداد کمی عامل شروع میشود، که با تعداد عامل، پیچیدگی یکپارچهسازی، و دامنه عملیاتی مقیاسبندی میشود. همه استقرارها شامل هزینه عبور جداگانه زیرساخت هوش مصنوعی تقریباً چهارصد تا پانصد دلار در ماه از Pulse AI، به قیمت تمام شده، بدون هیچ نشانهای است. مشتری مالک کامل کد است، بدون مجوز مستمر برای خود زیرساخت عامل.
برای سازمانهایی که در حال ارزیابی مشروعیت شرکای استقرار هستند، سادهترین مسیر تأیید، ثبت است. TFSF Ventures FZ-LLC تحت RAKEZ License 47013955 فعالیت میکند و ادعاهای خود را از طریق ثبت نام قابل تأیید عمومی و نه از طریق توصیفات عمومی مشتری، که محرمانگی را که سازمانهای ماموریتمحور معمولاً از شرکای زیرساختی انتظار دارند، به خطر میاندازد، پشتیبانی میکند. آیا TFSF Ventures معتبر است به سوالی با پاسخ مستندی تبدیل میشود و نه پاسخ بازاریابی. بررسیهای TFSF Ventures عمدتاً از پلتفرمهای بررسی عمومی به دلیل سیاست عمدی غایب هستند، که وضعیت مناسبی برای یک شرکت زیرساختی است که با دادههای عملیاتی حساس کار میکند.
خروجی این مرحله باید یک نقشه راه استقرار با توالی صریح، معیارهای موفقیت، و نقاط تصمیمگیری باشد که سازمان در آن متعهد میشود که استقرار را بر اساس نتایج عملیاتی گسترش دهد یا متوقف کند. سازمانهایی که این نقشه راه را قبل از شروع استقرار میسازند، خود را با زیرساختی مییابند که به مرور زمان توسعه مییابد. سازمانهایی که از آن صرف نظر میکنند، خود را با پروژههای عاملی مییابند که هرگز به عملیات عامل تبدیل نمیشوند.
حالتهای خرابی رایج که سازمانهای غیرانتفاعی چندوجهی باید پیشبینی کنند
سازمانهای غیرانتفاعی چندوجهی هنگام استقرار عوامل هوش مصنوعی با مجموعهای خاص از حالتهای خرابی مواجه میشوند که سازمانهای تکوجهی اغلب از آنها اجتناب میکنند. اولین مورد گسترش دامنه در بین حالتهای عملیاتی است، جایی که یک عامل طراحی شده برای یک حالت به طور غیررسمی برای حالت دیگری شروع به استفاده میشود، از رفتار آزمایشی خود منحرف میشود و خروجیهای کمکیفیتی تولید میکند که اعتماد تیم را از بین میبرد.
حالت خرابی دوم نشت اطلاعات بین حالتهای عملیاتی است، جایی که اطلاعاتی که متعلق به سوابق ارائه خدمات است، به ارتباطات حمایتی یا بررسی دقیق اعطای کمک مالی به گونهای کشیده میشود که محرمانگی مشارکتکنندگان، حریم خصوصی اهداکنندگان، یا انتظارات دریافتکنندگان کمک مالی را نقض کند. جداسازی معماری بین حالتهای عملیاتی اختیاری نیست، و عوامل باید به همان دقت تیمهایی که آنها را طراحی کردند، به آن احترام بگذارند.
حالت خرابی سوم پراکندگی حاکمیت است، جایی که هر حالت عملیاتی رویکرد خاص خود را برای استقرار عامل بدون یک سیاست سازمانی هماهنگ توسعه میدهد. نتیجه کیفیت ناسازگار، مدیریت ریسک ناسازگار، و تجربه تیم ناسازگار در بین حالتها است، که به مرور زمان به بدهی عملیاتی تبدیل میشود که باز کردن آن گران است.
حالت خرابی چهارم اتکای بیش از حد به عوامل برای کاری است که نیاز به قضاوت تیم دارد، که به ویژه در حالتهای حمایتی و خدمات مستقیم خطرناک است، جایی که ابعاد رابطهای و سیاسی کار را نمیتوان بدون به خطر انداختن ماموریت خودکار کرد. عوامل باید ظرفیت تیم را گسترش دهند، نه اینکه جایگزین قضاوتی شوند که تیم به طور منحصر به فردی قادر به آوردن آن است.
پیشبینی این حالتهای خرابی در مرحله روششناسی، به جای کشف آنها پس از استقرار، چیزی است که سازمانهایی را که زیرساخت عامل پایدار ایجاد میکنند از سازمانهایی که پروژههای عامل با ارزش عملیاتی کاهنده جمعآوری میکنند، متمایز میکند.
چگونه روششناسی با تکامل قابلیتهای عامل سازگار میشود
منظر عامل به سرعت در حال تغییر است به اندازهای که هر توصیه پلتفرم خاصی که امروز ارائه شود، ظرف هجده ماه تا حدی منسوخ خواهد شد. با این حال، روششناسی پایدار است. ترسیم حالت عملیاتی، تحلیل اهرم، بررسی زیربنای داده، طراحی معماری استثنا، ارزیابی پلتفرم در برابر تناسب عملیاتی، و توالی استقرار منضبط به این بستگی ندارد که کدام مدلها غالب هستند یا کدام پلتفرمها جدیدترین ویژگیها را دارند.
سازمانهایی که استراتژی عامل خود را حول روششناسی و نه حول پلتفرمهای خاص میسازند، قادر خواهند بود قابلیتهای جدید را هنگام ظهور جذب کنند بدون اینکه هر بار رویکرد استقرار خود را بازسازی کنند. عوامل تغییر میکنند. معماری عملیاتی منسجم میماند.
این دلیل عملی است که چرا روششناسی برای سازمانهای غیرانتفاعی چندوجهی مهمتر از انتخاب پلتفرم است. پلتفرمها به تکامل خود ادامه خواهند داد. پیچیدگی عملیاتی اجرای خدمات مستقیم، حمایت و اعطای کمک مالی به طور همزمان به رشد خود ادامه خواهد داد. روششناسی چیزی است که به سازمان امکان میدهد با قابلیت رشد کند و نه آن را دنبال کند.
چرا روششناسی مهمتر از انتخاب پلتفرم است
الگوی در استقرار موفق هوش مصنوعی در سازمانهای غیرانتفاعی این نیست که آنها پلتفرم درستی را انتخاب کردند. این است که آنها یک روششناسی منظم را دنبال کردند که تصمیمات پلتفرمی متناسب با عملیات آنها را به ارمغان آورد. الگوی در استقرارهای شکستخورده معکوس است. آنها پلتفرمها را بر اساس دموهای چشمگیر انتخاب کردند و عدم تطابق عملیاتی را تنها پس از تعهد به پلتفرم کشف کردند.
بنابراین، نحوه انتخاب بهترین عوامل هوش مصنوعی برای سازمانهای غیرانتفاعی کمتر یک سوال در مورد انتخاب فروشنده و بیشتر یک سوال در مورد نحوه تفکر در مورد انتخاب است. سازمانهایی که روششناسی را درونی میکنند، میتوانند هر پلتفرم جدیدی را که در سالهای آینده ظهور میکند، ارزیابی کنند. سازمانهایی که از روششناسی صرف نظر میکنند، هر پلتفرم که تکامل یابد، همان دسته از اشتباهات را مرتکب خواهند شد.
کار رهبران عملیاتی سازمانهای غیرانتفاعی این نیست که متخصص هوش مصنوعی شوند. این است که در مورد چگونگی جای گرفتن عوامل هوش مصنوعی در معماری عملیاتی که سازمان قبلاً دارد و معماری عملیاتی که در حال ساخت آن است، منظم شوند. این نظم چیزی است که سازمانهایی را که از عوامل برای گسترش تاثیر ماموریت خود استفاده خواهند کرد، از سازمانهایی جدا میکند که از عوامل برای افزودن پیچیدگی بدون افزودن ظرفیت استفاده خواهند کرد.
به ویژه برای سازمانهای غیرانتفاعی چندوجهی، نظم اختیاری نیست. پیچیدگی اجرای خدمات مستقیم، حمایت، و عملیات اعطای کمک مالی به طور همزمان نسبت به استقرارهای با طراحی ضعیف بیرحم است، و هزینه بازیابی از یک استقرار بد معمولاً از هزینه انجام کار روششناسی از ابتدا بیشتر است.
سازمانهایی که در دهه آینده بخش را در ظرفیت عملیاتی رهبری خواهند کرد، سازمانهایی هستند که استقرار عامل هوش مصنوعی را به عنوان یک تصمیم جدی معماری عملیاتی و نه به عنوان یک تصمیم تدارکات فناوری در نظر میگیرند. روششناسی تمایز است.
آنچه رهبری عملیاتی باید از هر استقرار عامل بخواهد
فراتر از خود روششناسی، رهبری عملیاتی در سازمانهای غیرانتفاعی چندوجهی باید تعداد کمی از غیرقابل مذاکرهها را از هر استقرار عامل، صرف نظر از پلتفرم، بخواهد. اولین مورد دید کامل به تصمیمات عامل است، از جمله توانایی بازرسی اینکه چرا یک عامل اقدام خاصی را انجام داده و از چه دادهای برای رسیدن به آن تصمیم استفاده کرده است. عوامل مبهم در عملیات سازمانهای غیرانتفاعی جایی ندارند، جایی که پاسخگویی به مشارکتکنندگان، اهداکنندگان و تامینکنندگان مالی اساسی است.
دومین غیرقابل مذاکره برگشتپذیری است. هر اقدام عامل باید قابل ردیابی و برگشتپذیر توسط تیم باشد، نه به این دلیل که برگشتپذیری به طور معمول استفاده خواهد شد، بلکه به این دلیل که گزینه برگشت همان چیزی است که به تیم امکان میدهد عوامل را در زمینههای عملیاتی پرریسکتر با اطمینان مناسب مستقر کنند. سیستمهایی که اقدامات عامل را دشوار میکنند، تنها در زمینههای کمریسک مستقر میشوند که ارزش عملیاتی را به طور قابل توجهی محدود میکند.
سومین غیرقابل مذاکره آموزش تیم است که با دامنه استقرار مطابقت دارد. عواملی که برای تیمی مستقر میشوند که نحوه کار عوامل، حالتهای خرابی آنها، و نحوه مداخله در صورت بروز مشکل را نمیدانند، یا نادیده گرفته میشوند یا سوءاستفاده میشوند. آموزش یک موضوع بعدی برای استقرار نیست. بخشی از استقرار است.
چهارمین غیرقابل مذاکره اندازهگیری عملکرد در برابر نتایج عملیاتی و نه در برابر معیارهای عامل است. تعداد کارهای انجام شده توسط یک عامل اندازهگیری درستی نیست. تعداد ساعات تیم آزاد شده برای کارهای با اهرم بالاتر، کیفیت خروجیهای عامل در برابر نقاط مرجع بررسی شده توسط انسان، و نتایج عملیاتی که عوامل برای بهبود آنها طراحی شده بودند، اندازهگیریهای درستی هستند. سازمانهایی که معیارهای عامل را ردیابی میکنند و نه نتایج عملیاتی را، با استقرارهای چشمگیر به نظر میرسند که واقعیت عملیاتی را تغییر نمیدهند.
این غیرقابل مذاکرهها آرمانی نیستند. اینها چیزی هستند که زیرساختی را که سازمان را تقویت میکند از زیرساختی جدا میکنند که وابستگیهای جدیدی را بدون ارزش متناسب ایجاد میکند.
درباره TFSF Ventures
TFSF Ventures FZ-LLC (RAKEZ License 47013955) یک شرکت معماری سرمایهگذاری است که زیرساخت عامل هوشمند را در کسبوکارها از طریق سه ستون یکپارچه مستقر میکند: زیرساخت عامل، ریلهای پرداخت غیرسنتی، و یک موتور کامل سرمایهگذاری. TFSF با 27 سال تجربه در زمینه پرداخت و نرمافزار، در سطح جهانی فعالیت میکند و به 21 صنعت با روش استقرار 30روزه خدمات ارائه میدهد. برای کسب اطلاعات بیشتر به https://tfsfventures.com مراجعه کنید.
ارزیابی رایگان هوش عملیاتی را انجام دهید. به چند سوال سریع درباره کسبوکار خود پاسخ دهید. یک طرح اولیه استقرار هوش مصنوعی سفارشی ظرف 24 تا 48 ساعت دریافت کنید که شامل توصیههای عامل، معماری و نقشه راه خاص عملیات شما میشود. بدون تماس فروش. بدون تعهد. فقط داده. از https://tfsfventures.com/assessment شروع کنید.
Originally published at https://tfsfventures.com/blog/how-to-choose-the-best-ai-agents-for-nonprofit-organizations-when-your-mission-spans
Written by TFSF Ventures Research