در جلسهای، مدیری پرسید: «ما میخواهیم هوش مصنوعی را در سازمان پیاده کنیم. از کجا شروع کنیم؟»
پرسیدم کدام مشکل را میخواهید حل کنید. مکث کرد و گفت: «خب… کلاً بهرهوری.»
همینجا بیشتر پروژههای پیاده سازی هوش مصنوعی در سازمان شکست میخورند — نه در انتخاب ابزار، در همین مکث.
این جواب، خودش تشخیص است. پروژهای که با «کلاً» شروع شود، معمولاً با «فعلاً متوقفش کنیم» تمام میشود — و علتش تقریباً هیچوقت فنی نیست.
این نوشته دربارهٔ ترتیبی است که ریسک را پایین نگه میدارد.
چرا این پروژهها میمانند
از آنچه دیدهام، چهار علت پشت بیشتر توقفهاست و هیچکدام دربارهٔ مدل نیست:
کاربرد خیلی بزرگ انتخاب شده. «هوشمندسازی فرایند فروش» یک پروژه نیست، یک آرزوست. چیزی که نتوان در یک جمله گفت که چه چیزی وارد و چه چیزی خارج میشود، قابل ساختن نیست.
مالک ندارد. پروژه به «واحد فناوری اطلاعات» سپرده میشود، ولی مشکل مال واحد فروش است. آنکه درد را میفهمد تصمیم نمیگیرد و آنکه تصمیم میگیرد درد را نمیفهمد.
داده در دسترس نیست. روی کاغذ همه چیز ثبت میشود؛ در عمل نصفش در ذهن آدمهاست و نصف دیگر در فایلهای پراکنده. این را معمولاً هفتهٔ سوم میفهمند.
معیار موفقیت تعریف نشده. پروژه راه میافتد، گزارشها عدد نشان میدهند، و هیچکس نمیتواند بگوید بهتر شد یا نه. پروژهای که نتوان شکستش را تشخیص داد، موفقیتش را هم نمیشود تشخیص داد.
آزمون انتخاب کاربردِ شروع
پیش از هر چیز، یک کاربرد انتخاب کنید که هر چهار شرط را داشته باشد. اگر یکی را نداشت، سراغ بعدی بروید.
۱. زیاد تکرار میشود. روزی چند بار، نه ماهی یک بار. کاری که کم پیش میآید، حتی اگر خودکار شود، چیزی آزاد نمیکند — و کسی هم نمیفهمد بهتر شده یا نه.
۲. خروجیاش روشن است. باید بشود در یک جمله گفت چه چیزی وارد میشود و چه چیزی بیرون میآید. «پیام مشتری وارد میشود، پاسخ یا پروندهٔ کامل بیرون میآید» روشن است. «تجربهٔ مشتری بهتر میشود» روشن نیست.
۳. اشتباه در آن فاجعه نمیسازد. برای شروع، جایی را انتخاب کنید که خطا قابل جبران باشد. پاسخ اشتباه به یک پرسش عمومی جبران میشود؛ قیمت اشتباه در یک پیشنهاد رسمی نه.
۴. یک نفر مشخص مالکش است. نه یک واحد — یک آدم با نام، که این مشکل مال اوست و بهتر شدنش به سود او.
اگر کاربردی پیدا نکردید که هر چهار را داشته باشد، هنوز آمادهٔ شروع نیستید. و این نتیجهٔ ارزشمندی است، نه شکست.
سه کاربرد که معمولاً شرطها را دارند
اگر در انتخاب ماندهاید، این سه در بیشتر سازمانها هر چهار شرط را میگذرانند و نقطهٔ شروع امنی هستند.
پاسخ به پیامهای بیرون ساعت کاری. زیاد تکرار میشود، خروجیاش روشن است، رقیبش سکوت است — پس بدترین حالتش برابر وضع موجود است — و مالکش معمولاً مدیر فروش یا پشتیبانی است.
تشکیل پروندهٔ اولیه برای درخواستهای ورودی. سیستم پاسخ نهایی نمیدهد؛ فقط اطلاعاتی را که همکار فردا لازم دارد جمع میکند. ریسکش نزدیک صفر است چون تصمیمی نمیگیرد، و صرفهجوییاش فوری است.
پاسخ به پرسشهای تکراری داخلی. کارمندی که میپرسد «فرم مرخصی کجاست» یا «قاعدهٔ فلان چیست». اینجا حتی اگر پاسخ گاهی ناقص باشد، کسی بیرون سازمان نمیبیندش — و همین آن را برای تمرین ایدهآل میکند.
آنچه معمولاً کاربرد بدی برای شروع است: هر چیزی که با قیمت، تعهد زمانی یا داوری تخصصی سروکار دارد.
چهار چیزی که باید روی کاغذ باشد
پیش از اینکه هر ابزاری وصل شود، این چهار پرسش باید جواب مکتوب داشته باشند. نبودشان همان جایی است که پروژهها از ریل خارج میشوند:
سیستم چه چیزی را حق ندارد بگوید. قیمت، زمان تحویل، تعهد، هر چیزی که سازمان را ملزم میکند. فهرست باید کوتاه، صریح و برای همهٔ کانالها یکی باشد.
وقتی نمیداند چه میگوید. یک جملهٔ روشن و از پیش تعیینشده، بهتر از هر پاسخ سرهمبندیشده است.
کجا به آدم تحویل میدهد و به چه کسی. با اسم، نه با عنوان واحد. و پروندهای که تحویل میدهد باید چه داشته باشد.
چه کسی و هر چند وقت بهروزش میکند. این را پیش از شروع مشخص کنید، وگرنه شش ماه بعد سیستمی دارید که با اطمینان حرفهای قدیمی میزند — و همان اطمینان خطرناکش میکند.
هیچکدام از این چهار پرسش فنی نیست. همهشان تصمیم سازمانیاند و کسی جز شما نمیتواند جوابشان بدهد.
ترتیبی که ریسک را پایین نگه میدارد
هفتهٔ اول — فقط تماشا. سیستم را وصل کنید ولی اجازهٔ پاسخدادن ندهید؛ بگذارید فقط دستهبندی کند. آخر هفته میبینید واقعاً چه چیزی وارد سازمان میشود، که تقریباً همیشه با تصور مدیران فرق دارد. این هفته بیشترین یادگیری را دارد و کمترین ریسک را.
هفتهٔ دوم — باریکترین قلمرو ممکن. فقط یک دسته پیام، فقط بیرون ساعت کاری. اینجا رقیبِ سیستم سکوت است، نه همکار خوب شما. بدترین حالت این است که بهاندازهٔ سکوت خوب باشد.
هفتهٔ سوم — تشکیل پرونده برای بقیه. سیستم به موارد تصمیمخواه پاسخ ندهد، ولی اطلاعات لازم را جمع کند و برای صبح آماده بگذارد.
هفتهٔ چهارم — بخوانید و تصمیم بگیرید. پنجاه گفتگو را از اول تا آخر بخوانید. خودتان. حالا داده دارید و میتوانید تصمیم بگیرید کجا اجازهٔ بیشتر بدهید و کجا نه.
خاصیت این ترتیب یک چیز است: در هر هفته، اگر چیزی خراب شود، خرابیاش کوچک و برگشتپذیر است.
این برای کسبوکار ایرانی یعنی چه
یک: پایداری دسترسی را در معماری فرض نکنید. دسترسی به سرویسهای مدل از ایران همیشه برقرار نیست. سیستمی که فرض کرده همیشه میرسد، در بدترین لحظه ساکت میماند. رفتار هنگام نبودِ دسترسی باید از روز اول تعریف شود، نه بعداً وصله شود.
دو: از کانالی شروع کنید که پیام واقعاً از آنجا میآید. در بسیاری از سازمانهای ایرانی، بیشتر ارتباط در واتساپ و بله است، نه در سامانهٔ داخلی. پروژهای که از سامانهٔ داخلی شروع کند، جایی را بهبود میدهد که مشتری آنجا نیست.
سه: تقویم کاری را جدی بگیرید. پنجشنبه و جمعه، تعطیلات رسمی، ایام نوروز. سیستمی که اینها را نداند وعدههایی میدهد که در آن روز کسی نیست انجامشان بدهد — و این سادهترین چیزی است که فراموش میشود.
چهار: مقاومت درونسازمانی را پیشبینی کنید. کارمندی که فکر کند این سیستم جای او را میگیرد، در اجرا همکاری نمیکند. راهش شفافیت است: بگویید کدام کارها را برمیدارد و کدام را نه، و چه چیزی بهجایش از آن آدم انتظار میرود.
پنج: فارسیِ واقعی را امتحان کنید، نه فارسیِ کتابی. پیامهای واقعی سازمان شما پر از غلط تایپی، فینگلیش و جملههای نصفه است. نمایش فروشنده همیشه با متن تمیز است.
آنچه باید بسنجید
یک عدد کافی است و باید پیش از شروع ثبت شود، وگرنه هیچ مقایسهای ممکن نیست.
برای کاربردی که انتخاب کردهاید بپرسید: پیش از این، از هر ده مورد چند تا به نتیجه میرسید؟ و حالا چند تا؟
«نتیجه» را خودتان تعریف کنید — سفارش، قرار، تیکت بستهشده، یا حتی یک «نه» روشن. مهم این است که پیش از راهاندازی تعریف شده باشد.
عددهایی که ابزارها نشان میدهند — تعداد گفتگو، سرعت پاسخ، ساعتهای پوشش — همیشه خوباند و هیچکدام کار سازمان نیست.
جمعبندی
پیادهسازی هوشواره — همان که هوش مصنوعی مینامیمش — در سازمان، بیشتر از آنکه پروژهٔ فنی باشد، پروژهٔ تعریفکردن است.
سختترین بخشش نوشتن کد نیست؛ نشستن و مشخص کردن این است که کدام کار، با چه حدی، به دست چه کسی، و با چه معیاری. سازمانی که این چهار را روشن کرده باشد، از سیستمی متوسط نتیجهٔ خوب میگیرد. سازمانی که روشن نکرده باشد، از توانمندترین سیستم دنیا هم فقط هزینه میگیرد.
و اگر امروز نمیتوانید یک کاربرد پیدا کنید که هر چهار شرط را داشته باشد، درستترین کار این است که شروع نکنید و بهجایش یک ماه بگذارید تا معلوم شود مشکل واقعی کجاست.
اینکه تا کجا باید به چنین سیستمی اختیار داد، در نوشتهٔ هوش مصنوعی عاملی چیست و کجا نباید به آن اختیار داد باز شده است.
چهار پرسش که در جلسهٔ فروش باید بپرسید
اگر فروشندهای برای سازمان شما پیشنهاد آورده، این چهار پرسش بیشتر از هر ارائهای به شما میگویند با چه کسی طرفید:
«سیستم چه کاری را مجاز نیست انجام دهد؟» فهرست بخواهید، نه اطمینان کلامی. اگر فهرست وجود ندارد، کسی به آن فکر نکرده.
«این محدودیتها کجا نوشته شدهاند؟» اگر پاسخ «در دستور متنی سیستم» باشد، آن یک توصیه است نه قاعده. قاعده وقتی است که سیستم اصلاً به آن داده دسترسی نداشته باشد.
«چه خطاهایی در پروژههای قبلی داشتید و چه کردید؟» فروشندهای که میگوید هیچوقت مشکلی نداشته، یا سیستمش جدی به کار نیفتاده یا حقیقت را نمیگوید.
«اگر قرارداد را قطع کنیم، دادههای ما را چطور تحویل میگیریم؟» گفتگوهای مشتریان و کارکنان شما دارایی سازمان است. پاسخ مبهم یعنی سرمایهای میسازید که در دست دیگری میماند.
سه شکست سازمانی که ربطی به فناوری ندارند
اینها را بیشتر از خطاهای فنی دیدهام و هیچ ابزاری جلویشان را نمیگیرد.
آزمایشی که تمام نمیشود. پروژه بهعنوان «پایلوت» شروع میشود و هیچوقت تصمیمی دربارهٔ ادامه یا توقفش گرفته نمیشود. سال بعد هنوز پایلوت است و کسی نمیداند مسئولش کیست. راهش این است که از روز اول تاریخ تصمیم را در تقویم بگذارید: در فلان روز، بر اساس فلان عدد، ادامه میدهیم یا متوقف میکنیم.
سیستمی که کسی بهروزش نمیکند. کسی که راهاندازی کرده رفته، و حالا هر تغییری یک پروژهٔ کوچک است. سیستمی که سه ماه دست نخورده، دارد اطلاعات قدیمی را با اطمینان کامل تحویل مشتری میدهد.
عددی که خوب است در حالی که هیچ چیز بهتر نشده. گزارش میگوید هزار گفتگو انجام شده و زمان پاسخ نود ثانیه است. هر دو درستاند و هیچکدام نمیگوید کار سازمان بهتر شده. برای همین است که معیار باید پیش از شروع و بر حسب نتیجهٔ کاری تعریف شود، نه بر حسب فعالیت سیستم.
پیاده سازی هوش مصنوعی در سازمان، اگر با یک کارِ کوچکِ اندازهگیریشدنی شروع شود، ریسکش از یک پروژهٔ بزرگ کمتر است و درسش بیشتر.
اگر میخواهید ببینید این تصمیمها پیش از هر کدی چه شکلی گرفته میشوند، سیستمعامل هوش مصنوعی چیست سه اصطلاحی را که معمولاً یکی گرفته میشوند از هم جدا میکند، و هوش مصنوعی عاملی و مرزهایش دربارهٔ حد اختیار است.