چرا برنامه‌های تحول دیجیتال شکست می‌خورند؟ پنج الگوی تکرارشونده

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

شکست اول: هیچ‌کس بر سر آنچه تأمین مالی می‌شد توافق نداشت

از پنج ذی‌نفعِ یک برنامهٔ در حال دست‌وپا زدن بپرسید «تحول» چیست، و اغلب پنج پاسخ می‌گیرید: مهاجرت سیستم، پروژهٔ کاهش هزینه، یک اپلیکیشن موبایل، «نوسازی»، و شانه بالا انداختن. وقتی تعریف مشترکی وجود ندارد، هر واحد بر اساس برداشت خودش بهینه‌سازی می‌کند و برنامه به سبدی از پروژه‌های IT نامرتبط تبدیل می‌شود که فقط یک برند مشترک دارند. راه‌حل، پرزرق‌وبرق نیست: یک تعریف یک‌صفحه‌ای از اینکه سازمان پس از تحول چه کاری خواهد توانست بکند که امروز نمی‌تواند — به زبانی که هم هیئت‌مدیره و هم خط مقدم بفهمند — و توافق بر سر آن پیش از جابه‌جایی پول جدی.

شکست دوم: استراتژی و اجرا هرگز به هم نرسیدند

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

شکست سوم: مالکیت به صندلی اشتباه سپرده شد

وقتی تحول فقط در مالکیت IT باشد، کسب‌وکار آن را چیزی می‌بیند که بر او اعمال می‌شود، نه چیزی که توسط او انجام می‌شود — و بی‌سروصدا منتظر می‌ماند تا بگذرد. برنامه‌های واقعی به مالکیت زوجی نیاز دارند: کسی پاسخ‌گوی نتیجه و ارزش، و کسی پاسخ‌گوی تحویل. سازمان‌ها اغلب این دو را در یک نقش بیش‌ازحد بارگذاری‌شده ادغام می‌کنند؛ همان سردرگمی‌ای که در مقالهٔ Product Owner در برابر Project Manager توضیح دادم: «چه و چرا» با «چگونه و چه زمانی» دو شغل متفاوت‌اند، و وقتی یک نفر یا یک واحد به‌طور پیش‌فرض هر دو را در دست بگیرد، هر دو بد انجام می‌شوند.

شکست چهارم: بودجهٔ تغییر، صرف نرم‌افزار شد

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

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

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

برنامه‌های موفق چه وجه مشترکی دارند

در صنایع مختلف، برنامه‌هایی که جواب می‌دهند شبیه هم‌اند: تعریف مکتوب و مشترک از مقصد؛ کارکرد معماری که استراتژی را به نقشهٔ‌راه مرحله‌بندی‌شده متصل می‌کند؛ مالکیت زوجی کسب‌وکار و تحویل؛ تلاش تغییرِ انسانیِ با بودجهٔ کافی؛ و ریتم پایلوت–اندازه‌گیری–مقیاس به‌جای بیگ‌بنگ. هیچ‌کدام از این‌ها عجیب نیست؛ بیشترش انضباطِ انجام مداوم کارهای خسته‌کننده است، در حالی که تیترها نصیب فناوری می‌شود.

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

من بر اساس تجربهٔ عملی در بانکداری و مخابرات، دربارهٔ مدیریت فناوری اطلاعات، تحویل پروژه و تحول دیجیتال می‌نویسم. مطالب بیشتر را همین‌جا در yousefi.site بخوانید یا در لینکدین با من در ارتباط باشید.