Xml-codes vergemakkelijken het werk van hypothecair dienstverlener Stater. De medewerkers hoeven niet langer veranderingen van hypotheekgegevens door te voeren in 3500 verschillende documenten. Door vorm en inhoud te scheiden, is het aantal standaard documenten teruggebracht tot 150 en zijn per hypotheekvorm of -aanbieder eenvoudig de kenmerken te bepalen.
Bedrijven gaan niet goed met informatie om. Financiële cijfers en de klantgegevens zitten waarschijnlijk overal in een database, maar welk bedrijf heeft inzicht in alle correspondentie, verslagen, rapporten en dergelijke?
Volgens Mariëlle Jonkers zit 60 procent van de informatie in bedrijfsnetwerken in ‘losse’ bestanden. Ze is commercieel directeur bij Salience, een bedrijf dat onder meer Shell, ING, De Nederlandse Bank en de Open Universiteit adviseerde en begeleidde bij het ontsluiten van deze losse gegevens. Tien jaar geleden was het wondermiddel sgml (standard generalized markup language). Sinds een jaar of vijf is xml (extensible markup language) hoofdbestanddeel van het elixer.
Innovatieve technicus
Jonkers stelt dat ze bedrijven helpt de kosten en baten van documentbeheer in kaart te brengen. De meeste bedrijven struikelden volgens haar in het verleden bij de aanleg van een documentbeheersysteem omdat het voorstel werd ingediend door een technicus. De directie begreep de uitleg niet. Het project verzandde, de technicus vertrok en het werd wachten tot de volgende innovatieve technicus de strijd weer opnam.
Tegenwoordig worden deze projecten juist geïnitieerd door de directie, zegt Jonkers. Het is bijvoorbeeld directies van banken en verzekeraars pijnlijk duidelijk dat met een behoorlijk contentbeheersysteem flink valt te verdienen. Jonkers: "Ze willen nu allemaal zo snel mogelijk alle gegevens inzichtelijk maken en zo hun backoffice ontsluiten."
Xml scheidt inhoud en vorm. Bij Stater, dat gegevens behandelt van hypotheekaanbieders als ABP, Delta Loyd, Zwitserleven, Ohra, Zurich en Bouwfonds, maakt die scheiding het mogelijk 3500 verschillende brieven te genereren op basis van slechts 150 stijl- en inhoudselementen.
"Ongeveer éénderde van alle Nederlandse hypotheken gaat door ons systeem", zeg Matthew van der Woerdt, een van de ongeveer honderd ict’ers van Stater in Leusden. Bijna twee jaar lang heeft hij met enkele collega’s de Sybase-database en de andere onderdelen van het systeem bewerkt met programma’s in Uniface, C-, Java- en Delphi-code, en brieven geconverteerd.
Het systeem levert de hypotheekgegevens aan de xml-machine, de Stater Document Engine (SDE). De xml-code bepaalt wat vervolgens gebeurt. In welke taal moet het document worden aangemaakt? Welke tekstblokken moeten erin? Ook wordt hier de koppeling gelegd met de huisstijlkenmerken van de hypotheekaanbieder. Hoe groot is de linkermarge, welk lettertype wordt gebruikt, waar staat de handtekening? Vervolgens wordt het document aangemaakt en gevalideerd.
Van der Woerdts werk is bijna af. Wil een hypotheekaanbieder de huisstijl veranderen? In plaats van het aanpassen van alle verschillende documenten (offerte, aanbiedingsbrief, contract, en correspondentie met tussenpersoon, bank en notaris) hoeft Stater alleen de xml-code voor de huisstijl bij te werken. Drukorders stuurt de SDE meteen naar een drukker. Wil een tussenpersoon de informatie ook als pdf (portable document format) per e-mail? Stater past de xml-code voor distributie aan en de mail kan weg.
De werkelijkheid is weerbarstiger, weet Wim van der Schoor, technisch directeur bij Salience. In 1999 werd hij benaderd door Stater. "Ik dacht, wat bedoelt die man, een soort mailmerge-functie?" In twee weken schreven programmeurs van Salience een xml-koppeling tussen het hypotheeksysteem en wat voorbeeldteksten. Het prototype overtuigde het bedrijf, maar aan het maken van de echte xml-machine gingen twee maanden van studie van de databankgegevens en de verschillende hypotheekdocumenten vooraf. Het bouwen ervan kostte vier maanden. Het volgende halfjaar werden documenten omgezet die waren gemaakt op verschillende tekstverwerkers.
Van der Woerdt herinnert zich de strijd met de documenten maar al te goed. "Er werd hier gewerkt met WP- en Word-documenten, de gecreëerd werden met zeer veel macro’s." Nog steeds zijn er struikelblokken. "Onze grootste nachtmerrie is dat een document dat wij opsturen niet aankomt, of niet afgedrukt kan worden. Je vertelt een hypotheekmakelaar dat hij een post-script printer moet aanschaffen. Zo’n man zegt weliswaar ja, maar weet niet waar je het over hebt. Dan moet je even langs om te helpen."