مدیریت قرارداد

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

یک نکته کوتاه درباره نگهداری: معمولا CFO همه نسخه‌های کاغذی یا سخت قراردادها را، امضاشده و مهرشده، نگه می‌دارد. با این حال، ایده خوبی است که شما نسخه دیجیتال آن‌ها را در فضای فایل معمول خودتان، مثل Google Drive، Dropbox یا Office 365، برای بازیابی سریع و ارجاع نگه دارید. با این مقدمه، سراغ قراردادهایی برویم که معمولا وسیله انتقال «روح نیت» شما هستند.

۱۰.۱ توافق‌نامه خدمات

زمانی خواهد رسید، یا شاید همین حالا رسیده باشد، که خدمات یک شرکت شخص ثالث را به کار بگیرید. برخی دلیل‌های این کار عبارت‌اند از:

• تقویت نیروی انسانی
• پروژه مشخص
• پشتیبانی
• مدیریت سیستم

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

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

• بیانیه کار
• توافق‌نامه سطح خدمت

۱۰.۱.۱ بیانیه کار

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

۱۰.۱.۲ تعریف

توافق‌نامه عدم افشا (NDA) قرارداد کوچکی است میان دو طرف تا بتوانند برای پیشبرد گفت‌وگوها اطلاعات را محرمانه مبادله کنند، بی‌آنکه از از دست رفتن یا سوءاستفاده از IPR یا حقوق مالکیت فکری بترسند. این سند معمولا دامنه محدودی دارد و با یک بازه زمانی همراه است. داشتن یک NDA که وکیل شرکت آن را تنظیم و اعتبارسنجی کرده باشد ابزار خوبی در زرادخانه شماست تا هنگام نیاز آماده باشد. این سند که معمولا توسط CFO یا CEO امضا می‌شود، اسرار تجاری و فرایندهای شما را حفاظت می‌کند و در عین حال اجازه می‌دهد گفت‌وگوهای محدودی برای پیشبرد هدف کوتاه‌مدت خود داشته باشید. نمونه‌ای از NDA را می‌توانید اینجا ببینید: https://www.lawdepot.com/contracts/non-disclosure-agreement/.

در یک بیانیه کار معمول، ممکن است حوزه‌های زیر وجود داشته باشد:

• دامنه کار: حوزه‌هایی که روی آن‌ها کار خواهد شد و حوزه‌هایی که کار نخواهد شد
• تعریف تحویل‌دادنی‌ها: کد منبع، کتابخانه یا خدمت
• زمانی که واگذاری IPR کار انجام‌شده رخ می‌دهد
• دسترسی لازم برای انجام قرارداد
• انعطاف‌پذیری یا محدودیت‌ها درباره افراد، یا برون‌سپاری فرعی کار
• گام‌های مجوزدهی برای هر کار خارج از دامنه، مجوزهای اضافه یا سفر
• ضمانت برای هر کار تحویل‌شده
• بازه زمانی قرارداد
• رویه‌های تمدید، تجدید یا خاتمه
• محدودیت‌های راهکارهای پیشنهادی
• شرایط پرداخت

ریزبودن این توافق‌نامه به نوع همکاری مورد نیاز بستگی دارد. برای منابع سریع و درخواستی، مثل توسعه‌دهندگان، معمولا از نظر کاری که ارائه می‌شود چندان جزئی نیست. شاید بگوید «خدمات توسعه Java طبق دستور مدیر پروژه»، اما وظایف دقیق را شرح ندهد. با این حال، یک حداقل بازه زمانی خواهد داشت و بندی که می‌گوید شرکت بدون تایید قبلی نمی‌تواند آن فرد را برای مدتی، مثلا تا دو سال پس از خاتمه، مستقیما استخدام کند. در قراردادهای پشتیبانی، بیانیه کار ممکن است نسخه نرم‌افزاری را که برایش پشتیبانی ارائه می‌شود محدود کند، توضیح دهد هر چند وقت یک‌بار ارتقا انجام می‌دهند، و اگر لازم باشد آن را آفلاین کنند، این کار چگونه با کسب‌وکار مدیریت می‌شود. یک بیانیه کار خوب آن‌قدر جزئیات دارد که هر دو طرف دقیقا بدانند چه انتظاری از آن‌ها می‌رود، اما همچنان با محیطی در حال تغییر و تکامل سازگار می‌ماند. هیچ‌یک از طرفین نباید احساس کند گروگان طرف دیگر است؛ پس مراقب توافق‌هایی باشید که دوره تعهد بیش از حد طولانی دارند. برای نمونه‌های SOW نگاه کنید به: https://www.projectmanager.com/blog/statement-work-definition-examples.

توافق‌نامه سطح خدمت

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

AWS در SLA خود برای سرویس Elastic Compute Cloud یا EC2 می‌گوید دسترس‌پذیری ماهانه ۹۹.۹۹٪ خواهد داشت و اگر شکست بخورد، ۱۰٪ اعتبار روی صورت‌حساب داده می‌شود. این تقریبا معادل هر چیزی بیش از شش دقیقه قطعی در ماه است؛ پس از آن، Amazon ده درصد از صورت‌حساب EC2 شما را بدهکار است (https://aws.amazon.com/compute/sla/). هدف SLA فراهم کردن اعتماد و اطمینان است که بتوانید به یک خدمت مشخص تکیه کنید. مثلا فرض کنید Amazon اصلا SLA نداشت یا بدتر، فقط ۵۰٪ زمان روشن‌بودن را وعده می‌داد. یعنی می‌توانست در هر ماه تا دو هفته قطع باشد و مشتری هیچ راه جبرانی نداشته باشد. آیا کسب‌وکار شما چنین دسترس‌پذیری ضعیفی را تحمل می‌کرد؟ توافق SLA برای مدل‌های ابری و انواع X-as-a-Service بسیار رایج است. برای هر چیزی که در آن برای راه‌اندازی بخشی یا همه کسب‌وکارتان به شخص ثالث تکیه دارید، SLA به شما امکان می‌دهد بفهمید دست‌کم چه میزان زمان روشن‌بودن می‌توانید انتظار داشته باشید، و همین به مشتریان شما می‌گوید از خدمت شما چه انتظاری داشته باشند. SLAها می‌توانند در سطح‌های مختلف بیایند؛ هرچه تعداد ۹های بیشتری (.999999) از قابلیت اتکا بخواهید، هزینه بیشتر خواهد شد. پیدا کردن این توازن تا حد زیادی به نیاز شما بستگی دارد و ممکن است برای همه یکسان نباشد. برخی بخش‌های اکوسیستم شما می‌توانند قطعی بیشتری را تحمل کنند. SLA همچنین می‌تواند تعریف کند از زمان گزارش یک باگ یا مشکل تا تحویل حل موفق چقدر باید انتظار داشت. هرچه یک خدمت مهم‌تر باشد، خواسته شما از SLA بیشتر خواهد بود.

تعریف یک SLA

اگر از سوی دیگر نگاه کنیم، اگر محصول شما یک محصول X-as-a-Service یا API ارائه می‌کند، باید SLA خودتان را داشته باشید و بکوشید آن را رعایت کنید. این سطح خدمتی است که انتظار دارید بتوانید به کاربران خود ارائه دهید و جبرانی است که اگر در انجام آن شکست خوردید فراهم می‌کنید. اگر کاربران شما بیرونی‌اند، بخش جبران چیزی است که همراه با کسب‌وکار روی آن کار می‌کنید. مسئولیت اصلی شما این است که SLAای پیشنهاد کنید که در بودجه‌ای معقول قابل دستیابی باشد. نخستین نکته این است که SLA با ۱۰۰٪ دسترس‌پذیری دست‌نیافتنی است؛ متغیرهای بسیار زیادی در جریان‌اند تا چنین چیزی واقعا قابل تحقق باشد. بنابراین هنگام تعیین تضمین‌های زمان روشن‌بودن، پیش از اعلام عدد خود این موارد را در نظر بگیرید:

• در میان همه خدمات شخص ثالثی که به آن‌ها متکی هستید، بدترین SLA کدام است؟ شما فقط به اندازه ضعیف‌ترین حلقه خود قوی هستید.
• برای انتشارها یا ارتقاهای سیستم چقدر زمان قطعی لازم دارید؟
• آیا می‌توانید برای کل ۲۴ ساعت هر روز SLA بدهید یا فقط در ساعت‌های اصلی کسب‌وکار؟
• زمان حل یک مشکل گزارش‌شده چقدر است؟
• آیا نیروی پشتیبانی لازم را برای پوشش پشتیبانی، به‌ویژه هنگام تعطیلات، دارید؟
• سابقه عملکرد ارائه شما تا اینجا چه بوده است؟
• ضعیف‌ترین بخش یا نقطه شکست واحد در ارائه شما چیست که بر زمان روشن‌بودن اثر می‌گذارد؟

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

۱۰.۲ ارزیابی فروشندگان

وقتی حوزه‌ای را که در آن از فروشنده شخص ثالث کمک می‌خواهید شناسایی کردید، طرح توافق‌نامه خدمات را ساختید و الزامات SLA خود را تعریف کردید، تلاش شما به سمت بررسی فروشندگان می‌رود. این فرایند، یا رفتن به مناقصه، یعنی گردآوری فهرستی از ارائه‌دهندگان بالقوه و شروع ارزیابی آن‌ها. گفتنش بدیهی به نظر می‌رسد، اما با این حال می‌گویم: قیمت ویژگی برنده نیست. پیش از تصمیم نهایی باید عوامل زیر را در نظر بگیرید:

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

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

۱۰.۳ مجوزدهی نرم‌افزار

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

• تاریخ تهیه
• تاریخ و هزینه تمدید
• جزئیات تماس
• جزئیات تماسی که آن‌ها از شما دارند، مانند ایمیل، تلفن یا نشانی
• یادداشت‌هایی درباره استفاده داخلی
• کلیدها یا کدهای مجوز

این فهرست باید دست‌کم هر شش ماه یک‌بار بررسی شود تا مطمئن شوید به‌روز مانده است، و همچنین هر زمان خرید جدید یا تمدیدی انجام می‌شود. شرکت‌ها اغلب هم کمتر از حد و هم بیشتر از حد برای مجوزها هزینه می‌کنند. فروشندگان بزرگ نرم‌افزار، مانند Microsoft، Oracle و IBM، مجوزهای پیچیده‌ای دارند که اغلب تغییر می‌کند. در روزهای قدیم ساده بود، چون نرم‌افزار اساسا برای یک سرور مشخص بود. اما با ظهور پردازنده‌های چند‌هسته‌ای و مجازی‌سازی، دیگر نمی‌شد به‌سادگی فرض کرد یک سرور سخت‌افزاری می‌تواند میزبان ۱۰ سرور مجازی باشد. مجوز چگونه تغییر می‌کند؟ اگر سرور فقط برای یک بازه زمانی مشخص اجرا شود، مثلا در ابر عمومی، چه؟ فروشندگان طبیعتا احساس کردند از آن‌ها کم گذاشته می‌شود و متناسب با آن خود را تطبیق دادند.

خارج شدن از محدوده مجوز می‌تواند با تکامل سازمان شما بسیار آسان و بی‌قصد رخ دهد. بنابراین مهم است هر زمان تغییرات مهمی ایجاد می‌کنید ریزنوشت‌ها را بررسی کنید. با نماینده حساب خود تماس بگیرید؛ او با خوشحالی تماس شما را پاسخ می‌دهد و می‌تواند شما را راهنمایی کند. اگر مراقب نباشید، مجوزدهی سیستم‌عامل‌ها و پایگاه‌های داده خیلی سریع بسیار گران می‌شود. اگرچه تصمیم به استفاده از SQL Server مایکروسافت در توسعه هزینه‌ای ندارد، وقتی به تولید می‌روید ممکن است با هزینه مجوز چشمگیری روبه‌رو شوید؛ در برخی موارد معادل یک حقوق. بیشتر فروشندگان خوشحال می‌شوند برای توسعه دسترسی کامل به مجموعه خود بدهند، چون این راه آن‌ها برای جذب یا قفل کردن شماست. انتخاب هوشمندانه و فهم ملاحظات مجوز پیش از چراغ سبز دادن به هر تصمیم فناوری می‌تواند در آینده سود زیادی داشته باشد. فروشندگان ابر عمومی این فاصله را کمی پر کرده‌اند. هم Amazon و هم Azure پیشنهادهای تجاری مجازی‌شده‌ای دارند که هزینه مجوز در قیمت دقیقه‌ای گنجانده شده است. اجرای یک نمونه Windows Server EC2 به جای یک نمونه Linux چند سنت در دقیقه بیشتر هزینه دارد تا مجوز را پوشش دهد. این نگرانی را از بین می‌برد که از نگاه مجوز قانونی هستید یا نه. پیش‌تر درباره مزایای گزینه‌های متن‌باز، مانند Linux در برابر Windows، MySQL/Postgres در برابر SQL Server و مانند آن صحبت کرده‌ایم. اما اگر پشتیبانی تجاری بخواهید، یعنی شماره تلفنی که وقتی چیزی خراب شد تماس بگیرید، چه؟ خبر خوب این است که همه نهادهای بزرگ نرم‌افزار متن‌باز اکوسیستم خود را دارند تا طیف گسترده‌ای از پشتیبانی را در اختیارتان بگذارند. قیمت‌ها و خدمات متفاوت‌اند، اما یافتن گزینه‌ای برای نیازهای شما نباید دشوار باشد.

۱۰.۴ قراردادهای پشتیبانی

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

همه اجزای اصلی سازمان خود را شناسایی کنید

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

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

جمع‌بندی

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

چک‌لیست

چند مورد از موارد زیر را می‌توانید ادعا کنید که پوشش داده‌اید؟

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