برون‌سپاری IT یعنی واگذاریِ بخشی از خدمات فناوری اطلاعات، مثل پشتیبانی، زیرساخت یا امنیت، به یک ارائه‌دهندهٔ بیرونی. دیدگاه ما این است که اجرا را میشود سپرد، ولی مسئولیت، نظارت و دانشِ کلیدیِ سازمان را نه. تناسبِ این مدل با شرکت شما را سه چیز تعیین می‌کند: اندازهٔ شرکت، حساسیتِ داده‌ها و سرعتی که برای پاسخ‌گویی لازم دارید.
این نوشته برای مدیرانی است که هنوز در مرحلهٔ سنجیدن‌اند و می‌خواهند بدانند کدام فعالیتِ IT را بسپارند و کدام را نگه دارند. آنچه می‌خوانید دیدگاه و تجربهٔ ماست، نه حکمِ قطعی. در انتها یک ماتریسِ تصمیم و یک برنامهٔ یک‌هفته‌ای دارید که می‌توانید همین حالا با شرایط شرکتِ خودتان تطبیق دهید.
اشتباهِ رایج: سپردنِ مسئولیت همراهِ اجرا
این سناریو را در عمل بارها دیده‌ایم. شرکتی پشتیبانیِ کاربران و نگهداریِ سرورها را سال‌ها به یک پیمانکار سپرده است. همه‌چیز کار می‌کند و کسی دغدغه‌ای ندارد. بعد همکاری به هر دلیلی قطع میشود، چه اختلاف مالی، چه مهاجرت یا تعطیلیِ خودِ پیمانکار، و مدیر می‌فهمد رمزهای سرور، دسترسیِ پنل‌ها و مستنداتِ زیرساخت نزد همان پیمانکار مانده است. شرکت صاحبِ زیرساختش است، اما کلیدش را ندارد.
ریشهٔ این اتفاق یک تصور است: «سپردنِ کار یعنی سپردنِ دغدغه». ما با این تصور مخالفیم. اجرا قابلِ واگذاری است. مسئولیت و نظارت نه.
برون‌سپاری IT دقیقاً چه چیزی را واگذار می‌کند
برون‌سپاری IT (outsourcing) یا برون‌سپاری فناوری اطلاعات، یعنی سپردنِ بخشی از فعالیت‌های فناوری به ارائه‌دهندهٔ بیرونی. این بخش می‌تواند پشتیبانیِ سطح یک و دو (Help Desk) باشد، مدیریتِ زیرساخت و شبکه، خدمات ابری و سرور مجازی، امنیت سایبری و تست نفوذ، DevOps یا توسعهٔ نرم‌افزار. برای هر کدام از این‌ها می‌توانید از خدمات فناوری اطلاعات در وانوریکس شروع به بررسیِ شرکت‌ها کنید.
چیزی که واگذار میشود کارِ روزمره است. چیزی که واگذار نمی‌شود، پاسخ‌گویی در برابر مشتری، قانون و مدیرعامل است. اگر سرور بخوابد، مشتری شما از شما شکایت می‌کند، نه از پیمانکار.
مدل‌های همکاری: پشتیبانی موردی، قرارداد ماهانه، تیم اختصاصی، پروژه و ترکیبی
مدل‌های همکاریِ برون‌سپاری یک‌شکل نیستند و انتخابِ مدل، بخشِ مهمی از تصمیم است. جدول زیر پنج مدلِ رایج را از نظر انعطاف، کنترل و نیازِ مناسب کنار هم می‌گذارد.
| مدل | انعطاف | کنترل شما | مناسب برای |
|---|---|---|---|
| پشتیبانیِ موردی | بالا | بالا، چون هر بار خودتان سفارش می‌دهید | مشکل‌های پراکنده و نیازِ غیرمنظم |
| قرارداد ماهانه | متوسط | متوسط، با SLA و گزارشِ دوره‌ای | نگهداریِ مداوم زیرساخت و پشتیبانیِ کاربران |
| تیم اختصاصی (Dedicated Team) | کم‌تر، چون ظرفیت ثابت است | بالا بر جهتِ کار، پایین بر انتخابِ افراد | نیازِ بلندمدت و پیوسته، مثل توسعهٔ یک محصول |
| پروژهٔ مشخص | پایین پس از امضا | وابسته به دقتِ دامنهٔ کار (Scope) | کارِ محدود با ابتدا و انتهای روشن |
| ترکیبی (Hybrid) | بالا | بالا، اگر تقسیمِ نقش روشن باشد | شرکتی که تیمِ داخلیِ کوچک دارد و برای بخشی از کار کمک می‌خواهد |
در عمل، بیشترِ شرکت‌ها به‌مرور به مدلِ ترکیبی می‌رسند، حتی اگر با پشتیبانیِ موردی شروع کرده باشند.
چرا می‌گوییم اجرا را بسپارید ولی مسئولیت را نه
برون‌سپاری نه همیشه ارزان‌تر است و نه همیشه امن‌تر. هر دو ادعا تا وقتی قرارداد و شرایطِ واقعیِ شما بررسی نشده، بی‌پشتوانه است. ما هم عددی از خودمان نمی‌گذاریم که شما را قانع کند. به‌جایش دلیلِ موضع را می‌گوییم.
مزایای واقعی: مهارتِ تخصصی، انعطافِ ظرفیت، کاهشِ نیاز به استخدام
سه مزیتِ مشخص وجود دارد. اول، دسترسی به مهارتی که استخدامش برای شما توجیه ندارد؛ مثلاً یک متخصصِ امنیت که فقط چند روز در ماه لازمش دارید. دوم، انعطافِ ظرفیت: وقتی بار کاری بالا می‌رود، تیم بزرگ‌تر میشود و وقتی می‌افتد، کوچک‌تر. سوم، کم‌شدنِ نیاز به استخدام برای نیازهایی که دائمی نیستند.
این مزایا واقعی‌اند، اما خودکار نیستند. به کیفیتِ قرارداد و نظارتِ شما بستگی دارند. برای نمونه، اگر نیازتان پشتیبانیِ روزمره است، صفحهٔ خدمات پشتیبانی آی‌تی نقطهٔ شروعِ خوبی برای دیدنِ نوع خدمات و شرکت‌های فعال است.
هزینه: قرارداد را با هزینهٔ کلِ تیم داخلی مقایسه کنید، نه با حقوقِ یک نفر
رایج‌ترین خطا در محاسبه این است که مبلغِ ماهانهٔ پیمانکار را با حقوقِ یک کارمند مقایسه می‌کنند. این مقایسه نادرست است، چون هر دو طرف اقلامِ پنهان دارند.
هزینهٔ پیمانکار فقط مبلغِ قرارداد نیست. شامل زمانِ مدیرِ شماست که صرفِ هماهنگی میشود، هزینهٔ انتقال دانش در ابتدا و انتهای همکاری، ابزارهایی که باید جدا بخرید و هزینهٔ تغییرِ دامنهٔ کار وقتی نیازتان از آنچه نوشته شده فراتر می‌رود.
هزینهٔ تیم داخلی هم فقط حقوق نیست. استخدام، جایگزینیِ نیرویی که می‌رود، آموزش، مرخصی و روزهایی که ظرفیتِ تیم بی‌استفاده می‌ماند، همه در حسابِ شما می‌نشینند.
پس معیارِ مقایسه را به‌شکل فرمول بنویسید و با اعدادِ خودتان پر کنید، که به آن هزینهٔ کلِ مالکیت (TCO) می‌گویند:
- هزینهٔ سالانهٔ پیمانکار = مبلغِ قرارداد + زمانِ مدیریتِ همکاری + هزینهٔ انتقال دانش + ابزارها + برآوردِ تغییرِ دامنه
- هزینهٔ سالانهٔ تیم داخلی = حقوق و مزایا + استخدام و جایگزینی + آموزش + ابزارها + هزینهٔ ظرفیتِ بی‌استفاده
هر دو را به تومان و برای یک دورهٔ مشخص حساب کنید. هر نتیجه‌ای که بیرون آمد، مالِ شرکتِ شماست و به شرکتِ دیگر تعمیم‌پذیر نیست. برای دیدنِ دامنهٔ کاملِ خدماتی که می‌توان سپرد، صفحهٔ خدمات فناوری اطلاعات را هم ببینید.
قوی‌ترین استدلالِ مخالف: «اگر نظارت کنم، دیگر چه فایده‌ای دارد؟»
منصفانه‌ترین شکلِ مخالفتِ طرفداران واگذاریِ کامل این است: من برای راحت‌شدن از دغدغهٔ IT برون‌سپاری کرده‌ام. اگر باید نظارت کنم، گزارش بخوانم و جلسه بگذارم، همان دغدغه را با هزینهٔ بیشتر برگردانده‌ام.
دلیلِ منطقیِ طرفدارانِ واگذاریِ کامل
این حرف سست نیست. شرکتِ کوچک معمولاً کسی را ندارد که توانِ مدیریتِ پیمانکار را داشته باشد. مدیرعامل خودش مسئولِ فروش و عملیات است و وقتِ بررسیِ گزارش‌های فنی ندارد. از طرفی پیمانکارِ متخصص در امنیت و زیرساخت ممکن است از یک تیمِ داخلیِ دو‌نفره تواناتر باشد. و نظارتی که ساختار ندارد، خیلی زود به یک جلسهٔ نمایشی تبدیل میشود که هیچ‌کس جدی نمی‌گیرد.
جایی که این استدلال واقعاً درست است
در یک نقطه با آن موافقیم: نظارتِ سنگین برای شرکتِ کوچک عملی نیست. برای بعضی شرکت‌ها، نظارتِ سبک و مشخص تنها چیزِ شدنی است، و این اشکالی ندارد. اگر تخصصِ امنیتی در داخل ندارید، ناچارید بخشِ بزرگی از آن را بسپارید؛ خدمات امنیت سایبری دقیقاً برای همین وضعیت وجود دارد. اختلافِ ما با این استدلال بر سرِ «چقدر نظارت» است، نه «نظارت یا بی‌نظارتی».
پاسخ به آن استدلال: نظارتِ حداقلی لازم است، ولی همین کافی است
نظارتی که ما می‌گوییم سنگین نیست. نظارتِ حداقلی است و هزینه‌اش در مقابلِ سناریوی ابتدای مقاله ناچیز است.
چهار چیزی که حتی در واگذاریِ گسترده باید نزدِ شما بماند
- مالکیتِ حساب‌ها و دسترسیهای اصلی. حسابِ ثبتِ دامنه، پنلِ سرویس‌های ابری و دسترسیِ مدیریتیِ سرورها باید به نامِ شرکتِ شما باشد، نه پیمانکار. پیمانکار به‌عنوان کاربر با حداقل سطح دسترسیِ لازم کار کند.
- مستندات. نقشهٔ شبکه، فهرستِ سرویس‌ها، نحوهٔ پشتیبان‌گیری و روشِ بازیابی باید در جایی باشد که شما به آن دسترسی دارید و به‌صورت دوره‌ای به‌روز شود.
- گزارشِ دوره‌ای. گزارشی کوتاه و منظم از آنچه انجام شده، آنچه خراب شده و آنچه در راه است. فرمتش مهم نیست؛ منظم‌بودنش مهم است.
- یک مسئولِ داخلی برای ارتباط. یک نفر (Vendor Manager) که کارش لزوماً تمام‌وقت نیست، اما می‌داند پیمانکار چه می‌کند و چرا.
این چهار مورد را میشود با چند ساعتِ کار در ماه نگه داشت. هزینه‌اش کم است و در عوض، شما را از وابستگی به تأمین‌کننده (Vendor Lock-in) دور می‌کند.
ماتریسِ تصمیم: کدام فعالیت را بسپاریم، کدام را نگه داریم
برای اینکه هر فعالیتِ IT را جای درستش بگذارید، دو محور را با هم بسنجید. محورِ اول: آن فعالیت چقدر حساس است و چقدر به تمایزِ کسب‌وکار شما مربوط میشود؟ محورِ دوم: آیا در داخلِ شرکت مهارت و ظرفیتِ انجامش را دارید؟ از تقاطعِ این دو، چهار خانه می‌سازید.
| مهارت و ظرفیتِ داخلی دارید | مهارت و ظرفیتِ داخلی ندارید | |
|---|---|---|
| حساسیت یا تمایزِ بالا | نگه دار. مثال: توسعهٔ نرم‌افزارِ هستهٔ کسب‌وکار، مدیریتِ دسترسی‌ها و کلیدهای رمزنگاری. | ترکیبی با نظارتِ شدید. مثال: امنیت و تست نفوذ. اجرا با پیمانکار، تصمیم و مالکیتِ نتیجه با شما، همراه با NDA و دسترسیِ محدود. |
| حساسیت یا تمایزِ پایین | به ظرفیت و هزینه نگاه کن. مثال: DevOps و نگهداریِ ابزارهای داخلی. اگر تیم بار را می‌کشد نگه دارید، وگرنه بخشی را بسپارید. | بسپار. مثال: پشتیبانیِ کاربران، میزبانی و سرور. اینجا برون‌سپاری بیشترین سود و کم‌ترین ریسک را دارد. |
برای مثال، میزبانی و سرور معمولاً در خانهٔ «بسپار» قرار می‌گیرند. اگر دنبال این خدمات هستید، خدمات سرور و هاستینگ و خدمات DevOps را بررسی کنید. اما هر شرکت باید جایگاهِ فعالیت‌هایش را خودش تعیین کند: یک فروشگاهِ آنلاین ممکن است سرور را «حساس» بداند و شرکتی دیگر نه.
این ماتریس راهنمای تصمیم است، نه فتوا. با شرایط خودتان تطبیقش دهید و هر جا حس کردید خانه‌ای نمی‌خورد، دلیلش را بنویسید؛ همین نوشتن، خودش بخشی از تصمیم است.
آیا برای شرکتِ شما مناسب است؟ پنج معیارِ سنجش
ماتریس به شما می‌گوید کدام فعالیت را بسپارید. این بخش می‌گوید خودِ برون‌سپاری برای شرکت شما معنا دارد یا نه. هر معیار را به یک پرسش تبدیل کنید و صادقانه جواب بدهید.
اندازهٔ سازمان، حساسیتِ داده و نیاز به پاسخ‌گوییِ سریع
- اندازه: آیا حجمِ کارِ IT شما آن‌قدر هست که استخدامِ تمام‌وقت توجیه شود، یا بیشترِ هفته بی‌کار می‌ماند؟
- حساسیتِ داده: اگر داده‌هایتان بیرون برود، چه میشود؟ هرچه پاسخ سنگین‌تر باشد، دسترسیِ پیمانکار باید محدودتر و نظارتتان دقیق‌تر باشد.
- سرعتِ پاسخ: وقتی سیستم از کار می‌افتد، چند ساعت می‌توانید منتظر بمانید؟ اگر پاسخ «تقریباً هیچ» است، باید ببینید پیمانکار واقعاً چنین تعهدی می‌دهد یا نه.
مهارتِ موجود و میزانِ کنترلِ موردنیاز
- مهارت: کدام کارها را همین حالا تیمِ داخلی می‌تواند انجام دهد و کدام‌ها را نه؟
- کنترل: اگر پیمانکار فردا ناپدید شود، شرکت چند روز می‌تواند کار کند؟ هرچه این عدد کوچک‌تر باشد، کنترلِ بیشتری باید نگه دارید.
اگر تصمیم گرفتید: چطور پیمانکار را بسنجید و همکاری را مدیریت کنید
برای انتخابِ پیمانکارِ IT شش چیز را بررسی کنید: تجربهٔ مرتبط با نوع کارِ شما، شیوهٔ پشتیبانی، فرایندهای امنیتیِ داخلیِ خودِ پیمانکار، توانِ واقعیِ پاسخ‌گویی، مراجعی که بتوانید با آن‌ها تماس بگیرید و شفافیتِ قرارداد. مرجعِ قابل‌بررسی از مشتری‌های قبلی را جدی بگیرید؛ ادعای خودِ پیمانکار کافی نیست.
در قراردادِ SLA و بقیهٔ بندها این‌ها باید روشن باشد:
- دامنهٔ خدمات: چه چیزی داخل قرارداد است و چه چیزی بیرونِ آن
- SLA (توافق‌نامهٔ سطح خدمت) و زمانِ پاسخ برای هر سطحِ اولویت
- مسئولیت‌ها و جریمه یا جبران در صورت تخطی
- قالب و دورهٔ گزارش‌دهی
- دسترسی‌ها و مالکیتِ آن‌ها
- قرارداد محرمانگی (NDA)
- فرایندِ پایانِ همکاری و انتقال دانش و مستندسازی
برای شروعِ بررسی از منبعی مرجع، می‌توانید از فهرستِ شرکت‌های تأییدشده و نظرهای راستی‌آزمایی‌شدهٔ وانوریکس کمک بگیرید. معیارهای ما در روش رتبه‌بندی وانوریکس و نحوهٔ بررسیِ نظرها در سیاست بررسی نظرها توضیح داده شده است.
پرهزینه‌ترین اشتباه: نداشتنِ طرحِ خروج
به سناریوی ابتدای مقاله برگردیم. آن شرکت ایرادی در انتخابِ پیمانکار نداشت و شاید پیمانکارش واقعاً کارش را خوب انجام می‌داد. اشتباهش این بود که همکاری را بدون مستندات، بدون مالکیتِ دسترسی‌ها و بدون بندِ انتقال شروع کرد. طرحِ خروج (Exit Plan) را وقتی می‌نویسید که همه‌چیز خوب است؛ بعد از اختلاف دیگر کسی همکاری نمی‌کند.
نشانه‌های عینیِ وابستگیِ خطرناک
- فقط یک نفر در پیمانکار سیستمِ شما را می‌شناسد.
- رمزها و دسترسیهای مدیریتی نزدِ پیمانکار است، نه شما.
- گزارشِ منظم دریافت نمی‌کنید یا اگر می‌کنید، کسی آن را نمی‌خواند.
- نمی‌توانید بگویید اگر امروز همکاری تمام شود، چه چیزی باید تحویل بگیرید.
اگر حتی دو مورد از این‌ها برای شما صدق می‌کند، شرکت در معرضِ وابستگی است.
قدمِ بعدی: یک هفته‌ای که می‌توانید همین حالا انجام دهید
- فهرستِ همهٔ فعالیت‌های IT شرکت را بنویسید و هر کدام را روی ماتریسِ بخشِ چهارم بگذارید.
- دسترسی‌ها و مستنداتی را که نزد پیمانکار است بازیابی کنید و حساب‌های اصلی را به نامِ شرکت منتقل کنید.
- یک مسئولِ داخلی برای ارتباط با پیمانکار تعیین کنید.
- بندِ خروج و انتقال دانش را به قرارداد اضافه کنید یا در تمدیدِ بعدی بخواهید.
تصمیم با شماست: هر چیزی را که خانهٔ «بسپار» ماتریس نشان می‌دهد با خیالِ راحت بسپارید، و آنچه به حسابِ شرکت، داده‌های حساس و کلیدِ زیرساخت مربوط است، همین امروز در دستِ خود نگه دارید. برای ادامهٔ مسیر، امنیت سایبری چیست و چرا هر کسب‌وکاری در معرض خطر است؟ و تحول دیجیتال چیست؟ دو مقالهٔ مرتبط هستند.
پرسش‌های متداول
قرارداد برون‌سپاری IT را به تومان ببندیم یا قیمت را متغیر بگذاریم؟
داده‌ها و سرورها روی زیرساخت داخل ایران باشند یا خارج؟
چطور بفهمم پیمانکار به تعهدات SLA عمل می‌کند؟
پیش از امضای قرارداد بلندمدت میشود پیمانکار را آزمایشی امتحان کرد؟
اگر پیمانکار فعلی دسترسی‌ها و مستندات را تحویل ندهد چه کنم؟
به این مقاله امتیاز دهید
اولین نفری باشید که امتیاز می‌دهد
درباره نویسنده
