EEN INTEGRAAL SYSTEEM Deel II

EEN INTEGRAAL SYSTEEM deel II 

Inleiding

In 1980 ben ik in dienst gekomen bij het Directoraat Telecom van de PTT. Ik was voorbestemd om ontwerper te worden van de opvolger voor het oude Telecom InCassO systeem (TICO). Al spoedig werden die werkzaamheden onderdeel van een Informatie-analyse voor een mega-infomatiesysteem ITCIS (Integraal Telecom Cliënten InformatieSysteem) dat alle klantprocessen zou moeten ondersteunen. Aan die analyse heb ik meegewerkt tot medio ‘82. Daarna heb ik enkele maanden doorgebracht bij het project Automatische Facturering Huisautomaten(AFH). Daar probeerde ik met de projectleider samen de enorme brei die op zijn bordje lag te structureren door voorstellen voor twee deelprojecten te bedenken: Journalisering (JOUR) waarmee alle journaalposten voor ITCIS geboekt konden worden. En Eenvoudige Facturering Bedrijfstelecommunicatie (EFBT), om de in hoog tempo opkomende nieuwe diensten te kunnen gaan incasseren.

Er werd besloten voor ITCIS te beginnen met incasso. AFH ging verder onder de nieuwe naam BedrijfsTeleFonie. Ik ging JOUR doen tot ergens in ‘84, daarna EFBT tot ‘87.

deel I gaat vooral over JOUR met een uitloper over de functie van dat systeem bij de grote reorganisatie van Telecom van 13 districten naar 32 regio’s in 1992.

In deel II behandel ik EFBT.  En daarna twee evaluaties van ITCIS: 

• één door een commissie in 1987 in het kader van de verzelfstandiging van PTT  op 1 jan 1989.
• mijn persoonlijke evaluatie als iemand die zeven jaar aan de ontwikkeling van ITCIS heeft meegewerkt. 

De beschrijving van EFBT is nogal uitgebreid. Er wordt in de tekst een leesaanwijzing gegeven om desgewenst enkele meer technische paragrafen over te slaan.

{De fles wijn die voorkomt op de foto’s voor beide delen, kreeg ik in 1989 van Peter van Delft, de laatste projectleider van ITCIS. Ik heb hem in 2024 opengemaakt en voorzichtig geproefd. Hij smaakte nog naar wijn; net als ITCIS was hij niet verzuurd, maar ‘over de datum’}

Eenvoudige facturering BedrijfTelecommunicatie

Er lag een geaccordeerd projectvoorstel voor EFBT en ik werd aangezocht als projectleider. In mijn tijd bij AFH had ik al aan een datamodel voor EFBT gewerkt.

Rob Loos was projectleider van de gebruikers. Enige tijd nadat Rob van Vliet de Definitiestudie van Bedrijfstelefonie had afgerond kwam hij ook bij EFBT; hij was mijn projectleider geweest en nu was ik de zijne. De onvolprezen Henk van der Ploeg was inmiddels al weer een tijdje projectleider van alle ITCIS gebruikers. {Hij onderhield behalve met de gebruikers ook goede contacten met de automatiseerders, en zorgde daardoor vaak voor afstemming tussen de eisen van de ene partij en de mogelijkheden van de andere}

Helaas beschik ik niet meer over mijn eigen functioneel ontwerp, en put daarom deels uit mijn geheugen, wel beschik ik nog over documentatie uit 1995. Deze is op zich prima, maar bevat vooral praktische informatie voor de productie, terwijl mijn globalere ontwerp diende om te overtuigen dat het concept tot een bruikbaar systeem zou leiden. {Het heeft later de status Definitie-Studie gekregen; hoewel het gebruikt is voor Technisch Ontwerp}

Doelstelling en globale Functionaliteit

EFBT staat voor Eenvoudige Facturering Bijzondere Telecommunicatie. {“bijzonder” betekent hier “niet zijnde telefonie”}. Uitgaande van de veronderstelling dat de naam de inhoud redelijk dekt roept dit de volgende vragen op:

• Wat wordt verstaan onder factureren?
• Welke te factureren diensten omvat bijzondere telecommunicatie?
• Welke produkten worden in het kader van die diensten geleverd?
• Wat is, gezien de funktionaliteit die uit de eerste drie punten volgt, de betekenis van "eenvoudig"?

Wat verstaan wij onder factureren?

In strikte zin betekent binnen ITCIS het factureren van iets, het berekenen van de kosten en het doorgeven van die informatie aan Notavervaardiging. 

Het factureringsproces van EFBT omvat:

• Het vastleggen van opdrachten in orders.
• Het factureren van uitgevoerde orders.
• Het onderhouden van een registratie van geleverde voorzieningen op basis van de uitgevoerde orders ten behoeve van de periodieke facturering.
• Het periodiek factureren van voorzieningen waarvoor huur en/of service in rekening wordt gebracht.
• Het factureren van het gebruik van de infrastructuur.
• Het factureren van incidentele kosten.

Na het factureren moeten de baten verbijzonderd worden, en een nota geproduceerd en geïnd worden. Die functionaliteit wordt geleverd door de ITCIS-deelsystemen Journaliseren, Notavervaardiging en Inning.

Om de nota's te kunnen produceren en versturen zijn klantgegevens nodig. Deze funktionaliteit wordt geleverd door het deelsysteem Klantenregistratie.

De betalingen worden  verwerkt, en de vorderingen worden bewaakt  door het deelsysteem Inning. Dit gehele traject staat beschreven in Een Integraal Systeem deel I.

Diensten van Bijzondere Telecommunicatie 

EFBT is in eerste instantie opgezet voor 4 diensten:

Autotelefonie, Semafonie, Telex en de landelijke dienst Datanet. Hierbij  heeft nadrukkelijk het idee meegespeeld dat EFBT  geschikt zou moeten zijn, om ook andere, zowel reeds bestaande, als nog te ontwikkelen diensten te factureren.

Dit betekent dat er bij het gehele ontwerp steeds naar gestreefd is om concepten zo te generaliseren dat zij een algemene geldigheid krijgen. Om een voorbeeld te noemen: Autotelefonie, Datanet en Telex kennen alle drie een openbaar telecommuncatie-net waarmee verbindingen tot stand gebracht kunnen worden.

Hieruit is ontwikkeld het concept 'verbruiksnet' dat beperkt is tot de voor de facturering en notavervaardiging essentiële aspecten van dergelijke netten: de nummering van de aansluitingen en het verbruik.

Binnen het kader van een verbruiksnet kan het verbruik voor Autotelefoon, Datanet, en Telex getarifeerd worden. 

Uit welke producten bestaan deze diensten?

De producten van deze diensten kunnen zijn:

• Apparatuur,
• Rechten:  zoals de toegang tot de infrastructuur,
• Het gemeten gebruik van de infrastructuur,
• Het tot stand brengen van niet-openbare verbindingen zoals huurlijnen.

 Apparatuur en Rechten

 Vanuit technisch oogpunt is het verschil tussen de eerste twee categorieen apparatuur en rechten, enorm. Voor de facturering is er echter geen wezenlijk verschil tussen beiden. EFBT heeft beiden ondergebracht in dezelfde categorie voorziening.

Indien we van een voorziening de prijs kunnen bepalen, weten hoeveel er geleverd zijn, hoe de voorziening op de nota gespecificeerd en hoe de opbrengst geboekt moet worden, dan weten we voor de facturering genoeg.

Vaak zijn voorzieningen niet individueel bekend en en zit een aantal exemplaren van hetzelfde type bij elkaar in een AGV (aantal geleverde voorzieningen)

 

Verbruiksnet 

 Het factureren van het verbruik op de openbare schakelnetten, heeft een nauwe relatie met de techniek, die we niet in die mate kunnen vermijden dat het verbruik zonder meer als voorziening ondergebracht zou kunnen worden.

Ten eerste wordt het gemeten verbruik vanuit de techniek aangeleverd gekoppeld aan een verbruiksnummer. Vervolgens vereist een goede specificatie op de nota dat het, bij de klant bekende, nummer vermeld wordt.

Tenslotte waren deze nummers, althans in die tijd, niet aan de klant gebonden, maar werden ze vanuit de techniek bepaald, waardoor ze zowel individueel als collectief omgenummerd kunnen worden.

Hiertoe is het al eerder genoemde verbruiksnet ingevoerd dat bestaat uit een verzameling 'verbruiksnummers' die een losvaste relatie met een klant hebben. 

Deze heeft een aansluiting op het betreffende net waar het verbruiksnummer bijhoort. Als de tellerstanden opgenomen zijn, dan resulteert dat in een verbruiksticket (een record met het aantal verbruikte impulsen sinds de laatste telleropname).

Huurverbindingen

Ook deze laten zich niet simpel terugbrengen tot voorzieningen omdat het vaak gewenst is om op de nota te vermelden wie aan de andere kant van de verbinding zit. Dit betekent dat voor dergelijke huurverbindingen relaties tussen klanten geregistreerd moeten kunnen worden.

Bovendien zijn dit type verbindingen niet beperkt tot tweepuntsverbindingen.  In Datanet en in Semafonie komen huurverbindingen voor met groepsdeelname.  Een dergelijke groepsverbinding behoeft dan een eigen identificatie, die veelal ook door de gebruikers van de huurverbinding gehanteerd zal worden; deze wordt dan op de nota vermeld. Er is één klant die kontraktant is van een bepaald type huurverbinding, en er zijn twee of meer klanten die een aansluitpunt hebben op die huurverbinding. Een van hen kan de kontraktant van die huurverbinding zijn.

Met deze drie categorieen:  voorzieningen, het gebruik van openbare telecommunicatienetten, en het leveren van huurverbindingen kunnen we alle diensten aan die in het kader van de eerste drie lagen van het OSI-model geleverd worden aan. (OSI staat voor Open ended System Integration; de eerste drie lagen bevatten een standaard voor het volledig verzorgen van de overdracht van pakketten informatie). 

Hierbij moeten we het voorbehoud maken dat de beschikbaarstelling  voor een dergelijke dienst gebruik maakt van de prijscalculatieregels die EFBT daarvoor biedt. 

Wat is de betekenis van "eenvoudig"?

In het voorafgaande hebben we gezien dat EFBT een systeem is dat, met ondersteuning van andere ITCIS-deelsystemen, de incasso moet kunnen verzorgen van huidige en toekomstige diensten die in het kader Bedrijfstelecommunicatie geleverd (gaan) worden. 

De in het kader van de diensten geleverde produkten, kunnen worden teruggebracht tot: voorzieningen (apparatuur en rechten), het gebruik van openbare telcommunicatienetten, en het leveren van huurverbindingen. 

Het zal duidelijk zijn dat een dergelijk systeem niet eenvoudig kan zijn in de zin dat het een klein gegevensmodel en een heel beperkte funktionaliteit heeft; het zal noodzakelijkerwijs een vrij omvangrijk systeem zijn.

 

EFBT is een generiek systeem: dat wil zeggen geschikt voor meerdere diensten, dankzij de onafhankelijkheid tussen diensten en functionaliteit.

Noch in de programmatuur van EFBT, noch in het Gegevensmodel komt een verwijzing naar één van de in EFBT ingevoerde  diensten voor.  

De term "autotelefoon" zal men dus in geen enkel programma tegenkomen, en er is geen enkel recordtype dat speciaal voor de dienst Autotelefonie gereserveerd is. De term “autotelefoon” komt alleen voor als ingevulde waarde van bepaalde eigenschappen. 

De konsekwentie hiervan is dat er voor geen enkele dienst een uitzondering gemaakt is, of kan worden. Er zijn algemene funkties en algemene gegevenstypen die door elke dienst gebruikt kunnen worden. Daardoor kun je er ook nieuwe diensten mee implementeren: je hoeft ‘alleen maar’ tabellen aan te vullen. 

{Hoewel bedoeld voor diensten uit de zakelijke markt die  geen gewone telefonie zijn, brengt de generieke opzet van EFBT met zich mee dat je er ook telefonie mee zou kunnen factureren. En dat kan natuurlijk ook voor particuliere klanten. Achteraf betreur ik het daarom dat we het predikaat Eenvoudig in de naam van het systeem opgenomen hebben; het suggereerde ten onrechte dat het systeem simpel was}

 Ingebouwde ontsnappingsmogelijkheden

De onafhankelijkheid tussen funkionaliteit en de diensten levert een strak keurslijf waar binnen diensten geperst dreigen te worden.

Om dit dragelijk te maken heeft EFBT een aantal ontsnappingsmogelijkheden ingebouwd. 

• Er wordt ruimschoots gebruik gemaakt van de mogelijkheden om zaken uit het “gemeenschappelijke keurslijf” te presenteren met een voor iedere dienst specifieke naam.
• Aangezien het  om een factureringssysteem gaat zijn er ook vrijheden  in de calculatiesfeer. Er zijn verschillende soorten kontrakten en prijsalgoritmen mogelijk. 
• Bovendien bestaat de mogelijkheid om iedere prijsstelling te overrulen door een prijs direkt aan het systeem op te geven.  

Concepten en Begrippen van EFBT

 In het bovenstaande is de doelstelling en aanpak van EFBT ruw geschetst.  Hieronder volgt het centrale begrippenkader waar EFBT omheen gebouwd is. Je krijgt een niet al te gedetailleerde samenvatting van het conceptuele datamodel tezamen met de bijbehorende  functionaliteit.

Er zijn vijf deelmodellen: de eerste twee beschrijven de operationele situatie van een dienst bij afnemers.

• Het pakketmodel. De afgenomen voorzieningen van een dienst bij de klant.
• Het ordermodel. Mutaties op die voorzieningen bij een klant.

De volgende drie vormen samen de meta-structuur. Deze bepalen hoe voor een bepaalde dienst de pakketten en orders er uit kunnen zien.

• Het netmodel. beschrijft de verbruiksnetten waarop diensten een aankiesbare aansluiting kunnen hebben.
• Het prijsmodel. Dit is een lijst van alle producten die een klant van een dienst kan afnemen. Inclusief de handelingen om deze te muteren.
• Het dienstmodel. Dit beschrijft hoe een pakket van een dienst opgebouwd kan zijn.

Bij alle modellen vertel ik iets over de bijbehorende functionaliteit.

Belangrijk bij het dienstmodel is de procedure om EFBT met een nieuwe dienst uit te breiden.

BESCHRIJVING VAN HET GLOBALE MODEL VAN EFBT

1 Registratie van geleverde Voorzieningen 

Pakketmodel

Het aangrijpingspunt voor de registratie van de voorzieningen bij één klant van één dienst op één vestiging geadministreerd door één tfd is het pakket.

Het pakket zelf wordt gebruikt om algemene klantgegevens ten behoeve van de dienst vast te leggen. De eigenlijke voorzieningen-registratie gebeurt bij  de deelpakketten van het pakket. 

 

Voorbeelden

Een klant heeft op een vestiging een telex-pakket en een autotelefoon-pakket. 

Bij het pakket zijn administratieve klantgegevens in verband met de dienst geregistreerd.  We noemen:  het dossiernummer, datum in dienststelling vh pakket, naam kontaktpersoon bij de klant en de laatste maand waarover gefaktureerd is. 

 Pakket en Klantgegevens

Het hoogste niveau in de registratie van een klant in EFBT, het pakket zweeft niet los in het gegevensmodel maar is gekoppeld aan vestiging (NAW-gegevens van  het adres waarop het pakket zich bevindt) van een kontraktant (NAW-gegevens met de naam en het adres van  de rechthebbende). Kontraktant en vestiging zijn begrippen uit de Centrale Klantregistratie  van ITCIS. 

Een notabundel is de linking pin tussen de (periodieke) nota’s door de tijd heen voor één klant en één dienst in één district. Het bevat of verwijst naar gegevens waarmee notabijdragen door Notavervaardiging kunnen worden gebundeld tot een nota die verstuurd kan worden naar de klant, en waarmee Inning de betaling van diens nota’s kan bewaken. Ook Notavervaardiging en Inning zijn deelsystemen van ITCIS.

Deelpakket

De eigenlijke registratie van producten gebeurt bij de deelpakketten. Een pakket heeft minimaal twee deelpakketten; één waarmee de essentie van de dienst geleverd wordt, en één voor de randapparatuur. 

Er zijn twee soorten deelpakketten: 

1. Deelpakketten die zelf “niets” zijn en louter fungeren als containers voor één of meer AGV’s. (Aantal Geleverde Voorzieningen van hetzelfde type)
2. Deelpakketten die zelf een bepaalde functionaliteit leveren, bijvoorbeeld een huurverbinding of een aansluiting op een kiesverbinding. Deze deelpakketten hebben een intrinsieke voorziening die deze functionaliteit levert. 

Vooral in de huurverbindingen zit een grote variatie. Niet alleen gaat het om verschillende technieken, zoals huurlijnen of Besloten Gebruikers groepen van Datanet. Maar ook binnen de huurlijnen is er variatie bijvoorbeeld de lengteklasse, de kwaliteit van de lijn, één of tweedraads.  Er is een type deelpakket, met een intrinsieke voorziening zoals een huurlijn, of een BGG-Datanet die de essentie van de dienst regelt. 

En er is een mechanisme om binnen het type deelpakket die variatie te regelen. Dit werkt met eigenschappen met namen die afhankelijk van dat type gekozen zijn, en met waarden die bij een eigenschap van die naam bij dat type voorkomen. 

De intrinsieke voorziening bij een huurlijn bijvoorbeeld wordt mede bepaald door de volgende eigenschappen:

•  De lengteklasse van de huurlijn,
•  Twee- of vierdraads,
•  De kwaliteitsklasse.

De metastructuur bevat een mechanisme het basisabonnement waarmee voor de huurlijn op grond van waarden voor deze eigenschappen de juiste voorziening wordt gevonden. Deze voorziening levert dan het zogenaamde basisabonnement van dat deelpakket.

Dit mechanisme wordt voor deelpakketten met een intrinsieke voorziening veelvuldig gebruikt. Het mechanisme staat uitgebreid beschreven in het dienstmodel.

Er zijn ook andere type deelpakket afhankelijke eigenschappen zoals een technische identificatie of een lijnbenaming. 

Er is geen harde koppeling tussen type pakket en type deelpakket. Bij een pakket voor een bepaalde dienst kan daardoor een deelpakket horen dat de essentie van een andere dienst levert.

Een aansluitpunt zelf is vaak een stukje techniek, maar ook rechten spelen een rol. Want de kontraktant van de huurverbinding kan een andere zijn dan de gebruiker ervan.  Dat werkt vaak door in de prijsstelling van de bijbehorende aansluitpunten en het basisabonnement van de huurverbinding.

Twee telex-pakketten verbonden door een huurlijn, deze loopt van het aansluitpunt bij pakket A naar dat van B via relaties 1. Relatie 2, de aansluitrelatie verbindt de aansluitpunten van A en B met hun randapparatuur. De huurlijn hoort bij A.

Hieronder een deelpakket voor een telex aansluiting, verbruiksnummer, teller en verbruiksticket.

 

De verbinding tussen deelpakket en net loopt via het verbruiksnummer. Daarmee zijn ook de tellers verbonden.  Het deelpakket heeft een basisabonnement.

                                    LEESAANWIJZING                                    

Je zou hierna de wat technische paragrafen:

 2 Ordermodel,

 3 Netten, 

 4 Prijscalculatie, en

 5 Dienstmodel,

voorlopig, over kunnen slaan, en deze desgewenst later lezen. 

En nu verdergaan bij de paragraaf Procedure inpassen van een Dienst, de laatste paragraaf specifiek over EFBT, voor de Evaluaties.

                                                                                                 

 

 

  2 Ordermodel

 Order

 Het begrip "order" zoals in EFBT gehanteerd, is een klantorder waarbij het initiatief van de klant komt. Dit is nadrukkelijk iets anders dan een werkorder waarbij het initiatief uit het bedrijf komt, bijvoorbeeld omdat er een klantorder  is geweest. Een EFBT-order is soms afgeleid uit een aanvraagformulier voor een dienst, wat natuurlijk ook een soort klantorder is.

 

Er is een zekere symmetrie tussen de statische registratie van de voorzieningen in een structuur van een pakket  met deelpakketten en de dynamische registratie van orders met deelorders (voor deelpakketten). 

Een verschil is dat een pakket gekoppeld is aan de kontraktant, de notabundel en de vestiging; terwijl order op zijn beurt gekoppeld is aan pakket. Aan een pakket kunnen meerdere orders hangen

Het feit dat een order altijd hangt aan een pakket roept natuurlijk de vraag op waar de order voor een nieuw pakket dan aan hangt.  Het antwoord is dat tijdens het invoeren van een order voor een nieuw pakket, onmiddellijk een pakket wordt gecreëerd met 'status' "in aanleg".  Dit pakket wordt gebruikt om de link naar Kontraktant, Notabundel en Vestiging vast te leggen en om de order aan op te hangen. 

 

 De rol van het orderproces in EFBT is groot:  alle wijzigingen aan pakketten, gaan met behulp van orders; er is dus in EFBT niet zoiets als een proces administratieve wijzigingen waarmee bijvoorbeeld de naam van de kontaktpersoon bij de klant gemuteerd kan worden.  

Een konsekwentie daarvan is uiteraard dat het afhandelen van een order niet altijd tot een rekening hoeft te leiden.  Voor een dergelijke administratieve wijziging wordt op de normale wijze een order gemaakt en definitief verklaard. 

Daarnaast kunnen orders ook als correctie definitief verklaard worden, met deze hoog geautoriseerde transactie worden de mutaties aangebracht zonder dat er een rekening wordt gemaakt.  Deze transactie is vooral nuttig bij conversie en bij schouwen (kijken of de administratie de werkelijkheid goed weergeeft). 

Met behulp van de entiteit 'order' wordt de entiteit ‘pakket’ gemuteerd.  Dit komt tot uitdrukking in de administratieve gegevens die bij order behoren, deze vallen uiteen in twee groepen: 

1. ordergegevens die gelijk zijn aan pakketgegevens zoals  dossiernummer, naam-kontaktpersoon ect, en 
2. gegevens die typisch behoren bij de orderadministratie zoals type-werk   (nieuwe aanleg, sloop of wijzigen), datum-offerte-order, datum-referte-klant order etc. 

 Bij het afhandelen van de order wordt het pakket gemuteerd met die pakketgegevens (1) uit de order.  Er is een enkel gegeven uit pakket dat niet ook ordergegeven is:  bijvoorbeeld datum-in-dienstelling-pakket.

Dit wordt gemuteerd aan de hand van het ordergegeven datum-uitvoering-order. 

Aangezien ook dit eigenlijk een andere rol van hetzelfde gegeven is, zou men kunnen stellen dat een order naast gegevens voor de orderadministratie een complete -nieuwe- versie van de pakketgegevens bevat, die bij het afhandelen 

van de order in het pakket worden gezet. 

 Deelorders

 De overeenkomst tussen pakket en order blijkt wanneer we zien dat een order opgebouwd is uit deelorders, waarbij elke deelorder betrekking heeft op EEN deelpakket.

Voor het deelpakket geldt op vergelijkbare wijze als pakket dat bij het invoeren van een deelorder voor een nieuw deelpakket, het deelpakket onmiddellijk met 'status' "in aanleg" wordt gecreëerd. Ook voor de deelorder geldt dat deze naast order-administratieve gegevens een -nieuwe- kopie van de deelpakketgegevens bevat die bij het afhandelen in het deelpakket worden gezet.  

Van de gegevens van de deelorder die typisch tot de orderadministratie behoren noemen we type-werk (nieuwe aanleg, sloop of wijzigen), dat ook bij de order zelf voorkomt.  Uiteraard zijn daarbij bepaalde combinaties verboden.  Bijvoorbeeld een order met type-werk "sloop", en een deelorder met type-werk "nieuwe aanleg" mag niet.

              

Identificatie van order en deelorder

 Een order wordt geidentificeerd door het pakket waar de order bij  behoort en een volgnummer binnen dat pakket.  De totale identificatie van een order is dus:  code van de dienst, pakketnummer (binnen de dienst), en volgnummer order(binnen het pakket).  Een deelorder wordt geïdentificeerd door de order waartoe deze behoort en de identificatie van het deelpakket waar de deelorder betrekking op heeft.  

De totale identificatie van een deelorder is dus:  code dienst, pakketnummer, en volgnummer order (deze identificeren  de order) en type deelpakket en volgnummer deelpakket (identificeren tesamen het deelpakket).

 

 Deelorder en Handeling

 De rol die in het pakketgebeuren gespeeld wordt door voorziening wordt bij de orders ingenomen door 'handeling'. Een handeling is een combinatie van een voorziening en een 'activiteit'.  Bij activiteit denke men aan de beperkte groep

 operaties die Telecommunicatie met de voorzieningen uitvoert zoals: "aanleggen", "slopen", "plaatsen".  

Het effekt in EFBT van een handeling is in principe tweeledig:  er worden -eenmalige- kosten voor het uitvoeren van de handeling in rekening gebracht, en de voorziening wordt geregistreerd bij het betreffende deelpakket.  

Merk op dat niet altijd beide effecten relevant zijn.  Bij echte verkoop bijvoorbeeld is registratie van de voorziening overbodig, en bij echte verhuur worden geen eenmalige kosten in rekening gebracht. Daarnaast bestaan ook handelingen zoals "voorrijkosten" waarbij in het geheel geen voorziening te pas komt. Dergelijke handelingen noemt men 'autonome handelingen'; daarbij wordt dus geen voorziening geregistreerd.  

Echte verkoop, waarbij ook geen voorziening bij deelpakket geregistreerd wordt, is geen autonome handeling!  Er komt wel degelijk een voorziening aan te pas, en deze bepaalt zelfs de eenmalige kosten; de voorziening wordt alleen niet geregistreerd.  (indien bij verkoop een servicekontrakt wordt gesloten, dan zou de voorziening alsnog  geregistreerd moeten worden).  

De registratie van handelingen van dezelfde soort operatie op hetzelfde type voorziening bij een deelorder gebeurt met 'aantal-uitgevoerde-handelingen', afgekort tot AUH. 

 In het algemeen zullen er bij een deelorder meerdere AUH's 

 zijn.  Merk op dat in EFBT ook handelingen niet individueel bekend zijn, slechts het aantal gelijksoortigen binnen een AUH van een deelorder is bekend.  

Voorbeelden

 Deelorder voor het aanbrengen van een deelpakket Telex-randapparatuur.  Met als AUH's de aanleg van een TS 12, de aanleg van een TS32, en het leveren van twee batterij-eenheden.

 

 Deelorder en basisabonnement

 Het basisabonnement wordt in de deelorder bepaald aan de hand van de waarden van de betreffende type-eigenschappen. Bij afhandeling van de deelorder krijgt het deelpakket deze waarden. En daarmee de bij die waarden behorende intrinsieke voorziening. 

 

 Deelorder en verbruiksnummer

Zoals in het bovenstaande verteld is, wordt bij het invoeren van een deelorder met type-werk "nieuw aanleg" tegelijkertijd een leeg deelpakket gemaakt. Indien het betreffende type deelpakket aan een net gekoppeld is dan zal dus ook het verbruiksnummer opgegeven worden.  Dit wordt dan aan het deelpakket bevestigd (tijdens het invoeren van de deelorder), met status "gereserveerd".  Het kan niet opnieuw uitgegeven worden.  Verbruik binnenkomend op zo'n gereserveerd nummer wordt gesignaleerd.  

Bij het definitief verklaren van de order krijgt het verbruiksnummer de status "in gebruik". Ook omnummeringen worden met de deelorder aan het systeem bekend gemaakt, deze worden echter pas bij het definitief maken geëffectueerd. 

Op de deelorder kunnen tellerstanden worden opgegeven; dit is met name van belang bij nieuwe aanleg, omnummering en sloop. In geval van omnummering en/of sloop wordt het 'oude' verbruiksnummer ontkoppeld van het deelpakket.  

 

 Deelorder en Technische Identificatie. 

 Indien bij het type deelpakket een technische identificatie 

 behoort, dan wordt dit met een deelorder opgegeven. Het zoekpad is pas beschikbaar nadat de order definitief is verklaard.  

 Aansluitpuntorder

 Deze heeft een verbindingsrelatie met een deelorder op het verbindingsdeelpakket, en een aansluitrelatie met het aansluitingsdeelpakket.

Het type aansluitpunt moet passen bij het type verbindingsdeelpakket.

       

 Verkorte invoer van orders

 Hoewel alle mutaties aan pakketten gaan met complete orders, is het   bijvoorbeeld voor het toevoegen van een voorziening aan een bestaand deelpakket niet nodig om de order en de deelorder in te tikken.  Er is een hoog geautoriseerde transactie "muteren AUH", die indien het pakket en het deelpakket bestaat zelf de order en de deelorder maakt.  Binnen dezelfde transactie kan het geheel definitief verklaard worden, waarmee de mutatie tot stand is gekomen (of de komende nacht in de batch gerealiseerd wordt). Gebruikt bij conversies en schouwen (controleren of de administratie de werkelijkheid goed weergeeft)

 

Manipuleren met orders

 Op een ingevoerde voorlopige order kunnen de volgende bewerkingen worden uitgevoerd: 

•  Controleren. Dit is het nagaan of deze order definitief verklaard zou worden.  Het is helaas niet het controleren of het aantal vermelde handelingen klopt met de verrichte handelingen, maar het controleren of er geen strijdigheden ontstaan zoals het verwijderen van niet aanwezige voorzieningen. Het resultaat is een controleverslag.
•  Calculeren: Dit omvat altijd controleren, en behelst het uitvoeren van de prijsberekeningen.  Het resultaat is een calculatieverslag. Er wordt echter geen nota geproduceerd. 
• Definitief verklaren: Dit omvat controleren en calculeren en daarnaast het muteren. Er wordt informatie voor de nota en de boeking aangeleverd. Na het definitief verklaren wordt een orderverslag geproduceerd, de order wordt op tape gezet en uit het systeem verwijderd.
• Als correctie definitief verklaren: Dit omvat controleren en het muteren.  Er wordt geen informatie voor de nota en de boeking aangeleverd.  Na het definitief verklaren wordt een orderverslag geproduceerd, de order wordt op tape gezet en uit het systeem verwijderd. 

3 Netten

Het belangrijkste produkt van de meeste binnen EFBT geregistreerde diensten is  de aansluiting op een openbaar telecommunicatienet.  Voor telex is dat het openbare telexnet, voor Datanet het datanet en voor autotelefonie het autotelefoonnet.  Dit produkt is zo belangrijk dat het onderscheid tussen dienst en net vaak niet gemaakt wordt.  

 Er is uiteraard wel een onderscheid:  zo kan je telex-apparatuur kopen en deze verbinden met een huurlijn, zonder op het openbare telexnet aangesloten wordt.  Bovendien kent Telecom een dienst Teletex die een relatie heeft met twee netten:  het telexnet en het datanet.

EFBT beperkt zich tot: de eenmalige en periodieke kosten voor de toegang tot het  net, en de kosten voor het verbruik. 

Voor het laden van de verbruikte impulsen vanuit de centrale, en voor een specificatie van de kosten daarvan op de nota moet EFBT de verbruiksnummers registreren.

 Voor het onderbrengen van de verschillende typen telecommunicatienetten is het concept "verbruiksnet", of kortweg "net" ingevoerd.  Een verbruiksnet is een verzameling verbruiksnummers die ieder geen, een, twee of drie tellers 

(afhankelijk van het type net) hebben.  

Verbruiksnummers hebben een status-gebruik die vijf waarden kan hebben: 

in gebruik, vrij, gereserveerd, besproken, in gebruik en testnummer.

Na het periodieke verwerken van de uit de centrale aangeleverde tellerstanden wordt het aantal impulsen en de periode ondergebracht in een verbuiksticket bij het deelpakket en de tellerstand krijgt een nieuwe waarde. Bij de periodieke facturering  worden de verbruikstickets in rekening gebracht.  {Een verbruiksticket is voor EFBT een (tijdelijk) record met een Aantal Uitgevoerde autonome Handelingen; van het type impuls. Er hoort ook nog leveringsinformatie bij}

Als op verbruiksnummers gebruik wordt geconstateerd terwijl dat niet strookt  met status-gebruik dan wordt dat gesignaleerd.

  4 Prijscalculatie

 EFBT kent twee vormen van prijscalculatie: 

1.  Standaardcalculatie waarbij aan de hand van het aantal geleverde voorzieningen (AGV) of het aantal uitgevoerde handelingen (AUH) de prijslijst en het kontrakt een prijs berekend wordt, 
2. Handberekening.  Hierbij wordt de handberekende prijs die in de AGV of de AUH staat in rekening gebracht, 

Standaardcalculatie:

Alle berekeningen worden uitgevoerd op basis van een AGV of een AUH; bij basisabonnementen en verbruiktickets zijn deze weliswaar niet direkt zichtbaar maar kunnen ze eenvoudig geconstrueerd worden. Al deze te factureren prijsdragers horen dus bij pakketten of orders. Een eventuele handberekende prijs staat daarmee in de operationele gegevens van de betreffend klant.

 

Alvorens meer over prijscalculatie te kunnen vertellen moet eerst het concept

kontrakt geïntroduceerd worden.  Het kontrakt bevat de voorwaarden waaronder een bepaalde voorziening geleverd wordt, en heeft de volgende  eigenschappen: 

• Eigenschappen die te maken hebben met de looptijd van dat kontrakt en het tijdstip en de wijze waarop EFBT dit signaleert.
• Toeslag/kortingspercentages als bijstelling op de basisprijzen voor huur en service. 
• Het prijsalgorithme: dit geeft de formule waarmee uit de basisprijzen van de kontraktdatum en de basisprijzen op dagdatum de uiteindelijke prijs berekend wordt.

Iedere AGV valt onder een kontrakt, en meerdere AGV's van hetzelfde pakket kunnen onder hetzelfde kontrakt vallen. 

Wanneer er geen expliciet kontrakt is opgegeven treedt een default kontrakt in werking met een onbepaalde looptijd, geen toeslag/kortingspercentages en het prijsalgoritme dat bij tariefvoorzieningen behoort. 

 Een kontrakt is altijd gekoppeld aan 1 pakket;  een pakket mag echter meerdere kontrakten bevatten.  De identificatie van een kontrakt bestaat dan ook uit de identificatie van een pakket en een volgnummer. 

 Ook een AUH valt altijd onder een kontrakt.  Indien een order 

 definitief wordt veklaard, dan vallen de AGV's die daarbij ontstaan onder hetzelfde kontrakt als de corresponderende AUH's. 

Structuur van de prijslijst:

• De prijstelling van een voorziening bestaat altijd uit twee componenenten één voor de huur en  één voor de service.  De prijs van een handeling bestaat uit één component voor de investering en één voor de uitvoeringskosten.
• Dit paar van prijscomponenten  is in principe tijdelijk. Er is een  aaneengesloten reeks tripels  (begindatum,componentenpaar). Op een bepaalde datum geldt het tripel waarvan de begindatum voor of op de betreffende datum valt, terwijl er óf geen opvolgend tripel is óf de begindatum van het opvolgende tripel  erna valt.

 De berekening van een AGV bestaat uit de volgende 5 stappen: 

1.  Opzetten van een calculatieformulier. Het creëeren van een (elektronisch) kladblad voor het bijeenbrengen van de nodige gegevens. 
2. Overnemen van de gegevens de AGV: het geleverde aantal, de verwijzing naar de prijslijst en kontrakt, de handberekende prijscomponenten indien ingevuld. Indien beide componenten ingevuld zijn is de berekenig klaar.  
3. Overnemen van de gegevens uit het kontrakt: datum aanvang, datum in-dienst-facturering, toeslag/kortingspercentage voor de huur, toeslag/kortingspercentage voor de service, code van het prijsalgorithme.
4. Uit de prijslijst worden voor de dagdatum en voor de kontraktsdatum de prijscomponenten opgehaald. 
5. Berekenen vergoeding per maand: Op grond van de op het formulier verzamelde gegevens wordt met het prijsalgorithme de VPM bepaald.  

De berekening van een AUH gaat analoog.

 In het prijsmodel staan ten behoeve van de notavervaardiging, bij voorzieningen, handelingen en prijsregelingen notateksten. En rekeningkenmerken voor de journaalposten.

 5 Maken van een nieuwe Dienst

                     Dienstmodel

Bij het invoeren van een dienst in EFBT en bij het wijzigen van een bestaande dienst moeten bepaalde gegevens ingevoerd worden.  

 Deze gegevens betreffen in eerste instantie de hierboven

 genoemde vier modellen het pakket-, order-, net- en prijsmodel.

 De relevante gegevens worden hieronder genoemd. 

 Terminologie: In het dienstmodel wordt de entiteit waarmee onderdelen uit die vier modellen worden gemaakt vaak als volgt aangeduid:

Voorbeeld aansluitpunt-descriptor.

(database-naam ASLP DESCR en nummer 506). Hiermee kan een nieuw type aansluitpunt gemaakt worden. Alle aansluitpunten verwijzen terug naar hun type. 

 Pakket-descriptor

 Hiermee wordt tegelijk een nieuwe dienst en een nieuw type-pakket geïntroduceerd worden.  De sleutel van het nieuwe type-pakket is een code van drie karakters. Deze code dient om naar de nieuwe dienst te verwijzen en  is ook de waarde voor rekeningkenmerk dst. Het nieuwe type-pakket bevat daarnaast ook de volledige naam van de dienst.

Merk op dat één dienst maar één type-pakket kan hebben.

 Deelrelatie

 Één dienst (1 type-pakket) kan meerdere typen deelpakketten hebben; en omgekeerd kan een bepaald type-deelpakket bij meerdere type-pakketten voorkomen. Dit betekent dat een deelpakket in tegenstelling tot een pakket dienst onafhankelijk is. Met dit relatierecord wordt vastgelegd dat een bepaalde combinatie toegestaan is.

Deelpakket-descriptor  

Dit is de belangrijkste entiteit uit het dienstmodel; het werkpaard. 

Allerlei speciale zaken worden gemaakt als  type-deelpakket. Een type-deelpakket bevat behalve een code van drie karakters (deze dient als sleutel en als boekingskenmerk) en de volledige naam van het type deelpakket, nog de volgende informatie: 

• De naam van het net (optioneel) waar deelpakketten van dit type mee verbonden zijn.
• De naam van de technische identificatie. Optioneel.
• De namen van type eigenschap 1, … ,5. Deze namen zijn afhankelijk van het type dpk. En dienen om bij een deelpakket van dat type basisabonnementen te definiëren. Als de naam van type eigenschap i leeg is, dan bestaat deze niet; en is er ook geen type eigenschap i+1 die niet leeg is.
• Opmaakgegevens voor de nota voor het type deelpakket

Domein

Een  waarde bij 1 van de max 5 eigenschapstypen van een bepaald type-deelpakket. De sleutel is de code van dat type dpk en het nummer van het eigenschapstype . Als één van de vijf eigenschapstypen een naam heeft, en dus bestaat, maar er behoort geen enkel domein bij dan komen eigenschappen van het type niet in een basisabonnement voor en heeft het geen invloed op de prijs. De invulling van waarden ervoor in een dpk van dat type is dan geheel vrij.

Een speciale domeinwaarde is nil, bij deze waarde heeft het eigenschapstype geen invloed op de prijs.

Basisabonnement in de metastructuur

Een type-deelpakket heeft 1 tot max 5 eigenschapstypen waarbij tenminste één domein is vastgelegd. 

Een basisabonnement voor dat type-dpk is een voorziening uit de prijslijst die gekoppeld is aan een combinatie van domeinwaarden met één waarde per eigenschapstype. 

Als in een combinatie de waarde nil voorkomt dan mag er geen andere combinatie zijn die voor het zelfde eigenschapstype geen nil heeft en voor de overige eigenschaptypen dezelfde waarde heeft.

Basisabonnement in het operationele proces

Bij het maken van een dpk van het onderhavige type krijgen in het operationele proces deelpakketten eigenschappen een waarde uit een domein van hun type. 

De combinatie van de ingevulde eigenschappen matched met een basisabonnement uit de metastructuur wanneer voor ieder type eigenschap  de domeinwaarde of gelijk is aan de eigenschapswaarde of als de domeinwaarde nil is. Als alle eigenschappen matchen dan wordt in het dpk een AGV met aantal 1 opgenomen voor de aan die eigenschappen gekoppelde voorziening uit de prijslijst. Dit noemen we in het operationele proces het basisabonnement van het dpk. Dit gedraagt zich als een AGV; en er kunnen dus handberekende prijzen in gezet worden.

In een bepaalde combinatie van waarden kan de waarde voor een bepaald eigenschapstype de waarde nil zijn, in dat geval speelt de waarde van de betreffende eigenschap bij een dpk van dat type geen rol; en bepaalt de rest van de combinatie de voorziening, die als basisabonnement optreedt. 

(Dit komt bij voorbeeld voor bij een lokale huurlijn waarbij de lengteklasse geen rol speelt; maar bij een interlokale huurlijn wel. Bij de lokale huurlijn heeft de lengteklasse de waarde nil, bij de interlokale huurlijk heeft als waarden echte lengteklassen.)

Aansluitpunt descriptor

Een type-aansluitpunt hoort bij het type-verbindingsdeelpakket. En de aansluitpunt-order hangt aan de order van het verbindingsdeelpakket. 

Aansluitabonnement 

Omdat bij huurverbindingen meerdere kontraktanten betrokken kunnen zijn, is er behoefte om de kosten op billijke wijze over het verbindingsdpk en de aansluitingen te kunnen verdelen. Daartoe dienen het tweetal 

aansluitabonnement en basisabonnement van het verbindingsdeelpakket.

 Procedure inpassen van een Dienst

Tijdens de werkzaamheden om de eerste vier diensten ATF (autotelefonie), DN (datanet), SMF (semafonie) en TLX (telex) binnen EFBT te realiseren is een procedure voor het inpassen van een dienst in EFBT ontwikkeld. 

We beschouwen het uitvoeren van die procedure als een bescheiden project. Het team bestaat uit twee medewerkers. Een gebruiker die kennis over de dienst inbrengt en een implementeerder die EFBT goed kent.

Het project kent zes fasen. De laatste stap is het produceren van het zogenaamde inpassingsrapport van de betreffende dienst. 

De inpassingsrapporten van reeds geïmplementeerde diensten zijn uitstekend studiemateriaal. 

 1 Studiefase. 

 1 a 4 weken. Inlezen. Na afloop is er een gezamenlijk beeld hoe de dienst in EFBT zou kunnen worden geïmplementeerd. En als dat onmogelijk is, de reden waarom niet.

2 Haalbaarheidsstudie

Kwantitatieve gegevens over de dienst verzamelen zoals het verwachte geheugenbeslag en de systeembelasting. Voer daarover overleg met de automatiserings-afdeling. Zijn er technische belemmeringen? 

       Formulier om kwantitatieve gegevens te registreren

De dienst voorlopig invoeren in de metastructuur. Daarna is er een eerste prototype voor de dienst. Lijkt het acceptabel?

Onderweg kunnen de ideeën bijgesteld worden. Doorlooptijd 2 a 6 weken.

3 Proefproductie

Hiervoor moeten alle tabellen zoals het dienstmodel, prijsmodel en netmodel voor EFBT, De koptekstentabel voor Notavervaardiging en de boekingsstructuur voor Journalisering volledig ingevuld zijn.

Doorlooptijd 4 weken.

Daarmee is heel volledige prototyping mogelijk, en kunnen proefgevallen volledig nagebootst worden, tot en met het produceren van nota’s!

Er kan nog van alles aangepast worden; het gaat om proefgevallen.

De beslissing om al dan niet in EFBT te implementeren kan genomen worden.  

4 Bouw van de conversieprogrammatuur

Doorlooptijd afhankelijk van de situatie.

5 Implementatie in EFBT

Bestaande klanten kunnen ingevoerd worden. Doorlooptijd afhankelijk van de situatie.

 6 Inpassingsrapport voor de nieuwe dienst

 EFBT heeft een programma om op  basis van de ingevulde tabellen een ruwe versie van het inpassingrapport te genereren. 

Dit moet uiteraard handmatig uitgebreid geredigeerd worden.  Maar dan heb je ook een goed document om de gebruikers op te leiden.

Doorlooptijd afhankelijk van de situatie.

 Met EFBT geïmplementeerde diensten

   ATF (autotelefonie), DCO (datanet), SMF (semafonie) en TLX (telex),  VVB (huurlijnen), en Teletex.

Er is ook een versie van Mobiel(ATF3)  geweest die geïmplementeerd was met EFBT. Omdat er sprake van was dat Mobiel in 2000 verzelfstandigd zou worden, is er voor Mobiel een Customer Care systeem gekocht.

                       einde van de beschrijving  van EFBT                

EVALUATIES VAN ITCIS 

Onderzoeksrapport ITCIS: NODIG of NIET?

Bevindingen van een commissie bestaande uit A.J.Wensink projectleider, C.A. de Feijter, L.Modderman, W.S.Turner en M.Visser. Een onderzoek van April 1987 naar de technische kwaliteit en functionaliteit van het toen nog in ontwikkeling zijnde ITCIS-systeem en welke ontwikkelingsmogelijkheden erin liggen. 

Opdrachtgever was P.Smits, lid van de hoofddirectie van Telecom.

Er is een duidelijk verband met de met de aankomende privatisering (1 jan 1989) en de gewijzigde visie op het klantproces.

Ik bespreek de conclusies van deel 2, dat zich richt op:

1. een evaluatie van het Telecommunicatie klantenproces;
2. de bruikbaarheid van ITCS, en 
3. de bruikbaarheid van de ITCIS-infrastructuur.

Het audit-team kreeg 6 weken de tijd. Hetgeen door de openhartigheid en medewerking van de geïnterviewden door het team als voldoende voor de essentie werd beschouwd. Ik noem wat constateringen, conclusies en aanbevelingen, vooral rond punt 2. {GK: en geef daar ook wel eens commentaar op}

Wat betreft versie 1 van ITCIS:

In 1981 was gekozen om prioriteit aan Incasso te geven. In 1985 is om technische en organisatorische redenen besloten versie 1 te beperken tot de Bedrijfstelecommunicatie. Dat wil zeggen wel ZM (de Zakelijke Markt), maar maar geen KZM (KleinZakelijke Markt) en geen PARTIC (de particuliere markt).

De functionaliteit van de facturerende deelsystemen is door de lange doorlooptijd deels achterhaald; dit geldt meer voor BTF (ook wel AFH genoemd)  dan voor het later gestarte EFBT.

Door de lange doorlooptijd sinds 1981 is het ITCIS-project onder druk komen staan. De automatisering van de basisprojecten is in 1987 nog lang niet voltooid. Naast ITCIS zijn inmiddels allerlei automatiseringsprojecten opgestart zodat een niet consistent geheel voor de basisprocessen dreigt te ontstaan.

Voor nieuwe producten zijn dedicated systemen ontwikkeld, die straks niet zonder meer inpasbaar zijn in ITCIS. Bijvoorbeeld voor Datanet waar men voor een niet in EFBT passende tariefstructuur heeft gekozen.

{GK: De dienst Datanet was operationeel voordat ITCIS dat was. Vanuit ITCIS is geholpen een noodsysteem in Mapper-rundesign, te ontwikkelen. We hadden de Productmanager daarbij beperkingen moeten opleggen. Uiteindelijk is Datanet als Dacom (DCO) toch in EFBT terecht gekomen}

De cluster deelsystemen inmiddels bekend onder de naam DISTEl+ (Notavervaardiging, Inning, Klantregistratie en Journalisering) wordt ervaren als een goed concept.

Versie 1 is een verbetering ten opzichte van TICO, zeker voor de ZM.

Betere notaspecificatie, on-line beschikbaar voor klachtafhandeling, geschikter voor het inrichten van de administratieve organisatie.

De algemene opinie is dat versie 1 zo snel mogelijk moet worden ingevoerd.

Als kritische succesfactoren voor het T-bedrijf na de verzelfstandiging worden genoemd:

1. Optimale exploitatie van de concessie
2. Optimale informatie over de klanten
3. Optimale winstgevendheid van de concessie-exploitaties

Voor het informatiebeleid volgt hieruit:

• Centralisatie van dit beleid
• Prioriteit voor de basis klantprocessen

Omdat het aantal geautomatiseerde (centrale en decentrale) systemen enorm is gegroeid wordt er gepleit voor gegevensbeheer in verband met de interfaceproblematiek. Niet als onderdeel van de systemen maar juist over de systeemgrenzen heen.

In dit kader wordt de praktijk genoemd om voor nieuwe diensten/producten eerst een eigen incasso systeem te maken, om later op ITCIS aangesloten te worden)

{GK: Hier had de commissie tegen moeten waarschuwen. Het is naïf om te denken dat die eigen incasso systemen onzichtbaar voor de klanten, en zonder veel moeite bij KPN, in ITCIS ingepast konden worden. En dat inpassen is dus nooit gebeurd}

Aanbeveling:  ITCIS door zetten en leidend maken bij andere automatiserings-projecten van het basisklantenproces. Die projecten waren vaak gericht op onderwerpen, die ITCIS ‘voorlopig’ liet liggen.

Onder het hoofdje Project Organisatie. 

“ITCIS kan, na invoering van AFH in de startdistricten als projectgroep opgeheven worden. Gezien de samenhang van diverse projecten voor het basis klanten-proces bevelen wij aan een nieuwe stuurgroep in te stellen: V(oortraject), I(ncasso), V(erkoop) en A(handeling), Cliënten) en E(indgebruikers). VIVACE. 

{GK: Het overgaan op een bredere stuurgroep was prima. Wat ik mis is aandacht voor EFBT. Er kwamen met grote regelmaat nieuwe diensten. Na invoering van AFH in de startdistricten en EFBT voor reeds daarin ingevoerde diensten; zou er gekwalificeerd personeel bij EFBT beschikbaar moeten blijven om nieuwe diensten te begeleiden, en met hen de procedure voor de invoering van nieuwe diensten te doorlopen.

Wat vooral ontbrak was sturing op de productmanagers om van de diensten van EFBT gebruik te maken. Iedere manager van een nieuw dienst/product wil het liefst zijn eigen billingstraat; want maximale vrijheid.}

{GK: Er wordt in dit rapport veel gesproken over KZM en PARTIC in relatie tot ITCIS. Ik kan niet nalaten op te merken dat een deel van de klanten van KZM al een factuur uit EFBT (zouden gaan) ontvangen, om de eenvoudige reden dat ze een dienst hebben die nu eenmaal door EFBT gefactureerd wordt.

Nu kan je met EFBT in 6 weken een prototype van de incasso van een dienst maken, een met met wat meer inspanning zelfs alle mogelijke proefgevallen tot en met een nota prototypen. 

Ik vermoed dat telefonie voor KZM wel in EFBT past. Maar natuurlijk zijn er technische capaciteitsproblemen.

Dezelfde redenering geldt voor PARTIC. Daar zullen de technische capaciteitsproblemen enorm zijn. Het is echter veel waard als je een prototype hebt waar de gebruikers op kunnen reageren. (niet zelden zeggen ze: doe maar, en verwachten dan binnen een paar weken een operationeel systeem!). 

Overigens is gebrek aan  capaciteit vaak goed oplosbaar, met optimalisatie van de performance en/of het bijkopen van hardware. En die hardware presteerde steeds beter voor een steeds lagere prijs}

                        einde van ITCIS:  NODIG of   Niet                       

Mijn mening als medewerker over ITCIS

Mijn achtergrond als programmeur/informaticus

Het vak heb ik in een bijzondere omgeving geleerd: op het Mathematisch Centrum (MC), het tegenwoordige Centrum voor Wiskunde en Informatica (CWI) in Amsterdam. Na het succesvol uitvoeren van een tentamenopdracht, zie Post Oudste Kunstmatige Voorlezer (een toepassing van de computational linguistics), werd ik daar assistent. Voor mijn afstuderen schreef ik nog een toepassing van dat vakgebied, zie Post Sommen in de vorm van een verhaaltje. 

Dit centrum behoorde in die tijd tot de top bij de ontwikkeling van programmeertalen: ALGOL60 en ALGOL68. Maar stond ook aan de basis van Electrologica dat een belangrijke rol speelde in de vroege ontwikkeling van computers in Nederland en Europa o.a. de X1 en de X8.

Als afstudeeropdracht voor Informatica kreeg ik de opdracht een robuust systeem  te ontwikkelen, waarmee heel grote verzamelingen gealfabetiseerd konden worden. Dit werd gebruikt voor frekwentie-tellingen van natuurlijke talen bijvoorbeeld uit kranten. En ook om bij bepaalde sleutelwoorden zoveel mogelijk contexten van bijvoorbeeld 6 woorden links en 6 rechts te presenteren. Er was geen beperking aan de omvang van het corpus als je maar genoeg magneetbanden had. 

Hoewel ik normaal weinig te maken had met de hardware: je leverde programma en data aan op ponsband bij een balie, en haalde later daar ook de resultaten op, meestal prints van een regeldrukker.

Voor heel grote sorteerklussen ben ik echter wel buiten kantooruren zelf operator geweest van de X8; opstarten en magnetische tapes verwisselen.

Na mijn afstuderen werd ik medewerker. We kregen toen ook langzamerhand terminals.

Ik heb heel veel geprogrammeerd in ALGOL60 en later ALGOL68. En ook wel in PASCAL, Fortran en Lisp. Meestal Kunstmatige Intelligentie-achtig bijvoorbeeld een “Automatic Theorem Prover”. Ik heb onderwijs gegeven in ALGOL60 aan studenten, wiskundeleraren en kunstenaars. Zie Post Tabaksdoos. Ook programmeer-college gegeven aan Psychologie-studenten waarvan een groep als eindopdracht een interactief klaverjas-programma heeft gemaakt. 

Pas bij PTT heb ik kennis gemaakt met de echte administratieve automatisering; vooral tijdens de Informatie Analyse.

Een integraal systeem

De oudste brochure over ITCIS die ik ken is van 1972. De T staat daar nog voor Telefonie, in latere vermeldingen is dat verruimd tot Telecommunicatie. De C staat voor Cliënten, en IS voor InformatieSysteem. 

In de inleiding wordt het oudste informatiesysteem van PTT Telecom uit 1962:  TICO voor Telefoon InCassO, genoemd. TICO is tot ver in de jaren ‘80 in productie gebleven voor particuliere klanten. Het draaide nog altijd  prima, maar het was functioneel al lang sterk verouderd: de klant was een telefoonaansluiting met een nummer. Voor een grotere zakelijke klant was dat absurd.

Er was ook behoefte aan een  systeem om het bekende 008 voor het opvragen van een telefoonnummer te ondersteunen en telefoongidsen te kunnen produceren.

Er zit een onmiskenbare overlap tussen de klantgegevens gebruikt voor de verschillende bedrijfsfuncties. Om daar efficient mee om te gaan en tegenstrijdigheden tussen de verschillende administraties te vermijden wordt de kwalificatie Integraal voor een informatie systeem in de brochure geïntroduceerd, waarmee het acroniem ITCIS compleet is. 

{Onder een integraal informatiesysteem wordt kennelijk verstaan een groot systeem dat bestaat uit een aantal samenwerkende deelsystemen, die gebruik maken van één database}

Uit de Brochure van 1972, paragraaf 2

_________________________________________________________

2. WAT IS ITCIS EIGENLIJK?

Er zijn heel wat plaatsen in een telefoondistrict, waar gegevens van abonnees worden bewaard en bijgehouden. Om er maar enkele te noemen: 008, de afdeling Aansluitingen en de dienstkringen.
Deze bestanden moeten regelmatig worden bijgewerkt. Zo zal de indienststelling van een nieuwe telefoonaansluiting de volgende wijzigingen (mutaties) tot gevolg hebben:

Een aantal gegevens van deze verschillende bestanden is min of meer gelijk, een aantal is specifiek voor de afdeling. Juist voor deze laatste informatie bestaan er regelmatig contacten tussen de afdelingen: zo zal de Afdeling Aansluitingen de dienstkring moeten bellen om aan de weet te komen of er een vrije ader is voor de toekomstige abonnee.

 

Het lijkt aantrekkelijk om op de afdelingen blijvend dezelfde bestanden op te slaan. Men moet dan echter wel bedenken dat ook mutaties op verschillende plaatsen moeten worden aangebracht, met de kans op fouten en verschillen.

Ideaal is het indien alle gegevens op één centraal punt zijn opgeslagen zodat

wijzigingen slechts éénmaal behoeven te worden aangebracht, en indien tevens elke afdeling er alle gewenst gegevens uit kan putten.

Wel dienst ervoor te worden gezorgd dat de snelheid, waarmee men over de gegevens kan beschikken, niet in het gedrang komt, denk b.v. aan 008.

Welnu de computer is in staat dit te realiseren.

De bestanden zijn geïntegreerd opgeslagen in een groot elektronisch geheugen, een z.g. “data-base”, terwijl muteren en opvragen van gegevens plaatsvinden door middel van terminals (eindstations).

Geïntegreerd wil zeggen dat in principe slechts één mutatie wordt gemaakt, maar ook dat in de data-base elk gegeven slechts éénmaal voorkomt. 

Het hiervóór genoemde voorbeeld van de indienststelling van een nieuwe aansluiting komt er dan als volgt uit te zien.:

Welke zijn nu die klanten-administratie en om welke aantallen gaat het?

ITCIS omvat:

• het technisch overzicht, waarin het lokale kabelnet is opgenomen: verbindingen voor 5 miljoen woningen, van centrale tot woning verdeeld over dunne en dikke kabels;
• de abonneeregistratie, zoals die bij de afdelingen Aansluitingen, Calculatie en Incasso bestaat; van alle 2,5 miljoen abonnees zijn hier alle gegevens vastgelegd in een bestand. Dezelfde gegevens zijn thans ook voor een deel ook opgeslagen in de computer waardoor elke twee maanden de telefoonnota’s kunnen worden vervaardigd;
• de orderregistratie, waar elke opdracht wordt bewaakt van het moment van aanvraag af tot het tijdstip van gereedmelding van de opdracht;
• de gidsvervaardiging, waar van elke abonnee wordt geregistreerd hoe en waar hij in de gids is opgenomen;
• de inlichtingendienst telefoonverkeer (008), waar aan de hand van allerlei naslagwerken jaarlijks 24 miljoen maal op aanvraag telefoonnummers worden opgezocht en verstrekt;
• de inlichtingendienst klantenadministratie (004), waar de klanten telefonisch, schriftelijk of aan de balie vragen kunnen stellen over gidsen, nota’s, aansluitingen, tarieven, enzovoorts;
• de storingsdienst, waar men op grond van klachten snelle en doeltreffende maatregelen moet kunnen nemen.

Aangezien het aantal telefoonabonnees van 1971 tot 1981 zal verdubbelen, zullen er zonder verdere automatisering van de administratie grote moeilijkheden ontstaan.

——————————————————————————————

In een latere brochure ITCIS uit 1980, de T in die naam staat inmiddels voor Telecommunicatie, heeft men het nog steeds over het gemeenschappelijk gegevensgebruik. 

Maar integraal betekent daar ook dat de output van het ene systeem input kan zijn voor het andere. Dat zou met een integraal systeem makkelijker zijn. {Dat is waarschijnlijk belangrijker dan het eenmalig invoeren van klantgegevens}

Bovendien zou ITCIS de districten de mogelijkheden moeten bieden het geautomatiseerd systeem af te stemmen op de verschillende indeling van taken die er tussen hen bestaat. 

Naast TICO was er inmiddels een systeem DB008 ontwikkeld. Een centrale Database te raadplegen door de telefonisten bij het opvragen van telefoonnummers, die ook gebruikt wordt voor het produceren van gidsen.

Het ontwikkelen van DB008, met een centrale database op Unisys, en een netwerk voor decentraal gebruik middels de PDP11 van DEC (Digital Equipment Corporation) was een groot succes en een technisch hoogstandje. Het werd beschouwd als een eerste fase van ITCIS. Er was een koppeling tussen TICO en DB008.

De Informatie-Analyse voor ITCIS

Zoals beschreven in Een Integraal Systeem deel 1 ben ik in 1980 bij PTT-Telecom aangenomen en was voorbestemd een nieuw TICO te ontwerpen; ik kwam echter al gauw terecht bij de Informatie Analyse voor ITCIS. 

Dit stond onder leiding van een Engelse externe medewerker Peter Clemerson. Onderzocht werden ruwweg de onderwerpen die in de brochure genoemd staan. Ik werd coördinator voor een aantal Haagse deelprojecten en -met een goed ingevoerde- medewerker verantwoordelijk voor het onderwerp INCASSO. Na het einde van de Informatieanalyse voor het Integraal Telecom Informatie Systeem was er een lange periode van besluitvorming.

Ik werd ondergebracht bij het project AFH (Automatische Facturering Huisautomaten). Dat was het complexe onderwerp van de eigen telefooncentrales van grotere klanten, er hoorden vaak ook eigen netwerken bij. Dit project zou ook in ITCIS opgenomen worden. Ik hielp de projectleider Rob van Vliet, met de grote brei die op zijn bordje lag. Het resultaat waren twee projectvoorstellen voor nieuwe deelsystemen voor ITCIS:

• Journalisering; als financieel systeem zouden er in ITCIS veel journaalposten geboekt moeten worden. En die taak wilden wij zoveel mogelijk automatiseren. Dit resulteerde in het voorstel voor een deelproject JOUR.
• Regelmatig werd Rob uitgenodigd voor een bijeenkomst over de facturering van een nieuwe dienst. Dit resulteerde in een voorstel voor een deelproject Eenvoudige Facturering BedrijfsTelecommunicatie EFBT. Bedoeld als pakket voor het factureren van nieuwe diensten.

Besluiten over ITCIS

{Ik ben er niet bij geweest; mij bereikten deze besluiten via de hiërarchie. Formeel heeft de Directeur Generaal van PTT en/of de Hoofddirecteur van Telecom deze besluiten genomen. Zijn belangrijkste adviseurs waren Hoofd FOWA (Formaties, Organisatie, Werkorganisatie en Administratieve automatisering) en de Directeur van DAUT (Directoraat Automatisering). FOWA was een onderdeel van Telecom, DAUT behoorde bij de concernstaf van PTT.}

1. Er zou een Integraal Informatiesysteem voor de klant-processen komen
2. De prioriteit werd gegeven aan Incasso
3. Als platform werd gekozen voor Unisys met Cobol als programmeertaal
4. Er werd een interne projectleider voor de gebruikers aangesteld
5. Er werd een interne projectleider voor de automatisering aangesteld
6. Er werd voor ITCIS een functionele infrastructuur ontwikkeld. Zeg maar systeemcomponenten die niet door de fabrikant worden geleverd: een menusysteem, een helpsysteem. 
7. Er werd een data interface ontwikkeld waarmee de netwerk-database van Unisys benaderd kon worden alsof dit een relationele-database was
8. Daar waar er verschillen in werkwijze tussen de districten belemmerend waren zouden de programmeurs mini-transacties ontwikkelen, waaruit per district passende transacties zouden worden samengesteld

Aantrekkelijkheid van de voorgelegde besluiten 

Over ITCIS werd binnen het bedrijf al vele jaren gesproken en geschreven, er was met DB008 al een eerst stap gerealiseerd. Nu zou er doorgepakt gaan worden. 

Incasso was een probleem: TICO was én verouderd, én ongeschikt voor de zakelijke markt. 

Voor PTT was Unisys met Cobol vertrouwd. 

De projectleiding in eigen handen houden is positief. 

Dat er nog wat systeemcomponenten ontwikkeld zouden moeten worden lag in de rede.

Een data interface waarmee het leek alsof ze wel een relationele database  hadden maakte de keuze voor Unisys makkelijker. 

Het overbruggen van de verschillen in werkwijze tussen de districten via de constructie met minitransacties loste een heikel probleem op: de noodzaak die werkwijze landelijk te standaardiseren.

Consequenties van die besluiten 

Doorlooptijd

Het zou veel tijd kosten voordat er een inzetbaar resultaat was.  Incasso is op zich al een groot onderwerp. Je hebt de functionele infrastuctuur en een ingerichte database met het data interface nodig, voordat je aan de bouw van het incassosysteem kunt beginnen. En ITCIS zit aan het eind van het leveringsproces. Je zult ook iets moeten bouwen om de vorderingen in het systeem  te krijgen.  En zolang niet alles klaar is, heb je er weinig aan.  

De randvoorwaarden 

waaronder gebouwd moest worden waren belastend:

• Op Unisys was geen relationele database beschikbaar, terwijl voor gemeenschappelijk gebruik van gegevens een relationele database ideaal is. Er is mij verteld dat de directie een ‘echt’ Main Frame wilde en dat men de VAX te ‘klein’ vond voor die taak. 
  Men had beter kunnen weten. De wet van Moore die stelt dat het aantal transistoren in een geïntegreerde schakeling door de technologische vooruitgang in twee jaar verdubbelt, is van 1965. Bij Telecom had men die wet aan den lijve ondervonden. FOWA zat in een groot gebouw aan de Beatrixlaan  in Den Haag naast die hoge straaltoren. Het gebouw was bedoeld voor grote telefooncentrales, maar was grotendeels leeg gebleven want die centrales waren zoveel kleiner geworden, en dus was er ruimte voor een mooie kantoortuin voor het groeiende FOWA-AUT. Voor het gebouw was een grasveld vrijgehouden voor nog zo een centrale-gebouw (nog altijd leeg). De wet van Moore gold net zo goed voor computers als voor centrales!
•  De keuze voor COBOL voor een ambitieus megaproject als ITCIS is jammer. COBOL was in 1982 al een achterhaalde taal: als je gebruik maakte van een subroutine begon iedereen te piepen. Terwijl het gebruik van subroutines voor moderne talen vanwege de transparantere structuur van de software (top down programmeren) en compactere software (minder regels programmatuur) juist aanbevolen werd. Het argument tegen subroutines was dat het meer tijd zou kosten. Een argument dat ik voor moderne talen nooit gehoord heb. Een ander argument was dat Telecommers aan COBOL gewend waren. In de bouw van ITCIS zaten echter haast alleen T-ers van een hogere rang als projectleider: die mochten niet programmeren. (Er waren wel ex-T-ers die overgestapt waren naar een software-huis omdat ze als programmeur aan het eind van hun schaal zaten)
• De keuze voor een  data-interface, waarmee je de netwerk-database van Unisys kon benaderen als ware het een relationele database. Dit bleek een grote belasting bij het inrichten van de netwerk database van Unisys voor ITCIS. Nadat het interface die inrichting ernstig had vertraagd is men ermee gestopt. Het middel was erger dan de kwaal.

Waarom hebben die consequenties geen invloed gehad?

{Nogmaals ik ben er niet bij geweest. Maar heb wel mensen gesproken die een rol speelden bij consultaties en als adviseur van de adviseurs. De rol van Chef FOWA-AUT is voor mij een raadsel. Hij was opdrachtgever geweest van de InformatieAnalyse en had daarover veel overlegd met de projectleider. Naar mij verteld is was zijn rol bij de besluitvorming heel beperkt. Voordat er geschrapt werd in Versie 1 van ITCIS was hij al weg bij Telecom}

Geen autoriteit in de administratieve automatisering.

Wat binnen Telecom ontbrak was een functionaris die de praktijkervaring had om de problemen waartoe de besluiten zouden leiden van te voren te onderkennen. En ook de autoriteit had om dat bij de beslissers in te brengen. 

{Hoofd FOWA was geen automatiseerder. De InformatieAnalyse van ITCIS lijkt nauwelijks een rol in de besluitvorming te hebben gespeeld}

Centraal versus decentraal 

Wat speelde was de vraag wie de computers voor ITCIS zou gaan beheren: centraal bij het concern PTT of decentraal bij Telecom. Dit was meer een bedrijfspolitieke dan een technische vraag. Er was niet zoveel synergie tussen de werkmaatschappijen Telecom, Post en Giro. Een groot centraal rekencentrum zou de functie van het concern onderstrepen. Twintig jaar later was er inderdaad geen overkoepelend concern meer, maar drie zelfstandige bedrijven KPN, TNT Post en de Postbank.

Dit beïnvloedde ook de discussie over de systeem keuze: DB008, dat beschouwd werd als de eerste fase van ITCIS, draaide op Unisys bij het concern. Een keuze voor de VAX van Digital Equipment Corporation zou eerder aanleiding kunnen zijn om het beheer bij Telecom te doen. Die werkte al met apparatuur van DEC.

{GK: Men had als platform voor de VAX met een relationele database moeten kiezen, en een moderne programmeertaal bijvoorbeeld Pascal of C. 

Als projectleider was Peter Clemmerson die de informatie-analyse geleid heeft zeer geschikt geweest. (De benoemde interne projectleider was een database-specialist, die het liefst zelf een Relationeel Database Management Systeem voor op Unisys was gaan bouwen. En daarna voor het data-interface koos.

Een goed vakman die wist dat ITCIS  een relationele database vereiste. Maar de verkeerde weg koos om dat te bewerkstelligen ) 

We hadden moeten beginnen met een ‘trail blazer’ een bescheiden project, om de functionele infrastuctuur uit te proberen. En ook al een eerste bescheiden resultaat te hebben, voordat we aan het grote INCASSO begonnen}

De start van ITCIS versie 1

In 1983 is ITCIS in de vorm van een aantal deelprojecten gestart: Voor de functionele infrastructuur, voor database en data-interface, voor de Centrale Klantregistratie, AFH/bedrijfstelecommunicatie, PARTIC/particuliere telecommunicatie, Notavervaardiging, Inning, en Journalisering. Ik werd projectleider van JOUR.

Het schrappen van particuliere telecommunicatie uit Versie 1  

     In ITCIS: NODIG of NIET staat:  “In 1985 is om technische en organisatorische redenen besloten versie 1 te beperken tot de Bedrijfstelecommunicatie” dat is een zakelijke beschrijving van de maatregelen die genomen zijn naar aanleiding van wat ik onder het hoofdje ‘Een Crises in ITCIS” in deel I beschrijf:

In 1984 kwam er een probleem aan het licht. Er was grote achterstand op de planning voor het database en -interface project. Het data-interface legde enorme beperkingen aan de database op waardoor er weinig voortgang bij het inrichten van de database was.

 Keith Greystoke de baas van het software house DCE  (Database Consultancy Europe) dat de database met het data-interface zou inrichten had kennelijk de verantwoordelijkheid om het probleem op te lossen. Hij belegde in afwezigheid van Telecom management een vergadering van projectleiders, en bracht boven water dat de vertraging niet beperkt was tot de database, maar dat ook de applicaties grote vertragingen hadden. Hiermee was zijn probleem opgelost door het groter te maken tot een algemeen probleem van ITCIS. En hij verkreeg de macht om dat grotere probleem -op zijn voorwaarden- op te lossen}

{De sfeer in die periode zou je naar analogie van het rampjaar 1672 kunnen beschrijven als: het Telecom management was radeloos, de gebruikers waren redeloos en ITCIS was reddeloos}

Er werd besloten ITCIS nog verder te beperken tot Bedrijfstelecommunicatie, zeg maar de Zakelijke Markt.  En de particuliere telefonie voorlopig in TICO te laten. Daartoe moest wel het projectvoorstel van Rob van Vliet en mij over EFBT uitgevoerd gaan worden; want BTF - eerder bekend als Automatische Facturering HuisAutomaten (AFH) - beperkte zich tot telefonie. 

Er kwam in feite een externe projectleider voor de automatisering: Fred Ras van DCE, formeel als assistent van de interne projectleider. Het data-interface werd later gestopt. En er was natuurlijk een forse vertraging.

Ik mocht EFBT gaan doen; JOUR had geen vertraging, maar vanwege de vertraging van de rest, ook geen haast.

Een enorme vermindering van wat er opgeleverd zou worden (geen particuliere markt), en een grote vertraging, was geen leuk bericht voor de directie en de gebruikers. De projectleider van de gebruikers protesteerde zo heftig bij Hfd FOWA die een veel hogere rang had, dat hij van zijn taak ontheven werd, en spoedig het bedrijf verliet. 

Dit alles leidde tot een slechte naam voor ITCIS bij de gebruikers en bij het personeel van de automatiseringsafdeling. Dat is bij de eindgebruikers waarschijnlijk wel goedgekomen, maar bij de automatiseerders binnen Telecom nooit.

     Doorgaan met ITCIS

     Fred Ras pakte de zaak goed aan; er werd een fors aantal externe medewerkers ingehuurd om de projecten te versterken, want er was weinig belangstelling bij het interne personeel om aan ITCIS te gaan werken. Er werd een ontwikkelmethode voor de applicaties ingevoerd; heel degelijk, maar wel tijdrovend. Werkend met grote teams met veel externen (veel verloop), krijg je ook een groot intern communicatieprobleem, vandaar dat je heel degelijk moet documenteren. 

     

     {GK: als we op de VAX met Pascal waren gaan werken, dan hadden we een relationele data-base gehad; en dus geen data-interface nodig gehad. We hadden mijns inziens met  minder mensen, maar wel van een hoog niveau moeten gaan werken, die zowel het technisch ontwerp deden als programmeerden. Je had de documentatielast kunnen beperken tot de essentie van het technisch ontwerp, en veel commentaar bij de programmatuur.  En zo een lagere documentatielast gehad }

     

     Fred Ras kende de Sperry Unisys 1100 waarop gewerkt werd goed en leerde ons er veel over. Er was een handig tool Mapper, waarin we de documentatie zouden maken, en daar hoorde een programmeertaaltje bij Mapper-Run-design bij. Hij vertelde ons ook dat een faciliteit van Unisys die ons was voorgespiegeld: Drip Feed niet werkte. Met Drip Feed zou je als de on line belasting van het systeem overdag laag was, die capaciteit kunnen benutten door stukjes van de Batch te draaien. Maar dat werkte dus niet. 

     Klantsystemen buiten ITCIS

     Doordat ITCIS een slechte naam gekregen had werd er voor andere klantprocessen geen gebruik van gemaakt van de ITCIS infrastructuur, terwijl de VAX heel populair werd. 

      In de districten was er het besef dat ITCIS aan het eind van het leveringsproces zat. Het software-huis Multihouse speelde daar handig op in door een soort werkorder-systeem voor hen te ontwikkelen op de VAX in DIBOL een COBOL-achtige taal. Het werkte met files; geen database. Bijna voor elk district een eigen versie want het leveringsproces in de districten was niet gelijk. 

     Dat vond de de directie later geen goed idee. Er moest één dergelijk programma  Automatisering WerkOrders (AWO) komen. Weg uit de districten, centraal bij FOWA, en de verschillen moesten rechtgetrokken worden. Zo ontstond er een gigantische VAX-cluster bij FOWA met 8 versies. Er was gecentraliseerd! De Amsterdamse versie werd leidend en de verschillen zijn langzaam weggewerkt. AWO heeft pas heel laat een interface met ITCIS gekregen, maar alleen voor opheffingen. 

     {GK: Een simpel werkordersysteem was een goede keuze geweest om voor ITCIS mee te beginnen; een ‘trail blazer’.  Het heeft eigenlijk Klantregistratie en Journalisering nodig maar je kunt beginnen zonder dat, als een electronisch dossier met soms vrije tekst maar ook een aantal vaste rubrieken voor items die voor de facturering nodig zijn. Er is in de InformatieAnalyse ook een onderzoek naar Werkorders geweest. De behoefte aan werkorders voor Incasso was daar bekend. Wetend dat er districts verschillen zijn, had je het samen met ‘the best in class’ kunnen ontwikkelen. }  

     CKR (Centrale KlantRegistratie) 

     Omdat ITCIS de centrale rol in de klantadministratie nooit verkregen heeft   is er later buiten ITCIS een algemene klantenregistratie CKR ontwikkeld waaraan alle systemen met  klantgegevens middels het zogenaamde CKR-nummer gekoppeld konden worden. De centrale klantregistratie van ITCIS is daar toen ook aan gekoppeld.

     Het was beter verlopen als de klantregistratie van ITCIS de rol van algemene klantregistratie van Telecom, zoals oorspronkelijk de bedoeling, wel gekregen had. 

     CKR heeft namelijk altijd veel last gehad van gegevensvervuiling; of beter gezegd de inconsistenties kwamen rond CKR aan het licht. Omdat ITCIS een incassosysteem is worden haar klantgegevens regelmatig getoetst. Een nota die naar een verkeerd adres wordt gestuurd; wordt niet betaald. En een kontraktant die ernstig in gebreke blijft wordt opgespoord en krijgt een deurwaarder op bezoek. Het is daarom een goede strategie om de incasso-klantgegevens ‘leidend’ te maken.

      ITCIS operationeel

      ITCIS ging ondertussen langzaam maar gestaag door, het werd pas in 1989 echt operationeel. Maar het was als integraal systeem toch geen monoliet geworden. 

     Dat kwam onder andere door de opzet van Journalisering, die had het totale werkterrein dat ITCIS per district besloeg verdeeld in zogenaamde  boekingsgemeenschappen. Zie het geldstroommodel in deel 1. Een boekingsgemeenschap mocht uitsluitend op zijn “eigen rekeningen” boeken en op één zijde van een interface-rekening naar een andere boekingsgemeenschap die een tegenboeking moest doen zodat bij ‘rust’ van het systeem er geen saldo zou zijn.  Er waren de volgende  boekingsgemeenschappen: Voor de facturering 1 per dienst, 1 voor Notavervaardiging, 1 voor Inning en 1 voor de Boekhouding voor de relatie met het grootboek. 

     Omdat er goed gedefinieerde (en bewaakte) interfaces tussen de boekingsgemeenschappen afgedwongen waren, konden  de betreffende deelprocessen ook ruimtelijk uit elkaar gehaald worden, desgewenst op een andere machine. 

     Bij de grote reorganisatie ELAND (Eenduidig LANDelijk) van 1992, waarbij 13 districten overgingen naar 32 regio’s. Is daarvan gebruik gemaakt om voor de grootzakelijke klanten een landelijke totaal-nota in te voeren. Daartoe was een speciale “Landelijke regio” ingevoerd in Groningen die voor dergelijke klanten de totaal-nota’s vervaardigde en  de betalingen verwerkten, terwijl het klantcontact in de regio van de vestiging van de klant bleef.  

     Was ITCIS een succes, of niet? 

     Volgens de “wandelgangen” heeft ITCIS een miljard gekost, maar er is zo een twintig jaar mee geïncasseerd, waarbij er in de topjaren 20 miljard mee werd geïnd. 

      ITCIS is door de conservatieve keuzen en fouten die bij de start werden gemaakt: voor een platform zonder uitzicht  op een relationele database, met als lapmiddel, een data-interface dat erger was dan de kwaal. En een verouderde programmeertaal. En natuurlijk een veel te optimistische planning. Vooral in het begin een tegenvaller geworden, maar het heeft in de loop der jaren toch goed gefunctioneerd.  

     Een gemiste kans voor Telecom

     ITCIS had de kern van de  klant-systemen kunnen worden, waar het voor bedoeld was. De ontwikkeling had goedkoper en sneller gekund. En dit ITCIS had met de ontwikkeling van de techniek mee kunnen gaan evolueren.

     Toen Versie 1 eenmaal klaar was, toen was het eigenlijk al verouderd. En er is bij de automatiseerders binnen Telecom altijd een weerzin tegen ITCIS geweest. 

     

     Dat  heeft zich vooral gewroken bij EFBT. Ik ben natuurlijk niet erg objectief; maar ben van mening dat het functioneel een goed pakket was. Waaraan Telecom een grote behoefte had. Maar waarvan de toepassing beperkt is gebleven tot een paar diensten die al aan het uitsterven waren.  Maar het kwam natuurlijk twee jaar te laat en ITCIS werd toen als ‘legacy’ beschouwd.

     In een paar andere omgevingen zijn tientallen min of meer onafhankelijke Billingstraten ontwikkeld voor nieuwe diensten. Ik weet niet of men daar wel blij van is geworden; en of het goedkoper was. Dat mag iemand anders uitzoeken; maar ik heb zo mijn twijfels. 

     Er is veel later nog door ATOS een voorstel “Avondrood” gelanceerd om een aantal van die straten in ITCIS onder te brengen. Dat is nooit uitgevoerd. Naar wat ik ervan gezien heb, was hun aanpak niet slim, Zij dachten aan het maken van een paar nieuwe factureringssystemen voor ITCIS; maar hadden natuurlijk gewoon van EFBT gebruik moeten gaan maken.        

           

                                                                                                          

     Is een integraal systeem een goed concept?

     Tenslotte de vraag of een “integraal systeem” een goed concept is? 

     Het als integraal realiseren van een cluster deelsystemen is zeker een voldoende voorwaarde om gemeenschappelijk gegevensgebruik, waarbij ook de output van een deelsysteem doorgeven wordt aan een ander deelsysteem, goed mogelijk te maken

     Het personeel van de incasso-afdelingen moest wennen aan wat ITCIS allemaal automatisch voor hen deed: vorderingen en storneringen bijgewerkt, aansluitingen met de giro en ook alles direct in de boekhouding. Het werk verschoof van uitvoerend naar controlerend. Vooral problemen als registraties niet goed werden bijgehouden. Integraal werkt dus wel.

     Maar er kleven grote nadelen aan een integraal systeem zoals de tendens dat de gebruikers pas iets krijgen als alles klaar is. En de complexe afstemming tijdens de ontwikkeling. Is voor gemeenschappelijk gegevensgebruik het integraal zijn van het totale systeem ook een noodzakelijke voorwaarde?

     Een alternatieve aanpak: integreerbare gegevens

     Gegevensmanagement (richt zich op de semantiek van de gegevens) en datamanagement (richt zich op de organisatie en de inrichting van databases).  

      

      Hiermee kun je ook gemeenschappelijk gegevensgebruik mogelijk maken, terwijl de betrokken systemen verder veel onafhankelijker van elkaar kunnen zijn. 

     In plaats van één integraal systeem, kun je zo werken met meerdere onafhankelijke systemen waarvan de gegevens geïntegreerd kunnen worden. Dat wil zeggen dat indien twee systemen beide over bepaalde zaken informatie bevatten dan kan deze informatie gecombineerd worden.  

     Het is heel goed mogelijk dat ook een gekocht pakket in dit gemeenschappelijk gegevensgebruik meedraait.  Eventueel met een vertaaltabel. 

      In 1987 ben ik overgestapt van ITCIS naar de afdeling Gegevensmanagement van het Informatiemanagement.   

   

      Bedankt    

      Vele oud collega’s hebben me informatie verschaft, of de weg gewezen om informatie te vinden. Daarvoor allen hartelijk dank. 

      Met name Henk Boleij en Martin Carbo.

      Uiteraard ben alleen ik verantwoordelijk voor de inhoud.