پیشنهادی که همه‌چیز را یکجا تحویل می‌داد
مدیر فناوری، در پاسخ به پرسش آخر مدیرعامل، دو پیشنهاد را روی نمایشگر آورد.
در اولی نوشته بودند: «راهکار آمادهٔ دستیار سازمانی؛ راه‌اندازی، میزبانی و پشتیبانی توسط تأمین‌کننده.» در دومی، بخشی از کار بر عهدهٔ تیم داخلی بود و چند جزء را باید جداگانه تهیه می‌کردند.
مدیر عملیات به پیشنهاد اول اشاره کرد: «این که مسیرش کوتاه‌تره. یک طرف هم مسئول تحویل داریم.»
مدیر مالی پرسید: «هزینهٔ ادامهٔ کارش چقدره؟»
مدیر فناوری گفت: «هزینهٔ راه‌اندازی و پشتیبانی رو نوشتن. برای تغییر دامنه و افزایش استفاده باید جزئیات بیشتری بگیریم.»
مسئول ریسک و انطباق پرسید: «دسترسی به اسناد رو چه کسی تعیین می‌کنه؟ اگر بخوایم استفاده از یک منبع یا قابلیت رو متوقف کنیم، خودمون می‌تونیم؟»
مدیر منابع انسانی گفت: «و وقتی یک سند عوض می‌شه، مسئول تأیید و جایگزین‌کردنش کیه؟ این رو هم شرکت انجام می‌ده؟»
مدیر عملیات گفت: «پس ازشون می‌پرسیم چه چیزهایی رو انجام می‌دن.»
مدیرعامل به دو پیشنهاد نگاه کرد. «فقط این رو نپرسیم. معلوم کنیم چه چیزهایی باید تحت اختیار خودمون بمونه. اگر یک روز بخوایم مسیر رو عوض کنیم، باید بدونیم چه چیزی رو می‌تونیم با خودمون ببریم.»
در درس هشتم حدود پاسخ‌گویی، پیشنهاد، تصمیم و اقدام را از هم جدا کردیم. دیدیم که برای هر استفاده، شواهد، مسئول تأیید و امکان رسیدگی یا توقف باید روشن باشند.
دو پیشنهاد روی نمایشگر، راه‌های متفاوتی برای اجرای همان حدود پیش پای مدیران گذاشته‌اند. انتخاب میان آن‌ها به تقسیم کار، محل نگهداری اطلاعات، اختیار تغییر، هزینهٔ ادامه و میزان وابستگی هم مربوط است. پرسش مدیرعامل دربارهٔ تغییر تأمین‌کننده، این تصمیم‌ها را آشکار می‌کند: سازمان برای ادامهٔ کار، کنترل چه چیزهایی را باید در اختیار داشته باشد؟
این درس، آغاز بخش چهارم دوره، «معماری، داده و تأمین‌کننده»، و مبتنی بر اسلایدهای ۴۹ تا ۵۴ است. پرسش ما مدیریتی است: چه چیزی را تهیه می‌کنیم، مسئولیت هر بخش با کیست و کنترل چه دارایی‌ها و تصمیم‌هایی باید در اختیار سازمان بماند؟
انتخاب معماری، میزان کنترل و وابستگی را تغییر می‌دهد
معماری در این بحث، به چگونگی کنار هم قرارگرفتن اجزای راهکار و تقسیم ادارهٔ آن‌ها مربوط است. مدیر لازم است بداند این ترتیب، چه اختیاری برای سازمان ایجاد می‌کند و چه وابستگی‌هایی به همراه دارد.
برای مقایسهٔ گزینه‌های معماری، پنج موضوع را پیش روی تصمیم‌گیر می‌گذاریم:
- کنترل: داده کجا می‌ماند، چه کسی می‌تواند تنظیمات را تغییر دهد و چه چیزی واقعاً در اختیار سازمان است؟
- هزینه: راه‌اندازی، افزایش استفاده، نگهداری و تغییر مسیر در آینده چه منابعی می‌خواهند؟
- امنیت: اطلاعات در چه محدوده‌ای پردازش می‌شود، دسترسی چگونه تعیین می‌شود و رخدادها چگونه پیگیری می‌شوند؟
- استقلال: سازمان برای فهم و ادارهٔ سامانه چه دانشی دارد و برای تغییرات تا چه اندازه به تأمین‌کننده وابسته است؟
- امکان خروج: آیا می‌توان داده و خدمت را منتقل کرد و تأمین‌کننده را جایگزین کرد؟
این پرسش‌ها باید در مقایسهٔ پیشنهادها حضور داشته باشند. ممکن است یک گزینه با هزینهٔ اولیهٔ کمتر آغاز شود، اما تغییر دامنه یا انتقال آن در آینده پرهزینه باشد. ممکن است گزینه‌ای اختیار بیشتری به سازمان بدهد، اما برای ادارهٔ آن به نیروی انسانی و مسئولیت بیشتری نیاز داشته باشیم.
برای مقایسهٔ عددی گزینه‌ها، هزینهٔ واقعی اجرای مدل زبانی؛ خرید، اجاره یا API هزینهٔ مصرف، نگهداری، ظرفیت و پایداری خدمت را کنار هم می‌گذارد؛ همان اجزایی که قیمت اولیه به‌تنهایی نشان نمی‌دهد.
داشتن تجهیزات در محل سازمان نیز به‌تنهایی پاسخ همهٔ پرسش‌های کنترل نیست. باید معلوم باشد چه کسی دسترسی مدیریتی دارد، چه کسی تغییرات را انجام می‌دهد و سازمان برای ادامه یا توقف خدمت به چه کسی وابسته است. در استفاده از خدمت بیرونی هم باید همین مرزهای اختیار را روشن کنیم.
مدیر مالی گفت: «پس این دو رقم راه‌اندازی رو مستقیم کنار هم نذاریم. هزینهٔ ادامه و تغییر رو هم بخوایم.»
مدیر فناوری گفت: «و مشخص کنیم چه تغییرهایی رو خودمون می‌تونیم انجام بدیم و برای کدوم‌ها باید سفارش تازه بدیم.»
مدیرعامل پرسید: «اگر بخوایم یک منبع نامعتبر رو از استفاده خارج کنیم، این کار در اختیار چه کسیه؟»
سؤال ساده بود، اما در هیچ‌کدام از دو صفحهٔ نخست پیشنهادها جواب روشنی نداشت.
مسئولیت را در چهار رکن سامانه روشن کنیم
ممکن است همهٔ راهکار را از یک شرکت بگیریم، اما مسئولیت‌های سازمانی آن همچنان متفاوت‌اند. برای روشن‌کردن این مسئولیت‌ها، چهار رکن را جدا می‌کنیم: داده، مدل، پلتفرم و زیرساخت، و کاربرد و فرایند.
| رکن | مسئولیت محوری | پرسش تصمیم‌ساز برای سازمان |
|---|---|---|
| داده | کیفیت، کامل‌بودن، محرمانگی و اعتبار منابع | چه اطلاعاتی وارد سامانه می‌شود، چه کسی مجاز به استفاده است و نسخهٔ معتبر کدام است؟ |
| مدل | کیفیت عملکرد، سوگیری و تغییر رفتار در طول استفاده | کدام مدل پذیرفته می‌شود و در چه شرایطی باید دوباره ارزیابی شود؟ |
| پلتفرم و زیرساخت | امنیت، دسترس‌پذیری، هزینه و وابستگی | خدمت کجا اداره می‌شود، دسترسی با کیست و مسیر پشتیبانی و خروج چیست؟ |
| کاربرد و فرایند | اثر بر کاربر و تصمیم سازمانی | دستیار در کدام تصمیم مجاز است، چه نظارتی لازم است و چه کسی پاسخ‌گوست؟ |
در پروندهٔ ما، واحد فناوری می‌تواند محل نگهداری اسناد را اداره کند، اما اعتبار آخرین اصلاحیهٔ خرید را باید مسئول محتوای همان حوزه تأیید کند. تیم ارزیابی می‌تواند کیفیت پاسخ را بررسی کند، اما اجازهٔ استفاده از آن برای تصمیم خرید، به صاحب فرایند و مرجع تعیین اختیار مربوط است.
تأمین‌کننده نیز ممکن است بخشی از کار هر رکن را انجام دهد. لازم است روشن کنیم چه کاری به او سپرده می‌شود، چه چیزی را تحویل می‌دهد و پذیرش نتیجه در سازمان بر عهدهٔ چه کسی است.
این تفکیک، به معنای ایجاد چهار سمت تازه نیست. مسئولیت‌ها کلاه‌اند: یک نفر می‌تواند چند کلاه داشته باشد و چند نفر می‌توانند در یک مسئولیت همکاری کنند. مهم آن است که هنگام تغییر یا خطا، مسیر تصمیم و پاسخ‌گویی معلوم باشد.
مدیر منابع انسانی پرسید: «اگر شرکت اسناد رو وارد کنه، مسئول درست‌بودن محتوا هم می‌شه؟»
مدیر مالی گفت: «ورود فایل رو می‌تونیم بهش بسپریم. ولی باید خودمون معلوم کنیم کدوم سند معتبره.»
مدیر فناوری گفت: «من هم باید مطمئن بشم همون نسخهٔ تأییدشده در دستیار استفاده می‌شه.»
مدیرعامل گفت: «پس در تحویل کار، فقط ننویسیم اسناد بارگذاری شد. تأیید محتوا و کنترل استفاده از نسخه رو هم مشخص کنیم.»
دستیار درون یک سامانهٔ سازمانی کار می‌کند
هوش مصنوعی در میانهٔ مسیر ارائهٔ خدمت قرار دارد. پیش از آن، منابع داده و سامانه‌های عملیاتی‌اند؛ پس از آن، کاربردها، کانال‌های ارتباط با کاربران و نتایج سازمانی.
برای دستیار خرید، مسیر می‌تواند از مقررات و اطلاعات معتبر شروع شود، به پاسخ یا پیشنهاد برسد و در نهایت بر نحوهٔ رسیدگی به درخواست اثر بگذارد. موفقیت، به درست‌کارکردن ارتباط این بخش‌ها وابسته است.
اگر مرجع معتبر محتوا روشن نباشد، پاسخ قابل اتکا دشوار می‌شود. اگر دستیار پاسخ درست بدهد اما کاربر نداند قدم بعدی چیست، ممکن است کار همچنان متوقف بماند. اگر پیشنهاد ارجاع تولید شود اما مرجع رسیدگی و مسیر تحویل آن معلوم نباشد، صرف تولید پیشنهاد مسئله را حل نمی‌کند.
لایه‌های پشتیبان این مسیر عبارت‌اند از امنیت و حریم خصوصی، اخلاق و مسئولیت‌پذیری، ریسک و انطباق، مالی و هزینه، نقش‌ها و سیاست‌ها، و پایش و بهبود مستمر. این موضوع‌ها به کل خدمت مربوط‌اند.
بنابراین، در ارزیابی پیشنهاد باید کل مسیر استفاده را ببینیم. تحویل یک محیط پاسخ‌گو، فقط بخشی از تعهد مورد انتظار است. باید روشن باشد به‌روزرسانی محتوا، مدیریت دسترسی، رسیدگی به بازخورد و سنجش نتیجه چگونه در کار روزمره قرار می‌گیرند.
مدیر عملیات پرسید: «اگر دستیار بگه درخواست باید به کمیته بره، خودش ارجاع می‌ده؟»
مدیر فناوری گفت: «در دامنه‌ای که فعلاً تصویب کردیم، نه. فقط مسیر رو توضیح می‌ده.»
مدیر عملیات گفت: «پس باید معلوم باشه کاربر بعدش چه کاری انجام می‌ده. اگر فقط اسم کمیته رو بگیم، ممکنه دوباره تماس بگیره.»
مدیرعامل کنار دامنهٔ تحویل نوشت: «بررسی مسیر واقعی استفاده، از سؤال تا رسیدگی.»
حالا می‌دانستند پایان نمایش پاسخ روی صفحه، الزاماً پایان کار کاربر نیست.
چه دارایی‌هایی باید در اختیار سازمان بمانند؟
شش گروه دارایی را از هم جدا می‌کنیم. برای هر گروه، لازم است از عنوان کلی «مالکیت سازمان» به یک انتظار قابل بررسی برسیم.
| دارایی | چه چیزی باید روشن بماند؟ |
|---|---|
| داده‌های راهبردی | اطلاعات اختصاصی، اسناد کلیدی و داده‌های تولیدشده کجا نگهداری می‌شوند و سازمان چگونه به آن‌ها دسترسی دارد؟ |
| مدل‌ها و دانش مدل | اجزای اختصاصی، تنظیمات، نسخه‌ها و دانش لازم برای اداره و ارزیابی آن‌ها در اختیار چه کسی است؟ |
| سیاست‌ها و استانداردها | قواعد امنیت، دسترسی، کیفیت و ارزیابی را چه کسی تعیین و تغییر می‌دهد؟ |
| فرایندها و تصمیم‌ها | منطق تصمیم، دستورالعمل‌ها و معیارهای موفقیت چگونه ثبت و به‌روز می‌شوند؟ |
| زیرساخت حیاتی | اختیار دسترسی، حفاظت، تداوم خدمت و بازیابی چگونه در اختیار سازمان قرار می‌گیرد؟ |
| نیروی انسانی و دانش داخلی | چه کسانی در سازمان، دانش کافی برای ارزیابی، تصمیم‌گیری و ادامهٔ کار دارند؟ |
در مورد ابزارها و مدل‌های عمومی، سازمان باید حق استفاده و حدود وابستگی را روشن کند. دربارهٔ دارایی‌های اختصاصی خود، مانند اسناد، قواعد تصمیم و دانش حاصل از اجرای پروژه، باید امکان حفظ و استفادهٔ مستقل را در تصمیم تأمین ببیند.
برای نمونه، اگر در طول پایلوت مجموعه‌ای از سؤال‌های ارزیابی، پاسخ‌های مورد تأیید و موارد خطا تهیه کرده‌ایم، این‌ها بخشی از دانش پروژه‌اند. برای ارزیابی تغییرات یا مقایسهٔ تأمین‌کنندهٔ بعدی به آن‌ها نیاز خواهیم داشت.
این دارایی‌ها باید در تعهد تحویل و انتقال هم دیده شوند. در قرارداد هوش مصنوعی؛ دقیقاً چه چیزی را باید تحویل بگیریم؟ داده، شناسنامهٔ سامانه، سابقهٔ ارزیابی و امکان خروج را به اقلام قابل مطالبه از مجری تبدیل کرده‌ام.
کنترل نیز باید عملی باشد. اگر سازمان نتواند فهرست منابع، وضعیت دسترسی‌ها یا سوابق لازم برای رسیدگی را دریافت کند، عبارت کلی «اطلاعات متعلق به کارفرماست» همهٔ نیازش را برآورده نکرده است. باید معلوم باشد چه چیزی، در چه قالبی و با چه ترتیبی در اختیار سازمان قرار می‌گیرد.
توان داخلی هم بخشی از همین کنترل است. سازمان به کسانی نیاز دارد که بتوانند اعتبار محتوا، کیفیت خروجی و اثر تغییرات را بررسی کنند و دربارهٔ پیشنهاد تأمین‌کننده تصمیم بگیرند. میزان این توان باید با دامنه و حساسیت استفاده تناسب داشته باشد.
وابستگی فنی نیز می‌تواند در ابزار اجرا و مهارت تیم پنهان بماند. اگر فردا NVIDIA را برداریم، چه چیزهایی می‌شکند؟ یک نمونهٔ مشخص از هزینهٔ خروج در لایه‌های نرم‌افزار، ارتباط پردازنده‌ها و موتور استنتاج است.
مدیر مالی پرسید: «اگر سال بعد بخوایم شرکت رو عوض کنیم، اسناد خودمون رو که داریم. چیز دیگه‌ای هم لازم داریم؟»
مدیر فناوری گفت: «باید بدونیم چه منابعی تأیید شدن، چه تنظیماتی اعمال شده، چه آزمون‌هایی انجام دادیم و چه ایرادهایی پیدا شده.»
مسئول ریسک و انطباق گفت: «و چه دسترسی‌ها و حدود اختیاری تصویب شده. نباید از اول حدس بزنیم نسخهٔ فعلی بر چه مبنایی کار می‌کرده.»
مدیرعامل گفت: «پس انتقال دانش و اطلاعات لازم برای ادامهٔ کار، جزو خروجی‌های مشخص پروژه باشه.»
ساخت، خرید، خدمت آماده یا ترکیب چند گزینه؟
پس از روشن‌شدن مسئله و دارایی‌های مهم، می‌توان پنج مسیر تأمین را با هم مقایسه کرد:
ساخت: می‌تواند برای نیاز اختصاصی یا قابلیت متمایز سازمان مناسب باشد. در مقابل، زمان، تیم و مسئولیت توسعه و نگهداری می‌خواهد. سازمان باید بسنجد آیا ارزش این اختصاصی‌سازی، منابع لازم را توجیه می‌کند.
خرید راهکار آماده: می‌تواند راه رسیدن به یک قابلیت استاندارد را کوتاه کند. باید دامنهٔ سازگاری با فرایند سازمان، محدودیت تغییر، پشتیبانی و هزینهٔ ادامهٔ استفاده روشن باشد.
دریافت یک قابلیت به‌صورت خدمت از تأمین‌کننده، یا API: می‌تواند شروع را سریع کند و نیاز به ادارهٔ بخشی از راهکار را کاهش دهد. پرسش‌های مدیریتی آن، محل و شرایط استفاده از داده، هزینهٔ مصرف، تداوم خدمت و وابستگی به عرضه‌کننده‌اند.
پرسش مربوط به خروج داده را در حفظ محرمانگی داده در استفاده از APIهای عمومی دقیق‌تر بررسی کرده‌ام؛ از اطلاعاتی که در معنا و روابط متن باقی می‌مانند تا حدود روش‌های حذف نام و ناشناس‌سازی.
استفاده از راهکار متن‌باز: می‌تواند امکان اداره و تغییر بیشتری در اختیار تیم قرار دهد. هزینهٔ استقرار، نگهداری و پشتیبانی و توان لازم برای پذیرفتن این مسئولیت‌ها باید در ارزیابی حضور داشته باشد.
معماری ترکیبی: اجزا را بر اساس نیاز تهیه می‌کند. ممکن است سازمان یک بخش را بخرد، از خدمت آماده‌ای استفاده کند و ادارهٔ منابع و قواعد حساس را در اختیار خود نگه دارد. این انتخاب به مسئولیت روشن برای هماهنگی اجزا و ادارهٔ کل خدمت نیاز دارد.
این گزینه‌ها می‌توانند کنار هم قرار بگیرند. لازم نیست انتخاب یک مدل، روش تهیهٔ همهٔ اجزای دیگر را هم تعیین کند. موضوع آن است که هر جزء چگونه به نیاز سازمان پاسخ می‌دهد و مسئولیت ارتباط آن با بقیهٔ سامانه بر عهدهٔ کیست.
این مقایسه، جهت کلی تفاوت‌ها را نشان می‌دهد. برای انتخاب واقعی باید همان عوامل را در پیشنهاد مشخص بررسی کنیم. سرعت شروع، هزینه و میزان کنترل، به دامنهٔ کار، شرایط تأمین و توان سازمان وابسته‌اند.
در پروندهٔ دستیار، نقطهٔ شروع مقایسه باید همان تصمیم‌های درس‌های قبل باشد: منابع معتبر، حدود دسترسی، اختیار محدود و مسیر رسیدگی. از هر گزینه می‌خواهیم نشان دهد این نیازها را چگونه برآورده می‌کند و چه تعهدی را بر عهدهٔ سازمان می‌گذارد.
پیش از انتخاب نام شرکت
مدیر عملیات به پیشنهاد اول برگشت: «ممکنه هنوز همین گزینه مناسب‌تر باشه.»
مدیرعامل گفت: «ممکنه. حالا می‌دونیم برای انتخابش چه چیزهایی رو باید روشن کنیم.»
مدیر مالی فهرست کوتاهی نوشت: «هزینهٔ شروع، ادامه، تغییر و خروج.»
مدیر فناوری اضافه کرد: «مسئولیت اجزا، دسترسی‌ها، تحویل دانش و ادارهٔ تغییرات.»
مسئول ریسک و انطباق گفت: «و اینکه محدودیت‌هایی که تصویب کردیم، در عمل چطور اجرا و بررسی می‌شن.»
مدیرعامل گفت: «با همین پرسش‌ها پیشنهادها رو تکمیل کنیم. بعد مقایسه کنیم چه چیزی می‌گیریم و چه مسئولیتی می‌پذیریم.»
مدیر منابع انسانی به فهرست قابلیت‌های یکی از پیشنهادها اشاره کرد: «اینجا برای همهٔ کارها، تولید پاسخ و متن پیشنهاد داده. برای تشخیص و دسته‌بندی درخواست‌ها هم همین رو لازم داریم؟»
مدیر فناوری گفت: «باید ببینیم هر کار دقیقاً چه خروجی‌ای می‌خواد.»
گفت‌وگو به پرسش بعدی رسیده بود: انتخاب نوع راهکار، بر اساس کاری که باید انجام شود.
در درس بعد، از اسلاید ۵۵ ادامه می‌دهیم و گزینه‌های راهکار و محدودیت‌های آن‌ها را بررسی می‌کنیم. محور بحث همچنان تصمیم سازمان است: برای هر مسئله چه قابلیتی لازم داریم و چه انتظاری از آن می‌توانیم داشته باشیم؟
این درس، نهمین درس مجموعهٔ «حکمرانی هوش مصنوعی در سازمان» و تشریح اسلایدهای ۴۹ تا ۵۴ دوره است. درس قبل: دستیار هوش مصنوعی تا کجا حق اقدام دارد؟؛ اسلایدهای کامل دوره