وقتی فروش افت می‌کند، معمولاً راه‌حل‌ها خیلی زود وارد جلسه می‌شوند: بودجه تبلیغات را بیشتر کنیم، قیمت را تغییر دهیم، فروشنده جدید استخدام کنیم، تخفیف بدهیم یا محصول را اصلاح کنیم.
اما قبل از همه این‌ها یک سؤال مهم‌تر وجود دارد: آیا مسئله‌ای که برایش راه‌حل انتخاب می‌کنیم، واقعاً همان مسئله‌ای است که در کسب‌وکار رخ داده است؟
یکی از پرهزینه‌ترین خطاهای مدیریتی، انتخاب راه‌حل برای مسئله‌ای است که هنوز تشخیص داده نشده. قبل از پرسیدن «چه کار کنیم؟» باید بتوانیم با شواهد بگوییم دقیقاً چه چیزی، کجا و تحت چه شرایطی درست کار نمی‌کند.
چرا مدیران ممکن است خیلی زود وارد راه‌حل شوند؟
Thomas Wedell-Wedellsborg در مقاله‌ای در Harvard Business Review گزارش می‌کند که در نظرسنجی از ۱۰۶ مدیر ارشد از ۹۱ سازمان در ۱۷ کشور، ۸۵٪ گفته‌اند سازمانشان در تشخیص مسئله ضعیف است و ۸۷٪ این ضعف را پرهزینه دانسته‌اند. این نمونه را نباید نماینده همه شرکت‌ها یا همه کشورها دانست؛ اما یک الگوی مدیریتی مهم را نشان می‌دهد: تیم‌ها ممکن است پیش از آنکه مطمئن شوند مسئله را درست فهمیده‌اند، وارد حالت حل مسئله شوند.
در مقاله دیگری در Harvard Business Review، Julia Binder و Michael D. Watkins نیز بر «صورت‌بندی مسئله» تأکید می‌کنند: پیش از پریدن به سمت پاسخ، مسئله باید از زاویه‌های مختلف دیده و تعریف شود.
این یعنی سرعت تصمیم به‌تنهایی مزیت نیست. اگر صورت مسئله اشتباه باشد، اجرای سریع فقط می‌تواند ما را سریع‌تر در مسیر اشتباه جلو ببرد.
نشانه، مسئله و علت را از هم جدا کنیم
«فروش کم شده» یک مشاهده مهم است؛ اما هنوز تشخیص نیست. «نرخ تبدیل افت کرده» نیز همین‌طور. این جمله‌ها به ما می‌گویند چیزی تغییر کرده، نه اینکه چرا تغییر کرده است.
چه چیزی تغییر کرده است؟ مثال: درآمد کاهش یافته است.
این تغییر دقیقاً کجا دیده می‌شود؟ مثال: بیشتر در مشتریان جدید یک محصول یا یک کانال.
چه توضیح‌هایی ممکن است این وضعیت را ایجاد کرده باشند؟
چه چیزی هر فرضیه را تقویت یا تضعیف می‌کند؟ چه چیزی هنوز نمی‌دانیم؟
با اطلاعات موجود، چه چیزی را می‌توانیم با اطمینان نسبی بگوییم و چه چیزی هنوز نامشخص است؟
قبل از پرسیدن «چرا؟»، بپرسید «دقیقاً کجا؟»
پرسیدن «چرا فروش کم شده؟» ممکن است ده‌ها پاسخ تولید کند: قیمت، تبلیغات، کیفیت لید، عملکرد فروش، محصول، رقابت، شرایط بازار یا تجربه مشتری.
اما اگر ابتدا مشخص کنیم افت فقط در مشتریان جدید، فقط در محصول A، فقط در یک کانال و از یک تاریخ مشخص شروع شده، فضای جست‌وجو بسیار کوچک‌تر می‌شود.
این همان جایی است که سه سؤال ساده ارزش پیدا می‌کنند:
شاخص یا رفتار مشاهده‌شده را تا حد ممکن مشخص کنید.
دوره قبل، میانگین چند دوره، دوره مشابه سال قبل، هدف یا یک معیار مقایسه معتبر.
مشتری، محصول، کانال، منطقه، تیم یا مرحله‌ای از فرایند.
محل بروز تغییر، علت تغییر نیست. اگر افت در یک کانال دیده شود، هنوز نمی‌توان گفت خود کانال علت مسئله است؛ فقط می‌دانیم بررسی را باید محدودتر و دقیق‌تر کنیم.
مبنای مقایسه؛ بدون آن «افت» ممکن است فقط یک برداشت باشد
برای اینکه بگوییم چیزی بهتر یا بدتر شده، باید بدانیم نسبت به چه چیزی. یک عدد منفرد معمولاً اطلاعات کافی برای تصمیم نمی‌دهد.
مثلاً فروش ۶۲۰ میلیون تومان به‌خودی‌خود نه خوب است نه بد. اگر دوره قابل‌مقایسه ۸۵۰ میلیون تومان بوده، یک تغییر معنادار برای بررسی داریم. اگر میانگین طبیعی کسب‌وکار بین ۵۸۰ تا ۶۵۰ میلیون تومان بوده، همان عدد معنای دیگری پیدا می‌کند.
نبودن مبنای مقایسه یک خطا نیست؛ خودش یک شکاف اطلاعاتی است که باید قبل از تصمیم پرهزینه برطرف شود.
به‌جای یک علت زودهنگام، چند توضیح رقیب بسازید
وقتی محل تغییر روشن‌تر شد، مرحله بعد انتخاب سریع یک علت نیست. بهتر است چند توضیح ممکن را همزمان نگه داریم.
فرض کنید نرخ تبدیل مشتریان جدید افت کرده است. ممکن است کیفیت ورودی تغییر کرده باشد، زمان پاسخ‌گویی بیشتر شده باشد، پیشنهاد تجاری تغییر کرده باشد یا ترکیب بازار عوض شده باشد. هرکدام یک فرضیه است؛ نه واقعیت.
منبع یک فرضیه هم مهم است: داده داخلی، مشاهده مستقیم، بازخورد مشتری، گزارش تیم، تحقیق بازار، تجربه قبلی یا صرفاً حدس شخصی. اما منشأ فرضیه، آن را اثبات نمی‌کند.
شواهد را سه‌قسمتی ببینید
| نوع | سؤال |
|---|---|
| شواهد تقویت‌کننده | چه چیزی باعث می‌شود این توضیح محتمل‌تر شود؟ |
| شواهد ناسازگار | چه چیزی با این توضیح جور درنمی‌آید؟ |
| شواهد مفقود | برای تصمیم بهتر هنوز چه چیزی را باید بدانیم؟ |
اگر تیم فروش می‌گوید «کیفیت لید افت کرده» اما نرخ واجدشرایط‌شدن در داده‌ها ثابت مانده است، نباید یکی از این دو را پنهان کنیم. نتیجه درست‌تر این است: شواهد فعلی یک‌جهت نیستند.
تعداد شواهد نیز به‌تنهایی معیار قدرت آنها نیست. یک اندازه‌گیری مستقیم و مرتبط می‌تواند از چند برداشت شخصی مهم‌تر باشد.
یک مثال تشخیصی: افت فروش از کجا شروع شده است؟
مثال زیر فرضی است و برای نشان‌دادن روش تحلیل ساخته شده است.
۲۲٪ کاهش
۳۱٪ کاهش
۱,۰۲۰ ← ۱,۰۶۰
۴۱۰ ← ۲۸۶
۱۲ ← ۹۰ دقیقه
اگر فقط درآمد را ببینیم، ممکن است اولین پیشنهاد «تبلیغات بیشتر» باشد. اما داده‌ها می‌گویند حجم لید کم نشده؛ افت بیشتر در مشتریان جدید دیده می‌شود و تعداد لیدهای واجد شرایط پایین آمده است. همزمان زمان پاسخ نیز افزایش یافته.
آیا زمان پاسخ علت است؟ هنوز نه. ممکن است ترکیب منبع لید نیز تغییر کرده باشد. ممکن است تعریف «واجد شرایط» عوض شده باشد. ممکن است هر دو عامل دخیل باشند.
گام تشخیصی بهتر این است که لیدها را بر اساس منبع و زمان پاسخ تقسیم کنیم و ببینیم افت واجدشرایط‌شدن در کدام گروه متمرکز است. این بررسی می‌تواند بین چند فرضیه تمایز ایجاد کند.
آزمون کوچک فقط برای امتحان راه‌حل نیست
گاهی آزمون کوچک را فقط بعد از انتخاب راه‌حل به کار می‌بریم: مثلاً یک کمپین را روی بخشی از بازار اجرا کنیم. اما آزمون می‌تواند برای تشخیص هم استفاده شود.
اگر نمی‌دانیم تأخیر پاسخ‌گویی با افت تبدیل ارتباط دارد یا نه، می‌توانیم برای یک گروه محدود از لیدها زمان پاسخ را کنترل کنیم و نتیجه را با گروه یا دوره قابل‌مقایسه بسنجیم. هدف این آزمون اثبات قطعی یک علت نیست؛ هدف کاهش عدم‌قطعیت است.
در مسائل پیچیده نیز همیشه یک زنجیره علت‌ومعلولی ساده در دسترس نیست. در چنین شرایطی، رویکردهای مبتنی بر آزمون محدود و یادگیری از نتیجه می‌توانند از اجرای یک تغییر بزرگ و برگشت‌ناپذیر منطقی‌تر باشند.
هر مسئله‌ای الزاماً یک «علت ریشه‌ای» واحد ندارد
تحلیل علت ریشه‌ای برای بسیاری از مسائل فرایندی و تکرارشونده بسیار مفید است. ASQ آن را خانواده‌ای از رویکردها، ابزارها و تکنیک‌ها برای کشف علت‌های مسائل تعریف می‌کند. روش «۵ چرا» نیز برای عبور از نشانه‌های سطحی و دنبال‌کردن زنجیره علت کاربرد دارد.
اما در یک مسئله مدیریتی پیچیده، نتیجه ممکن است حاصل تعامل چند عامل باشد. بنابراین بهتر است قبل از اینکه اصرار کنیم «یک علت اصلی» پیدا کنیم، ببینیم برای تصمیم فعلی چه مقدار عدم‌قطعیت باید کاهش یابد.
این چارچوب جایگزین روش‌هایی مانند تحلیل علت ریشه‌ای، ۵ چرا، A3، Kepner–Tregoe یا بازتعریف مسئله نیست. نقش آن این است که قبل از انتخاب ابزار حل مسئله، کیفیت تشخیص اولیه را بالا ببرد.
تعریف مسئله باید خروجی تشخیص باشد، نه حدس اولیه
تعریف ضعیف مسئله معمولاً یا خیلی کلی است—«فروش ما مشکل دارد»—یا راه‌حل را داخل خود مسئله پنهان می‌کند—«مشکل این است که باید تبلیغات بیشتری انجام دهیم».
تعریف قوی‌تر می‌تواند چنین ساختاری داشته باشد:
این تعریف قرار نیست زیبا باشد؛ باید تصمیم را دقیق‌تر کند.
مسیر هفت‌مرحله‌ای از نشانه تا تصمیم
چه چیزی تغییر کرده و نسبت به چه مبنایی؟
تغییر در کدام مشتری، محصول، کانال، منطقه، تیم یا مرحله متمرکز است؟
چه فرضیه‌هایی می‌توانند وضعیت را توضیح دهند؟
چه چیزی هر فرضیه را تقویت یا تضعیف می‌کند و چه چیزی هنوز مفقود است؟
با اطلاعات موجود دقیقاً چه چیزی را می‌توانیم بگوییم؟
کوچک‌ترین بررسی یا آزمونی که بیشترین ابهام را کم می‌کند چیست؟
اکنون باید اقدام کنیم، آزمون کنیم، بیشتر بررسی کنیم یا فعلاً متوقف شویم؟
سه سؤال برای جلسه بعدی مدیریت
دقیقاً چه چیزی تغییر کرده و مبنای مقایسه ما چیست؟
کدام بخش از توضیح فعلی ما «واقعیت ثبت‌شده» است و کدام بخش هنوز «فرضیه»؟
کدام اطلاعات اگر مشخص شود، تصمیم بعدی ما را بیشتر تغییر می‌دهد؟
این سه سؤال می‌توانند جلسه را از «چه کاری انجام دهیم؟» به «قبل از اقدام چه چیزی باید روشن شود؟» منتقل کنند.
مشکل واقعی را قبل از انتخاب راه‌حل بررسی کنید
«ابزار تشخیص مشکل واقعی کسب‌وکار قبل از انتخاب راه‌حل» همین مسیر را روی مسئله واقعی شما اجرا می‌کند: مشخص می‌کنید چه چیزی تغییر کرده، مبنای مقایسه چیست، تغییر کجا متمرکز است، چه توضیح‌هایی هنوز فقط فرضیه‌اند و چه شواهدی کم دارید.
خروجی ابزار یک «علت قطعی» یا امتیاز ساختگی نیست. در پایان چهار چیز روشن می‌شود: آنچه می‌دانیم، آنچه هنوز فرضیه است، آنچه هنوز باید بدانیم و بهترین گام بعدی برای بررسی.
اجرای ابزار تشخیص مسئله کسبوکارجمعبندی
مدیر خوب فقط سریع راه‌حل انتخاب نمی‌کند؛ ابتدا کیفیت صورت مسئله را بالا می‌برد.
فروش کمتر، نرخ تبدیل پایین‌تر، هزینه جذب بیشتر یا افت عملکرد تیم همگی می‌توانند نشانه‌های مهمی باشند. اما هیچ‌کدام به‌تنهایی علت را نشان نمی‌دهند.
مسیر مطمئن‌تر این است که تغییر را اندازه بگیریم، مبنای مقایسه را روشن کنیم، محل بروز را محدود کنیم، چند فرضیه رقیب بسازیم، شواهد موافق و مخالف را ببینیم و کوچک‌ترین بررسی‌ای را انتخاب کنیم که بیشترین عدم‌قطعیت را کاهش می‌دهد.
راهنمای اصطلاحات این مقاله
- Baseline
- مبنای مقایسه؛ وضعیتی که عدد یا عملکرد فعلی را نسبت به آن می‌سنجیم.
- Root Cause Analysis (RCA)
- تحلیل علت ریشه‌ای؛ خانواده‌ای از روش‌ها برای بررسی علت‌های زیربنایی یک مسئله.
- 5 Whys
- روش «۵ چرا»؛ پرسیدن چندباره «چرا» برای عبور از نشانه سطحی و بررسی زنجیره علت.
- A3
- روش ساختاریافته‌ای برای ثبت و هدایت فرایند حل مسئله و تصمیم‌گیری.
- Problem Framing
- صورت‌بندی مسئله؛ بررسی و تعریف مسئله پیش از انتخاب راه‌حل.
هنوز مطمئن نیستید مسئله واقعی کسب‌وکار کجاست؟
اگر نشانه‌ها را می‌بینید اما هنوز مشخص نیست مسئله دقیقاً کجاست، چه فرضیه‌ای باید بررسی شود یا قبل از تصمیم چه شواهدی کم دارید، می‌توانیم مسئله را دقیق‌تر بررسی کنیم.
شروع یک گفت‌وگوی حرفه‌ای