applicatie implementatie management

Inhoud Stel, je koopt een huis uit de jaren ’30. Het is je absolute droomhuis, maar er moet nog wel flink wat aan verbouwd worden. Uiteraard heb je hiervoor het benodigde budget bepaald en een tijdsplanning gemaakt. Om binnen scope te blijven kan een blauwdruk van het huis enorm helpen. Nu wil het geval dat er tot jouw grote teleurstelling geen blauwdruk van het huis voorhanden is. Om te zorgen dat je weet waar water- en gasleidingen of elektriciteitskabels lopen en je deze tijdens de verbouwing niet per ongeluk raakt, zul je met speciale meetapparatuur in kaart moeten (laten) brengen waar kabels zich bevinden en misschien zelfs hier en daar een muur open moeten breken om te zien waar leidingen lopen. Als gevolg van het ontbreken van de blauwdruk kan je de verbouwing nooit binnen je scope realiseren en raak je enorm achter op het budget en de tijd die je dacht nodig te hebben. Ondanks dat besluit je om – voor de verbouwing – overzicht te krijgen en een blauwdruk te maken van je huis. Uiteraard kost dat extra werk en tijd, maar vijf jaar later blijkt deze investering haar vruchten af te werpen als er een lekkage ontstaat. Een blik op je blauwdruk helpt je namelijk snel en gemakkelijk te achterhalen waar de lekkage vandaan moet komen, zonder dat je hiervoor muren hoeft open te breken. En dat geldt ook voor het bedrijfsleven. Door je bedrijfsprocessen vast te leggen in een blauwdruk van je organisatie in het Mavim platform, ben je in staat om sneller en eenvoudiger in te spelen op risico’s (zoals een lekkage in je huis), is de organisatie transparant (kun je als het ware door de muren heen kijken) en kun je incidenten voor blijven. Door processen, systemen en mensen met elkaar te verbinden en te borgen kan je goed inspelen op veranderingen (zoals de verbouwing van je huis).   Door: Léon van der Windt Lees hier hoe je in 10 eenvoudige stappen een procesblauwdruk van je organisatie kunt maken 

Inhoud   Zoals iedereen die ooit een huis heeft gebouwd begrijpt, biedt een blauwdruk je de basis en beste kans op het succesvol bereiken van jouw doelstelling. Ook in de bedrijfswereld kan een blauwdruk een effectief instrument zijn. Een blauwdruk van je bedrijfsprocessen helpt jou en je collega's om inzicht te krijgen in het verloop en de duur.  In het boek getiteld “The Power of Business Process Improvement” reikt Susan Page tien eenvoudige stappen aan die je kunt gebruiken bij het maken van je eigen proces blauwdruk.   Maak een procesinventarisatie — De eerste stap is het inventariseren van al uw processen. Hoewel deze handeling misschien eenvoudig lijkt (wellicht denkt u alle processen al te kennen), helpt het vergaren van een visuele lijst om alvast na te denken over de prioriteit van elk proces. Leg het fundament — Stap twee helpt je bij het ontwikkelen van het toepassingsgebied. Op dezelfde manier waarop je aan een plan begint voor de verbouwing van jouw huis, moeten er voor een procesblauwdruk kaders worden vastgesteld. Teken de blauwdruk — Het maken van de blauwdruk impliceert begrip van waar overdrachten tussen afdelingen voorkomen. Bij deze stap moet je de informatie (output) uit de vorige stap toepassen door in kaart te brengen welke afdeling of individu verantwoordelijk is voor welk deel van het proces, van begin tot eind. Maak een schatting van tijd en kosten — Voordat doelen voor procesverbetering worden gesteld, is een nulmeting van cruciaal belang. Hoe lang duurt het verloop van processen en wat kost dit momenteel voor jouw organisatie? Deze stap definieert de parameters die worden gebruikt voor de verbetering van de doelstellingen. Controleer de proces blauwdruk — Vanaf dit punt is het waardevol om feedback te krijgen van betrokken collega's om ervoor te zorgen dat je nieuwe blauwdruk de realiteit weerspiegelt. Deze stap helpt ook om de nodige ondersteuning van belanghebbenden te verkrijgen. Pas verbetertechnieken toe — Een gestructureerde aanpak voor het verbeteren van bedrijfsprocessen met behulp van methoden zoals: afschaffing van de bureaucratie, evalueren van waarde toevoegende activiteiten, elimineren van overtolligheid, vereenvoudigen van rapporten en formulieren, verminderen van de cyclustijd en automatisering toe te passen. Door dergelijke verbetertechnieken nauwkeurig toe te passen op elk proces, zorg je ervoor dat al je processen bedrijfswaarde opleveren. Creëer interne controles en statistieken — De volgende stap is ontworpen om je te helpen de voortgang te monitoren. Het instellen van interne controles helpt om hulpmiddelen te creëren voor het verhogen van de effectiviteit, de efficiëntie en het aanpassingsvermogen van het bedrijfsproces. Bedrijfsprocessen zijn, zoals veel andere dingen, vaak onderwerp van menselijke fouten. Daarom is het essentieel om interne statistieken te ontleden en het proces zo veel als mogelijk te automatiseren. Doe een proeftest — Op dezelfde manier waarop een gratis 30-dagen test is bedacht om je kennis te laten maken met een product zonder hiervoor grote investeringen te doen, zal een proeftest voor jouw nieuw ontworpen bedrijfsprocessen helpen bugs op te lossen en ervoor zorgen dat het procesresultaat aan jouw vereisten voldoet, voordat je de voorgaande manier van werken overboord gooit. Voer de verandering door — In dit stadium worden de vernieuwde processen uitgerold. Deze stap vereist dat je de juiste informatie richting de juiste mensen communiceert. Zonder deze stap, is het nieuwe proces bijna gegarandeerd te mislukken. Streef naar continue verbetering — Dit is de onderhoudsfase. Hopelijk zijn de nieuwe processen succesvol ingevoerd. De laatste fase behelst het creëren van een mentaliteit waarbij procesverbetering als een doorlopend fenomeen wordt beschouwd, dat voortdurend evaluatie vereist om continue doeltreffendheid en efficiëntie voor de organisatie te garanderen. Hebt u ooit met succes een proces blauwdruk vastgelegd? Bekijk hier de praktijkcase van Kuwait Petroleum waarbij een complexe ERP-implementatie de aanleiding vormde voor het in kaart brengen van een procesblauwdruk

Inhoud   Voor de jaarwisseling is Alrijne Zorggroep overgestapt op een nieuw epd, HiX. Daarmee zijn in alle ziekenhuislocaties in Leiden, Leiderdorp, Alphen aan den Rijn, Katwijk en Sassenheim verschillende systemen vervangen door één geïntegreerd epd. Daarnaast zit de organisatie midden in een fusieproces. Dat maakt zo’n overstap complex, maar werken aan een gezamenlijk epd disciplineert en enthousiasmeert ook. Als je een nieuw informatiesysteem / epd / workflow-systeem wilt invoeren, gemodelleerd naar de nieuwe situatie, de fusie dus, loop je tegen een dilemma aan. Eigenlijk zou je het liefst alles geharmoniseerd willen hebben voordat je een epd uitrolt: het organisatiemodel, de processen, de IT, het applicatielandschap. Alleen, je kunt je processen en organisatie niet optimaal harmoniseren zonder te beschikken over een nieuw systeem. Uiteindelijk hebben wij als raad van bestuur de keuze gemaakt om eerst het nieuwe systeem in te voeren, mét standaardcontent. En dat heeft geholpen.   Ervaringen van veel ziekenhuizen Standaardcontent is alle denkbare inhoud voor een optimaal epd, samengesteld uit de ervaringen van veel ziekenhuizen. En dát gestandaardiseerd. Dit varieert van verslagleggingsmogelijkheden tot complete orderworkflows, specialistische vragenlijsten, scorelijsten, ingebouwde richtlijnen, beslisondersteuning, multimedia. Die inhoud krijgen wij gestructureerd aangereikt van onze leverancier, waardoor veel werk al voor ons is gedaan. Niet alleen met de inhoud zelf, maar ook op het gebied van onderhoud en implementatie.   Harmoniseren Een standaard-content-epd dwingt je als organisatie om processen te harmoniseren. De werkgroepen van onze verschillende locaties kwamen bij elkaar en overlegden over een eenduidige werkwijze binnen de standaardcontent. Dat maakt harmoniseren gemakkelijker, omdat de richting al is bepaald. Bovendien is het veel leuker om samen aan iets nieuws te werken dan met elkaar te touwtrekken over wiens aanpak leidend moet worden. Natuurlijk zijn er specialismen die door de invoer van het nieuwe epd in eerste instantie inhoudelijk een stapje terugdoen, omdat ze hun vorige epd zelf geoptimaliseerd hadden. Mede omdat in die gevallen de standaardcontent minder functionaliteiten biedt dan in de oude situatie, moesten er ook veel weerstanden overwonnen worden. Maar, ze zetten straks veel stappen vooruit door te profiteren van de inrichting van patiëntendossiers in andere ziekenhuizen.   Regionale samenwerking Op het gebied van regionale samenwerking gaat standaardcontent ons ook helpen. Wij wilden een epd waarmee onze partners in de regio ook (kunnen/gaan) werken. Denk aan huisartsen, laboratoria en thuiszorg, maar ook het Leids Universitair Medisch Centrum, dat al met HiX werkt. Dat is essentieel voor ons. Het nieuwe epd faciliteert optimale gegevensuitwisseling tussen samenwerkende ziekenhuizen. Wij zijn er niet per se op uit om zelf de innovator of pionier te zijn op dit gebied, liever de early adaptor. Op beperkte schaal experimenteren hoort daarbij.   Hartverwarmend Aan de overstap naar ons nieuwe epd hebben we met 70 werkgroepen en ruim 400 mensen keihard gewerkt en we hebben zo’n 3.000 medewerkers opgeleid. Dat is immens. Het zijn unieke ervaringen binnen een organisatie als de onze. Als je achteraf ziet hoe de medewerkers daarmee zijn omgegaan, kan ik alleen maar een diepe buiging maken. Het is hartverwarmend te zien hoe de saamhorigheid is vergroot.   Lessons learned Ten slotte wil ik wat tips delen met ziekenhuizen die aan de vooravond staan van een epd-overstap: onderschat het niet. Breng je hardware vroegtijdig op peil en start direct met onderdelen als portalen en zuilen. Voor een portaal moet je namelijk aan strenge beveiligingseisen voldoen. En wat betreft de zuilen: dat heeft veel impact op de logistiek in je hal en bij de inschrijfbalies. Stel jezelf de volgende vragen: waar komen de afsprakenbureaus en inschrijfbalies? Wat is er fysiek en wat niet? Hoe werkt dat samen? Wat moet er verbouwd worden? Als u op tijd begint én gaat voor standaardcontent, dan heb ik er alle vertrouwen in dat ook ú een succesvolle overstap maakt.Auteur: Mark de Jong, lid van de raad van bestuur van Alrijne Zorggroep en verantwoordelijk voor de portefeuille bedrijfsvoering.Benieuwd naar het praktijkverhaal van Leger des Heils? In deze video legt procesbeheerder, Irene de Jong, uit hoe het Leger des Heils hun EPD hebben geïmplementeerd.

Inhoud Falende ICT-projecten komen regelmatig in het nieuws, trajecten waar niet opgeleverd wordt wat men verwacht had. Vaak zijn deze problemen en teleurstellingen terug te leiden naar één probleem: een ontoereikende voorbereiding. Wanneer een organisatie een softwarepakket kiest, gebeurt dit meestal op basis van een eigen referentiekader, wat dan vaak gekleurd is door denken vanuit de huidige situatie. Processen zijn vaak zoals ze zijn. Het risico is groot dat alleen de huidige werkwijze in een nieuwer, duurder jasje wordt gestoken. Zoals bij veel dingen in het leven, geldt ook bij het gebruik van software: “Als je doet wat je deed, krijg je wat je kreeg.” Om dat te vermijden is het van belang dat de organisatie zichzelf de juiste vragen weet te stellen voordat een kostbaar project wordt gestart.   Worden bestaande (ingesleten) processen wel voldoende ter discussie gesteld? Kan het wellicht beter, zelfs met de bestaande software? Is er voldoende reden om een proces in maatwerk te vervatten? Of is het proces een “gewoonteproces” en kan het eigenlijk ook wel anders? Tijdens projecten zie ik een grote meerwaarde in het maken van implementatie- of optimalisatie-blauwdrukken. Na enige tijd te hebben gezocht naar een goede tool, werken wij sinds 2015 samen met Mavim. Het pakket Mavim stelt ons in staat proceskaarten te maken van de klantprocessen die geraakt worden door een implementatie. Met functiestroomschema’s en verantwoordelijkheden matrices (RASCI) maken we inzichtelijk hoe huidige processen worden uitgevoerd. Met het huidige proces in beeld en het ideale proces als hoger doel, maken we samen met de klant op voorhand keuzes over de inrichting, van zowel het pakket als het proces. Naast de processen leggen we ook het functiehuis, de autorisatie en verschillende rapportages vast. Op deze manier zijn procesmatige en/of organisatorische veranderingen op voorhand bekend en kunnen we met onze klanten echt het maximale rendement uit een implementatietraject halen. We vermijden de kostbare verrassingen waar klanten door verrast worden en die vaak duur uitpakken. Met behulp van een blauwdruk is iedere stakeholder goed voorbereid op het veranderingstraject. Dat is de kracht van eerst denken en dan doen. En het enige recept om te vermijden dat de organisatie blijft doen wat ze deed en dus krijgt wat ze kreeg.Auteur: Jacob-Jan Mannak, senior consultant Forque

Inhoud Een goed jaar geleden maakte Michiel Hoogenboom van Microsoft kennis met Jan Koen, de bevlogen CIO van DEEN Supermarkten. Hij heeft een grote passie voor zowel technologie als de klant centraal te stellen. Michiel vindt het daarom leuk dat Jan aan het einde van deze maand als bezoeker én spreker naar Microsoft Convergence in Barcelona gaat. Wat voor inzichten voor de retail gaat hij daar ophalen en brengen? Michiel vraagt het hem.   Waarom ga je naar Microsoft Convergence in Barcelona? Voor een bedrijf als DEEN, een marktleider in de retail branche, is het altijd een uitdaging om op de hoogte te blijven wat de klant wil. Daarom wil ik in Barcelona de technologie van vandaag en zeker die van morgen gaan ontdekken waarmee we de klant kunnen blijven verrassen. Op dit moment verrassen we de klant vooral met producten en we willen dit ook met diensten gaan doen. Ik zoek naar subtiele wijzen waarop we moderne technologie in de winkels kunnen toevoegen waardoor het voor de klant altijd prettig is en blijft om bij ons te winkelen. Verder wil ik zien welke innovaties we van Microsoft kunnen verwachten. Voornamelijk ook in Microsoft CRM, wat wij in de cloud draaien. Ik wil Microsoft CRM een prominentere plaats geven in de omnichannel waardeketen: denk bijvoorbeeld aan onze kleine webshop die op dit moment sterk groeit. Daarnaast ondersteunt de combinatie van Microsoft CRM, Microsoft Dynamics AX en andere Microsoft producten op het gebied van mobiliteit, denk aan Windows10, mobile devices en Azure, mij niet alleen in het bedienen van mijn gebruikers maar juist ook met de communicatie naar de medewerkers en de klanten. Azure zorgt er bijvoorbeeld voor dat ik buiten mijn eigen legacy systemen om kan communiceren. Natuurlijk ga ik ook naar de presentaties van andere Microsoft-klanten kijken, want daar leer ik ook weer van.    Naar welke sessies tijdens Microsoft Convergence kijk je specifiek? Ik ben erg gericht op de toekomst. Niet alleen voor mijn vak, het is ook mijn hobby en passie. De sessie van technologie-ondernemer Peter Hinssen gaat over digitaal leiderschap en wat dat voor de toekomst zou kunnen betekenen. Het is altijd moeilijk om goede voorbeelden te zoeken en goede informatie te krijgen over hoe je het pad het beste kan bewandelen of je in de grote of kleine organisatie werkt. Wij doen dat met vallen en opstaan, met kleine stapjes vooruit. Grote stappen zijn moeilijk te maken omdat de operatie zich in hoog tempo beweegt en grote veranderingen niet in één keer doorgevoerd zijn. Er vinden al wel veel grote veranderingen plaats op basis van technologie. Welke slimme keuzes kun je dan maken? Ik ben zeer geïnteresseerd in wat Peter Hinssen hierover te vertellen heeft. Daarnaast zag ik op dinsdag de sessie ‘Achieving Business Transformation through the Power of the Cloud’ gepland. Ook wij zullen in 2016 weer gericht gaan kijken wat de mogelijkheden zijn van de cloud en dan in het bijzonder naar Azure. Dit omdat Azure precies binnen onze visie over de Microsoft producten valt: het inzetten van de cloud als onderdeel van ons applicatie portfolio. Verder wil ik graag leren van andere gebruikers. Ik heb verschillende keren deelgenomen aan rondetafelsessies in Nederland, maar ik heb geen idee van hoe het gaat in andere landen. Ik wil dan ook graag luisteren naar de verhalen van anderen. Waar staan ze en waar staan wij ten opzichte van hen? Welke keuzes hebben zij gemaakt en waarom hebben ze die keuzes gemaakt? Auteur: Michiel Hoogenboom, Microsoft Wilt u meer zien van Jan Koen? Bekijk dan hier het interview met Jan Koen.

Inhoud Wat kan er misgaan bij de implementatie van een ERP systeem? Wat zijn de valkuilen? Wanneer mislukt een implementatietraject van een ERP systeem. Lees in deze blog de antwoorden van tientallen ERP specialisten op deze vragen.   (1) Gebruikers worden niet betrokken in het voortraject Een ERP systeem implementatie mislukt wanneer de beoogde oplossing niet werkbaar wordt bevonden door de gebruikers. Dit ontstaat wanneer gebruikers niet bij het voortraject betrokken worden. Er is dan een mismatch tussen toepasbaar en werkbaar. Een workshop met alle gebruikers kan dit voorkomen. Ze krijgen dan een “speak now or forever hold your peace” moment. Het lastige van het definiëren van ‘werkbaar’ is dat het een subjectief begrip is. Dit leidt dan tot eindeloze discussies met de leverancier. Vergeet niet dat gebruikers bereid moeten zijn uit hun comfortzone te komen, hetgeen door niet alle managers begeleid wordt.   (2) Te vaak wordt er traditioneel geselecteerd Vaak wordt er erg traditioneel geselecteerd, gebruikers mogen ongeremd hun eisen en wensen indienen. Een enorme lijst is het gevolg, er wordt niet meer getest op relevantie. Op deze manier herautomatiseren bedrijven vaak vooral hun huidige manier van werken in een nieuw modern systeem. Terwijl de winst is te behalen in het ondersteunen van de nieuwe gewenste manier van werken. Door de oude situatie te kopiëren worden vaak nieuwe innovatieve ideeën van leveranciers niet in het ERP systeem geïmplementeerd.    (3) Het aantrekken van externen is niet goed Zijn externen voor de ERP systeem implementatie noodzakelijk? Laat ze de bestaande werkzaamheden overnemen. Eigen medewerkers dienen met de verandering bezig te zijn. Een veel gemaakte fout is om een lading externen aan te trekken en deze de implementatie te laten verzorgen. Selecteer een betrouwbare leverancier die opleiding, implementatie en ondersteuning zelf verzorgt. Het is goed mogelijk dat u tijdens het implementatieproces tegen onvoorziene zaken aanloopt. Denk hierbij aan de hele implementatieketen. Het proces van verkoop, implementatie, opleiding en support dient een soepele machine te zijn.    (4) Eerst organiseren, dan automatiseren Succes zie je terugkomen bij bedrijven die een beeld hebben van de toekomst en in staat zijn om de organisatorische veranderingen te benoemen. Het aloude gezegde “eerst organiseren, dan automatiseren” heeft in zijn essentie nog steeds niet afgedaan. Het bedrijf zal niet alleen een oplossing moeten zoeken voor de huidige problemen, maar eveneens participeren op gewijzigde omstandigheden in de toekomst. Er komt een afdeling bij, bedrijven worden samengevoegd of gesplitst. Zoek een op het web gebaseerde oplossing die gemakkelijk aanpasbaar is.    (5) Onvoldoende focus en aansturing Vaak mislukken ERP systeem implementaties door onvoldoende focus en aansturing. Het implementeren van een ERP oplossing is een enorme verandering voor de organisatie en vereist vaak een andere manier van werken. Gebrek aan change management en communicatie tijdens dit traject zijn serieuze valkuilen. Het is daarom ook belangrijk dat het senior management duidelijke doelen voor ogen heeft met het overstappen op nieuwe ERP software. Het is belangrijk voor de medewerkers om te weten waarom het bedrijf overstapt op een nieuwe ERP software oplossing en wat voor hen de voordelen zijn.    (6) Blijf managen! Ook na ERP systeem implementatie. Durf problemen te adresseren. Blijf managen ook als de ERP systeem implementatie is afgerond. De hang naar ‘het oude vertrouwde’ zit in medewerkers en dit werkt zeker niet ten gunste van uw ERP project.    (7) Het fenomeen van voortschrijdend inzicht Een valkuil is het fenomeen van het voortschrijdend inzicht. Tijdens de ERP systeem implementatie neemt het kennisniveau bij de klant over het ERP systeem toe en dit kan leiden tot het stellen van nieuwe eisen en het creëren van andere verwachtingen als bij de start van het project. Dit pleit dus voor een gefaseerde aanpak en een heel duidelijke afspraak over de te behalen doelstellingen van die fase.    (8) Besteed genoeg tijd aan het voortraject Als niet voldoende tijd wordt besteed aan het voortraject. Dat wil zeggen dat het traject niet in kleine stappen met hoogste prioriteit ingedeeld wordt. Verplaats u in de schoenen van de ander: de verkoper van het ERP systeem denkt opportuun en belooft van alles om het contract ondertekend te hebben, zodat hij verder kan met het volgende traject. Dit kan leiden tot veel maatwerkbeloftes, met alle problemen van dien. De inkoper van de klant aan de andere kant heeft er baat bij om voor een zo gunstig mogelijke prijs het traject in te kopen en zo snel mogelijk intern vorderingen te kunnen laten zien. De inkoper wil aan het voortraject en de ERP systeem implementatie dus zo min mogelijk geld spenderen. Dit kan ertoe leiden dat beiden gebaat kunnen zijn bij het te snel implementeren van een schaap met vijf poten. Tevens is een grote valkuil dat de verkoper en inkoper van ERP software gezamenlijk bepalen wat er nodig is, terwijl beiden vaak niet betrokken zijn bij de uiteindelijke implementatie.    (9) Geen oog meer hebben voor de hoofdlijnen De valkuilen zijn in het algemeen: het verzanden in details en geen oog meer hebben voor hoofdlijnen, het achterwege blijven van een culturele klik tussen de twee bedrijven, waardoor de samenwerking uitmondt in tegenwerking, de scope uitbreiden, waardoor een project te omvangrijk wordt en te weinig tijd uittrekken voor de voorbereiding.   (10) Beschouw ERP systeem implementatie niet als IT traject Uitgaande van een juiste keuze voor software en leverancier ligt het grootste afbreukrisico, zo blijkt uit onderzoek, in het niet goed vastliggen van (en vasthouden aan) de scope. Onvoldoende capaciteit kunnen vrijmaken door gebrek aan ondersteuning van de leiding is ook een beruchte. Beschouw de ERP systeem implementatie nadrukkelijk niet als IT traject. Vertegenwoordigers uit alle disciplines binnen de organisatie dienen betrokken te zijn bij de implementatie. Is dit niet het geval, dan ontbreekt het draagvlak m.b.t. de keuze en of de inrichting en is de kans zeer groot dat de organisatie niet of niet optimaal met het systeem gaat werken.    (11) Bezuinigen op prijs is een valkuil Geavanceerde ERP systemen met uitgebreide functionaliteiten hebben vaak een prijskaartje en verlangen een goede implementatieperiode alvorens de software operationeel is. Nog te vaak wordt er bezuinigd op prijs of implementatie-uren. Misverstanden over de ERP systeem implementatie zijn vaak te wijten aan onduidelijkheid over de taakverdeling. Het is belangrijk om vooraf een duidelijk projectplan te schrijven met hierin een taakverdeling: wie doet wat? Een implementatietraject vergt een goede samenwerking tussen u als organisatie en uw ERP leverancier. Een andere valkuil is dat de ERP oplossing niet gedragen wordt door de gehele organisatie. De toekomstige gebruikers zijn niet geraadpleegd bij de keuze of invoering van het ERP pakket, hierdoor kan er veel weerstand ontstaan bij het nieuwe systeem.    (12) Het ontbreekt vaak aan een lange termijnvisie Aan het begin van een ERP systeem implementatie zijn alle afspraken helder en zijn er nog geen teleurstellingen geweest. Maar hoe goed voorbereid ook, elke implementatie kent goede en minder goede momenten. Naarmate de implementatie vordert verminderd het elan en worden afspraken herzien, ten gunste van de korte termijn. Een voorbeeld kan zijn om toch maatwerk te ontwikkelen om een bepaalde gebruiker(sgroep) tevreden te stellen en verder te kunnen met het project. Maar dit komt de lange termijn van de implementatie niet ten goede en zal het eindresultaat schaden.    (13) Gestelde eisen zijn te hoog Over het algemeen zal een ERP systeem implementatie mislukken wanneer de gestelde eisen te hoog zijn t.o.v. het gemiddelde niveau van de gebruikers. Je kunt een pakket willen gebruiken dat nagenoeg alles kan, in de praktijk worden die mogelijkheden vaak niet uit een product gehaald. Een gebruikersvriendelijk opgezet ERP systeem met minder mogelijkheden kan soms een hoger rendement behalen. In onze markt zien we nog wel eens dat er gekozen wordt voor niet branchegerelateerde pakketten, maar voor de zogenaamde ‘algemene horizontale’. In de praktijk betekent dit dat tijdens de implementatie al gemerkt wordt dat allerlei finesses die met de branche te maken hebben ontbreken. Deze finesses worden in het selectietraject vaak niet benoemd. Een project kan ook makkelijk mislukken wanneer er na de aankoop te weinig tijd wordt ingeruimd voor de implementatie. Ook wordt er uit kostenoogpunt wel eens bezuinigd op begeleiding. Bron: ICT InformatiecentrumMeer weten over de aandachtpunten, valkuilen, voordelen en toegevoegde waarde van ERP implementaties? Bezoek onze themapagina over applicatie implementatie management! 

Inhoud   Van on-premise systemen tot cloud-based software-as-a-service: De IT managers van vandaag hebben meer keuzes dan ooit bij het kiezen van een ERP-oplossing. Beslissers kunnen zich overweldigd voelen wanneer ze proberen te bepalen welke functies en features voor hun organisatie het belangrijkst of meest relevant zijn. ERP-experts hebben de grootste fouten geïdentificeerd die beslissers maken bij het inventariseren, selecteren of implementeren van een ERP-systeem. Daarnaast hebben deze experts tips over hoe organisaties mogelijke kostbare fouten kunnen voorkomen.   1. Geen vereisten verzamelen Het is heel gebruikelijk, én zeer verleidelijk -, om bestaande bedrijfsprocessen te automatiseren met een ERP-systeem. Hoewel dit conceptueel begrijpelijk is, moet je zeker de tijd en moeite nemen om die processen te analyseren als basis voor het opstellen van een nieuwe verzameling ERP-vereisten. Het implementeren van een nieuw ERP-systeem biedt de uitgelezen mogelijkheid om bedrijfsprocessen te identificeren en vooraf te verbeteren. Immers, het automatiseren van een slecht proces maakt deze alleen sneller, maar zeker niet effectiever. Daarom is het belangrijk om bedrijf kritische problemen eerste te identificeren en aan te pakken alvorens er tot migratie wordt overgegaan. Hierdoor kunnen de nodige aanpassingen worden aangebracht aan achterhaalde, inefficiënte en complexe processen voordat ze eenvoudigweg op een nieuw platform worden verplaatst.   2. Het níét meenemen van eindgebruikers (van alle afdelingen) in het besluitvormingsproces Bij het implementeren van een ERP-systeem steken degenen die betrokken zijn bij de implementatie veel van hun tijd en moeite in het verkrijgen van goedkeuring van het management. Bedrijven zouden daarentegen eigenlijk veel aandacht moeten besteden aan het betrekken van medewerkers die het systeem uiteindelijk het meest zullen gebruiken. Het is cruciaal om niet alleen werknemers van IT te betrekken, maar alle belanghebbenden vanuit de gehele organisatie; van zowel de afdelingen financiën, marketing & sales als productie. Door stakeholders in de gehele organisatie in elke stap van het besluitvormingsproces te betrekken, zorgt een organisatie ervoor dat iedereen zich betrokken voelt, wat leidt tot meer draakvlak. Hierdoor zal er minder weerstand ontstaan tegen een ingrijpende verandering zoals de implementatie van een ERP-systeem. Daardoor wordt het vinden, het implementeren en het gebruik van de juiste oplossing een integraal proces met een maximaal rendement.   3. Niet goed budgetteren van technisch personeel Beslissers onderschatten vaak de uitgaven die gemoeid gaan met een implementatie van een ERP-systeem. Bij het vaststellen van het budget moet minimaal rekening worden gehouden met onderhoud en het kennisniveau dat nodig is om het project succesvol te implementeren. In gevallen waarin organisaties proberen meer te bereiken met minder, resulteert dat veelal in mislukte implementaties. Daarom is het belangrijk om goed de tijd te nemen voor de begroting. Rekening houden met het de implementatie betrokken resources en het benodigde kennisniveau, zodat zich (later) geen problemen of verrassingen voordoen, is hierbij cruciaal.   4. Overwegen van de voor- en nadelen: on-premise vs. cloud-based ERP Voordat gekozen wordt tussen een on-premise en cloud-based ERP-oplossing, moeten bedrijven verschillende factoren evalueren. Een cloud-implementatie vereist bijvoorbeeld goede internetverbindingen en biedt voordelen aan werknemers die op afstand werken. Aan de andere kant vereist de inbedrijfstelling op locatie een toegewijd IT-personeel lid en in-house hardware die geschikt is om de software op eigen servers te hosten. Software-as-a-service neemt een vogelvlucht en lijkt het belangrijkste platform voor nieuwe ERP-implementaties te worden. Dit komt voornamelijk door meer flexibiliteit, kosten efficiëntie en snel op- en afschalen. SaaS kan daarom vaak lijken op de perfecte oplossing voor organisaties die moeilijke implementaties hebben ondervonden of moeite hebben gehad om hun eerdere ERP-investeringen te ondersteunen. Hoewel SaaS veel voordelen biedt, moeten klanten de nieuwe organisatorische uitdagingen die SaaS kan veroorzaken wel begrijpen en aankunnen. Omdat SaaS-oplossingen niet altijd kunnen worden aangepast, worden gebruikers gedwongen om bedrijfsprocessen aan te passen aan de software. Deze proceswijzigingen hebben vaak gevolgen met legacy-systemen. Gevolgen zijn onder andere ontbrekende documentatie, datavervuiling tussen proces en data en is het wijzigen van bedrijfsprocessen een ingrijpende operatie. Daarnaast moeten organisaties met unieke functionele of bedrijfsspecifieke vereisten een structuur en aanpak hebben om de noodzakelijke functionaliteit aan te pakken die niet door het nieuwe systeem wordt geleverd, door middel van work-arounds, software van derden of alternatieve middelen.   5. In één keer het systeem implementeren ERP-systemen zijn complex, en het is niet mogelijk om alle implementatie-eisen aan de voorkant vast te stellen, vervolgens het systeem te implementeren, gebruikers te trainen en live te gaan. Dit is het traditionele waterval methode en het werkt niet. Deze methode werkt namelijk niet omdat na elke stap erdoor wordt gegaan met de volgende stap en er in principe niet meer teruggegaan kan worden naar een eerdere stap om fouten te verbeteren. Nadelen van de waterval methode zijn dan ook dat het lang duurt voor er resultaten zichtbaar zijn, en als ze dan zichtbaar zijn, ze moeilijk te herstellen zijn. In plaats daarvan moet een meer flexibele aanpak worden genomen, waarbij de implementatie in kleine stappen wordt uitgevoerd met de betrokkenheid van eindgebruikers om eisen te bepalen, te testen, ontbrekende functionaliteit te vinden en dit vervolgens te herhalen.   6. Negeren van change management Change management is een absolute vereiste bij het implementeren van een nieuwe ERP-oplossing. Het vermogen om zo’n verandering effectief te beheren, kan heel goed de belangrijkste vaardigheid zijn die leidinggevenden, managers en medewerkers moeten beheersen. Bedrijfstransformaties zoals de implementatie van een ERP-systeem kunnen niet (succesvol) plaatsvinden zonder drie belangrijke organisatorische gebieden effectief te beheren: mensen, processen en technologie. Al te vaak kijken organisaties alleen naar de IT-technologie om bedrijfsactiviteiten te verenigen, stroomlijnen en vereenvoudigen. Hoewel processen en systemen een diepgaande analyse vereisen, is de menselijke factor vaak nog kritischer tijdens een (cloud-)ERP-migratie. Zelfs cloud-based ERP-oplossingen vereisen change management.   7. Niet regelmatig communiceren van informatie (vooral over afdelingen) Om dit probleem te voorkomen, is het creëren van een projectcommunicatieplan voor alle fasen van het project van groot belang. Een klein kernteam aanstellen, - samengesteld uit individuen uit verschillende afdelingen - die goed communiceren met iedereen, die beïnvloed wordt door de nieuwe oplossing -, vormt hierbij zeker geen overbodige luxe. Het team zal ervoor zorgen dat zij te allen tijde volledig op de hoogte blijven van de voortgang van het project en op hun beurt alle betrokkenen in de betreffende afdelingen op de hoogte houden. Met dit in gedachten is het gebruik van een software platform om de beoogde communicatie en gewenste samenwerking te ondersteunen een absolute must.Auteur: Roderick Vos | MavimBenieuwd hoe Mavim de voorspelbaarheid vergroot van de impact en kosten van een applicatie-implementatie? Download de factsheet over het implementeren van bedrijfskritische applicaties met Mavim. Of bekijk de video over applicatie implementatie management en het AIM framework.

Inhoud De resultaten van zeer grote ICT-projecten laten nogal eens te wensen over, blijkt uit onderzoek. Slechts zeven procent is een succes. Hoe komt dat? En wat kunnen we leren? Door: Hans Mulder en Theo Mulder   In de afgelopen decennia verschenen met enige regelmaat berichten in de pers over problemen met automatiseringsprojecten. Sommige van die projecten zijn zelfs compleet mislukt. Met name de resultaten van zeer grote ICT-projecten laten te wensen over. Bij die projecten treden effecten op die te vergelijken zijn met onder meer de Deltawerken, de HSL of de Noord-Zuidlijn. Kennelijk gaat de complexiteit van dit type projecten het organisatievermogen van mensen te boven. Er zijn sinds de jaren zestig verschillende onderzoeken uitgevoerd naar de oorzaak van het mislukkingen van IT-projecten. Daar is uiteraard lering uit getrokken, maar door de enorme ontwikkeling die de IT de afgelopen decennia heeft doorgemaakt, is onderlinge vergelijking van projecten lastig. Ook omdat de aard en de scope van ICT-projecten ingrijpend zijn veranderd. Dat heeft ertoe geleid dat men zich met elk nieuw IT-project op nieuw en onbekend terrein heeft begeven. Aan het mislukken van IT-projecten hebben daardoor steeds andere oorzaken ten grondslag gelegen. Wat echter in de publieke opinie blijft hangen is dat de dienstverlening van de ICT-sector ondermaats is. Men beschouwt automatiseringsprojecten als zeer risicovol. Dit is een ongenuanceerde voorstelling van zaken, die heeft gezorgd voor een slechte reputatie van IT’ers, omdat vaak te makkelijk wordt verondersteld dat zij die problemen hebben veroorzaakt.   Meerjarig marktonderzoek Hoe lastig het ook is om IT-projecten verspreid over een aantal decennia met elkaar te vergelijken, er is wel degelijk lering uit te trekken. Met name uit grootschalig statistisch marktonderzoek kunnen waardevolle conclusies worden getrokken. Het zou daarom goed zijn dat bedrijven hun plannen aan dat soort onderzoek toetsen om daarmee een betere inschattingen te kunnen maken over de slaagkans van hun toekomstige projecten. Het marktonderzoekbureau Standish Group International doet sinds 1985 onderzoek naar het slagen en falen van ICT-projecten. Dat gebeurt al sinds 1994 op basis van case studies. Inmiddels zijn meer dan tachtigduizend projecten geanalyseerd en op basis daarvan kunnen we de ‘overall’ ontwikkelingen ten aanzien van ICT-projecten aangeven. Het zijn projecten die zich voor de helft in ondernemingen in Amerika hebben afgespeeld en voor een kwart in Europa, de overige ICT-projecten hebben vooral betrekking op Azië, Australië en Canada. De projecten in de database zijn afkomstig van meer dan duizend organisaties, waarvan vijftig procent grote, dertig procent middelgrote en twintig procent kleine bedrijven. De onderzochte projecten worden ingedeeld in drie categorieën: geslaagd, mislukt en problematisch. ‘Geslaagd’ betekent dat een project binnen de planning en begroting is afgesloten. ‘Mislukt’ wil zeggen dat het beoogde systeem niet in gebruik is genomen. De projecten die niet ‘geslaagd’ of ‘mislukt’ zijn, worden ‘problematische’ projecten genoemd. Deze duren langer dan gepland, kosten meer dan gebudgetteerd en bieden minder functionaliteit en/of kwaliteit dan overeengekomen en/of verwacht.   Het mislukken wordt voor 64 procent toegeschreven aan problemen in organisatie en communicatie   Zeer grote projecten Uit het langjarig onderzoek van de Standish Group wordt duidelijk dat het met name de zeer grote IT-projecten zijn waar problemen ontstaan. Wanneer die projecten buiten beschouwing worden gelaten, zien we een aanzienlijk positiever beeld. Van alle projecten met een omvang van minder dan één miljoen dollar aan arbeidskosten die in 2010 zijn uitgevoerd wordt slechts vier procent als mislukt bestempeld. Daar steken de grote projecten heel negatief bij af, want van de IT-projecten met arbeidskosten van meer dan tien miljoen dollar mislukte in 2010 liefst 44 procent. Het aantal problematische projecten in deze categorie bedroeg 49 procent. Daaruit kunnen we concluderen dat slechts zeven procent van de projecten als geslaagd kan worden aangemerkt. Dat is overigens wel een verbetering ten opzichte van vorige jaren, waarin geen enkel project van deze omvang volgens planning en begroting kon worden afgesloten.   Figuur 1. Oorzaken van mislukken ICT-projecten   Waarom mislukken ICT-projecten? Bij de statistische analyse van mislukte en van problematische IT-projecten (2010) kwam duidelijk tot uiting welke oorzaken in welke mate hebben bijgedragen tot het mislukken (figuur 1). Voor 64 procent wordt dit toegeschreven aan problemen op het gebied van organisatie en communicatie. ICT-gerelateerde kwesties zijn voor 36 procent debet aan het mislukken.   Eenvoud in complexiteit Nu bekend is wat de werkelijke faalfactoren zijn en in welke mate ze zich voordoen, is het mogelijk vooraf een complexiteitsfactor aan te geven en daarmee het risico van een te starten ICT-project te bepalen. De grootste complexiteitsfactor is de schaalgrootte, omvang of scope van een project. Dat is geen onverwachte uitkomst. Al tientallen jaren is bekend dat grote projecten ook grote risico’s met zich meebrengen, en dat is voor IT-projecten niet anders. Voor die laatste geldt echter dat nooit eerder duidelijk was hoe groot de risico’s precies waren. Evenmin is er veel aandacht besteed aan de onderlinge verhouding tussen succes- en faalfactoren. Op basis van langdurig statistisch onderzoek kan ook dat verband onder de loep worden genomen.  Figuur 2. Complexiteitsonderdelen   Complexiteit van ICT-projecten kan in drie onderdelen worden verdeeld (figuur 2), die elkaar onderling beïnvloeden: omvang van de onderneming, omvang van het te implementeren informatiesysteem en omvang van het project. In de figuur staan per onderdeel in een kader nog de ‘extra complicerende factoren’ aangegeven. De omvang van de onderneming is van grote betekenis voor de complexiteit van een project, want kleine projecten bij grote ondernemingen scoren slechter dan vergelijkbare projecten in het MKB. De omvang van een project kan het best worden aangegeven aan de hand van het aantal projectleden dat gemiddeld per maand aan het project heeft gewerkt of gaat werken. Vaak is het eenvoudiger om vast te stellen wat de arbeidskosten van eigen en ingehuurde medewerkers zijn (geweest). Hoe groter het project, hoe groter de kans op uitloop of mislukking. De omvang van het te ontwikkelen systeem kan worden aangegeven met het aantal te ontwikkelen ofwel te implementeren functies en het aantal (toekomstige) gebruikers. Duidelijk zal zijn dat wanneer alle drie de complexiteitsonderdelen maximaal zijn, de kans levensgroot is dat het IT-project onbestuurbaar wordt. Los van deze drie primaire complexiteitsfactoren spelen ook de ‘kwaliteit van de specificaties’ en de vraag of het om een ‘basistoepassing’ gaat of om een volledig nieuwe applicatie een belangrijke rol. Wanneer een systeem niet volledig of onjuist is gespecificeerd, heeft dat onmiddellijk repercussies voor de planning, kosten en kwaliteit. Gaat het om een financieel informatiesysteem dat al vaker is geïmplementeerd, dan is dat veel eenvoudiger dan een informatiesysteem waarmee geen of weinig ervaring is opgebouwd.   Complexiteitsmatrix In 2011 publiceerde Standish een studie naar complexiteit van ICT-projecten (figuur 3). De redenen van mislukking die het meest werden vermeld, zijn gecorreleerd met de projectsysteem- en ondernemingsaspecten. De resultaten zijn opgenomen in de complexiteitsmatrix. Die maakt is het mogelijk om ICT-projecten in te delen in 25 complexiteitscategorieën. Met behulp van deze matrix kan van een te starten, lopend, afgesloten of afgebroken ICT-project worden vastgesteld of het gaat om een eenvoudig dan wel zeer gecompliceerd project. Een dergelijke objectieve vaststelling is nuttig in discussies tussen opdrachtgevers en opdrachtnemers.  Figuur 3. Complexiteitsmatrix   Met behulp van de complexiteitsmatrix kan worden bepaald hoe complex een bepaald ICT-project is. De meest dominante complexiteitsfactor is de omvang (figuur 3). In figuur 3 is deze omvang op de y-as beperkt tot de projectomvang op een schaal van 1 tot en met 5. S1 (seize) staat voor arbeidskosten van minder dan één miljoen dollar en S5 voor meer dan tien miljoen dollar. Ondernemingsomvang en systeemomvang kunnen afzonderlijk worden meegewogen.  In het onderzoek bleek dat toename van deze complexiteitsonderdelen bijna altijd een toename van de projectomvang tot gevolg had. De factoren op de x-as C1 tot en met C5 staan voor extra complexiteit. De vaststelling daarvan vloeit voort uit de antwoorden van een beperkt aantal essentiële vragen. De cellen van de matrix bevatten een complexiteitsgetal lopend van 100 (zeer eenvoudig) tot 1000 (zeer complex). Met behulp van deze methode kan objectief de complexiteit worden vastgesteld van een te starten project (op basis van de state of work, blue print, planning, budget) en van lopende/afgesloten/afgebroken projecten. De keuze van de schaalgrootte (minder dan één miljoen tot meer dan tien miljoen) is het gevolg van de omvang van de onderzochte ICT-projecten. Het is goed mogelijk om deze matrix te vertalen naar een complexiteitmatrix voor het MKB, voor een specifiek softwarehuis of voor grote ondernemingen met veel ICT-projecten.   Projectaanpak ICT-projecten worden vaak gestuurd vanuit een projectorganisatie die naast de staande organisatie van een onderneming opereert. De klassieke inrichting van een projectorganisatie bestaat uit een stuurgroep, verschillende deelprojectgroepen en werkgroepen bestaande uit gebruikers uit de organisatie en ICT’ers. Voor kleine projecten is deze organisatievorm vaak te zwaar en voor zeer grote projecten niet altijd adequaat. Bedrijven/softwarehuizen zweren meestal bij een en dezelfde projectaanpak voor alle uit te voeren ICT-projecten. Grote moderniseringsprojecten (transformeren en aanvullen van bestaande sourcecode) zijn minder complex, omdat de uitvoering daarvan in hoge mate onafhankelijk van de bestaande organisatie kan plaatsvinden. Complexe ICT-projecten (met complexiteitsgetal 750 en hoger) vereisen de grootst mogelijke bestuurlijke aandacht en de best mogelijke professionele bemensing.   Cold cases De toegelichte complexiteitsbenadering is een belangrijk hulpmiddel om de meest geëigende aanpak van ICT-projecten vast te stellen. De benadering kan (mede) een hulpmiddel zijn om afgesloten en afgebroken projecten te analyseren. Dat kan gebeuren door zo’n ICT-project te onderwerpen aan een complexiteitsonderzoek. Verder kan met behulp van de database van tachtigduizend projectresultaten het betreffende project vergeleken worden met soortgelijke projecten uit de tijd waarin dat ICT-project werd uitgevoerd. Deze exercitie lijkt enigszins op het onderzoek van ‘cold cases’, zoals de politie die met onder meer de DNA-kennis van nu uitvoert bij onopgeloste zaken. Wij zullen binnenkort ons onderzoek naar enkele cold cases afronden en onze bevindingen publiceren. Prof. lec. dr. ing. Hans Mulder MScBA bekleedt verschillende bestuurs- en adviesfuncties in het bedrijfsleven en in het hoger en wetenschappelijk onderwijs. E-mail: hans.mulder@viagroep.nl Prof. Theo Mulder was mede-oprichter en directeur van Minihouse (1974) en eerste bestuursvoorzitter Multihouse NV (tot 1989). E-mail: theo.mulder@inventive.nl   > Lees hier hoe je in 10 stappen een ERP-systeem succesvol implementeert> Lees hier hoe Mavim jouw organisatie kan helpen om je ERP/CRM-implementatie te versoepelen, versimpelen en voorspelbaarder te maken