تحول دیجیتال در عملیات: یک تغییر واقعی در روش کار

سه تغییری که اغلب یکی حساب می‌شوند

نگهداری برگهٔ بازرسیِ اسکن‌شده آسان‌تر است، اما شاید هنوز کسی باید آن را پیدا کند، بخواند و با برنامه‌ریز تماس بگیرد. سریع‌ترشدن پاسخ تضمین نشده است. روشن بگویید کدام بخش کار عوض می‌شود.

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

بیشتر عمر یک درخواست می‌تواند در انتظار بگذرد

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

پیش از انتخاب نرم‌افزار، تحویل جدید کار را مشخص کنید

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

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

1. تعداد محدودی درخواست را ببینید

   ورود، آمادگی، تصمیم و پاسخ را همراه استثناها و دوباره‌کاری ثبت کنید.

2. بر مسئولیت‌های تازه توافق کنید

   مسئول تصمیمِ در دسترس و قاعدهٔ جانشینی یا ارجاع را تأیید کنید.

3. مسیر محدودی را بیازمایید

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

4. کل نتیجه را مقایسه کنید

   زمان سپری‌شده، اصلاح‌ها، زحمت کاربران و درخواست‌های گمشده را ببینید؛ سپس دربارهٔ ادامه تصمیم بگیرید.

توافق کنید کدام تفاوت‌های سایت‌ها باید تغییر کند

تیم با هماهنگ‌سازی فرایندها، تعریف‌ها، خروجی‌ها یا روش‌های کارِ منتخب را در سایت‌های مختلف با هم سازگار می‌کند. برای استانداردسازی یک روش مشخص، می‌تواند اجرای همان قاعدهٔ مصوب را در همهٔ محل‌های مشمول آن الزامی کند. سازمان‌ها این اصطلاحات را به شکل‌های متفاوتی به کار می‌برند؛ بنابراین الزامات مشترک و تفاوت‌های محلیِ مجاز را صریح بنویسید و به نام روش اکتفا نکنید.

درس SAP دربارهٔ شکل‌های مختلف اجرای فرایند، با مقایسهٔ روش واقعی کار سایت‌ها آغاز می‌شود. مثال دو سایت در یادداشت قبلی ابوش، تصمیم را روشن‌تر می‌کند: بررسی موجودیِ قابل‌استفاده و اختیار تخصیص مشترک است، اما تصمیم‌های بارگیری محلی می‌ماند. با این مثال دربارهٔ مرز کار مشترک و محلی گفت‌وگو کنید؛ نصب نرم‌افزار یکسان، لزوماً به کار یکسان در همهٔ سایت‌ها نیاز ندارد.

استفاده از روش و فایدهٔ آن را جدا بسنجید

معیار استفاده از روش می‌گوید افراد از مسیر توافق‌شده استفاده می‌کنند یا نه. مثلاً درخواست‌های پذیرفته‌شده‌ای را بشمارید که از همین مسیر تمام شده‌اند و همهٔ درخواست‌های واجد شرایط را در مخرج نگه دارید. موارد دورزده یا رهاشده هم باید دیده شوند.

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

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

هوش مصنوعی کجا کمک می‌کند و کجا فایدهٔ کمی دارد؟

وقتی دسته‌های درخواست و مسئول‌ها روشن‌اند، یک قاعدهٔ ثابتِ مسیریابی می‌تواند کافی باشد. هوش مصنوعی شاید در دسته‌بندی متن آزاد، پیشنهاد مسئلهٔ مشابه یا پیش‌نویس پاسخ کمک کند؛ ولی هرکدام به بررسی دقت، حریم خصوصی و بازبینی انسانیِ خود نیاز دارد.

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

آیا ۷۰ درصد تحول‌های دیجیتال شکست می‌خورند؟

پژوهش سال ۲۰۲۰ BCG گزارش کرد که ۷۰ درصد، با تعریف ترکیبیِ موفقیت در آن مطالعه، به هدف‌ها نرسیدند. روش آن، ۷۰ تحولِ تحت پشتیبانی را با پژوهش بیرونی از ۸۲۵ مدیر ترکیب کرد. بعضی طرح‌ها ارزش ایجاد کردند، اما همهٔ معیارهای موفقیت را نداشتند. شکست کامل نامیدن همهٔ آن‌ها، این تفاوت را حذف می‌کند.

این مطالعه را با دامنهٔ تاریخی خودش بخوانید؛ از آن احتمال شکست جریان کار خودتان را نتیجه نگیرید. عدد ۸۴ درصد در مصاحبهٔ Forbes که پایین‌تر توضیح می‌دهیم آمده است، اما مصاحبه روش پژوهش را به‌اندازهٔ لازم برای تأیید این نرخ ارائه نمی‌کند. در آزمایش خود، فرض‌های مربوط به تحویل کار، مسئولیت، آموزش و نتیجه را مشخص و بررسی کنید.

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

پنج، شش یا هفت ستون؟ منبع را مشخص کنید

این تعدادها به مدل‌های متفاوت اشاره دارند. گزارش تولیدِ APEC در نوامبر ۲۰۲۴ پنج ستون را توضیح می‌دهد: ارزش پیشنهادی، بهبود فرایند، فلسفهٔ رهبری، پرورش افراد و به‌کارگیری فناوری دیجیتال. این چارچوب برای آموزش در تولید مفید است، اما استانداردی عمومی نیست.

مدل Rewired مک‌کینزی در عوض شش قابلیت را مشخص می‌کند: نقشهٔ راه بر اساس ارزش، نیروی توانمند، مدل عملیاتی، فناوری، داده و پذیرش و گسترش. با این دسته‌ها تغییر پیشنهادی را بررسی کنید: مسئول نتیجه کیست، چه کسی می‌تواند سیستم را نگه دارد و در یک شیفت معمولی چه کسی از آن استفاده خواهد کرد؟

فهرست هفت‌ستونی هم به همین انتساب نیاز دارد. گزارش سال ۲۰۲۳ِ مایکروسافت برای دولت کویت به خدمات شهروندی، پشتیبانی کارکنان، زیرساخت دیجیتال، امنیت سایبری و حریم خصوصی، قانون‌گذاری، مدیریت و تحلیل داده، و استعداد و مهارت می‌پردازد. دامنهٔ بخش عمومی با نیاز عملیاتیِ کارخانه تفاوت دارد. فهرست‌ها را به هم نچسبانید تا یک توالیِ ظاهراً اجباری بسازید.

نوع تغییر و رویکرد 4D مک‌کینزی

AWS تحول دیجیتال را در چهار گروهِ فرایند کسب‌وکار، مدل کسب‌وکار، حوزهٔ کسب‌وکار و سازمان قرار می‌دهد. این‌ها می‌گویند چه چیزی تغییر می‌کند. تحویل سفارش تولید بین دو نفر یک مسئلهٔ فرایندی است؛ فروش یک خدمت جدید با اشتراک، مدل کسب‌وکار را تغییر می‌دهد. یک اقدام می‌تواند به چند گروه مربوط باشد.

رویکرد چهار-D مک‌کینزی در سال ۲۰۱۷ می‌گوید کار را چگونه سازمان دهید: Discover برای روشن‌کردن هدف و ارزش، Design برای طراحی برنامه‌ها، Deliver برای اجرا با قابلیت‌ها و شرکای لازم و De-risk برای کاهش ریسکِ گذار با ترتیب‌دادن تغییرها. این رویکرد با چهار نوعِ AWS تفاوت دارد. در مثال تحویل سفارشِ بالا، پیش از جایگزین‌کردن روش موجود، آزمایشی کوچک و برگشت‌پذیر انتخاب و روی روش بازگشت توافق کنید.

تیتر شکست ۸۴ درصدیِ تحول از کجا آمده است؟

عدد ۸۴ درصد در مصاحبهٔ بروس راجرز با مایکل گیل در Forbes در ژانویهٔ ۲۰۱۶ آمده است. گیل از پژوهش دربارهٔ تحول سازمانی و برآورده‌نشدن انتظارها می‌گوید، اما مصاحبه تعداد نمونه، روش نمونه‌گیری یا محاسبه‌ای تکرارپذیر برای نرخ شکست ارائه نمی‌کند. تعبیرهای مختلفی از موفقیت و شکست هم به کار می‌برد. این اطلاعات برای معرفی ۸۴ درصد به‌عنوان احتمال فعلیِ شکست تولیدکنندگان کافی نیست.

رفتار، مشوق‌ها و پذیرشِ روش جدید از مسائل مفیدی‌اند که مصاحبه مطرح می‌کند. آن‌ها را در محل خود بیازمایید: آیا برنامه‌ریز می‌تواند بر اساس اطلاعات جدید اقدام کند، آیا تغییر واقعاً کار را کم می‌کند یا فقط ورود دوبارهٔ داده می‌سازد و آیا فایدهٔ اندازه‌گیری‌شده در شیفت‌های عادی باقی می‌ماند؟ همین نتایج را گزارش کنید، نه درصدِ تأییدنشدهٔ یک تیتر را.