IT paslaugų ir SaaS sutartys: kas iš tikrųjų lemia projekto apimtį ir kaštus?
SaaS projektai dažnai prasideda kaip aiškūs ir standartiniai, bet baigiasi ginčais dėl to, kas iš tikrųjų įėjo į kainą.
Programinės įrangos kaip paslaugos (angl. Software as a Service, SaaS) modelis standartiniuose produktuose paprastai apsiriboja prieiga prie sistemos pagal iš anksto nustatytas sąlygas. Tačiau verslo sprendimuose (ERP, CRM ir pan.) ši prieiga derinama su papildomais darbais – diegimu, integracijomis, duomenų migracija ar pritaikymu. Tokiais atvejais sutartis tampa mišri, todėl esminis klausimas yra, kokia darbų apimtis įeina į kainą ir kada atsiranda papildomas apmokėjimas.
Pirmasis aspektas – funkcionalumo pakeitimai. Užsakovo prašymai dažnai įvardijami kaip sistemos pritaikymas, tačiau dalis jų realiai reikalauja programavimo. Sutartyje tikslinga aiškiai nustatyti kriterijų: jei pakeitimas negali būti įgyvendintas naudojant standartinį funkcionalumą, jis laikomas papildomu darbu ir apmokamas pagal iš anksto sutartus įkainius arba atskirą pasiūlymą. Priešingu atveju tokie darbai atliekami be aiškaus apmokėjimo pagrindo arba tampa ginčo dėl papildomų sąskaitų objektu.
Antrasis aspektas – integracijų apimtis. Formuluotė „integracija su X sistema“ savaime neapibrėžia darbų apimties. Sutartyje tikslinga įtvirtinti konkrečias technines prielaidas, kuriomis remiantis integracija vertinama (pvz., veikiančios programavimo sąsajos (API), dokumentacija, duomenų struktūra). Taip pat svarbu numatyti, kad šių prielaidų neatitikimas reiškia papildomus darbus, kurie užsakomi ir apmokami atskirai. Tai leidžia iš anksto aiškiai susieti darbų apimtį su kaina.
Trečiasis aspektas – užsakovo IT aplinka. Diegimo metu gali paaiškėti, kad esamos sistemos neatitinka techninių ar saugumo reikalavimų. Tokie darbai nėra SaaS paslaugos dalis, todėl sutartyje tikslinga aiškiai nustatyti, kad užsakovas atsako už savo infrastruktūros atitiktį, o jos pritaikymas ar trūkumų šalinimas laikomas papildomais darbais.
Ketvirtasis aspektas – naudotojų apmokymai. Pareiga apmokyti naudotojus turėtų būti apibrėžta kiekybiškai: nustatant mokymų valandų ar sesijų skaičių, dalyvių apimtį ir formatą. Taip pat būtina įtvirtinti, kad papildomi mokymai teikiami tik pagal atskirą užsakymą ir apmokami pagal sutartus įkainius. Priešingu atveju mokymai gali virsti papildomu darbo krūviu, kuris nebuvo įtrauktas į kainą.
Esminė šių sutarčių logika – iš anksto susitarti ne dėl abstrakčių pareigų, o dėl aiškių ribų: kokie darbai laikomi įtrauktais į paslaugą, kokiais kriterijais nustatoma papildomų darbų apimtis ir kokia tvarka jie užsakomi bei apmokami. Būtent šios ribos lemia, ar projektas išliks kontroliuojamas tiek apimties, tiek kaštų prasme.
Šių klausimų sureguliavimas negali būti grindžiamas vien universaliomis sąlygomis ar tipinėmis formomis – kiekvienas projektas turi savo rizikos profilį.
Jeigu dirbate su SaaS sprendimais ar planuojate jų diegimą – verta šiuos aspektus įsivertinti dar prieš pasirašant sutartį.
📩 info@prevence.legal 📞 +370 664 42822
