قرارداد پشتیبانی شبکه؛ ۹ بندی که پیش از امضا باید بخوانید
دو پیشنهاد پشتیبانی شبکه روی میز دارید. یکی ارزانتر است. تفاوت واقعیشان معمولاً در قیمت نیست — در بندهایی است که یکی نوشته و دیگری ننوشته. آن بندهای ننوشته همان جایی است که شش ماه بعد سرش دعوا میشود، و معمولاً در بدترین زمان ممکن: وسط یک قطعی.
این فهرست را کنار هر قرارداد پشتیبانی شبکه بگذارید و تیک بزنید. قاعده ساده است: اگر بندی در متن نیست، تعهدی هم نیست — هر چقدر هم در جلسه دربارهاش حرف زده باشند.
چرا مقایسه قیمت بهتنهایی گمراهکننده است
دو قرارداد با مبلغ متفاوت، معمولاً دو چیز متفاوت میفروشند. قرارداد ارزانتر اغلب ارزانتر است چون:
- دامنه کمتری را پوشش میدهد،
- زمان پاسخ مبهمتری دارد،
- بازدید دورهای ندارد،
- یا اصلاً تعهدی نداده و فقط اعلام آمادگی کرده است.
تا وقتی این چهار چیز را کنار هم نگذارید، دو عدد را با هم مقایسه میکنید که واحدشان یکی نیست. جدول انتهای همین مقاله دقیقاً برای این کار است.
۱. دامنه خدمات دقیقاً چیست
«پشتیبانی شبکه» بهتنهایی یعنی هیچ. باید فهرست شود کدام تجهیزات و کدام سرویسها زیر پوششاند:
- تجهیزات شبکه: سوئیچ، روتر، فایروال، اکسس پوینت
- سرورها و سرویسهای روی آنها
- مرکز تلفن و تجهیزات ویپ
- کامپیوترهای کاربران و چاپگرها
- زیرساخت پسیو: رک، پچپنل، کابلکشی
- اینترنت و ارتباط بین شعب
رایجترین اختلاف بعد از امضا دقیقاً همینجاست: کارفرما فکر میکند لپتاپ کارمندان هم شامل است، پیمانکار فکر میکند فقط تجهیزات مرکزی. هیچکدام دروغ نمیگویند؛ متن مشترکی وجود نداشته که به آن رجوع کنند.
و آنچه خارج از دامنه است
بند «خارج از دامنه» به اندازه بند «دامنه» مهم است. این موارد معمولاً جدا حساب میشوند و باید صریح نوشته شوند، نه اینکه بعداً معلوم شود:
- تعویض قطعه و هزینه سختافزار
- خرید و تمدید لایسنس
- کابلکشی جدید و توسعه زیرساخت
- پروژههای مهاجرت یا بازطراحی
- بازیابی اطلاعات از رسانه آسیبدیده
۲. زمان پاسخ و زمان حضور، جداگانه
این دو یکی نیستند و خلط کردنشان رایجترین ابهام قراردادهاست:
- زمان پاسخ: چقدر طول میکشد تا کسی جواب بدهد و بررسی را شروع کند.
- زمان حضور: چقدر طول میکشد تا کارشناس در محل شما باشد.
یک قرارداد جدی هر دو را جدا و عددی مینویسد، و برای هر کدام سطحبندی دارد: مشکل بحرانی که کل شرکت را خوابانده با مشکل یک کاربر، نباید زمان پاسخ یکسان داشته باشد.
سطحبندی که باید در متن باشد
| سطح | نمونه | زمان پاسخ | زمان حضور |
|---|---|---|---|
| بحرانی | قطعی کل شبکه یا سرور اصلی | عدد | عدد |
| مهم | یک بخش یا سرویس از کار افتاده | عدد | عدد |
| عادی | مشکل یک کاربر | عدد | عدد |
اگر فقط یک عدد مبهم نوشته شده، در عمل هیچ تعهدی وجود ندارد. برای اینکه بدانید این اعداد چطور باید تعریف شوند و اندازهگیری شوند، مقاله SLA و زمان پاسخ را ببینید.
۳. ساعات پوشش
روزهای کاری اداری؟ تا چه ساعتی؟ پنجشنبه چطور؟ تعطیلات رسمی؟
اگر کسبوکار شما شنبه تا پنجشنبه تا ساعت ۲۱ باز است، قراردادی که تا ۱۷ پوشش میدهد یعنی چهار ساعت از پرترافیکترین بازه شما بدون پشتیبانی است. این دقیقاً همان ساعتهایی است که در محاسبه هزینه خرابی شبکه گرانترین ساعتها هستند.
اگر پوشش خارج از ساعت اداری لازم دارید، نرخش باید همانجا در قرارداد نوشته شود — نه در لحظه اضطرار که قدرت چانهزنی ندارید.
۴. تعداد بازدید دورهای
پشتیبانی خوب فقط واکنش به خرابی نیست. باید نوشته شود ماهی چند بازدید برنامهریزیشده انجام میشود و در آن بازدید چه چیزهایی چک میشود.
بازدید بدون چکلیست، بازدید نیست. چکلیست باید پیوست قرارداد باشد و دستکم شامل: وضعیت فیزیکی رک و تهویه، سلامت دیسک و منبع تغذیه، وضعیت بکاپها، لاگ خطاها، مصرف منابع، و فهرست تجهیزاتی که به پایان عمر مفید نزدیک میشوند.
۵. مانیتورینگ؛ چه چیزی و چه کسی میبیند
سه سؤال را جدا بپرسید:
- چه چیزی پایش میشود؟ فقط در دسترس بودن، یا پهنای باند، دما، سلامت دیسک و مصرف منابع؟
- هشدار به چه کسی میرسد؟ فقط پیمانکار، یا شما هم میبینید؟
- تعهد واکنش به هشدار چیست؟
مانیتورینگی که هشدارش را کسی نمیبیند، فقط یک نمودار قشنگ است. و مانیتورینگی که فقط پیمانکار میبیند، ابزار سنجش عملکرد او نیست.
۶. مالکیت مستندات و رمزها
این بند را اکثر شرکتها جا میاندازند و بعداً گران میپردازند. باید صریح نوشته شود:
- نقشه شبکه، مستندات پیکربندی و فهرست تجهیزات متعلق به کارفرماست.
- در پایان قرارداد، این مستندات و دسترسیهای مدیریتی تحویل کارفرما میشود.
- رمزهای مدیریتی نزد کارفرما هم موجود است، نه فقط نزد پیمانکار.
- مستندات در طول قرارداد بهروز نگه داشته میشود، نه فقط یکبار در ابتدا.
اگر پیمانکاری از نوشتن این بند طفره رفت، همانجا تصمیمتان را بگیرید. شبکهای که فقط یک نفر میتواند بازش کند، دیگر شبکه شما نیست — و هزینه خروج از آن رابطه، هر سال بیشتر میشود.
۷. گزارش دورهای
ماهانه یا فصلی، باید گزارشی بگیرید که در آن باشد:
- چند درخواست ثبت شد و از چه نوعی
- میانگین زمان پاسخ و زمان حل
- چه کارهای پیشگیرانهای انجام شد
- چه چیزی در آستانه خرابی است و پیشنهاد چیست
- موارد نقض SLA و علتشان
گزارش، تنها راهی است که بفهمید بابت چه چیزی پول میدهید. قراردادی که گزارش ندارد، بعد از شش ماه به یک هزینه ثابت بیچهره تبدیل میشود.
۸. شرایط فسخ و انتقال
با چه اطلاع قبلی میتوانید فسخ کنید؟ آیا جریمه دارد؟ و در زمان انتقال به پیمانکار جدید، تحویل مستندات و همکاری در دوره گذار چطور تعریف شده؟
قراردادی که خروج از آن سخت طراحی شده، معمولاً به این دلیل طراحی شده که ماندن در آن جذاب نیست. یک بند «دوره گذار» با مدت مشخص، نشانه پیمانکاری است که به کیفیت کارش اتکا دارد.
۹. محرمانگی
پیمانکار پشتیبانی به دادههای شما دسترسی پیدا میکند. در متن باید باشد: تعهد به عدم افشا، فهرست افرادی که دسترسی دارند، فرایند ابطال دسترسی هنگام خروج نیروی پیمانکار، و تکلیف دادهها پس از پایان قرارداد.
جدول مقایسه دو پیشنهاد
این جدول را پر کنید. معمولاً بعد از پر کردن، معلوم میشود پیشنهاد ارزانتر در واقع ارزانتر نبوده — کمتر تعهد داده است.
| بند | پیشنهاد الف | پیشنهاد ب |
|---|---|---|
| دامنه خدمات فهرستشده | ||
| موارد خارج از دامنه فهرستشده | ||
| زمان پاسخ عددی و سطحبندیشده | ||
| زمان حضور عددی | ||
| ساعات و روزهای پوشش | ||
| تعداد بازدید دورهای + چکلیست پیوست | ||
| مانیتورینگ و مسئول واکنش | ||
| مالکیت مستندات و دسترسی | ||
| گزارش دورهای | ||
| شرایط فسخ و دوره گذار | ||
| محرمانگی |
پنج نشانه هشدار در متن قرارداد
بعضی عبارتها در ظاهر بیضررند اما در عمل تعهد را خنثی میکنند. اگر اینها را دیدید، بخواهید بازنویسی شود:
۱. «در اسرع وقت» بهجای عدد
هیچ داوری نمیتواند «اسرع وقت» را بسنجد. هر عبارتی که قابل اندازهگیری نباشد، در عمل قابل مطالبه هم نیست.
۲. «در صورت امکان» یا «حتیالامکان»
اینها شرط را به تشخیص یکطرفه پیمانکار واگذار میکنند. اگر محدودیتی واقعی وجود دارد، خودِ محدودیت باید نوشته شود، نه یک قید مبهم.
۳. پوشش «کلیه تجهیزات شبکه» بدون فهرست
عبارت کلی به نفع کسی است که بعداً بخواهد تفسیرش کند. فهرست پیوست، هم به نفع شماست هم به نفع پیمانکار درستکار.
۴. نبود بند نقض و پیامد
قراردادی که زمان پاسخ دارد اما ننوشته اگر رعایت نشد چه میشود، عملاً زمان پاسخ ندارد.
۵. تمدید خودکار بدون اطلاع
تمدید خودکار بهخودیخود بد نیست، اما باید با اطلاع قبلی و امکان بازبینی نرخ همراه باشد.
پیش از گرفتن پیشنهاد، این را آماده کنید
کیفیت پیشنهادهایی که میگیرید، مستقیماً به کیفیت شرح نیازی که میدهید وابسته است. اگر به سه پیمانکار فقط بگویید «قیمت پشتیبانی شبکه بدهید»، سه عدد بیربط میگیرید که قابل مقایسه نیستند.
این حداقل اطلاعاتی است که باید در اختیارشان بگذارید:
- تعداد کاربران و سایتها. چند نفر، در چند مکان.
- فهرست تجهیزات مرکزی. برند و مدل سوئیچ، روتر، فایروال و سرورها.
- سرویسهای حیاتی. کدام سیستم اگر بخوابد، کار شرکت میایستد.
- ساعات کاری واقعی. نه ساعات رسمی روی کاغذ.
- سابقه مشکلات. پارسال چه چیزهایی خراب شد و چقدر طول کشید.
- وضعیت مستندات. نقشه شبکه دارید یا نه.
اگر این فهرست را ندارید، خودِ تهیهاش اولین دستاورد این فرایند است. بسیاری از شرکتها وقتی این جدول را پر میکنند، تازه متوجه میشوند چه تجهیزاتی دارند که کسی مسئولش نیست.
قرارداد خوب چه چیزی را برای شما تغییر میدهد
فایده اصلی یک قرارداد درست، فقط سرعت تعمیر نیست. سه چیز عوض میشود:
- هزینه قابل پیشبینی میشود. بهجای صورتحسابهای نامنظم اضطراری، یک عدد ثابت ماهانه که در بودجه جا میگیرد.
- مسئولیت مشخص میشود. وقتی چیزی خراب میشود، بحث بر سر اینکه «کار چه کسی است» نمیشود.
- پیشگیری وارد برنامه میشود. بدون قرارداد، هیچکس انگیزهای برای پیشگیری ندارد؛ درآمد از خرابی میآید.
این نکته آخر مهم است و کمتر گفته میشود: در مدل پرداخت بهازای هر تماس، منافع پیمانکار با منافع شما همجهت نیست. در مدل قراردادی، هرچه شبکه شما پایدارتر باشد، هزینه پیمانکار هم کمتر است. برای همین بازدید دورهای در قرارداد، بندی است که هر دو طرف از آن سود میبرند.
پیوست فنی قرارداد: پنج سندی که باید ضمیمه شود
بندهای بالا، تعهدها را تعریف میکنند. اما قراردادی که پیوست فنی ندارد، در عمل قابل سنجش نیست. این پنج سند باید ضمیمه قرارداد باشند یا حداکثر در ماه اول تحویل شوند:
۱. فهرست داراییها
هر تجهیزی که تحت پوشش است، با این ستونها: نوع و مدل، شماره سریال، نسخه Firmware یا سیستمعامل، محل نصب، آدرس مدیریتی، تاریخ پایان گارانتی و پایان پشتیبانی سازنده، و سطح اهمیت (بحرانی، مهم، عادی). سطح اهمیت تعیین میکند کدام SLA به هر تجهیز تعلق دارد. بدون این فهرست، بند «کلیه تجهیزات» قابل اجرا نیست.
۲. ماتریس دسترسی و مخزن رمز
رمزها در یک مخزن رمز سازمانی با دسترسی مشترک نگهداری شوند، نه در ذهن یا فایل شخصی کارشناس پیمانکار. برای هر سیستم: چه کسی دسترسی کامل دارد، چه کسی فقط خواندنی، و یک حساب اضطراری (Break-glass) که فقط نزد شما است. احراز هویت چندعاملی برای دسترسی از راه دور، و ثبت ورود و خروج در لاگ.
۳. تعریف مانیتورینگ
فهرست دقیق آنچه پایش میشود، آستانه هر هشدار، و گیرنده هشدار در ساعات کاری و غیرکاری. «مانیتورینگ ۲۴ ساعته» بدون این فهرست، ادعاست. جزئیات طراحی را در مانیتورینگ زیرساخت آوردهایم.
۴. رویه مدیریت تغییر
هر تغییر در پیکربندی — قانون فایروال، VLAN جدید، ارتقای Firmware — باید این مسیر را طی کند: درخواست مکتوب، ارزیابی ریسک، زمانبندی در پنجره توافقشده، نقطه بازگشت (بکاپ پیکربندی پیش از تغییر)، اجرا، آزمون و ثبت در تاریخچه. تغییرات اضطراری هم ثبت میشوند، فقط بعد از اجرا.
۵. قالب گزارش ماهانه
قالب گزارش را پیش از امضا ببینید. حداقل شاخصها:
- تعداد درخواستها به تفکیک سطح اهمیت و دسته (شبکه، سرور، کاربر)
- درصد پایبندی به SLA = درخواستهایی که در زمان هدف پاسخ و حل شدند ÷ کل درخواستهای همان سطح
- میانگین و بدترین زمان حل در هر سطح
- دسترسپذیری سرویسهای اصلی بر اساس داده مانیتورینگ
- تغییرات انجامشده و وضعیت بکاپها
- ریسکهای باز و پیشنهادها با اولویت
برای بخش سرورها، چکلیست سرویس دورهای سرور مبنای خوبی برای بخش فنی گزارش است.
پرسشهای متداول
قرارداد پشتیبانی معمولاً چقدر طول میکشد؟
معمولترین حالت یکساله با پرداخت ماهانه است. قرارداد کوتاهتر برای شروع و ارزیابی طرفین منطقی است، به شرطی که شرایط تمدید و نرخ آن از قبل روشن باشد.
اگر شرکت ما کارشناس IT داخلی دارد، باز هم قرارداد لازم است؟
بستگی به دامنه دارد. رایجترین ترکیب موفق این است که کارشناس داخلی کارهای روزمره و پشتیبانی کاربران را میگیرد و قرارداد بیرونی، لایه زیرساخت، تخصصهای خاص و مواقع بحرانی را پوشش میدهد. مزیت دیگرش این است که وقتی کارشناس داخلی مرخصی است، شرکت بیپشتوانه نمیماند.
آیا تعویض قطعه در قرارداد است؟
معمولاً نه. هزینه قطعه جداست و باید صریح نوشته شود. آنچه در قرارداد است، تشخیص، تهیه پیشنهاد، نصب و پیکربندی قطعه جایگزین است.
اگر پیمانکار SLA را نقض کند چه اتفاقی میافتد؟
باید در متن پیشبینی شده باشد: معمولاً بهصورت کسر از صورتحساب دوره یا اعتبار خدمات. بندی که نقض را تعریف میکند اما پیامدی برایش ننوشته، بند تزئینی است.
چند پیشنهاد بگیریم؟
دستکم دو تا، و هر دو را با همان جدول بالا بسنجید. اگر هر دو پیشنهاد در چند ردیف جدول خالی ماندند، مشکل از پیشنهادها نیست — از شرح نیازی است که به آنها دادهاید.
قدم بعدی
اگر میخواهید پیشنهادی ببینید که این ۹ بند در آن نوشته شده باشد، کارشناسان ما ابتدا وضعیت فعلی شبکه شما را بازدید میکنند و بعد پیشنهاد فنی و مالی میدهند — با دامنه، زمان پاسخ و چکلیست بازدید مکتوب.
مشاهده خدمات پشتیبانی شبکه و درخواست بازدید · تلفن: 021-74903
پیمانکار یا مشاور IT هستید؟
اگر مشتریانی دارید که قرارداد پشتیبانی حرفهای میخواهند اما ظرفیت اجرایش را ندارید، از طریق برنامه همکاری در فروش نصیر ارتباط پروژه را مشترک پیش ببریم.