Onderhoudscontract voor software

Leg drie beheervoorstellen naast elkaar en u leest drie varianten op dezelfde zin: de leverancier verhelpt storingen, houdt de software actueel en is bereikbaar voor vragen. Dat klinkt als een belofte, maar het beschrijft een bezigheid. Binnen welke termijn, in welke uren, en wat er gebeurt als het niet lukt, staat er niet bij.

Het verschil tussen een loze en een bindende formulering is toetsbaarheid: kan een buitenstaander achteraf vaststellen of de afspraak is nagekomen? Daarvoor is een startmoment nodig, een termijn, en een gevolg als die verloopt. Zonder dat laatste heeft u een norm zonder consequentie.

Dit is de belangrijkste scheidslijn in de overeenkomst en tegelijk de vaagste. Een externe dienst wijzigt zijn koppeling en uw software moet mee. Een veld blijkt te kort voor wat klanten erin typen. Een overzicht wordt traag naarmate het aantal regels groeit. Steeds noemt de leverancier het een wijziging, en zegt u dat het gewoon hoorde te werken.

Beide standpunten zijn verdedigbaar, en dat is het probleem. Onderhoud is alleen te bepalen ten opzichte van een ijkpunt: de versie die is opgeleverd en geaccepteerd, met de beschrijving die daarbij hoorde. Zonder dat ijkpunt valt de discussie terug op wat men zich van de bouw herinnert, en dat wint zelden de partij die niet zelf bouwt. Leg dus vast welke versie en welke documenten het ijkpunt vormen, en zorg dat duidelijk is wat er precies in beheer is genomen.

Werk de categorieën uit met voorbeelden in plaats van definities; drie voorbeelden aan elke kant zeggen meer dan een omschrijving. Spreek daarnaast af dat een probleem eerst wordt opgelost en de vraag wie het betaalt daarna wordt beslecht. Anders ligt uw proces stil zolang twee partijen het oneens zijn over een factuur.

Een reactietijd is de termijn waarbinnen iemand inhoudelijk op uw melding reageert. Een hersteltijd is de termijn waarbinnen het probleem weg is. Contracten beloven bijna altijd het eerste en suggereren het tweede.

Dat een leverancier geen hersteltijd garandeert, valt te billijken: niemand weet vooraf hoe lang een onbekende fout kost, en de oorzaak kan bij een derde partij liggen. U kunt dan nog steeds afspreken dat er onafgebroken aan gewerkt wordt, dat u met een vaste frequentie bericht krijgt, dat er na een genoemde periode wordt opgeschaald naar een bij naam genoemde rol, en dat een tijdelijke omweg een geldige tussenstap is.

Leg dan wel vast wat opgelost betekent. Sluit een omweg de melding af, dan is het probleem administratief verdwenen en praktisch niet. Spreek af dat de klok bij een omweg pauzeert in plaats van stopt, en regel wanneer hij stilstaat omdat de leverancier op uw antwoord wacht.

Prioriteiten staan meestal technisch omschreven: kritiek, hoog, midden, laag, met een toelichting die alleen betekenis heeft voor wie de software van binnen kent. Wie een melding indeelt, staat er zelden bij. In de praktijk doet de leverancier dat, en dat is de partij die er zelf het werk aan heeft.

Beschrijf urgentie daarom in termen van wat er stilligt. Klanten kunnen niet afrekenen. Facturen kunnen de deur niet uit. Medewerkers komen er niet in. Zulke zinnen hoeft niemand te interpreteren, en ze vangen ook de kleine fout met grote gevolgen.

Neem het moment mee: dezelfde storing in de facturatie is halverwege de maand vervelend en op de laatste werkdag een ramp. Leg tot slot vast dat de melder de eerste indeling maakt, dat de leverancier die gemotiveerd kan aanvechten, en dat de behandeling ondertussen doorloopt.

Een beschikbaarheidspercentage zegt weinig zolang er niet bij staat over welke periode het geldt, wie het meet en wat als onbeschikbaar telt. Per jaar gerekend blijft één lange storing ongemerkt binnen de norm, per maand gerekend valt diezelfde storing meteen op. En meet de leverancier of de applicatie bereikbaar is, of ook of de betaalfunctie het doet?

Gepland onderhoud valt vrijwel altijd buiten de meting, en dat is redelijk, want updates moeten ergens gebeuren. Het wordt onredelijk zodra het venster onbegrensd is. Spreek af binnen welke uren die vensters vallen, hoe lang van tevoren u ze hoort, hoe vaak ze mogen terugkeren, en dat u ze in uw drukste periode kunt laten verschuiven.

Reken het percentage om: een half procent van een maand van dertig dagen is ongeveer drieënhalf uur uitval.

De afspraken over vertrek leest u pas als de verhouding op zijn slechtst is. Juist daarom regelt u ze aan het begin.

Toegang: de omgevingen, de repository, het domein en de accounts bij externe diensten staan op naam van uw eigen organisatie, vanaf de start en niet pas bij vertrek. Verwar dat niet met rechten op de software zelf, want wat u van de broncode mag verwachten is een aparte afspraak.

Gegevens: teruggave in een bruikbaar formaat is iets anders dan de zin dat gegevens ter beschikking worden gesteld. Bruikbaar is een formaat dat een andere partij kan inlezen, compleet inclusief bijlagen, met een beschrijving van de structuur en binnen een genoemde termijn. Medewerking: benoem de handelingen, zoals een dossier overdragen en meekijken bij de eerste wijzigingen van de partij die het overneemt.

Let ook op opschortingsbepalingen. Veel contracten laten de leverancier de dienstverlening stilleggen bij een betalingsachterstand; zorg dat dat nooit uw toegang tot uw eigen gegevens en omgevingen raakt.

Stilzwijgende verlenging en een jaarlijkse prijsaanpassing zijn in beheercontracten gebruikelijk; het heeft meer zin ze te kennen dan ze te bestrijden. Kijk naar de verhouding tussen verlengingstermijn en opzegtermijn, want bij verlenging met een jaar kost één gemiste datum u een volledig jaar.

Kijk daarnaast waaraan de verhoging gekoppeld is. Een gepubliceerd indexcijfer kunt u narekenen; een aanpassing naar redelijkheid of conform het dan geldende tarief is in feite een eenzijdig prijsrecht. De wettelijke bescherming tegen stilzwijgende verlenging is er voor consumenten, zakelijk geldt wat u zelf afspreekt.

Vrijwel elke beheerovereenkomst is opgesteld door de leverancier, en die heeft geen prikkel om scherp op te schrijven wat eronder valt: elke grens die vaag blijft, kan later als meerwerk worden uitgelegd. Appfront is zelf zo'n partij, dus dit is geen verwijt aan anderen.

Kwade wil is het meestal niet. Vaagheid geeft een leverancier ook de ruimte om iets een keer op te lossen zonder factuur. Alleen ligt die ruimte bij hem en het risico bij u, en die verhouding schuift zodra het druk wordt. Om verscherping vragen is dus aan u, en hoe een leverancier daarop reageert zegt meer dan de tekst die u tekent.

Dit is algemene uitleg over hoe deze afspraken werken, geen juridisch advies. Laat uw eigen overeenkomst voor ondertekening beoordelen door een jurist, zeker als er veel van afhangt.

• Software in beheer nemen
• Eigendom en overdracht van broncode
• Van softwarebureau wisselen