در بسیاری از پروژه‌های ERP، انتشار RFP به‌عنوان یک نقطه عطف حرفه‌ای و تعیین‌کننده شناخته می‌شود.

سازمان‌ها ماه‌ها زمان صرف تدوین آن می‌کنند، ده‌ها یا حتی صدها سؤال درباره قابلیت‌های نرم‌افزار می‌پرسند، پیشنهادها را با هم مقایسه می‌کنند و در نهایت یک تأمین‌کننده را انتخاب می‌کنند.

اما با وجود این همه تلاش و دقت، چرا بسیاری از این پروژه‌ها با تأخیر، افزایش هزینه یا حتی شکست مواجه می‌شوند؟

پاسخ را باید در یک خطای رایج جست‌وجو کرد:

نوشتن RFP قبل از شفاف شدن مسئله.

در این اپیزود از پادکست تسهیل‌گستر، به یکی از عمیق‌ترین و پرهزینه‌ترین چالش‌های پروژه‌های ERP می‌پردازیم؛ جایی که به‌جای تعریف درست مسئله، فقط فهرستی از قابلیت‌ها نوشته می‌شود.

در این گفتگو می‌شنوید:

  چرا بیشتر RFPها به‌جای تعریف مسئله، فقط لیست امکانات هستند

  چرا تمرکز بر Feature می‌تواند جریان ارزش را مخدوش کند

  نقش KPIهای پایه در ارزیابی موفقیت پروژه ERP

  چرا جمله‌ی «همه چیز حیاتی است» یکی از نشانه‌های ضعف RFP است

  چرا ساختار تصمیم‌گیری و معیارهای انتخاب باید قبل از ارزیابی مشخص شوند

  و چگونه معماری فرایند و Blueprint می‌توانند RFP را به یک ابزار واقعی تصمیم‌گیری تبدیل کنند

همچنین در این اپیزود، یک مثال واقعی را بررسی می‌کنیم که در آن یک RFP بسیار مفصل، به‌دلیل نبود معماری فرایند، به تأخیر و افزایش هزینه‌ی پروژه منجر شد.

اگر در حال برنامه‌ریزی برای انتخاب ERP هستید،

یا می‌خواهید از اشتباهات پرهزینه در مرحله RFP جلوگ