ادامهٔ همان جلسه
برگهٔ پیشنهاد گسترش دسترسی هنوز وسط میز بود. روی برگهٔ کناری، کلاه‌های مسئولیت و نام افراد و گروه‌های مرتبط نوشته شده بود. برای رسیدگی به پاسخ اشتباه دستیار، بالاخره تقسیم کار روشنی داشتند.
مدیر فناوری گفت: «از نظر ظرفیت، برای گروه بعدی مشکلی نداریم. دسترسی‌ها هم قابل تنظیمه.»
مدیر منابع انسانی پاسخ داد: «اما بررسی پاسخ‌های مربوط به کمک‌هزینه هنوز تموم نشده.»
مسئول ریسک و انطباق گفت: «پیشنهاد من اینه که فعلاً اون موضوع از پاسخ‌گویی خارج بشه.»
مدیرعامل به سه نفر نگاه کرد: «پس الان دسترسی رو بیشتر کنیم یا نه؟»
مدیر فناوری گفت: «حرف من آمادگی فنیه. دربارهٔ محتوای منابع انسانی، باید نظر اون واحد هم باشه.»
مدیر منابع انسانی گفت: «من هم دربارهٔ صحت پاسخ‌ها نظر می‌دم. اینکه استفاده برای گروه بزرگ‌تری مجاز باشه، باید با همین محدودیت‌ها تصمیم‌گیری بشه.»
روی کاغذ، مسئولیت‌ها تقسیم شده بود. در عمل، هرکس دربارهٔ بخش خود حرف می‌زد و هنوز معلوم نبود این نظرها چگونه باید به یک تصمیم قابل اجرا برسند.
مدیرعامل پرسید: «خوب، چه کسی باید این پیشنهاد رو جمع‌بندی کنه و اجازهٔ ادامه بده؟»
در درس دوم، چهار کلاه مسئولیت را از هم تفکیک کردیم: حامی اجرایی، مالک کسب‌وکار، مالک فنی و مالک ریسک. دیدیم که یک نفر می‌تواند چند کلاه داشته باشد و چند نفر هم می‌توانند یک کلاه را مشترکاً بر عهده بگیرند.
در ادامهٔ جلسه، پیشنهاد گسترش دسترسی هنوز روی میز مانده است. هر واحد دربارهٔ بخش خود نظر می‌دهد، اما جمع این نظرها هنوز به تصمیم منجر نشده است. اکنون باید مسئولیت‌ها را به اختیارهای مشخص وصل کنیم: چه کسی حق دارد پیشنهاد بدهد، ارزیابی کند، تصویب کند یا کار را متوقف سازد؟
این درس، قسمت دوم «مدل عملیاتی حکمرانی و حق تصمیم» است و با آن، بخش اول دوره را به پایان می‌رسانیم.
هر نقش در هر مرحله چه اختیاری دارد؟
در یک سازمان، تصمیم‌های مربوط به هوش مصنوعی معمولاً حاصل کار یک نفر یا یک واحد نیستند. برای مثال، تغییر مدل ممکن است از طرف تیم فناوری پیشنهاد شود، اما اثر آن بر کیفیت پاسخ‌های منابع انسانی را نمی‌توان صرفاً با ارزیابی فنی سنجید. واحد منابع انسانی باید بررسی کند که آیا پاسخ‌های جدید همچنان با نیازها و مقررات سازمان سازگارند؛ مسئول ریسک باید پیامدهای احتمالی تغییر را بسنجد؛ و در نهایت، مرجعی که اختیار تصویب دارد باید درباره اعمال تغییر تصمیم بگیرد.
اینجا یک تمایز مهم وجود دارد: مشارکت در یک تصمیم با داشتن اختیار تصمیم‌گیری یکسان نیست. کسی که اطلاعات یا ارزیابی تخصصی ارائه می‌کند، لزوماً حق تصویب ندارد. کسی که تصویب می‌کند، لزوماً مجری تغییر نیست. و کسی که مسئول اجرای سامانه است، الزاماً اختیار پذیرش ریسک ناشی از آن را ندارد.
برای روشن‌شدن این تفاوت، باید چهار نوع اختیار را در طول چرخه عمر سامانه از یکدیگر تفکیک کنیم:
- پیشنهاد دادن: آغاز یک تغییر یا طرح یک تصمیم. پیشنهاددهنده مسئله، دلیل تغییر، گزینه‌های موجود و پیامدهای مورد انتظار را مطرح می‌کند. برای مثال، تیم فناوری پیشنهاد می‌دهد مدل زبانی به‌روزرسانی شود تا کیفیت بازیابی یا سرعت پاسخ بهتر شود.
- ارزیابی کردن: بررسی پیشنهاد بر اساس شواهد و معیارهای مرتبط. ارزیاب باید بتواند مزایا، محدودیت‌ها و پیامدهای پیشنهاد را از منظر تخصصی خود بررسی کند. برای مثال، منابع انسانی کیفیت پاسخ‌های مربوط به آیین‌نامه‌ها را می‌سنجد و مسئول ریسک پیامدهای پاسخ اشتباه را بررسی می‌کند.
- تصویب کردن: اجازه دادن به اجرای پیشنهاد یا پذیرش یک وضعیت مشخص. تصویب‌کننده باید اختیار سازمانی لازم را داشته باشد و مسئولیت تصمیم خود را بپذیرد. تأیید یک ارزیاب تخصصی به‌تنهایی جایگزین این تصویب نیست.
- متوقف کردن: جلوگیری از ادامه یک فعالیت، محدودسازی موقت یا تعلیق یک قابلیت در شرایطی که ادامه آن می‌تواند پیامد نامطلوبی داشته باشد. این اختیار باید از پیش تعریف شده باشد؛ از جمله اینکه چه کسی می‌تواند توقف را درخواست کند، چه کسی مجاز به اعمال فوری آن است و بازگشایی به تأیید چه مرجعی نیاز دارد.
این چهار اختیار الزاماً به چهار فرد یا واحد متفاوت تعلق ندارند. ممکن است یک نفر در یک تصمیم پیشنهاددهنده و در تصمیم دیگری تصویب‌کننده باشد. همچنین ممکن است ارزیابی یک پیشنهاد به چند واحد سپرده شود. نکته این است که سازمان باید برای هر تصمیم مشخص کند چه کسی چه نقشی دارد و حدود اختیار هر نقش کجاست.
این تقسیم اختیار در مراحل مختلف چگونه عمل می‌کند؟
نقشهٔ حق تصمیم فقط برای زمان بهره‌برداری نیست. از لحظه‌ای که سازمان مسئله‌ای را برای استفاده از هوش مصنوعی انتخاب می‌کند تا زمانی که سامانه تغییر می‌کند، محدود می‌شود یا کنار گذاشته می‌شود، تصمیم‌های متعددی باید گرفته شوند. برای فهم بهتر، پروندهٔ دستیار سازمانی خودمان را در نظر بگیریم.
۱. انتخاب مسئله و تعیین دامنهٔ استفاده
فرض کنیم منابع انسانی پیشنهاد می‌کند دستیار هوش مصنوعی به پرسش‌های پرتکرار کارکنان درباره آیین‌نامه‌ها پاسخ دهد.
- منابع انسانی می‌تواند پیشنهاددهنده باشد و توضیح دهد کدام پرسش‌ها پرتکرارند، چه مشکلی را باید حل کرد و پاسخ معتبر از نظر آن واحد چیست.
- تیم فناوری امکان‌پذیری فنی، منابع مورد نیاز و محدودیت‌های معماری را ارزیابی می‌کند.
- مسئول ریسک، پیامدهای احتمالی پاسخ اشتباه، دامنه اطلاعات قابل دسترسی و مواردی را که باید به کارشناس ارجاع شوند بررسی می‌کند.
- مرجع دارای اختیار، پس از بررسی این شواهد، دامنه آزمایش را تصویب می‌کند؛ مثلاً استفاده برای گروهی محدود از کارکنان، با اتکا به اسناد عمومی و معتبر و بدون دسترسی به پرونده‌های شخصی.
- اگر در بررسی اولیه مشخص شود که کاربرد پیشنهادی با ریسک غیرقابل‌قبولی همراه است، مرجع تعیین‌شده باید بتواند از آغاز آن جلوگیری کند.
در این مرحله، منابع انسانی درباره نیاز کسب‌وکار نظر تخصصی می‌دهد، اما نمی‌تواند به‌تنهایی امکان‌پذیری فنی را تأیید کند. تیم فناوری نیز می‌تواند بگوید ساخت سامانه ممکن است، اما این به معنای تصویب استفاده از آن نیست.
۲. انتخاب فناوری، مدل و تأمین‌کننده
پس از تصویب دامنه، نوبت به انتخاب مدل، زیرساخت، ابزارها و احتمالاً پیمانکار می‌رسد.
- تیم فناوری گزینه‌های فنی را پیشنهاد می‌کند و درباره معماری، هزینه، ظرفیت، امنیت فنی و امکان نگهداری آن‌ها ارزیابی ارائه می‌دهد.
- مالک کسب‌وکار بررسی می‌کند که گزینه انتخابی واقعاً نیاز کاربران را پوشش می‌دهد و محدودیت‌های آن با جریان کاری سازمان سازگار است.
- مسئول ریسک و متولی امنیت، شرایط نگهداری داده، دسترسی تأمین‌کننده، امکان انتقال اطلاعات، وابستگی به ارائه‌دهنده و پیامدهای خروج از قرارداد را بررسی می‌کنند.
- مرجع دارای اختیار، گزینه نهایی را با توجه به ارزیابی‌ها، بودجه و سطح ریسک قابل‌پذیرش تصویب می‌کند.
- اگر بررسی‌ها نشان دهد تأمین‌کننده یا معماری پیشنهادی الزامات ضروری سازمان را برآورده نمی‌کند، باید امکان رد پیشنهاد یا توقف فرایند انتخاب وجود داشته باشد.
برای مثال، ممکن است یک مدل از نظر کیفیت پاسخ بهترین گزینه باشد، اما داده‌های سازمان را به یک سرویس خارجی ارسال کند. تیم فناوری می‌تواند کیفیت و عملکرد آن را تأیید کند؛ اما پذیرش پیامدهای محرمانگی و حقوقی این انتخاب باید از مسیر اختیارهای مربوط به ریسک و حاکمیت داده انجام شود.
۳. ارزیابی پایلوت و اجازهٔ ورود به بهره‌برداری
در این مرحله، سامانه ساخته شده و آزمایش محدود انجام شده است. پرسش دیگر صرفاً این نیست که آیا سامانه کار می‌کند؛ باید معلوم شود آیا شواهد کافی برای استفاده واقعی وجود دارد یا خیر.
- تیم فناوری نتایج آزمون‌های فنی، پایداری، دسترس‌پذیری، امنیت و عملکرد را ارائه می‌کند.
- مالک کسب‌وکار بررسی می‌کند که پاسخ‌ها برای کاربران مفیدند، نیازهای واقعی را پوشش می‌دهند و در جریان کار قابل استفاده‌اند.
- مسئول ریسک، خطاهای مهم، موارد پاسخ‌گویی نامطمئن، احتمال آسیب و کفایت کنترل‌ها را ارزیابی می‌کند.
- در صورت نیاز، ارزیاب مستقل یا واحدی خارج از تیم اجرا می‌تواند شواهد را بازبینی کند؛ به‌خصوص وقتی مجری پروژه هم‌زمان مسئول ارزیابی موفقیت آن است.
- مرجع تصویب‌کننده بر اساس مجموع این شواهد درباره ادامه آزمایش، اصلاح، محدودسازی یا ورود به بهره‌برداری تصمیم می‌گیرد.
فرض کنیم تیم فناوری اعلام کند دستیار در ۹۵ درصد آزمون‌ها پاسخ فنی قابل قبولی تولید کرده است. این عدد به‌تنهایی برای تصویب بهره‌برداری کافی نیست. باید پرسید آن ۵ درصد باقیمانده چه نوع خطاهایی دارند؟ آیا پاسخ اشتباه ممکن است کارمند را به اقدام نادرست سوق دهد؟ آیا سامانه در موارد نامطمئن از پاسخ‌دادن خودداری می‌کند؟ آیا کاربر راهی برای ارجاع پرسش به مرجع انسانی دارد؟
در نتیجه، تأیید فنی، تأیید کیفیت خدمت و تصویب بهره‌برداری سه موضوع مرتبط اما متمایزند.
۴. گسترش دسترسی و تغییر دامنهٔ استفاده
فرض کنیم پایلوت موفق بوده و مدیرعامل می‌خواهد دسترسی به دستیار از یک واحد به تمام کارکنان گسترش پیدا کند.
این تغییر ممکن است در نگاه اول صرفاً افزایش تعداد کاربران به نظر برسد، اما در عمل می‌تواند بار زیرساختی، دامنه اثر خطا، نیازهای پشتیبانی و حتی نوع اطلاعاتی را که کاربران وارد سامانه می‌کنند تغییر دهد.
- مالک کسب‌وکار می‌تواند گسترش استفاده را پیشنهاد کند و شواهد مربوط به تقاضا و منفعت آن را ارائه دهد.
- تیم فناوری ظرفیت زیرساخت، کنترل دسترسی، امنیت و آمادگی عملیاتی را ارزیابی می‌کند.
- منابع انسانی یا واحدهای بهره‌بردار، کیفیت پاسخ‌ها را در گروه‌های جدید و متناسب با نیازهای آن‌ها بررسی می‌کنند.
- مسئول ریسک، تغییر در دامنه مواجهه با ریسک و کفایت کنترل‌های قبلی را می‌سنجد.
- مرجع تصویب‌کننده درباره گسترش دسترسی تصمیم می‌گیرد؛ ممکن است تصویب مرحله‌ای را به جای گسترش یکباره انتخاب کند.
برای مثال، اگر دستیار ابتدا فقط به پرسش‌های عمومی کارکنان پاسخ می‌داده، اضافه‌شدن امکان پاسخ‌گویی درباره وضعیت فردی مرخصی یا مزایا یک تغییر ساده در دسترسی نیست. این تغییر، دامنه داده، مسئولیت پاسخ و سطح ریسک را عوض می‌کند و باید به‌عنوان تصمیمی مستقل ارزیابی شود.
۵. تغییر مدل، منابع و رفتار سامانه در زمان بهره‌برداری
حتی پس از آغاز بهره‌برداری، سامانه ثابت نمی‌ماند. مدل به‌روزرسانی می‌شود، اسناد تغییر می‌کنند، منابع جدید اضافه می‌شوند و گاهی تنظیمات بازیابی یا دستورالعمل‌های پاسخ‌گویی تغییر می‌کنند.
نباید برای تمام این تغییرها یک فرایند تصویب سنگین و یکسان تعریف کرد. تغییر جزئی در قالب نمایش پاسخ با تغییر مدل اصلی یا اضافه‌شدن منبعی که مبنای تصمیم‌های کارکنان است، پیامد یکسانی ندارد.
سازمان می‌تواند تغییرها را بر اساس اثر و ریسک آن‌ها طبقه‌بندی کند:
- تغییرهای کم‌اثر و از پیش تعریف‌شده، مانند اصلاح ظاهری رابط، ممکن است در حدود اختیار تیم فنی انجام شوند.
- تغییر در منابع محتوایی باید با تأیید متولی همان محتوا و کنترل نسخه انجام شود.
- تغییر مدل یا تنظیمات مؤثر بر رفتار پاسخ‌گویی باید از ارزیابی فنی و کسب‌وکاری عبور کند.
- تغییر در دامنه کاربرد، نوع داده یا سطح اختیار سامانه ممکن است به ارزیابی ریسک و تصویب مجدد نیاز داشته باشد.
برای نمونه، اگر منابع انسانی نسخه جدید آیین‌نامه کمک‌هزینه را منتشر کند، تیم فناوری می‌تواند مسئول به‌روزرسانی منبع در سامانه باشد، اما تشخیص اینکه نسخه جدید معتبر است و جایگزین نسخه قبلی شده، باید به متولی محتوای مربوط وابسته باشد. همچنین اگر تغییر مدل باعث شود پاسخ‌ها با اطمینان بیشتری اما با دقت کمتر تولید شوند، بررسی این تغییر فقط در اختیار تیم فنی نیست.
۶. مواجهه با خطا، محدودسازی و بازگشایی خدمت
این مرحله جایی است که نبود نقشه حق تصمیم می‌تواند به اختلاف جدی میان واحدها منجر شود.
فرض کنیم دستیار به کارمندی درباره شرایط دریافت کمک‌هزینه آموزشی پاسخ مثبت داده، اما منابع انسانی اعلام کرده است که آن پاسخ با شرایط واقعی آیین‌نامه سازگار نیست. در این وضعیت چند تصمیم متفاوت وجود دارد:
- چه کسی خطا را گزارش و مستند می‌کند؟
- چه کسی بررسی می‌کند که منشأ خطا، سند نامعتبر، بازیابی نادرست، رفتار مدل یا طراحی نامناسب فرایند بوده است؟
- چه کسی درباره اصلاح منبع یا سامانه اقدام می‌کند؟
- آیا لازم است قابلیت پاسخ‌گویی به این دسته از پرسش‌ها موقتاً محدود شود؟
- چه کسی اجازه می‌دهد خدمت پس از اصلاح دوباره فعال شود؟
این تصمیم‌ها نباید در یک عنوان کلی مانند «مسئولیت با واحد فناوری است» ادغام شوند.
برای مثال، منابع انسانی می‌تواند خطای محتوایی را گزارش کند و اعتبار پاسخ را بررسی کند. تیم فناوری می‌تواند منشأ فنی خطا را پیدا کند و اصلاح لازم را انجام دهد. مسئول ریسک می‌تواند شدت پیامد را ارزیابی و محدودسازی موقت را درخواست کند. اما اگر خطا جدی باشد، سازمان باید از پیش مشخص کرده باشد چه فرد یا مرجعی اختیار اعمال فوری توقف را دارد؛ نه اینکه در زمان وقوع حادثه تازه درباره این اختیار مذاکره کند.
همچنین بازگشایی خدمت لزوماً با انجام اصلاح فنی مجاز نمی‌شود. ممکن است اصلاح انجام شده باشد، اما هنوز شواهد کافی از رفع خطا وجود نداشته باشد. بنابراین باید مشخص شود چه کسی اصلاح را ارزیابی می‌کند و چه مرجعی اجازه بازگشت به بهره‌برداری را صادر می‌کند.
۷. خروج از خدمت و کنارگذاری سامانه
چرخه عمر سامانه با بهره‌برداری پایان نمی‌یابد. گاهی راهکار دیگر پاسخ‌گوی نیاز سازمان نیست، تأمین‌کننده خدمات خود را متوقف می‌کند، ریسک آن بیش از منفعتش می‌شود یا جایگزین مناسب‌تری در دسترس قرار می‌گیرد.
در این مرحله نیز باید مشخص باشد چه کسی خروج از خدمت را پیشنهاد می‌کند، چه کسی اثر آن بر کاربران و فرایندها را می‌سنجد، چه مرجعی آن را تصویب می‌کند و چه کسی مسئول اجرای خروج است. حذف دسترسی‌ها، تعیین تکلیف داده‌ها و سوابق، انتقال فرایندهای وابسته و اطلاع‌رسانی به کاربران از جمله اقداماتی هستند که باید برای آن‌ها مسئول مشخص وجود داشته باشد.
یک تصمیم، چند مشارکت‌کننده؛ اما نه چند صاحب اختیار نهایی
آنچه در مثال‌های بالا اهمیت دارد، صرفاً فهرست‌کردن نقش‌ها نیست. باید بین چهار نوع مشارکت تمایز قائل شویم:
- پیشنهاددهنده مسئله یا تغییر را مطرح می‌کند؛ اما الزاماً حق اجرای آن را ندارد.
- ارزیاب شواهد و نظر تخصصی ارائه می‌دهد؛ اما ارزیابی مثبت او به‌تنهایی مجوز اجرا نیست.
- تصویب‌کننده تصمیم نهایی را در محدوده اختیار تفویض‌شده می‌گیرد و باید بتواند مبنای تصمیم خود را توضیح دهد.
- متوقف‌کننده باید بتواند در شرایط تعریف‌شده از ادامه فعالیت جلوگیری کند؛ حتی اگر پیشنهاددهنده یا تصویب‌کننده با توقف موافق نباشند.
ممکن است در یک تصمیم، چند ارزیاب از واحدهای مختلف مشارکت کنند. برای مثال، تغییر مدل از نظر فنی، کیفیت پاسخ، امنیت و ریسک بررسی شود. اما باید معلوم باشد آیا همه این ارزیابی‌ها شرط لازم برای تصویب‌اند یا برخی صرفاً نظر مشورتی محسوب می‌شوند. اگر یکی از ارزیابان با تغییر مخالفت کند، آیا تصمیم متوقف می‌شود یا مرجع تصویب‌کننده می‌تواند با ثبت دلیل و پذیرش مسئولیت، آن را بپذیرد؟
این پرسش‌ها را نمی‌توان با تعیین عنوان‌هایی مانند مالک کسب‌وکار، مالک فنی یا مالک ریسک به‌تنهایی پاسخ داد. این عنوان‌ها حوزه مسئولیت را روشن می‌کنند؛ اما حق تصمیم باید جداگانه و برای هر نوع تصمیم تعریف شود.
حق توقف؛ اختیاری که نباید فقط روی کاغذ وجود داشته باشد
در میان چهار اختیار، حق توقف اهمیت ویژه‌ای دارد؛ زیرا ممکن است لازم باشد در شرایط اضطراری، ادامه فعالیت پیش از تکمیل فرایند معمول تصویب متوقف شود.
برای مثال، اگر دستیار به‌طور گسترده اطلاعات محرمانه را در پاسخ‌ها افشا کند، سازمان نباید منتظر تشکیل جلسه بعدی کمیته یا تأیید مدیرعامل بماند. باید از قبل مشخص باشد چه کسی می‌تواند قابلیت آسیب‌دیده را فوراً محدود کند، چه کسی مسئول اجرای این محدودسازی است و چه مرجعی درباره ادامه توقف یا بازگشایی تصمیم می‌گیرد.
در اینجا سه اختیار را باید از هم جدا کرد:
۱. درخواست توقف: هر فرد یا واحدی که نشانه‌ای معتبر از خطر مشاهده می‌کند، باید بتواند موضوع را گزارش کند و توقف را درخواست دهد.
۲. اعمال توقف: افراد مشخصی باید اختیار عملیاتی لازم برای غیرفعال‌کردن یک قابلیت، محدودکردن دسترسی یا تعلیق خدمت را داشته باشند. در موارد اضطراری، این اختیار می‌تواند پیش از تصویب نهایی اعمال شود.
۳. تصمیم درباره بازگشایی: بازگشت به وضعیت عادی باید پس از بررسی شواهد اصلاح، ارزیابی مجدد ریسک و تأیید مرجع دارای اختیار انجام شود.
این اختیارات ممکن است در سازمان‌های مختلف متفاوت توزیع شوند. برای مثال، مسئول ریسک می‌تواند اختیار درخواست توقف داشته باشد، تیم فناوری آن را اجرا کند و بازگشایی به تصویب مرجع مشخصی نیاز داشته باشد. در سازمانی دیگر ممکن است مسئول امنیت در محدوده‌ای از پیش تعیین‌شده اختیار توقف فوری داشته باشد. آنچه ضروری است، روشن‌بودن دامنه اختیار و امکان اجرای واقعی آن است.
داشتن عنوان «مالک ریسک» به‌خودی‌خود به معنای داشتن حق توقف نیست. این حق باید صریحاً در سازوکار اختیارات سازمان تعریف و ابلاغ شده باشد.
نقشه حق تصمیم را چگونه مستند کنیم؟
برای هر تصمیم مهم در چرخه عمر، بهتر است یک جدول یا ماتریس مشخص وجود داشته باشد که دست‌کم این موارد را ثبت کند:
- موضوع تصمیم و دامنه آن؛
- پیشنهاددهنده یا واحد آغازکننده؛
- ارزیابان لازم و شواهدی که باید ارائه کنند؛
- مرجع تصویب و حدود اختیار او؛
- فرد یا واحد دارای اختیار توقف؛
- مسئول اجرای تصمیم و ثبت نتیجه؛
- شرایط بازبینی، تجدید ارزیابی یا بازگشایی.
برای مثال، در تصمیم «گسترش دسترسی دستیار به تمام کارکنان» می‌توان منابع انسانی را پیشنهاددهنده، فناوری را ارزیاب آمادگی فنی، منابع انسانی و کاربران آزمایشی را ارزیاب کیفیت خدمت، مسئول ریسک را ارزیاب پیامدها و مدیر اجرایی دارای اختیار را تصویب‌کننده تعیین کرد. در کنار آن باید مشخص شود چه کسی در صورت مشاهده خطای جدی می‌تواند دسترسی را موقتاً محدود کند و بازگشایی به چه تأییدی نیاز دارد.
این ماتریس نباید صرفاً فهرستی از نام افراد باشد. ممکن است افراد تغییر کنند یا چند نقش در یک نفر تجمیع شوند؛ آنچه باید پایدار بماند، حدود اختیار، مسئولیت و مسیر پاسخ‌گویی است. همچنین تصمیم‌های مهم باید همراه با شواهد، نظرهای مخالف، دلیل تصویب یا رد و نام مرجع تصمیم‌گیر ثبت شوند. این ثبت، هم امکان بازبینی بعدی را فراهم می‌کند و هم مانع از آن می‌شود که در زمان بروز مشکل، هر واحد مسئولیت را به واحد دیگری ارجاع دهد.
اینکه ناظر چه شواهدی باید مطالبه کند و چه حقی برای آزمون مستقل و درخواست اصلاح داشته باشد، موضوعی جداگانه است. در مقالهٔ برای حکمرانی هوش مصنوعی، آیا باید کد منبع را ببینیم؟ این موضوع را با تفکیک حق ممیزی از مالکیت فناوری بررسی کرده‌ام.
مدیرعامل گفت: «پس پیشنهاد افزایش دسترسی رو با شرایطش بنویسید. فنی بگه چه چیزی آماده است، منابع انسانی نتیجه بررسی پاسخ‌ها رو بده و ریسک هم محدودیت‌های لازم رو مشخص کنه.»
مدیر فناوری پرسید: «تصویب این مرحله با شماست؟»
مدیرعامل پاسخ داد: «برای این گسترش مشخص، بله. اما قرار نیست برای هر اصلاح جزئی همین مسیر رو طی کنیم. حدود اختیار تغییرهای معمول رو هم مشخص کنیم.»
مسئول ریسک و انطباق گفت: «و تکلیف محدودسازی موقت و بازگشایی خدمت هم باید روشن باشه. اگر فردا خطای جدی دیدیم، نباید تازه دنبال این بگردیم که چه کسی اجازه توقف داره.»
این بار، کنار نام نقش‌ها، نوع تصمیم و حدود اختیار هرکدام هم نوشته شد.
آنچه سازمان نیاز داشت صرفاً تعیین مسئول برای هر واحد نبود؛ بلکه نقشهای بود که نشان دهد در هر مرحله چه کسی می‌تواند پیشنهاد بدهد، چه کسی باید شواهد را بررسی کند، چه کسی اجازه اجرا می‌دهد و در شرایط خطر چه کسی می‌تواند جلوی ادامه کار را بگیرد.
سؤال بعدی دیگر فقط این نیست که چه کسی مسئول است؛ بلکه این است که هر تصمیم بر اساس چه شواهدی گرفته می‌شود و چگونه می‌توان از درستی آن اطمینان پیدا کرد؟
چه چیزی باید به سطح بالاتر برگردد؟
در طراحی حکمرانی، فقط نام صاحب تصمیم را تعیین نمی‌کنیم؛ حدود تصمیم‌های واگذارشده و شرایط ارجاع دوباره را هم مشخص می‌کنیم. مرجع حاکم، جهت و حدود را تعیین می‌کند، مدیریت در آن حدود تصمیم می‌گیرد و اجرا فعالیت‌های مجاز را انجام می‌دهد. این مرجع، بسته به ساختار سازمان و اهمیت موضوع، می‌تواند هیئت‌مدیره یا مرجع دارای اختیار دیگری باشد.
| سطح | نمونهٔ مسئولیت در این پرونده |
|---|---|
| مرجع حاکم | تعیین حدود تحمل ریسک، اصول استفاده، سقف اختیارات و شیوهٔ گزارش‌دهی |
| مدیریت | انتخاب و اولویت‌بندی کاربرد، تخصیص منابع در حدود اختیار و پذیرش استفادهٔ مشخص |
| اجرا | نگهداری منابع، اعمال دسترسی، اجرای آزمون و رسیدگی طبق رویهٔ مصوب |
در مثال این درس، اصلاح یک سند در دامنهٔ پذیرفته‌شده، با تأیید مسئول محتوا و طی کنترل تغییر انجام می‌شود. افزودن پرونده‌های شخصی کارکنان یا اختیار رد خودکار درخواست، تغییر دامنه است و به تصمیم تازهٔ مرجع دارای اختیار نیاز دارد.
ارجاع به سطح بالاتر زمانی لازم می‌شود که تصمیم از حدود تفویض‌شده خارج شود، ریسک باقیمانده از حد پذیرفته‌شده عبور کند، منابع بیشتری از سقف مصوب بخواهد یا اختلافی ایجاد کند که در سطح جاری قابل حل نیست. این‌ها قواعد این مثال‌اند؛ سازمان باید مصداق و مرجع هرکدام را در نقشهٔ تصمیم خود ثبت کند.
بنابراین، هیئت‌مدیره لازم نیست هر تغییر جزئی دستیار را تصویب کند. مسئولیت آن در کاربردهای متناسب، می‌تواند تعیین چارچوب و مطالبهٔ شواهد دربارهٔ عملکرد همان چارچوب باشد.
Weill & Ross — IT Governance on One Page
اختیار در مرکز بماند یا در واحدها توزیع شود
پس از مشخص‌کردن اینکه چه کسی در هر مرحله حق پیشنهاد، ارزیابی، تصویب یا توقف دارد، پرسش دیگری مطرح می‌شود: این اختیارها باید در کجای سازمان قرار بگیرند؟
فرض کنیم منابع انسانی برای پاسخ‌گویی به پرسش‌های کارکنان از هوش مصنوعی استفاده می‌کند. آیا این واحد باید برای انتخاب هر ابزار، تغییر هر منبع اطلاعاتی و اصلاح هر قابلیت، از یک مرجع مرکزی مجوز بگیرد؟ یا می‌تواند مستقلاً درباره راهکار خود تصمیم بگیرد؟ اگر واحد مالی، فناوری اطلاعات و چند واحد دیگر نیز راهکارهای مشابهی داشته باشند، چه کسی مسئول هماهنگی، امنیت، استانداردها و جلوگیری از دوباره‌کاری خواهد بود؟
این مسئله فقط درباره سرعت تصمیم‌گیری نیست. محل استقرار اختیار، بر هزینه‌ها، کیفیت کنترل‌ها، امکان استفاده مجدد از قابلیت‌ها، استقلال واحدها و در نهایت پاسخ‌گویی سازمان اثر می‌گذارد.
اگر تمام تصمیم‌ها به مرکز ارجاع شوند، ممکن است کارها پشت صف تأیید بمانند و تصمیم‌گیرندگان از جزئیات نیازهای عملیاتی واحدها فاصله بگیرند. از سوی دیگر، اگر هر واحد همه‌چیز را مستقل تعیین کند، سازمان ممکن است با چندین سکوی ناسازگار، قراردادهای تکراری، استانداردهای امنیتی متفاوت و راهکارهایی روبه‌رو شود که امکان نظارت و پشتیبانی مشترک ندارند.
برای تنظیم این نسبت، سه الگوی اصلی را می‌توان در نظر گرفت: متمرکز، فدرال و توزیع‌شده.
۱. مدل متمرکز: تصمیم‌گیری و قابلیت‌های مشترک در مرکز
در مدل متمرکز، بخش عمده‌ای از سیاست‌گذاری، تعیین استانداردها، انتخاب فناوری‌های مجاز، مدیریت زیرساخت و تصویب تصمیم‌های کلیدی در یک مرجع مرکزی قرار می‌گیرد. واحدهای سازمانی نیازها و پیشنهادهای خود را مطرح می‌کنند، اما بخش مهمی از تصمیم‌ها و اجرا از مسیر مرکز عبور می‌کند.
برای مثال، سازمان ممکن است یک سکوی مشترک هوش مصنوعی، یک مخزن دانش سازمانی، قراردادهای یکپارچه با تأمین‌کنندگان و سیاست‌های واحد برای دسترسی به داده‌ها داشته باشد. واحد منابع انسانی می‌تواند نیاز خود را برای ساخت دستیار مطرح کند، اما انتخاب مدل، تأمین زیرساخت و تعیین الزامات امنیتی در مرکز انجام شود.
مزیت اصلی این مدل، هماهنگی و امکان اعمال کنترل‌های مشترک است. سازمان می‌تواند هزینه‌های زیرساخت را تجمیع کند، از خریدهای تکراری جلوگیری کند، استانداردهای امنیتی یکسانی داشته باشد و تصویر نسبتاً جامعی از کاربردهای هوش مصنوعی به دست آورد.
اما تمرکز بیش از حد سه مشکل ایجاد می‌کند:
- گلوگاه تصمیم‌گیری: درخواست‌های متعدد واحدها برای بررسی و تصویب به مرکز ارجاع می‌شوند و سرعت پاسخ‌گویی کاهش می‌یابد.
- فاصله از مسئلهٔ عملیاتی: تیم مرکزی ممکن است شناخت کافی از جزئیات فرایندهای منابع انسانی، مالی، فروش یا تولید نداشته باشد.
- تبدیل مرکز به مجری همه‌چیز: به‌جای فراهم‌کردن قابلیت‌ها و قواعد مشترک، مرکز مسئول اجرای تمام پروژه‌ها می‌شود و ظرفیت آن به‌سرعت محدود خواهد شد.
این مدل در سازمان‌هایی که اندازه کوچک‌تری دارند، کاربردهای محدودتری دارند یا به دلیل حساسیت داده و الزامات نظارتی به کنترل یکپارچه نیازمندند، می‌تواند انتخاب مناسبی باشد. بااین‌حال، حتی در یک مدل متمرکز هم مالکیت مسئله و مسئولیت نتایج کسب‌وکاری نباید از واحد متقاضی گرفته شود.
۲. مدل فدرال: قواعد مشترک، اختیار عملیاتی در واحدها
مدل فدرال تلاش می‌کند مزیت هماهنگی مرکزی را با شناخت و اختیار محلی ترکیب کند. در این مدل، مرکز چارچوب‌ها، استانداردها، زیرساخت‌ها و قابلیت‌های مشترک را فراهم می‌کند، اما واحدهای کسب‌وکار در محدودهٔ مشخصی درباره کاربردها، اولویت‌ها و نحوه استفاده از این قابلیت‌ها تصمیم می‌گیرند.
برای مثال، سازمان می‌تواند یک سکوی مشترک برای دسترسی به مدل‌های هوش مصنوعی، سیاست یکپارچه مدیریت دسترسی، چارچوب ارزیابی ریسک و قراردادهای پایه داشته باشد. در مقابل، منابع انسانی مسئول انتخاب و اعتبارسنجی اسناد مربوط به آیین‌نامه‌های کارکنان باشد؛ واحد مالی منابع معتبر خود را اداره کند و هر واحد درباره طراحی فرایندهای اختصاصی خود تصمیم بگیرد.
در این مدل، مرکز صرفاً یک مرجع تصویب‌کننده نیست؛ نقش مهم آن ایجاد توانمندی مشترک، تعریف مرزهای اختیار، ارائه ابزارهای استاندارد و نظارت بر رعایت الزامات سازمانی است. واحدها نیز صرفاً مصرف‌کننده خدمات مرکز نیستند؛ آن‌ها در محدودهٔ اختیارات خود مسئول انتخاب، اجرا و اداره کاربردهای هوش مصنوعی هستند.
مزیت اصلی مدل فدرال، ترکیب استانداردسازی با تناسب محلی است. واحدها برای هر تصمیم عملیاتی منتظر مرکز نمی‌مانند، اما در عین حال می‌توانند از زیرساخت، دانش، قراردادها و کنترل‌های مشترک استفاده کنند.
این مدل البته بدون تعریف دقیق مرزها می‌تواند به تعارض منجر شود:
- مرکز ممکن است تصمیم‌های واحدها را بیش از حد محدود کند یا در جزئیات اجرایی آن‌ها دخالت کند.
- واحدها ممکن است تغییرهایی را در پوشش اختیار محلی انجام دهند که بر امنیت، هزینه یا سایر واحدها اثر بگذارد.
- مسئولیت یک موضوع ممکن است میان مرکز و واحدها مبهم شود؛ مثلاً مرکز سکوی مشترک را اداره کند، اما هیچ‌کس مسئول کیفیت منابع محتوایی مورد استفاده در آن نباشد.
بنابراین مدل فدرال به یک نظام روشن تفویض اختیار نیاز دارد. باید مشخص باشد چه تصمیم‌هایی در سطح سازمان مشترک‌اند، چه تصمیم‌هایی در اختیار واحدها قرار دارند و در چه شرایطی یک تغییر محلی باید دوباره در سطح مرکزی بررسی شود.
این مدل به‌ویژه برای سازمان‌های بزرگ و چندبخشی که کاربردهای متنوع دارند، اما همچنان به استانداردها و قابلیت‌های مشترک نیازمندند، مناسب است.
۳. مدل توزیع‌شده: اختیار گسترده در واحدها
در مدل توزیع‌شده، واحدها استقلال بیشتری در انتخاب فناوری، طراحی راهکار، اجرای پروژه و اداره کاربردهای خود دارند. هر واحد متناسب با نیاز و ظرفیت تخصصی خود تصمیم می‌گیرد و لزوماً از یک سکوی اجرایی یا فرایند تصویب مرکزی استفاده نمی‌کند.
برای مثال، واحد فروش ممکن است دستیار تحلیل مکالمات مشتریان را توسعه دهد، واحد مالی از یک راهکار تحلیل اسناد استفاده کند و منابع انسانی سامانه‌ای برای پاسخ به پرسش‌های کارکنان راه‌اندازی کند. هر واحد می‌تواند تیم، پیمانکار و زیرساخت مورد نیاز خود را انتخاب کند.
مزیت اصلی این مدل، سرعت و نزدیکی تصمیم به مسئله است. واحدی که نیاز را بهتر می‌شناسد، می‌تواند بدون طی‌کردن مسیرهای طولانی اداری راهکار مناسب را انتخاب و اصلاح کند. همچنین مسئولیت نتایج کاربرد به واحدی نزدیک می‌ماند که از آن استفاده می‌کند.
اما استقلال گسترده، هزینه‌ها و ریسک‌های خاص خود را دارد:
- چند واحد ممکن است برای حل مسئله‌های مشابه، راهکارهای جداگانه بسازند و هزینه‌های تکراری ایجاد کنند.
- داده‌ها، قراردادها، مدل‌ها و کنترل‌های امنیتی ممکن است بدون هماهنگی توسعه پیدا کنند.
- سازمان ممکن است دید جامعی از محل استفاده از هوش مصنوعی، میزان وابستگی به تأمین‌کنندگان یا ریسک‌های انباشته نداشته باشد.
- در صورت خروج یک پیمانکار یا تغییر فناوری، پشتیبانی و نگهداری هر راهکار به مسئله‌ای مستقل تبدیل می‌شود.
مدل توزیع‌شده الزاماً به معنای نبود سیاست سازمانی نیست. حتی اگر واحدها در انتخاب و اجرای راهکار مستقل باشند، سازمان همچنان باید حداقل الزامات مشترک خود را درباره امنیت، محرمانگی، نگهداری داده، خرید و قرارداد، ثبت کاربردها و پاسخ‌گویی مشخص کند. تفاوت اینجاست که اجرای این الزامات و بسیاری از تصمیم‌های عملیاتی به خود واحدها سپرده می‌شود.
این مدل در سازمان‌هایی با واحدهای نسبتاً مستقل، تخصص‌های بالغ و قابلیت‌های فنی و مدیریتی قوی قابل استفاده است. در غیر این صورت، استقلال واحدها ممکن است به‌جای چابکی، پراکندگی و افزایش هزینه ایجاد کند.
سه مدل، سه پاسخ متفاوت به مسئلهٔ توزیع اختیار
| موضوع | متمرکز | فدرال | توزیع‌شده |
|---|---|---|---|
| سیاست‌ها و استانداردهای مشترک | عمدتاً در مرکز | در مرکز، با مشارکت واحدها | چارچوب مشترک با اجرای محلی |
| انتخاب فناوری و زیرساخت | عمدتاً مرکزی | ترکیبی؛ سکوی مشترک و انتخاب‌های محلی در محدوده مجاز | عمدتاً در واحدها |
| اولویت‌بندی کاربردها | با هماهنگی و تصویب مرکز | در واحدها، با هم‌راستایی سازمانی | عمدتاً در واحدها |
| تأمین و توسعه راهکار | تیم یا پیمانکار مرکزی | ترکیبی از قابلیت مرکزی و تیم‌های واحدی | عمدتاً در واحدها |
| ارزیابی ریسک | چارچوب و نظارت مرکزی | چارچوب مرکزی و ارزیابی محلی | مسئولیت اجرایی محلی تحت الزامات مشترک |
| اداره و پشتیبانی | عمدتاً مرکزی | تقسیم‌شده بر اساس نوع خدمت | عمدتاً محلی |
| هماهنگی و نظارت سازمانی | ساده‌تر، با خطر گلوگاه | نیازمند سازوکار هماهنگی روشن | دشوارتر و نیازمند شفافیت و گزارش‌دهی قوی |
این جدول یک الگوی مفهومی است، نه توصیف الزام‌آور ساختار همه سازمان‌ها. در عمل، ممکن است یک سازمان در بعضی حوزه‌ها متمرکز و در حوزه‌های دیگر فدرال یا توزیع‌شده عمل کند.
چرا انتخاب یک مدل واحد برای همه تصمیم‌ها اشتباه است؟
یکی از خطاهای رایج این است که سازمان تصور کند باید یک‌بار برای همیشه یکی از سه مدل را انتخاب کند و همه تصمیم‌های هوش مصنوعی را بر همان اساس پیش ببرد. درحالی‌که محل مناسب اختیار به ماهیت تصمیم، گستره اثر آن، حساسیت داده و توانمندی واحد مربوط بستگی دارد.
برای مثال، در پرونده دستیار سازمانی می‌توان چنین ترکیبی را در نظر گرفت:
- سیاست محرمانگی، امنیت و دسترسی: در سطح سازمان تعیین شود؛ زیرا تصمیم یک واحد می‌تواند بر داده‌ها و امنیت کل سازمان اثر بگذارد.
- انتخاب و به‌روزرسانی اسناد منابع انسانی: به خود واحد منابع انسانی سپرده شود؛ زیرا این واحد مرجع اعتبار محتوای مربوط به کارکنان است.
- زیرساخت، مدیریت مدل‌ها و قابلیت‌های مشترک: در اختیار تیم مرکزی فناوری باشد تا از دوباره‌کاری و پراکندگی فنی جلوگیری شود.
- ارزیابی کیفیت پاسخ‌ها: با مشارکت واحد بهره‌بردار و تیم فنی انجام شود؛ زیرا کیفیت خدمت هم به صحت محتوایی وابسته است و هم به عملکرد سامانه.
- افزودن قابلیت دسترسی به پرونده‌های شخصی: به دلیل تغییر جدی در دامنه داده و ریسک، از مسیر ارزیابی و تصویب مشترک عبور کند.
- اصلاح‌های معمول و کم‌اثر: در محدوده‌ای که از پیش تعریف شده، به واحد مسئول یا تیم فنی تفویض شود.
در چنین ساختاری، یک واحد برای هر تغییر کوچک نیازمند تأیید مدیران مرکزی نیست؛ اما نمی‌تواند با عنوان استقلال عملیاتی، سیاست‌های مشترک امنیت و محرمانگی را نادیده بگیرد.
چه عواملی در انتخاب مدل اهمیت دارند؟
برای انتخاب مدل مناسب، بهتر است سازمان به‌جای پیروی از یک الگوی رایج یا انتخاب ساختاری که در سازمان دیگری موفق بوده، چند عامل را بررسی کند:
اندازه و پراکندگی سازمان: هرچه تعداد واحدها، شعب، مناطق جغرافیایی و فرایندهای مستقل بیشتر باشد، مدیریت تمام تصمیم‌ها از یک نقطه دشوارتر می‌شود.
تنوع کاربردها: سازمانی که فقط چند کاربرد محدود و مشابه دارد، احتمالاً به ساختار متمرکز ساده‌تری نیاز دارد. اما در سازمانی با کاربردهای متفاوت در تولید، مالی، منابع انسانی، فروش و خدمات مشتری، واگذاری بخشی از اختیار به واحدها اهمیت بیشتری پیدا می‌کند.
سطح ریسک و حساسیت داده: کاربردهایی که با اطلاعات محرمانه، تصمیم‌های اثرگذار بر اشخاص یا فرایندهای حیاتی سروکار دارند، به کنترل و نظارت مشترک بیشتری نیازمندند. این موضوع حتی در سازمان‌های با ساختار توزیع‌شده نیز تغییر نمی‌کند.
بلوغ واحدها: واگذاری اختیار بدون وجود نیروی متخصص، توان ارزیابی، منابع نگهداری و مسئولیت‌پذیری می‌تواند به تولید راهکارهای ناپایدار منجر شود. واحدی که اختیار بیشتری دریافت می‌کند باید توان استفاده مسئولانه از آن را هم داشته باشد.
ظرفیت مرکز: اگر تیم مرکزی منابع و تخصص کافی برای پاسخ‌گویی به تمام درخواست‌ها نداشته باشد، تمرکز کامل ممکن است به گلوگاه تبدیل شود. در مقابل، اگر مرکز نتواند استانداردهای مشترک و قابلیت‌های پایه را فراهم کند، توزیع اختیار احتمالاً به پراکندگی منجر خواهد شد.
هزینه و امکان استفاده مجدد: اگر چند واحد مسئله‌های مشابهی دارند، ساخت راهکار مستقل برای هرکدام لزوماً منطقی نیست. گاهی یک سکوی مشترک یا قابلیت قابل استفاده مجدد، هزینه و پیچیدگی سازمان را به‌طور محسوسی کاهش می‌دهد.
در نهایت، انتخاب مدل باید متناسب با توان واقعی سازمان باشد، نه صرفاً ساختار رسمی آن. سازمانی که از نظر چارت سازمانی فدرال به نظر می‌رسد، ممکن است در عمل تمام تصمیم‌ها را در یک مدیر متمرکز کرده باشد؛ همان‌طور که یک ساختار متمرکز می‌تواند بخش زیادی از تصمیم‌های عملیاتی را با تفویض اختیار روشن به واحدها واگذار کند.
مدیر منابع انسانی گفت: «اگر برای اصلاح هر بخشنامه منتظر تأیید مرکزی بمونیم، جواب‌ها همیشه عقب می‌مونن.»
مسئول ریسک و انطباق پاسخ داد: «اصلاح محتوای معتبر یک موضوعه؛ اضافه کردن دسترسی به پروندهٔ افراد یک موضوع دیگه.»
مدیر فناوری گفت: «می‌تونیم مسیر به‌روزرسانی محتوا رو به خود واحد بدیم، ولی تغییر دسترسی‌ها و قابلیت‌های سامانه مسیر جدا داشته باشه.»
مدیرعامل گفت: «همین مرزها رو بنویسیم؛ چه چیزی در اختیار واحده و چه چیزی تصمیم مشترک می‌خواد.»
در این جلسه، مسئله دیگر انتخاب یک ساختار سازمانی با نام متمرکز یا فدرال نبود. آن‌ها داشتند مشخص می‌کردند کدام اختیار باید در نزدیک‌ترین نقطه به مسئله قرار بگیرد و کدام تصمیم به دلیل اثر گسترده‌تر، باید با هماهنگی و کنترل مشترک گرفته شود.
مرکز تعالی چگونه به این مدل کمک می‌کند
با افزایش تعداد کاربردها، نیاز به دانش، روش‌ها و ابزارهای مشترک بیشتر می‌شود. واحدهای مختلف ممکن است برای ارزیابی مدل، ثبت سامانه‌ها، انتخاب معماری، آموزش کارکنان یا بررسی تأمین‌کننده به کمک مشابهی نیاز داشته باشند. مرکز تعالی می‌تواند این قابلیت‌ها را فراهم کند.
در سازمان‌ها، واحدی که این نقش را بر عهده دارد، با عنوان‌هایی مانند «آزمایشگاه هوش مصنوعی» یا «معاونت هوشمندسازی» هم شناخته می‌شود. برای فهم جایگاه آن، باید مأموریت، خروجی و حدود اختیارش را در کنار نامش دید.
آزمایشگاه هوش مصنوعی در مأموریت آزمایشگاهی خود، بر کشف امکان‌ها، آزمودن ایده‌ها و ساخت نمونه تمرکز دارد. برای پروندهٔ ما، می‌تواند چند مدل را روی اسناد منتخب بیازماید، یک نمونهٔ دستیار بسازد و نشان دهد کدام روش پاسخ بهتری می‌دهد و چه محدودیت‌هایی دارد. خروجی این کار، نمونه و شواهدی است که به تصمیم بعدی کمک می‌کند. آزمایشگاه‌های هم‌آفرینی هوش مصنوعی مایکروسافت نمونه‌ای از تمرکز بر ساخت، آزمون و توسعهٔ راهکارند.
مرکز تعالی هوش مصنوعی، تجربه و توان تخصصی را به قابلیتی مشترک و ماندگار برای سازمان تبدیل می‌کند. در این نقش، چارچوب مشترک تدوین می‌کند، تجربه‌ها را میان واحدها منتقل می‌کند، ابزار و خدمت مشترک ارائه می‌دهد و به استفادهٔ دوباره از راهکارهای مناسب کمک می‌کند. همچنین می‌تواند ارزیابی اولیه و مشاورهٔ معماری را انجام دهد تا هر واحد همهٔ مسیر را از ابتدا طی نکند. در راهنمای ایجاد مرکز تعالی مایکروسافت نیز آموزش، هدایت پایلوت، استانداردهای مشترک و دارایی‌های قابل استفادهٔ دوباره، در کنار هم قرار دارند.
این دو مأموریت می‌توانند در یک گروه جمع شوند. مرکز تعالی می‌تواند خودش نمونه بسازد و آزمایشگاه هم می‌تواند مسئولیت استانداردگذاری، آموزش و خدمات مشترک را بپذیرد و نقش مرکز تعالی را ایفا کند. تفاوت در دامنهٔ مسئولیتی است که سازمان به آن سپرده است: ساختن و آزمودن یک راهکار، یا فراهم‌کردن روش و توان مشترک برای چندین کاربرد در طول زمان.
معاونت هوشمندسازی، عنوان یک جایگاه مدیریتی در ساختار سازمان است. مأموریت آن می‌تواند برنامه‌ریزی تحول، هماهنگی پروژه‌ها و منابع و پیگیری نتیجهٔ هوشمندسازی را دربر بگیرد و آزمایشگاه یا مرکز تعالی نیز زیرمجموعهٔ آن باشد. اختیاراتی مانند تصویب بودجه، پذیرش ریسک یا اجازهٔ بهره‌برداری باید در شرح مأموریت و تفویض اختیار مشخص شوند.
در پروندهٔ دستیار، ساختن نمونه و گزارش نتیجهٔ آزمون، مأموریت آزمایشگاهی است. وقتی همان گروه روش ارزیابی مشترک را نگهداری می‌کند، تیم‌های واحدها را آموزش می‌دهد و تجربهٔ هر پروژه را در اختیار پروژه‌های بعدی می‌گذارد، نقش مرکز تعالی را هم بر عهده گرفته است. عنوانی که سازمان برای گروه انتخاب کرده، این تقسیم کار را تغییر نمی‌دهد.
در عین حال، باید معلوم باشد مرکز در هر پرونده چه کلاهی بر سر دارد: استانداردگذار است، مشاور است، مجری است یا ارزیاب؟ اگر اجرای بخشی از کار به آن سپرده شده، تعهدات همان اجرا باید روشن شود. اگر اختیار ارزیابی یا تصویب دارد، حدود آن باید مشخص باشد.
صرف ایجاد مرکز تعالی، مسئولیت مسئلهٔ کسب‌وکار، ادارهٔ فنی خدمت و پیگیری ریسک را منتقل نمی‌کند. آن مسئولیت‌ها همچنان باید برای هر کاربرد تعیین شوند.
همچنین لازم نیست همهٔ پروژه‌ها برای هر تغییر کوچک به مرکز مراجعه کنند؛ موضوعاتی که به بررسی مشترک نیاز دارند باید از پیش روشن شوند.
همان‌طور که چهار کلاه مسئولیت الزاماً چهار سمت تازه نبودند، این قابلیت مشترک هم می‌تواند ابتدا توسط گروهی از افراد موجود فراهم شود. نام و ساختار آن زمانی مفید است که واحدها بدانند چه کمکی دریافت می‌کنند و در برابر چه چیزی پاسخ‌گو می‌مانند.
مدیر فناوری گفت: «برای ارزیابی پاسخ‌ها یک روش مشترک لازم داریم. چند واحد دیگه هم دارن دستیار می‌خوان.»
مدیرعامل پرسید: «گروه مشترکمون می‌تونه روش آزمون و ابزار ثبت نتیجه رو آماده کنه؟»
«بله؛ ولی پاسخ درست هر حوزه رو باید متخصص همون حوزه تعیین کنه.»
مدیر منابع انسانی گفت: «این کمک می‌کنه. همکاران من روی اعتبار محتوا و کاربرد کار می‌کنن؛ روش ارزیابی رو هم از صفر اختراع نمی‌کنیم.»
کمک مشترک، جای مسئولیت محلی را نگرفت. انجام آن را ممکن‌تر کرد.
عبور از هر مرحله به چه شواهدی نیاز دارد
وقتی مسئله تعریف می‌شود، راهکار طراحی می‌شود، پایلوت اجرا می‌شود و خدمت به بهره‌برداری می‌رسد، سازمان فقط یک فهرست فعالیت فنی را طی نمی‌کند. در نقاطی از این مسیر باید تصمیم بگیرد آیا شواهد موجود برای ادامه کافی است و ادامه با چه شرایطی مجاز خواهد بود.
دروازهٔ تصمیم، همین نقطهٔ بررسی است. برای هر دروازه باید پرسش، شواهد لازم، مرجع تصمیم و گزینه‌های پیش رو معلوم باشند. گزینه‌ها می‌توانند ادامه، ادامه با محدودیت، بازگشت برای اصلاح، بررسی بیشتر یا توقف باشند.
در مسیر آموزشی این بخش، هفت دروازه را دنبال می‌کنیم:
| دروازه | پرسش اصلی |
|---|---|
| ورود | آیا مسئله ارزش بررسی برای استفاده از هوش مصنوعی را دارد؟ |
| تصویب | آیا مالک، دامنه، ارزش مورد انتظار و ریسک اولیه به اندازهٔ لازم روشن‌اند؟ |
| طراحی | آیا داده، معماری و شیوهٔ تأمین برای این کاربرد قابل قبول‌اند؟ |
| آمادگی | آیا کیفیت، امنیت و معیارهای پذیرش مورد نیاز برای ورود به پایلوت فراهم شده‌اند؟ |
| گسترش | آیا شواهد پایلوت، افزایش دامنهٔ استفاده را توجیه می‌کنند؟ |
| بهره‌برداری | آیا مسئولیت عملیاتی، پشتیبانی و کنترل‌های لازم برقرارند؟ |
| ادامه یا توقف | با توجه به نتایج واقعی، خدمت باید ادامه یابد، اصلاح شود، گسترش یابد یا متوقف شود؟ |
این دروازه‌ها به معنای تشکیل هفت کمیته یا هفت جلسهٔ رسمی نیستند. برای یک تغییر کوچک، بررسی و تصمیم می‌تواند در همان فرایند جاری و با ثبت کوتاه انجام شود. برای گسترش اثرگذار، شواهد و مشارکت بیشتری لازم است. تغییر داده، مدل، کاربران یا حدود اختیار هم می‌تواند بازبینی یک تصمیم قبلی را ضروری کند.
در چارچوب NIST AI RMF نیز MANAGE 1.1 بر تصمیم دربارهٔ تحقق هدف و ادامهٔ توسعه یا استقرار تأکید می‌کند. MANAGE 2.4 نیز به سازوکار و مسئولیت مشخص برای کنار گذاشتن یا غیرفعال کردن سامانه‌ای می‌پردازد که عملکرد یا پیامدش با کاربرد مورد انتظار سازگار نیست. هفت دروازهٔ بالا، صورت‌بندی آموزشی این دوره برای عملیاتی کردن چنین تصمیم‌هایی است. NIST AI RMF 1.0، بخش MANAGE
پرسش فعلی پروندهٔ ما، دروازهٔ گسترش است. آماده بودن ظرفیت فنی، یکی از شواهد آن است. سازمان باید نتیجهٔ بررسی پاسخ‌ها، وضعیت منابع معتبر، کارکرد ارجاع و محدودیت‌های باقیمانده را هم ببیند و سپس دربارهٔ افزایش دسترسی تصمیم بگیرد.
نسبت نتیجهٔ ارزیابی با اختیار انتشار یا توقف، موضوع اصلی وقتی استاندارد هست، اما کسی ملزم به آزمون نیست است. آن نوشته کمک می‌کند فاصلهٔ میان داشتن گزارش و اثرگذاشتن گزارش بر تصمیم را دقیق‌تر ببینیم.
مدیرعامل پرسید: «برای تصمیم این مرحله، چه چیزهایی هنوز کم داریم؟»
مدیر منابع انسانی گفت: «نتیجهٔ بررسی پاسخ‌های مورد اختلاف و تأیید منابعی که قرار است استفاده بشه.»
مدیر فناوری گفت: «آزمون مسیر ارجاع و اجرای محدودیت پاسخ‌گویی رو هم اضافه کنیم.»
مسئول ریسک و انطباق گفت: «شرایطی که باعث محدودسازی موقت می‌شه و مرجع بازگشایی هم ثبت بشه.»
مدیرعامل روی برگهٔ پیشنهاد نوشت: «پس از تکمیل شواهد، برای تصویب گسترش بررسی شود.»
پیشنهاد روی میز ماند، اما دیگر بلاتکلیف نبود. معلوم بود برای تصمیم گرفتن چه کاری باقی مانده است.
کلاه‌ها و اختیارها را روی همان پرونده امتحان کنیم
اکنون می‌توانیم دوباره به اختلافی نگاه کنیم که در درس قبل آغاز شد. فناوری از زیرساخت و رفتار سامانه صحبت می‌کند، منابع انسانی از محتوا و فرایند، حامی از نتیجهٔ پروژه و متولی ریسک از پیامد پاسخ. همه بخشی از واقعیت را می‌بینند. مدل عملیاتی باید این سهم‌ها را به رسیدگی و تصمیم متصل کند.
برای پاسخ محل اختلاف، منابع انسانی رسیدگی به نیاز کارمند و تعیین مرجع معتبر را پیگیری می‌کند. تیم فنی منشأ اشکال و اصلاح سامانه را دنبال می‌کند. پیگیری ریسک، حدود استفاده و اقدام‌های لازم را روشن می‌سازد. حامی نیز منابع و همکاری مورد نیاز را فراهم می‌کند. این مسئولیت‌ها می‌توانند بر عهدهٔ افراد یا گروه‌های مشترک باشند؛ همان‌طور که در درس دوم توضیح دادیم.
حالا برای تصمیم دربارهٔ گسترش، همین نقش‌ها با اختیارهای مشخص وارد می‌شوند: پیشنهاد آماده می‌شود، شواهد ارزیابی می‌شوند و مرجع تصویب تعیین‌شده تصمیم می‌گیرد. اگر تصمیم مشروط باشد، باید روشن باشد چه کسی تحقق شرط‌ها را بررسی می‌کند و چه زمانی اجازهٔ اجرا برقرار می‌شود.
در صورت بروز خطا هم، مسیر محدودسازی و بازگشایی باید معلوم باشد.
داشتن اختیار اجرای یک توقف موقت، لزوماً به معنای داشتن اختیار رفع همهٔ محدودیت‌ها نیست.
هرکدام باید در نقشهٔ تصمیم جای مشخص داشته باشد.
با پایان بخش اول، باید بتوانیم برای همین پرونده توضیح دهیم چه کسی یا گروهی مسئول کدام موضوع است، چه اختیارهایی دارد، از چه قابلیت مشترکی کمک می‌گیرد و در کدام نقاط باید بر مبنای شواهد تصمیم تازه‌ای گرفته شود.
پایان بخش اول
در جلسهٔ بعد، برگهٔ پیشنهاد گسترش تنها نبود. گزارش بررسی پاسخ‌ها، فهرست منابع معتبر و نتیجهٔ آزمون ارجاع هم کنارش قرار گرفته بود.
در پیشنهاد تازه، پاسخ‌گویی دربارهٔ موارد فردی کمک‌هزینه به کارشناس ارجاع می‌شد. افزایش دسترسی برای گروه مشخصی از کارکنان پیشنهاد شده بود و زمان بازبینی هم داشت.
مدیر منابع انسانی گفت: «این دامنه و منابعش رو بررسی کردیم.»
مدیر فناوری گفت: «محدودیت‌ها و مسیر ارجاع آزمایش شده.»
مسئول ریسک و انطباق شرایط محدودسازی و بازگشایی را مرور کرد.
مدیرعامل، در جایگاه مرجع تصویب تعیین‌شده برای این مرحله، گسترش محدود را تأیید کرد. تصمیم، دامنه و زمان بازبینی آن ثبت شد.
درخواست سادهٔ «یک دستیار می‌خواهم» حالا به پرونده‌ای تبدیل شده بود که می‌شد مسئولیت‌ها و تصمیم‌هایش را دنبال کرد.
پیش از بسته شدن جلسه، مدیر عملیات فهرست دیگری را باز کرد: «برای چند کار دیگه هم درخواست هوش مصنوعی داریم؛ از جست‌وجوی اسناد تا خودکار کردن چند گردش کار.»
مدیرعامل به فهرست نگاه کرد: «همهٔ این‌ها باید همین مسیر رو طی کنن؟ اصلاً کدومشون هوش مصنوعیه؟»
بخش اول تمام شده بود، اما برای شروع پرونده‌های بعدی، پرسش تازه‌ای داشتند: دقیقاً چه چیزهایی باید زیر حکمرانی هوش مصنوعی قرار بگیرند؟
این درس، قسمت دوم و پایانی بخش اول «مدل عملیاتی حکمرانی و حق تصمیم» و تشریح اسلایدهای ۱۴ تا ۱۸ دوره است. درس قبل؛ اسلایدهای کامل دوره