Was eine Einführung umfasst und welche Rolle du hast

Worum es geht

Montag, 7 Uhr, in einem Handwerksbetrieb irgendwo im Mittelland. Am Wochenende hat der Lieferant die neue Auftragssoftware installiert, technisch einwandfrei: Server läuft, Schnittstelle zur Buchhaltung grün, alle Konten angelegt. Um 7.15 Uhr ruft die erste Monteurin an: Sie findet ihre Aufträge nicht. Um 7.40 Uhr merkt die Disposition, dass bei der Hälfte der Kunden die Telefonnummer fehlt. Um 9 Uhr fragt die Buchhaltung, warum keine einzige Rechnung im System ist. Am Mittag holt der Chef die alten Formulare wieder aus dem Schrank.

Was ist schiefgelaufen? Nicht die Technik. Niemand hat geprüft, ob die Daten vollständig übernommen wurden. Niemand hat mit der Buchhaltung getestet, ob ein Auftrag bis zur Rechnung durchläuft. Und die Monteurinnen haben die Software zum ersten Mal am Stichtag gesehen.

Genau hier setzt dieses Modul an. Als Entwickler/in digitales Business vermittelst du oft zwischen Fachabteilung, IT und Lieferant. Du programmierst und installierst die Software nicht, aber du sorgst dafür, dass sie am Stichtag im Alltag funktioniert: mit richtigen Daten, getesteten Abläufen und vorbereiteten Menschen. In dieser Lektion verschaffst du dir den Überblick: Was gehört alles zu einer Einführung, wer liefert was, und welche Rolle spielst du dabei?

Durch den ganzen Kurs begleitet dich Luca, Lernender im 2. Lehrjahr bei der Elektro Keller AG in Frauenfeld (140 Mitarbeitende). Die 45 Servicetechniker schreiben ihre Arbeitsrapporte heute auf Papier, die Disposition tippt sie danach ins ERP ab. Eine Einsatzplanungs-App auf Tablets soll das ersetzen. Luca unterstützt die Projektleiterin Sandra Frei bei der Einführung.

Mehr als Technik: was eine Einführung umfasst

Denk an einen Wohnungsumzug. Die Möbel in den Lastwagen laden ist der sichtbarste Teil, aber längst nicht alles. Vorher sortierst du aus, was du nicht mehr brauchst. Du meldest die neue Adresse bei Post, Bank und Gemeinde. Am Umzugstag braucht es einen genauen Ablauf: Wer trägt was, wann kommt der Lift, wo steht der Wagen? Und in den ersten Wochen danach suchst du Dinge, kaufst eine fehlende Lampe und gewöhnst dich an den neuen Arbeitsweg.

Bei einer Software-Einführung ist es genauso. Die technische Installation ist der Lastwagen. Dazu kommen viele Arbeitspakete, also abgegrenzte Aufgaben mit einem klaren Ergebnis und einer verantwortlichen Person:

Drei Parteien, viele Rollen

Bei fast jeder Einführung arbeiten drei Parteien zusammen, die verschiedene Sprachen sprechen und verschiedene Interessen haben:

• Der Lieferant will termingerecht liefern und das Projekt abschliessen. Er kennt seine Software, aber nicht deinen Betrieb.
• Die IT (intern oder ein IT-Dienstleister) sorgt für Geräte, Konten, Netz und Sicherheit. Sie betreibt die Lösung später.
• Die Fachabteilung muss mit der Lösung arbeiten. Sie kennt die Abläufe und die Sonderfälle, hat aber neben dem Tagesgeschäft wenig Zeit.

Dazu kommen konkrete Rollen. Eine Rolle ist eine Aufgabe im Projekt, keine Person: Eine Person kann mehrere Rollen haben, und eine Rolle kann auf mehrere Personen verteilt sein.

Deine Rolle: Übersetzer und Taktgeber

Als Koordinatorin oder Koordinator hast du drei Hauptaufgaben.

1. Übersetzen. Die Disposition sagt: «Die Rapporte müssen am Abend da sein.» Der Lieferant braucht eine prüfbare Anforderung: «Ein abgeschlossener Rapport ist spätestens 30 Minuten nach dem Abschluss im ERP sichtbar, auch wenn das Tablet unterwegs zeitweise offline war.» Umgekehrt übersetzt du technische Aussagen für die Fachabteilung: «Die Synchronisation läuft asynchron» heisst für die Techniker: «Ihr könnt auch im Keller ohne Empfang weiterarbeiten, die App schickt den Rapport, sobald wieder Netz da ist.»

2. Den Takt halten. Du führst die Liste der offenen Punkte, erinnerst an Termine und merkst früh, wenn etwas klemmt.

3. Entscheide vorbereiten, nicht treffen. Ob die App live geht, entscheidet die Geschäftsleitung. Du lieferst ihr die Fakten auf einer Seite: Testresultate, offene Fehler, Risiken, Empfehlung.

Woran Einführungen scheitern

Einführungen scheitern selten an einem grossen Fehler, sondern an mehreren vorhersehbaren. Für jeden gibt es ein Gegenmittel, das du in diesem Kurs lernst.

Schritt für Schritt: Luca sammelt die Arbeitspakete

Sandra Frei bittet Luca, bis Ende Woche alle Arbeitspakete für die Einführung der Einsatz-App zu sammeln. So geht er vor.

Schritt 1: Ausgangslage in Zahlen. Luca fragt in der Disposition nach. Pro Tag kommen rund 130 Papierrapporte zurück, das Abtippen dauert je etwa 4 Minuten. Das sind 130 × 4 = 520 Minuten, also über 8.5 Stunden Erfassungsarbeit pro Tag, und jede unleserliche Notiz führt zu einem Rückruf. Diese Zahlen helfen später, das Projekt zu begründen und den Erfolg zu messen.

Schritt 2: Sammeln entlang der neun Arbeitspakete. Luca geht die Tabelle oben durch und notiert zu jedem Paket, was bei der Elektro Keller AG konkret anfällt:

Konfiguration:     Rapportvorlage, Materialkatalog, Rollen, Schnittstelle ERP
Geräte:            45 Tablets beschaffen, einrichten, Zwei-Faktor-Anmeldung
Datenübernahme:    3'200 Kundenadressen, 900 Anlagen, Artikelstamm
Tests:             Testfälle für Rapport, Material, Rechnung, Offline-Betrieb
Schulung:          Techniker, Disposition, Buchhaltung (je anders)
Kommunikation:     Info am Monatsrapport, Fragen sammeln, Key User bestimmen
Go-Live:           Stichtag, Papierrapporte stoppen, Schlussimport
Hypercare:         Anlaufstelle, tägliche Kurzbesprechung, Ticketkategorie
Abschluss:         Übergabe an IT-Support, Lessons Learned

Schritt 3: Verantwortung klären. Zu jedem Paket schreibt er, wer das Ergebnis liefert und wer mitarbeitet. Beim Paket «Datenübernahme» steht: verantwortlich Disposition (fachlich), Lieferant (technisch), Luca prüft den Abgleich.

Schritt 4: Lücken entdecken. Beim Paket «Geräte» merkt Luca: Niemand hat die Tablets bestellt. Die IT dachte, der Lieferant liefere sie mit, der Lieferant verkauft nur die Software. Luca trägt den Punkt in die Liste der offenen Punkte ein: «Nr. 7: Beschaffung 45 Tablets mit Schutzhülle. Verantwortlich: IT. Liefertermin klären bis Freitag.»

Schritt 5: Grobe Reihenfolge. Schliesslich ordnet Luca die Pakete grob: Organisation und Kommunikation zuerst, dann Konfiguration und Datenbereinigung parallel, dann Testmigration, Tests, Schulung, Go-Live, Hypercare und Abschluss. Wie daraus ein Plan mit Daten wird, lernst du in der nächsten Lektion.

Ergebnis: Eine Liste mit 9 Paketen, 31 konkreten Aufgaben, je einer verantwortlichen Stelle und einem gefundenen Problem (Tablets), das sonst erst im Februar aufgefallen wäre.

Typische Fehler

• Nur an die Technik denken. Wer «Software installieren» als einziges Arbeitspaket sieht, vergisst Daten, Tests, Schulung und Kommunikation. Geh immer alle neun Pakete durch.
• Rollen mit Personen verwechseln. «Sandra macht alles» ist keine Rollenverteilung. Halte fest, welche Aufgabe jemand hat, damit klar ist, wer was entscheidet und wer was liefert.
• Aufgaben ohne verantwortliche Person. «Tablets beschaffen» ohne Namen bleibt liegen. Jede Aufgabe braucht genau eine verantwortliche Stelle.
• Als Koordinator selbst entscheiden. Wenn du den Go-Live allein «freigibst», übernimmst du ein Risiko, das nicht deines ist. Du bereitest vor, die zuständige Stelle entscheidet.

Zusammenfassung

• Eine Einführung umfasst neun Arbeitspakete: Organisation, Konfiguration, Datenübernahme, Abnahmetests, Schulung, Kommunikation, Go-Live, Hypercare und Abschluss.
• Daten, Tests und Schulung gelingen nur mit der Fachabteilung. Der Lieferant kennt seine Software, nicht deinen Betrieb.
• Lieferant, IT und Fachabteilung haben verschiedene Interessen. Rollen wie Auftraggeber, Projektleitung, Key User und Koordination machen klar, wer was liefert und entscheidet.
• Als Koordinator/in übersetzt du zwischen Fach- und IT-Sprache, hältst den Takt und bereitest Entscheide vor, ohne sie selbst zu treffen.
• Eine Liste der offenen Punkte mit verantwortlicher Person und Termin ist dein wichtigstes Werkzeug.
• Die meisten Einführungen scheitern an vorhersehbaren Fehlern bei Daten, Tests, Schulung und fehlendem Rückfallplan, nicht an der Technik.