Bevor es losgeht: Einbeziehen der zukünftigen Anwender
Ist die Entscheidung für ein Programm gefallen, wird dieses nun Schritt für Schritt eingeführt. Das Vorgehen sollte wohl durchdacht sein, vor allem aber sollten neben den technischen Voraussetzungen, auch die sozialen Aspekte mit einbezogen werden. Das klingt ungewöhnlich für eine „Software“, macht jedoch den Unterschied aus, wenn die teils sehr tiefgreifenden Änderungen (Changemanagement) die mit einem Wissensmanagementsystem einhergehen, auch angenommen und genutzt werden sollen. Welche Überlegungen sollten in dieser Hinsicht berücksichtigt werden?
- Alle Beteiligten (bzw. Stakeholder) zu einem Kick-Off Meeting einladen. (Führungskräfte, Key-User, Projektmitarbeiter, Entscheidungsträger, IT-Verantwortliche)
- Planen der Systemressourcen, wie auch den Bedarf an IT-Personal bzw. erstellen eines Zeitplans = Wann sind die Ressourcen verfügbar?
- Gegebenenfalls: Einbeziehen eines externen Dienstleisters zur Projektbegleitung, fachlicher Unterstützung, Schulung und Support.
- Klärung der Lizenzmodelle und Kommunikation der Kosten ggü. den Entscheidungsträger.
- Previewtermin der neuen Software auf freiwilliger Basis für alle Mitarbeiter (Desensibilisierung).
- Regelmäßige Angebote zu Rückfragen der Nutzer, erweitern und prüfen der damit verbundenen Anforderungen.
- Fragen aller Nutzer zentral, aber anonym kommunizieren (Rundmail jeden Freitag) um Dopplungen zu vermeiden und Transparenz zu zeigen.
- Erarbeiten einer organisatorischen Struktur. (Wer ist wofür zuständig?)
- Erstellen eines Berechtigungskonzeptes.
- Vorlagen für die Erstellung von neuen Wissensdokumente konzipieren.
- Prozesse definieren (Erstellungs- und Freigabeprozess von Dokumenten, Wiedervorlage, Frequenz von Änderungen, etc.).
- Dokumentation aller getätigten Anpassungen im Einführungsprojekt – bestenfalls bereits im Stil des geplanten Wissensmanagementsystems.
- Erstellen erster FAQs, deren Inhalt sich bereits aus dem Proof of Concept ergeben hat oder sich beim Projektstart zeigt.
- Definieren der „Quick-Wins„
In vielen Fällen kann der Aufbau des „Prove of Concept“ direkt genutzt werden, um als Grundlage für das Produktivsystem zu dienen. Das erspart viel Arbeit, jedoch ist darauf zu achten, dass Testdaten zuvor gelöscht werden und auch der technische Aufbau „sauber“ durchgeführt wurde. Handelt es sich bspw. um eine temporäre Datenbank auf Basis eines Systems in einer lokalen virtuellen Umgebung, lohnt sich ein Neuaufbau.
Meinungsführer*innen, Unterstützer*innen, Key-User und misstrauische Nutzer*innen
Ziel sollte es sein, während der Einführungsphase so viele Nutzeranfragen, kritische Meinungen oder Diskussionen wie möglich zu erhalten, um frühzeitig auf Bedenken eingehen zu können, aber auch um berechtigte Kritik oder Anmerkungen in die endgültige Programmgestaltung einfließen lassen zu können. Es gibt keine wertvollere Informationsquelle als misstrauische Nutzer*innen. Dennoch muss abgewogen werden, ob es sich bei den eingehenden E-Mails, Gesprächen oder Treffen um berechtigte Kritik oder um reine Abwehrhaltung handelt.
Der Einführungsprozess sollte so gestaltet werden, dass die Key-User von Anfang an einbezogen werden. Dazu gehört nicht nur ein regelmäßiger Austausch über den aktuellen Stand, sondern auch intensives Testen und die Erstellung erster Inhalte. Je besser dieser Personenkreis in das Projekt eingebunden ist, desto einfacher gestaltet sich der spätere Rollout und desto geringer ist der Umfang der Supportanfragen an das IT-Team, gerade weil diese meist inhaltlicher Natur sind.
Neben den Key-Usern, die als Ansprechpartner für einen größeren Nutzerkreis dienen, sollten auch Meinungsführer*innen und Unterstützer*innen eingebunden werden. Um diese zu identifizieren, können die bereits erwähnten Präsentationstermine für die Software genutzt werden. Diese werden in der Regel von interessierten und wissbegierigen Kolleg*innen besucht, mit denen man schnell ins Gespräch kommt. Ziel der „Pflege“ von Key-Usern, Meinungsführern*innen und Unterstützer*innen sollte es sein, ein deutliches Gegengewicht zu den misstrauisch oder negativ eingestellten Personen zu erreichen, um den Projekterfolg nicht durch (teilweise einflussreiche) Quertreiber zu gefährden. Vor allem aber kann durch diesen regen Austausch eine sehr fruchtbare Feedback-Kultur entstehen, in der Probleme sehr konstruktiv diskutiert werden können und die Erwartungshaltungen auf Seiten der Nutzer und der technischen Unterstützung in Einklang gebracht werden können.