In het kort wat voorafging aan mijn huidige functie. In 1968 ben ik afgestudeerd bij "van der Leeden" (Instrumentele analyse methoden) op de bouw van een Mössbauer spectrometer en onderzoek van het Mossbauereffect van IJzeracetaat bij lage temperaturen (dat betekende ondermeer dat ik een metalen Helium cryostaat moest realiseren met Berilium vensters in die tijd de eerste metalen cryostaat op de afdeling Lage Temperaturen ). De grote hoeveelheid gegevens die verwerkt moesten worden om het Mössbauer spectrum te bepalen nodigde uit tot computerverwerking op de X8 van de afdeling Wiskunde. Achteraf gezien een eerste verbinding met automatisering? Na mijn afstuderen ging ik aan het werk bij Philips Datasystems in Apeldoorn bij de ontwikkeling van geheugens voor de computersystemen. Na enige tijd kreeg ik de leiding over de geheugenontwikkeling en later ook enkele andere activiteiten zoals displays. In 1979 ben ik overgestapt naar Philips Test en Meetapperatuur in Almelo als groepsleider voor de ontwikkeling van diverse soorten meetapperatuur. Later kreeg ik de algemene leiding als bedrijfsleider over productontwikkeling,fabrikage, logistiek en centrale service.

Vanuit die beide laatste functies was ik vanuit de gebruikersgroep betrokken bij het overleg over Interne Automatisering van de Product divisie. In 90/91 werd me gevraagd als automation manager voor de Product divisie Industrial Electronics het automatiebeleid te definieren en vorm te geven. Philips Industrial Electronics is een van de kleinere product divisies van Philips met circa 7000 personen wereldwijd verdeeld over 15 productieplaatsen en met verkoop- en service- organisaties in 15 landen. De activiteiten zijn tegenwoordig georganiseerd in werkmaatschappijen die wereldwijd de verantwoordelijkheid hebben voor bepaalde product-markt-combinaties. De producten lopen uiteen van electonische voedingsunits en Closed Circuit TV Cameras tot Complexe op klantenorder samen te stellen zoals Electronen microscopen en X ray diffractie spectrometers. Daarnaast worden op klantenspecificatie projecten uitgevoerd o.a integrale voorzieningen voor security en public adressing in gebouwen, congressystemen of integratie van producten in hun omgeving.

In 1990 werd de Bussines Automatie ingevuld met grotendeels oude tot zeer oude op maat gemaakte mainframe programmma’s die in de loop van de tijd in hoge mate functioneel waren uitgebreid en toch bleven er nog veel wensen die door complexiteit steeds moeilijker te realiseren waren. De Technische Automatisering, Systemen om electrische, mechanische en software onwerpen te ondersteunen (CAD) waren redelijk bij de tijd. Maar in die wereld lopen de ontwikkelingen redelijk snel en blijven de gebruikers regelmatig om verbetering vragen. Door de grote varieteit in activiteiten en de inmiddels grotere zelfstandigheid van de werkmaatschappijen van de Product divisie was het voor velen de vraag of men zich wel zou moeten confirmeren aan een algemeen beleid. Van groot belang op dat moment was de definitie van, wat ik noemde, een functionele systeem architectuur. Een definitie van min of meer onafhankelijke automatie gebieden. Aan de hand van een aantal kriteria zoals functionele samenhang, minimale- niet tijd kritische- interfaces, beheer van de basis gegevens kunnen stabiele oplossings onafhankelijke gebieden gedefineerd worden. Ook binnen de hoofdgebieden zijn op dezelfde manier deelgebieden te definieren. Voor elk van deze gebieden kiezen we na analyse van de gewenst functies een voorkeursoplosssing. Voor enkele deelgebieden moeten we vaststellen dat de functies verschillend zijn voor de specifieke activiteiten van werkmaatschappijen hoewel dan veelal toch de wensen van enkele groepen redelijk goed samenvallen.Zo hebben de leveranciers van systemen met een grote varieteit aan opties behoefte aan ondersteuning van het verkoop proces met een "configurator" waarmee de verschillende combinatie mogelijkheden en beperkingen weergegeven kunnen worden. Wanneer we dit stuk isoleren blijken vele ander functies weer wel met algemenere functies te kunnen worden ingevuld. Werkmaatschappijen die goede redenen hebben om van de voorkeurs-oplossing af te wijken hebben de ruimte, na goed overleg, voor dat deelgebied tot een andere keus te komen zonder dat dat consequenties heeft voor de andere gebieden en het totaal concept. Hierdoor wordt voorkomen dat een afwijking van de gemeenschappelijke oplossingen doorwerkt op het totaal. Door eerst de discussie te richten op de gewenste functies en pas daarna tot een keus van het appplicatie pakket te komen is het proces in rationeler sfeer gekomen in vergelijking van situatie waar keuze van een pakket vooraf gaat aan de duidelijke definitie van het gebruik. Ondanks de grote verscheidenheid blijken de voorkeurs oplossingen in het overgrote deel van de situaties te voldoen. Drie factoren speelden hierbij een doorslaggevende rol:

1. Door de keuze van de totale architectuur konden de gebieden die specifieke bussines functies moesten afdekken separaat gehouden worden van de gemeenschappelijke elementen.
2. De gekozen applicatiepakketten boden een redelijke tot hoge flexibiliteit om ze aan te passen aan specifieke wensen. Nadeel is uiteraard dat hierdoor toch weer maatwerk ontstaat daartegen over staat dat we niet vastlopen in het realiseren van de vereiste functies.
3. Door goede samenwerking met de leveranciers bleek het mogelijk veel van onze wensen in de standaardpakketten te krijgen. Door de ervaring met de oude eigen gebouwde oplossingen en de grote varieteit van verschillende bussines processen bleken we een goede partner.

De hoge mate van integratie zowel van de afzonderlijke applicaties en hun samenhang maken de invoering tot een kritische, en vrij lastige activiteit. Zo’n project is zelfs te zien als een vorm van kwaliteits- of wrijvings-coefficient meting van de betreffende organisatie.