تصور کنید یک خطای کوچک در لحظه انتقال داده‌ها، کل زنجیره تأمین یک شرکت جهانی را در عرض چند دقیقه فلج کند. اگر در فصل مهاجرت‌های تابستان ۲۰۲۶ قصد دارید برای تصمیم نهایی «راه-اندازی» (Go-live) به هوش مصنوعی تکیه کنید، در حال انجام یک قمار خطرناک هستید که ماهیت شکننده مهاجرت‌های Brownfield را نادیده می‌گیرد. طبق هشدار وب‌سایت ayraix.com، یک شکست واحد در محیط تولید (Production) در جریان Cutover سیستم SAP می‌تواند کل عملیات لجستیکی یک سازمان را متوقف کند.
مهاجرت‌های Brownfield — که در آن سیستم‌های موجود به SAP S/4HANA تبدیل می‌شوند — به دلیل فشردگی تصمیمات بازگشت‌ناپذیر در یک بازه زمانی بسیار کوتاه، به‌شدت ریسکی هستند. در حالی که بسیاری از برنامه‌ها پیش از این از عامل‌های هوش مصنوعی برای اصلاح کدهای سفارشی (Custom-code remediation) و تولید تست‌ها استفاده کرده‌اند، خطر اصلی زمانی آغاز می‌شود که تیم‌ها تلاش کنند این عامل‌ها را به پنجره زمانی واقعی انتقال (Cutover) منتقل کنند.
چرا مرحله Cutover ریسکی‌ترین فاز است؟
مرحله Cutover یک محیط تحت فشار شدید است؛ جایی که انجماد داده‌ها (Data freezes)، انتقال رابط‌ها (Interface cutovers)، تحویل محدوده اعداد (Number-range handoffs) و تصمیمات نهایی «اجرا یا توقف» (Go/No-go) رخ می‌دهند. در این مرحله، وقتی کاربران محیط تولید در انتظار هستند، هیچ فرصتی برای تمرین مجدد وجود ندارد. چندین عامل این فاز را به‌شدت شکننده می‌کند:
- حقایق موازی: سیستم‌های مبدأ (ECC/S/4) و سیستم مقصد (S/4) ممکن است هر دو «درست» به نظر برسند، اما زمانی که تطبیق داده‌ها روی حجمی از اطلاعات انجام شود که هرگز در کلاینت تست (Test Client) وجود نداشت، این تطبیق شکست می‌خورد.
- انفجار یکپارچگی: وقتی IDocها، میان‌افزارها (Middleware) و APIهای شرکا پس از یک دوره انجماد به‌طور همزمان دوباره فعال می‌شوند، این «عمق صف» (Queue Depth) است که درباره موفقیت آن شب تصمیم می‌گیرد، نه تست‌های واحد (Unit Tests).
- ناهمگونی بازگشت: در حالی که مسیر مهاجرت رو به جلو معمولاً تمرین شده است، زمان‌بندی بازگشت (Rollback) اغلب نادیده گرفته می‌شود. اگر زمان بازگشت از پنجره زمانی موجود فراتر رود، آن برنامه دیگر یک نقشه عملیاتی نیست، بلکه صرفاً یک سند توصیفی است.
یک «اتاق جنگ» (War Room) با ریسک بالا را تصور کنید که در آن یک مدل هوش مصنوعی بر اساس یک اسکریپت تست موفق، پیشنهاد «اجرا» (Go) می‌دهد، اما متوجه جهش ناگهانی در عمق صف میان‌افزار نمی‌شود. در این لحظات، تأخیر در تصمیم‌گیری انسانی یک ویژگی مثبت (Feature) است، نه یک نقص (Bug)؛ زیرا تضمین می‌کند که یک شخص مسئول و نام‌برده، ریسک توقف تولید را می‌پذیرد. عامل‌هایی که بدون داشتن یک مالک انسانی پیشنهاد «اجرا» می‌دهند، تنها باعث ایجاد اعتماد کاذب می‌شوند.
چارچوب چهار مرحله‌ای گیت‌دار (Gated Framework)
طبق دستورالعملی که در ۱۲ اکتبر ۲۰۲۶ منتشر شد، عامل‌های هوش مصنوعی باید به‌عنوان شتاب‌دهنده در فازهای گیت‌دار عمل کنند، نه به‌عنوان اپراتورهای خودگردان. این رویکرد مشابه استفاده از مکانیزم Placement Gate برای ایجاد تعادل میان امنیت و دسترسی است که اجازه نمی‌دهد فرآیندهای حساس بدون عبور از فیلترهای کنترلی اجرا شوند. اگر یک گیت (دروازه) فاز شکست بخورد، تمام خروجی‌های بعدی عامل‌ها باید دور ریخته شوند، نه اینکه در محیط زنده وصله‌پینه شوند.
۱. ارزیابی (Assess): در این مرحله، حضور عامل‌ها برای اجرای ATC (ABAP Test Cockpit)، بررسی‌های آمادگی (Readiness checks) و اسکن کدهای سفارشی مورد استقبال است. آن‌ها می‌توانند یافته‌ها را بر اساس ریسک (سینتکس، عملکردی یا کارایی) خوشه‌بندی کرده و پیش‌نویس تخصیص مالک را تهیه کنند. با این حال، انسان‌ها همچنان درباره استثنائات محدوده (Scope exclusions) و امتیازات موقت تصمیم می‌گیرند. هدف، تولید فهرستی از یافته‌ها با «برچسب‌های اطمینان» است تا اطمینان حاصل شود مواردی با اطمینان پایین به‌طور خاموش حذف نمی‌شوند. تیم‌ها باید موارد «اصلاح پیش از تبدیل» را از مواردی که به‌عنوان استثنائات موقت با تاریخ انقضا پذیرفته شده‌اند، جدا کنند و نرخ خطای IDoc و زمان اجرای Jobها را برای مقایسه پس از Cutover ثبت کنند.
۲. اصلاح (Remediate): عامل‌ها می‌توانند تغییرات ABAP، CDS یا RAP و تست‌های واحد را پیشنهاد دهند. اما یک قانون مطلق وجود دارد: هیچ عاملی حق فعال‌سازی ترنسپورت‌ها یا ادغام (Merge) در شاخه تبدیل (Conversion branch) را ندارد. هر ترنسپورتی که اشیاء حیاتی تبدیل را لمس می‌کند، به یک بازبین انسانی ABAP نیاز دارد. برای حفظ حاکمیت (Governance)، تیم‌ها باید پیش‌نویس‌های عامل را با توافق‌نامه‌های سطح خدمات (SLA) بازبین‌ها جفت کنند؛ هر بک‌لگی که قدیمی‌تر از N روز شود، به یک ریسک Cutover تبدیل می‌شود. علاوه بر این، برنامه‌ها باید هزینه توکن‌ها و واحدهای AI را به ازای هر جریان کاری ردیابی کنند تا از غافلگیری‌های مالی در میانه برنامه جلوگیری شود و برای اهداف حسابرسی، یک پرچم «منشأ-عامل» (Agent-originated) روی ترنسپورت‌ها قرار دهند.
۳. تست (Test): هوش مصنوعی می‌تواند بسته‌های رگرسیون را بر اساس تم‌های نقص‌های یافت شده در SIT/UAT گسترش دهد. با این حال، سناریوهای حیاتی تجاری مانند پرداخت حقوق (Payroll)، بستن حساب‌های مالی، لجستیک با حجم بالا و EDI شرکا باید تحت مالکیت انسان باقی بمانند. این دستورالعمل بر «تطبیق اجرای موازی» (Parallel-run reconciliation) — یعنی مقایسه مانده‌ها، اقلام باز و تعداد رابط‌ها در سیستم‌های مختلف برای یک دوره مشخص — بیش از اسکریپت‌های ساده «مسیر خوش‌بینانه» (Happy-path) تأکید دارد.
۴. انتقال (Cutover): در طول دوره انجماد، دسترسی عامل‌ها به حالت «فقط خواندنی» (Read-only) محدود می‌شود. آن‌ها می‌توانند لاگ‌ها را خلاصه کنند یا یادآورهای چک‌لیست را ارسال کنند، اما اکیداً از فعال کردن Cutover تولید یا اجرای Rollback منع شده‌اند. این‌ها نقش‌های انسانی هستند که باید جایگزین‌های نام‌برده داشته باشند.
نقش‌های صریح انسانی
برای جلوگیری از تضاد منافع، این چارچوب تفکیک وظایف را اجباری می‌کند. نقش‌های زیر باید صریح و مجزا باشند:
- اپراتور عامل (Agent Operator): جریان‌های کاری تأیید شده را در محیط‌های غیرتولید یا حالت خواندنی اجرا می‌کند؛ مالک پیکربندی پرامپت/ابزار و شمارنده‌های مصرف است.
- بازبین ABAP: کدهای تولید شده توسط عامل را تأیید می‌کند و مالک صحت عملکردی ترنسپورت‌های اصلاحی است.
- تیم Basis / پلتفرم: مالک مکانیسم‌های SUM/DMO/NZDT، انجماد سیستم‌ها و SLAهای زیرساختی است.
- رهبر Cutover: مالک برنامه دقیقه به دقیقه، تصمیمات Go/No-go و ریتم ارتباطات است.
- رهبر اتاق جنگ تجاری: مالک اعتبارسنجی تجاری و تأیید نهایی «امکان ارسال» است تا از پیش‌راندن زمان‌بندی توسط «خوش‌بینی IT» جلوگیری کند.
اگر یک نفر همزمان نقش اپراتور عامل و رهبر Cutover را ایفا کند، کارایی بر ایمنی اولویت می‌یابد که یک ریسک بزرگ است.
محرک‌های غیرقابل مذاکره برای بازگشت (Rollback Triggers)
برخی سیگنال‌ها باید بدون توجه به خوش‌بینی هوش مصنوعی، باعث فعال شدن بازگشت تحت هدایت انسان شوند. این محرک‌ها باید پیش از شروع آخر هفته‌ی انتقال در بسته Cutover نوشته شوند:
- شکست رابط‌ها: نرخ خطای IDoc یا رابط‌ها از ضریب توافق‌شده نسبت به خط مبنا (Baseline) برای N بررسی متوالی فراتر رود.
- شکست اعتبارسنجی: فرآیندهای حیاتی مالی یا لجستیکی دو بار در اعتبارسنجی تجاری شکست بخورند و هیچ راهکار جایگزین تأیید شده‌ای وجود نداشته باشد.
- تجاوز از پنجره زمانی: زمان قفل نوشتن (Write-lock) یا پنجره توقف از تعریف تجاری امضا شده (نه فقط تعریف فنی) فراتر رود.
- ریسک زمان‌بندی: زمان تمرین بازگشت بیشتر از پنجره زمانی باقی‌مانده برای پیشروی باشد.
- مسدودکننده امنیتی: یک نقص امنیتی یا دسترسی، یک فرآیند تحت نظارت (Regulated) را بدون وجود کنترل جبرانی مسدود کند.
تمرین «غیرفعال‌سازی عامل» (Agent-Disable Drill)
پیش از آخر هفته واقعی، تیم‌ها باید یک «تمرین کلی» (Dress rehearsal) انجام دهند که شامل تمرین غیرفعال‌سازی عامل باشد. این کار ثابت می‌کند که تیم می‌تواند تمام عامل‌ها، از جمله اعتبارنامه‌ها و نقاط انتهایی MCP را در کمتر از ۱۵ دقیقه به حالت خواندنی یا خاموش تغییر دهد. تیم‌ها همچنین باید «شکست خلاصه‌ساز» را شبیه‌سازی کنند تا مطمئن شوند همچنان می‌توانند برنامه را از روی یک چک‌لیست چاپی و آفلاین اجرا کنند.
سایر الزامات تمرین شامل قرار دادن یک پیشنهاد اشتباه عمدی توسط عامل در محیط QAS است تا تأیید شود بازبین‌ها پیش از ترنسپورت آن را شناسایی می‌کنند. همچنین باید «زبان ساعت» تمرین شود (مثلاً: «ما X ساعت در یک پنجره تجاری Y ساعته هستیم») به جای گزارش‌های مبهمی مانند «SUM هنوز سبز است».
این تغییر در رویکرد، پذیرش این واقعیت است که شکست در اصلاحات AI اجتناب‌ناپذیر است. دستورالعمل پیشنهاد می‌کند که پیام شکست از پیش اسکریپت شود — با تمرکز بر شیء یا فرآیند آسیب‌دیده، تأثیر بر ساعت Cutover به ساعت، مالک انسانی و اینکه آیا این مورد باعث فعال شدن محرک بازگشت می‌شود یا خیر — به جای متهم کردن «توهم» مدل، که باعث سوزاندن اعتماد ذینفعان می‌شود.
معیارهای Go / No-Go
پیش از اعلام «اجرا»، برنامه‌ها باید حداقل گیت‌ها را پاس کنند: تمام نقص‌های حیاتی بسته یا با امضای تجاری به تعویق افتاده باشند، تطبیق اجرای موازی در محدوده تلورانس توافق‌شده باشد و زمان بازگشت در تمرینات، کوتاه‌تر از پنجره پیشروی باشد. نظارت پس از Cutover برای صف‌های IDoc، Jobها و میان‌افزارها باید برای ۴۸ ساعت اول توافق شده باشد.
برای یک معمار سازمانی، این بدان معناست که ارزش هوش مصنوعی در سال ۲۰۲۶ نه در خودمختاری، بلکه در «شفافیت» (Visibility) است. هدف این است که کارهای مقدماتی کاهش یابد تا انسان‌ها پهنای باند ذهنی بیشتری برای مسیر حیاتی (Critical Path) داشته باشند.
برای اجرای این استراتژی، با بازبینی SOW (بیانیه محدوده کار) فعلی مهاجرت خود شروع کنید تا مطمئن شوید «شکاف واژگانی» بین توقف فنی و توقف تجاری پیش از استقرار عامل‌ها پر شده است.
گفتگو