از پایلوت تا ارزش واقعی؛ چرا هر پروژه موفق هوش مصنوعی نباید توسعه پیدا کند؟

# از پایلوت تا ارزش واقعی؛ چرا هر پروژه موفق هوش مصنوعی نباید توسعه پیدا کند؟

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

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

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

به نظرم اینجا یکی از مهم‌ترین نقاط تصمیم‌گیری در پروژه‌های هوش مصنوعی است.

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

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

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

## بعد از پایلوت، تازه سؤال اصلی شروع می‌شود

در مرحله آزمایشی همه چیز معمولاً ساده‌تر است.

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

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

چه کسی مسئول پشتیبانی آن است؟

اگر خروجی اشتباه بود چه اتفاقی می‌افتد؟

کاربران بر چه اساسی به اطلاعات دسترسی پیدا می‌کنند؟

داده‌ها کجا پردازش یا ذخیره می‌شوند؟

راهکار چگونه به ERP، CRM یا سایر سامانه‌های عملیاتی متصل خواهد شد؟

هزینه استفاده وقتی تعداد کاربران ده برابر یا صد برابر شود چه تغییری می‌کند؟

اگر سرویس از دسترس خارج شد، فرآیند کسب‌وکار چگونه ادامه پیدا می‌کند؟

و شاید مهم‌تر از همه:

آیا ارزش ایجادشده واقعاً از هزینه و پیچیدگی‌ای که وارد سازمان می‌کنیم بیشتر است؟

این‌ها دیگر پرسش‌های صرفاً فنی نیستند.

در این مرحله، موضوع از فناوری به تصمیم سرمایه‌گذاری تبدیل می‌شود.

## یکی از اشتباهات متداول: Usage را با Value اشتباه می‌گیریم

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

عدد خوبی به نظر می‌رسد.

اما آیا واقعاً ارزش ایجاد شده است؟

صرف استفاده از یک ابزار، الزاماً نشانه موفقیت اقتصادی آن نیست.

ممکن است کارکنان از یک سیستم زیاد استفاده کنند، اما در نهایت زمان انجام فرآیند کاهش پیدا نکرده باشد، هزینه‌ای کم نشده باشد و کیفیت خروجی هم تغییر محسوسی نکرده باشد.

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

برای همین من فکر می‌کنم در پروژه‌های AI باید خیلی زود یک سؤال ساده مطرح شود:

**دقیقاً چه چیزی قرار است بهتر شود؟**

زمان؟

هزینه؟

کیفیت؟

سرعت پاسخ‌گویی؟

تعداد خطاها؟

رضایت مشتری؟

درآمد؟

ظرفیت عملیاتی؟

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

## بدون نقطه شروع، اندازه‌گیری تقریباً بی‌معناست

بارها دیده‌ایم که بعد از اجرای یک پروژه، تازه این سؤال مطرح می‌شود که «چقدر بهتر شدیم؟»

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

فرض کنید هدف استفاده از AI کاهش زمان بررسی یک درخواست است.

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

بعد می‌توانیم هدف تعریف کنیم و پس از اجرای پایلوت ببینیم واقعاً چه تغییری رخ داده است.

در غیر این صورت، بیشتر با برداشت و احساس مواجهیم تا اندازه‌گیری.

به همین دلیل، به نظرم هر پروژه AI قبل از شروع باید سه چیز کاملاً روشن داشته باشد:

وضعیت فعلی، نتیجه مورد انتظار و روش اندازه‌گیری.

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

## هزینه واقعی معمولاً بعد از Demo ظاهر می‌شود

در مراحل اولیه پروژه، نگاه ما به هزینه معمولاً محدود است.

هزینه License یا API را می‌بینیم، شاید هزینه زیرساخت را هم تخمین بزنیم و بر همان اساس درباره اقتصادی بودن راهکار صحبت می‌کنیم.

اما بخش بزرگی از هزینه‌ها در مقیاس واقعی ظاهر می‌شود.

داده باید آماده و کنترل شود.

اتصال به سیستم‌های موجود باید توسعه پیدا کند.

دسترسی‌ها باید مدیریت شوند.

Logging و Monitoring لازم است.

کنترل‌های امنیتی باید اضافه شوند.

گاهی خروجی مدل باید توسط انسان بازبینی شود.

کاربران نیاز به آموزش دارند.

فرآیندها باید تغییر کنند.

و در نهایت کسی باید این سرویس را در عملیات روزمره پشتیبانی کند.

همین‌جاست که Total Cost of Ownership اهمیت پیدا می‌کند.

یک پایلوت ممکن است با هزینه کم بسیار جذاب به نظر برسد، اما وقتی همه این مؤلفه‌ها وارد محاسبه شوند، تصویر اقتصادی پروژه کاملاً تغییر کند.

بنابراین پیش از تصمیم برای توسعه، بهتر است مدیران به جای پرسیدن «هزینه مدل چقدر است؟» سؤال دیگری بپرسند:

**هزینه واقعی داشتن این قابلیت در سازمان چقدر خواهد بود؟**

این سؤال معمولاً پاسخ بسیار متفاوتی دارد.

## تصمیم بعد از پایلوت الزاماً «ادامه» نیست

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

در نتیجه وقتی یک تیم چند ماه روی پروژه‌ای کار کرده، متوقف کردن آن سخت می‌شود.

اما همه پایلوت‌ها نباید به محصول یا سرویس سازمانی تبدیل شوند.

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

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

من برای تصمیم‌گیری پس از پایلوت، معمولاً پنج موضوع را مهم می‌دانم:

**ارزش واقعی**
آیا بهبود قابل اندازه‌گیری اتفاق افتاده است؟

**پذیرش کاربران**
آیا کاربران واقعاً تمایل دارند از راهکار استفاده کنند یا استفاده از آن فقط با فشار مدیریتی ادامه پیدا می‌کند؟

**کیفیت و قابلیت اتکا**
آیا خطاهای سیستم برای این فرآیند قابل قبول هستند؟

**ریسک و حاکمیت**
آیا موضوعاتی مانند امنیت، محرمانگی اطلاعات، دسترسی، مسئولیت‌پذیری و انطباق قابل مدیریت هستند؟

**هزینه در مقیاس واقعی**
اگر راهکار وارد کل سازمان شود، اقتصاد آن همچنان قابل دفاع است؟

بعد از پاسخ به این سؤال‌ها معمولاً یکی از سه نتیجه شکل می‌گیرد.

گاهی پاسخ روشن است: پروژه ارزش دارد و می‌توان آن را توسعه داد.

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

و گاهی هم نتیجه این است که پروژه نباید ادامه پیدا کند.

به نظرم این تصمیم آخر از همه دشوارتر است.

## هزینه‌ای که انجام شده، نباید ما را مجبور به ادامه کند

وقتی چند ماه زمان و بودجه برای پروژه‌ای صرف شده، توقف آن از نظر مدیریتی ساده نیست.

معمولاً استدلال‌هایی مانند این مطرح می‌شوند:

«تا اینجا هزینه زیادی کرده‌ایم.»

«تیم چند ماه روی پروژه کار کرده است.»

«اگر متوقف کنیم تمام این سرمایه‌گذاری از بین می‌رود.»

اما هزینه‌ای که قبلاً انجام شده، به‌تنهایی دلیل مناسبی برای هزینه‌کرد بیشتر نیست.

تصمیم باید براساس آینده گرفته شود، نه گذشته.

سؤال مفیدتر این است:

**اگر امروز برای اولین بار با اطلاعاتی که اکنون داریم با این پروژه مواجه می‌شدیم، باز هم حاضر بودیم برای ادامه آن سرمایه‌گذاری کنیم؟**

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

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

## گاهی فناوری آماده است، اما سازمان آماده نیست

حالت دیگری هم وجود دارد که کمتر درباره آن صحبت می‌شود.

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

مثلاً داده‌های سازمان ساختار مناسبی ندارند.

مدیریت دسترسی هنوز بالغ نیست.

معماری Integration برای توسعه سریع سرویس‌ها آماده نشده است.

مسئول AI Governance مشخص نیست.

فرآیندهای کسب‌وکار با نقش جدید AI بازطراحی نشده‌اند.

یا تیم عملیات هنوز توان پشتیبانی از چنین سرویسی را ندارد.

در این شرایط مشکل الزاماً از راهکار نیست.

ممکن است بهترین تصمیم این باشد که توسعه متوقف نشود، اما تا زمان رفع چند پیش‌نیاز اساسی به تعویق بیفتد.

Scale کردن یک پروژه روی زیرساخت یا سازمان ناآماده، گاهی می‌تواند یک پایلوت موفق را به یک تجربه ناموفق تبدیل کند.

## در مرحله بعد، دیگر پروژه‌ها را جدا از هم نبینیم

اگر یک سازمان فقط یک یا دو پروژه AI داشته باشد، ارزیابی موردی شاید کافی باشد.

اما زمانی که تعداد ایده‌ها زیاد می‌شود، مسئله تغییر می‌کند.

فرض کنیم ده Use Case مختلف روی میز مدیریت قرار دارد و بودجه و نیروی انسانی برای اجرای همه آنها وجود ندارد.

در این وضعیت دیگر سؤال اصلی این نیست که آیا هر پروژه به‌تنهایی «خوب» است یا نه.

سؤال این است که کدام پروژه نسبت به بقیه ارزش بیشتری دارد.

ممکن است یک پروژه بسیار جذاب و پیچیده باشد، اما زمان زیادی برای اجرا بخواهد و ریسک بالایی داشته باشد.

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

در چنین شرایطی، سازمان باید از مدیریت پروژه‌های جداگانه به سمت مدیریت سبد پروژه‌های AI حرکت کند.

ارزش کسب‌وکار، هم‌راستایی با راهبرد، ریسک، هزینه، آمادگی داده، پیچیدگی اجرا و زمان رسیدن به نتیجه باید در کنار هم دیده شوند.

هدف نباید این باشد که تعداد بیشتری پروژه AI داشته باشیم.

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

## سخن پایانی

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

اما سرعت در آزمایش نباید به معنی عجله در توسعه باشد.

پایلوت خوب، پایلوتی نیست که حتماً به Scale برسد.

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

گاهی این تصمیم توسعه است.

گاهی اصلاح و آزمایش مجدد.

و گاهی توقف.

از نگاه من، سازمانی که بتواند پروژه‌ای را که دیگر توجیه کافی ندارد متوقف کند، الزاماً از سازمانی که ده‌ها پروژه AI را همزمان اجرا می‌کند عقب‌تر نیست.

شاید حتی بالغ‌تر باشد.

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

**همه پروژه‌های هوش مصنوعی قرار نیست بزرگ شوند؛ مهم این است که بدانیم کدام‌یک ارزش بزرگ شدن دارند.**