Sharing IT Best Practices with youSharing IT Best Practices with you
Software implementatie
Een goede software implementatie herken je pas aan het einde van een project. Voordat we zo ver zijn is er heel wat aan vooraf gegaan. We begonnen met een business case, het verzamelen van de requirements, het ontwerp en tenslotte het programmeren en testen van de software. Heb je SaaS of andere standaard software geselecteerd dan heeft dat project ook geleid tot het testen van de software. Het blijkt goed te werken en nu kunnen we de software invoeren.
De woorden implementatie en invoering hoor je vaak in dezelfde context. Het klinkt echter niet helemaal hetzelfde. Invoering klinkt procesmatig, als een aantal acties vlak voor de overdracht. Implementatie geeft meer het gevoel van inbedding in de bestaande organisatie. Feitelijk begint de software implementatie al eerder in het project. Opzoek naar een definitie voor het begrip implementatie kwam ik veel omschrijvingen tegen. Onderstaande definitie heeft betrekking op processen in de geneeskunde maar spreekt mij het meeste aan:
Een procesmatige en planmatige invoering van vernieuwingen en-of verandering van bewezen waarde met als doel dat deze een structurele plaats krijgen in het (beroepsmatig) handelen, het functioneren van de organisatie.
Met name het feit dat de organisatie structureel verandert bij een implementatie van software geeft aan dat we te maken hebben met een belangrijk proces met veel impact.
Voor we een implementatieplan maken moeten we eerst weten wat de status van de software en de omgeving is. Pas als we alle elementen in beeld hebben kunnen we de vervolgstappen bepalen. De te inventariseren elementen zijn:
De complexiteit van de software implementatie kunnen op meerdere aspecten bepalen:
Over het algemeen identificeren we de verschillen op een schaal van grootte (groter of kleiner / meer of minder). Een voorbeeld van “kleinere” business-software is de implementatie van een kantoorpakket. Er kunnen echter veel eindgebruikers bij betrokken zijn, terwijl de impact op de taken en verantwoordelijkheden van de gebruikers niet groot is. De dagelijkse workflow van de eindgebruiker verandert immers ook niet veel. Een voorbeeld van “grotere” business-software is de implementatie van een ERP-systeem.
Als er koppelingen met andere systemen nodig zijn kan dit impact hebben op die systemen. We moeten er rekening mee houden dat deze systemen ook aangepast moeten zijn voor we de implementatie succesvol kunnen afronden.
De inventarisatie voor de software implementatie moet leiden tot diepgaande inzichten over de software, maar ook over de architectuur en de organisatie. Het gebruik van een grote software toepassing brengt veel meer toewijding van de eindgebruikers met zich mee. De impact van de verandering is groot vanwege de creatie van nieuwe taken en verantwoordelijkheden.
Voordat de nieuwe software tot stand kwam hadden de gebruikers al een werkwijze. Het is mogelijk dat we te maken hebben met een geheel nieuwe organisatie, dat scheelt veel werk. Het is echter onwaarschijnlijk dat de gebruikers nog gebruik maken van een kaartenbak en een rekenmachine. Van welke andere software maken ze dan wel gebruik? Waarom komt er vervangende software? Hebben ze een complete oplossing direct nodig, of kunnen ze tijdelijk met een gedeeltelijke oplossing werken? Welke impact hebben dergelijke keuzes op de bedrijfsprocessen?
Lopen er nog contracten met betrekking tot de oude software en hoe gaan we daar mee om?
Globaal gezien zijn er twee verschillende ontwikkelmethodes, waterval en Agile. Daarnaast kunnen we te maken hebben met de implementatie van standaard software of een SaaS oplossing. Belangrijkste gevolg van een ontwikkelmethode voor de implementatie is of de software als een geheel of in brokken wordt opgeleverd. En als het dan in brokken wordt opgeleverd kunnen we het dan ook broksgewijs implementeren of komt er een Big bang?
Met de komst van DevOps als ontwikkelmethode is er sprake van continue testen en releasen. De implementatie van de software is vrijwel impliciet en vereist een kanteling binnen het implementatieplan.
Niet iedere omgeving is hetzelfde. Sinds de komst van Cloud computing is het echter vrij eenvoudig om een omgeving op te zetten zonder dat we de bedrijfsprocessen verstoren. Dit opent de weg naar een Living Lab waarbij we de gebruikers grote invloed op de implementatie kunnen geven.
Voor we met de implementatie beginnen is het belangrijk om te weten wat de status van de software is. Als de ontwikkeling van de software nog gaande is kunnen we mogelijk nog in belangrijke mate invloed uitoefenen op de werking er van. Is de software al opgeleverd of is er sprake van COTS software dan hebben we alleen nog maar invloed op de configuratie. Is er rekening gehouden met een fall back scenario of is er geen weg terug?
De meeste software werkt niet zonder data. Een juiste werking van de software hangt juist in belangrijke mate af van de kwaliteit van de data. Waar komt deze data vandaan? Beginnen we met een blanco systeem? Kopen we datasets? Of koppelen we met andere systemen? Welke contracten moeten we daarvoor opstellen?
Converteren we de data uit het oude systeem en moeten we deze dan nog verrijken? Bedenk dat als de conversie en de datasets eenmaal geplaatst zijn we weer opnieuw moeten testen. Grote kans dat deze data net niet goed te verwerken is en ook nog een extra bewerking behoeft.
In een ideale organisatie weet iedere gebruiker hoe de bedrijfsprocessen werken en welke wetten en regels er van toepassing zijn. Deze materiedeskundigen zijn bij uitstek geschikt om het systeem te vullen en te testen. Helaas geldt dit echter slechts voor enkele gebruikers. Voor de software implementatie is het van belang te weten waar de sterke gebruikers zitten en waar de organisatie nog te kort schiet.
Iedere organisatie geeft een eigen invulling aan het service management, d.w.z. het beheer van IT systemen. ITIL, ASL en BiSL zijn bekende frameworks, maar soms is er slecht één gebruiker die alles doet. Het hangt erg af van de omvang en het type organisatie. Systeembeheer en applicatiebeheer kennen al beheerprocessen. We hebben een servicedesk voor onze vragen evenals een ticketsysteem om alles te volgen. Nu komt er nieuwe software bij. Die gaan we straks implementeren in de bestaande beheer processen. Daarom moeten we weten welke processen er al zijn en hoe die zijn ingericht.
Hetzelfde geldt voor het onderhoud van de software. Na de implementatie treden er storingen op en is er sprake van backlog. Dat wil zeggen, nog niet aan alle requirements is voldaan. Maar waar zijn de ontwikkelaars gebleven? Is er nu een onderhoudsteam? En zijn zij voldoende bekend met de software?
Als de software door een externe partij is ontwikkeld, hoe ziet het contract met deze partij er dan uit? Nemen zij ook het applicatiebeheer op zich?
Het software implementatie plan beschrijft alle stappen die nodig zijn om de implementatie te realiseren. Soms zijn ze afhankelijk van elkaar en soms kunnen ze tegelijkertijd plaatsvinden. De invulling van de implementatie stappen komt tot stand binnen het projectteam. De inhoud is mede afhankelijk van hetgeen we tijdens de inventarisatie hebben gevonden.
Binnen een bedrijfsproces kunnen we altijd meerdere subprocessen herkennen. Als het primaire proces bijvoorbeeld verkoop is, zijn er een aantal ondersteunende processen. Dit zijn bijvoorbeeld “beheren artikelen” en “beheren klanten”. Aangezien we artikelen aan klanten verkopen moeten we van beide iets weten voor we een deal kunnen sluiten. In dit voorbeeld kunnen we dus het beste eerst de artikelen-processen en daarna de relatiebeheer-processen implementeren. Als die goed werken volgt de implementatie van het verkoopproces.
Om deze activiteit te kunnen beschrijven hebben we informatie nodig uit de inventarisaties van:
Er is maar weinig software die werkt zonder data. Deze data moeten we converteren uit legacy systemen of via koppelingen uit andere systemen. Deze activiteit kan een groot project op zichzelf zijn. Tijdens de ontwikkeling en het testen is al data nodig om de werking van de software te controleren. We maken daar proefconversies voor en zorgen dat er geen mutaties plaatsvinden in andere systemen via de koppelingen. De gegevens voor deze activiteit vinden we in de volgende inventarisaties:
In de eerste plaats voeren we de gebruikers en hun rollen binnen de software in. Om hun autorisatie af te ronden geven we ze een wachtwoord zodat ze kunnen inloggen. Verder kent ieder type software zijn specifieke instellingen. Denk daarbij aan prijsstaffels, artikel kenmerken, formules, bedrijfsregels, enzovoort. Dit vormt de kern van het implementeren van de software, het afstemmen op de organisatie. Informatie voor het plannen van deze activiteit vinden we in inventarisaties betreffende:
Als de software eenmaal in gebruik is moet de gebruiker kunnen rekenen op de service van IT. In de eerste plaats moet er een Service Level Agreement (SLA) komen. Daarin staan alle afspraken over het service niveau waarop de gebruiker aanspraak kan maken. Met behulp van Key Performance Indicatoren (KPI) stellen we met elkaar vast hoe ver dat gaat. Denk aan beschikbaarheid van het systeem, reactie snelheid bij storingen enzovoort. Om de SLA waar te kunnen maken zijn processen en een service organisatie nodig. Denk aan:
Als er al een service management organisatie is kunnen we de nieuwe software daarin onderbrengen. Dat vergt natuurlijk de nodige aanpassingen. Input uit de inventarisaties over:
Nieuwe software vergt ook nieuwe kennis. De meeste gebruikers zijn bekend met de oude software en zijn tevens materiedeskundige. Zij zullen dus snel de functies van de nieuwe software herkennen. Hen moeten we wel duidelijk maken waar ze de functies kunnen vinden en hoe ze in de nieuwe software geïmplementeerd zijn. Hiervoor maakt het implementatieteam een gebruikershandleiding.
Naast eindgebruikers zijn er ook IT-ers die we voor de nieuwe software moeten trainen. Misschien is er sprake van een geheel nieuw platform of een andere programmeertaal. Dit geldt ook voor de servicedesk. Omdat de IT de gebruikers moet ondersteunen in het gebruik van de software moeten ze ook een veel diepgaandere kennis hebben van het systeem. Zodoende kunnen ze straks problemen oplossen die de gebruiker niet kan oplossen. Informatie voor deze activiteit is te vinden in de volgende inventarisaties:
Tijd om met het overgangsproces van het ene systeem naar het nieuwe te beginnen. De organisatie moet een overschakelingsplan hebben zodat we het voortdurende risico van overgang van het ene systeem naar het andere kunnen minimaliseren.
Zorg ervoor dat er tijdens de overgang controlepunten zijn. Communiceer met elkaar over uitslag van deze controles zodat iedereen weet wat de voortgang is.
Activiteiten tijdens de overgang zijn:
We identificeren alle sleutelactiviteiten en wijzen ze toe aan sleutelfiguren binnen het project. Doe dit ruim van tevoren zodat we met elkaar overeenstemming kunnen bereiken over de taken en onze aanwezigheid op de bewuste dag.
Om deze activiteit goed in het software implementatie plan op te kunnen nemen hebben we informatie nodig uit de volgende inventarisaties:
Het is zo ver. Het is tijd om de nieuwe software in te schakelen en gebruikers in staat te stellen transacties te doen.
Zorg er voor dat de gebruikershandleiding en de inlogcodes voor iedere gebruiker aanwezig zijn.
Een aantal gebruikers kennen de software al omdat ze in het project hebben meegedraaid. Als lid van de stuurgroep, materiedeskundige of als tester. Dit is slechte een klein deel van de organisatie en de andere gebruikers zien de software voor het eerst.
Daarom is het belangrijk dat er de eerste week een ondersteuningsteam klaar staat om de gebruikers te begeleiden. De gebruikers die al in het project meedraaien zijn belangrijke ambassadeurs, zo niet evangelisten van de software. Zij vormen een belangrijke groep. Daarnaast is het goed dat ook de ontwikkelaars en helpdeskmedewerkers op de afdeling rond lopen. Zij kunnen de gebruikers direct helpen. Dit bevordert de acceptatie van de software enorm.
Deze eerste ondersteuning kunnen we langzaam afbouwen tot het punt dat de gebruiker zelfstandig met de software om kan gaan. Alleen de servicedesk zal dan in stand blijven.
De nieuwe gebruikers komen met nieuwe vragen. Misschien komen ze met nieuwe wensen waar niet eerder aan was gedacht. De het onderhoudsteam moet hier de backlog voor openstellen. Alle bevinden kunnen we vastleggen en later bepalen of we ze ook gaan implementeren.
Informatie voor deze activiteit is afkomstig uit:
Communicatie is de smeerolie van een project. Tijdens een software implementatie geldt dit nog veel sterker. Alle betrokkenen hebben namelijk het gevoel dat het er nu op aankomt! Iedereen wil weten hoe het loopt en of hij of zij zelf nog iets moet doen om het soepel te laten lopen.
Goede communicatie is ook een issue voor de gebruikers. Zij moeten zich niet alleen betrokken voelen bij de software maar ook bij het project. Dat zal de acceptatie van de software bevorderen.
De volgende communicatiemiddelen staan beschikbaar voor het projectteam.
In het implementatieplan kunnen we opnemen op welke manier we met de gebruikers willen communiceren. We zijn nog niet klaar met dit onderwerp. In volgende artikelen zal ik nader ingaan op verschillende “Implementatie kaders” en de “Best Practices voor implementatie”.
Discussieer mee op LinkedIn. 
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.