معماری اتوماسیون هوش مصنوعی برای استخدام و جذب استعداد در Workday، Greenhouse، iCIMS و موتورهای منبعیابی مستقل
تصمیمات معماری برای اتوماسیون هوش مصنوعی برای جذب استعدادها در پشتههای ناهمگن ATS، منبعیابی، زمانبندی و ارزیابی.
شرکتهایی که قصد استقرار اتوماسیون هوش مصنوعی برای استخدام و جذب استعداد را دارند، معمولاً با یک مشکل مشابه روبرو میشوند. ATS آنها Workday یا Greenhouse یا iCIMS است. موتور منبعیابی آنها Gem، hireEZ، SeekOut یا ترکیبی از آنهاست. لایه زمانبندی GoodTime یا Prelude است. پلتفرم ارزیابی HireVue یا Codility است. هر ابزاری کار میکند. اما یکپارچهسازی بین آنها شکننده، ناقص یا توسط یک مهندس واحد که دو فصل پیش شرکت را ترک کرده، نگهداری میشود. Architecting اتوماسیون گردش کار استخدام مبتنی بر هوش مصنوعی در چنین منظری بیش از خرید یک ابزار دیگر نیازمند است.
چرا استقرارهای متمرکز بر ATS در مقیاس بالا شکست میخورند
حالت شکست دیگر استقرار متمرکز بر ATS (سیستم پیگیری متقاضیان) تأخیر ویژگیها است. فروشندگان ATS ویژگیهایی را در اولویت قرار میدهند که به کل پایگاه مشتریان آنها سود میرساند، یعنی قابلیتهای هوش مصنوعی که ارائه میدهند عمومی هستند نه متناسب با الگوهای عملیاتی خاص. شرکتهایی با گردشهای کاری غیرمعمول، الزامات انطباق پیچیده، یا محدودیتهای صنعتی خاص، به ندرت آنچه را که نیاز دارند از ویژگیهای عمومی هوش مصنوعی ATS دریافت میکنند.
رویکرد پیشفرض اکثر رهبران جذب استعداد (TA) این است که از فروشنده ATS ویژگیهای هوش مصنوعی را درخواست کرده و آنها را به مجوز موجود اضافه کنند. این برای مقیاسهای کوچک کار میکند. اما در مقیاس بالا شکست میخورد زیرا ATS ها به عنوان سیستمهای ثبت طراحی شدهاند، نه لایههای ارکستراسیون. ویژگیهای هوش مصنوعی موجود در Workday یا iCIMS توسط آنچه ATS میتواند ببیند، یعنی دادههای نامزد داخل خود ATS، محدود شدهاند.
دادههای نامزدی که برای عاملان جذب استعداد مبتنی بر هوش مصنوعی اهمیت دارد، به ندرت محدود به ATS است. تاریخچه تعامل با منبعیابی در Gem قرار دارد. نمرات ارزیابی در HireVue قرار دارد. رونوشت مصاحبهها در Metaview قرار دارد. اطلاعات جبران خسارت در HRIS قرار دارد، گاهی اوقات در همان نمونه Workday و گاهی اوقات در جای دیگر. در دسترس بودن تقویم در Google یا Microsoft قرار دارد. عاملی که به تمام این اطلاعات نیاز دارد، نمیتواند با زندگی در داخل ATS به آن دسترسی پیدا کند.
تصمیم معماری که تعیین میکند آیا اتوماسیون هوش مصنوعی واقعاً کارایی را ارائه میدهد، این است که لایه ارکستراسیون در کجا قرار دارد. برخی شرکتها آن را در ATS قرار میدهند و محدودیتها را میپذیرند. برخی دیگر آن را در یک لایه سفارشی قرار میدهند که به تمام سیستمها دسترسی پیدا کرده و بین آنها هماهنگی ایجاد میکند. رویکرد سفارشی ساختن دشوارتر است اما در صورت انجام صحیح، قابلیتهای بسیار بیشتری را به ارمغان میآورد.
این متدولوژی نحوه معماری اتوماسیون هوش مصنوعی برای استخدام و جذب استعداد را پوشش میدهد که در سراسر پشتههای ناهمگن کار میکند، نه اینکه با آنها مبارزه کند.
چهار لایه یک معماری اتوماسیون جذب استعداد کارآمد
لایه ارکستراسیون همچنین جایی است که اتوماسیون منبعیابی هوش مصنوعی کاندیدا، از مرز منبعیابی و غربالگری عبور میکند، جایی که ابزارهای غربالگری و رتبهبندی هوش مصنوعی به لجستیک مصاحبه منتقل میشوند، و جایی که نمرات ارزیابی به ساخت پیشنهاد شغلی کمک میکنند. هر یک از این انتقالها جایی است که اگر لایه ارکستراسیون وجود نداشته باشد یا ضعیف باشد، کار از بین میرود.
هر پشته جذب استعداد (TA) که مقیاسپذیر است، چهار لایه دارد، خواه تیم سازنده آن به طور صریح این لایهها را طراحی کرده باشد یا به طور تصادفی به آنها رسیده باشد. اولین لایه، لایه سیستم ثبت است که وضعیت معتبر درخواستها، نامزدها و پیشنهادها را نگهداری میکند. دومین لایه، لایه تعامل است که منبعیابی، ارتباطات و تجربه نامزد را در کانالهای مختلف مدیریت میکند. سومین لایه، لایه عملیاتی است که زمانبندی، ارزیابی و لجستیک مصاحبه را اجرا میکند. چهارمین لایه، لایه ارکستراسیون است که بین سه لایه دیگر هماهنگی ایجاد کرده و استثنائات را مدیریت میکند.
شرکتهایی که با اتوماسیون هوش مصنوعی دست و پنجه نرم میکنند، معمولاً لایههای یک تا سه را مستقر کردهاند اما لایه چهارم را ندارند. هر ابزاری دامنه خود را بهینهسازی میکند. گردش کار بین ابزارها از طریق کار دستی استخدامکننده، یکپارچهسازیهای شکننده نقطه به نقطه یا هر دو اتفاق میافتد. اضافه کردن ویژگیهای هوش مصنوعی به ابزارهای منفرد بدون یک لایه ارکستراسیون، به جای کاهش آن، هرج و مرج را تسریع میکند.
شرکتهایی که موفق هستند، لایه چهارم را به عنوان یک نگرانی معماری درجه یک در نظر میگیرند. آنها آن را به طور هدفمند میسازند، با ظرفیت مهندسی آن را تأمین میکنند و با آن به عنوان یک زیرساخت تولیدی رفتار میکنند تا صرفاً یک پیکربندی. لایه ارکستراسیون همان چیزی است که عاملان هوش مصنوعی را به جای دکمههای ویژگی در ابزارهای جداگانه، به زیرساخت استخدام شرکتی تبدیل میکند.
پیامد این برای انتخاب فروشنده این است که هیچ پلتفرم واحدی به خوبی تمام چهار لایه را جایگزین نمیکند. Workday در لایه یک قوی است. Greenhouse در لایههای یک و تا حدی سه قوی است. Gem در لایه دو قوی است. GoodTime در بخشی از لایه سه قوی است. هیچ یک از آنها در لایه چهار قوی نیستند زیرا لایه چهار به تعریف خود، یکپارچهسازی بین ابزاری است.
طراحی یکپارچه سازی سیستم ثبت اطلاعات
تکامل شماتیک نیز نیاز به رسیدگی صریح دارد. Workday، Greenhouse و iCIMS همگی بهروزرسانیهای دورهای را منتشر میکنند که میتوانند تعریف فیلدها را تغییر دهند، آبجکتهای جدید اضافه کنند، یا قراردادهای API را اصلاح کنند. لایه ارکستراسیون نیاز به نگاشتهای نسخهدار و یک استراتژی انحلال دارد تا انتشار نسخههای فروشندگان، اتوماسیون را یک شبه خراب نکند.
لایه سیستم ثبت اطلاعات باید وضعیت خود را به اندازهای تمیز عرضه کند که لایه ارکستراسیون بتواند به طور قابل اعتمادی از آن بخواند و در آن بنویسد. API Workday این امکان را از طریق نقاط پایانی مستند شده، اشتراک رویدادها و صادرات انبوه دادهها فراهم میکند. Greenhouse نیز از طریق Harvest API و Webhooks همین را فراهم میکند. iCIMS نیز از طریق REST API و چارچوب یکپارچهسازی خود، این امکان را ارائه میدهد.
تصمیم معماری این است که جریان وضعیت در کدام جهت باشد. تمیزترین الگو این است که ATS را برای وضعیت درخواست و کاندیدا مرجع در نظر بگیریم و به لایه ارکستراسیون اجازه دهیم به تغییرات مشترک شود تا به جای نظرسنجی از آنها. جریان رویداد مبتنی بر webhook، تأخیر را کاهش میدهد و از مشکلات محدودیت نرخ که نظرسنجی در مقیاس بالا ایجاد میکند، جلوگیری میکند.
همگامسازی دوطرفه دشوارتر است. هنگامی که لایه ارکستراسیون نیاز به نوشتن مجدد در ATS دارد، مدیریت تداخل مهم میشود. اگر یک استخدامکننده، مرحله کاندیدا را در همان لحظهای که لایه ارکستراسیون در حال پردازش یک رویداد است، بهروزرسانی کند، ممکن است بهروزرسانی اشتباه اعمال شود. معماریای که پایدار است، از کنترل همزمانی خوشبینانه، آخرین نوشتن برنده با گزارشهای حسابرسی، یا معناشناسی قفل صریح بسته به عملیات استفاده میکند.
همسویی مدل داده نیز اهمیت دارد. ATS یک شمای خاص برای کاندیداها، درخواستها و مراحل دارد. لایه ارکستراسیون باید مدل خود را با شمای ATS نگاشت کند و تغییرات اجتنابناپذیر را که ATS فیلدهای سفارشی اضافه میکند، مراحل گردش کار را تغییر میدهد، یا قراردادهای API را اصلاح میکند، مدیریت کند. این نگاشت یک کار مستمر است، نه یک یکپارچهسازی یکباره.
طراحی یکپارچه سازی موتور منبع یابی
الزامات اقامت دادهها، بعد دیگری به معماری یکپارچهسازی اضافه میکند. موتورهای منبعیابی و پلتفرمهای ATS به طور فزایندهای میزبانی دادههای منطقهای را برای رعایت مقررات GDPR، قوانین حفاظت از دادههای بریتانیا و رژیمهای مشابه ارائه میدهند. لایه ارکستراسیون باید این مرزها را با مسیریابی دادهها از طریق نقاط پایانی منطقهای صحیح، به جای متمرکز کردن همه چیز در یک منطقه، رعایت کند.
الگوهای احراز هویت نیز در موتورهای منبعیابی متفاوت است. برخی از جریانهای OAuth، برخی از کلیدهای API و برخی از طرحهای توکن اختصاصی استفاده میکنند. لایه ارکستراسیون باید اعتبارنامهها را به صورت ایمن در همه آنها مدیریت کند و آنها را مطابق با الزامات امنیتی فروشنده بدون ایجاد اختلال در گردشهای کاری اتوماسیون فعال، به روز کند.
موتورهای منبعیابی مستقل مانند Gem، hireEZ، SeekOut و Eightfold هر کدام مدلهای داده، API و الگوهای احراز هویت خاص خود را دارند. یکپارچهسازی آنها در لایه ارکستراسیون، نیاز به مهندسی اتصالدهنده برای هر یک و نگهداری مستمر با تکامل API آنها دارد.
انتخاب معماری این است که آیا موتورهای منبعیابی به طور مستقیم در لایه ارکستراسیون یکپارچه شوند یا اینکه آنها را با ATS یکپارچه کنیم و اجازه دهیم ATS وضعیت را به لایه ارکستراسیون منتقل کند. یکپارچهسازی مستقیم در ابتدا کار بیشتری میبرد اما سیگنال غنیتری تولید میکند زیرا اطلاعات منبعیابی که ATS آنها را ثبت نمیکند، برای لایه ارکستراسیون قابل مشاهده باقی میماند.
وضعیت توالی یک نمونه است. وقتی یک کاندید در توالی اطلاعرسانی Gem قرار دارد، مرحله توالی، سابقه پاسخ و کیفیت تعامل برای تصمیمات هماهنگی در مورد زمان درگیر کردن استخدامکنندگان، زمان افزایش سطح، و زمان حذف مهم است. ATS وضعیت توالی را ثبت نمیکند. یکپارچهسازی مستقیم با Gem این کار را انجام میدهد.
محدودیتهای نرخ (Rate limits) و مدیریت سهمیه (quota management) در اینجا شایسته توجه هستند. موتورهای منبعیابی اغلب دارای محدودیتهای نرخ درخواست هستند که میزان تهاجمی بودن لایه ارکستراسیون در دریافت وضعیت را محدود میکند. معماریهایی که این محدودیتها را رعایت میکنند، مقیاسپذیر هستند. معماریهایی که آنها را نادیده میگیرند، دقیقاً در نقاط حجمی که اتوماسیون باید سختتر کار کند، با مشکل مواجه میشوند.
نیازهای تازگی داده بسته به مورد استفاده متفاوت است. هماهنگسازی وضعیت میتواند چند دقیقه تأخیر را تحمل کند. اعلانهای استخدامکننده در مورد پاسخ نامزدها نمیتوانند. معماریای که پایدار میماند، بین موارد استفاده تمایز قائل میشود و سرعتهای بهروزرسانی متفاوتی را بر این اساس اعمال میکند.
طراحی یکپارچهسازی لایه عملیاتی
تغییرات چرخه حیات فروشنده نیز به مرور زمان این لایه را تحت تأثیر قرار میدهد. ابزارهای عملیاتی با تکامل بازار خریداری، منسوخ یا جایگزین میشوند. معماریای که پایدار میماند، منطق یکپارچهسازی را به اندازهای ماژولار میکند که جابجایی یک ابزار عملیاتی با دیگری نیاز به بازسازی لایه ارکستراسیون نداشته باشد.
پلتفرمهای زمانبندی، ارزیابی و اطلاعات مصاحبه هر یک مراحل عملیاتی خاصی را اشغال میکنند. ادغام آنها نیازمند درک این است که هر یک چه چیزی را در اختیار دارند، چه وضعیتی را تولید میکنند و چگونه آن وضعیت به سیستم ثبت بازمیگردد و به مرحله بعدی جریان مییابد.
GoodTime رویدادهای مصاحبه، دادههای حضور و ترکیب پنل را تولید میکند. لایه ارکستراسیون برای اینکه بداند مصاحبهها چه زمانی اتفاق افتادهاند، چه کسی شرکت کرده و اقدام بعدی چه باید باشد، به این وضعیت نیاز دارد. جریان رویداد مبتنی بر وبهوک این کار را در مقیاس بالا به خوبی مدیریت میکند.
پلتفرمهای ارزیابی مانند HireVue، نمرات، ضبطهای ویدیویی و فرادادههای ارزیابی را تولید میکنند. لایه ارکستراسیون برای تصمیمگیریهای مسیریابی به نمرات و برای اهداف انطباق و حسابرسی به ضبطها نیاز دارد. ورود نمره ساده است. مدیریت ضبط نیازمند سیاستهای ذخیرهسازی و نگهداری است که به EEOC و الزامات حریم خصوصی قابل اجرا بستگی دارد.
پلتفرمهای هوش مصاحبه مانند Metaview، یادداشتهای ساختاریافته و بینشهای مربیگری تولید میکنند. لایه ارکستراسیون میتواند از یادداشتها برای بهروزرسانی سوابق نامزدها، ارائه فرصتهای مربیگری به مدیران و فعال کردن بررسی انطباق در مواردی که محتوای مصاحبه نشاندهنده نگرانیهای EEOC است، استفاده کند. یکپارچهسازی از ارزش بالایی برخوردار است اما نیاز به طراحی دقیق در مورد اینکه کدام سیگنالها به کجا منتقل شوند، دارد.
سیستمهای تقویم اساسیترین یکپارچهسازی در این لایه هستند. تقویمهای Google Workspace و Microsoft 365 زیربنای هر ابزار زمانبندی هستند. لایه ارکستراسیون برای هر منطقی که شامل زمان، در دسترس بودن یا حل تعارض باشد، به آگاهی از تقویم نیاز دارد. APIهای تقویم بالغ و پایدار هستند، اما عمق یکپارچهسازی تعیین میکند که لایه ارکستراسیون چقدر میتواند هوش را به کار گیرد.
طراحی خود لایه ارکستراسیون
لاگین و حسابرسی نیز در این لایه انجام میشود. هر تصمیم خودکار باید یک رکورد از دادههایی که عامل دید، آنچه تصمیم گرفت و چرا، داشته باشد. دفاع در برابر EEOC، بازبینیهای داخلی انطباق، و اشکالزدایی پس از حادثه، همگی به کامل و قابل جستجو بودن این رکوردها بستگی دارند. معماریای که پایدار میماند، لاگین را از روز اول به عنوان یک نگرانی درجه یک در نظر میگیرد، نه اینکه پس از حادثهای که این شکاف را آشکار میکند، آن را پیادهسازی کند.
قابلیت مشاهده (Observability) بعد اغلب نادیده گرفته شده ارکستراسیون است. رهبران جذب استعداد (TA) که اتوماسیون هوش مصنوعی را در تولید اجرا میکنند، به داشبوردهایی نیاز دارند که نشان دهد لایه ارکستراسیون چه کاری انجام میدهد، کجا موفق است، کجا شکست میخورد و تغییرات اخیر چگونه بر رفتار تأثیر گذاشتهاند. بدون قابلیت مشاهده، اشکالزدایی حوادث روزها طول میکشد. با آن، اشکالزدایی ساعتها طول میکشد و اعتماد به سیستم افزایش مییابد.
لایه ارکستراسیون جایی است که تصمیمات معماری اتخاذ شده در جای دیگر، یا نتیجه میدهند یا شکست میخورند. این لایه باید ورود رویدادها را از تمام سیستمهای یکپارچه شده مدیریت کند، وضعیت خود را برای تصمیمگیریهای ارکستراسیون حفظ کند، منطق اتوماسیون را اجرا کند، استثنائات را به انسانها اطلاع دهد و تصمیمات را به ابزارهای زیرین بازنویسی کند.
مدل وضعیت برای لایه ارکستراسیون باید غنیتر از مدل وضعیت ATS باشد. وضعیت ATS مراحل گردش کار را ثبت میکند. وضعیت ارکستراسیون تاریخچه تصمیمگیری، استدلال عامل، محرکهای استثنا و اقدامات در حال انتظار در سراسر سیستمها را ثبت میکند. این مدل نیاز به نسخهبندی دارد تا تغییرات در منطق باعث عدم اعتبار تصمیمات تاریخی نشود.
پردازش رویدادها باید رویدادهای خارج از ترتیب، رویدادهای تکراری و رویدادهایی که پس از تأخیرهای طولانی میرسند را مدیریت کند. Webhooks به معنای دقیق قابل اعتماد نیستند. آنها مجدداً تلاش میکنند، شکست میخورند و گاهی اوقات هرگز نمیرسند. معماریای که پایدار میماند، شامل وظایف هماهنگسازی است که به طور دورهای سازگاری وضعیت بین لایه ارکستراسیون و سیستمهای یکپارچه شده را تأیید میکند.
منطق تصمیمگیری نیاز به مرزهای صریح در مورد اینکه چه چیزی به صورت خودمختار اجرا میشود، چه چیزی با تأیید انسانی اجرا میشود و چه چیزی فورا افزایش مییابد، دارد. سازمانهای جذب استعداد (TA) ناب که بیشترین بهره را از اتوماسیون میبرند، سیاستهای روشنی در مورد اینکه کدام عاملان میتوانند بر کدام نوع تصمیمات بدون نظارت عمل کنند، دارند. سیاستهای مبهم یا اتوماسیون بیش از حد محتاطانه را تولید میکنند که در ارائه کارایی شکست میخورد یا اتوماسیون بیش از حد تهاجمی را تولید میکنند که حوادثی را ایجاد میکند.
رسیدگی به استثنا (Exception handling) لایه بقا است. هر نقطه یکپارچهسازی میتواند با شکست مواجه شود. هر تصمیم خودکار میتواند اشتباه باشد. معماریای که پایدار میماند، شکستها را تشخیص میدهد، آنها را طبقهبندی میکند و یا به طور خودکار آنها را حل میکند، یا آنها را برای بررسی انسانی به صف میکشد، یا بسته به شدت، فورا آنها را افزایش میدهد. نگرانیهای EEOC مربوط به استخدام مبتنی بر هوش مصنوعی نیاز به افزایش فوری دارند. شکستهای معمول در تغییر زمانبندی میتوانند برای بررسی دستهای به صف شوند.
وابستگیهای بینرشتهای نیز در طول کارهای معماری ظاهر میشوند. لایه هماهنگی اغلب به دادههای HRIS، دادههای مالی و گاهی اوقات دادههای هویت IT برای اتخاذ تصمیمات کامل نیاز دارد. ایجاد این جریانهای داده در اوایل کار از محدود شدن لایه هماهنگی به اطلاعات فقط مختص استخدام جلوگیری میکند، در حالی که اطلاعات گستردهتر کسب و کار نتایج بهتری را به همراه خواهد داشت.
چگونه TFSF Ventures این معماری را در تولید میسازد
مستندات و کتابهای راهنما با هر استقرار همراه هستند. دانش عملیاتی مورد نیاز برای اجرا، نگهداری و گسترش لایه ارکستراسیون در مستندات کنترل شده نسخه، و نه در ذهن افرادی که آن را ساختهاند، نگهداری میشود، که تداوم را از طریق تغییرات نیروی انسانی محافظت میکند.
TFSF Ventures FZ-LLC (RAKEZ License 47013955) معماری ارکستراسیون را در Workday، Greenhouse، iCIMS و موتورهای منبعیابی مستقل برای تیمهای داخلی جذب استعداد مستقر میکند. متدولوژی استقرار 30 روزه با 19 سوال ارزیابی عملیاتی شروع میشود که ترکیب پشته فعلی، سلامت یکپارچهسازی و شکافهای ارکستراسیون را ترسیم میکند. سپس استقرار، زیرساخت ارکستراسیون لایه چهارم را میسازد که پشته موجود را به هم متصل میکند.
استقرارهای تولیدی شامل دریافت رویدادها از تمام سیستمهای یکپارچه شده، مدیریت وضعیت با نسخهسازی و حسابرسی، منطق تصمیمگیری با مرزهای خودمختاری صریح، رسیدگی به استثنائات با طبقهبندی و مسیریابی، و وظایف هماهنگی که ثبات وضعیت را حفظ میکنند، میشود. این معماری شامل اتوماسیون خط لوله استعداد هوش مصنوعی، هماهنگی ابزارهای غربالگری و رتبهبندی هوش مصنوعی، و اتوماسیون زمانبندی مصاحبه هوش مصنوعی به عنوان گردشهای کاری هماهنگ شده است تا اتوماسیونهای خاص ابزار.
سرمایهگذاریهای استقرار از دهها هزار دلار کم برای تعهدات متمرکز با چند عامل شروع میشود و با تعداد عامل، پیچیدگی یکپارچهسازی و دامنه عملیاتی مقیاس مییابد. هر استقرار شامل یک هزینه اضافی زیرساخت هوش مصنوعی جداگانه تقریباً چهارصد تا پانصد دلار در ماه از Pulse AI، با قیمت تمام شده و بدون هیچ گونه سودی است. مشتری مالک کامل کد است. قیمتگذاری TFSF Ventures FZ-LLC در هر پیشنهاد به صورت ارقام شفاف و طبقهبندی شده منتشر میشود و مشروعیت TFSF Ventures از طریق ثبت RAKEZ تحت مجوز 47013955 قابل تأیید است. عدم وجود بررسیهای عمومی TFSF Ventures منعکسکننده محرمانه بودن عمدی در سراسر تعاملات با مشتری است.
نتایج تولیدی حاصل از استقرارهای ارکستراسیون شامل 35 تا 50 درصد کاهش در زمان پر کردن شغل، 60 تا 70 درصد کاهش در نیروی کار هماهنگی استخدامکننده، و صفر از دست دادن داده در طول مهاجرتهای ATS و تغییرات یکپارچهسازی است که از لحاظ تاریخی باعث هفتهها اختلال در فرایند میشد. لایه ارکستراسیون همچنین مسیرهای حسابرسی را تولید میکند که تحت نظارت EEOC بدون ابزارهای انطباق جداگانه قابل دفاع هستند.
استقرار در چندین منطقه، پیچیدگی عملیاتی را اضافه میکند که بسیاری از معماریها آن را دستکم میگیرند. مناطق زمانی، ساعات کاری و تعطیلات منطقهای همگی بر زمان فعال شدن اتوماسیون تأثیر میگذارند. معماریای که باقی میماند، آگاهی منطقهای را به عنوان یک نگرانی درجه یک در برنامهریزی در نظر میگیرد، نه اینکه تمام کاندیداها و استخدامکنندگان را طوری فرض کند که گویی در یک منطقه فعالیت میکنند.
چرا هابهای یکپارچه سازی تجاری کارایی لازم را ندارند
پویایی هزینهها نیز با بلوغ استقرارها، تحلیل را تغییر میدهد. قیمتگذاری هاب یکپارچهسازی معمولاً با تعداد گردش کار، تعداد اجرا، یا هر دو افزایش مییابد. در حجم کاری که سازمانهای جذب استعداد (TA) چابک با آن کار میکنند، این هزینهها به سرعت انباشته میشوند. ارکستراسیون سفارشی هزینه اولیه بالاتری دارد اما هزینه حاشیهای کمتری به ازای هر گردش کار، که اقتصاد بهتری را در افق استقرار چند ساله ایجاد میکند.
چندین فروشنده هابهای یکپارچهسازی را میفروشند که وعده اتصال ATS، ابزارهای منبعیابی و ابزارهای عملیاتی را از طریق گردشهای کاری قابل تنظیم میدهند. این ابزارها نیاز واقعی را برطرف میکنند و برای موارد استفاده ساده به خوبی کار میکنند. اما هنگامی که منطق ارکستراسیون به اندازهای پیچیده میشود که نیاز به مدیریت وضعیت، جریانهای شرطی در چندین رویداد، یا منطق تصمیمگیریای که بر اساس الگوهای تاریخی سازگار میشود، میرسد، به حد خود میرسند.
هابهای یکپارچهسازی اساساً محیطهای برنامهنویسی بصری هستند. آنها یکپارچهسازیهای ساده را آسانتر میکنند. اما ارکستراسیون پیچیده را دشوارتر میکنند زیرا انتزاع بصری هنگامی که منطق شامل وضعیت طولانیمدت، مدیریت استثنائات و تصمیمگیری تطبیقی باشد، از بین میرود.
انتخاب معماری این است که آیا برای موارد ساده از یک هاب یکپارچهسازی استفاده شود و برای موارد پیچیده از یک لایه ارکستراسیون سفارشی استفاده شود، یا یک لایه سفارشی یکپارچه ساخته شود که هر دو را مدیریت کند. رویکرد یکپارچه در ابتدا کار بیشتری میبرد اما سیستمی منسجم را تولید میکند که بهتر از پشتهای از گردشهای کاری هاب یکپارچهسازی که در طول سالها انباشته شدهاند، عمر میکند.
چیزی که هابهای یکپارچهسازی نمیتوانند جایگزین کنند، قضاوت مهندسی در مورد اینکه چه چیزی باید خودکار شود، چه چیزی باید افزایش یابد و چگونه باید با استثنائات برخورد شود، است. این تصمیمات معماری هستند، نه قابل تنظیم. خرید یک هاب یکپارچهسازی و رفتار با آن به عنوان لایه ارکستراسیون، همان نتیجهای را تولید میکند که خرید ابزارهای نقطهای و رفتار با آنها به عنوان لایه ارکستراسیون. شکافها باقی میمانند. پیچیدگی جابجا میشود.
سوال تشخیصی برای رهبران جذب استعداد
تشخیص همچنین ابزارهایی را که تیم واقعاً از آنها استفاده میکند در مقابل مجوزهایی که پرداخت شدهاند اما مورد استفاده قرار نمیگیرند، آشکار میکند. بسیاری از پشتههای جذب استعداد، قابلیتهای اضافی را در بین ابزارهایی شامل میشوند که استخدامکنندگان هرگز از آنها استفاده نکردهاند. حذف آنها قبل از افزودن ابزارهای جدید اغلب ظرفیت بودجه فوری را برای سرمایهگذاری در ارکستراسیون که شکافهای واقعی را برطرف میکند، ایجاد میکند.
شرکتهایی که این کار معماری را به پایان رساندهاند، همچنین گزارش میدهند که تمدیدهای فروشنده آسانتر است زیرا دقیقاً میدانند هر ابزار چه قابلیتی را ارائه میدهد و میتوانند بر اساس شواهد عملیاتی به جای موقعیتگیری فروشنده مذاکره کنند. این امر پویایی خرید را به گونهای تغییر میدهد که مزایای بودجه را سال به سال افزایش میدهد.
برای رهبران جذب استعداد که استقرار فعلی اتوماسیون هوش مصنوعی خود را ارزیابی میکنند، سوال تشخیصی این است که آیا لایه ارکستراسیون وجود دارد یا خیر. یک درخواست شغلی معمولی را انتخاب کنید. آنچه را که از منبعیابی تا استخدام در هر سیستمی که نامزد با آن تماس دارد، اتفاق میافتد، ردیابی کنید. شناسایی کنید که کدام انتقالها خودکار هستند، کدام یک نیاز به مداخله دستی استخدامکننده دارند، و کدام یک در شکافهایی قرار میگیرند که هیچکس اقدام بعدی را بر عهده ندارد.
انتقالاتی که اتوماسیون در آنها کار میکند متعلق به ابزارهایی هستند که یک مرحله واحد را به خوبی پوشش میدهند. انتقالاتی که در آنها مداخله دستی اتفاق میافتد متعلق به شکافهایی هستند که لایه ارکستراسیون باید آنها را ببندد. انتقالاتی که در آنها هیچکس اقدام بعدی را بر عهده ندارد، شکافهایی هستند که باعث طولانی شدن درخواست، خروج نامزد و از دست رفتن برنامههای سه ماهه میشوند.
بستن این شکافها کار معماریای است که خروجی پایدار تولید میکند. این کار با خرید ابزارهای بیشتر انجام نمیشود. این کار با ساخت یا استقرار لایه ارکستراسیونی انجام میشود که ابزارهایی را که تیم قبلاً از آنها استفاده میکند، در یک سیستم منسجم هماهنگ کند.
شرکتهایی که این کار را به پایان رساندهاند، با تیمهای کوچکتر، وظایف جذب استعداد را انجام میدهند که با برنامههای استخدامشان مطابقت دارد. شرکتهایی که این کار را انجام ندادهاند، همچنان در حال خرید ابزارهای نقطهای هستند و امیدوارند مشکل یکپارچهسازی خود به خود حل شود. این اتفاق نمیافتد، صرف نظر از اینکه تیم چند ابزار نقطهای اضافی را روی همان معماری شکسته قرار دهد. اتوماسیون هوش مصنوعی برای استخدام و جذب استعداد زمانی اهرم میکند که بر پایه معماری اجرا شود، نه زمانی که به عنوان یک ادعای بازاریابی به ابزارهای جداگانه متصل شود. بدون معماری، پیچیدگی را به همان مشکلی که تیم قبلاً داشت اضافه میکند.
درباره 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/architecting-ai-automation-for-recruiting-and-talent-acquisition-across-workday
Written by TFSF Ventures Research