De data achter “data driven”
Software kan haar gedrag laten bepalen door gegevens. Een betalingstermijn, kortingsgrens of vragenlijst staat dan in configuratie en wordt door de applicatie gelezen en toegepast. Door die configuratie te wijzigen, kunt u het gedrag aanpassen zonder de programmacode te veranderen.
Deze vorm van datagedreven werken maakt software flexibel. Tegelijkertijd vraagt zij om zorgvuldig beheer van de gegevens die het gedrag bepalen. Een configuratiefout kan doorwerken in iedere bestelling, factuur of beoordeling waarop de instelling van toepassing is.
Bedrijfsafspraken vastleggen als data
Veel bedrijfsafspraken lenen zich voor configuratie. Denk aan:
| Instelling | Voorbeeld | Toepassing |
|---|---|---|
| Standaard betalingstermijn | 30 dagen | Berekenen van de vervaldatum van een nieuwe factuur |
| Geldigheidsduur van een offerte | 14 dagen | Bepalen tot wanneer een aanbod geldig is |
| Minimumbedrag voor gratis verzending | € 50,00 | Berekenen of verzendkosten in rekening worden gebracht |
| Maximale korting zonder goedkeuring | 10 procent | Bepalen of aanvullende toestemming nodig is |
Ook binnen de Quickscan van datamanagers.nl wordt dit principe toegepast. Welke kerndomeinen bij een scope horen en hoeveel vragen per domein worden toegewezen, ligt vast in de database. De software leest deze inrichting en handelt ernaar.
De programmacode moet de ingestelde mogelijkheden wel ondersteunen. Een bestaande kortingsgrens wijzigen kan via configuratie; een geheel nieuwe kortingsregeling kan alsnog een aanpassing van de software vereisen.
Eén plaats voor onderhoud
Een bedrijfsafspraak die op verschillende plaatsen wordt vastgelegd, kan uiteen gaan lopen. De webshop rekent bijvoorbeeld met een grens van € 50,00 voor gratis verzending, terwijl het ordersysteem nog € 40,00 gebruikt.
Het Single Point of Maintenance-principe helpt dit te voorkomen: beheer een regel op één aangewezen plaats en laat de toepassingen die regel consequent gebruiken.
Dat betekent niet dat iedere instelling één algemene waarde moet hebben. Betalingstermijnen kunnen bijvoorbeeld verschillen per klant of contract. Ook die verschillen moeten centraal en eenduidig worden beheerd, inclusief de afspraak welke waarde voorrang heeft.
Een waarde heeft een definitie nodig
De waarde 50 zegt op zichzelf weinig. Gaat het om euro’s, dagen of procenten? Geldt het bedrag inclusief of exclusief btw? Wordt het orderbedrag vóór of na korting gebruikt?
Voor een instelling als minimumbedrag voor gratis verzending moet duidelijk zijn:
- welke eenheid en valuta worden gebruikt;
- welke berekening aan de vergelijking voorafgaat;
- voor welke bestellingen de regel geldt;
- of verzending bij precies het grensbedrag gratis is;
- vanaf wanneer de waarde van toepassing is.
De naam van een instelling helpt de lezer, maar vervangt haar definitie niet.
Een geldige waarde kan toch verkeerd zijn
Stel dat de grens voor gratis verzending moet veranderen van € 40,00 naar € 50,00. Iemand voert per ongeluk € 0,50 in.
Dat bedrag is technisch geldig: het is een getal, heeft twee decimalen en is niet negatief. Toch wijkt het sterk af van de bedoelde bedrijfsafspraak.
Validatie moet daarom verder gaan dan het controleren van het gegevenstype. Afhankelijk van de instelling kunnen toegestane grenzen, een waarschuwing bij een wijziging met grote impact of een tweede goedkeurder nodig zijn.
Hetzelfde geldt voor ontbrekende waarden. Leg vast hoe de applicatie daarop reageert. Mag zij een standaardwaarde gebruiken, of moet de verwerking stoppen? Een ongemerkte terugval op een standaardwaarde kan een configuratiefout verbergen.
Een wijziging heeft een ingangsdatum
Als de standaard betalingstermijn verandert van 30 naar 14 dagen, moeten bestaande facturen hun afgesproken vervaldatum behouden. De nieuwe standaard geldt voor de gevallen waarop de gewijzigde afspraak van toepassing is.
Maak daarom onderscheid tussen de configuratie die bij verwerking wordt geraadpleegd en de afspraak die voor een individuele factuur, offerte of bestelling is vastgesteld.
Voor controle achteraf kan het nodig zijn om de toegepaste waarde of de gebruikte configuratieversie bij het resultaat vast te leggen. Alleen de huidige instellingen bewaren is onvoldoende om te verklaren hoe een ouder resultaat tot stand is gekomen.
Wie mag het systeemgedrag veranderen
Een configuratiewijziging kan gevolgen hebben die vergelijkbaar zijn met een wijziging in de programmacode. De toegang tot configuratie verdient daarom dezelfde aandacht als andere bedrijfskritische wijzigingen.
Bepaal wie verantwoordelijk is voor de inhoud van een instelling, wie wijzigingen mag uitvoeren en wanneer goedkeuring nodig is. Houd een wijzigingshistorie bij met de oude en nieuwe waarde, de uitvoerder, het tijdstip en de reden.
Controleer bovendien hoe een wijziging actief wordt. Als toepassingen instellingen tijdelijk (in het geheugen) bewaren, kan een centraal aangepaste waarde pas later overal worden gebruikt. Ook dat gedrag moet bekend en beheerst zijn.
Configuratie hoort bij datamanagement
Configuratie bevat afspraken die de software uitvoert. Heldere definities, validatie, toegangsbeheer en een bruikbare wijzigingshistorie maken die afspraken controleerbaar.
De centrale vraag is daarom: kunt u voor een resultaat uitleggen welke instellingen zijn gebruikt, waarom die instellingen golden en wie ze heeft vastgesteld?
Wie dat kan beantwoorden, beheert ook de data achter het datagedreven systeem.