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