RFP چیست و چه زمانی به آن نیاز دارید؟
RFP همان سندی است که قبل از انتخاب پیمانکار مینویسید تا همه پیشنهاددهندگان «یک داستان» بشنوند. بدون آن، هر شرکت فرض‌های خودش را می‌گذارد و قیمت‌ها و زمان‌ها قابل مقایسه نمی‌شوند.
چه مشکلی را حل میکند: پیشنهادهای غیرقابل مقایسه و اختلاف بعدی
وقتی به چند شرکت فقط می‌گویید «یک پنل سفارش می‌خواهیم»، یکی قیمت ورود و گزارش را می‌دهد، دیگری کیف پول و اپ موبایل را هم داخل همان عدد می‌گذارد، و سومی اتصال به حسابداری را خارج از محدوده حساب میکند. بعد از شروع کار هم اختلاف بر سر «چه چیزی داخل قرارداد بود» شروع میشود. RFP این فرض‌ها را از اول هم‌تراز میکند: وقتی محدوده نسخه اول و خروجی‌ها نوشته شده باشد، همان سه شرکت روی یک قالب پاسخ می‌دهند و مقایسه ممکن میشود.
کی RFP لازم نیست
اگر پروژه خیلی کوچک است — مثلاً یک صفحه فرود یا یک اسکریپت ساده — و فقط با یک پیمانکار مورد اعتماد کار می‌کنید، یک خلاصه کوتاه و جلسه کشف نیاز کافی است. RFP وقتی ارزش دارد که چند پیشنهاد می‌خواهید، محدوده مبهم است، یا بعداً باید بتوانید به قرارداد و تحویل استناد کنید.
تفاوت RFP با PRD، SRS، پروپوزال و RFQ
| سند | چه کسی مینویسد | هدف | چه زمانی |
|---|---|---|---|
| RFP (درخواست پیشنهاد) | کارفرما | گرفتن پیشنهاد راهکار، زمان و قیمت از چند شرکت | قبل از انتخاب پیمانکار |
| پروپوزال | پیمانکار | پاسخ به RFP با راهکار و پیشنهاد مالی | بعد از دریافت RFP |
| RFQ (درخواست قیمت) | کارفرما | گرفتن قیمت وقتی محدوده کاملاً مشخص است | وقتی فقط قیمت می‌خواهید، نه راهکار |
| RFI (درخواست اطلاعات) | کارفرما | شناختن بازار و توان شرکت‌ها | پیش از RFP، وقتی هنوز نمی‌دانید چه بپرسید |
| مستند نیازمندی پروژه (PRD) | کارفرما با کمک تیم تحلیل | روشن کردن نیاز محصول برای ساخت | معمولاً بعد از انتخاب پیمانکار؛ جزئیات در مستند نیازمندی پروژه (PRD) |
| سند نیازمندیهای نرمافزار (SRS) | تیم تحلیل / پیمانکار | جزئیات فنی و رفتاری سیستم | بعد از توافق کلی؛ توضیح در سند نیازمندیهای نرمافزار (SRS) |
پروپوزال پاسخ پیمانکار است، نه جایگزین RFP. RFQ وقتی منطقی است که دقیقاً می‌دانید چه می‌خرید — مثلاً تعداد لایسنس یک نرمافزار آماده — و فقط قیمت می‌خواهید. RFI برای مرحلهٔ قبل‌تر است: هنوز سؤال‌هایتان کامل نیست و می‌خواهید ببینید بازار چه گزینه‌هایی دارد.
ترتیب درست: اول RFP کوتاه، بعد مستند کامل
RFP لازم نیست همه جزئیات را داشته باشد. جزئیات در مستند نیازمندی و بعد از انتخاب پیمانکار کامل میشود. اول یک RFP کوتاه بفرستید، پیشنهادها را مقایسه کنید، پیمانکار را انتخاب کنید، بعد با او نمونه ساختار PRD یا SRS را عمیق کنید. تکنوراه مستند نیازمندی پروژه را پیش از شروع توسعه تدوین میکند؛ RFP جای آن را نمی‌گیرد.
قبل از نوشتن RFP این ۵ چیز را روشن کنید
قبل از باز کردن Word، این پنج مورد را برای خودتان بنویسید. اگر هرکدام مبهم بماند، پیشنهادها دوباره غیرقابل مقایسه می‌شوند.
- هدف کسب‌وکار: با این نرمافزار چه نتیجه‌ای می‌خواهید؟ کاهش خطا در سفارش، سرعت بیشتر در گزارش، یا حذف کار دستی؟
- تصمیم‌گیر نهایی: چه کسی پیشنهاد را تأیید و قرارداد را امضا میکند؟ بدون این نقش، جلسه ارائه بی‌نتیجه میماند.
- کاربران واقعی: چه نقش‌هایی هر روز با سیستم کار می‌کنند؟ مدیر، اپراتور، مشتری، انباردار؟
- وضعیت فعلی: امروز کار با اکسل، پیام‌رسان، نرمافزار قدیمی یا ترکیبی از این‌ها جلو می‌رود؟ داده کجاست؟
- محدوده نسخه اول: چه چیزی حتماً در انتشار اول باشد و چه چیزی عمداً برای بعد مانده؟ درباره نسخه اول در MVP چیست نوشته‌ایم.
مثال: اگر هدف «گزارش فروش ماهانه بدون اکسل دستی» باشد ولی نسخه اول را با اپ مشتری، باشگاه مشتریان و چت پر کنید، پیشنهادها روی چیزهایی قیمت می‌دهند که اولویت شما نیست.
ساختار یک RFP نرمافزاری؛ بخش به بخش
این ده بخش همان اسکلتی است که در قالب Word هم آمده است. لازم نیست هر بخش طولانی باشد؛ مهم این است که خالی نماند و فرض پنهان نگذارد.
۱. معرفی شرکت و پروژه، مهلت و روش ارسال پاسخ
نام شرکت، حوزه فعالیت، عنوان پروژه، مهلت ارسال پیشنهاد، و کانال دریافت (ایمیل یا فرم) را بنویسید. اگر جلسه ارائه حضوری یا آنلاین می‌خواهید، همان‌جا بگویید.
۲. مسئله فعلی و نتیجه مورد انتظار
مسئله را با زبان کسب‌وکار بنویسید، نه فهرست صفحه. «سفارش‌ها در پیام‌رسان گم می‌شوند و گزارش موجودی دو روز عقب است» بهتر از «نیاز به داشبورد» است. نتیجه مورد انتظار را هم قابل مشاهده بنویسید: مثلاً ثبت سفارش در یک جا و گزارش روزانه موجودی.
۳. کاربران، نقش‌ها و فرآیندهای اصلی
نقش‌ها و جریان اصلی کار را کوتاه توصیف کنید. لازم نیست اینجا User Story کامل بنویسید؛ همان اسکلت کافی است. اگر بعداً داستان کاربری مینویسید، راهنمای User Story را ببینید.
۴. محدوده نسخه اول و موارد خارج از محدوده
صریح بنویسید چه چیزی داخل نسخه اول است و چه چیزی نیست. موارد خارج از محدوده به اندازه موارد داخل مهم‌اند؛ جلوی Scope Creep را از همین‌جا می‌گیرند.
۵. داده، گزارش‌ها و اتصال به سیستم‌های دیگر
گزارش‌های ضروری، منبع داده فعلی، و اتصال‌ها را فهرست کنید: حسابداری، CRM، پنل پیامکی، درگاه پرداخت، انبار. اگر API — یعنی راه ارتباط استاندارد بین سیستم‌ها — از طرف مقابل موجود است یا نه، اگر می‌دانید بگویید. اتصالی که در RFP نیاید، مثل همان اتصال به حسابداری در مثال بالا، را هر شرکت به شکل خودش فرض میکند و قیمت‌ها دیگر قابل مقایسه نیستند.
۶. الزامات امنیت، میزبانی و پشتیبانی
میزبانی روی سرور شماست یا ابری؟ پشتیبان‌گیری، سطح دسترسی نقش‌ها، و انتظارات پشتیبانی بعد از تحویل را بنویسید. اگر SLA می‌خواهید — یعنی سطح خدمات توافق‌شده مثل زمان پاسخ به اختلال — همان را در قالب پاسخ بخواهید، بدون عدد ساختگی.
۷. خروجی‌ها، مالکیت سورس‌کد و معیار پذیرش
بگویید در پایان هر فاز چه چیزی تحویل میگیرید: محیط تست، مستند، آموزش، سورس‌کد. مالکیت کد و دسترسی به مخزن را روشن کنید. معیار پذیرش — یعنی شرط «تمام‌شدن» هر بخش — را در حد اصول بنویسید؛ جزئیات را بعداً با پیمانکار در معیار پذیرش دقیق می‌کنید.
۸. زمان‌بندی دلخواه و بودجه
اگر تاریخ کسب‌وکاری دارید (مثلاً قبل از یک نمایشگاه) بگویید. درباره بودجه: اعلام یک بازه کمک میکند پیشنهاد خارج از توان نیاید؛ نگفتنش ممکن است گزینههای متفاوتتری بیاورد. عدد و بازه ساختگی ننویسید؛ اگر بازهای اعلام می‌کنید، همان بازه واقعی تصمیم‌گیری خودتان باشد.
۹. قالب پاسخ پیشنهاددهنده
از پیشنهاددهنده بخواهید دقیقاً در این قالب جواب بدهد تا مقایسه ممکن شود:
- فهم مسئله و راهکار پیشنهادی
- تیم و نقش‌ها
- فازبندی و خروجی هر فاز
- زمان‌بندی
- قیمت به تفکیک فاز (نه فقط یک عدد کلی)
- فرض‌ها و ریسک‌ها
- نمونه‌کار مرتبط
فایلی که با دکمهٔ دانلود پایین همین صفحه میگیرید، قالب خالی RFP به شکل Word است: همین ده بخش و همین قالب پاسخ، آمادهٔ پر کردن.
اگر می‌خواهید یک پروپوزال واقعی تکمیل‌شده را هم ببینید، بخش «نمونه واقعی» در مقالهٔ سند نیازمندیهای نرمافزار (SRS) را بخوانید؛ فایل آن پروپوزال از دکمهٔ دانلود همان صفحه گرفته میشود.
۱۰. معیارهای ارزیابی پیشنهادها
بنویسید پیشنهادها را با چه معیارهایی می‌سنجید: فهم مسئله، کیفیت فازبندی، شفافیت فرض‌ها، تست، مالکیت سورس، پشتیبانی، و قیمت به تفکیک فاز. لازم نیست وزن عددی پیچیده بسازید؛ همین شفافیت کافی است تا پیشنهاددهنده بداند روی چه چیزی تمرکز کند.
نمونه RFP پرشده برای یک پروژه نرمافزاری (مثال فرضی)
متن زیر یک مثال فرضی است. نام شرکت، تعداد کاربر و مهلت‌ها واقعی نیستند و فقط برای نشان دادن شکل پرشدهٔ همان ده بخش آمده‌اند. می‌توانید آن را در Word یا Google Docs بچسبانید و با اطلاعات خودتان عوض کنید.
| بخش | متن نمونه (مثال فرضی) |
|---|---|
| عنوان پروژه | پنل ثبت سفارش و گزارش موجودی برای شرکت پخش (مثال فرضی) |
| کارفرما | شرکت فرضی پخش کالای تندمصرف — حوزه پخش مویرگی |
| مهلت ارسال پیشنهاد | ۱۰ روز کاری از تاریخ دریافت این RFP (مثال فرضی) |
| روش ارسال | یک فایل PDF به ایمیل اعلام‌شده در انتهای سند |
| ۱) معرفی | ما یک شرکت پخش متوسط هستیم. امروز سفارش فروشنده‌های حضوری با اکسل و پیام‌رسان ثبت میشود و موجودی انبار با تأخیر به‌روز میشود. به‌دنبال پنل وب برای نسخه اول هستیم؛ اپ موبایل در نسخه اول نیست. |
| ۲) مسئله و نتیجه مورد انتظار | مسئله: سفارش‌ها تکراری یا گم می‌شوند و گزارش موجودی به‌روز نیست. نتیجه مورد انتظار: ثبت سفارش در یک سیستم، مشاهده وضعیت سفارش توسط مدیر فروش، و گزارش روزانه موجودی کالاهای پرفروش. |
| ۳) کاربران و نقش‌ها | - مدیر فروش: مشاهده سفارش‌ها و گزارش - اپراتور سفارش: ثبت و ویرایش سفارش - انباردار: به‌روزرسانی موجودی - مشتری نهایی در نسخه اول دسترسی ندارد |
| ۴) محدوده نسخه اول / خارج از محدوده | داخل نسخه اول: ورود نقش‌دار، ثبت سفارش، وضعیت سفارش، گزارش موجودی ساده، خروجی اکسل. خارج از محدوده نسخه اول: اپ موبایل، باشگاه مشتریان، حسابداری کامل، مسیریابی ویزیتور. |
| ۵) داده، گزارش‌ها و اتصال‌ها | داده فعلی: چند فایل اکسل سفارش و یک فایل موجودی. گزارش‌های ضروری: سفارش روز، موجودی به‌تفکیک کالا، سفارش‌های تأخیری. اتصال نسخه اول: پنل پیامکی برای اطلاع وضعیت سفارش. اتصال حسابداری و درگاه پرداخت برای فاز بعد. |
| ۶) امنیت، میزبانی، پشتیبانی | میزبانی: ترجیح با سرور ابری پیمانکار در فاز اول، با امکان انتقال بعدی. نیاز: پشتیبان‌گیری منظم، دسترسی نقش‌محور، آموزش دو نقش اصلی. پشتیبانی: در پیشنهاد، مدل پشتیبانی ماهانه بعد از تحویل را شرح دهید. |
| ۷) خروجی‌ها، مالکیت، معیار پذیرش | خروجی هر فاز: محیط تست، راهنمای کوتاه کاربر، سورس‌کد در مخزن توافق‌شده. مالکیت: سورس و مستند متعلق به کارفرما پس از تسویه هر فاز. معیار پذیرش کلی: سناریوهای ثبت سفارش، تغییر وضعیت و گزارش موجودی بدون خطای مسدودکننده در محیط تست تأیید شوند. |
| ۸) زمان‌بندی و بودجه | زمان‌بندی دلخواه: انتشار نسخه اول قبل از شروع فصل پرفروش پاییز (مثال فرضی — تاریخ دقیق در جلسه کشف نیاز قطعی میشود). بودجه: بازه اعلام نمی‌شود؛ لطفاً قیمت را به تفکیک فاز و با فرض‌ها بنویسید. |
| ۹) قالب پاسخ الزامی | پاسخ باید شامل باشد: فهم مسئله، راهکار، تیم، فازبندی، زمان، قیمت به‌تفکیک فاز، فرض‌ها و ریسک‌ها، دو نمونه‌کار مرتبط. |
| ۱۰) معیارهای ارزیابی | فهم مسئله، شفافیت فازبندی و فرض‌ها، کیفیت طرح تست، مالکیت سورس، مدل پشتیبانی، و شفافیت قیمت به‌تفکیک فاز. |
نمونه RFP برای CRM؛ خرید نرمافزار آماده یا ساخت اختصاصی
اگر هدف شما خرید یک CRM آماده است — یعنی نرمافزار مدیریت ارتباط با مشتری — RFP بیشتر شبیه چکلیست خرید میشود تا سند ساخت. روی این‌ها تمرکز کنید: امکانات موجود در بسته، مدل مجوز، نصب ابری یا روی سرور خودتان، امکان سفارشی‌سازی محدود، پشتیبانی، و نحوه انتقال داده از اکسل یا سیستم قبلی.
اگر می‌خواهید CRM را اختصاصی بسازید، همان ساختار دهبخشی بالا را نگه دارید: محدوده نسخه اول، نقش‌ها، اتصال‌ها، مالکیت کد و فازبندی. تفاوت اصلی این است که در خرید آماده «چه چیزی از قبل هست» را می‌پرسید؛ در ساخت «چه چیزی باید ساخته شود» را تعریف می‌کنید.
برای مرور معیارهای خرید، چکلیست انتخاب نرمافزار CRM را ببینید. اگر CRM آماده می‌خرید، صفحه محصول CRM تکنوراه هم برای آشنایی با یک گزینه آماده است؛ این مقاله جای مقایسه محصول نیست.
پیشنهادهای رسیده را چطور مقایسه کنیم؟
پیشنهادها را در یک جدول کنار هم بگذارید. معیارها را از قبل در RFP اعلام کرده باشید تا کسی غافلگیر نشود. وزن‌های جدول زیر مثال فرضیاند؛ وزن واقعی را خودتان متناسب با اولویت کسب‌وکارتان بگذارید.
| معیار | چه چیزی را می‌سنجید | وزن (مثال فرضی) |
|---|---|---|
| فهم مسئله | آیا همان مشکل شما را روایت کرده یا فقط فهرست امکانات داده؟ | بالا |
| فازبندی و خروجی هر فاز | آیا نسخه اول واقعی و قابل تحویل است؟ | بالا |
| شفافیت فرض‌ها و ریسک‌ها | آیا نوشته چه چیزی را فرض کرده و چه چیزی خارج است؟ | بالا |
| تست و معیار پذیرش | آیا مسیر تأیید روشن است؟ | متوسط |
| مالکیت سورس و دسترسی | بعد از پرداخت، کد و مستند مال کیست؟ | بالا |
| پشتیبانی | مدل پشتیبانی بعد از تحویل چیست؟ | متوسط |
| قیمت به تفکیک فاز | آیا فقط یک عدد کلی است یا فاز به فاز؟ | بالا |
پیشنهادی که ارزان‌تر است ولی فرض‌هایش روشن نیست، ممکن است بعداً کارهایی را «خارج از محدوده» حساب کند. پس قبل از مقایسه قیمت، فرض‌های هر پیشنهاد را کنار هم بگذارید. برای نکات قرارداد و انتخاب شرکت، برون‌سپاری توسعه نرمافزار را بخوانید. اگر می‌خواهید منطق مقایسه قیمت را بهتر بفهمید، هزینه ساخت نرمافزار سفارشی هم کمک میکند.
۷ اشتباه رایج در نوشتن RFP
- تحمیل فناوری بدون دلیل کسب‌وکاری: مگر الزام امنیتی یا سازمانی دارید، فناوری را به پیمانکار دیکته نکنید؛ راهکار بخواهید.
- نوشتن فهرست صفحه به‌جای فرآیند: «صفحه داشبورد، صفحه گزارش، صفحه تنظیمات» مسئله را روشن نمی‌کند.
- جا انداختن اتصال‌ها و انتقال داده: پنل پیامکی، حسابداری و مهاجرت از اکسل را فراموش نکنید.
- نبودن معیار پذیرش: بدون تعریف «تمام‌شدن»، تحویل به مذاکره بی‌پایان تبدیل میشود.
- مهلت پاسخ غیرواقعی: پیشنهاددهنده باید وقت خواندن RFP، پرسیدن سؤال و برآورد داشته باشد. وقتی این وقت نباشد، پاسخ‌ها کلی و شبیه هم می‌شوند.
- نگفتن تصمیم‌گیر: اگر معلوم نباشد چه کسی انتخاب میکند، جلسه ارائه تلف میشود.
- کپی RFP یک پروژه دیگر: محدوده و اتصال‌های پروژه قبلی به پروژه شما نمی‌چسبد و دوباره پیشنهادها منحرف می‌شوند.
چکلیست قبل از ارسال RFP
قبل از فرستادن برای شرکت‌ها، این سؤال‌ها را با بله/خیر مرور کنید:
- مسئله فعلی و نتیجه مورد انتظار با زبان کسب‌وکار نوشته شده؟
- نقش کاربران نسخه اول مشخص است؟
- محدوده نسخه اول و موارد خارج از محدوده جدا شده‌اند؟
- اتصال‌ها و منبع داده فعلی فهرست شده‌اند؟
- خروجی هر فاز، مالکیت سورس و اصول معیار پذیرش آمده است؟
- قالب پاسخ پیشنهاددهنده اجباری شده (فاز، قیمت تفکیکی، فرض‌ها)؟
- معیارهای ارزیابی اعلام شده‌اند؟
- مهلت و روش ارسال واقعی و روشن است؟
- تصمیم‌گیر نهایی داخل سازمان مشخص است؟
- سند را یک نفر غیرنویسنده‌اش خوانده و جاهای مبهم را علامت زده؟
جمع‌بندی کاربردی
اگر فقط سه کار انجام دهید، کیفیت استعلام‌تان بالا می‌رود: مسئله و محدوده نسخه اول را بنویسید، قالب پاسخ و معیار ارزیابی را اجباری کنید، و پیشنهادها را در یک جدول با فرض‌های آشکار مقایسه کنید. قالب خالی Word را از دکمهٔ دانلود پایین همین صفحه بگیرید. نمونهٔ یک پروپوزال واقعی هم در مقالهٔ سند نیازمندیهای نرمافزار (SRS) آمده است.
قدم بعدی
RFP یا مستند نیازمندی پروژه‌تان را آماده کرده‌اید یا نمی‌دانید از کجا شروع کنید؟ در یک جلسه مشاوره رایگان ۱۵ دقیقه‌ای، محدوده نسخه اول را با هم روشن می‌کنیم.
اگر محدوده پروژه روشن است، برآورد اولیه زمان و هزینه را با فرم تکنوراه بگیرید.
تکنوراه مستند نیازمندی پروژه را پیش از شروع توسعه تدوین میکند. برای ساخت اختصاصی بعد از توافق، صفحه توسعه نرمافزار سفارشی را هم ببینید.
سوالات متداول
RFP پروژه نرمافزاری چیست و چه کسی آن را مینویسد؟
RFP یا درخواست پیشنهاد سندی است که کارفرما مینویسد و برای چند شرکت نرمافزاری میفرستد تا همه با یک اطلاعات یکسان پیشنهاد بدهند. هدفش گرفتن پیشنهادهای قابل مقایسه است، نه نوشتن همه جزئیات فنی.
تفاوت RFP با پروپوزال و RFQ چیست؟
RFP را کارفرما مینویسد تا راهکار بگیرد. پروپوزال پاسخ پیمانکار به همان RFP است. RFQ یا درخواست قیمت وقتی بهکار میآید که محدوده کاملاً مشخص باشد و فقط قیمت بخواهید. RFI هم برای شناخت بازار پیش از RFP است.
آیا باید بودجه پروژه را در RFP اعلام کنیم؟
اعلام بازه بودجه کمک میکند پیشنهادهای خارج از توان شما نیاید؛ نگفتنش هم ممکن است گزینههای متفاوتتری بیاورد. لازم نیست عدد دقیقی بگذارید؛ اگر بازه مینویسید، همان بازهای باشد که واقعاً با آن تصمیم میگیرید.
RFP با مستند نیازمندی (PRD یا SRS) چه فرقی دارد و کدام را اول بنویسیم؟
RFP برای گرفتن پیشنهاد است و کوتاه میماند. جزئیات بعد از انتخاب پیمانکار در مستند نیازمندی پروژه (PRD) یا سند نیازمندیهای نرمافزار (SRS) کامل میشود. ترتیب درست: اول RFP کوتاه، بعد مستند کامل.
نمونه RFP برای خرید CRM چه بخشهایی دارد؟
در خرید نرمافزار آماده، روی امکانات موجود، مجوز، نصب ابری یا روی سرور، پشتیبانی و انتقال داده تمرکز کنید. برای ساخت اختصاصی همان ساختار دهبخشی این مقاله را نگه دارید. معیارهای خرید را در مقاله چکلیست انتخاب نرمافزار CRM در آکادمی تکنوراه آوردهایم.