اگر امروز مسئول استراتژی هوش مصنوعی یک سازمان شوم، از کجا شروع می کنم؟

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

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

روزهای اول: شنیدن و دیدن

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

در همین مرحله اهداف اصلی کسب و کار را بنویسید: کاهش زمان خدمت، بهبود کیفیت، افزایش درآمد یا کنترل ریسک. هر ایده بعدی باید به یکی از این هدف ها وصل شود. همچنین محدودیت داده، امنیت، بودجه و مهارت را بدون تعارف ثبت کنید.

ماه دوم: یک آزمایش با امکان شکست

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

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

همزمان، زیرساخت حداقلی برای دسترسی، ثبت رخداد و ارزیابی ایجاد کنید. نباید برای یک آزمون کوچک پلتفرم عظیم بسازیم، اما نباید کنترل های ضروری را هم به آینده موکول کنیم.

ماه سوم: تصمیم بگیریم، نه فقط گزارش بدهیم

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

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

هر دو هفته چه گزارشی بدهیم؟

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

نود روز اول برای شناختن است، نه اثبات دانایی

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

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

اولویت بندی بدون شناخت ظرفیت خطرناک است

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

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

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

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

همزمان چند پایه مشترک بسازید

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

همچنین ظرفیت تیم را صادقانه بررسی کنید. چه مهارت هایی در داخل وجود دارد؟ کجا به شریک بیرونی نیاز داریم؟ چه چیزی را می توان با آموزش اصلاح کرد؟ خرید پلتفرم بدون شناخت توان نگهداری آن ممکن است سازمان را وابسته کند. استراتژی خوب فقط درباره پروژه ها نیست؛ درباره ساخت توانایی ماندگار نیز هست.

روز نودم باید تصمیم داشته باشید

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

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

گفتگو با مدیر مالی را از ابتدا شروع کنید

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

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

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

نود روز خوب لزوما با راه اندازی چند سامانه به پایان نمی رسد. ممکن است مهم ترین دستاورد آن، متوقف کردن پروژه های نامناسب و ایجاد توافق بر سر یک مسئله ارزشمند باشد. استراتژی از همین انتخاب های روشن آغاز می شود.