رفت‌وبرگشت میان تمرکز و عدم تمرکز در تیم‌های هوش مصنوعی را متوقف کنید

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

این رفت‌وبرگشت ثابت نمی‌کند یکی از این دو الگو غلط است؛ نشان می‌دهد هر الگو هزینه‌ی متفاوتی را به چشم می‌آورد.

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

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

خطای اول: مشکل خدمت‌رسانی را با مشکل ساختار اشتباه می‌گیریم

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

اعتراضشان به‌جاست، اما شاید تشخیص درستی نباشد.

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

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

پیش از جابه‌جایی مسئولیت، خدمت را بررسی کنید:

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

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

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

خطای دوم: هزینه‌ی دیرهنگام انتخاب را شاهد تازه‌ای می‌گیریم

فایده‌های هر مدل عملیاتی ممکن است زود نمایان شوند، اما بعضی هزینه‌هایش دیرتر خودشان را نشان می‌دهند.

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

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

بازبینی جدی باید کل وضعیت عملیاتی هر دو روش را بسنجد:

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

راهنمای عملیاتی بنیاد FinOps می‌پذیرد که کارِ مدیریت ارزش فناوری، بسته به نیاز سازمان، می‌تواند تیم مرکزی، تیم مجازی یا مدلِ مرکز و تیم‌های محلی داشته باشد. گزارش وضعیت FinOps در سال ۲۰۲۶ هم می‌گوید توانمندسازیِ متمرکز همچنان رایج است و مدلِ مرکز و تیم‌های محلی در شرکت‌های بزرگ بیشتر دیده می‌شود. این‌ها الگوهای مفیدند، نه جواب همگانی. اصل مهم‌تر چارچوب FinOps این است که حتی وقتی توانمندسازی مرکزی است، پاسخ‌گویی میان بخش‌های مختلف پخش می‌ماند.

خطای سوم: صدای بلندتر از شواهد عملیاتی جلو می‌زند

شکایت‌های سازمانی اطلاعات دارند، اما تعداد دفعات تکرارشان تشخیص قطعی نیست.

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

مدیریت وقتی شکست می‌خورد که روایتِ پرتکرار را تمام واقعیت فرض کند.

شکایت را فرضیه بگیرید و آن را به چیزی قابل‌مشاهده تبدیل کنید:

• «تیم مرکزی کند است» را به مدت‌زمان درخواست کامل تا نتیجه‌ی قابل‌استفاده بشکنید و زمان کار را از زمان انتظار جدا کنید.
• «همه دارند یک کار را تکرار می‌کنند» را با شمارش اجزا، قراردادها، ارزیابی‌ها و وقت پشتیبانیِ تکراری بسنجید.
• «استانداردها نوآوری را می‌کشند» را به تعداد استثناها، دلیل هرکدام و نتیجه‌ی آزمایش‌های تأییدشده تبدیل کنید.
• «تیم‌های محلی امن نیستند» را با کنترل‌های غایب، رخدادها، سامانه‌های بی‌مسئول یا اقدام‌های بیرون از آستانه‌ی ریسک نشان دهید.
• «سکو ما را نمی‌فهمد» را با دوباره‌کاریِ ناشی از گم شدن نیازمندی یا ناتوانی مسیر مشترک در پشتیبانی از کارِ ویژه‌ی حوزه بسنجید.

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

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

خطای چهارم: حاکمیت متمرکز است، اما پاسخ‌گویی نه

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

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

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

برای هر سامانه‌ی هوش مصنوعیِ عملیاتی این تصمیم‌ها را روشن کنید:

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

گروه مرکزی حاکمیت می‌تواند حداقل شواهد لازم و کاربردهای ممنوع را تعیین کند؛ اما از راه دور نمی‌تواند موردهای ارزیابیِ ویژه‌ی یک حوزه را بسازد. تیم محصول گردش‌کار را می‌شناسد، ولی نباید به‌تنهایی کنترل هویت را ابداع یا میزان ریسک قابل‌قبول سازمان را تعیین کند.

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

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

خطای پنجم: بازسازمان‌دهی جای نگهداریِ مستمر را می‌گیرد

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

اگر به ساختار رسیدگی نکنیم، هر الگویی به‌مرور فرسوده می‌شود.

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

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

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

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

پیش از جابه‌جایی افراد، آونگ را بررسی کنید

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

1. شکایت آغازگر را مشخص کنید. از عبارت‌هایی مثل «مدل دیگر کار نمی‌کند» پرهیز کنید. راه‌اندازیِ عقب‌افتاده، قرارداد تکراری، نقص کنترل، از دست رفتن زمینه‌ی مشتری یا تصمیم نامشخصی را پیدا کنید که مسئله را فوری کرده است.
2. سازوکار مشکل را بیابید. آیا اختیار جای نادرستی است؟ خدمت مشترک بد طراحی شده؟ ظرفیت کم است؟ رابط لازم وجود ندارد؟ انگیزه‌ها با هم تعارض دارند؟ سطح‌بندی ریسک روشن نیست؟ شاید چند مورد هم‌زمان درست باشد.
3. هزینه‌ی منتقل‌شده را بسنجید. کار را هنگام عبور از مرز تیم‌ها دنبال کنید. زمان انتظار و هماهنگی، دوباره‌کاری، ابزارهای سایه، پشتیبانی عملیاتی، هزینه‌ی فروشنده و میزان خطر را هم حساب کنید.
4. اگر شد، اول ساختار موجود را اصلاح کنید. سطح خدمت را اعلام کنید، کنترل معمول را خودکار کنید، متخصص حوزه را موقتاً به تیم بفرستید، قالب ارزیابی مشترک بسازید یا قاعده‌ی ارجاع را روشن کنید. اصلاحی کوچک می‌تواند تشخیص شما را بیازماید، بی‌آن‌که هزینه‌ی کامل بازسازمان‌دهی را تحمیل کند.
5. آستانه‌ی تغییر ساختار را تعیین کنید. مسئولیت را وقتی جابه‌جا کنید که جای فعلی، با وجود بهبود معتبر در خدمت و فرایند، پیوسته مانع نتیجه باشد؛ یا زمینه و اختیار لازم واقعاً نتوانند در محل تصمیم‌گیری کنار هم قرار بگیرند.
6. نقاط قوت الگوی فعلی را حفظ کنید. اگر کار پراکنده است، فهرست مرکزی، کنترل‌های حداقلی، داده‌ی مشترک برای پایش و پایه‌های قابل‌استفاده‌ی دوباره را نگه دارید. اگر کار متمرکز است، مشارکت مستقیم حوزه‌ها، اختیار محلیِ محدود و مسیر بازخورد کوتاه را حفظ کنید.
7. زمان بازبینی بعدی را مشخص کنید. تصمیم ابدی نیست. فایده‌ی موردانتظار، شاخص‌های کنترلی، هزینه‌ی گذار و شرط‌هایی را ثبت کنید که تغییر دوباره را توجیه خواهند کرد.

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

پیشرفت یعنی از هر دور تغییر چیزی یاد بگیریم

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

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

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

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