چرا پروژههای تحول دیجیتال شکست می‌خورند
نویسنده: حسن صابر (Hassan Saber) · 8 دقیقه مطالعه
پروژههای زیادی دیده‌ام که با بودجه‌ی خوب و ابزار درست شروع شده‌اند و شکست خورده‌اند.
من حسن صابر هستم و در این مقاله الگوهایی را که بارها تکرار شده‌اند مرور می‌کنم.
۱. شروع از ابزار بهجای مسئله
«می‌خواهیم CRM راهاندازی کنیم» یک هدف نیست، یک راه‌حل است. هدف باید این باشد: «می‌خواهیم نرخ پیگیری سرنخ را از ۴۰ به ۸۰ درصد برسانیم.»
وقتی از راه‌حل شروع می‌کنید، هیچ‌وقت نمی‌فهمید موفق شده‌اید یا نه.
۲. نبود مالک مشخص
پروژه‌ای که «همه مسئولش هستند» پیش نمی‌رود. یک نفر باید صبح‌ها با این پروژه از خواب بیدار شود.
این شخص لزوماً مدیرعامل نیست، اما باید اختیار تصمیم‌گیری داشته باشد.
۳. تغییر همه‌چیز به‌طور همزمان
تیم انسانی ظرفیت محدودی برای تغییر دارد. وقتی همزمان نرم‌افزار، فرآیند و ساختار گزارش‌دهی عوض می‌شود، مقاومت طبیعی است.
تغییرات پشت سر هم، با فاصله، هم قابل هضم‌ترند و هم قابل اندازه‌گیری.
۴. نادیده گرفتن آدمها
سیستم جدید معمولاً برای کسی که ده سال روش قدیمی کار کرده، تهدید است. اگر توضیح ندهید که چرا این تغییر به نفع خودِ اوست، در عمل کارشکنی می‌بینید — حتی اگر کسی چیزی نگوید.
۵. نبود عدد اولیه
اگر قبل از شروع اندازه نگرفته باشید، در پایان نمی‌توانید بگویید چه شد. و پروژه‌ای که نتیجه‌اش قابل اثبات نیست، در دور بعدی بودجه نمی‌گیرد.
الگوی مشترک پروژه‌هایی که موفق می‌شوند
پروژههای موفق، آینه‌ی همان پنج اشتباه‌اند — و یک چیز اضافه:
از مسئله شروع میکنند، نه از ابزار. مالکِ مشخصی با اختیار واقعی دارند. تغییرات را پله‌پله اجرا میکنند و بین هر پله، عدد می‌بینند. به آدمها قبل از سیستم فکر میکنند. و روز اول، عددِ مبنا را ثبت میکنند.
چیز اضافه: یک جلسه‌ی هفتگی ثابت، سی‌دقیقه‌ای، با دستورجلسه‌ی ثابت — چه کار شد، چه عددی حرکت کرد، کجا گیر داریم. پروژه‌ها در همین جلسه‌ها نجات پیدا میکنند؛ نه در جلسه‌ی آغازینِ پرشور.
چک‌لیست پیش از شروع: هفت سؤال
قبل از اینکه هر پروژهی تحولی سبز شود، این هفت سؤال جواب صریح داشته باشد:
۱. چه عددی را قرار است جابه‌جا کنیم؟ (عدد مبنا: چقدر است الان؟)
۲. مالک پروژه کیست — با اسم؟
۳. معیار موفقیت در روز آخر چیست — یک جمله؟
۴. کدام کارها در فاز اول نیستند؟
۵. چه کسی از تیم، چه چیزی را باید کم کند تا وقت این پروژه آزاد شود؟
۶. اگر در نیمه‌ی راه متوقف شدیم، چه شرطی برای ادامه یا توقف داریم؟
۷. چه کسی مخالف این تغییر است و چرا؟ (همیشه یکی هست؛ بهتر است روز اول بدانید)
جواب مبهم به هرکدام، ریسکِ همان بخش را به کل پروژه اضافه می‌کند.
مدیریت مقاومت: سه حرکت که کار می‌کند
مقاومت، نشانه‌ی آدم بد نیست؛ نشانه‌ی ترس از دست دادن کنترل و اعتبار است. سه حرکتی که در عمل جواب داده:
درگیر کردن زودهنگام. همان کسانی که با سیستم جدید کار میکنند، در طراحیاش نظر بدهند — حتی اگر نظریشان ناقص باشد. آدمی که بخشی از طراحی بوده، در خراب‌کردنش سهیم نمی‌شود.
اولین بردِ کوچک، دیده‌شده. در دو هفتهی اول، یک مشکل واقعی و مزاحمِ روزانه حل شود و نامِ حل‌کننده اعلام شود. اولین برد، هرچه کوچک‌تر، پروژه را از «حرف مدیر» به «کارِ ما» تبدیل می‌کند.
جایگزین، نه افزودن. سیستم قدیمی در همان روزِ روشنشدنِ جدید، جمع شود. تا دو سیستم موازی باشد، همه به قدیمی برمی‌گردند و پروژه در همین پاراللیسم خفه می‌شود.
اگر پروژه در میانه لنگ زد
لنگ‌زدن، قاعده است نه استثنا. سه واکنش درست:
اول، تشخیص: مشکل از داده است، از آدم است یا از محدوده؟ داده‌ی هفته‌های قبل جواب می‌دهد — اگر ثبت شده باشد.
دوم، کوچک‌کردن: محدوده را نصف کنید و یک بردِ کوچک بسازید. پروژهی لنگ‌زده معمولاً از بزرگ‌بودن لنگ می‌زند، نه از دشواری.
سوم، تصمیم صریح درباره توقف. بعضی پروژه‌ها باید بمیرند — با احترام و با درسِ نوشتهشده. پروژه‌ای که فقط از خجالت ادامه پیدا می‌کند، هم وقت میسوزاند هم اعتماد تیم را به پروژهی بعدی.
نقش مدیرعامل: کجا کمک کند، کجا دست بردارد
مشکلِ پروژههای تحولی، معمولاً یکی از این دو حالتِ مقابل است: مدیری که پروژه را راه می‌اندازد و می‌رود، یا مدیری که در هر تصمیمِ ریز و درشت می‌نشیند.
حالت درست، وسط است و دقیق: مدیر در سه نقطه حاضر است —
تعریف مسئله و عددِ هدف. این تصمیم قابل واگذاری نیست؛ باید خودِ مدیر بگوید کدام عدد مهم است، وگرنه هرکس عددِ خودش را بهینه می‌کند.
رفع موانعِ سازمانی. پروژه به دیوار می‌خورد که فقط مدیر می‌تواند بشکندش: بودجه، آدم، اولویت، و رودربایستی‌های قدیمی.
جلسه‌ی هفتگی. حضورِ ثابتِ کوتاه، هم نظارت است هم پیامِ «این پروژه جدی است».
و در بقیه‌ی موارد، دست می‌کشد — چون مدیری که در جزئیات می‌ماند، مالکِ عملیاتی را بی‌اقدام می‌کند و پروژه از مالک‌بودن، به «کارِ مدیر» تنزل می‌یابد؛ همان لحظه‌ای که صفِ تصمیم‌ها به یک نفر گره می‌خورد و همه منتظر می‌مانند.
درس‌ها را کجا نگه داریم؟
هر پروژه — موفق یا شکست‌خورده — یک دارایی نامشهود دارد: درسش. جایی برای نوشتنش داشته باشید؛ نه سندِ چندصفحه‌ای رسمی، یک برگه با سه سطر برای هر پروژه: چه چیزی جواب داد، چه چیزی نه، و دفعه‌ی بعد از کجا شروع کنیم.
تیمی که این برگه‌ها را جمع می‌کند، دو سه سال دیگر، پروژه‌ها را با حافظه‌ی سازمانی اجرا می‌کند نه با حافظه‌ی آدمها — و حافظه‌ی آدمها، همان‌طور که در استعفاهای ناگهانی دیده می‌شود، دارایی‌ای است که یک صبح می‌رود و برنمی‌گردد.
تحول دیجیتالِ واقعی، نه خریدِ نرم‌افزار است و نه یک پروژه؛ ساختنِ این حافظه‌ی جمعی است که هر پروژه را از قبلی کم‌ریسک‌تر می‌کند. و امتیازِ نهاییِ پروژهی بعدیِ شما، همیشه به برگه‌ی پروژهی قبلی بسته است.
جمعِ پنج اشتباه در یک جمله: پروژههای تحولی نه با فناوری شکست می‌خورند و نه با بودجه؛ با فرض‌های نوشته‌نشده. هر سؤالی که روز اول جوابِ نوشتهشده ندارد، در ماه سوم به بحرانِ گفت‌وگو تبدیل می‌شود — و این جمله، تلخیصِ تجربه‌ی تقریباً همه‌ی پروژه‌هایی است که دیده‌ام. و درست همین‌جاست که تفاوتِ پروژهی ترفندی و پروژهی اصولی مشخص می‌شود: اولی ابزار می‌خرد، دومی این فرض‌ها را روز اول روی کاغذ می‌آورد.
آن‌گاه پروژه‌ای که با سؤالِ «چه عددی را جابه‌جا می‌کنیم؟» شروع شده بود، با همان عدد که حرکت کرده، تمام می‌شود؛ و سازمان، برای بارِ بعد، فقط یک عادتِ ساده بهتر شده است: نوشتنِ فرض‌ها.
تغییرِ سازمانی، در نهایت، چیزی نیست که به یک نفر سپرده شود و تمام شود؛ چیزی است که هر هفته، در همان جلسه‌ی سی‌دقیقه‌ای، یک بار دیگر اتفاق می‌افتد — و آدمها، کم‌کم، باور میکنند که این بار جدی است.
با این پنج اشتباه، سه حرکتِ مقاومت و هفت سؤالِ پیشِ‌شروع، نسخه‌ی عملیِ این مقاله در جیب شماست؛ کافی است جلسه‌ی بعدیِ پروژه، از سؤالِ اول شروع شود.
جمع‌بندی
تکنولوژی معمولاً ساده‌ترین بخش است. بخش سخت، مشخص کردن مسئله، انتخاب یک مالک، و بردن آدمها همراه خودتان است.
از این جمله شروع کنید؛ نتیجه‌اش، همان چیزی است که پروژههای شکست‌خورده‌ی این فهرست، هر کدام به یک روش، فراموش کردند: عددِ مشخص، مالکِ مشخص، تغییرِ پله‌پله و حافظه‌ای که درس‌ها را نگه می‌دارد.
<!-- interlink -->
---
بیشتر بخوانید
---
نویسنده: حسن صابر (Hassan Saber) — مشاور رشد کسب‌وکار و تحول دیجیتال.
اگر می‌خواهید وضعیت کسب‌وکارتان را با هم بررسی کنیم، یک جلسه‌ی مشاوره‌ی رایگان رزرو کنید.
سؤالات متداول
شایعترین دلیل شکست پروژههای تحول دیجیتال چیست؟
شروع از ابزار بهجای مسئله. وقتی هدف «CRM راهاندازی کنیم» باشد بهجای «نرخ پیگیری سرنخ از ۴۰ به ۸۰ برسد»، پروژه هیچ معیار موفقتی ندارد و در واقعیت هم به آن نمیرسد.
چطور با مقاومت تیم در برابر تغییر کنار بیاییم؟
کسانی که با سیستم کار میکنند زودتر در طراحیاش نظر بدهند، اولین بردِ کوچک در دو هفتهی اول دیده شود، و سیستم قدیمی در روزِ روشنشدنِ جدید جمع شود تا حالت موازی ایجاد نکند.
اگر پروژه در میانهی راه متوقف شد چه کنیم؟
با داده تشخیص دهید مشکل از محدوده است یا از آدمها، بعد محدوده را کوچک کنید و یک برد بسازید؛ و اگر باید متوقف شود، صریح و با درسِ نوشتهشده توقف کنید — پروژهی ادامهیافته از خجالت، اعتماد تیم را میسوزاند.