راه‌حل مدل عملیاتی محصول چابک برای مشکل پذیرش Copilot در مایکروسافت

مشکل مایکروسافت در Copilot، مدل نیست؛ مدل عملیاتی است.

در طول سال گذشته، مقالات و یادداشت‌های متعددی در انجمن‌های تخصصی اشاره کرده‌اند که استقرار Copilot در سازمان‌ها کندتر از حد انتظار پیش می‌رود: شرکت‌ها تعداد زیادی لایسنس خریداری می‌کنند، اما استفاده از آن سطحی باقی می‌ماند، یکپارچه‌سازی‌ها ناهماهنگ به نظر می‌رسد و برخی مدیران در مورد دستیابی به رشد واقعی بهره‌وری تردید دارند. برای نمونه، می‌توانید تحلیل Lighthouse درباره واقعیت استقرار Copilot در Microsoft 365 و همچنین بررسی‌های جدیدتر درباره موانع پذیرش و چالش‌های ادغام این ابزار را مطالعه کنید.

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

از منظر مدل عملیاتی محصول چابک (APOM)، این دقیقاً همان چیزی است که باید انتظار داشت وقتی یک قابلیت قدرتمند در دل یک محیط مبتنی بر پروژه و متمرکز بر ابزار رها می‌شود. مدل هوش مصنوعی چشمگیر است. اما مدل عملیاتی پیرامون آن ضعیف است.

در این نوشته، ویژگی‌های APOM را با چالش‌های واقعی پذیرش Copilot مرتبط می‌کنم و گام‌های عملی‌ای ارائه می‌دهم که متخصصان اسکرام می‌توانند برای کمک به سازمان‌های خود بردارند تا «فعال‌سازی Copilot» را به عنوان یک محصول با مدل عملیاتی مختص خودش در نظر بگیرند.

نگاه به Copilot از دریچه APOM

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

وقتی به روند راه‌اندازی Copilot نگاه می‌کنم، الگوهایی را می‌بینم که با این ویژگی‌ها در تضاد است:

• لایسنس‌ها به صورت متمرکز خریداری می‌شوند، اما هیچ تعریف یا مالکیت مشخصی برای «ارزش Copilot» در یک حوزه خاص وجود ندارد.

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

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

APOM به ما زبانی و ساختاری برای تغییر این وضعیت می‌دهد.

۱. «فعال‌سازی Copilot» را یک محصول در نظر بگیرید

APOM تأکید می‌کند که هر محصول، مدل عملیاتی منحصربه‌فردی دارد که متناسب با بافتار آن طراحی شده است. برای Copilot، این به معنای توقف تفکر صرفاً در قالب «فعال کردن Copilot برای همه» و در عوض، تعریف محصولات مشخص مرتبط با Copilot است.

نمونه‌ها:

• «فعال‌سازی Copilot فروش» – متمرکز بر مدیریت فرصت‌ها، پیشنهادها و ارتباطات حساب‌ها.

• «فعال‌سازی Copilot خدمات مشتری» – متمرکز بر مدیریت درخواست‌ها، بازیابی دانش و خلاصه‌سازی تعاملات.

• «فعال‌سازی Copilot ارتباطات داخلی» – متمرکز بر نگارش، خلاصه‌سازی و ترجمه محتوای داخلی.

هر یک از این محصولات فعال‌سازی Copilot باید دارای این موارد باشند:

• یک هدف محصول (مثلاً: «کاهش ۳۰ درصدی زمان آماده‌سازی پیشنهادها برای مشتری همراه با بهبود کیفیت»).

• یک مالک محصول که مسئول حداکثرسازی ارزش است.

• یک بک‌لاگ که شامل کشف نیازها، پیکربندی، تغییرات گردش کار، آموزش و اندازه‌گیری باشد.

این رویکرد با ایده APOM همسو است که هر محصول، مدل عملیاتی خودش را مالک است، نه اینکه یک مدل عمومی را به ارث ببرد.

۲. پذیرش Copilot را کلی و کامل کنید

دو ویژگی دیگر APOM، کلی‌نگری و کامل بودن است.

کلی‌نگری به معنای در نظر گرفتن تغییرات مدل عملیاتی در سراسر انگیزه‌ها، ساختارها، فرآیندها و ابزارهاست. در بسیاری از راه‌اندازی‌های Copilot:

• به تیم‌ها گفته می‌شود «با Copilot آزمایش کنید» اما معیارهای عملکرد همچنان حجم خروجی فردی را پاداش می‌دهند، نه بهبود جریان کار یا کاهش اتلاف.

• حاکمیت، امنیت و آمادگی داده‌ها جدا از توسعه محصول مدیریت می‌شوند که به جای تسهیل آزمایش، ایجاد اصطکاک و ترس می‌کند.

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

• یک گروه محصول کامل Copilot برای فروش باید شامل افرادی باشد که سفر مشتری، چشم‌انداز داده‌ها، پیکربندی M365 و رویکرد تغییر را درک می‌کنند.

• این گروه باید بتواند سناریوهای ارزشمند Copilot را کشف کند، تغییرات پیکربندی و محتوا را تحویل دهد و از روش جدید کاری در محیط عملیاتی پشتیبانی کند.

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

۳. پذیرش Copilot را بر پایه شواهد و تجربه‌گرایی بنا کنید

APOM، تجربه‌گرایی اسکرام را با مدیریت مبتنی بر شواهد (EBM) برای پشتیبانی از تصمیمات محصول در مقیاس گسترش می‌دهد. این دقیقاً چیزی است که پذیرش Copilot اغلب فاقد آن است.

به جای اندازه‌گیری موفقیت Copilot با:

• تعداد لایسنس‌های خریداری شده، یا

• تعداد کاربرانی که یک بار Copilot را امتحان کرده‌اند،

می‌توانیم از معیارهای شبیه به EBM استفاده کنیم مانند:

• ارزش جاری: زمان ذخیره‌شده در گردش کارهای خاص، کیفیت خروجی‌ها، رضایت ذی‌نفعان.

• ارزش محقق‌نشده: فرآیندهای باارزشی که هنوز با Copilot بازطراحی نشده‌اند.

• توانایی نوآوری: سرعتی که تیم‌ها می‌توانند با سناریوهای جدید Copilot آزمایش کرده و آن‌ها را بهبود بخشند.

• زمان عرضه به بازار: مدت زمان از ایده‌پردازی برای یک گردش کار مبتنی بر Copilot تا اولین استفاده از آن در محیط عملیاتی.

تیم‌های اسکرام سپس می‌توانند:

• اسپرینت‌ها را با فرضیه‌های صریح درباره چگونگی بهبود یک گردش کار توسط Copilot آغاز کنند.

• از بازبینی اسپرینت‌ها برای بررسی هم تغییرات محصول (محتوا، دستورات، اتوماسیون) و هم تأثیر قابل اندازه‌گیری بر جریان کار و نتایج استفاده کنند.

• بک‌لاگ و مدل عملیاتی خود را بر اساس شواهد، نه نظرات، تطبیق دهند.

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

۴. گروه‌های محصول حول Copilot را توانمند سازید

۵. مدیریت تغییر را در مدل عملیاتی بگنجانید

یکی از مهم‌ترین ویژگی‌های APOM، «ادغام مدیریت تغییر» است. دنبال کردن یک مدل محصول، یک حالت نهایی نیست؛ مدل عملیاتی باید به طور مستمر بر اساس آموخته‌ها تکامل یابد.

برای Copilot، این به معنای:

• در نظر گرفتن فعالیت‌های مدیریت تغییر (ارتباطات، آموزش، مربی‌گری، تغییر سیاست‌ها) به عنوان کاری در بک‌لاگ محصول، نه به عنوان «پروژه‌های استقرار» جداگانه.

• ایجاد یک گروه کوچک مسئول برای مشاهده عملکرد مدل عملیاتی Copilot در سراسر محصولات و پیشنهاد تغییرات در ساختار، انگیزه‌ها و حاکمیت.

• استفاده از داده‌های تجربی حاصل از استفاده از Copilot و معیارهای EBM برای هدایت این تغییرات.

سرپرستان اسکرام و مربیان چابکی می‌توانند در اینجا نقش کلیدی ایفا کنند با:

• آشکار کردن موانع پذیرش Copilot.

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

۶. متخصصان اسکرام اکنون چه می‌توانند بکنند؟

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

گام‌های عملی بعدی عبارتند از:

• در بافتار خود، یک محصول فعال‌شده با Copilot را به وضوح تعریف کنید. مشتری کیست؟ به دنبال کدام نتیجه هستید؟

• از ویژگی‌های APOM به عنوان یک چک‌لیست استفاده کنید: آیا رویکرد Copilot شما منحصربه‌فرد، کلی، مبتنی بر شواهد، تجربه‌گرا، کامل و پشتیبانی‌شده با مدیریت تغییر ادغام‌شده است؟ شکاف‌ها کجا هستند؟

• معیارهای EBM را برای Copilot معرفی کنید: روی مجموعه کوچکی از متریک‌ها که ارزش، جریان کار و توانایی نوآوری را ثبت می‌کنند توافق کنید و به طور مرتب آن‌ها را بازبینی کنید.

• به ایجاد یا تأثیرگذاری بر یک گروه محصول Copilot برای حوزه خود کمک کنید که دارای قدرت تصمیم‌گیری واقعی بر فرآیندها، قالب‌ها و آموزش باشد—نه فقط پیکربندی ابزار.

با نگاه به Copilot از لنز یک مدل عملیاتی محصول چابک، می‌توانیم از «هوش مصنوعی به عنوان یک قابلیت» فراتر رفته و شروع به در نظر گرفتن آن به عنوان بخشی از مدل عملیاتی محصول خود کنیم. این جایی است که اسکرام، EBM و APOM در کنار هم می‌توانند به سازمان‌ها کمک کنند تا Copilot را از یک آزمایش پرهزینه به بخشی منظم و ارزش‌آفرین از نحوه انجام کار تبدیل کنند.