چک‌لیست RFP نرم‌افزار برای خریداران B2B

RFP نرم‌افزار باید پیش از پاسخ هر فروشنده‌ای مسئله، الزامات کارکردی و غیرکارکردی، نیازهای امنیتی و داده، شرایط تجاری و روش امتیازدهی را بیان کند. معیارهای وزن‌دار را امتیاز دهید تا بعداً بحث نکنید، به مراجع زنگ بزنید تا مطالعات موردی را باور نکنید، و پیش از امضای هر چیزی که بودجه‌ای را متعهد می‌کند یک پایلوت کوتاه پولی اجرا کنید.

چه چیزی باید در RFP نرم‌افزار باشد؟

این سند وجود دارد تا پاسخ‌ها قابل مقایسه شوند. فروشنده فقط می‌تواند به چیزی که مکتوب است پاسخ دهد؛ RFP‌ای که یک چشم‌انداز توصیف می‌کند و قیمت می‌پرسد، پیشنهادهایی دعوت می‌کند که همه عالی به نظر می‌رسند و هیچ‌کدام قابل مقایسه متقابل نیستند. محتوای کارکردی، محدودیت‌ها و قاعده امتیازدهی باید پیش از رسیدن اولین پاسخ ثابت شوند، وگرنه ارزیابی به مذاکره‌ای درباره معیارها تبدیل می‌شود.

یک نکته ترتیب هم هست که ماه‌ها صرفه‌جویی می‌کند: RFP جایی نیست که نیازتان را کشف کنید. الزامات از کار داخلی می‌آیند — مالکان فرایند که توضیح می‌دهند کسب‌وکار واقعاً چطور می‌چرخد، مالی که بیان می‌کند چه چیزی باید تطبیق یابد، کسانی که روزانه با سامانه کار می‌کنند و می‌گویند درد فعلی کجاست. این کار کند و سیاسی است و پیش از ورود هر فروشنده‌ای انجام می‌شود. تیم‌هایی که آن را به اولین فروشنده‌ای که رسید برون‌سپاری می‌کنند، الزاماتی به دست می‌آورند که به زبان محصول همان فروشنده نوشته شده و بعد هر پیشنهاد دیگری بد به نظر می‌رسد — نه به این دلیل که واقعاً بد است، بلکه چون خط‌کش ارزیابی دور یکی از پیشنهاددهندگان نوشته شده.

یک تفکیک دیگر هم هست که ارزش حفظ دارد، میان سه سندی که اغلب با هم اشتباه گرفته می‌شوند. RFI از بازار می‌پرسد چه چیزی وجود دارد؛ کوتاه است، پیش از الزامات می‌آید و کسی را متعهد نمی‌کند. RFP در برابر الزامات تعریف‌شده و روش ارزیابی اعلام‌شده پیش‌فاکتور می‌خواهد. RFQ در برابر دامنه تعریف‌شده قیمت می‌خواهد. اجرای RFQ پیش از وجود دامنه، رایج‌ترین راه مقایسه سه عددی است که سه معنای متفاوت دارند.

پنج کاری که یک RFP کامل انجام می‌دهد و RFP ناقص نمی‌دهد:

• مسئله را تعریف می‌کند، نه راه‌حل را. «کاهش زمان تهیه گزارش ادغامی ماهانه از چند روز به چند ساعت تعریف‌شده» بیان مسئله است؛ «برای ما یک انبار داده بسازید» حدس راه‌حلی است که شاید مسئله را حل نکند.


• الزامات را از ترجیحات جدا می‌کند. بایدهایی که رد یا قبول تعیین می‌کنند، بهترها که رتبه تعیین می‌کنند، و خوشایندهایی که هیچ‌چیز تعیین نمی‌کنند. فروشندهها فقط وقتی جدی پاسخ می‌دهند که این تفکیک دیده شود.


• محدودیت‌ها را نام می‌برد. سامانه‌های موجودی که باید یکپارچه شوند، داده‌ای که باید مهاجرت کند، تعهدات ممیزی و نگهداری، پنجره راه‌اندازی، اینکه چه کسی تأیید می‌کند.


• روش ارزیابی را از پیش بیان می‌کند. معیارهای وزن‌دار، چه کسی ارزیابی می‌کند، چه شواهدی لازم است و فروشندههای ناموفق کِی خلاصه امتیازشان را می‌گیرند.


• تاریخ‌های فرایند را می‌گذارد. مهلت پرسش، پنجره شفاف‌سازی، مهلت ارسال، دوره ارزیابی، تاریخ تصمیم. فرایند بدون تاریخ فروشندگانی را جذب می‌کند که از قبل سرشان شلوغ است.

ساختار سند RFP نرم‌افزار

الزامات کارکردی و غیرکارکردی نرم‌افزار

الزامات کارکردی شرح می‌دهند سامانه چه می‌کند: کدام فرایندها، برای کدام نقش‌ها، با کدام خروجی‌ها. الزامات غیرکارکردی شرح می‌دهند چقدر خوب انجامشان می‌دهد و همین‌ها بیش از همه جا می‌افتند — بعد گران، یا اصلاً اجرا می‌شوند.

ارزش دارد در بیشتر پروژه‌های B2B صریحاً بیان شود:

• کارایی. زمان پاسخ تحت بار اعلام‌شده، برای عملیاتی که مهم‌اند — ثبت سفارش، تولید گزارش، بستن ماه.


• در دسترس‌بودن. کسب‌وکار به چه میزان بهره‌وری نیاز دارد، پنجره‌های نگهداری، و در خارج‌شدن سامانه چه اتفاقی می‌افتد — هدف بدون شرح قطعیت قابل قبول، الزام نیست.


• بازیابی. RTO و RPO به زبان ساده: عملیات چقدر سریع بعد از یک رخداد از سر گرفته می‌شود و چقدر از کار ممکن است از بین برود. هر دو رقم باید در ارزیابی باشند، نه فقط در قرارداد.


• ردپای ممیزی. چه کسی چه چیزی را کِی عوض کرد، چه مدت نگهداری می‌شود، چه کسی می‌تواند بازیابی کند — به‌ویژه جایی که پول، موجودی یا داده شخصی جابه‌جا می‌شود.


• دسترس‌پذیری و کاربردپذیری. چه کسی با چه دستگاه‌ها و چه زبان‌هایی از سامانه استفاده می‌کند؛ سامانه‌ای که انبار نمی‌تواند با آن کار کند مستقر نشده، هرقدر هم امتیاز خوب گرفته باشد.


• یکپارچه‌سازی و داده. کدام سامانه‌ها وصل می‌شوند، داده در چه جهتی جاری می‌شود، و سند مرجع هر موجودی را چه کسی مالک است.

پرسش‌های امنیتی و انطباق

امنیت را بهتر است به‌صورت پرسش با شواهد الزامی پرسید، نه یک خط بله/خیر. مواردی که ارزش گنجاندن دارند:

• ISO/IEC 27001 — فروشنده آن را دارد و دامنه گواهی‌شده چه چیزی را پوشش می‌دهد؟ گواهی که سازمان فروش را پوشش می‌دهد اما تیم‌های تحویل را نه، حرف مشخصی به شما می‌زند.


• توسعه امن — امنیت در طراحی، بازبینی کد و آزمون کجا ایستاده است؛ مدیریت وابستگی‌ها و آسیب‌پذیری‌ها آیا روتین است.


• OWASP Top 10 — آیا بخشی از بازبینی فروشنده برای اجزای رو‌به‌وب است؛ پرسشی ملموس و قابل پاسخ.


• کنترل دسترسی — چه کسی به محیط‌ها و داده‌های شما می‌رسد، دسترسی چگونه اعطا و لغو می‌شود، چه سابقه ثبتی (لاگ) وجود دارد.


• تکالیف حفاظت از داده — KVKK و GDPR هرجا مصداق دارند؛ چه کسی کنترل‌کننده، چه کسی پردازنده، و توافق پردازش داده درباره پردازنده‌های فرعی و اعلام رخداد چه می‌گوید.

شرایط تجاری و SLAها

قیمت را در ساختاری بخواهید که قابل مقایسه باشد: چه چیزی شامل است، چه چیزی جدا محاسبه می‌شود، و تغییرات چگونه قیمت می‌شوند. یک عدد بدون دامنه پشتش را نمی‌توان با عدد دیگری مقایسه کرد؛ صفحه مدل‌های هزینه و قیمت‌گذاری ساختارهای رایج و پرسش‌هایی را که هرکدام مطرح می‌کنند توضیح می‌دهد.

SLAها همان دقت الزامات را می‌خواهند. درصد در دسترس‌بودن فقط با روش اندازه‌گیری، استثناها و جبران معنا دارد؛ زمان پاسخ فقط با تعاریف شدت و ساعات کاری معنا دارد. از هر فروشنده بخواهید شرایط داخل SLA را خودش تعریف کند، نه اینکه صفحه‌ای از درصدها بدون تعریف را بپذیرید.

ماتریس امتیازدهی ارزیابی

الگویی قابل کپی. وزن‌های زیر نمونه‌اند — وزن‌های خودتان را بر اساس اولویت‌هایتان بگذارید و جمع را روی 100 نگه دارید. معنای 1 و 3 و 5 را پیش از هر امتیازی تعریف کنید، نه بعد از شروع بحث‌ها.

دو انضباط این را کارآمد می‌کنند. پیش از بحث مستقل امتیاز دهید تا اولین صدای مطمئن اتاق را نسازد. و برای هر امتیاز یک خط توجیه ثبت کنید — فروشندگانی که خلاصه امتیاز با دلیل می‌گیرند خیلی راحت‌تر نتیجه را می‌پذیرند و تیم خودتان هم شش ماه بعد می‌تواند از آن دفاع کند.

انضباط سوم درباره این است که چه کسی امتیاز می‌دهد. هیئت باید کسانی را داشته باشد که با نتیجه زندگی خواهند کرد — مالک فرایند، کسی که مسئول داده است، نماینده امنیت یا مالی اگر این وظایف وجود دارند — نه فقط تدارکات. ارزیابی‌ها بی‌صدا شکست می‌خورند وقتی هیئت چیزی را که می‌تواند قضاوت کند امتیاز می‌دهد (ساختار پیشنهاد، صیقل تیم فروش) و آنچه را نمی‌تواند واگذار می‌کند (اینکه رویکرد یکپارچه‌سازی واقعاً با سامانه‌های فعلی می‌خواند یا نه). یک نفر فنی با اختیار اینکه بگوید «این با چیزی که ما می‌چرخانیم کار نمی‌کند» بیش از هر تخفیفی از هزینه پیشگیری می‌کند.

وزن‌ها خودشان یک هشدار دیگر حق دارند: آن‌ها بیان اولویت‌اند که برای فروشندگان هم دیدنی می‌شود. اگر امنیت 5% وزن دارد و قیمت 30%، فروشندگان جدی امنیتی متوجه می‌شوند و تیم خودتان هم هنگام امضای قرارداد متوجه خواهد شد. وزنی که عجله‌ای و برای پرکردن جدول گذاشته شود، برای همه بیرون از اتاق حقیقت خوانده می‌شود؛ یک‌بار و با حضور تصمیم‌گیرندگان بگذاریدش و فقط با همان تشریفاتی عوضش کنید که گذاشتیدش.

بررسی مراجع و پایلوت

مطالعات موردی بازاریابی‌اند؛ بررسی مراجع شواهد است. تماسی که جواب می‌دهد کوتاه است و درباره اتفاقی که افتاد می‌پرسد، نه چیزی که تحویل شد: آیا پروژه تمام شد، چه چیزی در دامنه عوض شد، واقعاً چه کسانی در تیم بودند، چه چیزی را متفاوت می‌کردند، و آیا باز هم همین پروژه را با همین فروشنده شروع می‌کردند. پاسخ‌های گذشته‌نگر و مشخص سیگنال است.

مرجعی از پروژه‌ای بخواهید که در اندازه و پیچیدگی شبیه شماست، نه مغرورانه‌ترین کار فروشنده — یک استقرار پرچمی دو برابر بودجه شما چیز کمی درباره رفتار تیم در مقیاس خودتان یادتان می‌دهد. و خودتان مرجع را بررسی کنید: مخاطبی که فروشنده از پیش آماده کرده تعریف‌نامه است، نه مرجع؛ تماس مفید آن است که مشتری در همان لحظه بفهمد شما چه می‌پرسید.

یک پایلوت کوتاه پولی بعداً بخشی را آزمایش می‌کند که هیچ مرجعی نمی‌تواند: اینکه این تیم با نیروهای شما وقتی الزامات ناقص است چگونه کار می‌کند. قواعد طراحی همان‌هایی‌اند که برای هر پایلوتی ارزش گذاشتن دارند — کار واقعی، معیارهای پذیرش مکتوب، یک تغییر میانه‌راه، و قاعده تصمیم توافق‌شده از پیش. صفحه برون‌سپاری طراحی پایلوت را با جزئیات بیشتری بررسی می‌کند.

بندهای قراردادی که باید بررسی کنید

• انتقال مالکیت معنوی — حقوق کد، مستندات و اشتقاقات که از زمان پدیدآوری به شما منتقل شود، نه فقط در پرداخت نهایی.
• مالکیت داده — داده شما مال شما می‌ماند؛ حقوق فروشنده به آنچه برای تحویل لازم است محدود می‌شود.
• پذیرش — پذیرش یعنی چه، چه کسی آن را اعلام می‌کند، و فرایند وقتی چیزی رد می‌شود چیست.
• کنترل تغییر — تغییرات دامنه چگونه درخواست، قیمت و تأیید می‌شوند؛ بدون آن، هر تغییری به اختلاف تبدیل می‌شود.
• خروج و انتقال — کد منبع، دسترسی، مستندات و کمک در پایان؛ اگر فروشنده عوض شود دانش چگونه منتقل می‌شود.
• امانت‌گذاری (Escrow) — جایی که تداوم کسب‌وکار به اجزای نگهداری‌شده توسط فروشنده وابسته است، اگر فروشنده نتواند ادامه دهد چه می‌شود.
• مسئولولیت — سقف‌ها، استثناها و آنچه بیمه نشده؛ با همان دقت قیمت آن را بخوانید.
• فسخ — مهلت‌های اعلام، تعهدات پس از فسخ، و فرایند بازگرداندن یا حذف داده.

پرسش‌های متداول

اول RFI بفرستیم یا RFP؟

RFI وقتی که بازار یا مسئله نامشخص است — دارید می‌پرسید چه چیزی وجود دارد و چقدر هزینه دارد. RFP وقتی که الزامات و روش ارزیابی تعریف شده‌اند؛ فرستادن زودتر از موعد فقط کار الزامات را به داخل پیشنهاد هر فروشنده منتقل می‌کند، با زبان و اولویت‌های خودشان.

چند فروشنده دعوت کنیم؟

آن‌قدر کم که بتوانید هر پیشنهاد را درست بخوانید و به هر مرجع زنگ بزنید. بیشتر ارزیابی‌ها فراتر از چندتایی کیفیت را از دست می‌دهند؛ فهرست کوتاهی که از یک RFI، یک تماس غربالگری و یک پروژه مرجع مشابه ساخته شود معمولاً از فهرست بلند نام‌های معروف مفیدتر است.

وزن‌ها چگونه گذاشته شوند؟

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

آیا قیمت باید امتیاز بگیرد؟

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

پاسخ‌های امنیتی را چطور امتیاز بدهم؟

بر اساس شواهد، نه لحن. سه سطح جواب می‌دهد: بدون موضع (1)، سیاست‌های شرح‌داده‌شده (3)، دامنه گواهی راستی‌آزمایی‌شده به‌علاوه شرح توسعه امن و ارائه شواهد (5). جایی که فروشنده گواهی ندارد، بپرسید کنترل‌های معادل مکتوب چیست — یک «نه» صادق با کنترل‌های مستند بهتر از یک «بله» غیرقابل راستی‌آزمایی امتیاز می‌گیرد.

آیا بعد از RFP می‌توانیم الزامات را عوض کنیم؟

پیش از ارسال‌ها، بله — با اعلام تغییر به همه. پس از ارسال‌ها، فقط از طریق شفاف‌سازی رسمی که همه پیشنهاددهندگان بگیرند؛ تغییر بی‌صدا برای یک فروشنده، قابلیت مقایسه‌ای را می‌کشد که کل فرایند روی آن بنا شده. پس از قرارداد، دقیقاً برای همین است که کنترل تغییر داریم.

منابع و استانداردها

• ISO — ناشر ISO/IEC 27001 (مدیریت امنیت اطلاعات)؛ پیش از اتکا، چاپ فعلی و دامنه گواهی را تأیید کنید.
• OWASP — ناشر فهرست Top 10 آسیب‌پذیری برتر امنیت برنامه‌های وب که در این صفحه ارجاع شده است.
• اصول ماتریس امتیازدهی از رویه الگوهای منتشرشده RFP پیروی می‌کند؛ وزن‌های نمایش‌داده‌شده نمونه‌ای برای ویرایش‌اند، نه توصیه. این صفحه راهنمای تدارکات است، نه توصیه حقوقی، و برای WorldwideTradeX هیچ گواهی یا ممیزی‌ای ادعا نشده است.

صفحات مرتبط

توسعه نرم‌افزار · برون‌سپاری IT از ترکیه · مدل‌های هزینه و قیمت‌گذاری · ممیزی و مشاوره IT · درخواست قیمت