چرا این تصمیم سخت بود؟
پیش از ورود به مراحل LIAM، باید دید چه نیروهایی تصمیم را در دو جهت متفاوت می‌کشیدند.
تصمیم بارها تکرار می‌شد
هر هفته پیشنهادهای مشابه از نو و با منطق‌های متفاوت بررسی می‌شدند.
نفوذ افراد بر نتیجه اثر داشت
نام مشتری یا فشار فروش گاهی مرزهای سود و ظرفیت را کنار می‌زد.
قاعده باید نه خشک باشد نه بی‌اثر
سیاست بیش از حد سخت فرصت را می‌کشت و استثنای آزاد آن را بی‌معنی می‌کرد.
صورت مسئله و گزینه‌ها
هدف قاعده، دامنه و معیارهای تصمیم آینده روشن شد
این سیاست قرار است کدام تصمیم تکراری را بهتر کند و در چه پرونده‌هایی اعمال شود؟
چرا قاعده لازم شد؟
پذیرش پروژه‌ها به فشار نقدینگی، علاقه مدیر فروش یا بزرگی نام مشتری وابسته شده بود. نتیجه، تصمیم‌های ناهماهنگ و پروژه‌های کم‌سود یا پرتنش بود.
دامنه قاعده
- پروژه‌های خدماتی جدید بالای ۱۵۰ میلیون تومان
- تمدیدهای بزرگ با تغییر دامنه
- پیشنهادهایی که بیش از ۲۰٪ ظرفیت ماهانه می‌خواهند
- خارج از دامنه: پروژه‌های کوچک استاندارد و خریدهای داخلی
هدف قاعده
- حفظ حاشیه سود
- کنترل نقدینگی و ظرفیت
- کاهش تصمیم سلیقه‌ای
- دیدن ریسک حقوقی و دامنه
- امکان استثنای محدود و مستند
معیارهایی که باید به آستانه تبدیل می‌شدند
| معیار | چرا مهم است؟ | نوع سنجش |
|---|---|---|
| حاشیه سود | پروژه پرحجم اما کم‌سود ظرفیت را قفل می‌کند | درصد برآوردشده |
| پیش‌پرداخت | هزینه شروع باید بدون فشار نقدی تأمین شود | درصد قرارداد |
| زمان پرداخت | کیفیت درآمد به زمان وصول وابسته است | تعداد روز |
| اشغال ظرفیت | تعهد جدید نباید تحویل مشتریان فعلی را تهدید کند | درصد ظرفیت ماهانه |
| کنترل دامنه | افزایش کار بدون قیمت، سود را پنهانی از بین می‌برد | وجود/عدم وجود سازوکار |
| ریسک حقوقی | برخی ریسک‌ها با امتیاز مالی جبران‌پذیر نیستند | کم، متوسط، بالا |
| تناسب راهبردی | برخی پروژه‌ها یادگیری یا دسترسی مهم می‌سازند | ارزیابی مستند |
این مرحله چه چیزی را تغییر داد؟
نیاز کلی به «دستورالعمل پذیرش پروژه» مطرح بود.
مسئله تکراری، دامنه، هدف و معیارهای لازم تعریف شد.
قاعده از یک فرم عمومی به پاسخ یک مسئله مشخص تبدیل شد.
هر آستانه بعدی به هدف و ریسک واقعی وصل شد.
شواهد و عدم قطعیت
آستانه‌ها از تجربه پروژه‌های گذشته استخراج شدند
در چه شرایطی پروژه‌ها واقعاً سودآور، پرتنش یا زیان‌ده شده‌اند؟
مرور ۲۴ پیشنهاد و ۱۲ پروژه گذشته
| الگوی مشاهده‌شده | شاهد | نتیجه برای قاعده |
|---|---|---|
| حاشیه سود زیر ۲۸٪ | ۴ پروژه از ۵ مورد با اضافه‌کاری یا زیان تمام شدند | مرز رد خودکار نامزد شد |
| پیش‌پرداخت کمتر از ۲۰٪ | در ۳ پروژه فشار نقدی و تأخیر در تأمین نیرو رخ داد | کف پیش‌پرداخت بالاتر لازم شد |
| ظرفیت بالای ۹۰٪ | کیفیت دو مشتری فعلی افت کرد | آستانه ظرفیت باید حذف‌کننده باشد |
| پرداخت ۳۱ تا ۴۵ روز | با پیش‌پرداخت و مرحله‌بندی قابل مدیریت بود | به منطقه بررسی منتقل شد |
| مشتری راهبردی | دو پروژه متوسط به رابطه بلندمدت سودآور رسیدند | استثنا ممکن است، اما فقط با سند و سقف |
| دامنه مبهم | بیشترین اختلاف و افت سود را ایجاد کرد | نبود کنترل تغییرات، رد خودکار |
شاهد مخالف
یک پروژه با حاشیه سود اولیه ۲۶٪ در نهایت سودآور شد؛ چون محصول استانداردسازی‌شده و ارزش راهبردی بالایی داشت. این مورد نشان داد قاعده به منطقه استثنا نیاز دارد، نه اینکه آستانه سود حذف شود.
خطر قاعده خشک
اگر همه معیارها به رد خودکار تبدیل شوند، فرصت‌های تازه و پروژه‌های یادگیری‌محور از بین می‌روند. قاعده باید میان مرز قطعی و قضاوت مستند تفاوت بگذارد.
خطر استثنای بی‌قاعده
اگر هر پروژه جذاب بتواند با برچسب «راهبردی» از قاعده عبور کند، سیاست فقط ظاهر رسمی برای همان تصمیم سلیقه‌ای قبلی خواهد بود.
این مرحله چه چیزی را تغییر داد؟
اعداد پیشنهادی بیشتر از شهود مدیران می‌آمدند.
۲۴ پیشنهاد، ۱۲ پروژه، الگوهای شکست و یک مورد استثنایی مرور شد.
مرزهای حذف، منطقه بررسی و نیاز به استثنای کنترل‌شده شکل گرفت.
قاعده بر تجربه واقعی بنا شد و در برابر شاهد مخالف هم اصلاح شد.
تحلیل و هم‌راستاسازی
یک قاعده سه‌منطقه‌ای با استثنای محدود ساخته شد
چه آستانه‌هایی تصمیم را سریع می‌کنند و کجا هنوز به قضاوت مستند نیاز داریم؟
قاعده سه‌منطقه‌ای پذیرش پروژه
ترتیب اجرای قاعده
| مرحله | سؤال | خروجی |
|---|---|---|
| ۱. مرزهای حذف | آیا پروژه یکی از شرایط رد خودکار را نقض می‌کند؟ | رد یا بازطراحی؛ امتیازهای دیگر جبران نمی‌کنند |
| ۲. پذیرش روشن | آیا همه شرط‌های پذیرش خودکار پاس شده‌اند؟ | ارسال برای تأیید نهایی کوتاه |
| ۳. منطقه بررسی | کدام بده‌بستان یا ارزش راهبردی وجود دارد؟ | تصمیم مشروط با سند یک‌صفحه‌ای |
| ۴. استثنا | چرا خروج از قاعده به نفع شرکت است و سقف ضرر چیست؟ | تأیید مدیرعامل + ثبت دلیل + تاریخ مرور |
| ۵. ثبت | چه کسی تصمیم گرفت و بر چه داده‌ای؟ | رکورد قابل ممیزی در CRM |
یک سیاست با مرز، منطقه قضاوت و استثنای کنترل‌شده
قاعده منتخب پروژه‌های روشن را سریع عبور می‌دهد، موارد خطرناک را زود متوقف می‌کند و برای پرونده‌های خاکستری مسیر بررسی مشخص می‌سازد. استثنا حذف نشده، اما مالک، دلیل، سقف و تاریخ مرور دارد.
آستانه‌ها قرار نیست جای فکرکردن را بگیرند. آن‌ها باید قضاوت را در نقاط تکراری ساده کنند و توجه انسانی را برای پرونده‌های واقعاً خاکستری نگه دارند.
این مرحله چه چیزی را تغییر داد؟
دو مدل افراطی وجود داشت: چک‌لیست سخت یا اختیار کامل مدیر.
آستانه‌ها، ترتیب اعمال، مالک تصمیم و منطق استثنا طراحی شد.
پذیرش، بررسی و رد به سه مسیر روشن تبدیل شدند.
تصمیم‌های تکراری سریع‌تر شدند، بدون اینکه پرونده‌های خاکستری نادیده گرفته شوند.
حرکت، پایش و اصلاح
سیاست به CRM، نقش‌ها و چرخه بازبینی متصل شد
چطور قاعده در جریان واقعی پیشنهادها اجرا شود و خودش نیز از نتیجه‌ها یاد بگیرد؟
قرار دادن قاعده در جریان واقعی کار
| اقدام | مالک | زمان | خروجی |
|---|---|---|---|
| افزودن فیلدهای سود، پرداخت، ظرفیت و دامنه به CRM | عملیات فروش | هفته اول | فرم اجباری پیشنهاد |
| ساخت محاسبه‌گر ظرفیت و حاشیه سود | مالی و عملیات | هفته دوم | عدد مشترک و قابل اتکا |
| تعریف جلسه منطقه بررسی | مدیر فروش | هفتگی ۳۰ دقیقه | تصمیم، شرط یا رد ثبت‌شده |
| آموزش تیم فروش | مدیر فروش | پیش از فعال‌سازی | سه مثال و آزمون کوتاه |
| ساخت رجیستر استثناها | مدیرعامل | هم‌زمان با شروع | دلیل، سقف، مالک و نتیجه |
مالکیت و حق تغییر قاعده
پیش‌برنده
مدیر فروش مسئول کامل‌بودن اطلاعات و حرکت هر پیشنهاد در مسیر قاعده است.
تأییدکننده
مدیرعامل فقط پرونده‌های منطقه بررسی و استثنا را تأیید می‌کند؛ موارد روشن دوباره به او ارجاع نمی‌شوند.
حافظ داده
مالی و عملیات مسئول دقت حاشیه سود، ظرفیت و شرایط پرداخت‌اند.
حق اصلاح
تغییر آستانه‌ها فقط در مرور دوره‌ای و با شواهد پروژه‌های جدید مجاز است.
| اگر این نشانه دیده شد | اقدام |
|---|---|
| بیش از ۴۰٪ پیشنهادها در منطقه بررسی می‌افتند | آستانه‌ها یا کیفیت داده بازبینی شود؛ قاعده احتمالاً بیش از حد مبهم است |
| فروش راه‌های دورزدن فیلدها را پیدا می‌کند | فرم و مالکیت داده اصلاح و تصمیم‌های خارج سیستم نامعتبر شود |
| پروژه‌های پذیرفته‌شده با وجود پاس‌کردن قاعده زیان‌ده می‌شوند | فرض‌های محاسبه سود و دامنه بازبینی شود |
| استثناها بیش از ۱۵٪ می‌شوند | تعریف ارزش راهبردی و حق استثنا محدودتر شود |
| فرصت‌های باکیفیت به‌طور تکراری رد می‌شوند | شاهد مخالف بررسی و آستانه‌ها در مرور رسمی اصلاح شوند |
این مرحله چه چیزی را تغییر داد؟
سیاست می‌توانست به یک فایل خوانده‌نشده تبدیل شود.
فیلدها، مالک‌ها، جلسه بررسی، رجیستر استثنا و سنجه‌های قاعده تعریف شد.
قاعده وارد ابزار و رفتار روزانه شد و زمان اصلاح آن مشخص گردید.
اجرای سیاست به حافظه افراد یا سلیقه هر مدیر وابسته نماند.
از این تصمیم چه می‌آموزیم؟
این نکات نتیجه خاص پرونده را نسخه عمومی نمی‌کنند؛ فقط سؤال‌ها و محافظ‌هایی را نشان می‌دهند که در تصمیم‌های مشابه ارزش بررسی دارند.
قاعده برای تصمیم تکراری ساخته می‌شود
یک پرونده خاص نباید بدون نیاز به تکرار، به سیاست دائمی تبدیل شود.
مرزهای حذف با امتیاز جبران نمی‌شوند
ریسک حقوقی یا سود زیر حداقل نباید با نام مشتری پوشانده شود.
منطقه خاکستری باید مسیر داشته باشد
ابهام را نمی‌توان حذف کرد، اما می‌توان مالک و روش بررسی آن را روشن کرد.
استثنا باید محدود و قابل ممیزی باشد
دلیل، سقف ضرر، تأییدکننده و تاریخ مرور، استثنا را از دورزدن قاعده جدا می‌کند.
قاعده هم یک فرضیه اجرایی است
نتایج پروژه‌های بعدی باید نشان دهند آستانه‌ها مفیدند یا نیاز به اصلاح دارند.