پرسشی که جلسه را به عقب برگرداند
مدیرعامل هنوز کنار نمایشگر ایستاده بود. زیر عنوان «دستیار هوشمند سازمان»، سه انتظار متفاوت نوشته بودند: پاسخ به پرسش‌های کارکنان، پیش‌بردن درخواست‌ها و کمک به تصمیم مدیران.
پرسید: «خوب، مسئلهٔ اصلی هر واحد چیه؟ کارکنان جواب رو پیدا نمی‌کنن، اسناد متناقضه یا فرایند رسیدگی طولانیه؟»
مدیر منابع انسانی گفت: «کارشناس‌های ما بخش زیادی از روز رو صرف جواب دادن به سؤال‌های تکراری می‌کنن.»
مدیر عملیات گفت: «برای ما مشکل اینه که درخواست از یک واحد به واحد دیگه می‌ره و معلوم نیست کجا مونده.»
مدیر مالی پوشه‌اش را بست: «من هم می‌خوام وقتی دربارهٔ یک هزینه سؤال می‌کنم، مجبور نباشم از چند نفر جداگانه توضیح بگیرم.»
مدیر فناوری به سه جمله نگاه کرد. «اگر برای همهٔ این‌ها یک چت‌بات بسازیم، از کجا می‌فهمیم کدوم مشکل واقعاً حل شده؟»
چند لحظه کسی چیزی نگفت. روی میز، پیشنهاد فنی دستیار باز بود؛ چند صفحه دربارهٔ مدل، زیرساخت و قابلیت‌ها. اما برای پاسخ به این پرسش، صفحه‌ای نداشت.
مدیرعامل گفت: «فعلاً پیشنهاد فنی رو ببندیم. قبل از اینکه بگیم چی می‌خریم، بنویسیم چه چیزی باید بهتر بشه.»
در درس چهارم دیدیم که عنوان یک سامانه، ماهیت و قلمرو حکمرانی آن را روشن نمی‌کند. برای تشخیص نوع کنترل، باید بدانیم سامانه چگونه کار می‌کند و خروجی آن چه نقشی دارد.
گفت‌وگوی مدیران اکنون یک قدم عقب‌تر رفته است: هرکدام از قابلیت‌های درخواستی قرار است کدام مسئلهٔ سازمان را حل کنند؟ پاسخ‌گویی به پرسش‌ها، پیگیری درخواست و کمک به تصمیم، زیر یک نام جمع شده‌اند؛ درحالی‌که مدیران هنوز دربارهٔ چیزی که باید بهتر شود توافق ندارند. پیشنهاد فنی آماده است، اما صورت‌مسئله هنوز صفحه‌ای در آن ندارد. «دستیار می‌خواهیم» آغاز گفت‌وگوست؛ تصمیم سرمایه‌گذاری به تعریف روشن‌تری نیاز دارد.
این درس، اسلایدهای ۲۷ تا ۳۵ ارائه را به ترتیب دنبال می‌کند؛ از آغاز «حکمرانی مسئله و سبد سرمایه‌گذاری» تا سومین کارت تحول. در این قسمت بر شناخت و صورت‌بندی مسئله تمرکز می‌کنیم؛ منشور پروژه، سبد سرمایه‌گذاری و شواهد مورد انتظار از پایلوت، ادامهٔ همین بحث در درس بعد خواهند بود.
فناوری، آخرین حلقهٔ حل مسئله است
مسیر حل مسئله از شناخت «سازمان» آغاز می‌شود: هدف چیست، چه تصمیمی باید گرفته شود، چه فرایندی درگیر است، چه کسانی از نتیجه اثر می‌پذیرند و چه محدودیت‌هایی وجود دارد؟
پس از آن، به «مسئله» می‌رسیم: فاصلهٔ وضع موجود و مطلوب کجاست؟ چه نشانه‌ای از این فاصله داریم؟ علت احتمالی چیست و خط مبنای مقایسه کدام است؟ تازه پس از روشن‌شدن این‌ها، می‌توانیم دربارهٔ راه‌حل صحبت کنیم؛ از اصلاح قاعده و فرایند یا آموزش، تا نرم‌افزار، خودکارسازی و هوش مصنوعی.
برای مثال، «کارکنان سؤال‌های تکراری می‌پرسند» یک نشانه است. ممکن است اطلاعات به‌سختی پیدا شود، متن مقررات فهم‌پذیر نباشد، کارکنان از وجود منابع خبر نداشته باشند یا برای تشخیص وضعیت خاص خود به کارشناس نیاز داشته باشند. هر علت، مسیر متفاوتی پیش پای سازمان می‌گذارد.
خط مبنا نیز باید به همین مسئله مربوط باشد. اکنون پاسخ‌گویی چقدر طول می‌کشد؟ چه مقدار از وقت کارشناسان صرف آن می‌شود؟ کدام سؤال‌ها تکرار می‌شوند و چه تعداد از آن‌ها بدون ارجاع قابل پاسخ‌اند؟ بدون این شناخت، حتی یک سامانهٔ خوش‌ظاهر هم ممکن است تغییری در گرفتاری اصلی ایجاد نکند.
اگر شناخت سازمان و مسئله را حذف کنیم، فناوری فقط پاسخ دقیق‌تری به سؤال اشتباه می‌دهد.
مدیر منابع انسانی گفت: «پس بنویسیم کاهش سؤال‌های تکراری.»
مدیرعامل پرسید: «اگر کارکنان دیگه سؤال نپرسن، ولی کارشون هم راه نیفته، موفق شدیم؟»
مدیر منابع انسانی مکث کرد. «نه. باید بتونن جواب قابل استفاده بگیرن، بدون اینکه برای هر سؤال منتظر کارشناس بمونن.»
مدیر فناوری کنار جمله نوشت: «پیدا کردن پاسخ قابل استفاده؛ زمان انتظار؛ میزان نیاز به ارجاع.»
تعداد سؤال‌ها هنوز مهم بود، اما دیگر تنها چیزی نبود که قرار بود اندازه بگیرند.
حکمرانی از تبدیل مسئله به پروژه آغاز می‌شود
برای تبدیل مسئله به پروژه، چهار مرحله را دنبال می‌کنیم: صورت‌بندی مسئله، طراحی گزینه‌های راه‌حل، آزمایش و تولید شواهد، و تصمیم برای ادامه، اصلاح یا توقف.
در مرحلهٔ نخست باید روشن شود چه نشانه‌ای دیده‌ایم، کاربر کیست و قرار است از کدام تصمیم یا فعالیت پشتیبانی کنیم. تأیید مسئله و مالک آن، در همین نقطه معنا پیدا می‌کند. اگر قرار باشد یک نفر هم‌زمان چند کلاه داشته باشد یا چند نفر مسئولیتی را با هم انجام دهند، باز هم باید معلوم باشد چه کسی با چه اختیاری پاسخ‌گویی را بر عهده گرفته است.
در مرحلهٔ دوم، گزینه‌ها را طراحی و مقایسه می‌کنیم: تغییر فرایند، قاعده، هوش تجاری، خودکارسازی یا هوش مصنوعی. تأیید گزینه و بودجهٔ آزمایش، یعنی سازمان برای بررسی یک مسیر مشخص، منابع اختصاص می‌دهد.
مرحلهٔ سوم باید دربارهٔ امکان‌پذیری، ارزش و ریسک شواهد تولید کند. سپس، در مرحلهٔ چهارم، بر پایهٔ آن شواهد دربارهٔ ادامه، بازطراحی، توقف یا گسترش تصمیم می‌گیریم.
حکمرانی را نمی‌توان به امضای نهایی پیش از استقرار محدود کرد. هنگامی که سازمان یک نشانه را «مسئلهٔ مهم» می‌نامد، برای آن مالک تعیین می‌کند و بررسی یک راه‌حل را تأمین مالی می‌کند، بخشی از تصمیم‌های اصلی را گرفته است.
مدیر مالی پرسید: «پس بودجهٔ آزمایش رو برای چی تصویب کنیم؟ برای ساخت دستیار یا برای بررسی راه کم‌کردن انتظار کارکنان؟»
مدیر فناوری گفت: «اگر از اول فقط ساخت دستیار رو تصویب کنیم، بررسی گزینه‌های دیگه عملاً از دستور کار خارج می‌شه.»
مدیرعامل عنوان ردیف بودجه را تغییر داد: «بررسی و آزمایش راه بهبود پاسخ‌گویی به کارکنان.»
بعد پرسید: «چه کسی تأیید می‌کنه که مسئله رو درست فهمیدیم؟»
نگاه‌ها به مدیر منابع انسانی برگشت. جلسه، پیش از خرید فناوری، به یک تصمیم دربارهٔ مسئولیت رسیده بود.
همهٔ مسئله‌ها، یک جنس ندارند
برای انتخاب شیوهٔ بررسی، باید میان روشن‌بودن صورت مسئله و وجود تعارض دربارهٔ خود مسئله تفاوت بگذاریم.
در مسئلهٔ خوش‌فرم، هدف، ورودی‌ها، قواعد و معیار تشخیص پاسخ نسبتاً روشن‌اند. بررسی احراز شرایط دریافت یک مزیت، وقتی قاعده و اطلاعات معتبر در اختیار داریم، می‌تواند به چنین وضعیتی نزدیک باشد.
در مسئلهٔ بدفرم، بخشی از هدف، اطلاعات، متغیرهای مؤثر یا معیار ارزیابی هنوز روشن نیست. بررسی و آزمایش می‌تواند به شناخت بهتر این ابهام‌ها کمک کند.
مسائل Wicked، که در این درس آن‌ها را «مسائل بدخیم و درهم‌تنیده» یا مطابق اسلایدها، به صورت طنز، «لاینحل» می‌نامیم، فقط اطلاعات ناقص ندارند. ذی‌نفعان ممکن است دربارهٔ تعریف مسئله، هدف مطلوب و قابل قبول بودن پیامدها اختلاف داشته باشند. خود مداخله نیز می‌تواند وضعیت و رفتار افراد را تغییر دهد. این سه عنوان، سه طبقهٔ کاملاً جدا و جامع نیستند؛ یک مسئلهٔ بدخیم می‌تواند زیرمسئله‌هایی با صورت روشن داشته باشد.
می‌توان برای اقدام، دامنه‌ای محدود و زیرمسئله‌هایی قابل بررسی تعریف کرد؛ اما حل آن زیرمسئله‌ها الزاماً تعارض اصلی را برطرف نمی‌کند. اگر کارکنان، دستیار را مقدمهٔ حذف شغل بدانند، کاهش زمان پاسخ‌گویی به‌تنهایی پاسخ این نگرانی نیست. انتخاب اینکه کدام پیامد را اندازه بگیریم و کدام موضوع را خارج از دامنه بگذاریم، خودش تصمیمی مدیریتی و قابل پرسش است.
بنابراین، هدف صورت‌بندی فقط ساده‌کردن مسئله نیست. باید روشن کنیم چه چیزی را برای اقدام محدود کرده‌ایم، چه وابستگی‌هایی باقی مانده‌اند، چه کسانی از این انتخاب متأثر می‌شوند و کدام اختلاف هنوز حل نشده است.
گاهی لازم است ابعاد مورد بررسی را تغییر دهیم؛ مثلاً از یک درخواست کلی مانند «رفع نارضایتی کارکنان» به زمان انتظار، اعتبار اطلاعات و مسیر رسیدگی برسیم. گاهی هم همان موضوع را در یک نمایش دیگر بهتر می‌فهمیم. تجزیهٔ فوریه مثال روشنی از این تغییر نگاه است.
یک موج تناوبی را تصور کنید که پر از برآمدگی و فرورفتگی است و شکل آن در نگاه اول عجیب و پیچیده به نظر می‌رسد. در تحلیل فوریه، آن را بر حسب مؤلفه‌های سینوسی با دامنه و بسامدهای متفاوت توصیف می‌کنیم؛ موج‌های ساده‌ای که با جمع‌شدن، شکل موج اصلی را می‌سازند. به‌جای دنبال‌کردن تک‌تک پیچ‌وخم‌ها، می‌پرسیم چه مؤلفه‌هایی با چه سهمی در آن حضور دارند. با نگه‌داشتن مؤلفه‌های اصلی نیز می‌توان تقریب ساده‌تری از موج ساخت. درس سری فوریه در MIT همین شیوهٔ نمایش را توضیح می‌دهد.
موج همان موج است، اما ساختارش در نمایش تازه آشکارتر می‌شود. درس مدیریتی این مثال، پیدا کردن زاویه‌ای است که بتوان از آن ساختار مسئله را دید و روی اجزای آن کار کرد. در پروندهٔ دستیار، وقتی «پاسخ‌گویی نامناسب» را به اعتبار منابع، پیدا کردن قاعدهٔ مرتبط و مسیر رسیدگی تقسیم می‌کنیم، برای هر بخش پرسش و مسئول مشخص‌تری پیدا می‌شود. با انتخاب یک حوزهٔ محدود و روشن‌کردن وابستگی این بخش‌ها، می‌توان آزمایشی تعریف کرد که از نتیجهٔ آن چیزی بیاموزیم.
این مثال، تمثیلی برای تغییر شیوهٔ نمایش مسئله است. در مسائل سازمانی، اجزا الزاماً مستقل یا جمع‌پذیر نیستند و رابطهٔ آن‌ها ممکن است با مداخله تغییر کند. تجزیهٔ مسئله می‌تواند محل اقدام را روشن کند، اما برای نتیجه‌گیری دربارهٔ کل سازمان باید وابستگی اجزا، بازخوردها و تعارض منافع را دوباره بررسی کرد.
مدیر عملیات گفت: «برای بعضی درخواست‌ها، مسیر رسیدگی دقیقاً معلومه. فقط کسی نمی‌دونه الان دست چه واحدیه.»
مدیر فناوری گفت: «اون قسمت رو می‌شه با ثبت وضعیت و گردش کار بررسی کرد.»
مدیر منابع انسانی پرسید: «ولی وقتی کارمند نمی‌دونه سؤالش زیر کدوم مقررات قرار می‌گیره چی؟»
مدیرعامل دو مورد را در دو سطر جدا نوشت. هر دو به کارکنان مربوط بودند، اما قرار نبود به‌خاطر این شباهت، یک راه‌حل مشترک به آن‌ها تحمیل شود.
هشت تله‌ای که پاسخ را در صورت سؤال پنهان می‌کنند
ممکن است ظاهراً دربارهٔ مسئله صحبت کنیم، اما جمله‌ای که نوشته‌ایم فقط خرید یا تصمیم از پیش انتخاب‌شده را توجیه کند. هشت تله را می‌توان در همان درخواست «دستیار سازمانی» دید:
| تله | چگونه وارد صورت‌مسئله می‌شود؟ | نمونه در پروندهٔ دستیار |
|---|---|---|
| Anchoring؛ قفل‌شدن روی پاسخ | سؤال طوری نوشته می‌شود که فقط یک پاسخ از پیش مطلوب داشته باشد. | «چگونه ثابت کنیم چت‌بات بهترین راه پاسخ‌گویی است؟» |
| Solutioneering؛ وابسته‌کردن مسئله به فناوری | انتخاب فناوری، پیش از بررسی مسئله انجام می‌شود. | «مسئلهٔ ما نداشتن یک سامانهٔ RAG است.» |
| Hamstringing؛ ساختن قیدهای مصنوعی | فرض‌هایی را بدون بررسی، محدودیت قطعی می‌گیریم. | «راه‌حل باید بدون هیچ تغییری در فرایند فعلی کار کند.» |
| Narrowing؛ محدودکردن میدان دید | فقط بخشی از وضعیت واقعی در تعریف مسئله جا می‌گیرد. | «فقط سؤال‌های ساده را بررسی کنیم و موارد ارجاع را از محاسبه کنار بگذاریم.» |
| Wishlisting؛ نوشتن فهرست آرزوها | مجموعهٔ قابلیت‌های دلخواه، جای مسئله را می‌گیرد. | «پاسخ بدهد، گزارش بسازد، درخواست ثبت کند و کارشناس هم باشد.» |
| Buzzwording؛ صورت‌بندی با نام‌های پرآوازه | نام محصول و سرویس، مبنای تعریف مسئله می‌شود. | «برای سازمان یک ChatGPT می‌خواهیم.» |
| Presuming؛ فرض‌گرفتن رفتار کاربر | بدون شواهد دربارهٔ رفتار و نیاز کاربر حکم می‌دهیم. | «اگر چت‌بات داشته باشیم، کارکنان دیگر تماس نمی‌گیرند.» |
| Catastrophizing؛ شروع از فاجعهٔ فرضی | بدترین حالت فرضی، بی‌بررسی به مسئلهٔ اصلی امروز تبدیل می‌شود. | «سامانه را برای روزی طراحی کنیم که هیچ کارشناسی در دسترس نیست و همهٔ کارکنان هم‌زمان پاسخ می‌خواهند.» |
این جدول، گزیده و بازپردازی آموزشی چند خطای صورت‌بندی مسئله است؛ فهرستی جامع یا طبقه‌بندی استاندارد خطاهای شناختی نیست. بخشی از نام‌گذاری‌ها و توضیح‌ها با ارائهٔ «Stop Doing What You’re Told» از Stephen P. Anderson تطبیق دارد.
این تله‌ها به معنای بی‌اهمیت‌بودن محدودیت یا سناریوی خسارت نیستند. محدودیت واقعی باید ثبت شود و خطر جدی باید بررسی شود. مسئله از جایی آغاز می‌شود که فرض تأییدنشده، بدون بررسی مبنای طراحی و هزینه می‌شود.
برای بازبینی صورت‌مسئله، می‌توان پرسید: کدام بخش این جمله یک مشاهده است؟ کدام بخش برداشت ماست؟ کجا نام راه‌حل را جای مشکل گذاشته‌ایم؟ کدام رفتار کاربر را هنوز ندیده‌ایم، اما قطعی فرض کرده‌ایم؟
مدیر فناوری پیشنهاد اولیه را دوباره باز کرد. در صفحهٔ نخست نوشته بود: «با استقرار دستیار هوشمند، تماس کارکنان با کارشناسان حذف خواهد شد.»
گفت: «این جمله رو هنوز نمی‌تونیم قول بدیم.»
مدیر منابع انسانی گفت: «بعضی‌ها حتی بعد از خوندن جواب هم می‌خوان دربارهٔ شرایط خودشون با کارشناس صحبت کنن.»
مدیرعامل گفت: «پس حذف تماس رو از هدف قطعی برداریم. اول ببینیم کدوم تماس‌ها واقعاً قابل کاهش‌اند و کدوم‌ها باید باقی بمونن.»
یکی از وعده‌های پررنگ پیشنهاد حذف شد؛ در عوض، چیزی پیدا کرده بودند که می‌شد درباره‌اش تحقیق کرد.
کارایی و اثربخشی را جدا بسنجیم
برای تصمیم دربارهٔ عمق تحلیل، تعداد کنترل‌ها و پیچیدگی راهکار، باید منابع مصرف‌شده و میزان تحقق هدف را جداگانه بررسی کنیم.
کارایی (Efficiency) به نسبت نتیجه و منابع مصرف‌شده مربوط است: برای رسیدن به پاسخ، چه مقدار زمان، هزینه، توان پردازشی و کار انسانی صرف می‌کنیم؟ در پروندهٔ دستیار، هزینهٔ پاسخ فقط مصرف مدل نیست؛ وقتی کارشناس باید پاسخ را دوباره بررسی کند یا درخواست را میان واحدها بگرداند، آن زمان و کار هم بخشی از منابع مصرف‌شده‌اند.
اثربخشی (Effectiveness) به میزان تحقق هدف مربوط است: آیا کارمند پاسخ معتبر گرفته، تکلیفش روشن شده و کارش پیش رفته است؟ پاسخ چندثانیه‌ای به پرسشی که مشکل اصلی کاربر را حل نمی‌کند، نتیجهٔ مورد انتظار پروژه را فراهم نکرده است. باید کل مسیر رسیدن به نتیجه را ببینیم.
راه‌حل خوب، با منابع متناسب به نتیجهٔ مورد نیاز می‌رسد. برای افزودن هر مرحلهٔ تحلیل، کنترل یا فناوری، باید روشن باشد چه تغییری در حل مسئله ایجاد می‌کند.
برای نمونه، می‌توان مدل را سریع‌تر کرد، اما تا وقتی از اسناد متناقض پاسخ می‌گیرد، کاربر همچنان به جواب قابل اتکا نمی‌رسد. از سوی دیگر، اگر برای هر پرسش ساده چند مرحلهٔ تأیید بگذاریم، زمان و هزینهٔ رسیدگی بالا می‌رود. باید بدانیم هر کنترل کدام خطا را کاهش می‌دهد و این بهبود در برابر منابعی که مصرف می‌کند، چه ارزشی دارد.
نمودار علت‌یابی در میانهٔ اسلاید، ابزاری برای بررسی عمیق‌تر مسئله است؛ از نشانه و علت فنی تا سازوکارهای سازمانی. این بررسی به ما کمک می‌کند محل مداخله را درست انتخاب کنیم. اگر ناسازگاری منابع، علت پاسخ‌های متفاوت باشد، روشن‌کردن مرجع معتبر می‌تواند هم کیفیت نتیجه را بهتر کند و هم نیاز به بررسی و اصلاح مکرر پاسخ‌ها را کاهش دهد. چنین تغییری، کارایی و اثربخشی را با هم بهبود می‌دهد.
پس دامنهٔ تحلیل و راهکار را متناسب با مسئله انتخاب می‌کنیم. برای یک پرسش با قاعدهٔ روشن، همان قاعده و مسیر سادهٔ رسیدگی کافی است. برای مسئله‌ای با منابع متعارض یا پیامد حساس، بررسی عمیق‌تر و کنترل بیشتر ارزش پیدا می‌کند. معیار تصمیم این است که با این پیچیدگی و هزینه، چه مقدار به حل مسئله نزدیک‌تر می‌شویم.
مدیر منابع انسانی گفت: «می‌تونیم قبل از رسیدن جواب به کارمند، یک مرحلهٔ بازبینی دیگه بذاریم.»
مسئول ریسک و انطباق پرسید: «کدوم جواب‌ها به این بررسی نیاز دارن و قرار است چه خطایی رو پیدا کنه؟»
مدیر فناوری گفت: «اگر همهٔ جواب‌ها رو بفرستیم، دوباره یک صف انتظار درست می‌کنیم. بعضی سؤال‌ها فقط نشانی یک فرم رو می‌خوان.»
مدیرعامل گفت: «پس موارد نیازمند بررسی رو جدا کنیم. بعد هم ببینیم همکارمون چقدر منتظر می‌مونه و آخرش جواب قابل استفاده می‌گیره یا نه.»
کنار پیشنهاد بازبینی، دو موضوع ثبت شد: منابعی که مصرف می‌کند و نتیجه‌ای که باید بهتر کند.
اختلاف بر سر راه‌حل، گاهی از اختلاف در دیدن مسئله می‌آید
زاویهٔ نگاه، تعیین می‌کند مسئله را با چه متغیرها و رابطه‌هایی تعریف کنیم. وقتی این صورت‌بندی عوض شود، راه‌هایی به چشم می‌آیند که پیش‌تر در محدودهٔ سؤال ما نبودند. کاری که پیچیده به نظر می‌رسید، گاهی با همین تغییر نگاه، راه‌حل ساده‌ای پیدا می‌کند.
برای نمونه، می‌توان مسائل فیزیک را بر اساس ظاهرشان دید: جعبه، سطح شیبدار یا فنر. نگاه دیگر، رابطهٔ انرژی را در همان مسئله تشخیص می‌دهد. در بعضی مسائل، دنبال‌کردن نیروها و شتاب در طول مسیر، محاسبه‌ای طولانی می‌سازد؛ اما نگاه از منظر انرژی، رابطهٔ ابتدا و انتهای حرکت را روشن می‌کند و مسیر حل کوتاه‌تر می‌شود. وضعیت فیزیکی همان است؛ کمیت و رابطه‌ای که مبنای حل قرار می‌دهیم تغییر کرده‌اند.
یک مثال آموزشی دیگر، جعبه‌های خالی در خط بسته‌بندی بستنی است. کارخانه‌ای را تصور کنید که بعضی جعبه‌ها بدون محصول از خط خارج می‌شوند. اگر مسئله را «چگونه داخل همهٔ جعبه‌های بسته را ببینیم؟» تعریف کنیم، به سراغ حسگر، تصویربرداری و سامانهٔ تشخیص می‌رویم. حالا پرسش را عوض کنیم: «چگونه مانع رسیدن جعبهٔ خالی به انتهای خط شویم؟» با این نگاه، اختلاف وزن جعبهٔ پر و خالی هم به یک امکان تبدیل می‌شود. در این مثال فرض کنیم جعبه‌های خالی آن‌قدر سبک‌اند که جریان هوا آن‌ها را از مسیر کنار می‌زند و جعبه‌های پر سر جای خود می‌مانند. در چنین شرایطی، پنکه‌ای در نقطهٔ مناسب خط، راهی ساده برای جداسازی است. هدف همچنان جلوگیری از خروج جعبهٔ خالی است، اما صورت‌بندی تازه اجازه می‌دهد از یک ویژگی فیزیکی ساده استفاده کنیم. به‌جای دیدن داخل جعبه، از تفاوت وزن آن استفاده کرده‌ایم.
پیش از پیچیده‌ترکردن ابزار، ببینیم صورت سؤال ما چه راه‌هایی را از ابتدا کنار گذاشته است. گاهی با تغییر پرسش، متغیری ساده پیدا می‌شود که همان هدف را با راه کوتاه‌تری محقق می‌کند.
در پروندهٔ دستیار هم اگر پرسش را «چگونه مدلی بسازیم که به همهٔ سؤال‌های کارکنان جواب بدهد؟» بگذاریم، میدان انتخاب را از ابتدا به قابلیت‌های مدل محدود کرده‌ایم. اگر بپرسیم «کارکنان برای پیش‌بردن کارشان چه چیزی را نمی‌دانند؟»، گزینه‌های دیگری هم پیدا می‌شوند: نمایش وضعیت درخواست، روشن‌کردن مرجع رسیدگی، دسترسی مستقیم به مقررات معتبر یا پاسخ‌گویی دربارهٔ معنای همان مقررات. هرکدام مسئله و روش مناسب خود را دارند.
مدیر عملیات گفت: «بخشی از تماس‌ها فقط برای اینه که همکارمون بدونه درخواستش الان دست کیه.»
مدیر فناوری گفت: «برای این مورد می‌تونیم وضعیت همون درخواست رو مستقیم از سامانه نشون بدیم.»
مدیر منابع انسانی پرسید: «پس سؤال دربارهٔ شرایط استفاده از مزایا چی؟ اون رو از کجا می‌فهمه؟»
مدیرعامل گفت: «اون رو جدا ببینیم. اول معلوم کنیم هر سؤال چه جوابی می‌خواد. برای پیگیری درخواست، وضعیتش رو نشون بدیم؛ برای فهم مقررات هم راه مناسب خودش رو پیدا کنیم.»
یکی از کارهایی که قرار بود به توان پاسخ‌گویی مدل سپرده شود، با تغییر سؤال به نمایش وضعیت موجود در سامانه تبدیل شد. صورت‌بندی تازه، راه ساده‌تری را وارد انتخاب‌های پروژه کرده بود.
کدام محدودیت واقعی است و کدام را به ارث برده‌ایم؟
در روایت مشهور این تصویر، چند میمون در محیطی قرار دارند که در مرکز آن نردبانی به سمت چند موز گذاشته شده است. هر بار که یکی از میمون‌ها برای برداشتن موز از نردبان بالا می‌رود، سایر میمون‌ها با پاشش آب سرد مواجه می‌شوند. پس از تکرار این اتفاق، میمون‌ها یاد می‌گیرند مانع بالا رفتن یکدیگر شوند؛ حتی وقتی دیگر پاشش آب اتفاق نمی‌افتد.
در ادامه، میمون‌ها به‌تدریج با اعضای جدید جایگزین می‌شوند. میمون تازه‌وارد هم وقتی به سمت نردبان می‌رود، از سوی دیگران متوقف می‌شود؛ با اینکه خودش هرگز پاشش آب را تجربه نکرده است. سرانجام گروهی باقی می‌ماند که هیچ‌کدام دلیل اولیهٔ این رفتار را نمی‌دانند، اما همچنان مانع نزدیک‌شدن به نردبان می‌شوند.
در پروژه‌های سازمانی نیز جمله‌هایی مانند «این فرایند نباید تغییر کند»، «کاربران این کار را انجام نمی‌دهند» یا «فقط همین واحد می‌تواند پاسخ بدهد» ممکن است بارها تکرار شوند. بخشی از آن‌ها پشتوانهٔ معتبر دارند؛ بخشی هم ممکن است از تصمیم یا محدودیتی قدیمی باقی مانده باشند که دیگر کسی دلیلش را به یاد نمی‌آورد.
نمی‌توان همهٔ این محدودیت‌ها را کنار گذاشت. باید پرسید هر قید از کجا آمده است: الزام قانونی، تعهد قراردادی، ملاحظهٔ امنیتی، محدودیت منابع، تصمیم مدیریتی یا صرفاً عادتی که در طول زمان تثبیت شده است؟ آیا هنوز برقرار است؟ چه کسی اختیار بازبینی آن را دارد؟
گاهی اجرای پروژه واقعاً به رعایت یک قید وابسته است. گاهی هم بازبینی همان قید، راه‌حل ساده‌تری پیش پای سازمان می‌گذارد. هدف، حذف محدودیت‌ها نیست؛ تشخیص تفاوت میان قیدهای واقعی و فرض‌هایی است که بدون بررسی به ارث برده‌ایم.
اگر قید پروژه، دسترسی به داده است، گره کور داده برای هوش مصنوعی نسبت محرمانگی با امکان بهره‌برداری را باز می‌کند و بحث را به سمت استفادهٔ مجاز و پردازش امن می‌برد.
مدیر منابع انسانی گفت: «یک فرض دیگه هم داشتیم؛ اینکه هیچ‌کس برای پیدا کردن جواب، صفحهٔ مقررات رو باز نمی‌کنه.»
مدیرعامل پرسید: «بررسی کردیم یا چون سال‌ها این جمله رو شنیدیم، همون رو نوشتیم؟»
مدیر منابع انسانی گفت: «آمار دقیقی نداریم. باید ببینیم پیدا نمی‌کنن، نمی‌خونن یا بعد از خوندن هم تکلیفشون روشن نمی‌شه.»
مدیر فناوری گفت: «این سه حالت، سه کار متفاوت از ما می‌خوان.»
قیدی که تا آن لحظه قطعی به نظر می‌رسید، به یک پرسش قابل بررسی تبدیل شد.
کارت تحول سوم: مسئله فقط جست‌وجو نیست؛ اسناد متناقض‌اند
در ادامهٔ همان پرونده، مسئله یک بار دیگر تغییر می‌کند. سؤال مشخص است: «سقف اختیار خرید تجهیزات IT چقدر است؟» اما سه پاسخ متفاوت پیش روی ماست: ۵۰۰ میلیون ریال، ۳۰۰ میلیون ریال و یک میلیارد ریال. پشت هر پاسخ هم سندی قرار گرفته است؛ سیاست خرید، آیین‌نامهٔ مالی و اصلاحیهٔ خرید.
وجود منبع، به‌تنهایی اعتبار پاسخ را اثبات نمی‌کند. باید معلوم باشد کدام سند برای این سؤال و این وضعیت معتبر است، اصلاحیه چه دامنه‌ای دارد، کدام نسخه جایگزین شده و مرجع رفع تعارض کیست. حتی تاریخ جدیدتر نیز بدون شناخت دامنه و اعتبار سند، برای داوری کافی نیست.
این وضعیت را نمی‌توان فقط به ضعف جست‌وجو نسبت داد. ممکن است سامانه هر سه متن را درست پیدا کند و همچنان معلوم نباشد سازمان کدام حکم را معتبر می‌داند. مدلی هم که از میان آن‌ها یک جواب روان انتخاب می‌کند، ابهام سازمان را رفع نکرده است.
در اینجا موضوع به حکمرانی دانش می‌رسد: مالک محتوا، اعتبار و نسخهٔ سند، قواعد استفاده و مسیر حل تعارض باید روشن شوند. فناوری می‌تواند در یافتن منابع، آشکارکردن اختلاف و ارجاع سؤال کمک کند؛ تعیین اعتبار سازمانی سند، به مسئولیت و اختیار نیاز دارد.
تمایز رساندن دانش درست به مدل و تغییر رفتار آن را در تفاوت روش‌های بازیابی دانش و آموزش دوبارهٔ مدل با مثال‌های ساده باز کرده‌ام. این تمایز کمک می‌کند پیش از پیشنهاد آموزش دوباره، محل مسئله را پیدا کنیم.
همان منطق کلاه‌ها اینجا نیز برقرار است. قرار نیست برای هر عنوان یک سمت تازه ایجاد کنیم. ممکن است یک نفر چند مسئولیت داشته باشد یا چند نفر در نگهداری یک حوزهٔ محتوا همکاری کنند. آنچه باید روشن بماند، مسئولیت به‌روزرسانی، اختیار تأیید و مسیر پاسخ‌گویی هنگام اختلاف است.
سه پاسخ، پیش از ورود مدل
مدیر مالی برای روشن‌شدن بحث، سقف اختیار خرید تجهیزات را مثال زد. یک نفر سیاست خرید را باز کرد؛ دیگری آیین‌نامهٔ مالی را. مدیر فناوری هم اصلاحیه‌ای را از پوشهٔ واحد خود بیرون آورد.
سه عدد روی میز بود.
مدیرعامل پرسید: «کدومش معتبره؟»
مدیر مالی گفت: «باید دامنهٔ اصلاحیه و مصوبهٔ مربوط رو بررسی کنیم.»
مدیر فناوری آهسته گفت: «اگر هر سه فایل رو به دستیار بدیم، فقط کاری کردیم که سریع‌تر به هر سه برسه. هنوز نگفتیم وقتی با هم نمی‌خونن، چه کنه.»
مسئول ریسک و انطباق پرسید: «و چه کسی مسئول روشن‌کردن این تعارضه؟»
مدیرعامل به صفحهٔ اول پیشنهاد نگاه کرد؛ همان‌جا که نوشته بودند «دسترسی سریع به دانش سازمان».
زیرش نوشت: «پاسخ بر پایهٔ منبع معتبر، با نسخه و مسئول مشخص؛ تعارض‌ها باید برای بررسی ارجاع شوند.»
حالا می‌شد دربارهٔ پروژه حرف دقیق‌تری زد. پیش از تصویب، باید معلوم می‌کردند کدام حوزهٔ محتوا را انتخاب می‌کنند، چه کسی اعتبار آن را تأیید می‌کند و از آزمایش چه نتیجه‌ای انتظار دارند.
پیش از تصویب پروژه، چه چیزی را مکتوب کنیم؟
مسیر این درس، درخواست مبهم «یک دستیار می‌خواهیم» را به پرسشی مشخص‌تر رساند: چگونه کاربر به پاسخ قابل استفاده‌ای برسد که منبع معتبرش معلوم باشد و موارد تعارض، مسیر رسیدگی داشته باشند؟
صورت‌مسئله هنوز باید با شواهد و بررسی صاحبان مسئولیت تکمیل شود. اما حالا می‌دانیم صرفاً با خرید مدل یا افزودن یک رابط گفت‌وگو، همهٔ اجزای آن حل نمی‌شوند. بخشی از کار به محتوا، بخشی به فرایند و بخشی به قابلیت فنی مربوط است.
در درس بعد، اسلایدهای ۳۶ تا ۳۹ را دنبال می‌کنیم: این شناخت چگونه در منشور پروژه ثبت می‌شود، پروژه با چه معیارهایی در سبد سرمایه‌گذاری قرار می‌گیرد و پایلوت باید چه شواهدی برای تصمیم ادامه یا توقف فراهم کند؟
این درس، قسمت دوم بخش دوم «حکمرانی مسئله و سبد سرمایه‌گذاری» و تشریح اسلایدهای ۲۷ تا ۳۵ دوره است. درس قبل؛ اسلایدهای کامل دوره