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