هزینه نگهداری نرمافزار را نمیتوان فقط با درصدی از مبلغ ساخت مشخص کرد. بودجه واقعی به ساعت پوشش، حساسیت عملیات، کیفیت مستندات، تعداد اتصالها، وضعیت زیرساخت و میزان تغییرات بستگی دارد. برای مقایسه پیشنهادها، ابتدا مشخص کنید چه چیزی باید پایدار بماند، چه کسی در زمان خرابی مسئول است و کدام کارها خارج از مبلغ ماهانه حساب میشوند.
این راهنما برای مدیری است که نرمافزار را تحویل گرفته یا در آستانه تحویل است و میخواهد هزینه سال بعد را قابل پیشبینی کند. موضوع ما قیمت توسعه اولیه نیست؛ آن بحث در راهنمای هزینه ساخت نرمافزار سفارشی توضیح داده شده است. اینجا بودجه بهرهبرداری، پشتیبانی و تغییر را از هم جدا میکنیم تا پیشنهاد ارزان روی کاغذ، بعداً به صورتحساب غیرمنتظره تبدیل نشود.
نگهداری دقیقاً شامل چه کارهایی است؟
پیش از دریافت قیمت، یک فهرست روشن از خدمات بسازید. عبارت «پشتیبانی کامل» به تنهایی مشخص نمیکند که اصلاح خطا، پاسخگویی به کاربر، ارتقای کتابخانهها، پایش سرور و افزودن گزارش جدید همگی در مبلغ پیشنهادی هستند یا نه. همین ابهام میتواند مقایسه دو پیمانکار را بیمعنا کند.
رفع خطا و پاسخ به رخداد
اگر یک قابلیت برخلاف رفتار تأییدشده کار کند، مسئله احتمالاً در محدوده رفع خطاست؛ اما ابتدا باید همان رفتار تأییدشده قابل مراجعه باشد. نمونه ورودی، خروجی مورد انتظار و شرایط تکرار مشکل را نگه دارید. درخواست «گزارش باید ستون جدید داشته باشد» معمولاً تغییر قابلیت است، نه خرابی گزارش قبلی. این مرز را با مثالهای واقعی سازمان تعریف کنید.
نگهداری پیشگیرانه و سازگاری
همه کارهای ضروری از شکایت کاربر شروع نمیشوند. بازبینی ظرفیت، بررسی خطاهای تکرارشونده، بهروزرسانی وابستگیها و کنترل سازگاری با سرویسهای متصل ممکن است قبل از خرابی لازم باشند. اگر فقط برای ساعات رفع حادثه بودجه بگذارید، کار پیشگیرانه دائماً به تعویق میافتد. برای هر فعالیت دوره، مسئول و خروجی قابل بررسی تعیین کنید.
توسعه و بهبود محصول
افزودن گردش کار تازه، تغییر قواعد قیمتگذاری یا طراحی داشبورد جدید باید بودجه مشخص داشته باشد. میتوانید ظرفیت محدودی برای تغییرات کوچک رزرو کنید، ولی تعریف «کوچک» را به تعداد صفحه محدود نکنید. تغییر ظاهراً ساده در یک فیلد ممکن است گزارشها، اتصالها و سطح دسترسی را تحت تأثیر قرار دهد. برآورد اثر، بخشی از خود کار است.
شش عامل اصلی هزینه پس از تحویل
اولین عامل، ساعت پوشش است. پاسخگویی در روزهای کاری با آمادگی خارج از ساعت اداری یکسان نیست. حتی وقتی رخدادی پیش نمیآید، حفظ آمادگی تیم هزینه دارد. مشخص کنید کدام فرایند واقعاً به پوشش گسترده نیاز دارد؛ ممکن است توقف ثبت سفارش فوری باشد اما اختلال یک گزارش هفتگی بتواند تا روز کاری بعد منتظر بماند.
عامل دوم، پیامد توقف است. تعداد کاربران تنها معیار مناسبی نیست. یک سامانه با کاربران محدود ممکن است تأیید خروج کالا را کنترل کند و توقفش عملیات انبار را متوقف سازد. برای هر قابلیت حساس، اثر اختلال و راهکار موقت را بنویسید. همین اطلاعات به انتخاب سطح خدمت متناسب کمک میکند، بدون اینکه برای همه بخشها بالاترین سطح پوشش بخرید.
عامل سوم، شناختپذیری سیستم است. مخزن کد مرتب، دستور استقرار قابل تکرار، آزمونهای کاربردی و مستندات اتصال، زمان شناخت و بررسی تغییر را کاهش میدهند. در مقابل، سامانهای که فقط یک نفر روش راهاندازی آن را میداند، هنگام جابهجایی تیم هزینه انتقال دانش دارد. این هزینه را از مبلغ نگهداری عادی جدا و بهعنوان مرحله تحویلگیری برآورد کنید.
عامل چهارم، وابستگی به سامانههای دیگر است. تغییر رابط یک سرویس بیرونی ممکن است در نرمافزار شما اصلاح لازم ایجاد کند، حتی اگر کد داخلی تغییر نکرده باشد. تعداد اتصالها، مالک هر سرویس و روش اطلاع از تغییرات را فهرست کنید. عامل پنجم، حجم داده و مصرف زیرساخت است؛ ذخیرهسازی، پردازش و نگهداری گزارشهای فنی باید مستقل دیده شوند.
عامل ششم، آهنگ تغییر کسبوکار است. سازمانی که هر ماه قواعد عملیاتی تازه دارد با سامانهای تقریباً ثابت یک بودجه ندارد. سابقه درخواستها را بررسی کنید و کارهای ضروری را از خواستههای قابل تعویق جدا سازید. تخمین بر اساس چند ماه فعالیت واقعی، معمولاً برای مذاکره مفیدتر از تکیه صرف بر مبلغ قرارداد ساخت است.
مدل ماهانه، ساعتی یا ترکیبی؟
در مدل ماهانه، برای دامنه مشخصی از خدمات و دسترسپذیری تیم مبلغ ثابت پرداخت میکنید. مزیت آن قابلیت برنامهریزی است؛ اما باید روشن باشد چه تعداد ساعت، چه نوع کار و چه سطح پوششی در آن وجود دارد. ساعات مصرفنشده منتقل میشوند یا خیر؟ کار اضطراری از همان ظرفیت کسر میشود؟ این پرسشها را قبل از انتخاب پاسخ دهید.
مدل ساعتی برای سامانه کمتغییر یا کارهای موردی قابل بررسی است. ریسک آن این است که پرداخت ساعت، لزوماً به معنای رزرو ظرفیت فوری نیست. روش ثبت زمان، تأیید برآورد و اطلاعرسانی پیش از عبور از سقف بودجه را مشخص کنید. صرف پایینتر بودن نرخ یک ساعت نشان نمیدهد مجموع هزینه کمتر خواهد بود.
مدل ترکیبی میتواند پوشش و فعالیتهای پایه را ثابت نگه دارد و تغییرات محصول را جدا حساب کند. برای مثال، پایش و رسیدگی اولیه در مبلغ پایه باشند، اما قابلیت جدید پس از برآورد تأیید شود. انتخاب مناسب به الگوی کار شما بستگی دارد؛ هیچکدام بهطور مطلق بهترین نیستند. مهم این است که خدمات مشابه را کنار هم مقایسه کنید.
یک نمونه محاسبه شفاف، بدون تعرفهسازی
فرض کنید برای برنامهریزی داخلی، ماهانه ۱۲ ساعت فعالیت پیشگیرانه، ۸ ساعت ظرفیت رسیدگی به رخداد و ۱۰ ساعت تغییر تأییدشده در نظر گرفتهاید. مجموع ظرفیت برنامهریزیشده ۳۰ ساعت است. این اعداد صرفاً مثالاند و نرخ بازار یا پیشنهاد ایزیساز محسوب نمیشوند. اگر نرخ توافقی هر ساعت را «ر» بنامیم، هزینه این ظرفیت برابر ۳۰ ضربدر ر خواهد بود.
به این عدد، هزینه زیرساخت، سرویسهای بیرونی و هر مبلغ جداگانه آمادگی تیم را اضافه کنید؛ البته فقط وقتی قبلاً داخل قیمت پایه حساب نشدهاند. سپس هزینههای یکباره مانند تحویلگیری یا اصلاح عقبماندگی را جدا بنویسید. دو بار شمردن ساعات داخل بسته و مبلغ بسته، یکی از خطاهای سادهای است که برآورد را گمراهکننده میکند.
برای بودجه سالانه، هزینه ماهانه تکرارشونده را در ۱۲ ضرب کنید و اقلام یکباره را اضافه نمایید. برای تغییر مصرف یا رخدادهای نامطمئن، یک سناریوی جدا بسازید، نه یک عدد قطعی بدون توضیح. سناریوی کممصرف، پایه و پرمصرف باید فرضهای متفاوت و قابل مشاهده داشته باشند. ذخیره احتیاطی نیز باید دلیل داشته باشد و با هزینه قطعی اشتباه نشود.
سطح خدمت را با نتیجه قابل اندازهگیری تعریف کنید
زمان پاسخ با زمان رفع مشکل فرق دارد. پاسخ میتواند صرفاً به معنای دریافت درخواست باشد؛ بررسی فنی، ارائه راهکار موقت و رفع نهایی مراحل دیگری هستند. پیشنهاد قیمت باید مشخص کند هر تعهد به کدام مرحله اشاره دارد و ساعت اندازهگیری از چه زمانی شروع میشود. درخواست ناقص و انتظار برای دسترسی مشتری هم باید روش ثبت روشن داشته باشد.
یک دستهبندی پیشنهادی، تفکیک توقف فرایند حیاتی، اختلال محدود با راهکار موقت و درخواست عادی است. برای هر دسته مثال بنویسید و مسئول اعلام اولویت را تعیین کنید. اگر همه درخواستها فوری نامیده شوند، اولویت واقعی از بین میرود. در گزارش ماهانه، رخدادها را با اثر عملیاتی و زمانهای ثبتشده مرور کنید، نه فقط تعداد تیکت بستهشده.
هزینههای پنهان را قبل از مقایسه پیدا کنید
از ارائهدهنده بخواهید اقلام خارج از محدوده را صریح بنویسد: زیرساخت، گواهیها، پیامک، فضای پشتیبان، محیط آزمایشی، سفر احتمالی، آموزش دوباره یا اصلاح داده. این فهرست الزاماً به معنای گرانبودن پیشنهاد نیست؛ شفافیت کمک میکند دو پیشنهاد را با مبنای مشابه بسنجید. درباره مبلغ نهایی قابل پرداخت و دوره اعتبار قیمت نیز توضیح مکتوب بخواهید.
به انتقال مسئولیت هم توجه کنید. چه کسی مالک حسابهاست و چه کسی مجوز دسترسی دارد؟ هنگام تغییر پیمانکار، مستندات و نسخه قابل استقرار چگونه تحویل میشوند؟ بودجه خروج و انتقال دانش را از ابتدا ببینید. برای ساماندادن نیازها پیش از مذاکره، راهنمای سفارش نرمافزار سفارشی میتواند مبنای آمادهسازی اطلاعات باشد.
امنیت و بازیابی، ردیف بودجه هستند
پشتیبانگیری زمانی ارزش عملیاتی دارد که بازیابی آن قابل انجام باشد. علاوه بر تهیه نسخه، برای بررسی نتیجه و تمرین بازگردانی در محیط مناسب زمان اختصاص دهید. مشخص کنید چه دادهای، با چه تناوب و توسط چه کسی کنترل میشود. داشتن فایل پشتیبان به تنهایی، زمان برگشت خدمت را تضمین نمیکند.
راهنمای CISA برای کسبوکارهای کوچک و متوسط به بهروزرسانی نرمافزار، ثبت رویداد و پشتیبانگیری توجه میدهد. در بودجه پیشنهادی این مقاله، این موارد باید مسئول و خروجی داشته باشند؛ این پیشنهاد جایگزین ارزیابی امنیت اختصاصی نیست. بهروزرسانیهای حساس نیز به بررسی اثر و برنامه بازگشت متناسب با سامانه نیاز دارند.
چطور سه پیشنهاد را منصفانه مقایسه کنیم؟
برای همه ارائهدهندگان یک برگه مشترک بفرستید: ساعات کار سازمان، قابلیتهای حیاتی، فهرست اتصالها، وضعیت مستندات و نمونه رخدادها. سپس از هرکدام بخواهید مبلغ پایه، ظرفیت، زمان پوشش، استثناها و هزینه تحویلگیری را جدا اعلام کنند. مقایسه یک بسته شامل زیرساخت با بسته بدون زیرساخت، بدون تعدیل این تفاوت معتبر نیست.
بعد، یک رخداد فرضی یکسان مطرح کنید: ثبت سفارش متوقف شده، بخشی از کاربران درگیرند و راهکار موقت محدود است. بپرسید روند اقدام چیست، چه کسی اطلاع میدهد و هزینه چگونه محاسبه میشود. پاسخ عملیاتی، ابهامهای پیشنهاد را بهتر از واژههایی مانند «طلایی» یا «نامحدود» آشکار میکند. وعده بدون روش اجرا را امتیاز قطعی حساب نکنید.
برنامه اولین ماه همکاری
در شروع، موجودی سامانه و دسترسیها را ثبت کنید؛ سپس یک استقرار آزمایشی و یک بازیابی کنترلشده انجام دهید. فهرست خطاهای شناختهشده و درخواستهای توسعه را از هم جدا سازید. برای هر مورد، مسئول، اولویت و تصمیم بعدی مشخص باشد. این مرحله را با تعهد رفع همه مشکلات قدیمی در مبلغ عادی ماهانه اشتباه نگیرید.
در پایان ماه، ساعات صرفشده، علت رخدادهای مهم و کارهای پیشگیرانه انجامشده را مرور کنید. اگر بخش زیادی از ظرفیت صرف یک خطای تکراری شده است، اصلاح ریشهای آن را جدا برآورد کنید. هدف گزارش، پرکردن ظرفیت خریداریشده نیست؛ باید نشان دهد چه ریسکی کم شده و چه تصمیمی برای ماه آینده لازم است.
جمعبندی: هزینه کمتر از محدوده روشن شروع میشود
بودجه نگهداری قابل دفاع، ترکیبی از دامنه روشن، پوشش متناسب و خروجی قابل بررسی است. ابتدا رفع خطا، پیشگیری و توسعه را جدا کنید؛ سپس هزینه تکرارشونده، یکباره و مصرفی را بنویسید. به این ترتیب، تصمیم شما بر اساس نیاز واقعی خواهد بود و تغییر هزینه هم قابل توضیح میماند.
اگر میخواهید نگهداری را همزمان با طراحی محصول برنامهریزی کنید، خدمات نرمافزار سفارشی ایزیساز را ببینید. برای بررسی محدوده و تهیه برآورد متناسب، از صفحه تماس ایزیساز وضعیت فعلی سامانه، ساعت پوشش مورد نیاز و فهرست اتصالها را ارسال کنید؛ همین اطلاعات نقطه شروع دقیقتری از درخواست یک قیمت کلی است.