Wie gaat onze interfaces bouwen?

Periodiek worden wij door klanten benaderd met een korte vraag over een interface die wordt ontwikkeld door een externe partij. Veelal gaat het dan om leveranciers van systemen die met Unit4 Financials (CODA) moeten integreren. Het lijkt allemaal zo simpel. De leverancier van een inkoopsysteem weet echt wel hoe webservices werken en kan zonder problemen de interfacing voor haar rekening nemen. Alles is klaar voor de test en dan komen de problemen. 

Iedere test gaat mis en met ieder probleem wordt een vraag bij ons neergelegd, waarom het niet werkt of wat er moet worden ingevuld. Dit leidt tot enorme vertraging in het testproces, de deadline komt snel dichterbij en de frustratie bij de klant neemt dagelijks toe. Er is ook weinig zo frustrerend voor een normale medewerker (niet zijnde een testprofessional) om iets te moeten testen dat bij iedere stap weer een foutmelding geeft.

Veel van deze problemen worden veroorzaakt door twee simpel te voorkomen oorzaken:
  • Onbekendheid met de syntax die door de webservices wordt vereist;
  • Onbekendheid met wat het ontvangende systeem aan valide data accepteert.

De eerste oorzaak heeft eenvoudig te maken met kennis en ervaring van het gebruik van de specifieke webservices van Unit4 Financials. Als je deze nog nooit hebt gebruikt, helpt een technische specificatie niet om uit de 500 mogelijke "tags" precies die 14 te kiezen die voor de specifieke situatie van belang zijn.

De tweede oorzaak heeft vaak te maken met het niet goed vooraf specificeren van wat de interface moet doen. De gebruikers zijn in hun ogen duidelijk: "De goedgekeurde facturen moeten in Unit4 Financials worden geboekt." De ontwikkelaar weet echter niet met welke codes, datum, verwijzigingen en bedragen dit moet gebeuren. Natuurlijk is hij/zij op de hoogte van wat een normale factuurboeking is, maar hoe dit gecodeerd moet worden in dit financiële systeem is geen standaardkennis. De medewerker die wel van het financiële systeem op de hoogte is, gaat vaak uit van veronderstelde kennis bij de ontwikkelaar en benoemt daarom maar weinig van de noodzakelijke data en informatie. Daarbij komt dat de financiële medewerker niet dezelfde taal spreekt als de ontwikkelaar van de interface. Dit laatste kan komen doordat beiden begrippen hanteren (bijvoorbeeld "boekdatum") die in het aanleverend systeem een ander betekenis kunnen hebben dan in het ontvangende systeem.
 

Klanten die met deze problematiek te maken krijgen, adviseren wij dan ook om in een vroeg stadium al een functioneel-technisch consultant in te schakelen. Deze heeft zowel kennis van de technische vereisten en werking van de Unit4 Financials services, alsmede functionele kennis waarmee deze de verbinding kan vormen tussen de ontwikkelaar van de externe leverancier en de financiële medewerker van de klant. Solmate consultants zijn gewend de juiste vragen te stellen om alle relevante informatie boven tafel te krijgen, waardoor het opstellen van een functionele specificatie een eenvoudige stap wordt in het proces om te komen tot een goed werkende interface.


Mocht u binnenkort nieuwe interfaces met Unit4 Financials willen gaan (laten) ontwikkelen, neem dan eens contact op met Solmate.

Contact