Het gegeven dat de vakgebieden ICT, finance en bedrijfskunde overlappen vormt vaak de oorzaak dat financiële koppelingen vaak zo slecht begrepen worden. De combinatie van kennis over bedrijfskunde en ICT is vrij zeldzaam en gebrek aan deze kennis voedt problemen bij de inrichting van koppelingen. Het inzicht dat vaak ontbreekt is dat als je systemen koppelt aan een boekhouding je gedwongen bent de systemen ook te laten voldoen aan de regels van dubbelzijdig boekhouden. Verder dat gekoppelde systemen zich gaan gedragen volgens de regels van de verzamelingenleer. 

Ik hoop dan ook dat lezers uit genoemde vakgebieden over en weer  volharden in het lezen van materie die niet specifiek tot hun vakgebied behoort, om iets zinvols bij bij te dragen aan het inzicht rondom deze materie.

Dit stuk bestaat uit twee gedeelten:

– Een financieel / strategisch gedeelte dat over de organisatorische achtergrond en keuzes bij deze problematiek gaat.
– Het tweede deel, dat over informatieanalyse en verzamelingenleer gaat.

Er is veel veranderd sinds de jaren 60, maar toch ook niet zo veel. Er wordt naar mijn mening ook onvoorstelbaar veel meer ge-amateurd in de ICT wereld dan vroeger en dat komt omdat technici de theoretische achtergrond niet kennen en het overzicht missen. De kosten van deze overhead van techniek worden meer “aangenomen” en minder toegerekend aan het productieproces, omdat de directe relatie tussen bedrijfsvoering en ICT verder weg is komen te staan en systemen complexer zijn geworden. Daarnaast wordt technische kennis in de de dagelijkse praktijk nog steeds op een hoger voetstuk gezet, dan bijvoorbeeld bedrijfskundige kennis. Als we het niet begrijpen stoppen we het in het hokje techniek. We snappen inmiddels wel dat techniek volgend moet zijn en een middel, niet een doel, maar als we in de praktijk systemen  inrichten of gaan koppelen, of beide, gaat het toch weer voornamelijk  over techniek. Techniek is onbegrijpelijk, maar als je dat nu maar uitbesteedt, dan komt het allemaal wel goed(!) Onzin natuurlijk en dat heeft rechtstreeks consequenties voor de kans op mislukking van een project. 

Wat in de praktijk daarom nogal eens voorkomt is dat een project “technisch” wordt ingevoerd en dat  “over de rug van de medewerkers van het bedrijf”  blijkt dat er niet met de systemen te werken valt, omdat de inrichting de manier van werken van de organisatie niet volgt en er allerlei aannames zijn gedaan die niet kloppen. Bovendien is vaak niet of onvoldoende afgewogen of de kosten wel opwegen tegen de baten. Verborgen extra werk voor het permanent onderhouden van de gegevens in het nieuwe systeem zijn in de praktijk vaker wel dan niet aan de orde.

Laat ik duidelijk zijn: sinds de jaren 60 en maar ook ver daarvoor is bij het creëren van toegevoegde waarde (iets dat bedrijven doen), niet zoveel veranderd. Het basismodel is nog altijd IPO (Input Proces Output). Er komt iets binnen, er wordt iets mee gedaan en na bewerking gaat er iets uit. Daar is niets moeilijks aan.

Om te kunnen meten of het IPO proces efficiënt werkt staat aan de basis van veel bedrijven een financieel systeem. Dit systeem fungeert als een spin in het web en is meestal gekoppeld met een aantal productiesystemen.

Wel: dan volgen we het IPO regiem en richten onze systemen in volgens deze werkwijze en dat doen we ook bij de gekoppelde systemen; eenvoudig toch, een kind kan de was doen?
Helaas werken de meeste bedrijfsprocessen verre van lineair. Waarde wordt cyclisch toegevoegd binnen een bedrijf en dat geschiedt vaak op hele andere momenten dan IPO doet vermoeden. Dat betekent ook dat er gegevens worden gewijzigd in het “onderste systeem”, terwijl het bovenliggende systeem al eerder gegevens van het onderste systeem heeft ontvangen. Hier begint veel van de ellende met gekoppelde systemen.

Als we strikt volgens IPO zouden werken, kunnen we gegevens van de I => doorsturen naar de => P en weer doorsturen naar de => O. Dit gebeurd in praktijk echter nooit. We voegen dus gelijktijdig waarde toe in I,P en als tegenzit zelfs in O.

Als we praten over financiële koppelingen hebben we in praktische zin eigenlijk twee keuzes:

1) we houden onze eigen productie systemen en koppelen die aan de financiële administratie of

2) we doen een ingewikkelde en kostbare ERP implementatie, waarbij alle software wordt vervangen door de modules van het ERP pakket.

Het ERP pakket dwingt ons natuurlijk wel een bepaalde standaard werkwijze voor de productie modules en de financiële module op. Bovendien gaat het vervangen van de productiesystemen vaak niet zonder verlies van functionaliteit, omdat er vele jaren investeringen in deze systemen is opgenomen en de functionaliteit logistiek gezien (binnen redelijke tijd) niet zomaar te vervangen is.
Het is daarnaast de vraag of het verstandig is om het bedrijf te uniformeren, immers de concurrenten doen ook ERP implementaties en waar blijft dan het onderscheidend vermogen van het bedrijf? Natuurlijk heeft ERP ook voordelen, zo is het door de integratie van alle modules beter mogelijk om niet lineair te werken. Een veel gemaakte fout met ERP implementaties, die niet zozeer letterlijk aan het ERP systeem te wijten is, is alles in één keer vervangen (financiële modules en productie modules). Dat is vergelijkbaar met het optillen van de wereld door Atlas, hetgeen ook niet lukte. Soms kan dit niet anders omdat bepaalde modules niet later ingevoerd kunnen worden en de administratie per 1 januari van het nieuwe jaar moet worden ingevoerd. Een zeer gevaarlijk “one-way street”, waabij er vele praktijkvoorbeelden zijn van bedrijven die bijna failliet gingen, omdat de implementatie niet lukte. Er zitten dus heel wat haken en ogen aan een ERP implementatie. Die haken en ogen zijn er natuurlijk ook voor het koppelen van de productiesystemen. Hieronder wordt getracht wat basisregels te formuleren om deze problemen deels te ondervangen.

Naast het behoud van de eigen bedrijfsidentiteit zijn er nog meer voordelen ten aanzien van het koppelen van productiesystemen t.o.v. een ERP implementatie. Het houdt het bedrijf onafhankelijk (geen Lock inn bij ERP leverancier) en de productiesystemen zijn desgewenst modulair te vervangen. Het bedrijf kan derhalve flexibeler en investering technisch ook met kleinere investeringen modulair wijzigingen blijven doorvoeren, die beter passen in de productieomgeving. Dat is natuurlijk wel weer afhankelijk van zaken zoals de juiste vakmensen, voldoende betrokkenheid, het juist platform, niet teveel verouderde systemen, kortom een gezonde ICT strategie.

Nu is er iets raars aan de hand met productie systemen voor data. Veruit de meeste ICT systemen werken als kaartenbak (!) Ik noem dat ook welenkelvoudige waarheid systemen. Vroeger als je een kaartenbak op papier bijhield, was het lastig iets te veranderen zonder dat dit zichtbaar was. Tippex was te zien, wegkrabben van geschreven tekst werkte ook maar beperkt. In ICT land ligt dit echter heel anders. Met hetzelfde gemak wijzigen we een waarde van vandaag 50 naar morgen 40 en geen haan die er naar kraait. We hebben natuurlijk database logging, maar daar kijkt over het algemeen niemand naar. De database weet misschien nog iets, maar het is niet geïntegreerd in het systeem. Bovendien: wie bepaalt de waarheid, de gebruiker toch? Dus als 50 40 moet zijn, veranderen we 50 in 40 en dan is dat geregeld. We hebben de waarheid aangepast, zonder dat dit ergens verbonden is met de echte toegevoegde waarde in het bedrijf !  Daar we organisatorisch niet kunnen vasthouden aan lineaire IPO, stellen de meeste “enkelvoudige waarheid systemen” ons in staat om initiële gegevens later te wijzigen in wat we maar willen.

Lekker flexibel, maar dat is natuurlijk niet handig als we de echte toegevoegde waarde willen meten, want hoe kunnen we zonder betrouwbare waarderingsgrondslag meten of we toegevoegde waarde creëren?

In de 13e eeuw is hiervoor een geniale oplossing bedachten door Luca Pacioli die voor de Medici’s een systeem ontwikkelde dat nu dubbelzijdig boekhouden wordt genoemd.

Bij enkelvoudige waarheid systemen is het mogelijk om de data te wijzigingen, of data te verwijderen, zonder dat duidelijk is hoe dit is gedaan. De waarheid kan worden aangepast zonder dat dit consequenties heeft.
Bij permanence systemen of dubbelzijdige boekhoudingen (debet = credit) bestaan deze mogelijkheden niet. De enige manier waarop de waarheid kan worden aangepast is door data toe te voegen (Belangrijk verschil!!!!)

–  Data toevoegen dus om de blik op de waarheid te veranderen, te wijzigen, of iets te verwijderen

Er is geen beter of slechter systeem, beiden hebben voordelen en nadelen. Essentieel is echter dat beide systemen niet doorelkaar te gebruiken zijn.

Luca Pacioli (1447-1517)

Hieronder een plaatje om het verschil inzichtelijk te maken. Dit betreft een vereenvoudigde weergave. De werkelijkheid is veel complexer.

Zoals gezegd kunnen de systemen niet door elkaar gebruikt worden, want dan ontstaan brokken.  Zo gebeurt het regelmatig dat de koppeling alleen de initieel aangemaakte gegevens doorgeeft en niet de wijzigingen nadien. Het komt ook nogal eens voor dat men niet inziet hoeveel werk er zit in het ombouwen van een enkelvoudig waarheid systeem naar een dubbelzijdig boekhoudsysteem. Degenen die de koppeling bouwen richting het financieel systeem hebben de kennis en het overzicht niet en dan zijn de poppen vaak serieus aan het dansen. In het bovenstaande voorbeeld is in de enkelvoudige waarheid (links)  50 veranderd in 40. Wat zou een koppeling nu moeten doorgeven aan de financiële boekhouding? Uiteraard een wijziging van -10. Dit is overigens in de wereld van de boekhouding niet zo vanzelfsprekend. Immers we kunnen ook eerst 50 weghalen en daarna 40 opvoeren. De koppeling geeft dan -50 en 40 door. Dit geeft extra informatie over de vervangen waarde en de nieuwe waarde, maar in essentie blijft het systeem hetzelfde. We voegen data toe om waardes te verwijderen en we overschrijven nooit iets. 

In de meeste enkelvoudige waarheid systemen zijn echter geen voorzieningen opgenomen die wijzigingen bijhouden. Immers: de waarheid is de waarheid en of we er 50 of 40 neerzetten maakt voor het systeem niets uit. Het is de verantwoordelijkheid van de gebruiker, om de juiste getallen bij te houden. Bovendien is de wijziging van de waarheid alleen zichtbaar op het moment van wijziging. Het systeem moet dus op het moment van wijziging het verschil naar de koppeling sturen al dan niet in 2 transacties geplitst. Dat is nogal fout gevoelig, als het systeem er tijdens de transactie uitklapt, wordt de verandering potentieel niet doorgegeven. Om deze reden moeten er vaak uitgebreide voorzieningen binnen enkelvoudige waarheid systemen worden doorgevoerd, als men ze koppelt met financiële systemen. Het gekoppelde productiesysteem wordt eigenlijk “dagboek” van de financiële administratie en daardoor noodgedwongen qua inrichting ook tot dubbelzijdige administratie aangezet. Hoe het ook bekeken wordt, in essentie worden de productiesystemen uitgerust met een vorm van dubbelzijdig boekhouden. Wat dit proces extra bemoeilijkt is dat de meeste ontwikkelaars niet meteen begrijpen waarom je een enkelvoudige waarheid systeem plotseling moet uitrusten met uitgebreide “logging” faciliteiten. Het concept van het veranderen van informatie door het toevoegen van informatie wordt niet altijd begrepen.

Verzamelingenleer

Dan is er nog zoiets als verzamelingenleer. Sinds Edgar Codd (de uitvinder van SQL) zijn er duidelijke beelden ontstaan over gegevensverzamelingen en hoe je verzamelingen wiskundig maar ook in een databasetaal managet. De taal SQL (Structured Query Language) voorziet in een vaste set met regels die niet geschonden kan worden. Deze set bepaalt hoe je verzamelingen met elkaar kunt vermenigvuldigen, optellen, aftrekken en zelfs delen. Ook bepalen de regels hoe je de deelverzameling kunt nemen van twee verzamelingen (in essentie een intersectie) en precies het omgekeerde (uitsluiting van de overlappingen) of beter optellen zonder dubbelen.

Naast deze vaste regels zijn er laten we zeggen: “hoffelijkheid regels”. Deze hebben te maken met Consistentie, daarmee samenhangend Uniciteit en referentiële integriteit en als laatste redundantie. Bij het niet toepassen van deze regels ontstaat vaak informatieverlies. De gegevens zijn er, maar de samenhang is verdwenen.

Een simpel voorbeeld in een datamodel diagram laat zien hoe zoiets in elkaar steekt:

1 klant kan N orders bestellen
1 artikel kan N keer voorkomen in een order
M artikelen kunnen door N klanten besteld worden

Er is in dit voorbeeld geen rechtstreekse relatie tussen een artikel en een klant. De order die de verbinding vormt wordt ook wel structuurrecord genoemd. Essentieel is dat als je het structuurrecord verwijderd, of artikelen en/of klanten verwijderd waarvoor een structuur record bestaat er gebrek aan referentiële integriteit ontstaat in de database. Er ontstaan dan zogenaamde “Orphans” ofwel records waarvan de betekenis verloren is gegaan. Orders met artikelen die niet bestaan. Orders met klanten die niet bestaan, of klanten zonder orders die er eerst wel waren en artikelen die eerder wel besteld waren in een order, maar nu niet meer.

Referentiële integriteit kan in essentie op twee niveaus worden afgedwongen 1) de database bewaakt het toevoegen en verwijderen van records teneinde Orphans te voorkomen 2) de applicatie doet dit. Er zijn tussenoplossingen die nog fraaier zijn, maar het voert te ver om daarover in dit artikel uit te weiden.

Het zelfde geldt voor Uniciteit. De database kan afdwingen dat een record uniek wordt aangeduid, bijvoorbeeld met een artikelnummer en ook de applicatie kan dit regelen (het voert weer te ver om hier uitgebreid over uit te weiden). Consistentie is hieraan verwant. We kunnen niet hebben dat een klantnummer bijvoorbeeld x-yyyy-z wordt geschreven en dan weer yyyy-x-z.

Met Redundantie is iets anders aan de hand. Hoe gaan we bijvoorbeeld  om met orders met meerdere dezelfde artikelen? Nemen we per  order regel de aantallen per artikel op, of nemen voor elke extra artikel een nieuwe orderregel in de order op? Het kan soms noodzakelijk zijn om redundantie juist te creëren; het zogenaamde denormaliseren. Over referentiële integriteit, denormaliseren en database optimalisatie zijn boeken vol geschreven, maar dat voert te ver voor dit artikel.

Koppeling van systemen en verzamelingenleer:

Als we binnen één systeem blijven lijkt het tegenwoordig over algemeen wel goed te gaan. Als we echter systemen gaan koppelen, dan ontstaat er een dynamiek tussen de systemen waarvan de basisregels in essentie te vergelijken zijn met verzamelingenleer. Hierdoor ontstaan allerlei vervelende bijverschijnselen, bijvoorbeeld het feit dat meeste systemen niet van dezelfde leverancier komen en dus niet hetzelfde datamodel hebben, misschien zelfs niet eens hetzelfde database type. Bovendien zijn de protocollen voor uitwisseling van data vaak afwijkend. Voor dit soort problematiek is middleware zoals Biztalk ontwikkeld, maar de basisproblemen die afkomstig zijn uit de verzamelingenleer blijven bestaan. Hoe koppelen we de gegevens, welke verzameling is leidend, hoe bewaren we referentiële integriteit, hoe gaan we om met redundantie en consistentie?

Helaas kunnen we SQL vaak niet of niet gemakkelijk gebruiken om de vertaling tussen gekoppelde systemen tot stand te brengen, vanwege verschillende datamodellen, verschillende databases en soms proprietary datamodellen van de leveranciers. Daarnaast wordt de referentiële integriteit vaak door de applicaties zelf bewaakt en dan kan dit niet door SQL worden gedaan.

Pakket leveranciers  staan vaak niet toe dat er gegevens op database niveau worden toegevoegd. De kern van de meest pakketten is dat het datamodel en het bewaken van de consistentie en referentiële integriteit wordt behandeld binnen de applicatie en niet op database niveau. Dit bepaald namelijk mede de toegevoegde waarde van een pakket. Daardoor is het niet mogelijk zonder tussenkomst van het pakket gegevens toe te voegen aan de database, omdat de leverancier zijn datamodel en “consistentie regels” niet, of niet geheel vrij geeft.

Koppelingen worden daarom vaak met interface talen zoals XML en JSON, of vroeger het CSV protocol gebouwd. Het exporterende pakket produceert XML zoals het importerende pakket het wil hebben. Hoewel talen zoals XML eigenlijk bedoeld zijn voor dynamische dataverwerking (liquid) zoal op het Web, werkt dit uiteraard niet voor bijvoorbeeld statische financiële pakketten. Er is tegenwoordig ook veel mogelijk op het gebied van koppeling software / middleware zoals BizTalk. Dit soort software vergroot echter de problemen van uitwisseling van gegevens, als niet wordt nagedacht over het datamodel en de IPO functie van de onderneming.

Kijken we dan wat verder dan is er altijd een beperkte set met regels die gehanteerd moet worden wil een koppeling succesvol tot stand worden gebracht.

1) Hou rekening met het feit dat enkelvoudige waarheid systemen meestal moeten worden omgebouwd tot dubbelzijdige boekhoudsystemen als de koppeling met de financiële administratie tot stand wordt gebracht, vooral als het om financiële gegevens gaat.

2) Kunnen we de structuur van de koppelingen en de processen in de organisatie zo opbouwen dat het IPO model wordt gevolgd? Dit betekent:
– van elke gegevenssoort wordt maar op 1 plaats de gegevens gewijzigd. Voorbeeld: als de adresgegevens van een debiteur worden gewijzigd en een productiesysteem heeft de regie, dan dus niet de adresgegevens in het financiële systeem wijzigen, want die worden  overschreven door de koppeling.
– de stroom van gegevens werkt zoveel mogelijk maar 1 kant op. De koppelingen brengen gegevens van het onderliggende systemen in IPO volgorde naar het bovenliggende systeem en niet andersom.

3) Welk systeem is de baas? In beginsel is het onderste systeem de baas. Dat wordt bijvoorbeeld door financiële pakketten, maar ook de boekhouding vaak niet zo leuk gevonden. Voorbeeld: welk systeem verzint het debiteurennummer, de unieke sleutel voor een debiteur. Door een range af te spreken waarbinnen het onderste systeem dit mag verzinnen, is het mogelijk om dit toch aan het onderste systeem over te laten. De overige debiteuren die niet door de productiesystemen worden geraakt kunnen dan buiten de range door het financiële pakket worden aangemaakt. Waarom is het hebben van hetzelfde debiteurnummer relevant? Als iemand de adresgegevens wijzigt en dat niet in het onderste systeem doet (maar bijvoorbeeld in de financiële administratie), dan weten we a) niet meer welke adresgegevens relevant zijn, b) kunnen we de klanten niet meer koppelen c) zal bij eerstvolgende adreswijziging in het onderste systeem een koppelingstroom ontstaan, die onterecht resulteert in het aanmaken van een nieuwe debiteur in het financiële systeem. Hierdoor ontstaat vervuiling en redundantie in het financiële systeem.

4) Koppelingen vormen vaak een essentieel onderdeel in de bedrijfsvoering. Ze bepalen mede de “Competitive Advantage” van het bedrijf ten opzicht van de markt. Het is derhalve van groot belang dat de leiding van het bedrijf betrokken is bij de realisatie van koppelingen en dit zeker niet afdoet als een zaak van techniek.

Het luxe model

Sommige organisatie willen het liefst dat het mogelijk is om in de bovenliggende systemen iets te wijzigen en voorzover relevant dat dit ook doorgevoerd wordt in de onderste systemen. Er ontstaat dan tweeweg communicatie waarbij gelijktijdigheid een rol speelt.  
Onder normale omstandigheden kunnen twee gebruikers in een database niet gelijktijdig hetzelfde record wijzigen. De database zorgt ervoor dat slechts één gebruiker tegelijk het record “heeft” en kan wijzigen. De tweede gebruiker moet wachten en kan pas na een refresh bepalen of hij / zij de wijziging nog wel wil doorvoeren adhv. de zojuist doorgevoerde wijziging van de concurrent. Helaas is dit met gekoppelde systemen haast niet de realiseren, omdat de wijzigingen op verschillende plaatsen plaatsvindt en ook nog eens op verschillende redundante gegevensverzamelingen. Het risico bestaat dus sowieso dat bepaalde gegevens worden overschreven met minder relevante gegevens, als we 2-weg gaan uitwisselen.

Mocht het dan toch noodzakelijk zijn om dit te realiseren, dan beschikt de meest Middleware wel over faciliteiten om dit tot stand te brengen. De kern van het probleem is dat beide systemen unieke sleutels hebben voor de uit te wisselen gegevens en dat de koppeling deze sleutels eigenlijk al moet kennen voordat de uitwisseling van de gegevens tot stand komt. Dat kan, door beide systemen leeg te trekken met de unieke sleutels van de uit te wisselen gegevens. Hierdoor ontstaat redundantie in de Middleware, die als het ware als “structuur record” (zie hierboven) fungeert. Vervolgens is het mogelijk om over en weer gegevens uit te wisselen.

Hieraan kleven wel de nodige nadelen: redundantie van gegevens, gelijktijdigheidsproblematiek en bij een gecrashte middleware omgeving zit er vaak niets anders op dan de database van de middleware in zijn geheel opnieuw op te bouwen. We kunnen immers niet meer precies bepalen, wat wel of niet gesynchroniseerd is. Dit heeft zijn beperking ivm de technische grenzen van de mogelijkheden van de koppeling. Als het uren of dagen gaat duren om de middleware te synchroniseren, na een crash, is het de vraag of dat acceptabel is.

Samengevat: koppeling van systemen aan de boekhouding, of een ERP systeem, er zijn altijd voordelen en nadelen. De afweging moet een strategische en bedrijfskundige zijn en niet een technische. ICT is tegenwoordig onderdeel van de strategische bedrijfsvoering en met enig logisch nadenken en de juiste betrokkenheid van de leiding van het bedrijf kan veel leed worden voorkomen.

Roland Zoet – Big data Analist – Rez Management. Hoe krijg je op ICT gebied iets voor elkaar in een organisatie? Heeft u weleens dat gevoel gehad van: “ik wilde dat ze het begrepen en erachter gingen staan”? Het succes van een project of een programma wordt in hoge mate bepaald door dit gevoel van collectieve urgentie. Het collectief gevoel van “goed bezig te zijn”…Dit laatste is ook vaak verbonden aan het juiste applicatielandschap en voldoende business alignment, ofwel de juiste tools voor de business. Wat gebeurt er als dit gevoel ontbreekt? Welke effecten op de winstgevendheid en het toekomstperspectief van het bedrijf heeft het keer op keer plichtmatig meedoen aan projecten ? Wat zou er gebeuren als je de kracht van “het gevoel van goed bezig” zou kunnen ontsluiten binnen een onderneming? Wat als je deze kracht keer op keer zou kunnen ontsluiten? Als bedrijfskundige en strategisch ICT consultant hoe ik me bezig met dit vraagstuk en ondervind ik in de dagelijkse realiteit dat ICT projecten en business / marktproposities niet vanzelfsprekend zijn.  Het ontsluiten van bedrijfskracht en het creëren van samenhang en een collectief gevoel van urgentie is een vak en een studie die nimmer stopt. Zwaar werk, maar verfrissend en dikwijls verbreekt het ook vicieuze cirkels…Waar zit voor uw gevoel de urgentie?

Mogelijk ook interessant

In het verlengde van de inhoud van de artikelen op onze website, biedt Utrecht Business de mogelijkheid op het onderwerp/vakgebied een opleiding te volgen. Hiertoe worden verschillende varianten aangeboden.