Implementeren van een FMIS

3048-1

Implementeren van een FMIS A.C. Stolk

1. 2. 2.1 2.2 3. 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4. 4.1 4.2 4.3 5. 6.

Inleiding Voorbereiding op implementatie Implementatie als project Projectbeheersing Activiteiten tijdens de implementatie Organisatorische wijzigingen inventariseren Parameters en autorisaties instellen Gegevens converteren of verzamelen Infrastructuur en werkomgeving inrichten De feitelijke implementatie uitvoeren Opleiding en voorlichting verzorgen Acceptatietest uitvoeren Documentatie en naslagwerken waarborgen Beheer na implementatie beleggen Technieken Procedure schema’s Entiteit Relatie Modellen Planning Praktische aanwijzingen Literatuurverwijzingen

1 2 2 6 9 10 11 12 14 14 18 20 21 21 22 22 24 25 28 29

1. Inleiding In het artikel Pakketselectie van een FMIS (Facilitair Management Informatie Systeem) is aandacht besteed aan het selecteren en het volgens afspraak verkrijgen van een FMIS van de leverancier. In dit artikel wordt ingegaan op de vraag hoe een dergelijk systeem vervolgens in de organisatie en technische infrastructuur ingebed kan worden. Er zijn nogal wat mogelijkheden om een FMIS te implementeren en er kan veel gewonnen, maar ook verloren worden bij de invoering van een systeem. Naast de technische implementatie 2007 – www.factomediabase.nl

3048

3048-2

Implementeren van een FMIS

van een systeem is het tevens belangrijk dat de gebruikers het systeem zullen accepteren en gebruiken. Hoe fantastisch en prachtig het zojuist verkregen FMIS ook mag zijn; als het niet gebruikt wordt door de beoogde gebruikers verliest het al zijn waarde. In hoofdstuk 2 wordt behandeld welke voorbereiding aan een implementatie voorafgaat. Er wordt ingegaan op de werkwijze tijdens een implementatie en vooral hoe de implementatie beheersbaar gehouden kan worden. In hoofdstuk 3 worden de feitelijke activiteiten van de implementatie besproken. ‘Hoe dient er getest te worden?’, ‘Hoe kan de voorlichting en opleiding van de gebruikers het beste plaatsvinden?’, ‘Hoe kan gegevensconversie aangepakt worden?' en 'Hoe kan de implementatie zelf aangepakt worden?’ zijn vragen die onder andere in dit hoofdstuk aan de orde komen. Tot slot wordt in hoofdstuk 4 een aantal technieken beschreven die bij de implementatie van een FMIS van pas kunnen komen. 2. Voorbereiding op implementatie Direct nadat een FMIS is aangeschaft, kan worden begonnen met het treffen van de voorbereidingen op de implementatie. Er moeten afspraken worden gemaakt over de te volgen werkwijze en hoe de implementatie beheersbaar kan blijven. In dit hoofdstuk wordt ingegaan op enkele voorbereidende activiteiten die aan deze beheersbaarheid zoveel mogelijk tegemoet komen. 2.1 Implementatie als project Het implementeren van een FMIS is geen eenvoudige zaak. Om tot een succesvolle implementatie te komen, zijn mensen met verschillende kennis en vaardigheden nodig die (vaak gelijktijdig) bezig zijn met een onderdeel van de implementatie. Zo zullen de gebruikers opgeleid worden, terwijl gelijktijdig andere mensen bezig zijn met het installeren van benodigde apparatuur en het treffen van ruimtelijke voorzieningen en weer ergens anders zijn mensen bezig met het converteren van de gegevens. Welke disciplines bij een implementatie betrokken kunnen zijn, wordt in latere hoofdstukken besproken. Voor de implementatie van een FMIS zal een aantal vertegenwoordigers met verschillende achtergronden gedurende een bepaalde periode met elkaar moeten samenwerken aan een vooraf gespecificeerd doel (een goed functionerend FMIS). De beste methode om 2007 – www.factomediabase.nl

3048


3048-3

situaties met dergelijke kenmerken beheersbaar en bestuurbaar te kunnen laten verlopen is om het projectmatig aan te pakken. 2.1.1 Projectorganisatie Een projectmatige aanpak vereist een projectorganisatie. Een projectorganisatie is niets anders dan een verzameling duidelijke afspraken over de werkverdeling, taken, verantwoordelijkheden, bevoegdheden en middelen. Met name afspraken over de verantwoordelijkheden verdienen speciale aandacht; men kan iemand wel ergens verantwoordelijk voor stellen, maar als dat niet gepaard gaat met voldoende bevoegdheden en middelen om de toegewezen verantwoordelijkheden te kunnen waarmaken, leidt dit onherroepelijk tot onacceptabele situaties. Zo zal een vrachtwagenchauffeur die verantwoordelijk is voor het transport van een lading van A naar B, maar niet beschikt over een rijbewijs (bevoegdheden) en brandstof (middelen), zijn verantwoordelijkheden moeilijk waarmaken. Cruciaal voor het welslagen van een project is een goede communicatie. Juist daar waar verschillende disciplines (mensen met verschillende kennis en ervaringsachtergronden) samenwerken in een complexe omgeving, zijn goede afspraken over overlegvormen en de wijze van voortgangsrapportage noodzakelijk. Het is zowel mogelijk om met alle projectmedewerkers op reguliere basis bijeen te komen om de voortgang te bespreken, als om alleen bij elkaar te komen als de situatie daarom vraagt. Door een regulier overleg zullen de projectmedewerkers elkaar makkelijker kunnen controleren en doordat alle medewerkers op de hoogte blijven van de ontwikkelingen elders kunnen eventuele knelpunten direct herkend worden. Hierdoor wordt de voortgang van het project beter gewaarborgd. Aan de andere kant hebben reguliere overleggen nog wel eens de neiging om zinloos tijd te consumeren van zowel de interne als de externe projectmedewerkers, omdat er ook bijeengekomen wordt als er mogelijk niets te bepreken valt. Een combinatie van andere vormen van communicatietechnieken om de medewerkers van de voortgang op de hoogte te houden en zelf van de voortgang van de taken van de projectmedewerkers op de hoogte te blijven en overleg uitsluitend indien de situatie daarom vraagt, kan hier een oplossing voor bieden. Hierbij kan gedacht worden aan nieuwsbrieven, informatieve sites, presentaties van mijlpaalproducten en dergelijke. 2.1.2 Organisatiestructuur Een projectorganisatie wordt meestal volgens het ‘linking-pin-principe’ gestructureerd. Dit houdt in dat een projectgroep is opgedeeld in meerdere werkgroepen die ieder een specifieke deskundigheid 2007 – www.factomediabase.nl

3048

3048-4


inbrengen. Meestal neemt de voorzitter van de werkgroep zitting in de projectgroep en legt verantwoording af over de activiteiten en voortgang aan de projectgroep. De voorzitter van de projectgroep is op zijn of haar beurt verantwoording verschuldigd aan een groter geheel: de stuurgroep. De stuurgroep heeft vaak een meer permanent karakter, is uitsluitend op strategisch niveau verantwoordelijk en beslist niet op inhoudelijk vlak. In figuur 1 is het linking-pinprincipe tussen de stuurgroep, projectgroep en werkgroep weergegeven.

Stuurgroep

Projectgroep

Werkgroep

Werkgroep

Projectgroep

Werkgroep

Figuur 1. Linking-pin-principe.

Het afbakenen van de verantwoordelijkheden en het toekennen van de bijbehorende bevoegdheden aan de verschillende onderdelen van de projectorganisatie, zijn hierbij van het allergrootste belang. Veel projecten lopen uit op een mislukking doordat de projectgroep onvoldoende bevoegdheden heeft en de stuurgroep zich teveel met details bemoeit op inhoudelijk niveau. Een mogelijke projectorganisatie wordt in het volgende voorbeeld beschreven: Stuurgroep FMIS De stuurgroep bestaat uit het managementteam van de facilitaire organisatie. (Meestal is dit een groep functionarissen die reeds op grond van andere projecten en processen op reguliere basis bijeenkomt). De stuurgroep beoordeelt en stuurt de projectgroep en neemt besluiten over de aanwending van de middelen en inzet van de mensen. De leden van de stuurgroep ontvangen iedere maand een voortgangsrapportage van de projectleider waarin de stand van het project en de toekomstprognose worden toegelicht. De stuurgroep 2007 – www.factomediabase.nl

3048


3048-5

komt bijeen indien zij dit op grond van de voortgang van het project nodig acht of op verzoek van de projectgroep wanneer deze hiervoor een dringende reden heeft. De projectgroep bestaat uit sleutelfiguren binnen de organisatie die een goede vertegenwoordiging vormen van de uiteindelijke gebruikers, aangevuld met (externe) deskundigen (bijvoorbeeld iemand van de automatiseringsafdeling of een vertegenwoordiger van de leverancier). De projectgroep is verantwoordelijk voor de implementatie van het systeem. Zij beslist onder meer over de inhoudelijke inrichting van het systeem en de procedures en werkwijzen zoals deze door de implementatiewerkgroepen worden voorgesteld. De projectgroep komt iedere twee weken bij elkaar. Implementatiewerkgroepen De implementatiewerkgroepen zijn verantwoordelijk voor de operationele invoering van de diverse systeemonderdelen. Per module is er een implementatiewerkgroep. In iedere implementatiewerkgroep heeft de projectleider zitting. Per functiegebied wordt een implementatiewerkgroep indien nodig aangevuld met een of meer functioneel betrokkenen uit de projectgroep. Incidenteel zal een van de overige gebruikers bij de implementatie worden betrokken. De implementatiewerkgroep bereidt de projectgroepvergaderingen voor door het maken van procedure- en inrichtingsvoorstellen. Tevens richt zij de modules in en is zij verantwoordelijk voor de gegevensinvoer, conversies en implementatie van de procedures. Overige projectorganisatie De projectleiding van FMIS valt onder de verantwoordelijkheid van het hoofd van de facilitaire organisatie en is wat de implementatie betreft gedelegeerd aan de projectleider FMIS. Binnen de organisatie wordt een applicatiebeheerder aangesteld die kennis heeft van het systeem en de procedures en intermediair is tussen de gebruikers en technisch beheer en na de implementatie ook tussen de gebruikers en de leverancier. Na implementatie zal de functie van applicatiebeheerder moeten worden gecontinueerd. Ook voor het technisch beheer zal iemand moeten worden aangesteld. Doorgaans wordt dit ondergebracht bij de automatiseringsafdeling. 2007 – www.factomediabase.nl

3048

3048-6


Het operationeel beheer (het daadwerkelijk invoeren van de gewijzigde gegevens) ligt bij de verschillende gebruikers. Binnen de tijdens de implementatie vast te stellen procedures zal duidelijk worden wie voor welke gegevensverzameling verantwoordelijk is en bevoegdheden krijgt. 2.2 Projectbeheersing De belangrijkste voorwaarde voor een succesvol project is een heldere en eenduidige doelstelling. Indien u niet exact weet wat het doel is (of anders gezegd: indien u niet weet welke richting u uit moet gaan) dan heeft het weinig zin te sturen en zal het project zeker niet beheersbaar zijn. Deze doelstelling dient te worden uitgedrukt in zogenaamde stuuraspecten: de aspecten waarop de voortgang van een project wordt beoordeeld. Deze stuuraspecten zijn doorgaans: – Geld. – Organisatie. – Tijd. – Informatie. – Kwaliteit. Deze worden ook wel afgekort als GOTIK. Om het aldus geformuleerde doel beheerst te kunnen nastreven, is het van belang dat er een Plan van Aanpak wordt opgesteld. Voor kleinere projecten - het implementeren van een FMIS is een relatief klein project, ook al is het een zeer ingrijpende zaak. Voor de meeste facilitaire organisaties zijn eigenlijk alleen de eerste drie aspecten van GOTIK van belang. Deze beheersaspecten hangen nauw met elkaar samen en er bestaat een onderling spanningsveld: als op de kosten bespaard gaat worden, zal dit vrijwel altijd gevolgen hebben voor de kwaliteit en doorlooptijd. Er zijn technieken die gebruikt kunnen worden bij het beheersen van projecten. Verderop in dit artikel wordt kort toegelicht hoe op eenvoudige wijze een netwerkplanning van de verschillende projectactiviteiten opgesteld kan worden en hoe daarmee de voortgang en afhankelijkheden van de activiteiten gevolgd kan worden. 2.2.1 Planning (Plan van aanpak) Het belangrijkste instrument voor het beheerst en projectmatig implementeren van een FMIS, is het Plan van Aanpak (PvA), waarin de doelstelling en de verschillende subactiviteiten worden beschreven en een integrale planning wordt afgeleverd. Een goed 2007 – www.factomediabase.nl

3048


3048-7

PvA vormt de basis voor een succesvolle implementatie van het FMIS. Het PvA bevat een stap voor stap beschrijving van de activiteiten die worden uitgevoerd. Een integrale planning zal zorg moeten dragen voor een gedegen voortgang die uiteindelijk resulteert in een op tijd geïmplementeerd systeem. Daarnaast zal ook het financiële plaatje ingevuld moeten worden. Uiteraard bevat het PvA een aantal algemene zaken, zoals het vaststellen van de feitelijke implementatiedatum, het inventariseren van eventuele uitwijkmogelijkheden en of er bijvoorbeeld tijdelijk extra apparatuur en personeel vereist is. Bij het vaststellen van de implementatiedatum dient rekening gehouden te worden met de levertijden van de leverancier en het verdient aanbeveling om deze afspraken formeel vast te leggen. Daarnaast zullen de specifieke implementatieactiviteiten geïnventariseerd moeten worden om een realistische en volledige planning op te kunnen leveren. Om een idee te geven welke activiteiten bij een implementatie ter sprake komen, kan de volgende checklist als handvat dienen: – planning opstellen; – organisatorische wijzigingen inventariseren; – procedures en formulieren vaststellen en beschrijven; – parameters en autorisaties instellen; – gegevensconversie of -collectie vaststellen; – infrastructuur en werkomgeving inrichten; – de feitelijke implementatie uitvoeren; – opleiding en voorlichting geven; – acceptatietest uitvoeren; – documentatie en naslagwerken waarborgen; – het beheer na de implementatie beleggen. De hierboven genoemde punten worden in het volgende hoofdstuk nader toegelicht. Voor het opstellen van het PvA is het op dit moment slechts van belang vast te stellen welke activiteiten wanneer en door wie uitgevoerd gaan worden en welke afhankelijkheden tussen de verschillende activiteiten spelen. Door de activiteiten vervolgens in een netwerkplanning op te nemen, ontstaat een instrument waarmee de voortgang van het implementatieproject gevolgd kan worden. In de paragraaf 4.3 wordt toegelicht hoe een netwerkplanning opgesteld kan worden en hoe hierin het kritische pad kan worden gevonden.

2007 – www.factomediabase.nl

3048

3048-8


Praktisch gesproken zijn de meeste integrale FMIS'en uit verschillende onderdelen (modules) opgebouwd. Het door u in te voeren FMIS zou bijvoorbeeld kunnen bestaan uit de volgende modules: 1. basismodule; 2. ruimtebeheer; 3. meerjarenonderhoudsplanning; 4. tekeningenbeheer; 5. werkorders; 6. inventarisbeheer; 7. meldpunt; 8. budgetbeheer. Het is verstandig de modules niet allemaal tegelijkertijd in te voeren, maar in een bepaalde volgorde op basis van prioriteiten. Tevens kan er afhankelijk van de omvang van de organisatie voor worden gekozen om niet alle gegevens tegelijk in te voeren maar bijvoorbeeld per object. Vervolgens kan per module worden aangegeven welke stappen doorlopen zullen worden. In het onderstaande voorbeeld zijn de stappen die per module zullen worden genomen, afgeleid uit bovenstaande checklist van activiteiten en de voorbeeldprojectstructuur uit de vorige paragraaf. Voorstel maken De betreffende implementatiewerkgroep maakt een voorstel voor: 1. de procedure rondom het systeem (de module); 2. de inrichting van het systeem (veldnamen en groeps- en rubriekindelingen); 3. uitdraaien en overzichten; 4. autorisaties. Vaststellen inrichting De voorstellen worden door de projectgroep in de periodieke vergaderingen doorgenomen, aangevuld en vastgesteld. Inrichten systeem De implementatiewerkgroepen richten het systeem volgens de overeengekomen specificaties in. Verzamelen, invoeren en/of converteren gegevens De bij de module behorende gegevens worden ingevoerd. Gebruikerscursus De eindgebruikers gaan naar een cursus waar zij een opleiding krijgen over de voor hen relevante modules op de voor hen ingerichte 2007 – www.factomediabase.nl

3048


3048-9

database. Deze cursussen kunnen deels door de leden van de implementatiewerkgroep worden gegeven en deels door de cursusafdeling van de leverancier. Ingebruikname De module wordt daadwerkelijk in gebruik genomen. Gedurende de eerste dagen krijgen de gebruikers hierbij extra ondersteuning van de medewerkers van de implementatiewerkgroep. 2.2.2 Budget(bewaking) regelen Een belangrijk onderdeel van het opstellen van het Plan van Aanpak is het budgetteren van het project, zodat alle activiteiten binnen het project financieel gedekt zijn. Vaak blijkt dit een moeilijk proces te zijn, waarbij vrijwel altijd een aantal onvoorziene omstandigheden over het hoofd wordt gezien. Naast het overschrijden van de geplande implementatiedatum, blijken de kosten maar al te vaak hoger dan in eerste instantie gebudgetteerd. Om enigszins grip te krijgen en te houden op de kosten, kan op vaste tijdstippen de projectvoortgang besproken worden, waarmee gedeeltelijk voorkomen wordt dat problemen op het gebied van tijd en geld te laat worden gesignaleerd. 2.2.3 Kwaliteit Het aspect kwaliteit leeft vaak een zwevend bestaan dat te pas en te onpas aandacht krijgt. De vraag kan gesteld worden hoe de kwaliteit van een resultaat gemeten kan worden. De meest zinvolle manier voor het vaststellen en toetsen van kwaliteit, vindt plaats door het vooraf vaststellen van duidelijk gespecificeerde eisen en normen waaraan het systeem getoetst kan worden. Voldoet het resultaat aan deze eisen en normen, dan heeft het tevens kwaliteit. Het aspect kwaliteit wordt voorts besproken bij de activiteit ‘acceptatietest’ waarin de eisen en wensen die gebruikers stellen ter sprake komen. 3. Activiteiten tijdens de implementatie In dit hoofdstuk worden de activiteiten benoemd die tijdens de implementatie worden uitgevoerd. Zo zal de organisatie voorbereid moeten worden op de komst van het nieuwe FMIS en zullen verschillende parameters van het FMIS ingesteld moeten worden. Voorts zullen procedures vastgelegd moeten worden, moeten bestaande gegevens geconverteerd worden en zullen de gebruikers van het systeem een opleiding krijgen. 2007 – www.factomediabase.nl

3048

3048-10


3.1 Organisatorische wijzigingen inventariseren Het kan zijn dat de invoering van het FMIS ook tot organisatorische wijzigingen leidt. Meestal is dat niet in de zin van veranderende of nieuwe afdelingen en hun onderlinge samenhang, maar meer de organisatie van het werk zelf. 3.1.1 Procedures vaststellen en beschrijven Procedures zijn regels voor die functies die wel onderdeel van het FMIS zijn, maar niet zijn geautomatiseerd, bijvoorbeeld het bestellen van artikelen bij een leverancier. Vanzelfsprekend is er een nauwe relatie tussen het opstellen van de procedures en het specificeren van de gebruikershandleiding en formulieren. Bij het opstellen van de procedurebeschrijving dient gelet te worden op onder andere de volgende punten: – Welke gebeurtenis triggert de procedure? – Welke handelingen moeten in welke volgorde uitgevoerd worden? – Welke condities zijn van toepassing op het uitvoeren van de handelingen? – Welke informatie is vereist voor het kunnen uitvoeren van de procedure? – Hoe moeten fouten worden afgehandeld? – Wie voert de handelingen uit? – Hoe lang duren de handelingen? – Wie is verantwoordelijk voor de handeling? – Welke bevoegdheden worden verstrekt? Verderop in dit artikel wordt toegelicht hoe een procedure op heldere, schematische wijze kan worden vastgelegd. 3.1.2 Formulieren vaststellen en ontwerpen Formulieren ondersteunen procedures door heel gericht en volgens standaardwijze informatie te verzamelen die van belang is voor de verwerking binnen het FMIS.


3048


3048-11

Het volgende voorbeeld verduidelijkt wat hier bedoeld wordt: Een van de eerste moeilijkheden waar men bij de implementatie van een FMIS tegenaan loopt, is het actueel houden van het klantenbestand (al die personen die door de facilitaire organisatie worden bediend) binnen het FMIS. Aansluiting op het personeelsbestand van P&O is vaak om redenen van privacy niet mogelijk en bovendien loopt dit bestand vaak achter en is onvolledig daar bijvoorbeeld alle externen die binnen de organisatie werkzaam zijn (vaak wel 30% van het totale medewerkersbestand) hier niet in voorkomen. Mutaties, zoals de komst van nieuwe medewerkers of het vertrek van medewerkers, worden vaak pas zeer laat of helemaal niet aan de facilitaire organisatie doorgegeven. Om de gegevens binnen het FMIS actueel te houden, kan hiervoor een procedure worden ontwikkeld. Deze procedure kan gebruikmaken van een formulier dat bij de diverse afdelingen op de secretariaten ligt. Op deze formulieren kan men de gegevens van een nieuwe medewerker of van een vertrekkende medewerker opgeven en aangeven welke faciliteiten en voorzieningen voor de nieuwe medewerker geregeld moeten worden door de facilitaire organisatie. Men dient aan de afdelingen duidelijk te maken dat indien dit formulier niet tijdig (bijvoorbeeld twee weken tevoren) is ingeleverd, er niet tijdig voor een werkplek kan worden gezorgd. Het werkt erg goed om een dergelijke procedure te combineren met de afdeling automatisering, voor de computeraansluiting en dergelijke. 3.2 Parameters en autorisaties instellen Alle standaard FMIS-systemen hebben een generieke opzet. Dat betekent dat ze over het algemeen redelijk, maar nooit helemaal perfect bij een organisatie aansluiten. Om een FMIS beter op de organisatie (maar ook op de infrastructuur) af te stemmen, kunnen diverse parameters aangepast worden. Voorts kent vrijwel ieder FMIS een autorisatiemodule om ervoor te zorgen dat bepaalde gegevens alleen toegankelijk zijn voor daartoe bevoegde medewerkers. 3.2.1 Systeemparameters instellen Sommige systemen kunnen voor een groot deel zelf worden ingericht; andere betreffen een volledig uitgewerkt concept. In het eerste geval zullen veel parameters moeten worden ingesteld. Vaak kan men de veldnamen zelf aanpassen, velden aan- of uitzetten, scherm2007 – www.factomediabase.nl

3048

3048-12


lay-outs wijzigen, (periodieke) rapportages definiëren en vastleggen, relaties tussen bepaalde gegevens aanbrengen, enz. Het instellen van de parameters zelf is geen ingewikkelde zaak. Het is veel moeilijker om alle mogelijkheden van het systeem te doorgronden en de keuzes te maken die het best bij de gegeven situatie passen. Enkele leveranciers hebben hiermee in het verleden met hun systeem reeds veel ervaring opgedaan en hebben deze ervaringen gebundeld in standaard beslismodellen die de gebruiker goed kunnen helpen bij het maken van de juiste keuzes. 3.2.2 Autorisaties instellen Om te voorkomen dat gegevens door niet-gerechtigde medewerkers worden geraadpleegd of – erger – worden gewijzigd, heeft vrijwel elk FMIS de mogelijkheid om de toegang tot functies en gegevens per gebruiker of gebruikersgroep aan banden te leggen. Als eerste moet een systeembeheerder aangewezen worden die zelf een ‘supervisor’-toegang tot het FMIS heeft en gebruikers kan toevoegen, wijzigen en verwijderen. Voordat het systeem geïmplementeerd wordt, dient een matrix opgesteld te worden waarin de rechten van de gebruikers(groep) zijn opgenomen. Deze rechten hebben betrekking op het creëren, lezen, muteren en verwijderen van gegevens. Men kan op de verticale as de gegevens of functies opnemen en op de horizontale de gebruikers(groepen) uitzetten. Op de kruispunten van de betreffende combinatie kan dan een C (creatie), L (lezen), M (mutatie) of een V (verwijderen) geplaatst worden. De gebruikers kunnen vervolgens met een ‘loginnaam’ en een ‘password’ aangeven wie zij zijn en tot welke functies en gegevens zij toegang hebben. 3.3 Gegevens converteren of verzamelen Een FMIS kan nog zo mooi ontworpen zijn, het draait uiteindelijk allemaal om de gegevens die het systeem opslaat, bewerkt en combineert. In veel gevallen zal een organisatie reeds over elektronische facilitaire gegevens beschikken, zij het in een ander (mogelijk zelfs onbruikbaar) formaat vanuit een voorgaand systeem. Dit kan variëren van tekstbestanden en spreadsheets tot complete databases. Indien deze gegevens actueel zijn, is het verstandig om deze gegevens om te zetten (te converteren) naar een formaat dat door het nieuwe FMIS kan worden verwerkt. Vaak zijn er mogelijkheden om de beschikbare gegevens met behulp van conversieprogramma’s om te zetten naar een bruikbaar formaat. Soms kan dat in eigen beheer worden gedaan, maar zeker bij gecompliceerdere conversies ver2007 – www.factomediabase.nl

3048


3048-13

dient het aanbeveling de kennis en kunde van een deskundige in te roepen. Vanuit de leverancier wordt deze ondersteuning vaak geboden en het is niet onverstandig hier gebruik van te maken. Verkeerd geconverteerde gegevens kunnen rampzalige gevolgen hebben. Daarom is het essentieel om secuur te werk te gaan bij de conversie van gegevens. In sommige gevallen kan het nodig zijn om tijdelijk extra personeel, apparatuur en programmatuur in te zetten. De planning en de wijze van de conversie worden grotendeels bepaald door de implementatiewijze (bijvoorbeeld gefaseerd of schaduwdraaien), maar zullen voltooid moeten zijn voordat het systeem operationeel is. Aandachtspunten bij de conversie van gegevens zijn de volgende: – Wat vormt de unieke identificatie en komt deze overeen voor de oude en nieuwe situatie? – Zijn de gegevens verspreid of centraal opgeslagen? – Op welk medium zijn de gegevens opgeslagen? – Wat is de opslagstructuur (recordindeling, bestandsorganisatie)? – Zijn er karakters die niet geconverteerd kunnen worden? – Wat is de kwaliteit van de te converteren gegevens? Het kan ook zijn dat een organisatie nog niet over elektronische gegevens beschikt, maar slechts over een papieren archief. In dat geval zal een plan opgesteld moeten worden hoe en waar deze gegevens vandaan gehaald moeten worden. De gegevens zullen dan handmatig ingevoerd moeten worden, waarbij fouten niet ondenkbaar zijn. Om de kans op invoerfouten te reduceren, kunnen gegevens dubbel ingevoerd worden. Na de handmatige invoer kunnen de gegevens met elkaar vergeleken worden, waarbij er over het algemeen vanuit gegaan mag worden dat alleen de verschillen tussen de twee bestanden op invoerfouten duiden. Uit deze twee invoerbestanden kan vervolgens het definitieve invoerbestand samengesteld worden, waarbij de kans op invoerfouten minimaal is. Het is van belang zich te realiseren dat het verzamelen en converteren van gegevens een van de grootste kostenposten binnen een implementatietraject is. Het is juist hierom van belang een goede inventarisatie te maken en vooraf aandacht te besteden aan een conversieplan.


3048

3048-14


3.4 Infrastructuur en werkomgeving inrichten De implementatie van het FMIS kan concrete eisen stellen aan de technische infrastructuur en werkomgeving. Deze aanpassingen dienen voor de feitelijke implementatie afgerond te zijn, opdat het systeem getest en na implementatie direct operationeel kan zijn. Vergeet niet dat de gekozen wijze van implementatie ook invloed heeft op deze activiteit. Als er bijvoorbeeld parallel wordt geïmplementeerd (zie par. 3.5), dan zullen zowel de oude als de nieuwe infrastructuur en werkomgevingselementen gelijktijdig gebruikt worden, hetgeen tijdelijk extra middelen vereist. Bedenk welke nieuwe infrastructuur vereist is voor het implementeren en gebruiken van het nieuwe FMIS. Het verdient aanbeveling om deze inventarisatie tezamen met de leverancier uit te voeren. Denk aan onder andere de volgende items: – pc’s; – printers; – datacommunicatielijnen; – servers; – modems; – programmatuur; – documentatie; – bureaus; – stoelen; – meubilair; – enz. De meeste FMIS'en draaien tegenwoordig wel op de gewone kantoorautomatisering infrastructuur, zodat het steeds minder noodzakelijk wordt om aanpassingen te maken. De aanpassingen beperken zich meestal tot een extra server of werkstation, hetgeen tegenwoordig eenvoudig en tegen beperkte kosten te regelen is. 3.5 De feitelijke implementatie uitvoeren Nadat alle randvoorwaarden voor de implementatie zijn geschapen, kan de feitelijke implementatie van het systeem plaatsvinden. Indien de mogelijkheid bestaat om een proefimplementatie in een proeftuin uit te voeren, wordt dit ten zeerste aangeraden. Een proefimplementatie kan al in een vroeg stadium aantonen waar problemen te verwachten zijn en men kan op die manier adequate maatregelen treffen. Daarnaast verdient het aanbeveling om een ‘terugvalscenario’ vast te stellen, zodat bij onverwachte problemen 2007 – www.factomediabase.nl

3048


3048-15

zonder veel problemen naar de oude situatie teruggekeerd kan worden. Bij de implementatie van een FMIS (en feitelijk bij alle systemen) zijn er grofweg de volgende methoden: – implementatie ineens (Big-Bang-Scenario); – gefaseerde implementatie; – parallelle implementatie (schaduwdraaien). Alle varianten hebben hun voor- en nadelen. Voor welke methode gekozen dient te worden, hangt met name sterk af van de organisatie en de complexiteit van het systeem. Huidige Situatie

Nieuwe Situatie

Figuur 2. Implementatie ineens.

3.5.1 Implementatie ineens Bij een implementatie ineens wordt het FMIS in één keer op een van te voren vastgesteld tijdstip geïmplementeerd. Dit heeft als voordeel dat – als het goed gaat – de organisatie direct beschikt over een volledig operationeel systeem. Bovendien is dit veruit de goedkoopste oplossing – zeker op korte termijn – voor het implementeren van een FMIS. De praktijk leert dat een implementatie ineens niet altijd succesvol verloopt en men beter voor een andere (beter beheersbare) methode had kunnen kiezen. Naast kans op mislukking heeft een implementatie ineens ook vaak een schokeffect in de organisatie aangezien er geen periode voor gewenning heeft plaatsgevonden. De gebruikers van het systeem worden van het ene op het andere moment geconfronteerd met een nieuw systeem en spenderen de eerste tijd met het vertrouwd raken met het systeem. Natuurlijk hoeft niet iedere implementatie ineens van een FMIS uit te draaien op een mislukking. Enkele overwegingen bij een implementatie ineens: – Het betreft een relatief eenvoudig FMIS, waarbij slechts een kleine hoeveelheid gegevens geconverteerd hoeft te worden. – Het betreft een geïntegreerd systeem dat moeilijk of niet in fasen geïmplementeerd kan worden. – Als parallelverwerking moeilijk of niet mogelijk is.


3048

3048-16 – –


Er dient een goed alternatief (terugvalmogelijkheid) te zijn voor het geval de implementatie niet verloopt zoals gewenst. Als er vanuit het management grote druk wordt uitgeoefend om het systeem zo snel mogelijk te implementeren. Huidige Situatie

Fase 1

Fase 2

Fase n

Nieuwe Situatie

Figuur 3. Gefaseerde implementatie.

3.5.2 Gefaseerde implementatie Bij deze methode wordt het FMIS geleidelijk geïmplementeerd. In praktijk betekent dit dat een systeem per subsysteem wordt ingevoerd en dat een gedeelte van de gegevensverwerking nog door het oude systeem wordt uitgevoerd. Het voordeel van deze aanpak schuilt in het feit dat de implementatie beheerst plaatsvindt. Mocht een geïmplementeerd subsysteem niet aan de gestelde eisen voldoen, dan kan vaak op eenvoudige wijze de implementatie ongedaan gemaakt worden. Bovendien kan een geleidelijke implementatie van een FMIS de acceptatie bij de gebruikers van het FMIS gunstig beïnvloeden. Het belangrijkste nadeel van een gefaseerde implementatie is dat er een nauwkeurige en vaak ingewikkelde planning vereist is – per subsysteem kan immers weer de keuze gemaakt worden voor een implementatie ineens en voor parallelle implementatie. Daarnaast ben je bij gefaseerde implementatie vaak gebonden aan een bepaalde volgorde, aangezien het anders voor gebruikers van het FMIS niet acceptabel is. Enkele overwegingen bij een gefaseerde implementatie van een FMIS: – Indien het ontwerp van het FMIS zich bij uitstek leent voor een gefaseerde implementatie, kan hier dankbaar gebruik van gemaakt worden. – Wanneer er hoge eisen aan de betrouwbaarheid van het FMIS worden gesteld.


3048


– –

3048-17

Het betreft een complex FMIS dat moeilijk ineens geïmplementeerd kan worden. Er zijn duidelijke koppelingen (interfaces) tussen het oude en het nieuwe systeem die gedurende de gefaseerde implementatie met elkaar kunnen samenwerken. Huidige Situatie

Nieuwe Situatie Figuur 4. Parallelle implementatie

3.5.3 Parallelle implementatie Bij deze wijze van implementatie vindt de verwerking van gegevens gedurende een bepaalde periode door zowel het oude als het nieuwe FMIS plaats. Pas nadat aan een aantal vooraf opgestelde criteria is voldaan, vindt volledige ingebruikname van het nieuwe FMIS en opdoeking van het oude systeem plaats. Het mag duidelijk zijn dat deze wijze van implementeren leidt tot een minimale risico’s. Bij het schaduwdraaien is het gebruikelijk dat het nieuwe systeem in principe als volledig operationeel wordt beschouwd en dat het oude systeem slechts als terugvalmogelijkheid dient, wanneer het nieuwe systeem (nog) niet voldoet. Gedurende de schaduwperiode is optimale gelegenheid om het nieuwe systeem onder actuele condities te toetsen en kan de uitvoer van het oude en het nieuwe systeem naast elkaar gelegd worden om correcte verwerking van gegevens te verifiëren. Bovendien hebben de gebruikers de tijd om volledig vertrouwd te raken met het nieuwe systeem. Aan de negatieve kant van de streep staan uiteraard de hoge kosten van het parallel verwerken: gedurende een bepaalde periode worden twee systemen operationeel gehouden, hetgeen tot hogere systeemen personeelskosten leidt. In sommige gevallen kan schaduwdraaien ook tot moeilijk beheersbare situaties leiden: welk systeem en welke gegevens zijn nu de werkelijke gegevens en lopen de deze twee gegevensverzamelingen niet door elkaar? Voorts kunnen het oude en nieuwe systeem twee totaal verschillende organisatiestructuren ondersteunen, waardoor het praktisch niet mogelijk is om de parallel te implementeren.


3048

3048-18


Enkele overwegingen bij parallelle implementatie van een FMIS: – De uitvoer van het oude systeem wordt voornamelijk gebruikt voor de verificatie van de uitvoer van het nieuwe systeem, terwijl het nieuwe systeem primair voor de verwerking van de actuele gegevens wordt gebruikt. – Schaduwdraaien leent zich uitstekend wanneer het nieuwe systeem vooral een uitbreiding van een bestaand systeem is, waarbij het oude systeem grotendeels als een subsysteem van het nieuwe is, waarbij vrijwel geen sprake is van gegevensduplicatie. 3.6 Opleiding en voorlichting verzorgen Een van de belangrijkste aspecten bij het implementeren van een FMIS is het voorlichten van de organisatie en het opleiden van toekomstige gebruikers. Een FMIS is pas werkelijk functioneel wanneer het daadwerkelijk gebruikt wordt. Acceptatie door de gebruikers is daarmee een kritische succesfactor. Voorlichting en opleiding zijn zodoende twee middelen om een FMIS succesvol te implementeren. 3.6.1 Voorlichting De praktijk leert dat gedurende de eerste fasen van de implementatie er nogal eens wat weerstand te bespeuren is. Deze weerstand is gedeeltelijk gebaseerd op rationele factoren (verlies van functies of werkzaamheden), maar ook op irrationele gronden als gevolg van onwetendheid over het systeem en de mogelijk veranderende organisatie. Het verdient daarom aanbeveling om de gebruikers tijdig op de hoogte te brengen van achtergronden van het systeem en de gevolgen voor de werkzaamheden. Zo zal de weerstand bij aanvang aanzienlijk verminderd worden en kan het systeem zonder veel weerstand geïmplementeerd worden. Geef zo veel mogelijk antwoord op logische en voor de hand liggende vragen als het waarom van het nieuwe systeem, de verwachte voor- en nadelen, de consequenties voor het personeel, een globale beschrijving van het systeem, enzovoort. De voorlichting zal op alle niveaus binnen de organisatie plaats moeten vinden. Vertel ook welke aanpak bij de implementatie wordt gekozen en hoe de medewerkers op de hoogte worden gehouden.


3048


3048-19

Daarnaast is het belangrijk om zich te realiseren dat elke verandering onderhevig is aan het groeifasemodel van Nolan. Dit komt er op neer dat mensen en organisaties veranderingen in vier stappen ondergaan: 1 Aanvangsfase

4 Integratiefase

2 Verspreidingsfase

3 Beheersfase

Figuur 5. Groeifasemodel van Nolan.

Nolan stelt dat personen, maar ook de organisatie waarin mensen werkzaam zijn, een proces doorlopen van gewenning. Men kan niet in één stap van A naar F overgaan, maar zal ook de fasen B, C, D en E moeten doorlopen. Dat begint met een kennismaking- of aanvangsfase, waarin kennisgenomen wordt van een verandering of nieuw fenomeen. Daarna wordt men tijdens de verspreidingsfase geconfronteerd met de verandering. Vervolgens krijgt men de verandering of nieuwe technologie onder de knie en leert de sterke en zwakke kanten kennen, waarna deze effectief benut kan worden door verspreiding binnen de organisatie in de integratiefase. Na iedere nieuwe verschuiving in de technologie begint de cirkel opnieuw en worden de stappen wederom doorlopen. Deze fasen gelden zowel bij primaire zaken als het leren fietsen, als bij het implementeren van een nieuw informatiesysteem in een organisatie. 3.6.2 Opleiding Naast de voorlichting over de implementatie zelf, is het van belang dat de gebruikers voldoende kennis krijgen van het efficiënt werken met het systeem zelf. Vaak kunnen kant-en-klare opleidingen bij de leverancier van het systeem gevolgd worden. Meestal valt de keuze op een klassikale opleiding die gecombineerd wordt met workshopachtige oefeningen waarin de zojuist behandelde stof in praktijk gebracht wordt. Een opleiding kan in veel gevallen twee kanten op 2007 – www.factomediabase.nl

3048

3048-20


werken: naast het opleiden van de toekomstige gebruikers, kan het namelijk ook duidelijk maken waar eventuele problemen bij de implementatie of het gebruik te verwachten zijn. Door dit tijdig te signaleren, kan daar tijdig een passende oplossing voor gevonden worden. Soms is het dan ook verstandig enkele gebruikers die actief bij de implementatie betrokken zullen worden bij aanvang van het implementatietraject een cursus te laten volgen. Behalve de gebruikers dient ook het personeel dat technisch en functioneel beheer gaat uitvoeren over voldoende kennis dient te beschikken. Ook zij kunnen vaak een kant-en-klare training bij de leverancier van het systeem volgen. 3.7 Acceptatietest uitvoeren Een acceptatietest heeft tot doel aan te tonen dat een systeem aan de gestelde eisen voldoet en dat het na implementatie zonder verstoringen operationeel kan zijn. Vaak zal de nadruk bij een acceptatietest op de functionaliteit liggen, hetgeen begrijpelijk is; doet het systeem waarvoor het is aangeschaft? Maar naast de functionaliteit zijn er legio andere aspecten die getest kunnen worden. Hieronder volgt een lijst met een aantal aspecten, maar de lijst is theoretisch ongelimiteerd en het belang per aspect kan per organisatie en systeem enorm verschillen: – gebruikersvriendelijkheid; – responsetijden; – beveiliging; – prestaties; – betrouwbaarheid; – documentatie; – integriteit; – herstelbaarheid; – integratiemogelijkheden met andere systemen. Een test moet altijd volgens een vooraf opgesteld plan afgewerkt worden. In dat testplan dient aangegeven te zijn op grond van welke criteria een systeem al dan niet geaccepteerd wordt. De gebruikelijke manier van werken bij acceptatietests is de volgende: 1. Stel een checklijst van meetbare acceptatiecriteria op. 2. Maak eenduidige tests die de acceptatiecriteria toetsen. 3. Voer de tests uit en rapporteer de bevindingen. 4. Corrigeer of pas het systeem aan naar aanleiding van de bevindingen.


3048


3048-21

5. Voer tests eventueel opnieuw uit om aangepaste en gecorrigeerde delen van het systeem te testen. 6. Accepteer het systeem formeel op basis van de acceptatiecriteria. De acceptatiecriteria moeten bij de test echt als een checklist fungeren die punt voor punt afgestreept kan worden. Zorg ervoor dat de test reproduceerbaar is, zodat dezelfde situatie na een wijziging nogmaals kan worden uitgevoerd. 3.8 Documentatie en naslagwerken waarborgen De laatste stap voordat tot de werkelijke implementatie kan plaatsvinden, is het op orde brengen van alle documentatie. Eigenlijk is dit geen aparte stap of activiteit bij de implementatie, maar een integraal onderdeel van de andere activiteiten. De onderstaande lijst geeft een idee van welke typen documentatie gecontroleerd en eventueel aangepast kunnen worden: – gebruikersdocumentatie; – systeemdocumentatie; – testdocumentatie; – handboek conventies. Vanzelfsprekend dient de gebruikershandleiding up-to-date te zijn en dienen alle onderdelen die in het FMIS geconfigureerd zijn in de gebruikershandleiding terug te vinden te zijn. Daarnaast verdient het aanbeveling om ook alle testresultaten en daaruit voortvloeiende wijzigingen of correcties te documenteren. Men moet niet dat vergeten wijzigingen in het systeem ook van invloed kunnen zijn op de gebruikershandleiding. In het handboek met conventies dienen alle afspraken over coderingen van gegevens binnen het systeem te worden beschreven. 3.9 Beheer na implementatie beleggen Nadat het systeem geïmplementeerd is, dient het overgedragen te worden aan de beheerder en deze moet daar uiteraard op voorbereid zijn. Dat betekent dat de systeembeheerder ook opgeleid moet zijn en moet weten wat zijn taak is. Daarnaast moet vastgelegd worden hoe er omgegaan wordt met de volgende zaken: – Wanneer en hoe worden back-ups gemaakt? – Hoe en door wie wordt het systeem geëxploiteerd? – Hoe wordt omgegaan met wijzigingsverzoeken?


3048

3048-22 – – –


Welke eisen gelden ten aanzien van de beschikbaarheid (tussen welke tijden moet het systeem zonder meer beschikbaar zijn)? Hoe wordt het systeem beveiligd (om de hoeveel tijd dienen passwords gewijzigd te worden? Is er nog voldoende opslagcapaciteit?

4. Technieken In dit hoofdstuk wordt kort een aantal technieken beschreven die gebruikt kunnen worden tijdens verschillende activiteiten bij de implementatie van een systeem. Het betreft technieken om procedures te beschrijven, relaties tussen gegevens weer te geven en het maken van een (netwerk)planning. 4.1 Procedure schema’s Om de opeenvolging van activiteiten en beslissingen binnen een procedure visueel te beschrijven, is een goed bruikbare techniek ontwikkeld. Hier onder wordt deze techniek kort toegelicht en gevolgd door een voorbeeld.

Activiteit

Dit symbool geeft een activiteit weer

Beslissing

Dit symbool geeft een beslissing of vraag weer

Dit symbool geeft een verwijzing naar een volgende activiteit

Figuur 6. De verschillende symbolen in de procedure.

Met behulp van de drie basissymbolen worden de activiteiten waaruit de procedure is opgebouwd, op logische wijze (op volgorde) met elkaar verbonden. Op verschillende punten zullen beslissingen genomen moeten worden die kunnen leiden tot twee of meer verschillende vervolgactiviteiten, die met het beslissingssymbool worden weergegeven. Een algemene afspraak is dat de verwijzingen van voorgaande activiteiten of beslissingen aan de bovenkant worden gekoppeld en ver-


3048


3048-23

wijzingen naar volgende activiteiten of beslissingen links, rechts of aan de onderkant worden gekoppeld. Voorts worden vaak de verwijzingen naar beneden en naar rechts zonder pijl getekend (omdat dat met de natuurlijke stroom van het lezen van informatie overeenkomt). Verwijzingen die naar boven en naar links lopen, worden dan wel met een pijltje aangegeven. Omwille van de duidelijkheid kan men ervoor kiezen om altijd pijlen in de verwijzingen op te nemen. Hierna volgt een voorbeeld van een procedurebeschrijving voor het verwerken van een gebruikersautorisatie (bijvoorbeeld voor het FMIS). In dit voorbeeld zijn de pijltjes naar rechts en naar beneden weggelaten.

Gebruikersgegevens invullen

Ondertekenen door manager

Nee

Correct ingevuld en getekend? Ja

Gebruikersklasse toekennen

Gebruiker aan het systeem toevoegen

Terugkoppeling aan gebruikers geven

Toegang tot systeem correct?

Ja

Nee Incorrecte toegang registreren

Autorisatieaanvraag archiveren

Figuur 7. De procedurebeschrijving in schema.


3048

3048-24


4.2 Entiteit Relatie Modellen Een veelgebruikte techniek voor het vastleggen van een gegevensstructuur is het Entiteit Relatie Model (ERD). Dit model geeft op eenvoudige en duidelijke wijze de relaties tussen gegevenselementen weer. De techniek wordt veel in de automatisering gebruikt en is eenvoudig te begrijpen. Binnen het ERD-model worden vier symbolen gebruikt:

Entiteit

Dit symbool geeft een entiteit of gegevenselement weer Dit symbool geeft een 1 op 1 relatie weer Dit symbool geeft een 1 op N relatie weer Dit symbool geeft een N op M relatie weer

Figuur 8. De gebruikte symbolen in het ERD-model.

Door de gegevenselementen door middel van relaties te koppelen, ontstaat een duidelijk overzicht van de structuur waarin de gegevens met elkaar samenhangen. Hieronder is een voorbeeld gegeven:

Gebouw

Ruimtegroep

Ruimte

Sleutel

Figuur 9. De schematische weergave van het ERD-model.

Uit het voorbeeld is het volgende op te maken: – Een gebouw bestaat uit een of meer ruimtes en een ruimte hoort slechts bij één gebouw. – Een ruimte heeft een of meer sleutels en een sleutel hoort slechts bij één ruimte. 2007 – www.factomediabase.nl

3048


–

3048-25

Een ruimte behoort tot één ruimtegroep en een ruimtegroep kan uit een of meer ruimtes bestaan.

4.3 Planning Nadat de activiteiten zijn vastgesteld die gedurende de implementatie uitgevoerd moeten worden, kunnen we de basis leggen voor een beheersmatige aanpak door een netwerkplanning op te stellen. Een planning wordt over het algemeen gedaan door het maken van een GANTT-chart (balkenplanning). Daarvoor dienen twee stappen te worden uitgevoerd: 1. Stel eerst een netwerkplanning op volgens de PERT-methode (Progress Evaluation Review Technique). Hiermee worden de onderlinge relaties en het kritische pad duidelijk. 2. Vervolgens wordt de netwerkplanning vertaald in een GANTTchart. De GANTT-chart geeft een helder overzicht van de geplande start- en eindtijden van activiteiten en is door de eenvoudige leesbaarheid en herkenbaarheid voor alle betrokkenen toegankelijk. 4.3.1 Netwerkplanning Hoe maken we een netwerkplanning? Hieronder wordt in zes stappen aangegeven hoe we een netwerkplanning maken: Stap 1 Inventariseer alle activiteiten die gedurende de implementatie uitgevoerd moeten worden. Stap 2 Stel per activiteit vast wat de doorlooptijd is. Doe dit, indien mogelijk, in samenspraak met de verantwoordelijke mensen van die activiteit.


3048

3048-26


Stap 3 Stel de onderlinge afhankelijkheden tussen de activiteiten vast. Het begin of eind van de activiteit is afhankelijk van een of meer activiteiten. De volgende relaties kunnen zich voordoen: Afkorting

Soort verband

Betekenis

FS

Finish to start

De activiteit begint wanneer zijn voorganger geëindigd is (wordt in praktijk het meeste gebruikt).

SS

Start to start

De activiteit begint wanneer zijn voorganger begonnen is.

FF

Finish to finish

De activiteit kan alleen beëindigd worden wanneer zijn voorganger is beëindigd.

SF

Start to finish

De activiteit kan alleen eindigen als zijn voorganger begonnen is (wordt in praktijk vrijwel niet gebruikt).

Stap 4 Maak en optimaliseer de netwerkplanning. Dit kan eenvoudig met een planningspakket zoals MS Project for Windows. Maar het kan uiteraard ook handmatig, bijvoorbeeld door middel van een brainstormsessie. Het is handig om hiervoor een whiteboard te gebruiken en post-it-blaadjes. Zet iedere activiteit op een post-it-blaadje en plak deze op het whiteboard. Geef vervolgens met een stift de relaties tussen de activiteiten aan. Op deze manier kunnen eenvoudige wijzigingen worden aangebracht om het netwerk te optimaliseren. Bij het optimaliseren van een netwerk kunnen de volgende vuistregels worden gehanteerd: – Ga uit van één start- en één eindmoment. – Werk van links naar rechts. – Zorg voor zo min mogelijk kruisende lijnen. – Voorkom dat er ‘doodlopende’ paden zijn die geen opvolger hebben. Alle activiteiten moeten een voorganger en een opvolger hebben, behalve de start- en eindactiviteit. Stap 5 Reken nu de planning door. Bepaal hiertoe: – De vroegste start- en einddatum. – De laatste start- en einddatum. – Bereken de vrije en totale speling. – Geef het kritieke pad aan.


3048


3048-27

Ook voor deze stap geldt dat een planningspakket gebruikt kan worden, maar handmatig kan vanzelfsprekend ook. Maak per activiteit de volgende verdeling: Code:

–

–

–

Duur:

VB:

TS:

VE:

LB:

VS:

LE:

Bereken de vroegste begindatum (VB) en de vroegste einddatum (VE). Gebruik hiervoor de volgende formules: • VB = VE (voorganger); • VE = VB + doorlooptijd; Bereken de laatste begindatum (LB) en de laatste einddatum (LE). Gebruik hiervoor de volgende formules: • LB = LE - doorlooptijd; • LE = LB (opvolger); Bereken de vrije en totale speling. De vrije speling is de tijd die een activiteit mag uitlopen zonder dat de einddatum van het project in gevaar komt, terwijl de totale speling de vertraging is die men in een activiteit mag hebben zonder dat het vroegste begin van de opvolgende taak in gevaar komt. Gebruik hiervoor de volgende formules: • TS = LE - VB - doorlooptijd; • VS = VB (opvolger) - (doorlooptijd + VB).

Stap 6 Geef het kritieke pad aan. Het kritieke pad wordt gevormd door de activiteiten geen speling hebben en dat betekent dat vertraging bij het uitvoeren van deze activiteiten onherroepelijk leidt tot een latere einddatum van het gehele implementatieproject. De implementatiemanager zal zich met name op deze activiteiten moeten richten bij de tijdbeheersing van het project. 4.3.2 GANTT-chart Wanneer een geautomatiseerd planningsprogramma wordt gebruikt, kan de netwerkplanning met één druk op de knop omgezet worden in een GANTT-chart. Maar ook hier kan omzetting met de hand plaatsvinden. De activiteiten worden hiertoe op een verticale as gezet en de tijd op een horizontale as. De activiteiten worden voorgesteld door balken. Hierna kunnen de geplande, de werkelijke en de verwachte situatie worden ingetekend. Een nadeel van de


3048

3048-28


GANTT-chart is dat de relaties tussen de activiteiten niet gevisualiseerd kunnen worden. 5. Praktische aanwijzingen Tot slot nog een aantal hints en tips die kunnen helpen bij de implementatie en waarmee men kan voorkomen dat men onbewust in valkuilen stapt. Eerst denken, dan doen! Maar al te vaak worden mensen snel bij elkaar gezocht en wordt er afgesproken dat er een FMIS geïmplementeerd moet worden. Vervolgens gaan de medewerkers hard aan de slag, maar niet gestructureerd en krijgt het project al snel de aanblik van een de spreekwoordelijke kip zonder kop. Het loont altijd om een gedegen Plan van Aanpak op te stellen! Met een PvA in handen is het vele malen eenvoudiger om de komende werklast te overzien en daarmee een goede (= realistische) planning op te stellen. Stel een daadkrachtige projectgroep samen Het is belangrijk dat de projectgroep daadkrachtig is en slagvaardig kan opereren. Natuurlijk stelt dat eisen aan de personen die deelnemen in het project, maar daarnaast zal de projectgroep over voldoende bevoegdheden en middelen moeten beschikken die het mogelijk maken het projectresultaat te realiseren. De stuurgroep zal uitsluitend sturend betrokken mogen zijn en zal zich nimmer met de inhoudelijke kant van het project mogen bemoeien. Daar is de primaire verantwoordelijkheid voor de projectgroep. Informeer tijdig de organisatie Om de weerstand tegen het implementeren van een nieuw FMIS te verminderen, is het belangrijk om tijdig te beginnen met het informeren van de organisatie. Als gebruikers het systeem niet accepteren, kan de kracht van het FMIS nooit ten volle benut worden. Om weerstand op basis van irrationele gronden te reduceren, dienen de toekomstige gebruikers op de hoogte te zijn van het hoe en waarom van het nieuwe FMIS. Door de gebruikers actief bij de acceptatietest te betrekken, kan de weerstand nog verder weggenomen worden. Begin tijdig met conversie of het verzamelen van gegevens De conversie of het verzamelen van gegevens is vaak een struikelblok bij de implementatie van het FMIS, waar men zich lelijk op 2007 – www.factomediabase.nl

3048


3048-29

kan verkijken. Met name het verzamelen en boven water krijgen van de benodigde gegevens vergt vaak meer tijd dan in eerste instantie begroot. Implementeer geleidelijk Ervaringen leren dat de implementatie zelden zonder horten of stoten verloopt. Het is daarom raadzaam om op een beheerste wijze te implementeren. Een implementatie van het gehele systeem ineens wordt daarom afgeraden. Veel verstandiger is het om geleidelijk te implementeren. Vrijwel alle systemen zijn modulair opgezet en kunnen per module geïmplementeerd worden. Indien er mogelijkheden zijn voor een proefimplementatie, dan verdient het aanbeveling om dit serieus te overwegen. Ga uit van realistische doelen. 6. Literatuurverwijzingen Derksen, Th. J.G., Automatisering van de Informatie Verzorging, Schoonhoven: Academic Services 1988. Turner, W.S., Langenhorst, R.P., e.a., System Development Methodology, Rijswijk: Cap Gemini Publishing, 1990. Nolan, R.L., 'Managing the crisis in data processing', Harvard Business Review, 57, 1979, mrt/april, p. 115-126, 1979. Davis, G.B., Olson, M.H., Barten-Hart, H.M.E., Management Informatie Systemen, Schoonhoven: Academic Services, 1987. Yourdon, E., Gestructureerde analyse, Schoonhoven: Academic Services, 1990. Dit artikel is eerder verschenen in het Handboek Facility Management, in september 2001. De redactie is van mening dat dit artikel een waardevolle bijdrage levert aan de diversiteit van de Factomediabase.


3048

Implementeren van een FMIS

Recommend Documents