EEN INTEGRAAL SYSTEEM Deel I

EEN INTEGRAAL SYSTEEM

        DEEL I (versie 1.0)

Voorgeschiedenis, Informatieanalyse,                                   Journalisering. 

IN DIENST BIJ KPN

In 1980 ben ik in dienst getreden bij wat toen PTT Telecom heette. Na de verzelfstandiging van de PTT, is de naam KPN: Koninklijke PTT Nederland ingevoerd, en werkte ik bij KPN Telecom. Na een  boedelscheiding tussen Post en Telecom is KPN de naam van het Telecom-deel geworden. Ik gebruik deze naam vaak gemakshalve omdat deze nog altijd gebruikelijk is. Waar dat relevant is ook wel een eerdere naam gebruikt.

 

Ik had na het verlaten van het Mathematisch Centrum alleen maar tijdelijke functies gehad. Een vaste baan in de wetenschap was niet voorhanden. Karien en ik hadden ondertussen een dochter en een tweede kind was op komst. We kregen behoefte aan wat vastigheid. 

{Op de periode tussen Mathematisch Centrum en PTT Telecom kom  ik misschien later nog wel eens terug.}

Ik was aangenomen bij een afdeling van PTT Telecom: met als naam CAFOWA;  een acroniem voor een centrale afdeling verantwoordelijk voor allerlei organisatorische aspecten van Telecom, waaronder de Administratieve-Automatisering. Ik kwam terecht bij het onderdeel FOWA-AUT; dat verantwoordelijk was voor dat laatste aspect.

Ik heb zo een 7 jaar bij AUT gewerkt, in feite steeds als medewerker aan één groot integraal project. Ik wijd twee posts aan deze periode. In dit eerste deel gaat het over de voorgeschiedenis van dat project voordat ik erbij betrokken raakte, mijn deelname aan de informatieanalyse, en mijn projectleiderschap van het deelproject Journalisering van dat integrale project. 

In het tweede deel zal het gaan over mijn projectleiderschap aan een ander deelproject: Eenvoudige Facturering van Bedrijfstelecommunicatie (EFBT), en een evaluatie van de resultaten  van het overkoepelende project, en de werkwijze bij de ontwikkeling ervan.

EEN AMBITIEUS PLAN: ITCIS

Voor FOWA-AUT was er reeds geruime tijd  een ambitieus plan: voor intern gebruik is er in 1973 een brochure verspreid over het ITCIS-project (Integraal Telecom Cliënten InformatieSysteem). Er wordt gewezen op de noodzaak tot het verder inschakelen van de computer dan het uit 1963 stammende incassosysteem TICO (TelecomInCassO). Genoemd worden de dan al lopende activiteiten voor het vervaardigen van telefoongidsen en het populaire 008 voor het telefonisch opvragen van nummerinformatie.

Waar het in om gaat in deze brochure is: dat op heel wat plaatsen in de 13 telefoondistricten gegevens van abonnees worden bewaard en bijgehouden. Bij de indienststelling van een nieuwe telefoonaansluiting moesten de volgende bestanden worden gemuteerd: het orderbestand, de gegevens voor 008 (telefonisch opvragen van telefoonnummers), het gidsbestand, het incassobestand en het technisch overzicht (van het lokale aansluitnet), en de storingsdienst. Bovendien werd in de aankomende jaren een sterke groei van het aantal abonnee’s verwacht.

De computer werd geacht te kunnen realiseren dat deze gegevens centraal éénmalig zouden worden opgeslagen in een database terwijl opvragen en muteren middels terminals zou kunnen gebeuren.

Integraal wil zeggen zeggen dat in principe slechts één mutatie wordt gemaakt, maar ook dat in de database elk gegeven slechts eenmaal voorkomt. 

ITCIS zou de afdelingen moeten bedienen die bovengenoemde bestanden muteren of gebruiken. 

In de brochure (uit 1973) staat dat het ontwerp van ITCIS in grote trekken gereed is en dat men bezig is de onderdelen rond 008 en telefoongidsen in detail uit te werken, zodat de programmeurs aan de slag kunnen.

Om opportuniteitsredenen, schaarste aan beschikbare deskundigen op andere onderwerpen, zal men met de inlichtingendienst 008  beginnen: verwacht wordt dat in 1974 het eerste district ermee kan werken. Vanwege de enorme conversie voor het aansluitnet zal het technisch overzicht als laatste aan de beurt komen. De bedoeling was dat ITCIS in zijn totaliteit voor 1980 gereed zal zijn.

Er is in 1978 een tijdschrift verschenen, een special van het maandblad INFORMATIE, dat geheel gewijd was aan “Het ITCIS-project van de PTT”. Met een inleiding van prof. Van Oorschot en artikelen van prominente medewerkers van FOWA-AUT. 

Telecom beschikte inmiddels over één geavanceerde database; de destijds bekende Database 008, waarbij je van iedere klant aan een telefoniste het telefoonnummer kon opvragen. Deze database, en alle programmatuur daar omheen (ik dacht dat ook het produceren van gidsen gerealiseerd was) was daarmee het eerste  onderdeel van ITCIS. Maar dat zou nog vele andere onderdelen gaan bevatten: (klant)orders, (werk)orders, logistiek, storingen, gids vermeldingen, autotelefonie, bedrijfs- en particuliere telefonie en incasso. 

Ik denk dat de hoop uit 1973 dat ITCIS voor 1980 gereed zou zijn toen al lang vervlogen was. 

Binnen (FOWA-)AUT kwam ik in eerste instantie terecht bij het onderhoudsteam van TICO (Telecom Incasso), een groot, functioneel en technisch verouderd, maar nog prima draaiend systeem. Hierin werd een klant geïdentificeerd met zijn telefoonnummer: twee telefoonnummers; twee klanten. Met de toen al aanstormende communicatiemogelijkheden en -behoeften, met name van bedrijven, was dat volkomen achterhaald. Ik was beoogd ontwerper van een opvolger voor TICO. 

De eerste paar maanden  heb ik me verdiept in dat systeem, waarbij ik nogal wat wonderlijke zaken tegen kwam. Zo was er bijvoorbeeld een gegevenstype met de naam telefoonsoort, dat niets met het type van het telefoontoestel die op het betreffende nummer zat te maken had, maar een codering was voor de soort klant die er achter zat, en hoe deze gefactureerd moest worden. Er was zelfs een code van telefoonsoort die betekende dat de betreffende klant lid was van de PTT-kamer (een adviesorgaan dat tussen 1955 en 1988 bestond); en daarom geen rekening kreeg. 

TICO had een heel groot bestand, dat op tape stond, of beter gezegd op een aantal tapes. Dit bestand was georganiseerd als ware het een grote bak ponskaarten.

 

Daarnaast kreeg ik uit de afdelingsbibliotheek boeken in handen over (relationele) databases. En dat was nieuw en zeer leerzaam voor mij. In de administratieve automatisering waren databases snel heel belangrijk aan het worden. Waar eerst een bestand een bak met ponskaarten was, of hooguit een magnetische tape, werd het nu een bestand dat op meerdere sleutels bevraagd kon worden.

 

Kort voor ik aankwam was er een nieuwe chef-AUT aangetreden die ITCIS moest gaan realiseren. En vanaf een bepaald moment werd er planmatig gewerkt, met als eerste stap een informatie-analyse.

Ik heb van 1980 tot 1987 aan ITCIS gewerkt. Tot 1982 als deelprojectleider van de informatieanalyse, daarna tot 1984 als projectleider van het deelproject Journalisering, en vervolgens tot 1987 als projectleider van het deelproject EFBT (Eenvoudige Facturering Bedrijfs Telecommunicatie). 

INFORMATIEANALYSE (1980-1982)

Voor ITCIS moest natuurlijk een grote informatieanalyse uitgevoerd worden. De Chef-Aut was zo verstandig om daarvoor een heel ervaren (Engelse) deskundige in te huren: Peter Clemerson; ik heb veel van hem geleerd. Onder hem zouden twee teams de informatieanalyse uitvoeren, één team in Groningen dat 4 projecten (onderwerpen) zou doen, en één in Den Haag waar ik de leiding van kreeg, tevens zou ik het onderzoek voor Incasso doen. Voor het laatste had ik één goed in deze materie ingevoerde medewerker. De andere Haagse projecten hadden een eigen bemensing.

 

Clemerson stelde lijsten op van de soort informatie die ieder project zou moeten opleveren. Dit waren kwantitatieve gegevens: het aantal en de grootte van de records. Hoeveel interactieve gebruikers, hoeveel records er in real time, en hoeveel in de nacht in de batch, behandeld zouden  moeten worden. Kortom de systeembelasting. 

Maar ook een indicatie van de hoeveelheid programmatuur dat ontwikkeld zou moeten worden.

Om de gevraagde informatie te vergaren was er veel contact met de uitvoeringsorganisatie: de 13 telefoondistricten nodig.

Omdat ik met Clemerson in Den Haag zat, en hij geen Nederlands sprak, trad ik veel als zijn tolk bij bijeenkomsten op.

Naast Clemerson was een lijnchef van AUT uit Groningen, die  veel van de betrokken bestaande systemen/administraties, zoals TICO, aanstuurde formeel projectverantwoordelijk. Clemerson had de dagelijkse leiding, maar droeg ook -daar was hij voor aangetrokken- de inhoudelijke verantwoordelijkheid voor de informatieanalyse.

 

Deze analyse duurde langer dan gepland.  Vooral het onderwerp TICO/Incasso dat op mijn bordje lag kostte veel tijd, tot ongenoegen van de verantwoordelijke lijnchef. Waarbij gezegd moet worden dat hij een veel grotere kennis had van het deelgebied Incasso dan van Clemerson of mij verwacht kon worden, en redelijkerwijs van tevoren had kunnen weten dat de planning onhaalbaar was. 

Clemerson claimde extra tijd, verminderde de hoeveelheid informatie die voor Incasso opgeleverd moest worden, en raadde mij sterk aan de nieuwe planning te halen: hetgeen lukte.

 

Bij het eindrapport van de analyse van een deelgebied hoorde ook een schets van de opzet van een nieuw systeem.  Voor mij was dat Incasso.

 

Mijn Schets van Incasso

De hoeksteen van mijn schets was, wat ik een  Notaparagraaf noemde: een vordering met de intrinsieke gegevens die daarbij horen, geschikt om eventueel zelfstandig als nota verstuurd te kunnen worden. Er zouden stuurgegevens aan toe gevoegd worden die ervoor zouden zorgen dat de vordering conform de eisen van Telecom en de afspraken gemaakt met de klant op een nota zou komen te staan.

Er zou een grote “hoed”, database, komen waarin allerlei partijen van Telecom hun notaparagrafen konden deponeren. 

Regelmatig zouden er notaruns draaien die alle vorderingen die bij deze run hoorden uit de hoed visten om deze vervolgens uit te sorteren  naar  de nota’s die deze run zou gaan produceren. Het incassobeleid zou eisen opleggen aan de notaruns, en aan de stuurgegevens bij de vorderingen die bijvoorbeeld afdwongen dat alle nota’s van een notarun dezelfde betalingstermijn zouden hebben. 

Het incassobeleid zou er met de stuurgegevens ook voor kunnen zorgen dat het oninbaar verklaren van vorderingen, en het stoppen van bepaalde diensten na wanbetaling,  enerzijds redelijk simpel zou kunnen, en aan de andere kant aan de eisen van Telecom zou voldoen.

Beoordeling van mijn funtioneren

 Bij  het einde van de informatieanalyse werden wij beoordeeld. En mijn  beoordeling, door de lijnchef uit Groningen, was slecht: 

1. De vertraging in de informatieanalyse werd mij kwalijk genomen
2. De mensen uit de gebruikersorganisatie hadden mijn optreden bij bijeenkomsten ‘merkwaardig’ gevonden.
3. Het managementteam van AUT was niet gecharmeerd van mijn systeemschets. Ze vonden met name dat een Nota te verzenden door een districtsdirecteur niet uit hetzelfde systeem kon komen als een Nota te verzenden door een Centrale afdeling

En ik werd door de lijnchef ongeschikt geacht een projectorganisatie te leiden.

Ik maakte bezwaar tegen de beoordeling bij het hoofd van de Centrale Afdeling waar Automatisering een onderdeel van was. Argumenten:

Ad 1. Incasso was nu eenmaal gigantisch, vandaar dat een vertraging mij niet zwaar aangerekend kon worden, bovendien had ik  de aangepaste planning wel gehaald.

Ad 2. De lijnmanager had mij deelname aan de normale bedrijfsopleiding onthouden omdat ik zo hoog geschoold was dat ik meteen aan de slag kon. Maar daarmee had ik een kennismaking met de bedrijfscultuur gemist. Bovendien was een groot deel van mijn optreden als tolk voor en spreker namens Clemerson geweest.

Ad 3. Dit was onzin; het is triviaal om voor iedere afzender een eigen kop en ondertekening van de nota te maken. Daar ga je toch geen apart systeem voor bouwen!

 

Het afdelingshoofd had mijn rapport gelezen, vond het glashelder, maar het managementteam van de Automatiseringsafdeling had hem uitgelegd dat er toch veel aan schortte.

Ik heb vervolgens contact opgenomen met de chef van de Automatiseringsafdeling, en hem er op gewezen dat volgens het reglement van PTT een medewerker beoordeeld moet worden door de functionaris die direkt leiding heeft gegeven aan de werkzaamheden gedurende de betreffende periode. Die functionaris was Clemerson en niet de bewuste lijnmanager. En het feit dat Clemerson een externe was, zou niet mijn probleem mogen zijn. In tegendeel het had mij in het bedrijfsbelang geleken Clemerson zo goed mogelijk te ondersteunen.

De Chef-Aut heeft toen nog een beoordeling gevraagd aan Clemerson, en deze was wel positief.

 

Het afdelingshoofd had toen twee beoordelingen die elkaar tegenspraken, en vond dat hij geen oordeel kon geven. Er zou geen beoordeling in mijn dossier komen te staan.

 

Ik heb daarop een interne sollicitatie gedaan bij de Postgiro, dat toen nog tot de PTT behoorde. Daar was, in strijd met de afspraak bekend, dat ik een slechte beoordeling had gehad, en ik werd niet aangenomen.

 

Ik hoorde van een collega dat de bewuste lijnmanager wel vaker academici een rare beoordeling gaf. En ik besloot in geen geval voor PTT naar Groningen te gaan. (Ik had inmiddels bij een bezoek aan de collega’s in Groningen geconstateerd dat de Centrale Directie dat ook niet van plan leek, men toonde mij een chique gang in een indrukwekkend gebouw, met kamers voor alle directeuren. Naar men mij vertelde stonden deze altijd leeg).

 

Volgens mij zou de automatiseringsafdeling misschien wel naar Groningen gaan; maar Telecom als bedrijf niet. Het zou binnen niet al te lange tijd verzelfstandigd worden, en de grote klanten zaten vooral in de randstad.

Verder had ik geconstateerd dat het personeelsbeleid van Telecom op papier prima was, maar met de uitvoering ervan had ik geen goede ervaringen. Ik ging niet met de Automatiseringsafdeling mee naar Groningen.

 

Opstart van ITCIS

Na het einde van de Informatieanalyse voor het Integraal Telecom Informatie Systeem was er een lange periode van besluitvorming.

•   De directie besloot dat de prioriteit werd gegeven aan Incasso.  Uit het oogpunt van de bedrijfsvoering zal dit ongetwijfeld rationeel geweest zijn. Maar informatietechnisch komt Incasso na de klantorder en in geval van nacalculatie zelfs na de levering, en vaak een werkorder. Vorderingen zouden op enigerlei wijze aan de notavervaardiging aangeleverd worden. Beginnen met Incasso betekent extra programmatuur om dergelijke vorderingen in het systeem te krijgen.
•   Er werd voor heel ITCIS een interne projectleider namens de gebruikers en een interne projectleider voor de Automatisering aangesteld.
• In het eindrapport van de  Informatieanalyse werd als machinekeuze  de VAX van DEC voorgesteld.  Telecom gebruikte echter Unisys en er werd geprogrammeerd in Cobol.  Op een gegeven moment heeft de Directie besloten dat het Unisys en Cobol zou blijven. Dat was, naar mijn bescheiden mening, weinig vooruitstrevend. Het gaat hierbij om het al dan niet de beschikking hebben van een relationeel database systeem, en het gebruik van een verouderde programmeertaal.  ITCIS heeft nooit een relationele database gekregen. Wel is er als ambitieuze  eigen ontwikkeling een Data Interface gebouwd teneinde een relationele view op de database mogelijk te maken. Dit betekende overhead die de ontwikkelomgeving zwaar en duur maakte De bedoeling was dat dit Data Interface zodra Unisys een relationele database kreeg de overgang simpel zou zijn en het Data Interface kon vervallen. Dit is nooit gebeurd. DEC Digital Equipment Cooperation was in die tijd een belangrijke speler die voorop liep in de ontwikkelingen. De VAX had een relationele database, en had helemaal geen datainterface nodig. De basis voor het Data-interface is echter gelegd toen een keuze nog niet gemaakt was. 

Ondersteunend Projectmedewerker 

Ikzelf zou op grond van de beoordeling van mijn inbreng bij de informatieanalyse geen projectleider van bijvoorbeeld Notavervaardiging of Inning worden. Maar aangezien de informatieanalyse van Incasso niet is overgedaan, is mijn eindrapport inclusief de systeemschets wel als uitgangspunt van ITCIS gebruikt, ‘what else?’ Deze schets ligt daarmee aan de basis van veel wat van ITCIS gerealiseerd is.

Ik werd ondergebracht bij het project AFH: Automatische Facturering Huisautomaten. Dat zijn de telefooncentrales van bedrijven. Ze  variëren van klein, een paar lijnen, tot heel groot; met een eigen intern netwerk. Een bijzonder complex onderwerp. Daarnaast waren er nieuwe ontwikkelingen als autotelefonie en datanet die in eerste instantie  ook onder AFH  vielen.

AFH was in aanvankelijk geen ITCIS-project, maar het lag gezien de prioriteit van ITCIS voor incasso wel voor de hand dat het dat in een later stadium zou worden.

De projectleider van AFH: Rob van Vliet en ik kenden elkaar want we waren een paar jaar op het Mathematisch Centrum collega’s geweest. We zijn beiden nogal inhoudelijk ingesteld, en mijn rol binnen AFH is vooral geweest dat ik Rob ondersteund heb bij zijn pogingen de grote complexe brei die op zijn bord lag wat te structureren.

Dat resulteerde uiteindelijk in twee projectvoorstellen voor ITCIS:

1.   PTT Telecom had een nogal complex rekeningschema. Bedenk dat de PTT onderdeel van een departement was, maar Telecom in transitie was naar een commercieel bedrijf in een zich snel ontwikkelende markt. Er zouden heel wat verschillende typen financiële transacties binnen ITCIS automatisch uitgevoerd moeten worden: dit zou per deelproject flink wat regels programmatuur betekenen. Bovendien gebruikte de boekhouding een 11-cijferig rekeningnummer, waarin een bepaalde betekenis gecodeerd zat. (Het werkt als een getal achter de komma, de voorste cijfers hebben de meeste betekenis, een paar nullen achteraan betekent “geen verdere detaillering”). Wij zochten een oplossing waarbij voor het journaliseren van een bepaalde bedrijfsfunctie, zoals het verzenden van een nota, het boeken in het journaal op een wijze zou kunnen gebeuren, die zowel simpel was, maar ook voor elke andere bedrijfsfunctie binnen het boekhouddomein gebruikt zou kunnen worden, waarbij de betekenis expliciet was. Onze oplossing was een eigen detail rekeningstelsel, waar geboekt werd op kenmerken die op natuurlijke wijze in de database konden worden opgenomen. Terwijl de programmatuur nodig voor de detailboekingen als subroutine onderdeel kon zijn van de programmatuur waarmee de betreffende bedrijfsfunctie werd uitgevoerd. Dit werd het projectvoorstel Journalisering.

2.   In de Bedrijfstelecommunicatie kwam naast telefonie ook andere  oude diensten zoals Telegrafie en Huurlijnen voor, maar ook nieuwe zoals Datanet, Semafonie en Autotelefonie. Deze hebben ieder hun eigen problematiek, maar zijn op zich veel simpeler dan de Bedrijfstelefonie met zijn huisautomaten. Bovendien kwamen er met enige regelmaat nieuwe, in eerste instantie, simpele diensten op de markt. Hiervoor bedachten wij het concept Eenvoudige Facturering Bedrijfstelecommunicatie. Waarmee je volgens ons in hoge mate tabelgestuurd een applicatie voor een nieuwe simpele dienst zou kunnen genereren. Dit werd het projectvoorstel EFBT. “Eenvoudig” slaat hierbij op de facturering; deze moest relatief simpel zijn om door EFBT te kunnen worden afgehandeld. Het systeem EFBT zelf was een generiek systeem bedoeld voor allerlei diensten, en als zodanig helemaal niet zo eenvoudig.

Na ongeveer een jaar, werd AFH onder de naam BedrijfsTeleFonie (BTF) opgenomen in ITCIS en schreef Rob met zijn team de zeer omvangrijke Probleemdefinitie-Studie daarvoor.

Ikzelf werd projectleider van Journalisering, in eerste instantie zowel voor de gebruikers als voor de automatisering.

 

 

HET PROJECT JOUR

Bij de start van het project lag er het geaccordeerde projectvoorstel  van Rob en mij.

Ik mocht alsnog projectleider worden. Ook voor de gebruikers want daarvoor was in eerste instantie niemand beschikbaar. Het district Rotterdam was bereid medewerking te verlenen. In een kantoor aan de Botersloot aldaar zijn alle groepsbijeenkomsten gehouden, er deed personeel  van de boekhoudafdeling die daar gevestigd was aan mee, maar ook personeel van andere districten. Totaal ongeveer tien personen. Er was ook een medewerker van de Centrale Afdeling Control bij betrokken, deze was in opleiding tot accountant. Hij hielp mij heel goed op weg, maar verdween helaas naar het bedrijfsleven. Later is de jong overleden René de Ruyter projectleider van de gebruikers geworden.

 

We begonnen met een uitgebreide informatieuitwisseling: de boekhouders fristen mijn boekhoudkennis op en leerden mij hoe de processen die door ITCIS ondersteund/uitgevoerd zouden worden nu gejournaliseerd werden. Ik legde uit met welke middelen we dat in ITCIS dachten te doen.

 

We begrepen elkaar goed. Maar al gauw bleek dat er voor het boeken op kenmerken veel meer rekeningen nodig zouden zijn dan op dat moment het geval was. Het kwam vaak voor dat op één grootboekrekening voor één kenmerk meerdere waarden gecombineerd werden. En soms zelfs twee rekeningen van verschillende rekeningsoorten gecombineerd moesten worden. Ik kwam met een mechanisme om voor het grootboek meerdere detailrekeningen te projecteren op één grootboekrekening. (Eigenlijk zat het andersom een bestaande grootboekrekening werd gesplitst in meerdere detailrekeningen). Het grote voordeel van dat uitsplitsen is dat het boeken simpel en daarmee goed automatiseerbaar kan worden.

Maar er waren ervaren boekhouders die zich niet prettig voelden met zoveel rekeningen. Uiteindelijk zijn we er toch uitgekomen. Voornamelijk omdat de last van die extra detailrekeningen door de computer gedragen zou worden, en het transparante en gedetailleerde mechanisme vergaande controles op het totale proces zouden opleveren. Dit is gebleken heel handig te zijn bij boekingsfouten. Deze ontstonden vooral bij nieuwe of gewijzigde functionaliteit van de boekende processen. Als het detailrekeningstelsel en de proceswijzigingen eenmaal goed op elkaar afgestemd waren, had je er geen omkijken meer naar.

 

Het functioneel ontwerp

Dat heb ik in mijn herinnering alleen geschreven, maar natuurlijk wel regelmatig aan de projectgroep en anderen laten lezen. 

In de tekst hieronder gebruik ik vereenvoudigde voorbeelden uit de praktijk van ITCIS. Ze zijn bedoeld om de opzet van JOUR duidelijk te maken, maar ze hebben niet de pretentie om de wijze waarop  bijvoorbeeld in 1995 geboekt werd precies te representeren. Zo zult u het verschijnsel BTW in die voorbeelden niet tegenkomen, hoewel er natuurlijk wel BTW werd geheven. Het zou de voorbeelden complexer maken, maar geen extra aspecten van JOUR tonen.

{ik beschik helaas niet meer over een exemplaar van het functioneel ontwerp. Voor de gebruikte voorbeelden heb ik wel documentatie uit de periode 88/89 kunnen inzien. Martin Carbo die in 1985 als programmeur bij het team kwam, en  na de bouw vele jaren functioneel beheerder van JOUR is geweest heeft me bij het interpreteren hiervan geholpen. Alle onjuistheden heb ik zelf gemaakt!}

Het Voortraject van ITCIS

Zoals gememoreerd naar aanleiding van het besluit tot het verheffen van Incasso tot prioriteit van ITCIS; beginnen de klantprocessen niet met Incasso. Er zit vóór het eigenlijke factureren dus invoerprogrammatuur die door de dienst gevoed moet worden voordat er iets te factureren valt. Soms is dat geautomatiseerd, zeker in de beginperiode was dat met behulp van een papieren dossier.

ITCIS heeft uiteindelijk twee factureringssystemen gekregen eerst BTF voor bedrijfstelefonie en later EFBT een generiek systeem voor het factureren van meerdere eenvoudige diensten, begonnen met Telex, Autotelefonie. Later zijn Datanet, Facsimile en Huurlijnen daar nog bij gekomen. 

In het gebruik van de Klantenregistratie, Notavervaardiging, Inning en Journalisering verschillen BTF en EFBT  nauwelijks. Maar Bedrijfstelefonie is natuurlijk in alle opzichten groter dan Telex. In de onderstaande figuur is sprake van een (oorspronkelijk papieren) orderdossier. Voor Bedrijfstelefonie is dat vaak een dik pak papier; voor Telex een formulier. Voor het aspect factureren zijn er wel verschillen. De diensten die door EFBT gefactureerd worden hebben wel eigen rekeningen, maar deze verschillen vooral door de waarde van het kenmerk dst; het lijkt allemaal op elkaar. BTF heeft zijn eigen rekeningen, waarbij vooral de opbrengstrekeningen uitgebreider zijn gemaakt dan die van EFBT.

HET BEDRIJFSPROCES FACTUREREN

De cirkels staan voor deelprocessen van facturering. Als er een dikke stip in de cirkel staat wordt er door het proces geboekt,   ontbreekt deze dan wordt er niet geboekt. Weergegeven wordt het bedrijfsproces. De pijlen staan voor het transport van Informatie(dragers); het zin geen boekingen. 

Dit is de eerste stap in ITCIS waarin geboekt wordt; het behelst het overdragen van een  notaparagraaf door een (telecommunicatie)dienst aan het proces Notavervaardiging.

Een notaparagraaf bevat een referentie naar een “notabundel” dat is een pijplijn van (periodieke) nota’s, door de tijd heen, voor een bepaalde klant voor een dienst. De bedrijfsprocessen van Notavervaardiging en Inning hebben daarmee toegang tot de nodige

gegevens van de klant, zijn incassoafspraken en historie. En daarmee ook de waarden van de kenmerken die afhankelijk zijn van die klant.

Voor een order voor nieuwe aansluiting van een klant op een dienst,

moet de klant geregistreerd staan; in de terminologie van de factureringssystemen: een pakket van die dienst hebben. Dit kan in eerste instantie leeg zijn; er zitten dan geen producten of aansluitingen oid aan vast. Maar op een leeg pakket kunnen wel orders geplaatst worden, en het heeft ook een notabundel (en daarmee een link naar de klantregistratie). Er kunnen dus nota’s heen. Administratieve wijzigingen, zoals het maken van een leeg pakket, of een administratieve wijziging gebeurt met orders die gratis zijn.

Bij ‘echte’ orders voor het leveren van producten, of het maken van verbindingen kan de dienst besluiten dat ze een aanbetaling willen ontvangen. Daarvoor wordt met een eenmalige notaparagraaf een nota gemaakt die vooraf gaat aan de nota voor die grote levering. De dienst zal later de aanbetaling gebruiken, om het bedrag op die laatste nota te verlagen. Maar heeft in afwachting daarvan tijdens de uitvoering van de werkzaamheden de aanbetaling al binnen. 

Bij het factureren van orders zullen vaak kontraktmutaties ontstaan. De dienst produceert periodieke notaparagrafen op basis van die kontrakten.

Daarnaast kunnen er ook met een bepaalde periodiciteit vanuit een net wat bij de dienst hoort, verbruikstickets worden gemaakt aangeleverd. Deze bevatten een verbruiksnummer dat gekoppeld moet zijn aan een pakket van de betreffende dienst. Deze worden bij het factureren van verbruik omgezet in notaparagrafen. 

Zowel de orders als het verbruik komen van buiten JOUR. Beiden vertegenwoordigen een waarde, die niet op de gebruikelijke wijze door journalisering gecontroleerd worden. 

Voor de orders is er een controle op het niveau van het grootboek; want er is een relatie tussen de eenmalige kosten, en de kosten van de werkzaamheden en leveringen bij het realiseren van de orders.

Voor het verbruik van klassieke telefonie, zeg maar BTF, is er een balansrekening voor het bestand aan verbruikstickets die ontstaan bij het inlezen van tellerstanden, maar nog niet gefactureerd zijn.

Tot zover een schets van het voortraject, waarin de notaparagrafen ontstaan.

Hieronder volgen voorbeelden van de belangrijkste journaalposten van ITCIS.

{Leesaanwijzing: hier aangekomen is het verstandig om een blik te werpen op de plaat van het Geldstroommodel (stukje lager) en daar een screenshot of foto van te maken, en deze bij de hand te houden.

Het Geldstroommodel is een kaart van het hele Incassoproces. Hieronder beschrijf ik steeds in detail een gebied op, of een aspect van die kaart}

Voorbeelden van journaalposten:

1 Factureren

factureren-KPM(tlx,rst):

van notaparagrafen(tlx,rst)    75

       aan opbrengsten-KPM(tlx,rst)     75

Deze (detail)journaalpost wordt door het factureringssysteem geboekt wanneer een periodieke notaparagraaf van 75 euro wordt verzonden naar Notavervaardiging. Daarbij worden ook de opbrengsten geboekt. Daar staat een vordering op de klant, de notaparagraaf, tegenover. In juridische zin heeft de dienst zijn opbrengsten binnen; want heeft een prestatie aan de klant geleverd. Het incassoproces dient om deze vordering te innen, waarmee de opbrengsten ook feitelijk binnen komen. 

Tussen de haakjes staan de kenmerkwaarden tlx en rst.  De eerste is een waarde van het kenmerk dst (dienst) en staat voor telex. (Daarnaast heeft dst nog waarden als btf voor bedrijfstelefonie, atf voor autotelefonie, smf semafonie, en nog een paar andere).  De tweede is een waarde van het kenmerk avk (aard-van-de-klant) en staat voor alle klanten behalve de onderdelen van Telecom zelf, die hebben tlc  als aard van de klant. Het kenmerk avk kan invloed op de prijs van produkten hebben.

De term factureren (de boekingsfunctienaam) omschrijft de soort gebeurtenis: het versturen van een resultaat van factureren: een notaparagraaf naar Notavervaardiging. Door het invullen van kenmerkwaarden  wordt de boekingsfunctie verder gespecificeerd tot een boekingstaak; het gaat over een notaparagraaf die betrekking heeft op telex, als vordering op een externe klant. De debet- en creditregels noemen we boekingstaakposten.

notaparagrafen en opbrengsten (beide rekeningsoortnamen) staan voor de betekenis van de waarden die er op geboekt worden. 

Deze worden door kenmerkwaarden tlx en rst gespecificeerd tot rekeningen: notaparagrafen betreffende telex bestemd voor een externe klant, waarvan de opbrensten voor telex zijn.

Journaalposten zijn altijd gespecificeerd. De gebruikte boekingstaakposten worden door het invullen van een bedrag, boekingposten. Hierbij moet het totaal van de debet- en creditzijde gelijk zijn. 

De notaparagraaf gaat als onderdeel van een nota op weg naar de klant, teneinde door deze betaald te worden. 

{de specificatie van de opbrengsten is tijdens de levensloop van ITCIS steeds uitgebreider geworden, vooral voor BTF.

Uitgesplitst in Verbruik, OpbrengstenKVE en OpbrengstenKPM; de laatste twee nog verder uitgesplitst in Randapparatuur en Infrastructuur. 

De drang om JOUR te gebruiken voor management informatie werd zo groot dat er er kenmerken kwamen voor installatie-typen, type voorzieningen en type leidingnet, met ieder tussen de 40 en 180 kenmerkwaarden. Dit betekende een gigantisch aantal detailrekeningen rond opbrengsten.

ik heb begrepen dat als de tabel met kenmerkwaarden maar onderhouden werd dit goed werkte. Maar als het type van een bepaald product wat bij een kenmerk behoorde, niet in de tabel stond; en de bijbehorende rekening daarom niet aangemaakt was, dan veroorzaakte dit een fatale foutmelding en een verstoring van de productie.

Voor JOUR  zijn al die extra boekingsposten voor opbrengsten meer van hetzelfde, daarom hou ik het hier simpel; ik wil inzicht geven; volledigheid is niet van belang voor het voorliggende document }

Bij facturerenKVE kunnen aanbetalingen een rol spelen. Een rekening aanbetalingen wordt gecrediteerd als in de vorm van een notaparagraaf om een aanbetaling gevraagd wordt. Deze rekening wordt gedebiteerd als in een later stadium de aanbetaling als creditnotaparagraaf verstuurd wordt om de uiteindelijke nota (deels) te voldoen.

Bij factureren verbruik zijn er twee complicaties voor BTF:

1. Er is een extra kenmerk type verbruik (tvb). Met waarden voor handgesprekken, gidsen, telegrammen en dergelijke maar ook imp voor de ‘normale’ automatische telefonie’.
2. Synchroon met de boeking ivm het versturen van de notaparagraaf voor het verbruik wordt de balansrekening te factureren verbruik afgeboekt. (voor credit-notaparagrafen is er zelfs een correctie op dat afboeken)

Voor EFBT is er niet zo een balansrekening. Er is wel een derde kenmerk voor de boekingsgemeenschap bkg, zie het vervolg, maar de kenmerkwaarde is gelijk aan die van de dienst.

Het boeken van bovenstaande journaalpost heeft tot effect dat zowel op de debetzijde van de rekening notaparagrafen(tlx,rst) als de creditzijde van opbrengsten(tlx,rst)  komt te staan factureren(tlx,rst)   75 plus de datum. Dit zijn de boekingposten.

Daarnaast bestaan er ook creditnotaparagrafen; die staan voor een bedrag aan geld, waar de klant recht op heeft. Creditnotaparagrafen worden gemaakt als er een onterechte of te hoge vordering op een nota is gezet en inmiddels is betaald. Ze worden ook gefactureerd maar de opbrengsten van de dienst worden gedebiteerd=verkleind en een rekeningsoort cr-notaparagrafen wordt gecrediteerd. Het initiatief daartoe ligt bij klachtafhandeling maar het aanmaken en opsturen ervan gebeurt door de facturering van de dienst; zij moeten het verlies aan opbrengsten accepteren.

De boekingsfunctie waarmee zowel gewone als credit-notaparagrafen kunnen worden ingediend voor kosten per maand wordt daarmee dus:

facturerenKPM(dst,avk):

van notaparagrafen(dst,avk)

van opbrengstenKPM(dst,avk)

       aan opbrengstenKPM(dst,avk)

       aan cr-notaparagrafen(dst,avk)                   

Een boekingsfunctie is nauw verbonden met de programmatuur van het bedrijsproces dat de boeking verricht. De keuze voor de boekingstaak evenals de selectie van de te gebruiken credit- en debetregels; de boekingstaakposten. en de hierbij te noteren bedragen worden aan de hand van het onderhavige geval tijdens de uitvoering van het bedrijfsproces (in run time) bepaald omdat dan de geldende kenmerkwaarden en bedragen bekend zijn. De som van debet- en creditzijde moet gelijk zijn.

Welke boekingstaken er voor een bepaalde boekingsfunctie gemaakt worden, wordt bepaald door de behoeften van het boekende proces. Sommige combinaties zijn onwaarschijnlijk; het zal niet tegelijk om een notaparagraaf en een credit-notaparagraaf gaan. Maar je zou wel een boekingstaak kunnen maken die voor beiden gebruikt kan worden, waarbij je voor journaalposten alleen die credit- en debetregels gebruikt die van toepassing zijn.

2 Ontvangen van notaparagrafen

Dit gebeurt in het systeem voor de notavervaardiging (NVS). De notaparagraaf behorende bij voorbeeld(1) wordt door NVS als volgt geboekt:

ontvangen-notaparagrafen(tlx):   

van buffer(tlx,a02)     75

       aan notaparagrafen(tlx,rst)    75

De betreffende bedrijfsfunctie neemt de notaparagraaf in ontvangt en stopt deze in een buffer. Een buffer is voor JOUR een bestand met een bijbehorende rekening. Omdat het saldo van die rekening de waarde van het bestand hoort te zijn, wordt het een balansrekening genoemd; het bestand vertegenwoordigt een waarde die op de balans thuishoort.

Er komt bij buffer een kenmerkwaarde a02 van het kenmerk administratiegroep (vaak afgekort tot admiegroep, code adm) voor.

Een admiegroep is een verzameling klanten waarvoor de periodieke nota in dezelfde batchrun wordt vervaardigd. Dit kenmerk is voor Notavervaardiging een middel om de omvang van de batchruns te bepalen. Deze kenmerkwaarde is afleidbaar uit de notaparagraaf.

Die verwijst namelijk naar de bovengenoemde notabundel, welke op zijn beurt de kenmerkwaarde van de admiegroep bevat. Daarmee kan het  boekende deelproces ontvangen-notaparagrafen, de notaparagraaf in de juiste buffer stoppen. Hetgeen een voorsortering voor het produceren van nota’s is.

Voor Inning is de admiegroep een middel om het werk op de afdeling te organiseren. Een District had 2 tot 4 admiegroepen (a01 … a04).  Na de reorganisatie ELAND (Eenduidig LANDelijk) van 1992 viel een regio samen met een admiegroep.

 

Naast de buffer is er een credit-buffer; waarvan het saldo op de   creditzijde van de balans staat omdat er credit-notaparagrafen inzitten. Beide worden ook verder uitgesplitst naar dst en adm.

De boekingsfunctie is:

ontvangen-notaparagrafen(dst):

van buffer(dst,adm) 

van cr-notaparagrafen(dst,avk)

       aan notaparagrafen(dst,avk)

       aan cr-buffer(dst,adm)

Ook hier horen per dienst meerdere boekingstaken bij, en wel precies één per dienst. De boekingstaak waarmee de bovengenoemde journaalpost geboekt zou kunnen worden.

ontvangen-notaparagrafen(tlx):

van buffer(tlx,a01) 

van buffer(tlx,a02)  

van buffer(tlx,a03)

van cr-notaparagrafen(tlx,rst) 

van cr-notaparagrafen(tlx,tlc)

       aan notaparagrafen(tlx,rst) 

       aan notaparagrafen(tlx,tlc)

       aan cr-buffer(tlx,a01) 

       aan cr-buffer(tlx,a01) 

       aan cr-buffer(tlx,a01)

 Zoals je ziet worden voor het maken van die journaalpost  maar een paar van boekingstaakposten gebruikt. De keuze hiervan gebeurt in run time.

{De gehele boekingsstructuur: boekingsfuncties, boekingstaken, rekeningsoorten, rekeningen waar we het hierover hebben zijn  met transacties van JOUR vastgelegd als data. De boekingsstructuur bepaalt welke journaalposten er mogelijk zijn. Wat ik hier beschrijf is (een vereenvoudiging) van wat er voor ITCIS, op een bepaald moment was ingevoerd. Maar JOUR zou ook voor een totaal ander bedrijf, zeg een broodfabriek, gebruikt kunnen worden; met een geheel andere boekingsstructuur}

3 Produceren van nota’s

Dit is de andere boekingsfunctie van de afdeling Notavervaardiging en gebeurt vooral in een omvangrijk batchproces per admiegroep.

Voor een bepaalde dienst en admiegroep worden notaparagrafen en cr-notaparagrafen uit de betreffende buffers gehaald. Alles voor 1 klant wordt bij elkaar gevoegd. Als het totaal een vordering is dan wordt er een nota geproduceerd en anders een creditnota. Er wordt binnen de nota dus gesaldeerd. 

De (cr)-nota wordt afgedrukt en naar de klant gestuurd. Een digitale versie gaat door naar de afdeling Inning.

De (credit)nota’s voor de interne klanten (boekingskenmerk avk heeft waarde tlc, dit staat o.a. in de notabundel), gaan niet het proces van Inning in; de nota’s gaan naar de betreffende afdelingen en de kosten worden met een sluitrekening verrekend.

De boekingsfunctie is

produceren-nota’s (dst,adm):

van nota’s (dst,adm)

van cr-buffer (dst, adm)

       aan cr-nota’s (dst, adm)

       aan buffer ( dst, adm )

Een journaalpost voor een nota waarop voor 300 aan notaparagrafen staan en  een credit-notaparagraaf van 125 euro. 

(Voorbeeld A)

produceren-nota’s (tlx,a01):

van nota’s (tlx,a01)        175

van cr-buffer (tlx,a01)   125

      aan buffer ( tlx,a01)       300 

Bij het salderen is de cr-notaparagraaf gebruikt om het eindbedrag op de nota te verlagen, niet 300 maar 175. Maar de buffer, een totaal aan vorderingen op klanten, wordt wel verkleind met de waarde van de notaparagrafen. En de credit buffer wordt 125 kleiner.

Indien in dit geval de cr-notaparagraaf naar Notavervaardiging verstuurd was nadat de er al een rekening voor de notaparagrafen was aangemaakt. Dat waren er twee boekingen geweest. 

Voorbeeld B1

produceren-nota’s (tlx,a02):

van nota’s (tlx,a02)        300

      aan buffer ( tlx,a02)       300

en B2

produceren-nota’s (tlx,a02):

van cr-buffer (tlx,a02)     125

      aan cr-nota’s ( tlx,a02)     125

Bij het produceren van nota’s wordt de rol van (credit)notaparagrafen als drager van de vorderingen op en “trekkingsrechten” van de klant worden overgenomen door (credit)nota’s. 

Door het salderen is er bij A alleen een wat lagere nota; en bij B zowel een nota als een creditnota.

4 Ontvangen nota’s

Een nota gaat naar een debiteurenbestand van de afdeling Inning en een creditnota naar een bestand vooruitbetalingen. Bij beide bestanden horen balansrekeningen. Alles uitgesplitst naar dienst en admiegroep. 

De boekingsfunctie is

ontvangen-nota’s (dst,adm):

van debiteuren (dst,adm)

van credit-nota’s (dst,adm)

       aan nota’s (dst,adm)

       aan vooruit-betalingen (dst,adm)

Er is een boekingstaak voor iedere combinatie van kenmerkwaarden voor dienst en admiegroep.

      

De nota uit voorbeeld A zou de volgende journaalpost opleveren

ontvangen-nota’s (tlx,a02):

van debiteuren (tlx,a02)    175

       aan nota’s (tlx,a02)            175

      

Ingeval B wordt een nota en een creditnota ontvangen met de volgende journaalposten.

Eerst een nota van 300 met journaalpost B1.

ontvangen-nota’s(tlx,a02):

Van debiteuren(tlx,a02)       300

        aan nota’s(tlx,a02)                300

Daarna nog een creditnota met journaalpost B2

ontvangen-nota’s (tlx,a02):

van credit-nota’s (tlx,a02)         125

       aan vooruit-betalingen (tlx,a02)     125

Na het ontvangen van de (credit)nota’s wordt de rol van de drager van  de vorderingen op en “trekkingsrechten” van de klant worden overgenomen door debiteuren en vooruitbetalingen. {ik moet de nijging onderdrukken om niet te zeggen crediteuren; want dat maakt goed duidelijk dat bij Inning de relatie met de klant als persoon duidelijk wordt. Maar KPN beschouwd de vooruitbetalers niet als crediteuren; die term wordt gebruikt voor de leveranciers. En voor het grootboek staat het saldo van vooruitbetalingen op de creditzijde van de rekening DEBITEUREN}

De credit-nota’s gaan door  inning als vooruitbetalingen gebruikt worden om openstaande posten te voldoen. Bijvoorbeeld de vooruitbetaling 125 van B2 om het debiteuren bedrag van B1 te verlagen tot 175. Hetgeen uiteraard gelijk is aan wat het debiteutenbedrag van A zou zijn geweest.

We hebben ondertussen drie verschillende typen rekeningsoorten gezien. Deze typen hebben te maken met het gedrag en betekenis van het saldo van hun rekeningen:

1. Balansrekeningen: dat zijn buffer, cr-buffer, debiteuren en vooruitbetalingen. Maar ook aanbetalingen en te factureren verbruik.Het saldo vertegenwoordigt de waarde van een bestand. Journalisering en bestandsadministratie moeten met elkaar kloppen!
2. Interfacerekeningen: dit zijn (cr-)notaparagrafen en (cr-)nota’s. Deze rekeningen dienen om een interface te bewaken. Na de nachtelijke batch moet het saldo van dergelijke rekeningen nul zijn. Als er wel een saldo is, dan is de oorzaak vaak achterstand in de verwerking bij het ontvangende proces.
3. Exploitatie-rekeningen: dit zijn de rekeningsoorten opbrengsten, verbruik en verlies-op-vorderingen (volgt hieronder). Het saldo van deze rekeningen wordt bij de jaarwisseling op nul gezet.   

De afdeling Inning kent nog een aantal processen die ik hieronder aanstip. Ze vergen vaak handmatig ingrijpen. Ik laat de journaalposten achterwege; ze geven geen nieuwe inzichten in de werking van JOUR, maar ze staan wel afgebeeld in het onderstaande Geldstroommodel.

• Dubieus verklaren; deze verplaatst vorderingen van debiteuren naar het bestand dubieuze debiteuren, met een gelijknamige bestandsrekening. Dit proces kan teruggedraaid worden.
• Oninbaar verklaren. De bijbehorende boekingsfunctie haalt het geld van de exploitatierekening verlies-op-vorderingen.
• Verrekenen vooruitbetalingen; deze gebruikt vooruitbetalingen om openstaande debiteuren of dubieuze debiteuren te voldoen. Eventueel zelfs oninbare vorderingen. Als de klant geen openstaande posten heeft wordt er gerestitueerd.

In deze versimpelde versie van INNING gebruik ik een speciale rekeningsoort sluitrekening(dst,adm) voor geldstromen die de admiegroep in of uit gaan, anders dan voor de ontvangst van nota’s en creditnota’s.

Processen die de sluitrekening gebruiken:

• De belangrijkste zijn natuurlijk de betalingen van klanten voor hun nota’s. Die komen binnen op bankrekeningen bij de boekhouding, één per admiegroep. Zij boeken de bedragen op de passende sluitrekening. Vooral als het niet gaat om automatische afschrijvingen maar om ‘losse’ betalingen, dan kan het gebeuren dat het personeel van de admiegroep, tot de conclusie komt dat het bedrag bestemd is voor een andere admiegroep. Deze gaat dan via de passende sluitrekening naar die admiegroep. Het kan ook gebeuren dat een ‘losse’ betaling voor iets buiten Inning bedoeld lijkt, een ander district, of een rekening voor een heel ander onderwerp. Dan wordt de betaling teruggestort op de creditzijde van de sluitrekening naar de eigen admiegroep. Waarbij het de bedoeling is dat de boekhouding dat verder regelt. { de tijdrovende losse betalingen zijn er steeds minder omdat vaak abonnementen worden aangeboden waarbij automatisch afschrijven geëist wordt }
• Restitueren: als er geen vorderingen op de betreffende klant zijn; dan kunnen vooruitbetalingen teruggestort worden.

GELDSTROOMMODEL VAN ITCIS

In dit model wijzen de pijlen in de richting waarin de waarde (het geld) stroomt. Dit in tegenstelling tot het bovenstaande “Bedrijfsproces FACTUREREN”; daar gaven de pijlen de richting aan waarin documenten zich verplaatsen (de informatiestroom). Bijvoorbeeld bij de gewone (debet) notaparagrafen. De informatie stroomt van factureren naar ontvangen notaparagrafen; maar de waarde stroomt andersom. Het ligt in de aard van factureren dat de hoofdstroom van het geld naar boven in de richting van de opbrengstenrekening gaat. Bij correcties zoals bij creditnotaparagrafen stroomt er geld omlaag; maar dit behoort niet de hoofdstroom te zijn; dunne pijlen.

     

Hier boven staat  een versimpeld overzicht van de samenhang tussen de detail-boekingsfuncties van ITCIS.  

De tekening is op het niveau van boekingsfucties en rekeningsoorten.

De boekingsfuncties worden voorgesteld door een dikke stip. 

De tekenwijze voor rekeningsoorten bestaat uit een gebogen lijn die altijd in een boekingsfunctie begint. Op die lijn staat een pijl, als deze van de boekingsfunctie afwijst dan worden rekeningen van die soort gedebiteerd, wijst die andersom dan worden ze gecrediteerd. 

• Bij een interfacerekening loopt de lijn direct naar een andere boekingsfunctie. Daar staat een pijl in dezelfde richting als de pijl naar de eerstgenoemde functie; als de één de rekeningen debiteert, dan crediteert de  ander de rekeningen en andersom.
• Bij een balansrekening loopt de lijn naar een rechthoek die het bestand voorstelt. Er kunnen meerdere pijlen naar en van de rechthoek, steeds vanuit een boekingsfunctie. Als een pijl naar de rechthoek wijst wordt de balansrekening gecrediteerd, als deze van de rechthoek afloopt dan gedebiteerd.
• Exploitatierekening wordt voorgesteld door de naam van de rekening. Een pijl vanuit een boekingsfunctie crediteert deze rekening, een pijl van de naam naar een boekingsfunctie debiteert hem.

Het teken van de pijl wordt wel eens vet en ook weleens dun afgedrukt. In de context betekent dit dat een vette pijl een omvangrijkere stroom is dan een dunne.

Boekingsgemeenschap

In het grootboek komen de rekeningen (CR-)NOTAPARAGRAFEN voor. Deze bestonden vòòr ITCIS niet, ze zijn geïntroduceerd omdat ITCIS met het concept notaparagrafen de bedrijfsfuncties factureren en notaproductie uit elkaar trok. 

Het grote voordeel hiervan is behalve de simpelere controle de ‘information hiding’ tussen beide functies: Notavervaardiging heeft weinig te maken hebben met de complexiteit van de verschillende diensten. En andersom hoeven de diensten zich weinig zorgen te maken om de nota’s.  Zij hebben na het factureren de opbrengsten ‘binnen’. Pas na een notaklacht zal de dienst ingeschakeld kunnen worden om een creditnota(paragraaf) te maken. 

Een voordeel van de detail interfacerekeningen (cr-)notaparagrafen is dat ze een interface tussen de dienst en Notavervaardiging bewaken; na de nachtelijke batchruns behoren alle interface-rekeningen geen saldo te hebben. Dit faciliteert de mogelijkheid dat de facturering van een dienst en de notavervaardiging op een andere machine of op een andere locatie draaien.

Dit is geformaliseerd in het concept boekingsgemeenschap. Dat is een verzameling boekingstaken die allen op dezelfde “eigen” rekeningen boeken; of op één zijde van een interfacerekening. 

{Ik heb het u bespaard; maar de naamgeving van boekingsfuncties kent een prefix van drie letters en die van rekeningsoorten een suffix van drie letters, beiden meestal de code van de boekingsgemeenschap. Hiermee kunnen “eigen” rekeningen en interfacerekeningen onderscheiden worden}

Soms, maar niet altijd, valt een boekingsgemeenschap samen met een of andere organisatorische eenheid.

De boekingsgemeenschappen zijn:

• Één voor het factureren van iedere dienst. Met als naam de kenmerkwaarde van die dienst.
• De boekingsgemeenschap NVS voor Notavervaardiging.
• De boekingsgemeenschap INN voor het Inningsproces. { Bij inning is het proces veelal per admiegroep georganiseerd; maar de admiegroep is geen boekingsgemeenschap.}

Dan zijn er nog twee speciale boekingsgemeenschappen.

• Een voor de journaalposten van ITCIS voor het grootboek geformuleerd in de methodiek van JOUR. De code is GRB.
• De boekingsgemeenschap ITC. Deze bevat middelen om afgekeurde journaalposten voorlopig, voor het maandelijks opleveren van de journaalposten voor het grootboek, te herstellen. De interfacerekeningen en de sluitrekeningen behoren ook bij ITC. 

Het ontwerpen van de programmatuur 

Het type  structuren nodig om zoiets als het detailrekeningstelsel met zijn kenmerken op te bouwen had ik vaker toegepast. De transacties om die structuren  concreet in te vullen lagen voor de hand. Er zijn natuurlijk ook een paar (andere) transacties voor de boekhouding nodig.

Boekingsmodule

Deze dient om detailjournaalposten te maken en te boeken. Dit was ongetwijfeld  het meest intensieve gebruikte stukje software van ITCIS (en al gauw technisch vakkundig geoptimaliseerd). 

JOUR kent een eigen autorisatie per boekingstaak.

Je kan tot 20 boekingstaken tegelijk binnen een programma openen. Je mag de boekingsposten van die taken door elkaar aanbieden. De boekingsmodule heet BOEKER en zijn paramers staan in een lijst tussen [  en ].  Ik geef steeds alleen die lijst.

• Boekingstaken, rekeningen en boekingsposten worden aangeduid met hun volledige naam. Respectievelijk boekingsfunctienaam + ingevulde kenmerken; rekeningsoortnaam + ingevulde kenmerken; boekingstaaknaam +rekeningnaam+D/C.
• Openen van boekingstaak: [OPEN,E/V,boekingstaaknaam,boekingsdatum]
• Maken van een boekingspost: [VERWERK, E/V/L, boekingstaaknaam, rekeningnaam,D/C, bedrag, aantal]

Opmerkingen:

• E/V/L staat voor eerste, volgende en laatste.
• Behalve op bedrag kan er ook geboekt worden op aantallen. Daarvan hoeven debet- en creditzijde niet gelijk te zijn.
• JOUR kent een fors aantal foutmeldingen, deze zijn allemaal fataal; de database wordt gereset. Er is wel een versie van BOEKING die voor testen gebruikt kan worden en bij fouten voor zover  mogelijk doorgaat.

Consolideren

Het oorspronkelijke doel van Journalisering was het afschermen van het complexe rekeningstelsel van PTT Telecom van de programmatuur van ITCIS. Dit werd bereikt met een verfijnder rekeningstelsel voor de journalisering van ITCIS waarbij er op (detail)rekeningen met kenmerken wordt geboekt, zoveel mogelijk geïntegreerd met de on line en batch transacties waarmee de processen worden uitgevoerd. 

Er moeten echter wel maandelijks Journaalposten door ITCIS conform de eisen van KPN worden opgeleverd. 

Het detailrekeningstelsel van ITCIS is dan ook een verfijning van dat deel van het grootboek van KPN waaraan JOUR de vereiste Journaalposten moet aanleveren. Daartoe is er een kopie van dat deel van het grootboek volgens de systematiek van JOUR, dus met kenmerken, gecreëerd. Ter onderscheid schrijf ik die kopie-versie van het grootboek met hoofdletters. De namen van boekingsfuncties en rekeningsoorten van het grootboek worden ook vaak in de detailboekingsstructuur gebruikt. Er zijn soms minder kenmerken en er worden elementen samengenomen.

Detailrekeningen of detailjournaalposten kunnen geconsolideerd worden tot een grootboekrekening of grootboekjournaalpost als de betekenis van het detailelement voldoet aan de betekenis die het grootboekelement wordt geacht te hebben. Hierbij zal vaak detail informatie verloren gaan. 

 Als voorbeeld nemen we Notavervaardiging. Notavervaardiging kent twee detail boekingsfuncties.

 

ontvangen-notaparagrafen (dst)

van buffer(dst,adm) 

van cr-notaparagrafen(dst,avk)

       aan notaparagrafen(dst,avk)

       aan cr-buffer(dst,adm)

en 

produceren-nota’s (dst,adm)

van nota’s (dst,adm)

van cr-buffer (dst, adm)

       aan cr-nota’s (dst, adm)

       aan buffer ( dst, adm )

Deze leveren samen voor het grootboek

JOURNAALPOST-NVS (dst).

Waarbij de detail rekeningsoorten notaparagrafen(dst,avk) en buffer(dst,adm)  samen de grootboek rekeningsoort NOTAPARAGAFEN(dst) vormen.

En de rekeningsoorten cr-notaparagrafen(dst,avk) en 

cr-buffer(dst,adm)  samen CR-NOTAPARAGRAFEN(dst). 

Het grootboek negeert hier dus zowel de uitsplitsing naar de aard van de klant als naar admiegroepen. Terwijl ook het onderscheid of een notaparagraaf ‘onderweg is naar Notavervaardiging’ of daar al gebufferd is, verdwijnt.

De consequentie is dat de journaalpost ontvangen-npgn(dst) geen rol speelt in het grootboek. Het grootboek kent de gebeurtenis van het ontvangen van notaparagrafen door NVS niet, een journaalpost zou slechts boekingsposten kennen die beide zijden van dezelfde rekening zouden crediteren en debiteren. Als alles goed gaat is het saldo 0.

De rekeningsoorten nota’s(dst,adm) en credit-nota’s(dst,adm) zijn beide opgenomen in DEBITEUREN(dst,adm). Merk op dat voor het resultaat in DEBITEUREN gesaldeerd wordt; zeg maar de creditnota’s verminderen het saldo aan debiteuren, maar dat het kenmerk adm gehandhaafd blijft. 

 

Dat levert ons op:

JOURNAALPOST-NVS(dst):

van CR-NOTAPARAGRAFEN(dst)

van  DEBITEUREN(dst,adm)

        aan NOTAPARAGRAFEN(dst)

        aan DEBITEUREN(dst,adm)

Het grootboek wordt natuurlijk altijd gepresenteerd met ingevulde kenmerkwaarden, en gesommeerde bedragen over een bepaalde periode. 

Als getallen-voorbeeld een ‘journaalpost’ waarmee voorbeelden A en B1+B2 (zie 3 produceren van nota’s) geconsolideerd worden:

JOURNAALPOST-NVS(tlx)                   A        B1      B2     GRB

van CR-NOTAPARAGRAFEN(tlx)       125                125     250

van  DEBITEUREN(tlx,a01)                 175                         175

van  DEBITEUREN(tlx,a02)                           300               300

         aan NOTAPARAGRAFEN(tlx)      300    300               600

        aan DEBITEUREN(tlx,a01)

        aan DEBITEUREN(tlx,a02)                               125    125

{ik heb in dit voorbeeld de bedragen van A, B1 en B2 voor het gemak ingevuld}. 

Omdat A en B1+B2 hetzelfde doen moeten ze dus ook dezelfde bijdrage aan het grootboek leveren. Voor de credit-notaparagrafen zie je tweemaal 125 en voor de notaparagrafen tweemaal 300. Op de debiteurenrekening van A staat 175 debet. En op die B1+B2 staat 300 debet en 125 credit. De saldi zijn dus beiden 175 debet.

Merk op dat bij consolideren het ‘standpunt’ van het grootboek leidend is. De betekenis van de boekingsinformatie in het journaal mag gedetaileerder zijn dan die in het grootboek, maar andersom niet! Deze extra informatie in het Journaal dient de controle op het hele proces en helpt bij het opsporen van fouten. 

De grootboekrekeningen (CR-)NOTAPARAGRAFEN zijn geen interface- maar balansrekeningen. Bijvoorbeeld van NOTAPARAGRAFEN van een bepaalde dienst moet het saldo gelijk zijn aan de som van de saldi van alle buffers van die dienst en de som van alle detailrekeningen notaparagrafen van diezelfde dienst. De controle of dat klopt is veel simpeler bij de detailrekeningen; want een eventuele afwijking is daar gelokaliseerd tot één buffer.

Discussies over het ontwerp

Er zijn over het functioneel ontwerprapport nog twee discussies gevoerd:

• Binnen het ITCIS-project verkondigde één van de engelstalige externe medewerkers dat ik er een verkeerde manier van boekhouden op na hield. Er werd een commissietje benoemd met deze medewerker, de projectleider van het databaseteam Gerard Otten, en ikzelf. Otten was het met me eens dat de klager niet bekend was met dubbelboekhouden en alleen het zogenaamde, bij de overheid voorkomende, kameralistisch boekhouden  (zoals in een kasboek) kende.
• Een managementsamenvatting is, buiten mijn aanwezigheid, besproken met de financiële hoofddirecteur van PTT. Die was enthousiast over mijn originele aanpak, en vond dat ik het moest publiceren. Bij deze.

De bouw van het systeem JOUR

Voor de bouw had ik twee goed in Unisys en Cobol ingevoerde programmeurs, tegen het einde kwam de bovengenoemde Martin Carbo daar nog bij.

 

We hebben gezamenlijk een soort technisch ontwerp gemaakt. Mijn rol was natuurlijk vooral uitleggen hoe alles bedoeld was. We werkten heel prettig samen. Maar ik herinner me ook dat we dagenlang gediscussieerd hebben over de opzet die ik in mijn hoofd had. Zij waren gewend om voor hergebruik van code, een kopie te maken en die toe te snijden op de andere situatie. Ik was gewend om veel met subroutines te doen. We zaten ondertussen in 1984! Top down systeemontwerp was al vele jaren gangbaar, maar niet in een Cobol-omgeving.

Ik herinner me dat ik het heb gehad over ballen die je beter  bij elkaar in een netje kon stoppen zodat je in veel situaties maar met één ding te maken in plaats van met tien. Uiteindelijk kon ik ze overtuigen, en maakten we goede voortgang.

 

Een crises in ITCIS

Er waren problemen met de database. Die was gebaseerd op een opgave op formulieren van de data items en hun voorkomen binnen de projecten. 

Waarschijnlijk was het probleem dat de combinatie van het bouwen van de database met het datainterface voor vertraging zorgde; het datainterface legde veel beperkingen op aan de opzet van de database.

De directeur/eigenaar Keith Greystoke van het  softwarehuis  DCE dat de projectleider voor het database-ontwerp had geleverd stelde zich verantwoordelijk voor het probleem en zou het oplossen. 

Hij belegde een vergadering met de projectleiders van alle deelprojecten en nam, in afwezigheid van KPN-management, een “openbare biecht” af over de voortgang van hun planning. Iedereen melde een heel forse vertraging, behalve JOUR. Ik zei de planning te gaan halen. Daarna kregen we een diner aangeboden; ik heb bedankt.

Daarmee had de softwarehuis-directeur zijn probleem “opgelost” door het groter te maken. Maar daarmee was het niet opgelost voor KPN. De conclusie was dat de combinatie van de facturering voor de miljoenen simpele klanten voor de particuliere markt, en de honderdduizenden complexe klanten voor de zakelijke markt te veel was.

{ik denk niet dat we met een een keuze voor de VAX van DEC dit probleem hadden gekregen. Die beschikte over een relationele database en had helemaal geen datainterfase nodig}.

KPN besloot te kiezen voor incasso van de zakelijke markt, en TICO (vooral de consumentenmarkt) voorlopig in stand te houden, waarmee het ambitieniveau voor ITCIS weer  verder verkleind werd.

Medewerkers van het softwarehuis DCE, met name de goed in Unisys ingevoerde Fred Ras, kregen een grote rol bij de opzet van het technisch ontwerp en de bouw. In het Technisch Ontwerp moest de te bouwen functionaliteit uitvoerig gespecificeerd worden; heel degelijk, maar het kostte ook veel tijd. Voor JOUR waren we dat stadium gelukkig al voorbij.

Nadat geconstateerd was, dat mijn standpunt dat JOUR zijn planning zou halen reëel was, werd ik van JOUR gehaald en gevraagd projectleider van EFBT te worden ( zie Deel II ).

 

De kwaliteiten van JOUR.

1. De notatiewijze van JOUR met boekingsfuncties en rekeningsoorten met kenmerken en kenmerkwaarden is heel geschikt voor de menselijke lezer.
2. Door het invoeren van een detailrekeningschema met interfacerekeningen en balansrekeningen per afzonderlijk bestand, kon het boeken van de detailjournaalposten in hoge mate geautomatiseerd worden. Terwijl de grootboek journaalposten hier automatisch uit afgeleid kunnen worden.
3. Het detailrekeningschema faciliteert de controle op de boekende bedrijfsprocessen. Na de nachtelijke batch mogen interfacerekeningen geen saldo hebben; anders zijn er achterstanden bij de ontvangende partij, en het saldo van een balansrekening moet gelijk zijn aan het totaal van het bijbehorende bestand. De controles zijn geautomatiseerd, maar bij fouten levert dit veel uitzoekwerk. Fouten ontstaan vooral bij proceswijzigingen.
4. Bij mijn weten is JOUR het enige deelsysteem van ITCIS dat expliciete personeelsbezuinigingen heeft opgeleverd. Die waren er omdat het journaliseren voor het grootste gedeelte geautomatiseerd werd. (JOUR was een mooi systeem; maar ‘niemand’ zag het). Daarmee is natuurlijk niet gezegd dat het invoeren van ITCIS geen andere grote voordelen voor KPN heeft gehad. De kwaliteit van het proces en de geproduceerde nota’s werden natuurlijk veel beter. De zakelijke en vooral de grootzakelijke klant kregen een veel meer op hun behoefte toegespitste nota.

De conversie voor ELAND (Eenduidig LANDelijk).

Bij de grote organisatorische wijzigingen van het project ELAND uit 1992, waarbij de verkooporganisatie overging van 13 districten (met 37 administratiegroepen) naar 32 regio’s. Als een klant iets kocht buiten zijn eigen regio, zou de verkopende regio toch direct kunnen factureren. Voor de grote landelijke klanten werd een landelijke totaalnota gerealiseerd.

De regio’s werden resultaatverantwoordelijk, de rol van de districten werd ondersteunend voor de regio’s. De boekhoudafdeling bleef bij het district.

Iedere regio zou een admiegroep worden en dus zijn eigen rekeningen namens de regiomanager versturen. De landelijke totaalnota zou verstuurd worden vanuit een speciale regio in Groningen (eigenlijk was dat meer een admiegroep want de verantwoordelijkheid lag bij de regio van de hoofdvestiging van het bedrijf dat de nota’s ontving).

Nu vielen de grenzen van de bestaande admiegroepen niet samen met de beoogde indeling in regio’s dus van te voren werd uitgezocht welke klanten, beter gezegd welke klantgegevens, van het ene naar het andere bestand (in een andere admiegroep) moesten worden verplaatst.

Dit betekende een grote complexe conversie. Normaal draaide ITCIS op één Unisys computer, tijdens de conversie waren er drie ingezet. De I&AT (zo heette de automatiseringsafdeling inmiddels) zorgde in Groningen voor hotelaccommodatie, kantoorruimte, catering en verbindingen. In ELAND speelde JOUR een belangrijke rol als controller.

Nadat de bestanden geconverteerd waren naar de nieuwe situatie kwam JOUR aan de beurt. De opzet van JOUR werd gecreëerd met alle rekeningen met saldo 0. Vervolgens werden het totaal van alle financiële bestanden bepaald, en kreeg de bijbehorende bestandsrekening het saldo passend bij de nieuwe situatie. Alle interface-rekeningen en exploiatierekeningen hielden het saldo 0. (Het bepalen van de jaarlijkse eindsaldi van de exploitatierekeningen 

zou aan het eind van het jaar door de boekhouding vastgesteld worden. Het saldo 0 op de interfacerekeningen was terecht want de interfaces waren tijdens de conversie niet gebruikt.)

Vervolgens begon het controleren. Dit gebeurde o.a door de beheerder van JOUR. Om een voorbeeld te geven: tijdens de conversie kon er aan de administratie van de dubieuze  debiteuren niets gewijzigd zijn; dus zou het totaal over alle admiegroepen van de rekeningen dub.deb(dst,adm) per tcd voor en na de conversie gelijk moeten zijn. En dat gold uiteraard voor iedere balansrekeningsoort. Dit kon per district want de bestanden van NVS en INN van de speciale regio/admiegroep voor de landelijke nota waren op dat moment nog leeg. Er werden pas na de conversie landelijke nota’s aangemaakt.

De conversie van de bestanden liep van vrijdag tot zaterdag. Zondag werden de correcties in het detailjournaal vanwege de geografische herindeling gecontroleerd. Er werden geen fouten geconstateerd dit leidde zondagavond al tot de conclusie dat er een volledige en betrouwbare dataconversie had plaatsgevonden. 

JOUR gaf de business een beeld van geld en waarden voor en na de conversie. Er werd een kleine miljard gulden herschikt!

Einde van Deel I

Hiermee zijn we gekomen aan het eind van Deel I over ITCIS. In Deel II wordt EFBT behandeld en een externe evaluatie van ITCIS, en een meer persoonlijke evaluatie van de methode van ontwikkelen van ITCIS gegeven.

 

Voor Deel I heb ik met een aantal personen contact gehad. Waarvoor dank. Alleen ik ben echter verantwoordelijk voor onjuistheden. Ik vermeld: Martin Carbo, Rob van Vliet, Henk Boleij, Gerard Otten, Fred Borensztajn, Fred Ras.