04 De afdelingen De systeemontwikkeling Inleiding Er is nogal een verschil tussen de programmeur van het eerste uur die zijn COBOL programma op ponsformulieren schreef en de man of vrouw die nu met een beeldscherm een programma met IEF genereert. Er zit dan ook veertig jaar ontwikkeling tussen. In die tijd werden talloze “Tools” en methoden bedacht om het programmeren maar sneller en met minder fouten te laten verlopen. We bespreken ze niet allemaal, dat zou te ver voeren. Alleen de belangrijkste zaken zijn opgenomen. Maar één ding is hetzelfde gebleven: IEF genereert nog steeds COBOL. Een oma uit 1960! Na deze opsomming een hoofdstukje over meten en een bespreking van het HBSO. En tot slot wat foto’s.
Voor 1967 Er waren tot 1967 twee ontwikkelafdelingen. De Gamma en de 1401 in Den Haag. Op de 1401 werd met SPS geprogrammeerd; de taal van de Gamma is niet meer bekend. In Rotterdam bij de Nationale werd er op de 650 geprogrammeerd. In eerste instantie werd er gewerkt in Assembler, (10 was optellen, 11 was aftrekken), later werd dit Soap (Symbolic Optimal Assembly Program). Wim Combé die nog op deze machine geprogrammeerd heeft noemt SOAP een hele verbetering ten opzichte van Assembler. Je kon nu ADD en SUB schrijven in plaats van 10 en 11, maar vermenigvuldigen was wel herhaald optellen. Hij herinnert zich ook nog de onbetrouwbaarheid van de machine. Leo Verwoert kan zich nog uit het begin weekenden herinneren waarin hij meerdere malen naar de zaak moest omdat de 650 een dump gaf. Meestal was dat verkeerde input waar het programma op stuk liep. Of ze hadden op de afdeling wat trucjes gebruikt om een post in te voeren en daar kon dan het programma niet tegen. Hij moest dan Martha Bestebreurtje helpen om de invoer te verbeteren en dan ging de boel weer verder zolang als het duurde. Wel op je sokken i.v.m. met vuil. Het was trouwens een vervelende tijd, het jaar na de fusie. Er was nog niet besloten welke machine gekozen zou worden, en er werd dus niets nieuws meer opgezet. Er was niets te doen. Jaarverslagen kleuren uit verveling. En toen de machine eenmaal gekozen was werd hij op het laatste nippertje vervangen door een 360/40 waar niemand nog iets vanaf wist. De 1401 cursus die ze gevolgd hadden was ook voor niets geweest. Vanaf de bestelling van de 360/40 gingen de nieuwe programma’s in COBOL, bij beide programmeringsgroepen. Hillard van der Steeg herinnert zich zijn opleiding tot leerling-programmeur in najaar 1967: “Wij (Leen Buitelaar, Dik Heikoop, Marijke Weststrate, Hans Broekhans en mijn persoon) zaten in een kamer op de begane grond van de nieuwbouw (Schiekade) vlakbij de directie (Nieuwland, Van den Broek en Kuyte). Van Wijk was toen nog directiesecretaris. Cursussen (Inleiding /360, Cobol en RPG) volgden we in Amsterdam bij IBM in het kerkgebouw “Het Open Hof”. Tussen deze cursussen door hielpen wij op de Hollerith afdeling met sorteren e.d . Pletser, Blom en Leentfaar waren onze begeleiders. Af en toe mochten we wat experimenteren met het maken van een eenvoudig programmabord (zo’n bord met al die snoertjes). Verder
was er genoeg tijd om ons voor te bereiden op het examen Actuarieel A. Van den Broek was daar altijd zeer geïnteresseerd in en kwam af en toe langs om ons van advies te dienen. Na afloop van de cursussen gingen we naar de dependance Kramer & Röder waar toen de afdeling Systeemanalyse en Programmering onder leiding van Van der Ven was gehuisvest. Dik Heikoop en ik kwamen bij de groep Leven Individueel, waar o.a. Bestebreurtje en Den Hond deel van uitmaakten, om onze eerste cobolprogramma’s te schrijven (P60winst en een programma voor het IVARO boek (inschrijvingen, veranderingen en royaties).”
Ponsen en terminals Zo zaten Dick van Veelen, André van der Hart en Wessel Burger achter hun bureau in 1972. Het was een kantoortuin, flinterdun groen slaapkamertapijt, de bureaus in een vlinderopstelling en veel plantenbakken en geluidschotten. Potlood en papier om te programmeren. Niks geen schermen. Cobol sheets waarop het programma gecodeerd werd. De sheets werden daarna geponst want in die tijd stonden de programma’s in ponskaarten. En moest je die zelf netjes opbergen. De bakken werden met testopdrachten ingeleverd bij de computerafdeling en dan maar wachten tot de output terugkwam. Bij de operating waren er duidelijke instructies in welke bakken de testjobs aangeleverd moesten worden en wanneer er gedraaid moest worden. Ton Modderman herinnert zich nog: Ponskaarten de trap af Elke programmaregel stond vroeger in even zo vele ponskaarten. Die ponskaarten zaten in stalen bakken. Zo heb ik eens een keer een programma dat uit 5 stalen bakken ponskaarten bestond vanaf driehoog in het trappenhuis laten vallen. Geeft effe veel rommel en lawaai. Versiebeheer in vroeger tijden Lang geleden toen programma's nog in ponskaarten waren vastgelegd, was ook al sprake van versiebeheer. Er waren van elk programma 2 versies aanwezig. De ene versie was bedoeld om verder mee te ontwikkelen en de andere versie was de productieversie. Deze versies zaten dus in stalen bakken. Nu iets over de procedure. Zodra een programma na het testen in productie kon, werd de complete set ponskaarten van de ontwikkelversie mechanisch gekopieerd. De kopie werd daarna opnieuw gecompileerd naar de productieomgeving en de ponskaarten van de oude versie werden in de bakken vervangen door de nieuwe versie. Je kon dus heel goed zien wat productie was of ontwikkelversie. De set ponskaarten van de ontwikkelversie was sterk beduimeld door het vele gebruik door de programmeurs.
Maar er gebeurden ook leuke dingen door de ponskaarten volgens Irene Oostrum: Liefde op het werk Onder de jonge meiden (tussen 15 en 20 jaar) bloeide altijd wel iets moois op. Er was dan ook een periode van verlovingen, van huwelijken en later van zwangerschappen. Ook met de programmeurs (die hun ‘correcties’) kwamen brengen werd hevig geflirt en afspraakjes gemaakt in de fietsenkelder van de Groenhovenstraat. We werden zelfs ‘omgekocht’ met snoepjes en rolletjes pepermunt in de programma’s om maar zo snel mogelijk een programma geponst terug te krijgen.
Als er in een programma maar een enkele kaart gewijzigd moest worden deed een programmeur dat vaak zelf, met de handponsmachine. Bij de operating waren er duidelijke instructies in
welke bakken de testjobs aangeleverd moesten worden. De programmalijsten waren de documentatie, die werden uiteraard ook netjes opgeborgen. En als je de lijsten niet goed opborg gebeurde het volgende: Je maakt dat af en toe wel eens mee. Het programma loopt stuk en je kan de zaak niet repareren omdat je de oorzaak niet kan vinden. Geleerde heren hadden ontdekt dat het programma in het geheugen 8 posities was verschoven. De oorzaak daarvan was onvindbaar, ondank vele interessante theorieën. Uiteindelijk na vele dagen kwamen we er achter dat het programma vlak voor het draaien was aangepast en dat de bijbehorende listing nog niet opgeborgen was. Nadat we de goede listing hadden, was het een zeer eenvoudig op te lossen standaardfoutje geworden.
In 1974 werd een proef gehouden met terminals, en in 1977 kwamen de eerste beeldschermen aan de Groenhovenstraat. Bert Rosbach vertelt er meer over: Kort na de oplevering van PCS volgde de evaluatie door de groep TSO-testers. Die groep was overigens een select gezelschap van ervaren programmeurs. Het was ons goed bevallen, met uitzondering van het lawaai. In het geval van PCS was het voortreffelijk te gebruiken omdat je de interne tabel met te selecteren rekeningnummers goed zichtbaar kon maken. Toen we daarna allemaal naar TSO gingen kregen we gelukkig een beeldscherm. Die maakten geen lawaai als er een stuk output gepresenteerd moest worden. Ook was het intoetsen van de benodigde gegevens wat geruislozer. In 1977 hadden we een open dag in KG (Kantoor Groenhovenstraat). Daarbij was ook een demo TSO op een COBOL-source, die ik met een paar anderen verzorgde. In een COBOL-source kun je de auteur meegeven. Dat deden we toen nog wel. Bij die demo geven we soms het toetsenbord over aan de gast. Dan veranderden we de naam, zetten via het repeatcommando het hele scherm vol met die naam, om het daarna met een grapje weer weg te halen. Kinderen vonden het prachtig. Als je hetzelfde door hun moeder wilde laten doen, dan kreeg je soms het idee, alsof het van de duivel was en ze hun vingers konden branden aan het toetsenbord.
Leo van den Berg weet nog dat in 1980 alleen de wijzigingen nog maar door hemzelf werden ingevoerd achter de terminal. De eerste invoer gebeurde toen nog door de ponskamer. Pas in 1985 had iedereen zijn eigen terminal. En zo zaten de heren Van Veelen, Burger en Van der Hart er in 2003 bij. De modernste bureaus, nog meer plantenbakken, en een dikker tapijt dan in 1972. Mooie platte schermen, een extra scherm voor ingescande documenten en de PC onder het bureau. Geen lijsten meer, de gegevens staan op het mainframe en kunnen elke minuut worden opgeroepen.
Talen en Ontwikkelmethodes RPG (Report Program Generator) Zowel op de 360/40 als op de 360/20 werd RPG (zeker in het begin) veel gebruikt. Je kon er heel snel lijstjes mee draaien, en eigenlijk alle mechanische apparatuur mee imiteren. Door de voorgedrukte formulieren was het eigenlijk geen programmeren, maar meestal meer coderen. Maar er werd wel flink productie mee gedraaid. Bas Snaauw weet nog dat ze naast een RPG programma ook nog een assembler programma lieten draaien op de 360/20. Dat was verboden (het operating system van de 20 kon maar één programma tegelijk aan) maar de truc was er des te leuker om. Het was bijna een vergeten taal, maar RPG kwam weer helemaal terug op de S/34 en de S/38. Het was wel een heel wat mooiere taal geworden dan de oude RPG op de veertig. Bij Leven is RPG fanatiek gebruikt. Op de AS/400 werd dan wel geen nieuw programma in RPG geschreven, maar het onderhoud vroeg nog steeds de nodige kennis. Tot in de jaren negentig werden er mensen opgeleid voor RPG. COBOL Vanaf het eerste uur werd in COBOL geprogrammeerd. Adri Vergalen heeft opnieuw blijk gegeven van historisch besef door een COBOL boek uit 1960 te bewaren. Het zit in een Oranje map met Opleidingscentrum-DP erop gedrukt, bovenaan die map staat IBM. En met de pen staat er ook nog Hans Nijman opgeschreven. En het boek was oorspronkelijk van Joost Kegge! We hebben op de CD een stukje geschiedenis van COBOL uit het boek overgenomen. Er is tenslotte geen enkele taal die het zolang uitgehouden heeft en zoveel gebruikers gehad heeft. Er is zelfs nog een streven geweest om COBOL op de PC als standaard in te voeren, maar dat is toch niet gelukt. Uit de inhoudsopgave zien we wat er in die tijd kon met COBOL. Maar een NN’er moest zich aan het rode boekje houden. Daar waren de instructies opgenomen die ze mochten gebruiken. De rest was taboe. En als je een dump had en de referencekaart hielp je niet verder, dan kon je bij Jan van der Linden de uitgebreide lijst met interrupts gaan bestuderen, en er misschien een nieuwe dumpoorzaak bij zetten.
SDM In 1970 wordt Pandata opgericht door drie Nederlandse bedrijven: PTT, AKZO en NationaleNederlanden. Eén van de eerste dingen die uit deze samenwerking te voorschijn komt is SDM, de systeemontwikkelings-methode die heel lang in gebruik geweest is bij NN. In 1987 kwam er een nieuwe versie uit, die ook wel SDM II genoemd werd. In de 2N uit 1989 wordt verteld hoe deze methode bij NN wordt toegepast.
SDW SDW (System Development Workbench) is in 1986 ontwikkeld door Pandata. Het is vanaf 1987 ingezet bij veel nieuwe projecten. Voor de eerste keer wordt de PC bij programmaontwikkeling voor het Mainframe ingezet. Ilias was een goed voorbeeld. Na de introductie van IEF sterft SDW uit. ADS ADS (Application Development System) is een aparte taal binnen IDMS. Je gebruikt hem om IDMS Maps te genereren gebruik makend van de MAPC compiler. Het is een voorbeeld van een vierde generatie taal. Hij werd vooral voor Schade gebruikt vanaf 1985. Toen DB2 werd ingevoerd verdween ADS. CSP (Cross System Product) In 1991 wordt er een proef gehouden met CSP bij Leven, VOS wordt nieuw opgezet met CICS/DB2. Iedereen is enthousiast, nu is er een vierde generatie taal met DB2. Er wordt besloten om het tool in te voeren. Zoals wel meer gebeurt bij proeven wordt VOS niet op het mainframe ingevoerd, maar blijft vrolijk op de AS/400 draaien. En door de ontwikkelingen binnen IEF sterft CSP een vroege dood. IEF (Information Engineering Facility) In 1993 verschijnt er een TOS Kompas gewijd aan Applicatiegeneratoren. Een werkgroep heeft vier producten onderzocht en komt nu met zijn conclusie. De vier producten waren ESDF HPS, Huron en Sapiens. Er wordt besloten om HPS verder te onderzoeken. Maar in de loop van het onderzoek komt IEF op de proppen en dat wordt de uiteindelijke keuze. Corine Cools schrijft in oktober 1993: “IEF is een I-Case Tool dat gedeeltelijk op het werkstation onder OS/2 en gedeeltelijk op het mainframe draait. De systeemontwikkeling vindt in zijn geheel op het werkstation plaats, enkele centrale functies bevinden zich op het mainframe. IEF biedt ondersteuning voor de gehele systeemontwikkelcyclus, vanaf informatie planning tot en met implementatie.” In 1994 wordt een proef gestart met RSL bij Leven. Die proef slaagt, en vanaf dat moment gaan alle grote nieuwe projecten met IEF. Dat mag ook wel want een IEF pakket kost ongeveer 40.000 gulden, en draait alleen maar op een zware PC. Dus het is een behoorlijke investering. Jammer dat veel van de in die tijd ontwikkelde systemen nooit verder gekomen zijn dan het teststadium. Wat dat betreft is de score van COBOL veel beter. RAD (Rapid Application Development) Bij Leven toegepast bij PC programmering. Goedkeuring van gebruikers in een vroeg stadium door middel van prototyping is de basis van deze methode.
CMM Onder de Naam SPINN (Software Process Improvement NN) wordt in 1997 een proces op gang gebracht om het softwareontwikkel traject te verbeteren. Er wordt gebruik gemaakt van CMM, het Capability Maturity Model.
Meten Meten van prestaties, plannen van projecten en beheersen van testkosten is vanaf het begin een belangrijk punt bij de leiding van SAP. Prompt Nou niet gelijk boos worden. Er roept niemand dat Prompt vandaag ingeleverd moet worden. Het wordt alleen maar besproken. Als er ooit een systeem geweest is waar iedere automatiseerder een hekel aan had dan was het Prompt wel. In 1971 wordt Prompt ingevoerd. Het werd gebruikt voor de verantwoording van de computerkosten en van de manuren. Er is een formulier uit 1971 waarmee de computerkosten van een testrun werden vastgelegd, in 1/100 uren. Maar het meest werden er toch manuren uren mee geboekt. Niet alleen bij het AC, ook bij Leven en Schade. In 1980 wordt er een rapport opgesteld over de bestaande meetinstrumenten en daarin wordt Prompt als volgt omschreven: Het Prompt-systeem heeft binnen SAP betekenis als tijdverantwoording- en planningsysteem. Per medewerker kunnen taken, onderverdeeld in subtaken, gepland worden en kan de tijdbesteding per subtaak geregistreerd worden. De gegevens per taak worden getotaliseerd naar fase/projekt/gebruiker/afdeling/generaal totaal. Gekoppeld aan de opgenomen taken kan informatie over testen opgenomen worden v.w.b. planningen en realisaties van aantal testshots en bestede CPU-tijd. Alle registratie van mantijd en CPU-tijd worden door het systeem tegen de ingebrachte tarieven omgerekend naar kosten.
Maar daarna volgt direct: De tevredenheid over het Prompt-systeem is matig en de motivatie om alle mogelijkheden van het systeem te benutten is laag. Met betrekking tot de huidige situatie zijn de volgende opmerkingen te maken: 6.4.1 Prompt is mede bedoeld als planningssysteem en biedt de mogelijkheid om aan de hand van ingebrachte planningen capaciteitsoverzichten te vervaardigen per project, functie en afdeling. Het corrigeren van eenmaal ingebrachte planningen is echter dermate veel werk dat hiervan nauwelijks gebruik gemaakt wordt. 6.4.7 Slechts voor de AC-aktiviteiten geeft Prompt een enigszins betrouwbaar beeld. De wijze waarop Prompt door de verschillende AO’s gehanteerd wordt is volledig ongecontroleerd en betekent in het ergste en zeker niet uitzonderlijke geval, een verantwoording van 40 uur per week op een willekeurig nummer .
De leiding van de AO’s zal het met de laatste opmerking niet helemaal eens zijn geweest. Als José Killian bij AO Schade in 1992 een rapport schrijft over een factureringssysteem voor automatiseringskosten, geeft ze een samenvatting van het gebruik van Prompt. Binnen NN-Schade hanteren de automatiseringsafdelingen Nieuwbouw en Onderhoud & Beheer het door AN beheerde PROMPT (PROgramming, Monitoring and Planning Techniques) als tijdschrijfsysteem. Van dit systeem is voor deze studie van belang dat het, naast het plannen van de werkzaamheden, gebruikt wordt als basis voor de doorbelasting van de mankosten die met het ontwerpen en beheren van systemen gepaard gaan.
Niet iets wat je op schrijft als er niets met Prompt gedaan wordt. Al moet er bij gezegd dat Schade op dat moment Prompt wil gaan vervangen. En bij Leven schrijft Dick van Valkenburg in 1980 in INFOO:
Bij Leven wordt Prompt ook rond 1992 afgeschaft en vervangen door BOMIS en allerlei programmaatjes op de PC om schattingen te maken.
Het AC gaat nog even door na 1992 (daar hadden ze wat extra programma’s gemaakt om de rapportage naar de leiding wat makkelijker te maken) en gaat dan over op PIT. In 2002 legt René Landsman nog eens een keer uit waarom PIT er is: om goede nota’s bij de klant te krijgen. Plannen Als hulpmiddel voor de planning treffen we in 1975 een paar formulieren aan. Ze worden in 1980 bij het Metingen rapport niet meer genoemd. En Prompt was natuurlijk ook bedoeld om te plannen. Maar daar kwam in de praktijk niet veel van terecht. Bij IFPA, dat in 1990 wordt ingevoerd bij NN, is het opstellen van de planning één van de doelen. Edith Verheusen schrijft in TOS Kompas in 1994: Het doel van het gebruik van IFPA binnen het concern en de uitvoering van een IFPA-telling is drieledig: - Het vaststellen van de omvang van een systeem in een vroegtijdig stadium van een projekt ter ondersteuning van het maken van een planning. - Het na afloop van een projekt kunnen bepalen van de behaalde produktiviteit (werkelijk bestede uren in verhouding tot het aantal funktiepunten). Met deze nieuwe produktiviteitscijfers kan het gemiddelde worden gecorrigeerd, zodat de nieuwe planningen hierop kunnen worden gebaseerd. - Het kunnen vaststellen van de toename van de funktionaliteit van een systeem door het vergelijken van tellingen die zijn gemaakt na het Basisontwerp en na het gereedkomen van het projekten
Een paar jaar later wordt met IEF weer een andere funktiepunt analyse in gebruik genomen. Andere registraties Behalve Prompt worden in het Metingen rapport nog twee overzichten genoemd die ook echt gebruikt worden. Het zijn de performance meting SAP NS, die metingen per module geeft en de TSO lijsten waarin per medewerker per TSO sessie tijdsduren en kosten vermeld worden.
HBSO In 1979 schrijft Joop Hakkennes: De richtlijnen Programmering in hun huidige vorm zijn in het grijze verleden ontstaan als een voorlopige noodoplossing, na een rapport van Hendriks, Verbaan en Van Zaanen d.d. 15-2-72, door het verzamelen van allerlei, tot dat moment verschenen, losse circulaires. Ondanks vele uitbreidingen en verfraaiingen is de opzet nooit gewijzigd en daardoor is een tamelijk onsamenhangend (afgezien van wat verwijzingen over en weer) geheel ontstaan. Van de problemen, die aan de huidige opzet verbonden zijn, zijn de belangrijkste: - Richtlijnen Detailontwerp, Basisontwerp, e.d. kunnen moeilijk worden ingepast. - De ordening is per onderwerp en niet per aktiviteit, waardoor de richtlijnen niet als een echt richtsnoer bij de systeemontwikkeling gebruikt kunnen worden. - Door het verzamelen van alle informatie per onderwerp (bijv. JCL) ontstaat een mengsel van richtlijnen, gebruiksaanwijzing en (soms) motivering. - Op veel punten is er geen goede aansluiting van de richtlijnen op de diverse kursussen. De inhoud van de kursussen zou in de richtlijnen terug te vinden moeten zijn, zodat bijv. gewijzigde inzichten ook doordringen tot de mensen die een kursus waarin dit verteld wordt al gevolgd hebben. Om aan dit soort problemen het hoofd te bieden is m.i. een totaal andere opzet gewenst, waarvoor hierna een voorstel volgt. Er zou een "Handboek Systeemontwikkeling" moeten komen, bestaande uit drie delen: 1. Richtlijnen 2. Technieken/Methodieken 3. Hulpmiddelen.
Bij dit verhaal is een inventarisatie bijgesloten van alle “richtlijnen:” Gijs van Zaanen (rechts op de foto, links Kees Heijning) krijgt de opdracht een dergelijk Handboek Systeemontwikkeling samen te stellen. In 1985 zijn er twee delen klaar: deel 1 Beschrijving werkmethodes en Deel 3 Beschrijving hulpmiddelen. Deel 2 is er nog niet. Van 1985 tot 1988 wordt er driftig heen en weer gepraat over verbeteringen. Een voorbeeld van zo’n discussie is het bijgaande verhaal over verschillen in systeemontwikkeling. Jan van der Linden, belast met de leiding van Schade, geeft de verschillen aan in systeemontwikkeling tussen Leven en Schade.
Zo’n tendentieus verhaal wordt niet gepikt door de Leven mensen, en dezelfde dag schrijven ze een weerwoord:
Ondanks deze verschillen komt het er dan toch van. In 1988 worden de voorstellen van Piet Brijs en Jan van der Linden uitgevoerd, er komt een HBSO. Uit de naam moet al blijken dat in dit handboek alle regels staan. Alle losse regels en instructies zijn naar de prullenbak verwezen De hoofdstukindeling met de geplande manmaanden: Deel 1 Algemeen Deel 2 Organisatie Deel 3 Systeemontwikkeling Deel 4 Technieken en methoden Deel 5 Hulpmiddelen AO Deel 6 Hulpmiddelen SO
1 manmaand 5 manmaanden 5 manmaanden 5 manmaanden 5 manmaanden samen met deel 5
Deel 7 Technische zaken algemeen Deel 8 Technische zaken PC Deel 9 Beveiliging Deel 10 Standaards en controles Deel 11 Formulieren 1 manmaand
2 manweken 1,5 manmaand 1 manmaand 1 manmaand
Totaal
26,5 manmaanden
Jan van der Linden herinnert zich uit die periode nog het volgende: Bij het schrijven van het HBSO werden veel medewerkers ingeschakeld om een hoofdstuk te maken. Ik zelf kreeg hoofdstuk 8 toegewezen. Wanneer een versie klaar was gaf Gijs van Zaanen persoonlijk commentaar. Nadat ik versie 7 had ingeleverd was het commentaar als van ouds: niets was goed, het moest geheel anders. Daarop heb ik versie 1 van het verhaal opnieuw ingeleverd, hetgeen onmiddellijk wordt goedgekeurd.
In 1989 is de klus klaar en vanaf dat moment staan er op iedere afdeling van Systeemontwikkeling een 11 tal delen te pronken. Jammer genoeg is er ook nog zoiets als onderhoud. Dat betekent om de twee maanden een zogenaamde HBSO wijzigingsronde, waarbij alle delen bijgewerkt moeten worden door de administratieve krachten. Op sommige afdelingen gebeurt dat wat onregelmatig (het is een vervelende klus) en daarom ligt er wel eens wat achterstand. Het is de bedoeling om bij elk nieuw project eerst de betreffende hoofdstukken in het HBSO te raadplegen, maar als ik in 1992 als nieuwkomer bij Leven op zoek ga naar het HBSO is er eigenlijk maar één exemplaar bij (BOC, op dat moment de afdeling van Jan van der Linden) de rest loopt achter of slechts de oude garde weet waar het staat. Bij Leven speelt het handboek dus geen grote rol. In 1995 wordt het handboek online gezet. Foto’s De programmeursafdeling in 1972 (Schiekade) met op de voorgrond Ben van Geffen (bekend schaker). Op de andere foto Wessel Burger die zijn programma “update” door ponskaarten daarin te vervangen.
De Uitvoering Organisatie In de loop van de jaren wijzigt de organisatie van de productie natuurlijk geregeld. Er zijn drie groepen constant. De Operating, de Werkvoorbereiding en de Invoerafdeling. De overige functies zoals Kontrole/Kontakt, Systeemprogrammering, Planning en Nabewerking worden in de loop van de jaren voortdurend herschikt en herbenoemd. Verder zien we bij de ondersteuning een groep Telecom ontstaan, die in de loop van de jaren uitgroeit tot een aparte poot. Jan Rotteveel krijgt hierover de leiding. Op de foto drie leidinggevenden van de uitvoering in 1970. Van links naar rechts : Leen Velthuizen, Joop Fokke en Thijs Blom Er wordt in ploegen gewerkt. Twee, eventueel drie shifts. In 1971 komt er een circulaire die de ploegendienst regelt na de verhuizing naar KG. Uit deze circulaire kun je afleiden dat er in Rotterdam ook al zo’n regeling was vóór het jaar 1971. In 1973 hebben we een afdeling Produktie onder leiding van Van Deursen, en daar onder de groepen Werkvoorbereiding, Operations en Kontrole/Kontakt. Wim van Berkum, Dick de Paus en Hans van Moerkerken zijn bekende werkvoorbereiders in die tijd. De shiftleiders hebben functionele verantwoordelijkheid. In 1982 zijn er vier groepen: Werkvoorbereiding, Kontrole, Operations en Nabewerking, onder hiërarchische leiding van de afdeling Shiftleiders. In 1986 zijn er drie groepen. Operations, Werkvoorbereiding en Kontrole en Nabewerking, hiërarchische vallend onder de groep Produktiebeheer. In 1991 wordt de Wilgenplas betrokken. De uitvoering van AN en RVS worden samengevoegd, en de bediening van de AS/400 van de Schiekade gaat ook naar WP. Er wordt een drieploegendienst ingevoerd. Kennelijk was de derde shift na 1971 verdwenen. Jan van der Linden merkt op dat er normaal twee ploegen waren, maar dat er zo nu en dan, bij grote drukte (eind van het jaar of bijzondere klussen) in drie ploegen gewerkt werd. In 1993 wordt het contact naar de klanten geaccentueerd, en praten we over Relatiebeheer. Er wordt in SO Kompas een artikel gewijd aan deze reorganisatie. Er wordt ook een aantal plannen voor de toekomst aangegeven. Afschaffen van de nachtploeg in 1996 is er één van. In plaats daarvan werd het 7 dagen per week 24 uur.
Directeur speelt voor operator Als je de foto’s in de Schakel en 2N wilt geloven zijn directeuren de operators. Als er een nieuwe machine in gebruik genomen wordt, staat er altijd wel een directeur de knoppen te drukken of boter kaas en eieren te spelen. Systeemprogrammeurs en chefs willen ook nogal eens achter het console plaatsnemen voor de foto. Of we zien een lege zaal die suggereert dat alles vanzelf gaat.
Zelfs als de mensen die op de foto gingen bij de computerafdeling horen (Huub Klunder met een bezoekster, Coby Schoneveld), zie je ze nog niet bezig met het dagelijkse werk. Want als je operator was op de 1401, de 650 of later op de kleine systemen dan stond je ponskaarten in te lezen, uren achter elkaar. Of je stond volle dozen zebrapapier leeg te printen. En als I/O operator sleepte je met tapes en diskpacks. De glamour van de man die achter het console de computer bediende ging ook voor de console operator niet helemaal op. Natuurlijk bediende je het console, maar meestentijds was je met JCL bezig. En die stond in de begin jaren echt nog op kaart.
Pas nadat een paar jaar met de 158 was gewerkt gingen beeldschermen voor de bediening een rol spelen. En kon je zittend een mountopdracht doorsturen aan je collega bij de tapes. Uiteindelijk kon de console operator het hele netwerk bedienen vanuit zijn stoel. En in 2005 zelfs een zaal in Arnhem vanuit WP. De verantwoordelijkheid ’s avonds en ’s nachts hoeft meestal niet gedeeld te worden, iedereen is blij als hij thuis mag zitten. Maar bij incidenten overdag bemoeit Jan en alleman zich er mee. In de beginjaren stond er dan ineens een systeemprogrammeur op de vloer die het overnam, maar later verdwenen de consoles soms onder je handen vandaan, omdat iemand van Telecom of Systeemprogrammering zonder overleg besloot het van je over te nemen.
Werkvoorbereider Het meest verguisde vak binnen de automatisering. Als we bijvoorbeeld dit stukje tekst uit het Otto Dicke verhaal uit 1970 lezen wordt de werkvoorbereider in de laatste alinea wel heel makkelijk weggezet. In het boekje met functies uit 1973 krijgen we een heel wat meer afgewogen beeld van de werkvoorbereider. De lastigste taak was (en is) het accepteren van de rundiagrammen, de nieuwe programma’s van de systeemontwerpers. Natuurlijk is er al die jaren een perfecte beschrijving geweest van wat er aan documentatie aanwezig moest zijn bij overdracht, maar als er ergens tegen gezondigd werd, was het hier tegen. Het maken van JCL en de documentatie voor de uitvoering was niet moeilijk, maar wel als de programmeurs de programma’s over de schutting gooiden. Of op het laatste moment nog een wijziging hadden die echt die avond nog mee moest. Ook de operator die de bijgevoegde instructie niet las, maar gewoon begon, waardoor die job over moest, gaf veel irritatie.
Handleidingen Het Handboek Operations uit 1972 dat Jan van den Broek (hiernaast rechts op de foto samen met Dik Heikoop) bewaard heeft, is onderdeel van een Handboek A.C. De eerste wijzigingsmededeling is van 12 mei 1972. Samensteller is de afdeling AO van het AC, maar “de afdelingen S.O.S (Systeem Ondersteuning Systeemontwikkeling) en Productie Algemeen zijn in eerst instantie verantwoordelijk”. In 1976 kunnen er ook richtlijnen opgenomen worden voor de overige werkzaamheden van de sector Produktie en de naam luidt daarom voortaan Richtlijnen voor de sector Produktie (RSP). Naast algemene regels (niet roken op de zaal, ieder is verantwoordelijk voor orde en netheid) is er een hoofdstuk voor Noodsituaties, een beschrijving van alle computers en de randapparatuur, de aanwezige software en hoe te handelen bij allerlei voorkomende situaties. De inhoudsopgave 16-1-74 geeft de details. Het voorbeeld van een jobbegeleidingsformulier met de instructie over invullen geeft de mate van detail aan waar het handboek zich mee bemoeide. En de kontakten tussen WVB (Werkvoorbereiding), Computers en KK (Kontrole Kontakt) zeggen iets over de wijze van communicatie in die tijd.
In het overzicht van Joop Hakkennes uit 1979 worden ook de richtlijn “overdracht aan produktie” genoemd in het Handboek AC. Er wordt op dat moment een begin gemaakt met het HBSO, waarvan Hakkennes opmerkt “dat het vervaardigen in een tamelijk strakke planning moet plaatsvinden, om te voorkomen dat een soort Handboek AC ontstaat met veel tabbladen en weinig inhoud”. Of deze opmerking zo lelijk bedoeld is als hij er staat, zal altijd wel een geheim blijven. In een memo van 1986 van Jan van der Linden staat een voorstel voor een andere hoofdstukindeling van het HBSO, waarbij het bestaande hoofdstuk 1.6.3. Overdracht aan Produktie wordt genoemd. In 1988 bestaat het uit blz. 10 t/m 90. De invoering van Endevor in 1992 zorgt voor een stroomlijning van de overdracht, de invoering van Changemanagement in 1994 verhoogt de grip van de uitvoering op wijzigingen. Al vonden vele systeemontwikkelaars het maar ambtenarij, zeker toen eind 1999 de hele overdracht ook nog eens door de directie moest worden goedgekeurd i.v.m. de eeuwwisseling. (dat duurde trouwens maar twee maanden).
Hulpmiddelen uitvoering Scheduling en Tapemanagement. Huub Klunder vertelt hoe de gang van zaken was voor er sprake was van een schedulingspakket: Voordat een schedule/planningspakket werd ingevoerd, werd als volgt gewerkt. De afdeling Planning van Fred Desmet maakte aan de hand van aan hen toegestuurde opgaven per plandag een overzicht waarop de jobs stonden die op een bepaalde plandag moesten draaien. Hierbij waren jobs die zonder afhankelijkheid direct konden draaien. Uiteraard stonden er ook jobs op die een afhankelijkheid hadden, bijvoorbeeld van invoer van Invoerverwerking. Deze jobs werden pas aangeboden aan het systeem op het moment dat de invoer aanwezig was. Voor de onderlinge afhankelijkheid tussen jobs werd gebruik gemaakt van het door Dik Heikoop geschreven programma "COMMANDS". Hiermee konden jobs worden geactiveerd of reset. Dit programma was dan het laatste programma van een totale job met programma’s.
Voordat CA1 werd gebruikt, werden aan de hand van de joblogs de nummers van gemaakte tapes genoteerd en ingevoerd in de tapeadministratie. Dit pakket voorzag ook in een opgave van tapes die weer vrij kwamen, dus waarvan de retentieperiode was verstreken. Er was geen enkele koppeling tussen de tapeadministratie en de catalog, zoals dat bij CA1 wel het geval is.
In 1987 wordt het scheduling pakket UCC 7 geïnstalleerd. Dit pakket wordt later omgedoopt tot CA 7. In de plannen voor 1993 wordt een overgang aangekondigd naar OPC/ESA, het scheduling pakket van IBM. In 1988 neemt CA1 de plaats in van de tapeadministratie. Netview Dit pakket voor de controle van het netwerk werd in 1988 ingevoerd. BUNDL In 1991 wordt Bundl ingevoerd, een pakket voor de distributie van de output. Dick de Paus schrijft er een stukje over. Endevor In 1992 wordt Endevor ingevoerd, een pakket om overdrachtsprocedures tussen verschillende omgevingen te standaardiseren. TOS Kompas geeft bij monde van de werkgroep Endevor een samenvatting van het systeem. SMS (System Managed Storage) SMS maakt het mogelijk de specificaties van bestanden los te koppelen van de karakteristieken van de opslagmedia. Bestanden kunnen gewoon op schijf staan, gecomprimeerd op schijf staan, of op tape zijn gearchiveerd. Dit pakket vroeg een stevige conversie, maar gaf een nieuwe kijk op het opslaan van gegevens. In 1994 geeft Kleywegt een toelichting op dit pakket waarvan de invoering gestart was. In 1995 nog wat meer details in IT Kompas.
Insluitstraat Machines om output te verwerken zijn er al zo lang er printers bestaan. Hak- en burstmachines waren er al in de Hollerithtijd. Later kwam daar de insluitmachine bij. Salarisstroken, winstbrieven, belastingopgaven, er kwamen steeds meer formulieren die automatisch ingesloten en verzonden konden worden. In 1992 wordt er een moderne insluitstraat geïnstalleerd. In 1994 wordt er een selectief reprint programma gemaakt, om door de insluitstraat kapot gemaakte formulieren over te maken, zonder de klant lastig te vallen. Aad van der Spek (voormalig Postbanker) nu bij AN
AS/400 Er was in de loop van de jaren rondom de S/38 een produktieafdeling ontstaan bij Leven. Nadat de eerste online koppeling naar het mainframe in 1981 was gemaakt nam het aantal toepassingen hand over hand toe. Binnen enkele jaren stonden er drie machines, en het aantal operators groeide mee. In de kwaliteitskrant Blijvend Beter uit 1989 staat een stukje over de servicegerichte afdeling Produktie. Hierbij wordt ook even de ploegendienst aangetipt. Er waren bij Leven minder regels waar de operators zich aan moesten houden. Er moest zeker in het begin wat meer geïmproviseerd worden en dat werkte door in de totale aanpak van de afdeling. Afzetten tegen het logge apparaat van het AC was normaal. De overkomst van Ger Leentfaar (zie foto), die jarenlang leiding gegeven had bij AC Produktie, kon die mentaliteit niet veranderen.
Toen dan ook de AS/400 in 1991 verplaatst werd naar WP, voelden de meeste operators er niets voor om overgeplaatst te worden. Ze wilden, nadat ze de kennis hadden overgedragen, weer terug. Na zes maanden gebeurde dat ook. Uiteindelijk bleef er maar één operator bij AN. Het duurde dan ook even voordat alle ploegen de trucjes van de bediening van de AS/400 onder de knie hadden, dit tot grote verontwaardiging van de oude AS/400 ploeg, die soms met stijgende verontwaardiging meekeek vanaf de Helpdesk Leven.
Nadat alle procedures, vooral die van Postinfo nog eens op een rijtje gezet waren, werden alle SLA’s voor de AS/400 weer ruimschoots gehaald.
Tegenwoordig wordt de AS/400 niet alleen voor Leven maar ook voor de Postbank en de RVS gebruikt.
De ponskamers In 1956, bij een uitvoerige behandeling van de Ponskaartenadministratie, wordt voor het eerst een foto gemaakt van een ponstypiste bij De Nederlanden. Maar toen waren ze al een paar jaar aan het werk. Na de oorlog werden op alle ponskamers in Nederland vrouwen in dienst genomen om ponsformulieren om te zetten in ponskaarten. In de verzekeringswereld en ook bij NN is het altijd een vrouwenberoep geweest. Middenin het mannenbolwerk, wat de automatisering in het begin was, zaten daar veertig tot vijftig, overal het algemeen jonge, meisjes en vrouwen, met veel lawaai ponskaarten aan te maken. Het lawaai kwam van de machines, want tijdens het ponsen kon je niet praten. In 1958 wordt mevrouw Schuijer benoemd tot chef de bureau op de ponsafdeling. Dat blijft ze tot ze in 1968 met pensioen ging. Maar dan is het wel in 1963 één van de ponskamers van het AC geworden. Van Hoewijk volgt haar op. De andere ponskamer is uiteraard ontstaan uit die van de Nationale. Er waren daar heel wat dames nodig vanaf het moment dat de 650 administratie voor individueel ingevoerd werd. Die conversie vroeg nogal wat ponskaarten (minimaal zes per verzekering). Een kijkje in de ponskamer in 1966 laat slechts een klein gedeelte van de afdeling zien, en dan ook nog op de rug. Het eerste concrete aantal dat we kunnen vinden dateert van 1969, dan zijn er 41 dames in Rotterdam. Ans Wagenaar heeft daar de leiding. In datzelfde jaar krijgen we ook nog een overzicht van een groter gedeelte van de zaal dan in 1966. Met bezoek van buitendienst mensen. Die moesten altijd op de ponskamer kijken, zeker nadat in 2N deze foto met Lenie Luneberg gestaan had. Dat zou je nu toch niet moeten flikken, met als onderschrift dat er nog veel fotogenieke schatjes rondlopen bij NN. In 1973 hebben we een organisatieschema waarin Wagenaar (zie foto hiernaast) de algehele leiding heeft van beide ponskamers, met in Rotterdam Steylen en in Den Haag Van Hoewijk als direct verantwoordelijke. Een fotootje uit 1974 in Den Haag genomen laat de Univac apparatuur zien en de 026 en 029 van IBM. Tegen die tijd worden de ponsmachines langzaam maar zeker vervangen door MDS apparatuur. Hierbij worden de gegevens vastgelegd op tape. De tape wordt ’s avonds naar het rekencentrum gebracht. Begin jaren tachtig wordt de tape vervangen door een RJE aansluiting, de gegevens gaan rechtstreeks naar de computer in KG.
De allerlaatste ponsmachine (Univac) heeft nog heel erg lang eenzaam en alleen verstopt in een hoekje op de grote Ponszaal in HKR gestaan. Deze stond er voor noodgevallen die nog op ponskaarten moesten worden verwerkt. Deze machine heeft er zeker tot 1985 gestaan. Tussen 1970 en 1980 is het verschrikkelijk druk op de ponskamers. Er is veel verloop, dus er komen ook veel nieuwe dames binnen. Op elke introductiecursus zitten wel een paar ponstypistes. Vooral augustus en september waren dé maanden. Ze doen mee met de introductie van de gebouwen waar ze in werken, want met het AC hebben ze eigenlijk niet zo’n band. In de tachtiger jaren zien we de teruggang van de centrale ponskamers. Interactieve invoer wint veld, langzaam maar zeker verdwijnt de ponsinvoer. In Den Haag gaat het harder dan in Rotterdam, het begint in 1980 met de AVP, het eindigt in 1989 met de restadministratie. Maar dan is de Haagse ponskamer al lang opgeheven (1979), alles wordt nu naar Rotterdam gestuurd. In 1990 draagt het AC de ponskamer over aan Leven, Wim Combé wordt verantwoordelijk, en mag afbouwen. Maar eerst moet er nog even verhuisd worden naar de Zalmstraat, totdat DP klaar is. Ans Wagenaar verdwijnt in 1993 naar de telefooncentrale in HKH, en Irene Oostrum mag, samen met de chef van EXO, Henk de Jong, de laatste loodjes dragen. Ze wegen zwaar omdat er niet voor iedereen vervangend werk is. Dat geeft een vervelende sfeer op het laatst. In 1994 is het voorbij. De laatste LEGO mutaties, werksoort 7500, worden ingevoerd en overgezonden. Irene vertrekt als laatste, naar INO als administratief medewerkster. Naast de ponskamer was er nog invoer op de boekhouding. Die gebruikte daar eerst boekhoudmachines, later een Philips X –1150 voor. Bij De Vaderlandsche stond Nixdorf apparatuur. Dat zal dan wel een Nixdorf 820 geweest zijn. Als aanvulling hier de persoonlijke herinneringen van Irene herself. Die heeft het echt allemaal meegemaakt.
Van ponstypiste tot secretaresse MT Op 18 september 1972 ben ik in dienst gekomen na een ‘open’ sollicitatie. Na een test werd ik geplaatst op de Ponskamer voor het ‘riante’ salaris van fl 315,00 voor 5 dagen. Toen waren we nog verplicht om één dag in de week deel te nemen aan partiële leerplicht, dus moest ik 1/5 van mijn salaris inleveren. Hetgeen neerkwam op een salaris van fl 252,00 en daar ging nog iets van inhoudingen af waardoor ik ongeveer fl 220,00 per maand kreeg. Belastingen hoefden we vanwege onze jonge leeftijd nog niet te betalen. De eerste werkdag Het ging al meteen mis, ik moest me melden op de Prinses Beatrixlaan 15 voor een introductie ochtend. Dit stond in mijn bevestiging. Doordat ik halverwege de maand begon (18 september ’72) hadden ze niet in de gaten dat er dan géén introductie werd gehouden. Dus ik weer op mijn vouwfiets naar de Groenhovenstraat waar de Ponskamer zetelde. Aan de slag Doodnerveus mocht ik beginnen met oefeningen. Op een ‘handkar’ zelf een ponskaart er in stoppen en de cijfertjes 1-2-3-4 uit den treuren intoetsen. Het ging heel erg zwaar en als je een hele grote
stapel had gedaan moest je dit laten controleren door de cheffin Mw. Van Hoewijk. Ze maakte dan een mooie stapel en keek dan door de ‘gaatjes’ of deze allemaal op dezelfde plaats zaten. Als dat zo was dan mocht je verder met de volgende cijfertjes 2-3-4-5. En zo ging je door tot je alle cijfers van 1 t/m 0 (de 0 was het laatste cijfer) had gehad. Na 2 weken had ik het wel gezien en wilde ik graag op een ‘echte’ ponsmachine gaan werken. Dit verzoek werd ingewilligd. Ik mocht op de IBM 29 simpel ponswerk gaan doen. Een machine die direct een gaatje maakte van het cijfer of de combinatie die je had ingetoetst. We sloegen heel vaak mis, dus er gingen heel wat ponskaarten de prullenbak in. Na hier weer een maandje op te hebben gewerkt wilde ik weer een stapje verder en mocht ik op de Univac 2410 gaan werken. Dit was een snellere machine met geheugen. Je toetste eerst alles in en als de kaart eruit werd ‘gespuugd’ werden ook de gaatjes in de kaart gestanst. Op deze machines werd ook ‘controle’ geponst. De stapel kaarten die door de beginners waren geponst werden weer in de machine gestopt en de cijfercombinaties of letters werden weer ingetoetst. Wanneer er een fout was aangetroffen ging er een rood lampje branden en moest er een nieuwe kaart gemaakt worden. Van ponskaart naar magnetische tapes Medio 1973 werd in de Rotterdamse ponskamer gestart met het MDS (Mohawk Data entry Systeem). Dit was een systeem bestaande uit een CPU, Diskdrive en een tape unit. Alle gegevens die normaliter op ponskaarten werden ingetoetst werden nu opgeslagen onder een batchnummer op de disk. Door middel van een toetsenbord en een klein beeldschermpje kon je zien wat je intoetste. Ook konden de records, zoals de ponskaarten daarna werden genoemd, worden verlengd van 80 characters naar 125. Zelfs records van 250 posities (characters) konden worden gemaakt.
Door een supervisor werden de batches op een tape gezet die vervolgens met de pendel naar de computerruimte in de Groenhovenstraat werden gebracht. Elke werksoort had een eigen tape die voorzien was van een tapelabel zodat de operators wisten welke werksoort ze ontvingen. Nadat we allemaal een weekje naar Rotterdam waren gezonden om te leren werken op het MDS systeem werd ook in Den Haag dit systeem neergezet. Er werden 2 supervisors aangesteld. Bep van der Winden van de Haagse ponskamer en Johanna Smits kwam over uit Rotterdam. Met de ingebruikname van het MDS systeem ging Ans Wagenaar de scepter over de Haagse en Rotterdamse Ponskamer zwaaien. Dit zorgde voor de nodige commotie, want deze dame wist wel
van wanten. Wie niet luisteren wilde, kon haar carrière elders gaan voortzetten (ontslag). Met hoogrode wangen en het zweet in mijn handen ging ik door met mijn werk. Er was in de periode heel veel achterstand. We hebben met ca. 150 datatypistes (verdeeld over Rotterdam en Den Haag), met heel veel overwerk, uitbesteding van werkzaamheden aan Service Bedrijven en zelfs met avondploegen, de achterstanden kunnen wegwerken. We werkten toen al met planningsroosters, want dagwerk moest dezelfde dag nog gedraaid worden op de computers. We hadden ook maand-, week-, kwartaal- en jaarwerk. In die periode zijn ook LABORA en LEGO ingevoerd. Om er nog een paar te noemen: Hypotheken, Restadministratie, Medisch Fonds, ER, Fatum, Brand, AVLI en OVLI, HIS, CIS, Bromfietsverzekeringen, etc. Ook de tijdverantwoording (PROMPT) van de programmeurs werd door ons verwerkt. Evenals de programma’s (Cobol) die door onze programmeurs werden geschreven werden door ons ingevoerd. Het was niet altijd even makkelijk om die ‘rare teksten’ in te toetsen. Na een maand of 6 vroeg Ans Wagenaar of ik Supervisor wilde worden. Hier had ik wel oren naar en zo werd ik gedurende een jaar ingewerkt. Ik leerde hoe je de data van disk op tape kon zetten, maar ook hoe je programma’s kon maken. Deze programma’s zorgden ervoor dat er blanks (skippen) kwamen waar blanks moesten en ook het uitvullen met nullen kon je helemaal voorprogrammeren. Ook vaste gegevens kon je opgeven en alfabetische en numerieke velden kon je van te voren bepalen. Na een jaar werd ik bij de directeur, Dhr. Van Wijk, geroepen en kreeg ik mijn officiële benoeming tot Supervisor. Dit werk heb ik tot medio november 1990 gedaan. Toen was de Invoerverwerking al in de afbouwfase en zaten er nog slechts 6 dames op de afdeling. Deze zijn later elders binnen ons bedrijf geplaatst of hebben ontslag genomen. Verplicht pauze houden Als je zulk geestdodend werk doet, ben je verplicht om elk uur een kwartier rust te houden. Omdat het vervelend is om elk uur van het werk te moeten, werd er na 2 uur werken een half uur pauze ingesteld. Dit werd meteen gecombineerd met één kop koffie ’s ochtends en ‘s middags één kop thee. Ik weet nog goed dat de serveerster (de koffie of thee werd toen nog uitgeserveerd) niet eerder dan de afgesproken tijd de afdeling op mocht komen. Zij stonden dan ook geduldig te wachten totdat het precies 10.00 uur of 14.45 uur was. Liefde op het werk Onder de jonge meiden (tussen 15 en 20 jaar) bloeide altijd wel iets moois op. Er was dan ook een periode van verlovingen, van huwelijken en later van zwangerschappen. Ook met de programmeurs (die hun ‘correcties’) kwamen brengen werd hevig geflirt en afspraakjes gemaakt in de
fietsenkelder van de Groenhovenstraat. We werden zelfs ‘omgekocht’ met snoepjes en rolletjes pepermunt in de programma’s om maar zo snel mogelijk een programma geponst terug te krijgen. Ook werd er driftig geflirt met de technische dienst (Jaap de Vreugd) en monteurs van het MDS Systeem. En mevrouw Wagenaar maar boos kijken naar ‘haar’ meisjes!! Ook was er wel eens een flinke ruzie, vooral de oudjes van de Oude Haagsche mej. Els Kuipers en Soelani konden flink 'bekvechten' met elkaar. Ook Edith Goor en mej. Vollenhoven en Veldhoven konden er wat van. (Els Kuipers en Edith Goor hebben nog op de Wilgenplas gewerkt). Ponstoelage Als bleek dat je het toetsenbord een beetje begon te beheersen mocht je een soort van examen doen om in aanmerking te komen voor een ponstoelage. Dit bestond uit vier examens waarmee je resp. 30, 60, 100 en 250 gulden per maand opslag kon krijgen. Verhuizingen Toen al werd regelmatig verhuisd. Binnen HKR (Schiekade) zijn er vele verhuizingen geweest, zelfs naar de Coolse Poort (Coolsingel) en de Westerstraat (RVS). Totdat we naar Delftse Poort gingen. Daar zijn we in een klein achterzaaltje gezet, want we zaten toen al in de afbouwfase. We waren de allereerste afdeling die hun intrek nam in DP. Met een Champagne ontbijt werden we onthaald. De leiding In Den Haag werd de afdeling gerund door mejuffrouw Knijf (groepshoofd) en mevrouw Van Hoewijk (cheffin). Vanaf 1974 daarbij assistentie van de Supervisors Bep vd Winden, Johanna Smits, Irene Oostrum en Klazien den Dulk. In Rotterdam werd de scepter gezwaaid door Agnes Steijlen, mejuffrouw Klein en later ook weer Johanna Smits (beiden groepshoofd) en de Supervisors Mieke Feijen, Jolanda Stoter, Corry Zoutewelle, Irene Oostrum (kwam in 1976), Marian Bredius, Nel de Gids, Sonja van der Poort. Over deze hele club was mevrouw (Ans) Wagenaar uiteindelijk de echte baas. Ook op 2e echelons niveau hebben we veel bazen gehad. Te weten: dhrn. Van Wijk, Van Deursen, Huizinga, Beumer, Pletser, Van der Ven, Hakkennes, Combé en uiteindelijk Opmeer.
Ook dhrn. Blom en Leentfaar waren veel geziene heren op onze afdeling. Voor ons waren dit volslagen onbekenden, want we mochten eigenlijk met niemand contact hebben (!!) Een ‘vroegertje’ Vele afdelingen waren jaloers op het feit dat we al vroeg naar huis mochten als er geen werk meer voor ons was. In de afbouwfase kwam het regelmatig voor dat er na de lunchpauze geen werk was. Dan mochten we per toerbeurt eerder naar huis. Er werd natuurlijk vaak extra hard gewerkt om maar zo snel mogelijk naar huis te gaan. Dit was vaak al vanaf 13.30 uur. Ook gebeurde het dat er ’s ochtends van 10.00 – 12.45 uur (want dan kwam de pendel met een nieuwe zending) geen werk meer was. We waren dan vaak te vinden op de Lijnbaan of er werd driftig gebreid op de afdeling. Irene Oostrum En dan (op de CD) een serie foto’s uit het boek van Irene. Met namen. Tenminste… bijna alle namen.
Algemene Zaken Naast de sectoren Systeemontwikkeling en Produktie was er binnen het AC ook een sector Algemene zaken. In 1986, na de gehouden Alloway enquête, bestond Algemene Zaken uit de volgende afdelingen: Coördinatie, Advisering, Systeemarchitectuur en Onderzoek (CASO); Informatiecentrum; Personeelopleidingen en Publiciteit; Interne Zaken.
Aan het Informatie Centrum, Opleidingen en Interne Zaken (o.a. inkoop en kosten(doorbelasting) is elders in dit boek reeds enige aandacht besteed. CASO was een afdeling bestaande uit consultants die wereldwijd werden ingezet. Jacques Etienne was de oprichter van deze afdeling. Behalve de in het schema genoemde namen hebben ook Fred Buurmans, Willem Korteweg, Jack Jansen, Dick van Gijzen, Koos ter Beek, Jan van der Hauw, Johan van der Wal, Cok van Oosterhout, Hoejenbos en Tuijnman deel uitgemaakt van CASO.
Hierna nog enkele foto’s van een gezellig etentje met leidinggevenden van het AC (omstreeks 1987). Van links naar rechts: Matthijs Glastra, Willem Korteweg, Giel Keijzer en Ton van Rijn
Voorste tafel van links naar rechts: Jan Rotteveel, Willem van Ruitenburg, Cees Jacobs, Piet Brijs, Dick de Paus, Ton van Lierop, Jan Beumer, Jack Jansen en op de rug gezien Eibert Renes
En tenslotte hieronder enkele oudgedienden van Algemene Zaken, van links naar rechts: Frans Meijboom (personeelsreferent, helaas jong overleden), Vincent Roeloffzen (Interne zaken) en Kees Vermeer (Opleidingen).
05 Toepassingen Inleiding Van ponskaart naar database De ponskaart overheerste in de eerste jaren van de automatisering. Vanuit de mechanische administratie had De Nationale de eerste stappen gezet met een IBM 650. Het automatiseringsgebeuren bij De Nederlanden van 1845 begon met een Bull Gamma, gekoppeld aan een IBM 1401. Maar dit waren toch nog echt kaartmachines. De eerste stappen op de 360/40 die NN zette, ging dan ook richting tape. Zet kaartimage op tape en versnel daarmee de administratie. Pas toen deze exercitie achter de rug was (met alle omringende programmatuur een klus van jaren) begon het serieuze werk. Maak een database en gebruik die. Als invoer werd nog steeds de ponskaart gebruikt, bij Collectief papertape, later werd MDS de leverancier van de invoerrecords. Bij Schade werd branche voor branche omgezet van kaart naar tape. In 1970 was die operatie in Den Haag achter de rug. Maar daarna kwamen de toevoegingen, de overgang naar FM, en het produceren van documenten. In Rotterdam werden LABORA en LEGO opgezet en geprogrammeerd. Deze twee projecten slokten zo goed als alle mankracht van AO Leven op. (Mankracht is niet helemaal het goede woord, Martha Bestebreurtje bracht vrouwkracht in voor twee). En de groep SAP bij het AC was er ook druk bezig mee. De eerste beeldschermen werkten al. Rekenaars konden met VSPC communiceren met het mainframe. In 1977 startte AN een aantal testen om interactief uit te proberen. Beide werden bij Schade uitgevoerd. Eén proef met een 3790 als communicatiestation, één rechtstreeks met CICS. Uiteindelijk werd CICS met beeldschermen rechtstreeks aan het mainframe de manier waarop Schade verder ging. Pas toen bij Leven Labora en daarna LEGO goed liepen (we praten over 1978/1979), begon AO Leven na te denken over interactief.
Leven gaat naar de mini Maar daar was ondertussen de Mini ontdekt. De proef van AN met een S/34 (bedoeld voor Effecten) werd goed gevolgd, en er werd besloten om ook een proefproject op te zetten. David werd dit, in 1978 ging dit systeem de lucht in, snel gevolgd door Valk in 1979. Toen was iedereen bij AO zo enthousiast over de mogelijkheden dat besloten werd de interactieve uitbreidingen met een S/34 te gaan doen. Al werd dat al snel een bestelling voor een S/38. Eigen programmeurs werden aangetrokken, Toen Labora uitbouw in de lucht ging in december 1981, performde het systeem voor geen meter. De responsetijden waren zo slecht dat er besloten werd te stoppen met deze ontwikkeling. Maar door wat forse aanpassingen en een installatie van een groter S/38 sloeg de stemming in dat jaar om in enthousiasme. Uitbouw Labora kon verder op de ingeslagen weg en ook Klivia, het project dat LEGO moest gaan voeden, mocht door gaan. In 1984 kwam dit systeem in de lucht. De S/38 kon niet meer stuk. Een aparte machine erbij als backup- en testmachine, de oude zaal van de 360/40 werd weer in gebruik genomen als computerzaal.
Van links naar rechts: René van der Linden, Tineke Mark, Loek Schoenmakers In 1983 wordt er gestart met de bouw van een nieuw excasso systeem. De bedoeling is de batch op het mainframe, de online op de S/38. In de loop van 1984 lopen de geplande produktiekosten op het mainframe nogal hoog op. Het kan veel goedkoper op S/38 roept Leven. Begin 1985 geeft dit een heftige discussie tussen de directie Leven en de directie AC, die uiteindelijk beslist wordt door de Raad van Bestuur! Leven mag LES op de S/38 opzetten. Met excuses aan de mensen die er bij het AC al zo veel werk ingestopt hadden. Er kwamen nog veel meer programma’s bij, merendeels hulpsystemen zoals LNS/POS en VOS, het aantal beeldschermen nam toe, er werd een tweeploegendienst ingesteld. In 1987 kwam de vierde S/38 binnen. Er was binnen NN een nieuw rekencentrum ontstaan. Toen er dan ook een nieuw plan gemaakt werd voor Individueel was NN Leven vast van plan om daar opnieuw de S/38 voor in te zetten. Er werd een nieuwe machine aangekondigd door IBM, de AS/400, en die kan een nieuw interactief systeem gemakkelijk trekken. AN was hierop tegen. Die was voorstander van CICS met DB2, rechtstreeks op het mainframe. Ze zag nog geen bruikbare vorm van distributed processing. Eind 1988 wordt de knoop doorgehakt (opnieuw op niveau RVB), ILIAS wordt een ontwikkeling op de host. Maar tegelijkertijd vervangt Leven zijn S/38 door de AS/400 en worden alle toepassingen uitgebouwd en aangevuld met talloze hulpprogramma’s. In 1990 heeft NN Leven het grootste AS/400 rekencentrum van Europa. De HDN besluit dat het ITC alle apparatuur moet gaan beheren, dus ook die van Leven. In 1991 gaat de gehele installatie naar het WP, waar hij echter rustig doorgroeit. Er is dan wel in 1992 besloten geen nieuwe zaken meer te ontwikkelen op de AS/400, maar vier jaar later ligt er al weer een ander besluit. Stock wordt vrolijk een AS/400 toepassing. Onderzoeken naar een conversie naar het mainframe, die in de negentiger jaren regelmatig gehouden werden, liepen stuk. In 2001
schrijven Lex Schreurs en Hans Tobé een stukje over de stand van zaken op dat moment. Onder de kop: AS/400, vloek of zegen komen ze tot de volgende conclusie:
Er komt een derde platform bij eind jaren tachtig. De PC, gekoppeld via een LAN, met eigen servers voor de dataopslag, begint zijn overwinningsronde bij BI. In 1989 wordt voor hen een LAN aangelegd, en binnen een paar jaar draaien de EV programma’s op eigen servers, in beheer bij BI. Binnen Collectief wordt de groep die zich met Culprits en queries op de AS/400 bezighoudt uitgebreid met PC programmering. Op de AS/400 wordt een duplicaat van het Lego bestand gezet, en dit is input voor het PC Lan. In 1994 bij een inventarisatie voor het IP Collectief zijn er 44 projecten bij de automatisering in beheer en 83 bij de gebruikers. En bij die 83 zit een enkele query op AS/400 of Host, maar de rest is PC programmatuur. De automatisering wordt er bang van. Natuurlijk hadden zij zelf ook de overstap naar de PC gemaakt. De meest dramatische was de overstap naar de rekenserver. Alle berekeningen op Host en AS/400 werden naar een server geleid om te rekenen. En daarnaast waren er vele andere toepassingen in (bijna) evenzoveel talen. Maar of dat nu aan gebruikers overgelaten moest worden. Na twee vergeefse pogingen om in de jaren negentig een Informatieplan zowel voor Individueel als Collectief van de grond te krijgen, ligt er dan in 2002 een nieuw plan. Of dat op den duur minder platforms zal opleveren? Door de oude systemen als “legacy” te benoemen, is er tenminste één scheiding verdwenen.
Schade doet CICS Tussen 1977 en 1989 zette Schade alle toepassingen over van ponsconcepten naar interactief. CICS met FM, en later CICS met IDMS. AO Schade werkte nauw samen met de SO Schade bij AC. Voor elke sector is er een reeks programma’s. Aansprakelijkheid en Vermogen, Brand, Inkomen, Motorrijtuigen, Transport en Ziektekosten. En de Restadministratie is er voor de losse einden. Maar
zo wil Schade niet verder. Er moet een totaalsysteem komen, branch onafhankelijk. DrieS wordt gestart. Terwijl er over DrieS wordt nagedacht gaan de ontwikkelingen verder. De domme buizen worden vervangen door PC’s en Stratego vraagt om een aanpak over alle branches heen. Maar zo snel kan de Automatisering niet reageren met een totaal opzet. Er wordt met Easel een Stratego schil gebouwd, die ervoor zorgt dat één medewerker op zijn PC met alle bestaande branches uit de voeten kan. Natuurlijk komen er in die tijd ook bij Schade de nodige PC toepassingen. Gegevens van het mainframe ophalen kost dure CPU secondes, de PC lijkt bijna niets te kosten. Ook hier draaien weldra vele servers die heel snel vele afgeleide bestanden bevatten. De ontwikkelingen binnen DrieS gaan in de richting van een systeem dat beheerst wordt door Work Flow Management. Daar hoort uiteraard Imaging bij. Per branch opzetten, binnen de Architectuur van DrieS, dat wordt de Informatie Planning bij Schade. De techniek is een grote bottleneck. Hoeveel servers moet je wel inzetten voor Imaging. Maar dank zij de snelle groei in PC ontwikkeling, zowel op hard- als softwaregebied komen er werkbare oplossingen. Bij de eeuwwisseling beginnen een aantal projecten in de praktijk hun nut te bewijzen. Donna en Diva zijn twee begrippen die hierbij horen.
Leven Individueel De Nationale Mechanische administratie Voor de komst van een computer is er al een uitgebreide mechanische administratie bij De Nationale. De gegevens voor de reserve en het borderel waren vastgelegd in kaarten. In 1949 wordt er in Kompas melding gemaakt van zo’n ingenieuze Hollerith machine welke registreert, groepeert en telt. IBM 650 In 1957 wordt in Parijs de reserve gedraaid voor 260.000 polissen, in 130 uur fikst de IBM 650, die daar voor een beurs opgesteld staat, dat karwei. In datzelfde jaar koopt De Nationale een IBM 604 en bestelt gelijk een 650. Die wordt in 1959 geleverd. Vanaf 1961 wordt er fors gewerkt aan de opbouw van een bestand voor het Individuele bedrijf. Alle verzekeringen worden op ponsformulieren vastgelegd en verponst in honderdduizenden ponskaarten. Dit was een enorm karwei. Iedereen met een administratieve achtergrond werd verplicht om veel (over)werk te besteden aan het invullen van de formulieren. Leo Verwoert heeft nog het oorspronkelijke boekje, waarin de regels voor de ponskaarten van het systeem IBM 650 zijn vermeld. Het is opgesteld door Frigge en telt meer dan 200 bladzijden. Er waren ongeveer 90 kaartsoorten, bij invoer moest er voor de meeste tarieven 6 kaarten aangemaakt worden, voor sommige verzekeringsvormen liep dat wel op tot 20 of 30. De andere kaartensoorten waren hulpkaarten die in veel gevallen aangemaakt werden door de 650.
De conversie duurde tot 1964. Toen stond het gehele Individuele bestand op kaart. De conversie werd geleid door “ome”Arie van der Graaf. De 650 Administratie heeft doorgedraaid tot 1969. U kunt zich voorstellen over welke hoeveelheden ponskaarten we praten en wat er naast de IBM 650 nog in gebruik was aan apparatuur. En wat een kunst het was om een ponsformulier in te vullen volgens het boek van Frigge met alle x-ponsingen die nodig waren. In 1966 gingen zowel de 360/40 (emulatie van de 650) als de 360/20 meehelpen om met hun veel grotere snelheden de kaartmassa te lijf te gaan, maar het wachten was op de tapeadministratie .
De Nederlanden van 1845 Mechanische Administratie In 1927 wordt een start gemaakt met de mechanische administratie. In 1956 is er een vrij uitgebreid artikel over de mechanische administratie, zonder dat daar ingegaan wordt op de lopende administraties. Maar Reserve en Prolongatie liggen nogal voor de hand. Gamma en 1401 In 1958 doet de Gamma zijn intrede met de nodige publiciteit. Veel grapjes over wat hij allemaal kan, maar ook nu geen concrete administratiegegevens. We zijn nog op zoek naar “het boek van Frigge” van de Nederlanden. Maar of dat er nog is?
In 1960 een stukje in de Schakel over de reserveberekening die dan op de Gamma gedaan is. En eveneens uit 1960 een stuk over Transport, waar ook weer de reserve genoemd wordt. Een overzicht van de stand van zaken bij de Nationale en De Nederlanden in 1963 geeft de verschillen en overeenkomsten aan in de administratie van beide fusiepartners. De Nationale is in het individuele stuk duidelijk verder met haar 650 administratie. Na de fusie wordt het Nederlanden bestand bevroren en gaan de nieuwe inschrijvingen naar Rotterdam. Maar het blijft natuurlijk een klus om dat bevroren bestand bij te houden en prolongatie en reserve vast te stellen. Zeker als je zo’n machinepark niet kan vernieuwen of uitbreiden. In 1969 wordt het Nederlanden bestand op tape gezet, en verder op de 360/40 afgewikkeld. Het blijft tot de invoering van Labora een apart bestand. In 1973 in een rapport over het naambestand, worden twee tapebestanden genoemd, het Ned-PKN bestand en het Ned-ACT bestand.
Nationale-Nederlanden TLI In 1969 wordt de 650 administratie overgezet op de 360, op tape. Om deze conversie goed te laten lopen worden eerst de kaartbestanden samengevoegd. Een verhaal in 2N vertelt daar meer over. Daarna kwam de eigenlijke conversie. Leen Pieren weet het nog goed. Ook dat er na het inlezen een verschil geconstateerd werd met het standenregister. Er moest een groot gedeelte opnieuw ingelezen worden. Het premieborderel kan vanaf dat moment van tape worden vervaardigd. Voor de rest blijft alles bij het oude. In 1970 kan ook het renteborderel met de tape worden gemaakt, maar de inhoudingen worden nog in kaarten vastgelegd. Overleg over automatisering winstsysteem. Van links naar rechts op de foto: Martha Bestebreurtje, Wessel Burger, Jan Sluijter en Leen Pieren
In de tussentijd wordt hard gewerkt aan een verbeterde mutatie- en invoermethode. Het krijgt de naam Tussenfase Leven Individueel. De invoer blijft gebaseerd op het voor de 650 administratie ontwikkelde ponsdocument, de naam geeft het voorlopige karakter aan. In november 1970 wordt het Winstsysteem 66 naar tape gebracht. In 2N wordt groots aangekondigd dat het nieuwe systeem is ingevoerd, maar uit andere bronnen weten we beter. Op dat moment wordt er nog druk gewerkt aan het nieuwe mutatiesysteem voor de TLI en wordt er voor Winstsysteem 66 een noodprogramma gemaakt.
In april 1971 wordt het nieuwe Mutatiesysteem TLI in gebruik genomen.
Het ponskaartenbestand kan weg. Dat scheelt veel ruimte, er stonden er nog 5.000.000. Bovendien kan een groot gedeelte van de mechanische apparatuur nu verdwijnen. Behalve de mutatiefunctie bevat het nieuwe programma een infofunctie, waardoor het mogelijk is tweemaal per dag de status van posten op te vragen (1,5 uur per run). Tot dat moment wordt het standenregister (de vervallen premie per tussenpersoon) nog met ponskaarten gedaan. Nu wordt het standenregister toegevoegd aan het tussenpersonen- bestand en met de mutatierun bijgewerkt. Bovendien kan er nu Info worden opgevraagd per tussenpersoon. In 1971 komt er een projectgroep Invoer TLI met het voorstel het invoerdocument te veranderen. Drie invoerdocumenten i.p.v één. Hierdoor worden de eenvoudige verzekeringen gemakkelijker in te vullen en zijn er veel minder kaarten nodig. Goedhart stuurt een notitie aan Sachse waarin hij aangeeft dat hij dit niet zo’n goed idee vindt. Het wordt met drie formulieren moeilijker en alles gaat meer tijd kosten. Ga liever de statistiek doen, die wordt nu weer uitgesteld. Uiteindelijk worden er een paar kleine wijzigingen aangebracht in de invoermethodiek, maar de basis blijft dezelfde. Tot de invoering Labora zal het 650 ponsdocument gehandhaafd blijven. Natuurlijk is er veel gesleuteld aan de mutatiecyclus tor de invoering van Labora. De belangrijkste wijziging voor de automatisering was het vervangen van tape door een direct toegankelijk geheugen. Dit gebeurde met het File Maintenance Pakket, een zelf geschreven routine op basis van een IBM product. In principe gebouwd voor de Data Cell. Later werd de Data Cell vervangen door een 3330 schijfsysteem. Dit was in 1974.
Leen Pieren weet geen exacte datum meer voor de overgang van TLI naar FM, maar het heeft wel een paar jaar geduurd. Hillard van der Steeg heeft nog een rapport: "Overgang TLI naar Labora" d.d. 19 november 1974, waarin sprake is van het royeren van het Data Cell bestand. Hieruit moeten we concluderen dat het TLI bestand in 1974 op Data Cell stond, onder het FM pakket, en dat dit bestand eind 1974 naar de 3330 migreerde. Bij een voorstel voor een naambestand uit 1973 (let op de waarschuwing van de projectgroepleden aan hun bazen in de inleiding: dit is een moeilijk rapport, goed lezen hoor) worden alle bestanden genoemd waarin namen staan. Hierdoor krijgen we een aardige indruk van de toenmalige administratie. Verschillende bestanden die allemaal apart bijgewerkt worden met als enig outputdocument de nota. Vandaar dat er al direct na het opleveren van de TLI een projectgroep aan de gang ging. Labora Notities van Leen Keemink en Leo Verwoert, aangevuld met automatiseringsgegevens. 7 januari 1972 Installatie van een projectgroep die tot doel heeft een voorstudie te maken van een nieuw administratief en beleidsondersteunend informatiesysteem. De mannen van het eerste uur gaan o.a. naar Amerika om in de keuken van IBM en Amerikaanse Levensverzekeraars te kijken. Januari 1972 Inventarisatie Leven Individueel. Er verschijnt een circulaire, waarin verwezen wordt naar de aankondiging voor een nieuw administratief systeem en een verzoek om enquêteformulieren in te vullen. Het doel van de enquête is de routing van de verschillende werksoorten in kaart brengen. Per dossier wordt een enquêteformulier bijgevoegd dat gedurende de verwerking door alle behandelaars moet worden ingevuld. Januari 1973 Er wordt een onderzoek ingesteld naar de behoefte aan informatie voor het PAIS-deel van Labora. PAIS = Produktie-Informatie en AktiviteitenSysteem. 14 maart 1973 Aanbieding rapport Definition Study Labora aan directies van NN-Leven en van het AC. Opstellers: De Boer, Etienne, Jonker, Sachse, Van der Stee en Van den Broek (adviseur). Foto’s: Cursus Basiskennis Labora 8 juni 1973: De grote Labora circulaire verschijnt. LABORA staat voor: Levensverzekerings Administratie en BeleidsOndersteuning met Random Access Er wordt uitgebreid aandacht besteed aan o.a. de blauwdruk, de fasering, de organisatorische aanpak. Er worden A, B en C werkgroepen ingesteld.
A: inventarisatie, analyse, suggesties voor heroriëntering B: bouw administratiesysteem C: bouw informatiesysteem. De bezetting voor al deze werkgroepen werd samengesteld uit alle afdelingen van het bedrijf. Een aantal mensen zit in meerdere werkgroepen. In totaal wordt inclusief begeleiding een beroep gedaan op ca. 75 medewerkers en leidinggevenden. Een zeer forse investering in mankracht. 25 september 1973 De automatiseerders gaan op cursus om basiskennis Labora op te doen. 28 november 1974 Ter voorbereiding op de komst van Labora wordt besloten tot een herindeling binnen het Individuele bedrijf in twee sectoren 16 mei 1975 Verdere informatie over LABORA staat als kop boven deze circulaire. Inhoud: een beknopte beschrijving van de inhoud van LABORA een inzicht in de huidige stand van zaken en verdere plannen voorlopige resultaten van het mutatieproces gedachte over de toekomstige organisatie. Alle plannen die men heeft worden vroegtijdig gepubliceerd. De betrokkenheid is dan ook zeer groot. 25 juli 1975 Aankondiging wanneer de diverse basisontwerpen gereed zijn. Verzocht wordt om commentaar en uiteindelijk van de fiattering van deze basisontwerpen. 26 november 1975 De basisontwerpen zijn gereed, er wordt gestart met detailontwerpen. Verder wordt een proefneming met een beheerteam aangekondigd waar het werk meer geïntegreerd gaat worden. Bovendien zal dit team tevens een proef nemen met “buitendienstgericht werken”. In een eerdere circulaire was voorzichtig als startdatum van Labora 1 januari 1977 genoemd, nu wordt aangegeven dat dit zeker later zal zijn. Dat het werk van een zeer hoog niveau betrof blijkt uit het voorwoord dat is aangetroffen in één van de basisontwerpen: Voorwoord 'Wij leven in duistere tijden. Lieden van stand worden gedwongen hun levenswandel onder de korenmaat te plaatsen omdat neerdrukkende wetten voortdurend een domper zetten op hun lichtend voorbeeld. Menig hoogstaand iemand wordt daardoor de kop ingedrukt en door onbesnaarde gezagsdragers in zijn ontplooiing gefnuikt. Deze meedogenloze misstand riep sinds lang om een krachtig woord, dat hier thans op schrijnende wijze voor ons ligt. Op ontroerende toon heeft dit werk mij meegesleept op de martelgang van een onverschrokken heer, die zijn verheven beginselen fier boven een poel van benepen verordeningen weet uit te dragen.' aldus de heer O.B.B. te R.
9 februari 1976 start het eerste AVI team. 10 februari 1977. Voor 1-4-1978 moeten de betrokken lijnmedewerkers opgeleid zijn om met Labora om te kunnen gaan.
Er worden 3 varianten aangeboden: a. cursus (90 deelnemers) introductie voor de leiding en voor medewerkers die minder intensief met Labora communiceren b. basiscursus (160 deelnemers) voor (nagenoeg) alle medewerkers die intensief met Labora in aanraking komen. c. specialistentraining 10 deelnemers Uiteraard wordt een beroep op de lijn gedaan om gastdocenten te leveren. 28 februari 1977 Een eerste basisnotitie verschijnt waarmee de discussie wordt aangeslingerd over aspecten die samenhangen met de invoering van Labora. 18 maart 1977 Aankondiging dat in 1978 (!) twee nieuwe systemen in gebruik genomen zullen worden nl. LEGO (voor Collectief) en LABORA (voor Individueel). Als vermoedelijke startdatum wordt aangehouden een datum na het jaarwerk winst (mei 1977). Als uiterste operationele datum wordt boekjaar 1978 aangehouden. Deze grote spreiding is noodzakelijk om de conversie gefaseerd te kunnen laten plaatsvinden. Deze circulaire telt 16 kantjes. 21 sept. 1977 De uitnodigingen voor de systeemtest zijn verstuurd. De deelnemers krijgen tevens een uitnodiging voor een opleiding 3 augustus 1978 Eerste dagwerk Labora. Voorlopig alleen nieuwe verzekeringen (AVI-6). Introductie verloopt voorspoedig.
Op de foto: projectleiders AO (Koos Kerkhof en Martha Bestbreurtje) en projectleiders AC (Giel Keijzer en Hillard van der Steeg) bekijken samen met voorzitter stuurgroep Labora (Sam Jonker) de eerste net geprinte Laborapolis.
Opgericht wordt een afdeling TU (Technische Unit), later omgedoopt in OIL (Ondersteuning Invoer Labora) met als taken: - verspreiding van alle uitvoerproducten voor Leven - verwerking van alle adresmutaties voor Leven - ondersteuning van de lijnafdelingen. 1978 De voorbereidingen voor de conversie vorderen gestaag. Besloten is om proefconversies uit te voeren in dezelfde volgorde als de echte conversie. Zo kan men bepalen welk deel van de signalen en weigeringen nog in de TLI kan worden verbeterd. Ook is het zo mogelijk om in te schatten hoeveel mankracht nodig is om de (nu voorspelbare) weigeringen en signalen bij de conversie op te lossen.
11 juni 1979 De conversie van de Nederlanden portefeuille is dan al achter de rug. Alsmede een groot deel van de conversie van de TLI naar Labora. Aangekondigd wordt dat door het voorspoedig verlopen van alle deelconversies de laatste conversie niet in oktober 1979 wordt uitgevoerd maar al in juni 1979. Najaar 1979 Nu de laatste conversie achter de rug is staat niets de invoering van de postcode in de weg. Ook deze 'conversie' verloopt voorspoedig. Slechts 5 % uitval, toch nog 38.501 signalen die met de hand uitgezocht moeten worden. Uitbouw Labora Rond 1980 De eerste computerschermen deden hun intrede op de werkvloer. Om te kunnen wennen aan deze schermen was het mogelijk om spelletjes te spelen. (yahtzee, hangman, Russische roulette). Dat spelen was alleen toegestaan tussen de middag, maar ja. In een afdelingsverslag over 1981 valt zelfs te lezen dat ook de oudere medewerkers enthousiast waren geworden over de invoering van beeldschermen. Nu kan de interactieve invoer ter hand worden genomen. Tot nog toe moesten alle verzekeringen ingevoerd worden met behulp van het 220 formulier. Het invullen was een hele klus, het aantal weigeringen door verkeerde invoer was ongeveer 30%. Hiervan kwam een gedeelte voor rekening van de ponskamer, die dit zware formulier moest invoeren. Met beeldschermen kon een interactieve invoer gerealiseerd worden. In 1991 schrijft Leo Verwoert nog een rechtvaardiging achteraf over de kostenbesparingen.
De start van een geslaagde proef bij AVI 3 van interactieve invoer van nieuwe verzekeringen is in 1981. In mei 1982 kunnen alle AVI teams interactief invoeren. Daarna worden de kleine mutaties aangepakt. In het jaarverslag over 1982 (AVI) wordt gemeld dat het werken met interactieve invoer, inclusief een nieuw invoerscherm voor koopsomverzekeringen, als zeer prettig ervaren wordt. Echter de verschillende S/38 machines raken vol. De responsetijden worden te lang. Uit eigen ervaring soms langer dan 5 seconde, als er anno 2004 een vertraging is op het netwerk van meer dan een halve seconde, wordt er al moord en brand geschreeuwd.
Ook de verschillende aanpassingen in tarieven en producten werden genoemd, kennelijk waren die onder grote tijdsdruk ingevoerd. De kwaliteit liet nog al te wensen over. In de jaren die volgen worden langzaam maar zeker alle verzekeringen die nog via het ponsdocument worden ingevoerd naar interactief overgevoerd. Het laatste ponsdocument verdwijnt in 1992. Om de status van invoer en mutaties te kunnen volgen worden twee voortgangssystemen ingevoerd. Eén voor de nieuwe verzekeringen AVLI (Acceptatie Voortgang Leven Individueel) en één voor mutatie BVLI (Beheer Voortgang Leven Individueel). Grote zorg moet worden besteed aan een omvangrijke schoningsactie. Na een gedegen voorbereiding wordt in december 1982 gestart met een omvangrijke schoningsactie van de NAW gegevens in Labora. De geschatte inspanning bedraagt 27 manjaar. De vastgestelde einddatum 1-6-1984. Deze actie kreeg als naam "Actie 300". In totaal werden ca. 300.000 dossiers uit het archief gehaald. Waarvan na vergelijking van gegevens (opgehaald uit Labora via Cullprit, een soort Query toepassing) ca 90.000 gemuteerd moesten worden. Bij ex-Nederlanden polissen had men gebruik gemaakt van het 10-tallig stelsel om de geboortedatum (12-tallig stelsel) op te slaan. Bij conversie was daarna alleen de geboortedatum 1-1 nog de juiste. Alle andere geboortedata verschilden 1 tot meerdere dagen. En dat alleen om in de 60'er jaren 1 positie te besparen bij de opslag van gegevens. Ook was er sprake van een behoorlijke vervuiling. De klus werd in 25,2 manjaren geklaard. (N.B. Het is onduidelijk wat er met 10-tallig en 12-tallig stelsel wordt bedoeld. In een conversierapport uit 1974 staat over de Haagse posten: “ Bij bijna alle posten die op 1 januari 1966 bestonden is de decimaal van einddatum en geboortedatum onbekend. Alleen de leeftijd op de einddatum is aanwezig; het is dan niet mogelijk t.b.v. de winstbijschrijving de leeftijd in jaren naar beneden afgerond op 1 juni te bepalen." Dat stukje over “de decimaal van einddatum en geboortedatum”verduidelijkt ook niets. Ik vraag me af of hier geen sprake is van een conversiefout met bovenponsingen. Bij De Nederlanden waren ze in de 60’er jaren toch niet zo dom om een onbruikbare datum op te nemen). In 1989 worden op de AS/400 twee hulpsystemen in gebruik genomen. LNS, Leven Naam Systeem en POS, Polisdossier Opvraag Systeem. In 1990 worden de twee voortgangsystemen AVLI en BVLI vervangen door VOS. VOS wordt gekoppeld aan LNS/POS En in 1990 krijgt het Flexiplan de primeur van de toelevering vanuit een PC aan Labora. Het wordt hoog tijd Labora te gaan vervangen roepen alle deskundigen al jaren. Het systeem, met zijn randsystemen is nu vanaf 1978 uitgebouwd en gewijzigd en kan niet veel langer mee. Reeds in 1985 is er een werkgroep gestart die de basis moet leggen voor een nieuw begin voor Individueel. Het zou allemaal anders lopen dan men toen dacht. Tijdens het schrijven van dit verhaal in 2005 draait Labora nog op volle toeren. Bij het 25-jarig jubileum van Labora in 2003 werd een expositie ingericht en een symposium georganiseerd. Ton Hulsbosch, Rob de La Ruelle, Lex Schreurs, Hillard van der Steeg en Leo Verwoert hadden de organisatie hiervan op zich genomen. Van de vroegere bestuurders waren Sam Jonker en Jacques Etienne aanwezig. Hierna een foto-impressie van dit gebeuren met vele oude bekenden. Meer foto’s, gemaakt door Ton Modderman, zijn op de CD te zien.
Ilias Het jaarverslag van Organisatie en Opleiding zegt over 1985: Een andere belangrijke gebeurtenis was uiteraard de start van het projekt Blauwdruk Leven. In maart werd een plan van aanpak opgesteld en door de projektleider in april aan de begeleidingscommissie, bestaande o.a. uit direktieleden en sektorhoofden, gepresenteerd. Na de acceptatie van het plan is het projekt van start gegaan. Medio april 1985 zijn een aantal organisatiemedewerkers gestart, waarna geleidelijk aan zowel AO-medewerkers als eindgebruikers werden ingeschakeld. Een belangrijk aspekt van de gekozen aanpak is om, naast de
blauwdrukaktiviteiten, de projektgroep ook relatief weinig inspanning vragende en snel realiseerbare projekten aan te laten pakken (pleisters). Op het gebied van de pleisters worden al enige resultaten zichtbaar. De blauwdrukontwikkeling zelf is een zaak van lange adem, waarbij ook nog geldt dat het niet zeker is of de gekozen aanpak wel de juiste is. Dit laatste zou overigens gelden voor iedere gekozen aanpak. Het hoeft geen betoog dat het Blauwdrukprojekt (nu al) een flinke aanslag pleegt op de AO-capaciteit en dus ten koste moet gaan van andere projekten. Prioriteitenstelling is dus ook van het grootste belang. Direktie en sektorhoofden zullen hier zoveel mogelijk bij betrokken moeten zijn.
De genoemde projectleider is Loek Schoenmakers. Eind 1986 geeft Loek Schoenmakers een interview met 2N, vlak voor hij vertrekt, waarin hij nog eens uitlegt waarover de blauwdruk gaat. Maak een schets van de toekomstige organisatie, de handmatige procedures en de geautomatiseerde systemen. Rob van Bokkem neemt de projectleiding over en levert in 1987 een eindrapport op. De voornaamste knelpunten met betrekking tot de informatievoorziening zijn: - De huidige administratie en organisatie is intern gericht en polis georiënteerd. (De ingang om gegevens op te zoeken of op te slaan is nagenoeg altijd het polisnummer.) Een meer cliënt georiënteerde administratie, met zowel ingang op cliënt als op polisnummer, is gewenst. - Het onderhoud van de huidige systemen is arbeidsintensief; de systeemdocumentatie is soms slecht toegankelijk en er zijn doublures van identieke functies. Inbouw van nieuwe wensen gaat hierdoor moeizaam en is tijdrovend. - De huidige partiële aanpak van de automatisering kent als nadelen: arbeidsintensief beheer en onderhoud; versnipperde informatie; meervoudige invoer van gegevens. - Door de diversiteit van bestanden kunnen gegevens moeilijk aan elkaar gerelateerd en ontsloten worden. - Historische gegevens worden niet vastgehouden. Voor de informatieverschaffing is men dikwijls aangewezen op het dossier. Het genereren van beleidsinformatie is arbeidsintensief. Ook biedt het systeem te weinig ondersteuning bij het aanmaken van verzekeringsbescheiden en correspondentie. - Een groot deel van de invoerverwerking geschiedt nog via invoerdokumenten. De verwerking daarvan is arbeidsintensief, waarbij correcties achteraf moeten plaatsvinden. - De grenzen van de capaciteit van de huidige apparatuur zijn bereikt. Hierdoor is soms sprake van slechte performance. - Een integraal voortgangssysteem voor Individueel ontbreekt, waardoor invoer dubbel moet plaatsvinden en het inzicht in de voortgang en werkvoorraad versnipperd is.
Er wordt dan ook in 1987 gestart met een definitiestudie voor een nieuwe administratie Individueel die al deze bezwaren moet opheffen. Ton Hulsbosch is de projectleider. In 1988 wordt gestart met het Basisontwerp van Ilias, maar er ligt nog een heet hangijzer. Op welke machine gaat de productie draaien. In het blauwdruk rapport wordt aangegeven dat de S/38 niet geschikt is, dus dat het mainframe wel moet. Maar er wordt nog een slag om de arm gehouden, want IBM komt met een nieuwe machine in de lijn van de S/38. In mei 1988 gooit Wim Combé de knuppel in het hoenderhok. Hij stelt voor de productie op de Olympic (krijgt daarna de naam AS/400) te gaan doen. Er volgen enkele maanden van verhitte discussies in het Branchoverleg Leven, waar Leven en het AC samen praten over nieuwe ontwikkelingen. Ergens wordt er een besluit genomen, want op 29 november staat in het verslag dat het gehele Ilias-systeem op de Host ontwikkeld gaat worden. En dat dit verteld is aan alle medewerkers van O&A. Einde discussie. Hillard van der Steeg, in 1967 begonnen als programmeur bij het AC en daarna samen met Giel Keizer leiding gegeven aan de systeemontwikkeling van Labora, komt in juli 1988 terug van een jarenlang uitstapje bij Tiel-Utrecht en wordt projectmanager. Hij gaat met SDM2 en SDW op het eerste Lan aan de slag. Met DB2, ook nieuw. Er wordt heel wat verwacht van Ilias. In het jaarverslag over 1988 van de OR geeft Lex Schreurs een interview, waarbij hij alle functies van Labora ziet overgaan naar Ilias.
Hillard heeft geen goede herinneringen aan die tijd: “Direct bij mijn aantreden moest ik de dubbelfunctie Projectmanager Ilias en Hoofd van het onderdeel Automatisering van NN-Leven gaan vervullen. Iets wat uit oogpunt van scheiding van verantwoordelijkheden helemaal niet kon. Ik werd geconfronteerd met een planning waarin was aangegeven dat in 3 jaar tijd alle huidige systemen van Individueel zouden moeten zijn vervangen door Ilias met toepassing van de nieuwste technieken en hulpmiddelen, waarmee nog niemand enige ervaring had. Ook werd verwacht dat ik de integratie van de afdelingen Systeemontwikkeling van het AC en NN-Leven er in 1988 nog even bij zou doen. Dit gevoegd bij het feit dat de nieuwe directeur van Leven Individueel, gezien zijn ervaringen bij RVS met “Acolade”, niet geloofde in dit soort grootschalige projecten, maakte het geheel tot een voor mij onmogelijke opdracht. Een reeds snel door mij aangevraagde review bevestigde dat. Vastgesteld werd dat binnen de organisatie Individuele Pensioenen het grootste knelpunt was. Dit werd dan ook de eerste stap van Ilias. In 1991 draait er een grote organisatie. Met heel veel inspanning en menskracht kon de eerste Pensioenpolis in 1992 worden opgeleverd.”
Op de foto van links naar rechts: Jacques Spee, Ed Teer, Paul de Widt Coen Nieuwveld en Gerard van Staveren. In dat jaar (1992) is Sonnet, het rekenprogramma op PC, ook opgeleverd. Dit rekenprogramma werd ook ingezet voor de offertes buiten. Verdere uitbouw van de pensioenen volgt. Maar dan hapert de machine. In 1992 is er een nieuwe ronde Informatieplanning gestart; de opstellers geven andere wegen prioriteit boven uitbouw Ilias. In 1994 schrijft Wim van Eijk, die de leiding overgenomen heeft, de afscheidswoorden. Een paar jaar later, na een reorganisatie, wordt Ilias overgeheveld naar Bedrijven. In 2009 heeft Lex Schreurs nog steeds een dagtaak aan onderhoud en beheer van Labora.
Life In 1990 kregen Labora en Ilias een concurrent. NN gaat naast de verzekeringen op basis van guldens ook Beleggingsverzekeringen verkopen. Het investeringsgedeelte van de premie wordt belegd in fondsen naar keuze van de verzekeringnemer. De producten worden met klaroengeschal aangekondigd, Inge van Hoek moet de club, die de administratie gaat opzetten en uitvoeren, gaan trekken.
Om administratief snel te kunnen starten wordt er een voorlopig programma op de AS/400 opgezet, het vangnet. Coen Nieuwveld neemt dat voor zijn rekening. Voor de definitieve administratie wordt besloten een pakket aan te kopen. Na enig onderzoek wordt dat het Life pakket van Paxus. AN is daar niet echt blij mee, want Paxus werkt met Supra als databasesysteem, en AN heeft net de keus voor DB2 gemaakt. Dit betekent dus nog een databasesysteem onderhouden. Maar er zijn voor een snelle invoer eigenlijk geen alternatieven en Johan van der Wal (zie foto) krijgt de opdracht het Paxus pakket in te voeren. Met behulp van interne en (Engels sprekende) externen lukt het om binnen redelijke tijd Life in de lucht te krijgen. En dat is maar goed ook, want de verzekeringen stromen binnen. En dat betekent heel wat capaciteit op het mainframe. Niet alleen ’s nachts in de batch (de eerste run van de maand wordt berucht vanwege zijn doorlooptijd) maar ook tijdens de online worden er heel wat CPU secondes verstookt. Een aantal mutaties wordt namelijk gelijk afgewikkeld tijdens die online. De responsetijden zijn niet altijd even leuk. Voor de automatiseerders is de snel groeiende database een groot probleem. Uitbreidingen van diskspace zijn aan de orde van de dag en er moet regelmatig gereorganiseerd worden. Maar Life groeit door en neemt steeds meer CPU secondes af. In 1993 zijn de productiekosten al even hoog als die van Labora. In de loop van de jaren worden er voortdurend verbeteringen in de doorlooptijden aangebracht. Omdat de papieren uitvoer van het Engels pakket niet voldeed wordt er een apart PC programma voor geschreven. Er zijn in de loop der jaren heel wat printers versleten op de gigantische aantallen. Iedereen die er mee te maken had was blij toen deze outputstroom naar het ITC verplaatst werd. IP In 1992 schrijft Leen Pieren, Hoofd Consultancy, in de nota Informatiebeleid dat NN Leven geen Informatieplan heeft. En zegt hij: het Informatieplan vormt de basis van gestructureerd werken. In 1995 kan hij, in een nieuwe nota Informatiebeleid schrijven: In 1995 is de derde versie Informatieplan Particulieren opgeleverd. Er is dan al gekeken naar een Frans pakket, CIRVIE, maar dat wordt afgewezen. Zelf bouwen is de voorlopige conclusie. Het Informatieplan beschrijft de systemen die bestaan, de gewenste toestand en vijf mogelijke manieren hoe we daar moeten komen. De keuze wordt een jaar later gemaakt. Bouw een nieuw systeem voor beleggingen en voeg daar twee guldensverzekeringen aan toe. Bouw dit systeem vervolgens uit voor alle verzekeringen. Voeg daar een Rekensysteem, Workflowmanagement, Productvervaardiging en een NN relatiesysteem aan toe. Een aantal stukken bij de start van fase 1 geeft wat details, ook over de samenwerking met Collectief.
Er wordt in dit stadium al wat opgeleverd onder de vlag IP. RSL gaat in de lucht, na een geslaagde herontwikkeling van de Schade programmatuur met IEF in 1995. Niet alle gebruikers zijn even blij, ze moeten van de AS/400 overschakelen naar de Host, en dat vinden sommigen maar lastig. Al wordt er wel voor gezorgd dat de AS/400 programma’s hun eigen verbinding naar de RSL database krijgen. In IT Kompas staat een wat meer technische verhaal over RSL en IEF. Er wordt op alle fronten gestart met onderdelen van systemen. Ook met een nieuw incasso systeem dat het sterk verouderde LIS moet gaan vervangen. In 1997 rapporteert de OR positief over de ontwikkelingen. Maar in 1998 beschrijft het jaarverslag van de OR het mislukken van dit project door vertraging in de oplevering van de rest van de nieuwe administratie. Ook van het idee dat Flits op de plank blijft tot de nieuwe administratie klaar is kwam niets terecht. In 2004 werd er pas een nieuw incasso systeem ingevoerd. Nu met SAP CD onder de vlag van Flaming. LIS is na 27 jaar ter ziele. In 1999, als blijkt dat er te veel hooi op de vork genomen is, wordt een herstart gemaakt. Nu alleen met Particulieren sparen, een deel van de beleggingsverzekeringen. FlamING In 2000 stelt ING dat er binnen ING meer samengewerkt moet worden. Op Europees niveau wordt er naar nieuwe automatisering gezocht. In 2001 resulteert dit in een nieuw plan, waarbij NN voortrekker moet worden bij FlamING (Fundament for Life Administration and Management Information ING). Miedema houdt een presentatie en schetst de nieuwe plannen. SAP en Unisys zijn de partners om een nieuwe administratie op te zetten. In 2003 worden de eerste resultaten voor Particulieren zichtbaar. De eerste implementatie van Juice is een feit. Juice moet de contractadministratie van de beleggingsverzekeringen gaan vervangen. Er is een bijeenkomst om dit feit te vieren Met o.a. Henk Kruidenier Bert Richaers, Age Miedema v.l.n.r. op eerste rij; Fred Buurmans, Hans Kadiks en Kees Buis op tweede rij. Ton van der Linden staande midden. In het midden achter de katheder: Eric Dralans (COO ING Europe).
Dank zij de Image en Workflow ervaring bij Schade kan er nu snel resultaat worden geboekt op deze terreinen. In 2007 staat in I-Magazine een artikel over de manier waarop met SAP gewerkt wordt. Het brede gebruik van SAP wordt ook genoemd: In en Excasso, Provisie, Operations &Performance Management, Datawarehousing, Collectieve Pensioenadministratie en Claimshandling
Leven Collectief De start In 1939 was het Bureau voor Groepsverzekeringen opgericht, een samenwerking tussen de Nederlanden van 1845 en de Nationale. Maar de administratie van de collectieve contracten ging wel apart bij de verschillende maatschappijen. Bij de Nederlanden werd in 1959 een programma gemaakt voor het contract Hoogovens, als proefobject voor een algemene opzet.
In 1963 is het nog steeds Hoogovens, de rest van het programma laat nog op zich wachten.
In 1964 is het contract Hoogovens rond en is er een begin gemaakt met een rekenprogramma en kunnen de verzekeringsbewijzen worden gemaakt,
Er was (in ponskaarten) een tussenfase gemaakt waarbij meerdere kaarten betrokken waren. Hiervoor was een ponsformulier ontwikkeld. Deze tussenfase liep op de 1401. Een overzicht bij het rapport van het “Leidse comité” uit 1963 laat zien dat de Nationale al iets verder was met de Groeps administratie. De eerste stap bij binnenkomst van de 360/40 was het omzetten van kaart naar tape. Er werd een /360 administratie gebouwd. Om los te komen van de beperkte invoer van een ponskaart (het bleven 80 posities), werd besloten de invoer met papertape te gaan doen. Hierdoor kwamen 125 posities ter beschikking. De papertape werd vervaardigd door een boekhoudmachine, die ook de nodige controlegetallen produceerde. Dat was wel nodig ook, want door de snelle papertapereader brak er nog wel eens een tape, en na plakken moest alles wel weer kloppen. En dan waren de controlegetallen hard nodig. Die reader las zo snel dat bij kleine hoeveelheden er een stuk blanco tape voor en achter geplakt moest worden, een te kort stukje tape was al voorbij voordat hij ging lezen. Toen de programma’s klaar waren werden bij beide maatschappijen de ponskaarten ingelezen. Jan Lindenberg herinnert zich nog dat er speciaal voor dit doel aan de Schiekade een 1401 werd ingehuurd om tapes aan te maken. Na een maand kon die weer weg. In Den Haag gebruikte men de eigen 1401 om de tussenfase om te zetten naar /360 administratie. Hierna verdwenen de ponskaarten voor Collectief. We schrijven 1968 als deze /360 administratie begint, met weekruns. Het kon niet vaker want in het begin kostte alleen het lichten van de te muteren posten 30 uur. Ton Modderman heeft dit programma aangepast, zodat het alleen nog maar even snel keek of de post nodig was, en dan weer vlug verder ging. De tijd werd toen teruggebracht tot ongeveer 10% van die 30 uur. In 1972 werd een aantal bestanden overgeheveld naar de Data Cell en werd het MDS systeem geïntroduceerd als vervanger van de papertape invoer. Vanaf juni 1971 was er een conversiegroep bezig om alle gegevens in de tapeadministratie aan te vullen. Alleen met deze conversie was het mogelijk om offertes uit te draaien en de reserve te berekenen en vast te houden. Begin 1973 werd er een eindspurt genomen om in juli van dat jaar klaar te zijn met de conversie. In 1975 werd de Data Cell vervangen door de 3330 disk, een medium wat veel sneller en betrouwbaarder was dan de Data Cell. Toen Lego startte werd in eerste instantie alleen de brutoberekeningen overgenomen, de rest bleef /360 administratie. Naarmate Lego werd uitgebouwd werd de /360 administratie afgebouwd. In 1987 kwam het einde van deze administratie.
BPF In het artikel over de ingebruikname van nieuwe BPF systeem in 1977 wordt gewag gemaakt van de geschiedenis van systeem.
het dit
Hierna wordt het nieuwe systeem beschreven.
Bert Rosbach herinnert zich nog het volgende: In 1972 gaf men de opdracht aan een extern softwarehouse (Pandata) om een systeem voor BPF te ontwikkelen. Dat duurde maar en duurde maar. Wat daarvan de oorzaak was weet ik niet, maar op een gegeven moment werd de opdracht ingetrokken en is men het maar zelf gaan doen. Het nieuwe BPF-systeem ging in 1977 in productie. Het is nog steeds in gebruik, al is een groot aantal functies vervangen door VACBPF. Het is nog steeds de VTA voor BPF. Momenteel is men bezig het over te bouwen in SAP.
Alle medewerkers worden door Veldhuizen bedankt. Op de CD hebben we er wat namen bij gezet. En zo als Bert Rosbach hierboven al aangeeft draait dit systeem nog.
LEGO In 1974 werd besloten om een nieuw systeem te gaan bouwen. Het kreeg de naam Lego mee (Leven Groeps Otomatisering) om aan te geven dat het in stukken gebouwd ging worden, die gemakkelijk te vervangen zouden zijn. In 1977 geeft de directie nog eens een korte samenvatting van de geschiedenis en de toekomst met het nieuwe systeem. In 1979 wordt het eerste gedeelte opgeleverd, een batchprogramma. De aanwezigen bij het feest toen hadden er geen weet van dat dit systeem het meer dan 25 jaar zou uithouden. In 1982 werd begonnen met een belangrijke uitbreiding, Lego comptabel. Het werd in 1987 opgeleverd, gelijk met het treintje dat Ton Modderman jaren op zijn kast had staan, voordat het in 2004 aan Exciting werd geschonken. Na het succes met Labora en de S/38 in 1982 werd ook voor Lego een dergelijke invoer- en informatiepoot gebouwd, Klivia. In 1984 werd dit systeem opgeleverd. Vanaf dat moment groeide de S/38 en later de AS/400 van Groeps als kool. Het volgende verhaal is door Bert Rosbach verteld toen Lego 25 jaar draaide: Vandaag 25 jaar geleden zaten er een aantal mensen bijeen in een Chinees restaurant aan het Stadhuisplein. Duidelijk bezig met een feestje. Het was het feestje vanwege het gereed komen van een systeem, waarmee men gestart was in 1974, en dat op die dag voor het eerst in productie draaide. Het etablissement is al een tiental jaren ter ziele. Het systeem bestaat nog steeds. De naam van dat systeem? LEGO! Bij het horen van de naam van het systeem denkt men direct aan dat speelgoed uit Denemarken. De naam van het systeem zou connecties hebben met die plastic blokjes. Met een aantal componenten of blokjes kun je gemakkelijk een pensioengebouw neerzetten. Maar dat is een misverstand. LEGO als speelgoedmerk is een acroniem is van een tweetal Deense woorden. De vertaling is: "Goed speelgoed". De naam van het pensioensysteem is ook een acroniem, van LEVEN GROEPS AUTOMATISERING. De letters LE vormen geen probleem denk ik. De G ook niet. En die O? In de jaren 70 nam men het met de spelling niet altijd even nauw. Vandaar dus. Hoe is nu LEGO ontstaan?
Er was al een voorganger, het 360-systeem. Dat systeem kon een aantal zaken al, die nu ook door LEGO worden gedaan. Alleen was dat systeem uit 1968 technisch verouderd. De ontwikkelingen in de hardware lieten een aantal verbeteringen toe. Een van die ontwikkelingen was de mogelijkheid om grote hoeveelheden gegevens sneller te benaderen dan het doorspoelen van een tape. Ook was het mogelijk om grotere programma's te maken dan voorheen. De programma's van het 360-systeem waren niet groter dan 90 Kilobyte. Het geheugen van de toenmalige computer bepaalde die bovengrens. Het 360-systeem draaide op een computer met aanvankelijk een intern geheugen van 128 kilobyte. En ook de capaciteit per schijfgeheugen was groter geworden. In 1970 hadden we schijfgeheugens met een capaciteit van 2000 tracks van elk 3000 bytes. Totaal 6 megabyte. Tegenwoordig een lachertje. Het LEGO systeem was dus een grote sprong voorwaarts. Dat was nodig ook, want het 360-systeem begon behoorlijk traag te worden. De run om de posten te lichten bij de mutatieopdrachten duurde in 1971 ongeveer 10 uur. Eén programma, 10 uur. Het weekwerk was zo echt een week werk. En wat maakte LEGO nou zo bijzonder? De hoge graad van automatische verwerking. Voor een nieuwe post heeft men ongeveer een 15-tal gegevens nodig: 1. Het contractnummer van het pensioencontract, 2. Het groepsnummer (De groep bepaalt de berekeningswijze) 3. Het onderdeelnummer (Het onderdeel bepaalt de afrekeningwijze) 4. De mutatiedatum 5. De naam van de verzekerde en of het een mannetje of een vrouwtje is. 6. Zijn geboortedatum. 7. Die van zijn of haar partner, en eventueel ook of dat een mannetje of vrouwtje is. 8. De datum indiensttreding. 9. Eventueel de datum van opname in de regeling. 10. Het salaris met de bijbehorende omschrijvingscode 11. En of die persoon full-time of parttime werkt... Aan het eind van de reeks programma's rollen er de benodigde stukken uit, keurig berekend geplust en gemind. Er was dus in wezen heel weinig nodig om toch iets moois te maken. Waar ik in 1967 15 minuten over rekende, vulde je nu in 1 minuut in. Wat maakt LEGO nu echt uniek in het hele wereldje? Veel verguisd, maar toch zo af en toe geprezen: Planning. Een systeem ter bewaking van het handmatig op volgorde zetten van de veelheid van jobs. En dan ook nog niet één job vergeten. Dat lukte door bewaking van de datum van aanmaak van elke bestand, dat in job A gemaakt werd en in job B weer werd gebruikt. Bovendien zorgt het voor de juiste functionele dateringen. En sinds eind 2000 bestuurt het ook het draaien van de mutatiecyclus. De mutatiecyclus is de opvolger van de "week". Door de hogere frequentie mag je niet meer van de weekcyclus spreken. En zo af en toe redt het systeem ons ook nu nog. Vlak na de conversie van guldens naar euro's hadden we zo'n dump. Bij het maken van de JCL was er door een fout een bestaande generatie van een bestand verwijderd. Als "Planning" er niet was geweest, hadden we niet direct gemerkt dat er iets mis was. Waarschijnlijk een tijdje later, door allerlei verschillen. En probeer het dan nog maar weer eens te herstellen. Ik heb liever een dump. En dat nu ging draaien in mei 1979. Maar was het 360-systeem volledig afgeschaft in dat jaar?. Nou nee. Alleen de bruto-berekeningen werden al volgens LEGO uitgevoerd. Na deze berekeningen werden de LEGO-reeksen omgezet in
360-reeksen, waarmee de comptabele verwerkingen werden uitgevoerd. Daarna pas werden deze reeksen weer omgezet in records om het datacellbestand bij te werken. Het regelingenbestand was al wel in orde. Tot op vandaag. En hoe ging het verder. In al die 25 jaar is er gewerkt aan het systeem. Aanvankelijk vlogen de dumps in het mutatieprogramma ons om de oren. Kennelijk was het FO of het TO nog niet sluitend. Soms kan de complexiteit van de diverse processen ons ook boven het hoofd groeien. In de jaren 1981 en 1982 is de reserveberekening en lijstvervaardiging aangepast en verbeterd. Daarmee werd het gebruik van 360-reeksen een stukje verder teruggedrongen. In 1983 werd het zelfgeschreven databasesysteem vervangen door IDMS. Dat ging soms gepaard met een paar blauwe plekken in de vorm van ongunstige doorlooptijden. Maar ook daar vonden we altijd weer een oplossing. In 1984 werd gestart met het FO voor de uitfasering van het laatste stukje 360-systeem. Het project LEGO-Comptabel. In 1987 kwam dit project gereed, en op 31 mei 1987 draaide de eerste weekcyclus zonder 360-reeksen. Daarna is het systeem alleen maar beheerd, en aangepast aan technische en wettelijke ontwikkelingen. Zo is in 1989 het planningsysteem herbouwd in DB2. In 1992-1993 is er een poging gedaan om het systeem te herbouwen naar een systeem met meer databaseondersteuning. De bouw van dat systeem werd echter te duur gevonden, en de stekker is er uit getrokken. Dat is naderhand ook nog wel eens gedaan, met het project "Automatische terugdraaiers". In 1995 werden de records uitgebreid, en op basis van die uitbreiding is groot aantal kleine aanpassingen en verbeteringen gedaan. We hebben toen ook de verzekeringen mogelijk gemaakt tegen het ANW-hiaat en het WAO-gat. In de jaren daarna hebben we het ontzettend druk gehad met allerlei zaken, die over ons heen spoelden: Millennium, 2000N, Verbod Uitstelfinanciering, 3% rekenrente naast 4% rekenrente, de euro, art 2b PSW. Over het millenniumprobleem wil ik alleen nog opmerken, dat er in LEGO alleen een aanpassing hoefde te komen bij het verwerken van de ingevoerde data. Voor de rest was LEGO al helemaal ingericht op het gebruik van datums in verschillende eeuwen. Nu zit er weer een wettelijke maatregel aan te komen: Sexe-neutraal tarief. Geen onderscheid tussen mannetjes en vrouwtjes. Een uitdaging dus. Sinds kort zijn we overgegaan op het releasegewijs verwerken van de aanpassingen. Maar gelukkig, er is troost voor allen, die zuchten onder het gebrek aan verandering. Sinds het begin van het jaar zijn we bezig met een gigantische herstructurering van LEGO. Dit om LEGO om te vormen naar de architectuur volgens het FLAMING-project. Als alles volgens plan gaat, is volgend jaar rond deze tijd de nieuwe versie van LEGO in productie. Daarbij is IDMS vervangen door DB2, zijn de gevolgen van de polissplitsingen opgeheven. En zijn we volop bezig met het vervolg op deze stap, de eigenlijke inrichting overeenkomstig de FLAMING-architectuur. Er ontstaat dan een aparte VTA (Verzekering Technische Administratie). Er komt een apart deel voor de berekeningen. Dat berekeningendeel wordt zodanig opgezet, dat een nieuw product sneller dan tot nu toe in productie is. Ook komt er een apart deel voor de NAW-gegevens, en er worden nog weer andere functiegerichte delen. Alleen zijn dat geen LEGO-delen meer, maar algemene delen. Ik heb er het volste vertrouwen in, dat het nieuwe systeem eenzelfde succes als LEGO wordt. Niet alleen voor de automatiseerders, maar vooral voor de gebruikers. Bert Rosbach.
Valk en David Deze systemen hebben administratief niets met elkaar te maken. Maar technisch stonden beide aan de wieg van de S/34. David was het proefproject.
In 1979 zit Sam Jonker achter de eerste S/34 terminal. Valk is een jaar later de tweede toepassing. De eerste grootschalige toepassing waar terminals aan te pas kwamen. Herman Huizinga (op dat moment directeur NN Leven) wordt achter de terminal gezet om de eerste handelingen te verrichten. David zou na enkele jaren overgezet worden op het mainframe. Het was proefproject voor DB2, voordat Ilias er aan moest geloven. Valk is steeds de AS/400 trouw gebleven.
Klivia Een paar maanden later dan gepland, in maart 1984, kan Groeps via Klivia mutaties invoeren en informatie trekken . In de loop van de jaren is Klivia inderdaad uitgegroeid tot de plant die Dick zich in 1980 al voorstelde. Het is vanaf het begin de zwaarste toepassing geweest op de S/38, later de AS/400.
ORA ORA was het eerste zware batchsysteem, dat onder DB2 werd overgebouwd. ORA zorgt voor de afrekening van contracten met overwinst en winstdelingtechnisch resultaat. Het was een oud systeem uit de jaren zestig en moest nodig vernieuwd worden. Koos Kerkhof mocht dit project leiden. Hij startte in 1989. ORA werd helemaal opnieuw gebouwd. In 1992 beschrijft Koos de stand van zaken. Hij kan het niet laten om ook even de volleybal- en schaakresultaten te noemen. In september 1993 wordt het systeem overgedragen aan de onderhoudsgroep. En eindigt Koos met de woorden “in principe zijn de gestelde doelen binnen het budget gehaald”. ORA vraagt in de maanden dat er wordt afgerekend heel wat cpu seconden. Een teken dat er veel functionaliteit in deze programma’s zat. Al zorgde het “leereffect” met zo’n grote DB2 database in het begin wel eens voor wat extra secondes. Maar dat werd snel verbeterd naarmate de kennis van DB2 toenam.
Connect Het verkrijgen van salarisgegevens van alle collectieve deelnemers was elk jaar weer een marteling. En al die gegevens moesten keurig ingetikt worden. Terwijl toch de meeste klanten wel een computer of een PC hadden waar alles instond. Met grote klanten was er al jaren uitwisseling met tapes en floppy’s. Bedrijven besloot dit probleem via telefoonverbindingen aan te gaan pakken. Er werd een groep geïnstalleerd, bestaande uit automatiseerders en gebruikers, die gezamenlijk aan de slag gingen. Er was voldoende kennis in huis bij de automatiseerders over belnetwerken, daar was met Markis ervaring mee opgedaan. In 1994 werd Connect opgeleverd. Het was vanaf het begin een succes. Niet alleen NN, ook de klanten zaten hierop te wachten. Binnen een jaar gingen de gegevens van 175.000 deelnemers over de lijn. In 1995 was er nieuwe versie die ook Schade Bedrijven aankon.
In 1996 kreeg het project de ING IT Award. In 1997 worden er al 250.000 deelnemers mee verwerkt.
Stock Voor beleggingsverzekeringen moest bij Individueel het systeem Life worden aangekocht omdat Labora niet geschikt was. Ook Lego bleek niet te voldoen voor deze vorm van verzekeren. In 1995 werd besloten er een nieuw programma voor te maken. Omdat de druk van buiten erg groot was en een AS/400 programma sneller geschreven kon worden, werd met de net vastgestelde regel: ”niets nieuws op de AS/400” gebroken. Een gezamenlijke werkgroep van automatiseerders en gebruikers zette met vliegende vaart Stock in elkaar. Net op tijd, want de aanvragen vlogen binnen. De database groeide en groeide. Ook hier, net als bij Life, was de eerste run van de maand een verschrikking qua doorlooptijd. De batch moest ’s avonds vroeg beginnen om redelijk op tijd klaar te zijn. En er ging wel eens wat mis. Dan was er uren geen online. De uitvoer van Stock gebeurde met ITP op een PC.
GBA In 1995 werd NN aangesloten op de GBA. Hiermee konden de laatst bekende adressen van onze relaties worden opgezocht. Bij de start waren er nogal problemen met de verbinding. Maar dat kwam omdat om een of andere duistere reden de oudste PC was ingezet die we in huis hadden. En die gaf nogal eens storing.
PC en AS/400 De gebruikers bij Bedrijven hadden altijd de hun geboden mogelijkheden op de computer goed benut. Culprit, de querytaal op het Mainframe werd veel gebruikt. En queries op de AS/400 draaiden elke dag. De PC werd dan ook juichend begroet bij bedrijven en er werd heel wat afgeprogrammeerd. Om te voorkomen dat gegevens ingetikt moesten worden kwam er vraag naar koppelingen. Eerst met floppy’s, maar dat was nogal omslachtig. Een rechtstreekse verbinding wilde WAC (werkplek automatisering collectief). Naar het mainframe stuitte op te veel bezwaren, daarom werd er een
koppeling gemaakt naar de AS/400, en werd Lego verkort neergezet op de AS/400E, de AS/400 voor bedrijven. Het gaf technisch wel wat kopzorgen maar uiteindelijk lukte het om met CAS/400 de verbinding te maken. Op deze manier konden de PC’s op het LAN gebruikmaken van Lego gegevens. In 1994 zijn er 83 PC programma’s bij Bedrijven in gebruik, die meer doen dan alleen maar cijfertjes voor één afdeling leveren. PC’s, AS/400 en mainframe zijn zodanig gekoppeld dat alle platforms nodig zijn voor de administratie. Tussen 9.00 en 16.00 is er een verbod om queries te draaien op de AS/400, omdat anders de responsetijden voor alle andere gebruikers teveel achteruit gaan. Ondanks dat verbod is de AS/400E de snelst groeiende machine van NN.
IP In 1992 start er een onderzoek in het kader van het Informatieplan. Waar gaat Bedrijven naar toe met haar administratie. Dit onderzoek is van IBM, Verkenningsfase. In 1993 volgt er een Detailanalysefase en daarna gaat er een werkgroep DBO verder. De naam (DataBase Ontwikkeling) dekt nauwelijks de lading: het gefaseerd bouwen van een nieuw systeem voor Collectief. Het werk van deze groep wordt in 1994 overgenomen door de projectgroep Informatieplanning. Aan het eind van 1994 ligt er een Informatieplan Collectief. Dit is de samenvatting van de belangrijke systemen op dat moment. De korte omschrijving is uit het rapport overgenomen. In 1995 lijken de doelen van de Collectieve en Particulieren plannen toch samen te kunnen gaan en in 1996 worden de plannen voor fase 1 geconcretiseerd. Dit schema geeft in heel grote lijnen de architectuur weer van de nieuw op te zetten systemen.
Er wordt samen met Particulieren veel tijd gestoken in de VTA (Verzekeringstechnische Administratie), de Rekenbox, Flits (het nieuwe Incasso systeem) en Workflowmanagement. Het lukt echter niet om het totale systeem van de grond te krijgen.
In 1999 wordt besloten om eenvoudiger door te gaan. Workflow management en Imaging hebben zich bij Schade dan al bewezen en worden dan ook als eerste aangepakt. Eind 1999 start SEAL. In datzelfde jaar start EB card, wat een vernieuwing in kleine stappen mogelijk moet maken. Maar voordat deze ontwikkelingen kunnen bewijzen de nieuwe automatiseringsaanpak te zijn, moeten er ING programma’s komen. FlamING ook voor Employee Benefits. De eerste stappen kunnen al in 2002 gezet worden. Miedema geeft aan dat er voortgebouwd is op EB Card. Maar zoals de lezer nu begrijpt is de ondergrond wel iets breder dan alleen EB Card. Lego blijft nog even het fundament.
