در هوش مصنوعی سراغ نتیجه سریع برویم یا سرمایه گذاری بزرگ؟

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

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

سه سبد، سه نوع پرسش

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

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

سبد سوم فرصت های راهبردی است. مثلا تبدیل خدمات پس از فروش یک سازنده تجهیزات به خدمت پیش بینی و نگهداری مستمر. در اینجا تنها پرسش فناوری نیست. آیا مشتری حاضر است پول بدهد؟ آیا داده لازم را در اختیار داریم؟ مسئولیت اشتباه سیستم با کیست؟ پاسخ را باید با آزمایش بازار و طراحی خدمت پیدا کرد.

اشتباه پنهان در رتبه بندی ایده ها

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

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

علامت سلامت سبد پروژه چیست؟

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

تفاوت سرعت با عجله چیست؟

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

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

سرمایه گذاری روی زیرساخت مشترک را جداگانه ببینید

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

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

یک سبد متوازن چه شکلی دارد؟

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

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

ترتیب پروژه ها، وابستگی ها را آشکار می کند

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

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

جلسه بازبینی سبد را جدی بگیرید

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

یک پروژه کوچک می تواند زیربنای تصمیم بزرگ باشد

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

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

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