Iedereen kent ze wel, die implementaties die zichzelf moeizaam naar de finish slepen. Je voelt aan alles dat die implementatie geen doorslaggevend succes zal worden. Welke basale vuistregels zijn er dan geschonden?
Instemmen en uitdragen van het Management Team.
Eén van de meest belangrijke basisregels is dat het management team (mt) met de oplossing moet instemmen. Als het mt niet instemt dan zweeft het project tussen realiteit en hoop waarbij hoop de overhand heeft. Zo’n project dat alleen gedragen wordt door het projectteam en daarbuiten door niemand zal eindigen in desillusie. Het mt zal daarom formeel moeten instemmen en het besluit niet alleen moeten vastleggen in notulen, zij zal het ook actief moeten uitdragen. Het mt zal zelf de oplossing moeten ‘verkopen’ aan de organisatie waaraan zij leiding geeft. Zien en laten zien dat het mt achter de oplossing staat zodat de gehele organisatie één doel heeft of één middel om dat doel te bereiken. Wat is een sterker argument dan dat het mt zelf toont dat zij gebruik maakt van de oplossing?
Instemmen en meewerken van de gebruikersgroep.
Een oplossing kan niet tot stand komen zonder een gebruikersgroep. Selecteer daarom uit de vele gebruikers een groep die ervaren is. Laat de groep een goede afstemming zijn van de organisatie en betrek deze groep van begin tot eind intensief in het traject. Deze groep van materie-deskundigen weet tot in detail wat de dagelijkse werkzaamheden omvatten. Zij zijn daarom bij uitstek geschikt om de oplossing te bedenken of te toetsen op geschiktheid. Na de bouw kunnen zij deelnemen in het testen, het opstellen van gebruikersdocumentatie en fungeren als eerste hulp tijdens de eerste dagen van de productiegang.
De gebruikersgroep moet niet een groep op zichzelf worden, zij zijn en blijven tenslotte een deel van de organisatie. De gebruikersgroep houdt nauw contact met de organisatie door te communiceren over de oplossing en advies te vragen. Hierdoor ontstaat draagvlak voor de uiteindelijke oplossing.
Oplossing beschikbaar stellen en blokkeren van alternatieven
De oplossing moet zo bedacht zijn dat er een generieke werkwijze is. De gehele organisatie werkt met de oplossing op dezelfde wijze. Hierdoor vervallen andere werkwijzen of sterker: andere werkwijzen moeten niet meer worden getolereerd. Hier komt de betrokkenheid en de steun van het mt weer in beeld. Een voorbeeld in het werkveld van ecm: documenten worden in het nieuwe ecm-systeem opgeslagen. Documenten worden niet meer op lokale of netwerk directories opgeslagen, geprint en in kasten opgeslagen, in eigen gemaakte MS Acces-databases opgeslagen of in e-mail programma’s. Het klinkt logisch maar onderschat de ingesleten praktijk in organisaties niet, ‘mijn oplossing werkt, die van jou moet zich nog bewijzen’ of ‘ik kan toch alles vinden’.
Met het wegnemen van alternatieven is de organisatie nog niet gediend. De nieuwe oplossing moet werken! Het moet de werkzaamheden ondersteunen, vereenvoudigen en tot een feest maken om er mee te werken. De oplossing moet ook beschikbaar zijn voor iedereen die er mee moet werken. Ook hier een voorbeeld: als alle inkomende post gedigitaliseerd wordt dan moet iedereen in de organisatie toegang hebben tot zijn gedigitaliseerde post. De oplossing werkt niet als slechts een deel van de organisatie toegang heeft.
De oplossing zelf
De oplossing zelf dient eenvoudig te zijn. Liever een oplossing met een paar knoppen die de werkzaamheden ondersteunen dan een oplossing met honderden mogelijkheden waardoor elk overzicht ontbreekt en het een doolhof is. De oplossing dient intuïtief te werken. Een mooi voorbeeld is de zoekmachine van Google. Iedereen in de wereld werkt ermee maar ik ben nog niemand tegengekomen die er een cursus van een dagdeel over heeft gehad. Of neem de app’s op mobiele apparaten: welke app heeft een gebruiksaanwijzing van meer dan tien pagina’s? Een niet te onderschatten voordeel hebben intuïtief te gebruiken oplossingen in een organisaties met een hoog personeelsverloop.
Daarnaast moet ook de valkuil van veel maatwerk genoemd worden. Gebruik in eerste instantie de standaard oplossing. In de afstemming met de gebruikersgroep heb je dan een sterk argument: wat met de standaard oplossing kan wordt ondersteund en wat niet met de standaard oplossing kan, wordt niet ondersteund. Als het echt niet anders kan, zet dan pas maatwerk in. Vele implementaties zijn immers verzand in maatwerk met als gevolg overschrijding van budget en tijd. Bedenk ook dat de standaard oplossing, standaard onderhouden kan worden. Bij upgrades heeft maatwerk speciale aandacht nodig.
Kortom: betrekt, van hoog tot laag, iedereen in de organisatie met verantwoordelijkheid en start eenvoudig: keep it stupid simple!
Er is overigens een goede handleiding en instructies beschikbaar ga daar een paar uurtjes mee stoeien, het verdient zich in een maand terug. Omdat je veel efficiënter en gerichter kunt zoeken.
Jammer genoeg wordt daar door excell sheet ridders anders over gedacht.
Ook een leuke: je kunt een image aangeven en vergelijkbare images zoeken. Misschien niet direct voor je werkt geschikt maar wel voor een leuk uurtje (het algoritme is nog niet erg goed)
Een aanbeveling als ‘andere werkwijzen moeten niet meer worden getolereerd’ begint wat mij betreft steeds meer achterhaald te raken. Zelfs in de geschetste gewenste situatie dat het MT instemt en actief uitdraagt, een ervaren gebruikersgroep enthousiast draagvlak creeert en de betreffende oplossing a la Google of mobiele apps werkt, heb ik moeite met een ‘wij weten wat goed is ‘ aanpak. Zolang je op cruciale momenten zorgt voor aansluiting met aanwezige bedrijfsbrede voorzieningen kunnen er best eigen keuzes worden gemaakt door de gebruikersorganisatie. Als er standaard oplossingen zijn niet via maatwerk, maar ik ken ook genoeg gevallen waarbij maatwerk een goede keuze was.
Er is natuurlijk niks mis met goede gedragen bedrijfsbrede voorzieningen, maar ik denk dat een just-enough aanpak het in praktijk steeds vaker wint van een all-in-one aanpak.
Randvoorwaarden opsommen voor een geslaagd project/implementatie is niet zo moeilijk. Daar hoef je bijv geen senior consultant voor te zijn.
Uitdaging zit erin hoe je de organisatie en project medewerkers kunt overtuigen/sturen. En voor zover dat niet lukt, hoe je daar mee omgaat om het project toch succesvol te laten worden.
Daar lees ik niets over in dit artikel.
Wat een gezwam weer.
Wel overal roepen dat je de nieuwste en beste oplossingen aanbied,
Maar als het er op aankomt blijf je gewoon vasthangen in oude rommel zodat je nergens moeite voor hoeft te doen.
Niet zo vreemd dat de ICT sector steeds verder inkakt.
Als je van de toekomstige gebruikers zelf te horen krijgt dat hun management er de ballen verstand van heeft, is vaak al een duidelijke waarschuwing dat het project gedoemd is te mislukken.
Het is de kunst om iets te maken waar de gebruikers op zitten te wachten zonder dat de rest (lees managers) zich inhoudelijk mee gaan bemoeien.
De ECM-IF (Implementation Framework) methode is een methode die specifiek is ontwikkeld om ECM projecten tot een goed einde te brengen. Hierbij wordt niet het wiel opnieuw uitgevonden worden best practices van verschillende ‘proven’ methodes gecombineerd. Binnen het framework gaat het niet alleen om techniek maar neemt juist de (gebruikers)organisatie en de acceptatie een van de belangrijkere plaatsen in. Daarnaast wordt ook de inbedding in de beheerorganisatie vanaf het begin van een ECM project meegenomen.