Ik kwam vandaag een aardig artikel tegen over valkuilen die (Amerikaanse) bedrijven zijn tegen gekomen bij de implementatie van een leermanagement systeem (LMS). Het artikel is gebaseerd op een onderzoeksrapport van Bersin & Associates. Er worden vier clusters van valkuilen onderscheiden.
In de eerste plaats blijken gebruikers niet tevreden met de data analyse mogelijkheden van een LMS. Managers willen een LMS graag gebruiken om bijvoorbeeld de vorderingen van medewerkers te kunnen volgen. Ik heb de indruk dat de cultuur van Nederlandse bedrijven hierin verschilt van de cultuur van Amerikaanse (en internationaal opererende?) bedrijven. Nederlandse managers hebben wellicht minder behoefte hebben aan een (achter)volgsysteem van medewerkers.
Een tweede valkuil wordt gevormd door de specifieke gebruikerswensen, die maatwerk vereisen. Eindgebruikers willen dat een LMS aangepast wordt aan de bestaande werkprocessen. Dit leidt vaak tot complexe, tijdrovende en dus dure implementaties. Het is vaak eenvoudiger en goedkoper om werkprocessen aan te passen aan een LMS. Bij de invoering van pakketten voor enterprise resource planning (ERP) is dat heel gebruikelijk.
Valkuil drie is dat klanten vaak in één keer over alle functionaliteiten willen beschikken. Daardoor duurt de implementatie lang. Beter is het om een LMS stapsgewijs in te voeren, waardoor gebruikers op kortere termijn over bepaalde functionaliteiten kunnen beschikken.
De vierde en laatste valkuil zijn tegenstrijdige gebruikerswensen. Verschillende afdelingen kunnen wensen hebben ten aanzien van functionaliteiten, die haaks op elkaar staan: "when you try to please everyone you fail to please any one", aldus de auteur. Denk daarbij aan het proces van het geven van toestemming voor het inschrijven voor een training.
Met name de laatste drie valkuilen vind ik wel herkenbaar. Het valt me overigens op dat de gebruikersacceptatie niet als valkuil wordt genoemd. Dit zou ook kunnen liggen aan de bedrijfscultuur. Als het management uiteindelijk besluit om een LMS te gebruiken, dan volgen de emdewerkers in een (Amerikaans?) bedrijf.
This content is published under the Attribution 3.0 Unported license.
Beste Wilfried,
Leuk dat je ook het artikel Chris Howard hebt gevonden. Ik had eigenlijk ook nog al wat punten waar ik het niet mee eens was.
Altijd maar terug vallen op voorbeelden van de bekendere namen onder de LMS leveranciers (IBM, Oracle, C2L). Het is het echt de moeite waard iets verder te kijken dan alleen maar naar de bekendere namen.
Er zijn systemen die de features hebben of die zodanig flexibel zijn dat die features zo bij te zetten zijn zonder een grote rekening voor ’tig’ mandagen werk. Je zou haast denken dat de systemen van de bekendere namen erg inflexibel zijn ontworpen waardoor aanpassingen aan het systeem erg tijdrovend en duur zijn.
Rapportages uit een LMS zijn een vereiste: hoe flexibel is een LMS op dat gebied? Geeft het LMS de gelegenheid aan de managers zelf hun rapportage te ontwerpen? (zou eigenlijk een standard feature moeten zijn). Daarnaast is het mogelijk al aanwezige tools zoal Cristal Reports/Business Object toegang te geven tot de LMS database?
Het ontwikkelproces van een leverancier. Hoe flexibel is dat? Je kunt het bijna niet voorkomen dat er interne conflicten ontstaan ten aanzien van de gewenste functionaliteit. Wat is er mis mee meerdere functionaliteiten beschikbaar te stellen op basis van het gebruikersprofiel? Je kunt ze naast elkaar testen in een pilot, is er geen eenduidige keuze biedt je ze toch beide mogelijkheden.
Ik denk dat wij een aantal van deze ‘valkuilen’ hebben voorkomen door de architectuur van het product flexibel te maken. Daardoor is het mogelijk aanpassingen snel te realiseren in een fractie van de tijd dan normaal mogelijk zou zijn, door gebruik te maken van een part stuk software voor de aanpassingen van het LMS (Customization Toolkit). Ook onze klanten kunnen hierop worden opgeleid.