تلهٔ پایلوت: اتوماسیون سریع عامل‌ها فرآیندهای ناکارآمد را کدگذاری می‌کند

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

این پدیده که در تحلیل مکینزی (McKinsey) منتشرشده در ۴ اوت ۲۰۲۶ با عنوان «تلهٔ پایلوت» (Pilot Trap) توصیف شده است، زمانی رخ می‌دهد که سرعت اتوماسیون در سطح تک‌وظایف، باعث می‌شود انحراف در طراحی کلی سیستم نادیده گرفته شود. نویسندگان این گزارش وضعیت را «سرعت در سطح وظیفه، انحراف در سطح طراحی» می‌نامند. برای رهبران فنی، این بدان معناست که موفقیت ظاهری یک پایلوت می‌تواند سدی در برابر دگرگونی واقعی سازمانی باشد. این چالش با یافته‌های اخیر هم‌راستا است، چرا که پژوهش‌های MIT نشان می‌دهد بسیاری از پروژه‌های آزمایشی عامل‌ها به دلیل فقدان بازگشت سرمایه واقعی شکست می‌خورند.

بسیاری از سازمان‌ها در حال حاضر در وضعیتی به نام «اتوماسیون سایه» (Shadow Automation) هستند. ابزارهای کم‌کد (Low-code) به متخصصانی نظیر مدیران حقوق و دستمزد یا استخدام‌کنندگان اجازه می‌دهند تا تنها در یک بعدازظهر، عامل‌های هوشمند (AI Agents) فعال را پیکربندی کنند. این‌ها پلتفرم‌های «ساخت از طریق پیکربندی» (Build-by-configuring) هستند که در آن‌ها بیشترِ کار به‌جای کدنویسی، صرف کلیک کردن و نوشتن دستورالعمل‌ها می‌شود. این‌ها صرفاً نمونه‌های اولیه یا پروتوتایپ نیستند؛ بلکه عامل‌های عملیاتی هستند که به جریان‌های کاری واقعی متصل شده و خروجی‌های واقعی تولید می‌کنند.

سازوکار تلهٔ پایلوت

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

• ریسک موفقیت: پایلوت‌های شکست‌خورده کم‌هزینه‌اند؛ آن‌ها را بعد از چند هفته خاموش می‌کنند و فراموش می‌کنند. اما پایلوت‌های موفق تبدیل به «عناصر تکیه‌گاه» (Load-bearing) می‌شوند؛ یعنی وضعیت روزانهٔ یک فرد به آن وابسته می‌شود و سازمان به آن متصل می‌گردد.
• تأیید ضمنی: وقتی یک عامل فعال در جریان کار ادغام می‌شود، در جلسات بودجه از آن دفاع می‌شود. این ابزار برای عملیات روزانه ضروری تلقی می‌گردد و به بخشی جدایی‌ناپذیر از سیستم تبدیل می‌شود.
• قفل‌شدگی فرآیند: عامل هر فرآیندی را که به او دیکته شده، کدگذاری می‌کند. این شامل تمام مراحلی است که شاید فقط به دلیل وجود یک سیستم قدیمی (که ۴ سال پیش جایگزین شده) یا سیاستی که هیچ‌کس از سال‌ها پیش نخوانده، وجود دارند. وقتی این مراحل کدگذاری می‌شوند، به چالش کشیدن آن‌ها بسیار سخت‌تر از زمانی است که صرفاً در یک سند متنی بودند.

این سخت‌ترین نسخهٔ تله است: در حالی که تلاش‌های تلف‌شده قابل بازیابی هستند، اما «قفل‌شدگی» (Lock-in) نیست. شما یک جریان کاری را بهینه نکرده‌اید، بلکه آن را تثبیت (Ratify) کرده‌اید. این موضوع تأکیدی است بر این یافته که نتایج هوش مصنوعی بیشتر به «شکل جریان کاری» وابسته است تا «ابزاری» که به آن اشاره می‌کند. سخت کردن یک جریان کاری بد، گران‌ترین اتفاقی است که یک پایلوت موفق می‌تواند رقم بزند.

هزینه پنهان نظارت

مکینزی رقم حیاتی‌ای را دربارهٔ هزینه وضعیت پایدار (Steady-state cost) هوش مصنوعی عامل‌محور فاش می‌کند. طبق گزارش این مؤسسه، تقریباً دو-سوم فعالیت‌های فعلی منابع انسانی (HR) می‌تواند تا سال ۲۰۳۰ به‌طور کامل اتوماتیک شود یا در مرحلهٔ تحویل به‌طور کامل اتوماتیک گردد. با این حال، عدد حیاتی‌تر در نمودار تخصیص زمان نهفته است.

در یک وضعیت مقصدِ بالغ، تقریباً ۲۰٪ از زمان انسان‌ها به «مدیریت قابلیت‌های عامل‌محور» اختصاص می‌یابد. گزارش صریحاً ذکر می‌کند که این یک «رقم قابل چشم‌پوشی یا گرد کردن» نیست.

این سربار ۲۰ درصدی شامل موارد زیر است:

• پیکربندی عامل‌ها و نوشتن یا بازبینی منطقی که عامل‌ها دنبال می‌کنند.
• تست کردن عامل‌ها پیش از انتشار گسترده (Wide release).
• نظارت بر عملکرد و مدیریت «انحراف» (Drift) — یعنی لغزش آهسته‌ای که در آن خروجی عامل همچنان محتمل به نظر می‌رسد، اما بی‌سروصدا دیگر درست نیست.
• بازنشسته کردن عامل‌ها هنگامی که جریان کاری زیربنایی تغییر می‌کند.

اگر مدلی برای کاهش هزینه، این یک-پنجم از ظرفیت انسانی را نادیده بگیرد، اساساً ناقص است. اتوماسیون در اینجا صرفاً یک هزینه نیروی کار را با هزینه دیگر جایگزین می‌کند: یک سربار نظارتی که قیمت واقعی اجرای عامل‌ها در مقیاس بزرگ است. این روند، برنامهٔ عامل‌ها را از «کاهش هزینه» به «جابه‌جایی هزینه» (Cost swap) تبدیل می‌کند. در مقیاس‌های وسیع‌تر، این پیچیدگی‌های نظارتی می‌تواند به شکاف‌های هماهنگی منجر شود که مانع از عملکرد صحیح سامانه‌های چندعاملی در سطح سازمانی می‌گردد.

شکاف حاکمیتی

مکینزی رویکردی از بالا به پایین را پیشنهاد می‌کند: ابتدا مدل عملیاتی انسان-عامل برای سال ۲۰۳۰ را تعریف کنید و سپس مسیر را به عقب برگردانید. مقصد را تعریف کنید و سپس توالی پیاده‌سازی، سرمایه‌گذاری در قابلیت‌ها و حاکمیت را مشخص نمایید.

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

• مهارت مدیریت محصول (Product Management) که اکثر بخش‌های منابع انسانی امروز فاقد آن هستند.
• زیربنای داده‌ای به اندازه کافی قوی برای اجرای یک گراف مهارت‌ها (Skills Graph).
• مدیر منابع انسانی (CHRO) با mandate (حکم یا mandate) واقعی برای طراحی نیروی کار در سطح سازمان.

برای یک شرکت معمولی، تنها اقدام عملی، تهیه یک «فهرست جامع» (Inventory) است. حاکمیت نباید با نقشه سال ۲۰۳۰، بلکه با شمارش تک‌تک اتوماسیون‌هایی که در محیط فعال هستند (Running in the wild) شروع شود. یک سازمان در این گزارش ۵۰ مورد کاربردی را اجرا کرد و «صرفه‌جویی سالانه قابل‌توجهی» یافت، اما نویسندگان هشدار می‌دهند که برخی سازمان‌ها صرفاً کارایی فرآیندهایی را بهبود بخشیده که یک بازطراحی جامع (End-to-end redesign) بعداً آن‌ها را به‌طور کلی حذف می‌کند.

رهبران باید برای هر عاملی که در ابزارهای کم‌کد، کارهای زمان‌بندی‌شده در اینباکس‌های مشترک، یا دستیارهای پیکربندی‌شده در سیستم‌های ثبت رکورد یافت می‌شود، سه حقیقت را شناسایی کنند:

• چه کسی آن را ساخته است؟
• به کدام سیستم‌ها دسترسی دارد؟
• اگر متوقف شود، چه چیزی می‌شکند؟

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

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

این تغییر دیدگاه، نحوه اندازه‌گیری پیشرفت را دگرگون می‌کند. این غریزه که عامل‌ها را به سمت দৃশ্য‌ترین فرآیندها هدایت کنیم، اغلب غلط است؛ فرآیندهای داخلی‌تر و آرام‌تر ممکن است شرط‌بندی‌های امن‌تری باشند.

هزینه «پیشرفت»

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

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

شرکتی با ده‌ها عامل فعال، جلوتر از شرکتی با سه عامل نیست؛ بلکه صرفاً تعهد بیشتری به «وضعیت فعلی» خود دارد. پرسش حیاتی برای هر برنامهٔ عامل‌محور این نیست که چه تعداد عامل در حال اجرا هستند یا دقت آن‌ها چقدر است، بلکه این است که برای تغییر یک تصمیم استراتژیک، چه مقدار از مدل عملیاتی فعلی باید بازخوانی و حذف شود — و آیا امروز کسی می‌تواند به این پرسش پاسخ دهد؟

گام بعدی شما

• فهرست تمام اتوماسیون‌های سایه در دپارتمان خود تهیه کنید و نقاط شکست آن‌ها را شناسایی نمایید.
• پیش از اتوماسیون هر فرآیند، بپرسید: «اگر این کار را امروز برای اولین بار طراحی می‌کردیم، آیا باز هم همین مراحل را طی می‌کردیم؟»
• بودجهٔ زمانی ۲۰ درصدی برای «مدیریت قابلیت‌ها» را در مدل‌های هزینه‌ای سال آینده لحاظ کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.