Niets is wat het lijkt: let op de kleine lettertjes

terms of contract
Standaard

De laatste tijd zitten we mede dankzij onze partners steeds vaker in de aan tafel bij uitvragen. Met elkaar wil je als team de beste presentatie bezorgen van de technische oplossing die je de klant kan bieden op zijn uitvraag. Echter een technische oplossing komt niet zonder contract. Waar bij veel mensen aan de onderhandelingstafel de focus ligt op de oplossing en is de technische kant ook iets wat ze uitbesteden, blijft het contract iets voor na de keuze van de oplossing. Maar wat er uiteindelijk in dat contract komt, is ook van invloed op de toepasbaarheid van de oplossing.

Waar de klant vaak prima kennis heeft van zijn eigen markt/business, is de kennis van de techniek en ook het contract in technische taal minder aanwezig. Tijdens de presentatie van de oplossing worden dan termen als “open datamodel”, “volledige toegang tot eigen data” en “uitwisselbaarโ€ gebruikt om de klant te verleiden om voor hun oplossing te kiezen. Meestal wordt hiermee bedoeld dat er altijd toegang is tot de data, iets wat je eigenlijk normaal mag verwachten. En meestal is het ook wel erg verleidelijk om met iemand in zee te gaan die alles klaar op de plank heeft liggen: het geeft snelheid aan de implementatie van de oplossing. Maar op welke punten moet je dan extra gaan letten als ze deze voordelen uitdrukkelijk benoemen?

Een open-formaat klinkt gewelding, echter aan een open formaat alleen heb je niet voldoende. Het formaat van Office-bestanden is ook helemaal openbaar, echter geen enkel ander programma laat de inhoud zien zoals Office zelf. Er komt meer bij kijken dan het kunnen inlezen van de data alleen. Het programma moet ook weten wat er uiteindelijk in staat en wat het ermee moet doen. Een Word-document openen met Excel geeft ook een heel ander beeld van de data dan verwacht.

Relevant is dan dus de vraag wat er echt verkregen wordt. In hoeverre is er vrijheid om met de eigen Relatics-workspace te blijven werken? Of moet er met de workspace van de leverancier gewerkt worden omdat anders de werking van de oplossing niet gegarandeerd wordt? En wat te spreken over de ontwikkelingen die worden doorgevoerd, wie is er eigenaar van het idee, ontwerp en uitwerking? Dit soort afkaderingen staan meestal in juridische taal in het contract, maar worden niet meegenomen in de presentatie van de oplossing.

Voor de korte termijn zijn deze voorwaarden vaak geen probleem, voor de lange termijn-visie gaat hem hier juist wel de schoen wringen. Want wisselen van leverancier is dan niet tot nauwelijks mogelijk zonder ook grote wijzigingen aan de software. Maar ook onderhoud door een eigen interne afdeling is hiermee uitgesloten. Voor elke aanpassing zal altijd naar de leverancier gebeld moeten worden. Dit geldt niet enkel voor oplossingen in Relatics, maar voor elke willekeurige SAAS-oplossing.

Dus op zoek naar een nieuwe technologische SAAS-oplossing zoals bijvoorbeeld Relatics, vergeet dan niet even naar de kleine lettertjes uit het contract te vragen.