چرا قراردادهای نرمافزاری به بند تعدیل نیاز دارند؟
تعدیل قراردادهای فناوری اطلاعات هنوز برای بسیاری از کارفرمایان و حتی برخی شرکتهای نرمافزاری، موضوعی عجیب یا معادل «گران کردن قرارداد» تلقی میشود. در حالی که در پروژههای نرمافزاری، تعدیل نه یک امتیاز اضافی برای پیمانکار، بلکه یکی از ابزارهای منطقی مدیریت ریسک قرارداد است.
وقتی یک قرارداد توسعه نرمافزار برای ۶ ماه، یک سال یا حتی چند سال منعقد میشود، آیا منطقی است انتظار داشته باشیم تمام هزینههای اجرای آن پروژه در طول مدت قرارداد دقیقاً ثابت باقی بماند؟
هزینه نیروی انسانی، حقوق برنامهنویسان، هزینه زیرساخت، سرور، خدمات ابری، لایسنس نرمافزارها، سرویسهای خارجی، خدمات امنیتی، پشتیبانی و حتی هزینههای سربار یک شرکت فناوری اطلاعات در طول زمان تغییر میکنند.
با این حال هنوز در بسیاری از قراردادهای نرمافزاری، مبلغ قرارداد در روز انعقاد قرارداد تعیین میشود و تا پایان پروژه بدون هیچ سازوکاری برای تغییر شرایط اقتصادی ثابت باقی میماند.
این رویکرد ممکن است در ظاهر به نفع کارفرما باشد، اما در پروژههای بلندمدت میتواند در نهایت به ضرر هر دو طرف قرارداد تمام شود.
تعدیل قرارداد دقیقاً چیست؟
به زبان ساده، تعدیل قرارداد یعنی از ابتدا در قرارداد پیشبینی کنیم که اگر در طول اجرای پروژه، برخی عوامل اقتصادی یا زمانی خارج از کنترل طرفین تغییر کرد، مبلغ یا مدت قرارداد بر اساس یک سازوکار مشخص قابل اصلاح باشد.
تعدیل با افزایش قیمت دلخواه تفاوت دارد.
در یک قرارداد حرفهای، مشخص میشود:
- چه عواملی باعث تعدیل میشوند؟
- تعدیل از چه تاریخی محاسبه میشود؟
- شاخص یا معیار تعدیل چیست؟
- تعدیل شامل کدام بخشهای قرارداد است؟
- حداقل یا حداکثر میزان تعدیل چقدر است؟
- تعدیل در چه دورههایی محاسبه میشود؟
- تأخیر کارفرما چه اثری بر تعدیل دارد؟
- تغییرات ناشی از درخواستهای جدید کارفرما چگونه محاسبه میشوند؟
بنابراین تعدیل در واقع تبدیل یک موضوع مبهم و مناقشهبرانگیز به یک فرمول قراردادی از پیش توافق شده است.
چرا تعدیل در قراردادهای نرمافزاری اهمیت بیشتری دارد؟
ممکن است تصور شود تعدیل بیشتر مربوط به پروژههای عمرانی، ساختمانی یا خرید تجهیزات است؛ اما ساختار اقتصادی پروژههای نرمافزاری نیز بهشدت تحت تأثیر تورم و تغییر قیمت نهادهها قرار دارد.
مهمترین تفاوت اینجاست که در نرمافزار، بخش بزرگی از هزینه پروژه به نیروی انسانی متخصص وابسته است.
برای مثال فرض کنید یک شرکت نرمافزاری در ابتدای سال قراردادی ۱۲ماهه برای توسعه یک سامانه سازمانی منعقد میکند.
در زمان قرارداد، شرکت بر اساس هزینههای جاری خود محاسبه کرده است که پروژه با استفاده از:
- تحلیلگر کسبوکار
- مدیر پروژه
- برنامهنویس Backend
- برنامهنویس Frontend
- متخصص پایگاه داده
- متخصص DevOps
- تستر نرمافزار
قابل اجراست.
اما اگر در طول اجرای قرارداد هزینه جذب و نگهداری این نیروها به شکل محسوسی افزایش پیدا کند، مبلغ قرارداد همچنان ثابت مانده است.
در این شرایط شرکت نرمافزاری سه انتخاب دارد:
۱. کاهش کیفیت پروژه
یعنی استفاده از نیروی ارزانتر، کاهش زمان تست، کاهش مستندسازی یا حذف بخشی از فعالیتهای مهندسی.
۲. کاهش حاشیه سود یا حتی ورود به زیان
شرکت پروژه را با همان قیمت ادامه میدهد و افزایش هزینهها را خودش تحمل میکند.
۳. توقف یا اختلاف قراردادی
پیمانکار به این نتیجه میرسد که ادامه پروژه با شرایط موجود اقتصادی نیست و اختلاف میان طرفین شکل میگیرد.
در هیچکدام از این سه حالت، کارفرما برنده واقعی نیست.
تعدیل فقط برای پیمانکار نیست؛ برای کارفرما هم مفید است
یکی از مهمترین نکاتی که باید در فرهنگ قراردادهای فناوری اطلاعات جا بیفتد این است:
تعدیل، ابزار حمایت از پیمانکار در برابر کارفرما نیست؛ ابزار حفاظت از پروژه در برابر تغییرات محیطی است.
اگر قرارداد بهگونهای تنظیم شود که پیمانکار در برابر افزایش غیرعادی هزینهها هیچ راهکاری نداشته باشد، ریسک اقتصادی پروژه به شکل نامتعارفی روی یک طرف قرار میگیرد.
نتیجه چنین قراردادی ممکن است شامل موارد زیر باشد:
- کاهش کیفیت نرمافزار
- کاهش سطح پشتیبانی
- خروج نیروهای متخصص از پروژه
- کاهش انگیزه تیم توسعه
- افزایش اختلافات مالی
- تأخیر در تحویل
- درخواستهای مکرر برای الحاقیه
- توقف پروژه
- یا حتی شکست کامل پروژه
در مقابل، اگر مکانیزم تعدیل از ابتدا مشخص باشد، هر دو طرف میدانند در صورت تغییر شرایط چه اتفاقی خواهد افتاد.
این یعنی کاهش ریسک قراردادی.
تعدیل در قراردادهای فناوری اطلاعات موضوع جدیدی نیست
موضوع تعدیل قراردادهای حوزه فناوری اطلاعات در ایران حداقل از سالهای گذشته به شکل رسمی مورد توجه تشکلهای تخصصی و دستگاههای دولتی قرار گرفته است.
برای نمونه، در سال ۱۳۹۹ و در پی افزایش شدید نرخ ارز، آثار کرونا، مشکلات تخصیص ارز و تحریمها، وزارت ارتباطات و فناوری اطلاعات پیشنهاد تدوین سازوکار تخصصی برای تعدیل قراردادهای حوزه ICT را به سازمان برنامه و بودجه ارائه کرد.
در این پیشنهاد، علاوه بر تعدیل ریالی، موضوع تعدیل زمانی قراردادهای حوزه فاوا نیز مطرح شده بود و بر تعیین یک فرمول منطقی و منصفانه برای جلوگیری از زیان پیمانکاران تأکید شده بود. این پیشنهاد با مشارکت تشکلهایی از جمله سازمان نظام صنفی رایانهای، سندیکای صنعت مخابرات ایران و اتحادیه صادرکنندگان خدمات مهندسی مشاوران و پیمانکاران صنعت مخابرات ایران تهیه شده بود.
نکته مهم اینجاست که باید میان «پیشنهاد آییننامه» و «آییننامه نهایی و لازمالاجرا» تفاوت قائل شد. مستندات منتشرشده درباره سال ۱۳۹۹، از ارسال و پیگیری یک آییننامه پیشنهادی خبر میدهند؛ بنابراین نمیتوان صرفاً بر اساس آن مستند گفت که یک آییننامه مستقل و عمومی برای همه قراردادهای نرمافزاری کشور تصویب و لازمالاجرا شده است.
اما این موضوع یک پیام مهم دارد:
حتی در سطح سیاستگذاری کشور نیز سالهاست پذیرفته شده که قراردادهای فناوری اطلاعات میتوانند تحت تأثیر عوامل اقتصادی خارج از اختیار پیمانکار قرار بگیرند.
تعدیل در تعرفههای خدمات فناوری اطلاعات هم سابقه دارد
موضوع حتی از این فراتر میرود.
در اسناد تعرفهای خدمات فنی-تخصصی انفورماتیک، نمونههایی از پیشبینی تعدیل سالانه وجود دارد.
برای مثال، در تعرفه خدمات مشاوره مرکز داده، برای قراردادهایی که در اثر تطویل مجاز پروژه ــ خارج از کنترل و تعهد مشاور ــ ادامه پیدا میکنند، سازوکاری برای تعدیل و افزایش سالانه نرخ خدمات بر اساس نرخ اعلامی سازمان نظام صنفی رایانهای پیشبینی شده است.
این نکته بسیار قابل توجه است.
یعنی مسئله این نیست که «آیا خدمات فناوری اطلاعات اصولاً باید تعدیل داشته باشند یا نه؟»
مسئله اصلی این است که:
تعدیل باید با چه فرمولی، در چه شرایطی و برای چه بخشهایی از قرارداد اعمال شود؟
چرا قیمت نرمافزار نمیتواند برای چند سال ثابت بماند؟
بیایید یک قرارداد واقعی را تصور کنیم.
فرض کنید یک سازمان در سال ۱۴۰۵ قراردادی برای طراحی و توسعه یک سامانه جامع سازمانی منعقد میکند.
مدت قرارداد:
۱۸ ماه
مبلغ قرارداد:
۱۰ میلیارد تومان
حالا اجرای قرارداد تا سال ۱۴۰۶ یا ۱۴۰۷ ادامه پیدا میکند.
در این مدت ممکن است هزینههای زیر تغییر کنند:
| عامل | اثر احتمالی بر پروژه |
|---|---|
| حقوق و دستمزد نیروی متخصص | افزایش هزینه تیم توسعه |
| تورم | افزایش هزینههای عملیاتی |
| نرخ ارز | افزایش هزینه سرویسها و لایسنسهای خارجی |
| خدمات Cloud | افزایش هزینه زیرساخت |
| تجهیزات Server و Network | افزایش هزینه تأمین |
| سرویسهای API خارجی | افزایش هزینه مصرف |
| خدمات امنیتی | افزایش هزینه تست و ارزیابی |
| هزینههای اداری و بیمه | افزایش هزینه سربار |
| تأخیر در پرداخت کارفرما | افزایش هزینه تأمین مالی |
| تأخیر در تحویل اطلاعات توسط کارفرما | افزایش مدت پروژه |
اگر قرارداد هیچ سازوکاری برای این تغییرات نداشته باشد، در واقع یک ریسک بسیار بزرگ را بدون محاسبه به پیمانکار منتقل کرده است.
نکته مهم: تعدیل با Change Request فرق دارد
یکی از اشتباهات رایج در قراردادهای نرمافزاری، مخلوط کردن تعدیل با تغییر محدوده پروژه است.
این دو موضوع باید کاملاً جدا باشند.
تعدیل
مربوط به تغییر هزینه اجرای همان تعهدات قبلی است.
مثلاً:
پیمانکار متعهد به توسعه همان سامانه است، اما هزینه نیروی انسانی در طول اجرای قرارداد افزایش پیدا کرده است.
تغییر محدوده یا Change Request
مربوط به اضافه شدن تعهدات جدید است.
مثلاً:
کارفرما ابتدا ۱۰ گزارش مدیریتی درخواست کرده اما در میانه پروژه ۱۵ گزارش جدید، اپلیکیشن موبایل و اتصال به یک سامانه خارجی نیز درخواست میکند.
این دیگر تعدیل نیست؛ تغییر محدوده کار است و باید بهصورت جداگانه قیمتگذاری شود.
تعدیل زمانی هم به اندازه تعدیل مالی اهمیت دارد
در پروژههای نرمافزاری، تنها پول نیست که تغییر میکند؛ زمان نیز هزینه دارد.
فرض کنید قرارداد برای تحویل یک سامانه در مدت ۹ ماه منعقد شده است.
اما کارفرما:
- اطلاعات مورد نیاز را با تأخیر تحویل میدهد؛
- API سامانههای وابسته را دیر آماده میکند؛
- فرآیند تأیید مستندات را طولانی میکند؛
- محیط تست را بهموقع آماده نمیکند؛
- یا درخواستهای جدیدی به پروژه اضافه میکند.
پروژه به جای ۹ ماه، ۱۴ ماه طول میکشد.
اگر قرارداد برای ۱۴ ماه هیچ راهکاری نداشته باشد، پیمانکار عملاً باید پنج ماه بیشتر نیروی انسانی و زیرساخت در اختیار پروژه قرار دهد، بدون اینکه لزوماً امکان دریافت هزینه متناسب با این افزایش مدت را داشته باشد.
بنابراین در قراردادهای نرمافزاری حرفهای بهتر است بین موارد زیر تفکیک وجود داشته باشد:
تعدیل مبلغ قرارداد + تمدید مدت قرارداد + هزینه دوره تمدید + تغییر محدوده پروژه
آیا باید برای همه قراردادهای نرمافزاری یک درصد ثابت تعدیل تعیین کرد؟
خیر.
اتفاقاً یکی از بدترین روشها این است که بدون توجه به ساختار هزینه پروژه، صرفاً یک عدد ثابت مانند «۲۰ درصد افزایش سالانه» در قرارداد نوشته شود.
پروژههای فناوری اطلاعات ساختار هزینه یکسانی ندارند.
برای مثال:
یک پروژه ممکن است ۹۰ درصد هزینهاش نیروی انسانی باشد.
پروژه دیگری ممکن است بخش قابل توجهی از هزینه آن مربوط به:
- لایسنس خارجی
- Cloud
- تجهیزات
- سرویسهای ارزی
- APIهای خارجی
باشد.
بنابراین روش حرفهایتر، استفاده از فرمول تعدیل متناسب با ساختار هزینه پروژه است.
برای مثال، میتوان در یک قرارداد فرضی چنین ساختاری تعریف کرد:
۷۰ درصد مبلغ قرارداد تابع شاخص هزینه نیروی انسانی، ۲۰ درصد تابع شاخص هزینههای ارزی و خدمات خارجی و ۱۰ درصد مربوط به هزینههای عمومی و سربار باشد.
اعداد فوق صرفاً مثال هستند و برای هر پروژه باید متناسب با ساختار واقعی هزینه تعیین شوند.
یک مدل منطقی برای تعدیل قرارداد نرمافزاری
یک روش قابل دفاع میتواند این باشد که مبلغ قرارداد به اجزای مختلف تقسیم شود.
برای نمونه:
مبلغ تعدیلشده =
سهم نیروی انسانی × شاخص تغییر هزینه نیروی انسانی
سهم ارزی × شاخص تغییر نرخ ارز
سهم سایر هزینهها × شاخص توافقشده
در چنین مدلی، تعدیل دیگر یک افزایش قیمت نامشخص نیست.
بلکه طرفین از روز اول میدانند:
اگر X تغییر کند، اثر آن روی قرارداد Y خواهد بود.
این شفافیت، احتمال اختلاف را بهشدت کاهش میدهد.
تعدیل باید از ابتدا در قرارداد نوشته شود
یکی از مهمترین توصیههای قراردادی برای کارفرمایان و شرکتهای فناوری اطلاعات این است:
تعدیل را به روزی موکول نکنید که بحران اقتصادی اتفاق افتاده است.
بهترین زمان برای تعیین فرمول تعدیل، زمان مذاکره و انعقاد قرارداد است.
در آن زمان هر دو طرف شرایط را میدانند و میتوانند درباره فرمولی منصفانه توافق کنند.
اما اگر قرارداد بدون تعدیل امضا شود و یک سال بعد هزینه اجرای پروژه افزایش شدیدی پیدا کند، مذاکره مجدد بسیار دشوارتر خواهد شد.
از نظر حقوق قراردادها نیز باید توجه داشت که اصل آزادی قراردادها به طرفین اجازه میدهد در حدود قانون، شروط قراردادی خود را تنظیم کنند و قرارداد صحیح نیز اصولاً برای طرفین لازمالاتباع است. بنابراین اگر طرفین میخواهند سازوکار تعدیل داشته باشند، بهتر است این سازوکار بهصورت شفاف و دقیق در متن قرارداد درج شود، نه اینکه صرفاً به انتظار یک تصمیم بعدی یا توافق مجدد گذاشته شود.
یک بند تعدیل خوب باید چه چیزهایی داشته باشد؟
یک بند تعدیل حرفهای در قرارداد نرمافزاری بهتر است حداقل موارد زیر را مشخص کند:
۱. مبنای شروع تعدیل
مثلاً تاریخ امضای قرارداد، تاریخ ارائه پیشنهاد قیمت یا تاریخ شروع اجرای پروژه.
۲. دوره محاسبه
مثلاً هر شش ماه یا سالانه.
۳. شاخص تعدیل
برای مثال شاخص مورد توافق طرفین، نرخنامه رسمی مرتبط، شاخص هزینه نیروی انسانی یا شاخص ارزی مربوط به بخشهای ارزی پروژه.
۴. دامنه شمول
آیا کل مبلغ قرارداد تعدیل میشود یا فقط بخش باقیمانده کار؟
۵. تأخیر کارفرما
اگر تأخیر ناشی از کارفرما باعث افزایش مدت پروژه شود، باید مشخص شود هزینه این دوره چگونه محاسبه خواهد شد.
۶. تغییرات ارزی
اگر پروژه دارای لایسنس، سرویس یا زیرساخت ارزی است، مبنای نرخ ارز باید دقیقاً مشخص شود.
۷. سقف یا کف تعدیل
در صورت توافق طرفین میتوان آستانهای تعیین کرد که تعدیل تنها پس از عبور تغییرات از آن اعمال شود.
۸. فرآیند درخواست تعدیل
مشخص شود چه کسی، در چه زمانی و با ارائه چه مستنداتی میتواند درخواست تعدیل کند.
یک نمونه بند قراردادی
برای مثال، یک قرارداد نرمافزاری میتواند بهصورت کلی چنین رویکردی داشته باشد:
«با توجه به مدت اجرای قرارداد و احتمال تغییر قابل توجه هزینههای مؤثر بر اجرای خدمات، طرفین توافق نمودند مبلغ بخشهای باقیمانده قرارداد در صورت تحقق شرایط تعدیل، مطابق شاخصها و فرمول مندرج در پیوست مالی قرارداد محاسبه و اصلاح گردد. مبنای محاسبه تعدیل، هزینههای مؤثر بر اجرای خدمات از جمله نیروی انسانی، خدمات و اقلام ارزی و سایر هزینههای مورد توافق طرفین خواهد بود. در صورت افزایش مدت اجرای پروژه به دلایلی خارج از تعهدات و مسئولیت پیمانکار، مدت تمدیدشده نیز حسب مورد مشمول سازوکار تعدیل مقرر در قرارداد خواهد بود.»
البته این متن نمونه عمومی است و برای استفاده در یک قرارداد واقعی باید با توجه به نوع پروژه، ساختار پرداخت، قوانین حاکم، شاخصهای قابل استناد و شرایط کارفرما و پیمانکار تنظیم شود.
تعدیل به معنای انتقال تمام ریسک به کارفرما نیست
این نکته برای فرهنگسازی بسیار مهم است.
یک قرارداد عادلانه نباید تمام ریسک را به کارفرما منتقل کند.
پیمانکار نیز باید بخشی از ریسکهای قابل پیشبینی را در قیمتگذاری خود لحاظ کند.
هدف تعدیل این نیست که:
«هر زمان پیمانکار خواست، قیمت قرارداد افزایش پیدا کند.»
هدف این است که:
ریسکهای غیرعادی و قابل اندازهگیری که پس از انعقاد قرارداد ایجاد میشوند، بر اساس یک قاعده از پیش تعیینشده میان طرفین توزیع شوند.
این تفاوت، مرز میان یک قرارداد حرفهای و یک قرارداد پرریسک است.
چرا نبود تعدیل میتواند کیفیت نرمافزار را تهدید کند؟
نرمافزار برخلاف یک کالای آماده، حاصل کار مستمر انسانهای متخصص است.
اگر قرارداد یک پروژه نرمافزاری برای مدت طولانی بدون تعدیل باقی بماند و هزینه واقعی اجرای آن به شکل محسوسی افزایش پیدا کند، شرکت مجری ناچار است برای حفظ اقتصادی بودن پروژه تصمیم بگیرد.
در چنین شرایطی ممکن است:
- نیروهای باتجربه از پروژه خارج شوند؛
- زمان تست کاهش پیدا کند؛
- مستندسازی ضعیف شود؛
- معماری نرمافزار سادهسازی شود؛
- بدهی فنی افزایش پیدا کند؛
- کیفیت پشتیبانی کاهش پیدا کند؛
- یا شرکت توسعهدهنده عملاً توان ادامه پروژه را از دست بدهد.
بنابراین تعدیل میتواند در نهایت بخشی از مکانیزم تضمین کیفیت و تداوم پروژه باشد.
قرارداد ارزانتر همیشه قرارداد اقتصادیتری نیست
فرض کنید دو شرکت برای اجرای یک پروژه پیشنهاد میدهند:
شرکت A:
۱۰ میلیارد تومان، بدون تعدیل
شرکت B:
۱۱ میلیارد تومان، با مکانیزم تعدیل شفاف
در نگاه اول ممکن است پیشنهاد شرکت A ارزانتر باشد.
اما اگر پروژه ۱۸ ماه طول بکشد و هزینه اجرای پروژه بهشدت افزایش پیدا کند، شرکت A ممکن است در ادامه پروژه با مشکلات مالی مواجه شود.
در مقابل، شرکت B از ابتدا ریسک اقتصادی پروژه را شفاف کرده است.
بنابراین هنگام ارزیابی پیشنهادهای نرمافزاری، بهتر است به جای مقایسه صرف قیمت اولیه، این موارد نیز بررسی شوند:
قیمت + مدل تعدیل + مدت قرارداد + ریسک اقتصادی + کیفیت تیم + ضمانت اجرا + SLA + پشتیبانی
گاهی قرارداد گرانتر، در نهایت ارزانتر تمام میشود.
فرهنگ قراردادهای فناوری اطلاعات باید تغییر کند
پروژه نرمافزاری یک پروژه ایستا نیست.
فناوری تغییر میکند، نیازهای سازمان تغییر میکند، هزینه نیروی انسانی تغییر میکند، سرویسهای خارجی تغییر میکنند و حتی مدت اجرای پروژه ممکن است تحت تأثیر عوامل خارج از کنترل پیمانکار و کارفرما قرار بگیرد.
بنابراین قرارداد نرمافزاری نیز باید به اندازه خود پروژه هوشمند، شفاف و قابل انطباق باشد.
قراردادی که برای یک پروژه ۱۸ماهه در سال ۱۴۰۵ تنظیم میشود، نمیتواند بدون هیچ سازوکاری فرض کند که شرایط اقتصادی روز انعقاد قرارداد تا پایان پروژه ثابت خواهد ماند.
تعدیل، راهی برای افزایش قیمت نیست؛ راهی برای جلوگیری از فروپاشی اقتصادی قرارداد است.
به همین دلیل، پیشنهاد میشود کارفرمایان، مدیران فناوری اطلاعات و شرکتهای نرمافزاری هنگام تنظیم قراردادهای میانمدت و بلندمدت، موضوع تعدیل را از ابتدا در مذاکرات قراردادی مطرح کنند و به جای استفاده از عبارتهای مبهم، یک فرمول شفاف، قابل محاسبه و قابل رسیدگی برای آن تعیین کنند.
نقش شرکت فناوری اطلاعات رادنت در قراردادهای نرمافزاری
در شرکت فناوری اطلاعات رادنت معتقدیم موفقیت یک پروژه نرمافزاری فقط به کیفیت کدنویسی وابسته نیست.
یک پروژه موفق باید از ابتدا از نظر:
- محدوده پروژه
- زمانبندی
- هزینه
- پرداختها
- تغییرات نیازمندی
- پشتیبانی
- SLA
- مالکیت فکری
- امنیت
- محرمانگی
- ضمانت اجرا
- و تعدیل
به شکل شفاف طراحی شود.
هدف از شفافیت قراردادی، پیچیدهتر کردن رابطه کارفرما و پیمانکار نیست؛ برعکس، هرچه قواعد همکاری از ابتدا شفافتر باشند، احتمال اختلاف در طول پروژه کمتر خواهد بود.
در پروژههای نرمافزاری بلندمدت، تعدیل باید بخشی از مدیریت ریسک باشد، نه موضوعی که پس از ایجاد بحران درباره آن مذاکره کنیم.
جمعبندی
تعدیل قراردادهای نرمافزاری یک امتیاز برای پیمانکار نیست؛ یک ابزار مدیریت ریسک برای هر دو طرف قرارداد است.
در شرایط اقتصادی متغیر، قراردادهای چندماهه و چندساله بدون سازوکار تعدیل میتوانند باعث افزایش ریسک مالی، کاهش کیفیت، خروج نیروهای متخصص، تأخیر در پروژه و حتی شکست پروژه شوند.
تجربه سالهای گذشته در صنعت ICT و حتی پیشبینی تعدیل در برخی اسناد تعرفهای خدمات فناوری اطلاعات نشان میدهد که مسئله تغییر هزینه خدمات تخصصی فاوا، مسئلهای واقعی و قابل انکار نیست.
راهکار نیز الزاماً پیچیده نیست:
شاخص مشخص + فرمول مشخص + دوره مشخص + دامنه مشخص + مسئولیت مشخص
وقتی این موارد از روز اول در قرارداد تعیین شوند، تعدیل دیگر یک «درخواست افزایش قیمت» نیست؛ بلکه تبدیل به یک قاعده قراردادی شفاف و قابل پیشبینی میشود.
و شاید مهمترین فرهنگسازی در قراردادهای فناوری اطلاعات همین باشد:
قرارداد خوب قراردادی نیست که فقط قیمت امروز را ثابت کند؛ قراردادی است که برای تغییرات فردا نیز راهحل داشته باشد.
پرسشهای متداول
آیا تعدیل در قرارداد نرمافزاری از نظر قانونی اجباری است؟
خیر، نمیتوان بهصورت کلی گفت تمام قراردادهای نرمافزاری الزام قانونی عمومی به تعدیل دارند. تعدیل باید با توجه به نوع قرارداد، مقررات حاکم و شروط توافقشده میان طرفین بررسی شود. به همین دلیل، درج صریح سازوکار تعدیل در قرارداد اهمیت زیادی دارد.
آیا تعدیل فقط در قراردادهای دولتی کاربرد دارد؟
خیر. هر دو طرف قرارداد خصوصی نیز میتوانند در چارچوب قانون درباره نحوه تعدیل مبلغ یا سایر شرایط قرارداد توافق کنند.
آیا تعدیل همان افزایش قیمت قرارداد است؟
خیر. افزایش قیمت دلخواه با تعدیل قراردادی متفاوت است. تعدیل حرفهای باید بر اساس شاخص و فرمولی باشد که از قبل مورد توافق طرفین قرار گرفته است.
آیا تعدیل شامل کل مبلغ قرارداد میشود؟
لزومی ندارد. میتوان برای بخشهای مختلف قرارداد، وزنهای متفاوتی تعیین کرد؛ برای مثال سهم نیروی انسانی، هزینههای ارزی و سایر هزینهها.
آیا تأخیر کارفرما میتواند باعث تعدیل شود؟
میتواند، اما نحوه اثرگذاری آن باید در قرارداد مشخص شود. بهخصوص در پروژههای نرمافزاری، تأخیر در ارائه اطلاعات، API، محیط تست یا تأیید خروجیها میتواند مدت اجرای پروژه را افزایش دهد.
آیا بهتر است در قرارداد درصد ثابت سالانه تعیین کنیم؟
در بسیاری از پروژهها فرمول شاخصمحور از درصد ثابت منطقیتر است؛ زیرا ساختار هزینه پروژههای مختلف فناوری اطلاعات یکسان نیست.
بهترین زمان تعیین تعدیل چه زمانی است؟
قبل از امضای قرارداد. وقتی بحران اقتصادی ایجاد شده، توافق مجدد بسیار دشوارتر از زمانی است که طرفین در ابتدای قرارداد درباره ریسکهای احتمالی توافق کردهاند.
