شنیدن و نگه‌داشتن این اپیزود
پخش را شروع کن؛ هنگام رفتن به صفحه‌های دیگر هم ادامه پیدا می‌کند.
برای خواندن و مرور دوباره
گفت‌وگو را به متن همراهت تبدیل کن
متن کامل و خوانای این اپیزود در Word و PDF، همراه با نقشهٔ تصویری موضوعات.
کتابخانه و بازخورد
برای شناخت بهتر پیش از شنیدن
این اپیزود هنوز بررسی عمیق نشده است
در اپیزودهای بررسی‌شده، پادگرد خلاصه، محورهای گفتگو، فصل‌های قابل پخش و پرسش‌های مهم را از متن اپیزود استخراج می‌کند.
تحلیل این اپیزودتکمیل این اپیزود
اگر مهمان یا اسپانسری جا افتاده، از فهرست موجود انتخاب کن یا نام تازه‌ای پیشنهاد بده. پیشنهادها بعد از بررسی مدیر عمومی می‌شوند.
متن منتشرشده توسط پادکستر
توضیحات اپیزود
در بسیاری از پروژه‌های ERP ، انتشار RFP به‌عنوان یک نقطه عطف حرفه‌ای و تعیین‌کننده شناخته می‌شود. سازمان‌ها ماه‌ها زمان صرف تدوین آن می‌کنند، ده‌ها یا حتی صدها سؤال درباره قابلیت‌های نرم‌افزار می‌پرسند، پیشنهادها را با هم مقایسه می‌کنند و در نهایت یک تأمین‌کننده را انتخاب می‌کنند. اما با وجود این همه تلاش و دقت، چرا بسیاری از این پروژه‌ها با تأخیر، افزایش هزینه یا حتی شکست مواجه می‌شوند؟ پاسخ را باید در یک خطای رایج جست‌وجو کرد: نوشتن RFP قبل از شفاف شدن مسئله. در این اپیزود از پادکست تسهیل‌گستر، به یکی از عمیق‌ترین و پرهزینه‌ترین چالش‌های پروژه‌های ERP می‌پردازیم؛ جایی که به‌جای تعریف درست مسئله، فقط فهرستی از قابلیت‌ها نوشته می‌شود. در این گفتگو می‌شنوید: چرا بیشتر RFPها به‌جای تعریف مسئله، فقط لیست امکانات هستند چرا تمرکز بر Feature می‌تواند جریان ارزش را مخدوش کند نقش KPIهای پایه در ارزیابی موفقیت پروژه ERP چرا جمله‌ی «همه چیز حیاتی است» یکی از نشانه‌های ضعف RFP است چرا ساختار تصمیم‌گیری و معیارهای انتخاب باید قبل از ارزیابی مشخص شوند و چگونه معماری فرایند و Blueprint می‌توانند RFP را به یک ابزار واقعی تصمیم‌گیری تبدیل کنند همچنین در این اپیزود، یک مثال واقعی را بررسی می‌کنیم که در آن یک RFP بسیار مفصل، به‌دلیل نبود معماری فرایند، به تأخیر و افزایش هزینه‌ی پروژه منجر شد. اگر در حال برنامه‌ریزی برای انتخاب ERP هستید، یا می‌خواهید از اشتباهات پرهزینه در مرحله RFP جلوگ
نظرها
هنوز نظری نوشته نشده.