Veel bedrijven zijn op dit moment bezig om naast elkaar twee belangrijke projecten tot een succesvol einde te brengen: de invoering van de euro en de oplossing van het millenniumprobleem. Om redenen van efficiëntie, kostenbesparing en verhoging van de kwaliteit is het raadzaam om diverse dwarsverbanden tussen beide projecten te leggen.
Het euro- en het millennium-probleem worden beide door de meeste IT-managers gezien als ‘van buitenaf komende onheilen’, die zo snel mogelijk tegen de laagst mogelijke inspanning tot een goed einde gebracht moeten worden. Deze projecten brengen immers een grote verstoring teweeg in de dagelijkse business van het IT-bedrijf en brengen tal van problemen (oud zeer en vuile was) naar boven, die men liever binnenskamers had willen houden.
Voor veel bedrijven betekenen deze projecten dat de oorspronkelijk geplande, innovatieve automatiseringsprojecten tijdelijk worden stilgelegd of op een laag pitje worden gezet. Daarbij komt dat beide projecten helaas vaak de inzet vereisen van de creatiefste en deskundigste mensen van de IT-afdeling.
Genoeg reden om ernaar te streven de beide projecten ‘mean and lean’ op te zetten en zo snel mogelijk resultaten te boeken.
Beide projecten, met name het oplossen van het millenniumprobleem, kunnen een aantal verbeteringen binnen de IT-organisatie realiseren. Mits de tijd genomen wordt om tot verbeteringen te komen in de dienstverlening.
Zelfde resources
Vanuit het perspectief van het management kan het millenniumprobleem bijna volledig door de IT-functionarissen worden afgewikkeld (met uitzondering van de testfase). Het millenniumprobleem wordt als een louter technisch defect gezien dat onderzoek vereist, niet alleen binnen de eigen applicaties, maar ook binnen alle technische installaties.
Daarentegen beschouwt het management de komst van de euro voor zijn administratieve systemen (met name de betaal- en ‘netting’-functies) meer als een functionele aanpassing op bestaande applicaties: als adaptief onderhoud. Voor de invoering van de euro wordt een veel grotere inbreng van de ‘business’ verwacht; de euro schept immers nieuwe kansen in de markt. Hier speelt de IT-organisatie haar ‘normale’ ondersteunende rol.
Daarom zal men geneigd zijn om de beide projecten met gescheiden opdrachten en verschillende teams te laten uitvoeren. Op zich is daar niets tegen; uiterlijk onderscheiden beide projecten zich naar verschillen in:
doelstellingen, onderzoeksgebied, omvang, resultaten, tijdlijnen, en projectsamenstelling.
We hebben geleerd vanuit een projectmatige aanpak te streven naar risicobeheersing en -spreiding om de afhankelijkheden tussen (beide) projecten te minimaliseren. Ook hebben we geleerd slechts sturend op te treden, daar waar projecten botsen met andere projecten of met de organisatie.
Veel bedrijven hebben derhalve separate trajecten (projecten) voor euro en millennium ingericht.
De projecten zitten elkaar ook nog eens in de haren zitten, want ze maken gebruik van dezelfde schaarse resources:
- IT-medewerkers en gebruikersafdelingen;
- leveranciers van pakketsoftware, die euro- en millenniumbestendige versies leveren.
- hardwareplatformen, waarop getest moet worden
- netwerkinfrastructuur, waarmee getest moet worden (deels met uitzondering van specifieke tijdreistesten)
- tijdsfasering, waarbinnen alles gerealiseerd moet zijn.
Projectopzet
Indien synchronisatie plaatsvindt van de beide projecten aan het einde van iedere fase (bij de oplevermomenten), kan uit de synergie voordeel behaald worden. Ik noem dat synergie-effect ‘het waakzame oog’. Hiermee wil ik aangeven dat over beide projecten heen gelet moet worden dat beide op eenzelfde leest geschoeid zijn en blijven. Dat geldt met name ten aanzien van de onderdelen: projectorganisatie, -vorm en -aanpak; procedures voor projectdocumentatie, risicoanalyse, voortgangsbewaking, kwaliteitsbewaking, en overlegstructuur (intern en extern).
Ik kies er bewust voor om de kwaliteit van binnenuit de projecten te verbeteren en niet van bovenaf of van buitenaf.
De zelfsturende projectteams moeten lering trekken uit elkaars bevindingen en resultaten, en op basis daarvan proberen verbeteringen aan te brengen.
Bovendien is het voor de lijnorganisatie en voor de externe partijen (leveranciers) van belang dat beide projecten langs dezelfde (project)wegen opereren en resultaten proberen te boeken.
Projectresultaten
Aan het einde van iedere fase kan men elkanders bevindingen checken op omissies, andere aannames, tijdlijnen, verschillen in oplossingsrichtingen, enzovoort.
Tevens kan de aanpak van het vervolgtraject besproken worden, waardoor een aantal activiteiten, die mogelijk dubbel uitgevoerd gaan worden, te minimaliseren zijn. Denk daarbij aan:
- het benaderen van leveranciers;
- het bijwerken van contracten;
- het bijwerken van licentie-overeenkomsten;
- het bijhouden van geïnventariseerde objecten;
- de participatie van gebruikers en systeembeheerders;
- het bijwerken van documentatie;
- het opstellen van escalatieplannen, noodplannen, en uitwijkplannen.
Voordelen synergie
De beoogde voordelen zitten dus in het uniformeren van projectactiviteiten en het eenmalig uitvoeren van werkzaamheden die op eenzelfde resultaat uit zijn.
Hierdoor zijn besparingen te bereiken in de vorm van minder gebruik van resources.
Een dergelijke aanpak levert ook de volgende gemeenschappelijke eindproducten (‘deliverables’) op:
- inventarisatie van objecten (applicaties, pakket-oplossingen, maatwerk-oplossingen, tools, hardware, netwerk-apparatuur, etc.);
- overzicht van interfaces;
- overzicht van leveranciers;
- licentie-/onderhoudscontracten;
- inkoopcontracten;
- bijgewerkte documentatie;
- ‘coding practices’;
- opwaardering;
- testplannen/testscripts;
- kwaliteitsplannen;
- versie- en configuratiebeheer;
- veranderings- en probleembeheer.
Waarschuwingen
Waarom stel ik een dergelijke aanpak voor?
Het millenniumprobleem hebben we te danken aan het niet meer up-to-date zijn van standaarden, routines en procedures voor systeem-ontwikkeling; versies van programmeer-talen; versie van pakket-software; licenties en onderhoudscontracten; hardware-platformen, systeemprogrammatuur, enzovoort.
Blijkbaar hebben we ons adaptieve en correctieve onderhoud laten verslonzen en krijgen we daar nu de rekening voor gepresenteerd. De kwaliteit van het ontwikkelproces, de gehanteerde standaarden, de routines en de procedures voor systeemontwikkeling, de overdrachtsprocedures om software van de ontwikkelomgeving via de test- naar de productieomgeving te verplaatsen, en de wijze van beheer van systemen hadden ons in een veel vroeger stadium moeten waarschuwen dat we op verouderde leest geschoeid waren. De in onbruik geraakte versies van exotische programmeertalen hadden ons moeten waarschuwen dat we ons in een doodlopende straat bevonden.
Het feit dat we niet meer beschikten over de broncode in de ontwikkelbibliotheek had ons eraan moeten herinneren dat we tegen een potentieel risico zouden aanlopen.
Het niet tijdig vernieuwen van licentieovereenkomsten met leveranciers van pakketsoftware, danwel het aangaan van nieuwe licenties voor overeenkomstige softwarepakketten, had ons alert moeten maken voor toekomstige gevaren.
Geïntegreerde aanpak
Banken en effectenhuizen moesten op 1 januari 1999 gereed zijn om het girale betalingsverkeer en het effectenverkeer in Nederland in euro’s af te wikkelen. Op dezelfde datum moesten hun bedrijfskritische systemen gecertificeerd zijn voor het millenniumprobleem. Het bankwezen wordt hierin gecontroleerd door De Nederlandse Bank.
Vaak opereert bij deze financiële instellingen op centraal projectniveau een projectbureau dat voor de euro of het millennium het aantal ‘gecertificeerde’ applicaties bijhoudt. Met behulp van ’thermometers’ tracht het de voortgang van het proces te bewaken. Ook moet het aantonen dat het proces voldoende kwaliteit heeft. Door middel van procedures wordt een kwaliteitsnormering opgesteld en vervolgens nagestreefd, die nog niet in die vorm en diepgang werd gekend.
Deze methodiek kost een overdosis aan resources, wordt als een dodelijk proces voor de organisatie ervaren en is ‘verkeerd gerichte energie’. Het creëert namelijk negatief gedrag en appelleert niet aan positief gedrag.
Het gebrek aan kwaliteit binnen het normale ontwikkel- (productie-)proces van de IT-organisatie heeft ons in het nabije verleden blijkbaar nauwelijks gewaarschuwd of tegengehouden. Wat zou dan de toegevoegde waarde van een centrale kwaliteitsborgende functie zijn, die een ‘politiestaat’ creëert en ‘law and order’ probeert te handhaven binnen de IT-organisatie? Een organisatie, die bol staat van de losbandigheid en zich in veel opzichten nonconformistisch opstelt.
Professionaliteit en kwaliteit moeten blijken uit de organisatie zelf, uit de inrichting van de processen binnen de IT-organisatie en uit haar producten en diensten, en zijn niet van boven af te dwingen, en nauwelijks van boven af inhoudelijk te besturen.
Ik zie voldoende redenen om de vaak afzonderlijke projectprocessen van millennium en euro te laten samensmelten tot een smeltkroes van aanbevelingen en verbeteringen voor de toekomst.
Een geïntegreerde aanpak van de projecten is gewenst, waarbij beide projecten met elkaar worden verankerd en zo min mogelijk centraal leiding wordt gegeven. De centrale leiding moet juist de geïntegreerde coördinatie rond de beide projecten als haar voornaamste aandachtsgebied beschouwen.
Win/win-situaties
Door deze aanpak zijn de volgende win/win-situaties te bereiken:
Volledigheid van objecten
Beide projecten dienen hun reikwijdte te bepalen. Welke systemen en applicaties vormen mogelijkerwijs onderwerp van onderzoek? Vaak lukt het de IT-organisatie niet om snel op een rijtje te krijgen welke systemen en applicaties er momenteel (nog) in gebruik zijn, welke uitgefaseerd en vervangen worden en wanneer die vervanging plaatsvindt. Welke projecten zijn nog in uitvoering en vormen mogelijk een bedreiging voor de toekomst, indien de betreffende systemen of applicaties niet op tijd worden opgeleverd?
Vaak begint ieder project met een inventarisatieopdracht; een eerste analyse van de vereisten of een vooronderzoek.
In het belang van beide projecten zijn hier verbanden te leggen. Men hoeft zich niet per definitie te beperken tot één onderzoek; beide partijen zouden gebruik kunnen maken van elkaars onderzoeksresultaten.
Wanneer beide onderzoeken onafhankelijk van elkaar plaatsvinden, worden sterke claims gelegd op systeem-, applicatie- en product managers. Dat mag niet onderschat worden. Omwille van het complete plaatje – het aantonen van volledigheid – kan ik me een dergelijke opstelling wel voorstellen. Het millenniumprobleem omvat immers ook hardware-objecten en dergelijke, die in het geval van de euro buiten beschouwing kunnen blijven.
Het sluiten van de kranen
Beide projecten hebben er belang bij om de afbakening van hun veranderings- of onderzoeksgebied zo consistent en helder mogelijk te houden.
Het aanschaffen door de organisatie van nieuwe, niet (voor euro en het jaar 2000) gecertificeerde automatiseringproducten vormt een potentiële bedreiging van het project. De verkoop (en de aanschaf) gaat immers gewoon door. Daarom moet de bestel- of inkoopfunctie ‘opgevoed’ worden. De organisatie, die bestel- en inkoopafdelingen heeft bij verschillende werkmaatschappijen, moet ervan doordrongen zijn dat euro- en millenniumbestendigheid bij de standaard leveranciersverplichtingen behoren. Het aanpassen van de inkoop- en leveringsvoorwaarden met standaardclausules op dit gebied kan samengaan.
Leveranciersbenadering
Beide projecten hebben belang bij een goede relatie met de leveranciers van (standaard) pakketoplossingen en bij duidelijkheid omtrent (het tijdstip van) de levering van nieuwe software-versies.
De inventarisatie zal opgeleverd hebben dat een aantal gebruikte pakketten geleverd zijn door externe leveranciers. Daarmee ligt in veel gevallen de verplichting om het pakket aan te passen buiten de eigen IT-organisatie (deze laatste haalt verlicht adem).
Niet altijd is meer bekend wie de leverancier is die momenteel het pakket vertegenwoordigt (in Nederland), noch waar deze leverancier gevestigd is. Vaak zijn ook de licentie-overeenkomsten en de onderhoudsverplichtingen niet duidelijk vastgelegd of terug te vinden, waardoor de mate waarin de leverancier nog aansprakelijk gesteld kan worden, onduidelijk is.
Ook ‘zwarte software’ kan uit de inventarisatie naar boven zijn gekomen; niet altijd wordt software langs de formele kanalen aangeschaft en geïmplementeerd. Uiteraard zal ook dit rechtgetrokken moeten worden.
Door een gezamenlijke inspanning (dezelfde vragen dienen immers in veel gevallen door dezelfde leverancier beantwoord te worden), kan bepaald worden in welke mate de leverancier tegemoet komt of wil komen aan de wensen van de betrokken organisatie.
Bovendien wordt duidelijk wanneer een nieuwe (euro- en/of millenniumbestendige) versie geleverd zal worden en onder welke versie van het besturingssysteem en onder welke platformeisen dit zal plaatsvinden.
Generieke routines
Zowel voor het oplossen van het millenniumprobleem als voor de invoering van de euro zullen zoveel mogelijk generieke routines geschreven moeten worden. Deze moeten centraal opgesteld worden voor de verschillende ontwikkelplatformen en dienen door alle ontwikkelteams gebruikt en aangeroepen te worden binnen de programmatuur.
Voorkomen moet worden dat ieder ontwikkelteam een eigen oplossingsrichting kiest; om redenen van eenduidigheid en efficiëntie verdient het de voorkeur om zoveel mogelijk een standaardoplossing te kiezen (en te onderhouden).
Achterstallige documentatie
Het lijdt geen twijfel dat ontdekt wordt dat ook de programmadocumentatie bijstelling behoeft.
Het lijkt dan ook evident dat beide projecten in hun opdrachtdoelstelling meenemen dat zij ervoor zullen zorgdragen dat de desbetreffende systeemdocumentatie ‘op orde gebracht’ wordt. De vraag is of beide projectteams dat ieder voor zich moeten doen, danwel dat één persoon (of team) dat voor het gehele systeem integraal doet.
De volgende vraag is waarom de documentatie niet goed beheerd werd. Reden te meer om het documentatiebeheer gelijk goed te verankeren in de project- en lijnorganisatie. Wie houdt de documentatie bij; onder wiens beheer valt dit stiefkind en wie betaalt het gelag in de toekomst?
Testen
Ook voor de volgende onderdelen kunnen beide projecten bij elkaar aanhaken: het opzetten van testplannen en van een functionele test, het houden van een schaduwtest, een ‘end-to-end’ test en een stress-test (prestatietest).
Een referentietest(omgeving) en de beschikbaarheid van cast-tools kunnen de testsessies van beide projecten helpen bekorten. Dat kan een belangrijke kostenbesparing opleveren en minder belastend zijn voor de gebruikers- en IT-organisatie.
Versie- en configuratiebeheer
Door tijdgebrek bij beide projecten wordt men gedwongen meerdere omgevingen naast elkaar te laten bestaan. Hierdoor worden stringentere eisen gesteld aan het versie- en configuratiebeheer.
Een goed moment om eens te kijken hoe het gesteld is met het beheer van omgevingen, platformen, hardware-configuraties, enzovoort.
Veranderings- en probleembeheer
Net als hierboven geldt dat meerdere versies van de programmatuur naast elkaar een stringenter beheer noodzakelijk maken. In hoeverre wordt dit beheer ondersteund met geautomatiseerde hulpmiddelen? In welke mate is men afhankelijk van experts? Veelal worden hier de meeste risico’s gelopen.
Uitwijk- en noodscenario
Als vangnet onder de productie behoren voor de bewaking van de continuïteit van de kritische bedrijfsprocessen een uitwijk- en een noodscenario aanwezig te zijn. Met projecten als euro en millennium behoren deze plannen – als ‘standard procedure’ – uit de kast gehaald, nog eens nadrukkelijk bestudeerd en, indien mogelijk, gerepeteerd te worden.
Efficiënt
Door een gelijke projectopdracht, een identieke projectorganisatie, een gelijke uitstraling, een geïntegreerde coördinatie en een evenwichtig belang (prioriteit) in de organisatie kunnen beide projecten op dezelfde leest te geschoeid worden. Door overleg en samenwerking, waarbij zoveel mogelijk gebruik wordt gemaakt van elkaars onderzoeksresultaten en beleidsvoornemens (uitwerking van oplossingsrichtingen) is te vermijden dat langs twee gescheiden kanalen wordt geopereerd.
Zo kan worden voorkomen dat de (gebruikers- en IT-)organisatie onnodig wordt lastig gevallen en belast; leveranciers twee keer worden benaderd; schaarse (test-)platformcapaciteit wordt geclaimd; met prioriteiten wordt geschoven, en dubbele werkzaamheden worden uitgevoerd.
Ook miscommunicatie, non-synchronisatie, over- dan wel desorganisatie zijn op deze manier te voorkomen.
Een geïntegreerde aanpak van beide projecten zal synergie- en efficiëntievoordelen opleveren. De ‘nalatenschap’ van beide projecten zal meer kunnen zijn dan het bereiken van de individuele doelen van ieder project afzonderlijk.
J.J. Neeft en F. Veltman, business consultants Applicon Nederland
Onderwerpen van samenwerking
Onderwerp | Invoering van de euro | Millenniumbestendigheid |
Aantallen onderzoeksobjecten | bedragvelden aanwezig? | datumvelden aanwezig? |
Leveranciersbenadering | wanneer euro release? | wanneer Y2K versie |
Licentiebeleid/onderhoud | recht op onderhoud? | recht op onderhoud? |
Beheer van generieke tools | d.m.v. standaardroutines | d.m.v. standaardroutines |
Testmanagement | testopzet, acceptatietest | testopzet, acceptatietest |
Documentatie | up-to-date brengen/houden | up-to-date brengen/houden |
Versie- en configuratiebeheer | up-to-date brengen/houden | up-to-date brengen/houden |
Veranderings- en probleembeheer | up-to-date brengen/houden | up-to-date brengen/houden |
Uitwijk en noodplannen | up-to-date brengen/houden | up-to-date brengen/houden |