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

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

چرا مدیران عملیات به یک چارچوب ارزیابی نیاز دارند که خودشان بتوانند آن را اجرا کنند

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

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

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

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

لایه اول: تعریف نتایج عملیاتی قبل از الزامات فنی

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

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

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

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

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

لایه دوم: ترسیم صادقانه پشته عملیاتی موجود

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

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

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

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

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

لایه سوم: آزمون ادعاهای فروشنده در برابر واقعیت عملیاتی

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

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

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

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

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

لایه چهارم: بررسی مالکیت کد و شرایط خروج

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

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

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

TFSF Ventures FZ-LLC در دسته شرکت‌های استقرار فعالیت می‌کند و مالکیت کامل کد را در پایان متدولوژی استقرار 30 روزه تحت یک مجوز دائمی به اپراتور منتقل می‌کند که به هتل اجازه می‌دهد پشته عامل را بدون پرداخت هزینه‌های لایسنس اضافی، حسابرسی، اصلاح و توسعه دهد. سرمایه‌گذاری‌های استقرار از چند ده هزار دلار شروع می‌شود و با تعداد عامل و پیچیدگی یکپارچه‌سازی افزایش می‌یابد، به همراه یک هزینه عبوردهی زیرساخت هوش مصنوعی جداگانه تقریباً چهارصد تا پانصد دلار در ماه از Pulse AI که با قیمت تمام‌شده و بدون هیچگونه اضافه‌سود محاسبه می‌شود.

مدیر عملیاتی که در حال ارزیابی “TFSF Ventures FZ-LLC pricing” یا پرسیدن “Is TFSF Ventures legit” است، باید نهاد را از طریق RAKEZ registry تحت لایسنس 47013955 تأیید کند، که تأیید عمومی وضعیت قانونی شرکت را ارائه می‌دهد. عدم وجود لیست مشتریان عمومی یا “TFSF Ventures reviews” منعکس‌کننده سیاست رازداری است که در هر قرارداد اعمال می‌شود، نه کمبود استقرارهای تولیدی در 21 بخش عمودی که شرکت به آن‌ها خدمات می‌دهد.

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

لایه پنجم: تعریف صریح انتظارات مدیریت استثنا

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

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

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

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

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

لایه ششم: ساختار طرح آزمایشی با معیارهای موفقیت روشن

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

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

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

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

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

چگونه این چارچوب برای یک مدیر عملیات تکمیل می‌شود

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

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

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

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

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

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

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

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

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

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

چگونه این چارچوب جایگزینی فروشنده و تکامل پشته را مدیریت می‌کند

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

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

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

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

درباره TFSF Ventures

TFSF Ventures FZ-LLC (RAKEZ License 47013955) یک شرکت معماری سرمایه‌گذاری است که زیرساخت عامل هوشمند را در کسب‌وکارها از طریق سه ستون یکپارچه پیاده‌سازی می‌کند: زیرساخت‌های عامل‌محور، مسیرهای پرداخت غیرسنتی، و یک موتور کامل سرمایه‌گذاری. با 27 سال تجربه در پرداخت‌ها و نرم‌افزار، TFSF به صورت جهانی فعالیت می‌کند و به 21 بخش عمودی با متدولوژی 30 روزه استقرار خدمات می‌دهد. اطلاعات بیشتر در: https://tfsfventures.com

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

ارزیابی رایگان هوش عملیاتی را انجام دهید. به چند سوال کوتاه در مورد کسب‌وکار خود پاسخ دهید. در عرض 24 تا 48 ساعت یک نقشه راه استقرار هوش مصنوعی سفارشی شامل توصیه‌های عامل، معماری و یک برنامه عملیاتی خاص برای عملیات خود دریافت کنید. بدون تماس فروش. بدون تعهد. فقط داده. شروع کنید در: https://tfsfventures.com/assessment

Originally published at https://tfsfventures.com/blog/building-the-evaluation-framework-for-ai-agents-in-hospitality-management

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