In den vergangenen zwei Jahren hat das digitale Lernen im deutschsprachigen Raum einen enormen Auftrieb erhalten und viele Unternehmen sind entweder neu in das Thema eLearning eingestiegen oder haben bisherige Maßnahmen ausgebaut. Um das digitale Lernen allerdings langfristig zu etablieren, müssen nachhaltige Strukturen geschaffen werden, was in der Regel die Anschaffung und Implementierung von entsprechenden Bildungstechnologien bedeutet. In dem nachfolgenden Artikel möchte ich Ihnen ein paar Tipps und Hinweise mitgeben, wie man diesen Prozess erfolgreich gestalten kann.
Wer in einigen Jahren in einer unaufgeregten Reflektion auf die Folgen der Ausbreitung des Corona-Virus blicken wird, kommt hoffentlich zu der Erkenntnis: „Never waste a good crisis.“ (Sir Winston Churchill). Dies gilt im besonderen Maße für den Bildungs- und Weiterbildungsbereich zwischen Nordsee und Alpen. Aus meinen Erfahrungen als Projektmanager und Administrator von verschiedenen Anwendungen zum digitalen Lernen und Lehren möchte ich einige Anregungen geben, welche den Kauf solcher Technologien planvoller und damit nachhaltiger gestalten. Die Art der E-Learning-Anwendung ist nicht erheblich für die Betrachtung. Wenn ein LMS, eine LXP, ein Autorentool, ein Webinartool oder ein Kollaborationstool angeschafft und eingeführt werden soll, sind alle nachfolgenden Punkte in unterschiedlicher Gewichtung zu beachten. Jede geplante Einführung einer neuen Technologie für das digitale Lernen stellt ein Projekt dar. Dies ist eine Grundannahme. Somit leiten sich die nachfolgenden Punkte ab.
1. Projektvorbereitung
Der Erfolg der Einführung von neuen IT-Anwendungen hängt im wesentlichen Teil von der ersten Phase ab. Beginnend mit einem umfassenden Stakeholder-Management sind die Projektmitarbeiter*innen der einzelnen Projektphasen zu bestimmen, damit deren Kapazitäten eingeplant werden können. Gleichzeitig sind die wesentlichen Rollen des Projektes zu besetzen (Projektleitung, Projektkommunikation, Fachprojektleiter, IT-Projektleiter). Spätestens in diesem Moment ist zu klären, ob das benötigte fachliche, methodische und / oder technische Knowhow in der Organisation vorhanden ist, zeitnah intern aufgebaut werden kann oder extern zugekauft werden muss. Fehlende Expertise oder der fehlende Einfluss der Experten in Entscheidungsprozesse kostet vielen solcher Projekte viel Geld und führt oft zum Scheitern. Nun ist der bereits formulierte Projektauftrag – Auslöser der Vorbereitungsphase – genauer zu betrachten, um daraus Projektziele (Empfehlung: kompromisslose Nutzung der S.M.A.R.T.-Methode) abzuleiten und eine Meilensteinplanung und grobe Budgetplanung anzulegen. Die Projektziele sollten auch und insbesondere die Business Cases abbilden (Steigerung der Qualität, der Umsätze, der Mitarbeitenden-Zufriedenheit u.ä.)
2. Grobkonzeption
In dieser Phase bilden die vier Dimensionen (Allgemeine, Funktionale, Technische, Organisatorische & Fachliche Dimension) die Grundlagen der zukünftigen Auswahl oder Entwicklung der entsprechenden IT-Anwendung. Dabei lege ich in den jeweiligen Dimensionen keinen Anspruch auf Vollständigkeit der Parameter. Insbesondere im Bereich der Fachlichkeit sind die betroffenen Kernprozesse und Richtlinien der Organisation detaillierter zu definieren. Die Mehrzahl der Projekte scheitert, da innerhalb der Organisationen häufig keine kritische Instanz in solchen Projekten implementiert oder geduldet wird. Aus diesen Erfahrungen heraus empfehle ich die Bildung eines unabhängigen Boards, welches regelmäßig mit dem Kernteam Feedbackrunden absolviert. Dieses wird mit einer kleinen Anzahl von schonungslos ehrlichen Mitarbeitenden besetzt, welchen scheinbar der „Respekt“ vor Hierarchien, bestehenden Prozessen und / oder das „Verständnis“ für organisationsinternes, politisches Geplänkel fehlt.
Nachdem das Projektteam die Parameter der vier Dimensionen bestimmt hat, bilden diese die Grundlage für die Gewichtung der Parameter nach deren Notwendigkeit. Zum Beispiel: Eine Schnittstelle zur Personalsoftware (technische Dimension) muss bidirektional funktionieren. Diese Anforderung ist a) nicht erforderlich, b) ein nice to have, c) ein must have oder stellt bei Nichtvorhandensein d) ein knock out dar. Oder in der Anwendung können Nutzertypen (Rollen und deren Rechte) individuell erstellt werden. Das letztgenannte Beispiel eines Anforderungsparameters spielt in einer QuizApp wahrscheinlich eher eine untergeordnete und in einem Autorentool keine Rolle.
Ein spezieller Tipp für den Parameter „Referenzen“ der „Allgemeinen Dimension“ besteht in der Bildung zweier Gruppen. Die eine Gruppe wird durch die Information bzw. Nennung seitens der Anbieter gebildet und die zweite Gruppe als eine Art Kontrollgruppe wird durch eigene Recherche zum Beispiel in Anwenderforen oder sozialen Netzwerken gebildet. Grundlage dafür bildet die Annahme, dass mir ein Anbieter nicht unbedingt seinen größten Kritiker als Referenz nennen wird. Solche kritischen Stimmen sind für ein breites Spektrum notwendig.
3. Softwareauswahl
Die Auswahl der Anwendung erfolgt anhand fünf anerkannter Parameter. Erstens weist der Anbieter einen regelmäßigen und geplanten Zyklus neuer Entwicklungen vor und hat Änderungen von technischen Grundlagen (neue php-Version, Änderung der App-Pakete im Google PlayStore o.ä.) im Blick. Zweitens können Anwender – unabhängig ob Administratoren oder „normale“ User – aufgrund einer möglichst intuitiven Oberfläche schnellstmöglich einen sicheren Umgang mit der Software entwickeln. Dies schafft eine Akzeptanz. Drittens werden Anfragen und / oder technische Probleme in einem zufriedenstellenden zeitlichen und fachlichen Rahmen beantwortet bzw. gelöst. Viertens wird betrachtet, wie die User auf die Anwendung Zugriff erhalten. Benötigt jeder User oder jedes Anwendergerät eine eigene Lizenz? Wird von Desktoprechnern oder auch mobilen Endgeräten zugegriffen? Handelt es sich um eine lokale Anwendung auf den Endgeräten oder eine Webanwendung? Der fünfte und letzte Parameter betrachtet den Reifegrad der Anwendung. Eine große Anzahl nutzender Organisationen bedeutet neben dem bereits vorhandenen Reifegrad auch einen größeren Hebel bezüglich der Weiterentwicklung neuer Features und Ausweitung der Einsatzmöglichkeiten.
Meine ausdrückliche Empfehlung ist eine längere, tiefergehende Testphase eines Piloten.
4. Umsetzung und Einführung
Auch wenn der Kauf auf den ersten Blick abgeschlossen scheint: In dieser Phase ist für die Einführung der jeweiligen Anwendung ein eigenes Teilprojekt hilfreich. Denn hier wird oft die Akzeptanz der Nutzer verspielt, da zum Beispiel die Anwender- und Rollenkonzepte nicht sauber definiert sind. Dazu erfolgt der Rückgriff auf die unter 2. definierte Matrix und deren Ergebnisse. Dabei sind die Fachkonzepte für eine Umsetzungsfähigkeit feiner auszuarbeiten, Schulungen zu planen und durchzuführen. Auch mit Blick auf zukünftige Weiterentwicklungen und die Notwendigkeit des Einspielens von Sicherheitsupdates ist der Aufbau von unterschiedlichen Instanzen (Entwicklungs- , Abnahme- und Produktivumgebung) ratsam. Fehler in den ersten beiden Instanzen sind wünschenswert.
5. Laufender Betrieb
Es kommt der Tag des Go-Live. Ab diesem Ereignis wird der speziell geschulte Support benötigt. Die Geschwindigkeit und Ergebnisse der Lösungen von Problemen entscheiden maßgeblich über die Akzeptanz der Anwendung bei den Lernenden. Viele der typischen Anfragen können vorab über FAQs, Handbücher und / oder How-To-Videos abgefangen werden. Unter Umständen hat der gewählte Anbieter hier bereits Content zur Nutzung parat. Oft sorgt die Einführung solcher Anwendungen für eine Beeinträchtigung der Komfortzone. Häufig hörte und las ich in diesem Zusammenhang Äußerungen wie: „Das haben wir bisher aber anders gemacht.“ Dies ist ein Ausdruck der hinterliegenden Anforderung eines Change im bisherigen Prozess. Hier gilt, dass Führungskräfte eine sichtbare Vorbildfunktion leben müssen und Multiplikatoren einbeziehen. Ein Einbezug, welcher auch für Verbesserungsvorschläge seitens der Nutzer zu leben ist. Unter Umständen besitzt die Anwendung integrierte Tools und Prozesse, um solche Vorschläge strukturiert abzufragen und mit den notwendigen Daten angereichert, an den Anbieter zur Weiterentwicklung zu geben. Bei aller Projektplanung gilt, die Erfahrungen werden ausschließlich durchs Handeln erzielt. Oder mit den Worten von Herbert Spencer: „The great aim of education is not knowledge, but action.“
Drei abschließende und extrem wichtige Tipps zum Erwerb von E-Learning Anwendungen: 1. Keine Anwendungen anschaffen, die ich nicht kenne. 2. Keine Anwendungen anschaffen, die ich nicht anwenden kann. 3. Keine Anwendungen anschaffen, die ich nicht beherrsche.
Der Autor:
Tino Roth
ist zertifizierter Digital Learning Designer der Universität Stuttgart. Nach einem Lehramtsstudium und einer Ausbildung in der Versicherungswirtschaft wirkte der 1973 geborene Autor viele Jahre als Fachtrainer für die Ausbildung von Versicherungs- und Finanzanlagenfachmann/-frau für die Swiss Life Deutschland Vertriebsservice GmbH und verantwortete die Aktualisierung, Weiterentwicklung und Professionalisierung der virtuellen Lernangebote sowie die Integration in bestehende Systeme des Personalmanagements. Seine Expertise bringt er seit Anfang 2019 in diversen Projekten innerhalb der EOS Group ein und freut sich, die Themen Digitalisierung, Change und Learning begleiten zu dürfen.
Kontakt:
Tino Roth
DB Training, Learning & Consulting
Solmsstraße 8-18
D-60486 Frankfurt a. Main
