مدیران فناوری اطلاعات بارها در موقعیتی قرار گرفته اند که بعد از سه ماه اجرای پروژه شبکه متوجه می شوند پیمانکار در حال تحویل چیزی است که نه در صورتجلسه آمده بود نه در بودجه. ریشه این وضعیت تقریبا همیشه یک چیز است: نبود یک درخواست ارائه طرح پیشنهادی دقیق. شیوه نوشتن درخواست ارائه طرح پیشنهادی RFP – RFP نوشتن برای خدمات شبکه، از انتخاب سوئیچ تا قرارداد پشتیبانی، تعیین می کند که شما خریدار واقعی هستید یا فقط تامین کننده مالی ایده های دیگران.
اگر قرار است شبکه سازمان را به پیمانکار بسپارید، سند RFP تنها ابزار کنترل کیفیت و جلوگیری از هدررفت بودجه مشتری است. بدون این سند، جلسات فنی تبدیل به بازارگرمی می شود و مقایسه پیشنهادها شبیه مقایسه سیب و پرتقال خواهد بود.
RFP چیست و چرا در خدمات شبکه بدون آن شکست می خورید؟
خیلی از مدیران تصور می کنند برای پروژه شبکه داخلی، تماس تلفنی با دو شرکت و دریافت چند عدد کتبی کافی است. نتیجه این رویه را در شبکه های سازمانی زیاد دیده ایم: سوئیچ های access با ظرفیت اشتباه، کابل کشی بدون مستندات، و پشتیبانی که فقط در ساعات اداری جواب تلفن می دهد. استعلام شفاهی هیچ کدام از این موارد را قابل پیگیری حقوقی نمی کند. RFP نوشتن هزینه اولیه دارد اما دقیقا همان هزینه ای است که جلوی چند برابر شدن بودجه در فاز اجرا را می گیرد.
ارزان ترین مسیر یعنی استعلام شفاهی از دو شرکت فنی، دقیقا مخرب ترین مسیر انتخاب پیمانکار شبوکه است. چون خروجی آن هیچ ساختار قضاوت پذیری ندارد. شما نمی دانید قیمت پیشنهادی شامل کابل کشی است یا فقط تجهیزات اکتیو. بعد از تحویل، پیمانکار می گوید پچ پنل اضافه شده جداگانه هزینه دارد و شما هیچ سندی برای رد ادعا ندارید.
چرا RFP نویسی خدمات شبکه با RFP وب فرق دارد؟
در پروژه وب، خروجی نرم افزار است و خطا با یک به روزرسانی قابل اصلاح است. در خدمات شبکه، یک تصمیم اشتباه در طراحی رک یا مسیر فیبر نوری، ساعت ها خواب اپراتور را مختل می کند. RFP شبکه باید شامل نقشه طبقات، فاصله بین نودها، نوع کابل، دمای اتاق سرور، مسیر عبور کابل، تغذیه برق اضطراری و حتی پیچ و مهره رک باشد.
شبکه با CRM یا طراحی سایت فرق دارد. شما نمی توانید بعد از تحویل، یک سوئیچ core را به سادگی جابجا کنید. تعویض آن بعد از اجرا یعنی قطعی چند ساعته کل سازمان. به همین دلیل RFP خدمات شبکه باید به داده های فیزیکی و ترافیکی واقعی گره بخورد، نه به یک فهرست آرزوها. اگر داده های فعلی زیرساخت را ندارید، قبل از انتشار RFP یک ممیزی زیرساخت انجام دهید.
ساختار RFP خدمات شبکه: از داده تا قرارداد
سند RFP خدمات شبکه اگر این پنج بخش را نداشته باشد، فقط یک ایمیل طولانی است. هر بخش باید یک خروجی قابل اندازه گیری از پیمانکار طلب کند.
وضعیت فعلی زیرساخت را با داده واقعی ثبت کنید
نوشتن شبکه فعلی کند است یعنی تحویل پروژه به سلیقه پیمانکار. در RFP باید جدول تجهیزات فعلی، مدل سوئیچ ها، نسخه IOS، تعداد کاربران همزمان، پیک ترافیک صبحگاهی، لاگ خطاهای اینترفیس و نقشه کابل کشی موجود را ضمیمه کنید. اگر این داده ها را ندارید، پیمانکار در نبود داده، مفروضات خودش را جایگزین می کند و همه این مفروضات در فاز اجرا برای شما هزینه باز می شود.
از مشاوره و راه اندازی شبکه تا پشتیبانی فنی و دقیق . ما زیرساخت های شما را بهینه سازی میکنیم با امنیت تضمین شده و گزارش ۲۴ ساعته
- تضمین تخصص
- در همه جای ایران
الزامات امنیتی و انطباق را از چک لیست عمومی جدا کنید
چک لیست عمومی فقط عناوین کلی مانند امنیت بالا تولید می کند. برای شبکه باید سناریوهای مشخص بنویسید: دسترسی مهمان از کدام VLAN عبور می کند؟ سیاست BYOD چیست؟ آیا ترافیک بین شعب باید IPSec شود یا SD-WAN؟ چه سطحی از ۸۰۲.1X برای پورت ها الزامی است؟ اگر این سناریوها را ننویسید، پیمانکار امنیت را به حداقل های پیش فرض کاهش می دهد.
SLA و جریمه های تاخیر را قبل از انتخاب پیمانکار بنویسید
زمان پاسخ، زمان بازیابی، زمان در دسترس بودن، و مبنای اندازه گیری هر کدام. اگر RFP شما فقط پشتیبانی ۲۴ ساعته بنویسد، پیمانکار در ساعت ۲ بامداد پیام شما را می بیند و ساعت ۹ صبح پاسخ می دهد. SLA بدون جریمه مکتوب، یک آرزو است. مشخص کنید خطای بحرانی یعنی قطع کامل سرویس، خطای متوسط یعنی افت کیفیت یک طبقه، و خطای کم یعنی یک کاربر نمی تواند به پورت خاصی دسترسی پیدا کند.
| بخش RFP | حداقل داده فنی | اشتباه رایج | نتیجه در فاز اجرا |
|---|---|---|---|
| وضعیت فعلی شبکه | توپولوژی، مدل تجهیزات، پیک ترافیک، نقشه کابل کشی | فقط نوشتن شبکه کند است بدون داده پایش | طراحی ظرفیت اشتباه و خرید سوئیچ ناکافی |
| الزامات امنیتی | سطح دسترسی، سیاست BYOD، انطباق با ISO ۲۷۰۰۱ | کپی کردن چک لیست عمومی از اینترنت | گپ امنیتی بعد از تحویل و دسترسی غیرمجاز |
| SLA و پشتیبانی | زمان پاسخ، زمان بازیابی، جریمه تاخیر | نوشتن پشتیبانی ۲۴/۷ بدون سناریو | اختلاف بر سر ماموریت خارج از ساعات اداری |
| معیارهای ارزیابی | وزن فنی و مالی، نمونه کار مستند، آزمون POC | ارزیابی فقط بر اساس کمترین قیمت | پذیرش پیشنهاد ارزان و پرداخت هزینه پنهان |
معیارهای ارزیابی را وزن دار کنید نه سلیقه ای
پیشنهاد ارزان معمولا به معنای حذف آیتم های نرم افزاری یا کاهش پشتیبانی است. در ارزیابی، اگر فقط ستون قیمت را نگاه کنید، باید منتظر خرید مجدد تجهیزات در سال دوم باشید. وزن فنی را دست کم ۶۰ درصد و وزن مالی را حداکثر ۴۰ درصد قرار دهید. هر پیمانکار باید قبل از ارائه قیمت، پاسخ فنی خود را با جزئیات تجهیزات، برند و مدل دقیق تحویل دهد.
اگر در حال آماده سازی همین ساختار برای سازمان خود هستید و داده های فنی لازم را ندارید، تیم متااندیش می تواند در یک جلسه مشاوره، ساختار RFP شما را قبل از انتشار بازبینی کند. هدف متااندیش تمرکز بر کیفیت و جلوگیری از هدررفت بودجه مشتری است. برای دریافت مشاوره تدوین RFP خدمات شبکه با متااندیش تماس بگیرید.
RFP خدمات شبکه باید شامل چه سوالاتی باشد؟
سوالات RFP نباید کلی باشند. هر سوال باید یک خروجی قابل اندازه گیری از پیمانکار بخواهد. این سوالات را مستقیم در سند بیاورید:
- تعداد کاربران همزمان در هر طبقه و پیک ترافیک صبحگاهی چقدر است و طراحی ظرفیت بر چه مبنایی انجام شده است؟
- مسیر کابل کشی بین رک ها از کدام داکت و با چه نوع کابل اجرا می شود؟
- تجهیزات اکتیو پیشنهادی چه مدت گارانتی و چه مدت پشتیبانی فنی دریافت می کنند؟
- در صورت قطع برق، چه تجهیزاتی به UPS متصل می شوند و زمان نگهداری باتری چقدر است؟
- راهکار پیشنهادی برای رشد ۳ ساله تعداد کاربران و دوربین های مداربسته چیست؟
- نقشه پورت های PoE برای تلفن IP و اکسس پوینت چگونه توزیع شده است؟
چگونه پیشنهادها را ارزیابی کنید بدون اینکه فریب اسلاید بخورید؟
ارائه فنی پر زرق و برق هیچ تضمینی برای توان اجرایی پیمانکار نیست. بدترین لحظه برای مدیر شبکه، ساعت سه بامداد است که core switch هنگ کرده و قرارداد پشتیبانی فقط یک ایمیل دارد. از هر پیمانکار بخواهید سه پروژه مشابه را با شماره تماس مدیر فنی تحویل داده شده ارائه کند. اگر شماره تماس نداد، یعنی اعتماد به اجرا ندارد. آزمون POC اجباری برای یک سناریوی مشخص مثل failover بین دو لینک یا احراز هویت ۸۰۲.1X برگزار کنید. این آزمون از صد جلسه اسلاید ارزشمندتر است.
در جلسه دفاع فنی، از پیمانکار بخواهید در حضور شما یک مشکل واقعی از شبکه مشابه را رفع کند. اگر فقط توضیح داد و اجرا نکرد، او را کنار بگذارید. پیمانکار خدمات شبکه باید با دستش کار کند، نه با پاورپوینت.
نمونه جدول زمانی RFP برای خدمات شبکه
- روز صفر: انتشار RFP برای پیمانکاران کوتاه لیست شده
- روز پنجم: آخرین مهلت ارسال سوالات فنی
- روز هفتم: انتشار پاسخ به سوالات برای همه شرکت کنندگان
- روز چهاردهم: دریافت پیشنهادهای فنی و مالی
- روز هجدهم: برگزاری جلسه دفاع فنی و آزمون POC
- روز بیست و دوم: اعلام پیمانکار منتخب و شروع قرارداد
اشتباهات رایج در RFP نویسی برای شبکه که شما را به دادگاه می کشاند
اولین اشتباه، تعیین نکردن مالکیت مستندات است. اگر در RFP نگویید نقشه های as-built، فایل های پیکربندی و دسترسی به رابط مدیریت تجهیزات متعلق به کارفرماست، بعد از اتمام پروژه گروگان فنی پیمانکار می شوید. رمز سوئیچ core نباید فقط در لپ تاپ پیمانکار باشد.
دومین اشتباه، پذیرش شرط مطابق با استاندارد روز دنیا در قرارداد است. این عبارت هیچ مرجع حقوقی مشخصی ندارد. باید دقیق بنویسید چه استانداردی: TIA-۵۶۸ برای کابل کشی، IEEE ۸۰۲.3af برای PoE، یا ISO ۲۷۰۰۱ برای امنیت اطلاعات. هر جا استاندارد مبهم نوشتید، پیمانکار ارزان ترین تفسیر را انتخاب می کند.
سومین اشتباه، جدا نکردن فاز طراحی از اجراست. اگر پیمانکار هم طراحی کند هم اجرا، تعارض منافع به وجود می آید. در پروژه های حساس، طراحی را از یک مشاور مستقل بگیرید و اجرا را به پیمانکار دیگری بدهید. این کار هزینه اولیه را کمی بالا می برد اما جلوی فاجعه های پنهان را می گیرد.
سوالات متداول قبل از تدوین RFP خدمات شبکه
RFP چیست و چه فرقی با RFQ دارد؟
RFP درخواست ارائه طرح پیشنهادی است که راهکار فنی، روش اجرا و قیمت را می خواهد. RFQ درخواست قیمت کالا یا خدمات مشخص است. در پروژه شبکه که نیاز به طراحی و ادغام دارد، RFP انتخاب درست است؛ در خرید ۵۰ عدد سوئیچ با مدل مشخص، RFQ کافی است.
آیا می توانم از نمونه RFP آماده استفاده کنم؟
فقط به عنوان چارچوب صفحه بندی. اگر نمونه را بدون تغییر داده های واقعی سازمان منتشر کنید، پیمانکار متوجه می شود که شما زیرساخت خود را نمی شناسید و قیمت را با حاشیه سود بالاتر می دهد.
حداقل زمان مناسب برای دریافت پیشنهاد چقدر است؟
برای خدمات شبکه، کمتر از ۱۰ روز کاری یعنی فشار آوردن به پیمانکار برای حدس زدن. فاز سوالات فنی حداقل ۳ روز، فاز POC حداقل ۲ روز و فاز ارزیابی حداقل ۵ روز در نظر بگیرید.
چه SLAهایی در RFP خدمات شبکه غیرقابل مذاکره هستند؟
زمان پاسخ به خطای بحرانی، زمان بازیابی، نرخ در دسترس بودن ماهانه، و جریمه تاخیر در تحویل. SLA بدون مشخص کردن ابزار پایش و گزارش ماهانه، فقط یک جمله تزئینی است.
چگونه از دریافت قیمت های غیرواقعی پایین جلوگیری کنم؟
قیمت را به صورت تجمیعی تحویل نگیرید. از پیمانکار بخواهید قیمت هر آیتم را جداگانه و با برند و مدل دقیق ارائه کند. برای تجهیزات اکتیو، لیست قیمت توزیع کننده رسمی را ضمیمه کند.
آیا تیم متااندیش در تدوین RFP خدمات شبکه کمک می کند؟
بله. متااندیش می تواند قبل از انتشار RFP، ساختار فنی، معیارهای ارزیابی و SLA ها را بازبینی کند و در جلسه دفاع فنی به عنوان مشاور مستقل حضور داشته باشد. برای هماهنگی مشاوره با تیم متااندیش تماس بگیرید.