Eine Präsentation zur Produkteinstellung sollte zeigen, was entfällt, wer darauf angewiesen ist und wie die betroffenen Gruppen ihre Arbeit fortsetzen können. Ein Abschalttermin allein ist noch kein Übergangsplan. Hilfreiche Folien verbinden eine konkrete Nutzeraufgabe mit einer Nachfolgelösung, einem Verantwortlichen und den Entscheidungen, die vor der Ankündigung noch fehlen.
Dieser Leitfaden zeigt den Aufbau anhand eines fiktiven Buchungsportals. Browser-Nutzer, Integrationsverantwortliche und Personen, die alte Datensätze benötigen, brauchen unterschiedliche Anweisungen. Halten Sie diese Wege zunächst in einem kurzen Briefing fest und lassen Sie Presenti daraus einen Präsentationsentwurf erstellen. Die Folien erklären den Übergang; sie migrieren keine Konten, Buchungen oder historischen Daten.
Benennen Sie genau, was nicht mehr möglich sein wird
„Wir stellen das alte Portal ein“ klingt für das Produktteam eindeutig. Für Kunden bleiben Fragen offen: Kann ich mich weiterhin anmelden? Bleibt eine vorhandene Buchung gültig? Funktioniert meine Integration noch? Komme ich an die Daten des letzten Jahres?
Beschreiben Sie zunächst das betroffene Verhalten, bevor Sie einen Lebenszyklusbegriff verwenden. Das Lifecycle-Glossar von Microsoft unterscheidet beispielsweise innerhalb seiner eigenen Richtlinien zwischen Abkündigung, Entfernung und Einstellung. Solche Begriffe ersetzen nicht die Erklärung, was sich bei Ihrem Dienst tatsächlich ändert.
Beim fiktiven Portal ist zunächst vorgesehen, neue Buchungen in der alten Browser-Oberfläche zu stoppen. Damit ist noch nicht entschieden, was mit bestehenden Buchungen, API-Anfragen, Datenzugriff und Support geschieht. Stellen Sie diese Punkte getrennt dar:
| Nutzeraufgabe | Vorgesehene Änderung im Beispiel | Was das Team klären muss |
|---|---|---|
| Eine Buchung im Browser anlegen | Neue Buchungen werden im Nachfolgeportal angelegt. | Zugangsberechtigung, Umstellungszeitpunkt und Hilfsangebot. |
| Eine vor der Umstellung angelegte Buchung verwalten | Der Stopp neuer Buchungen beantwortet diese Frage nicht. | Wo sich die Buchung ansehen, ändern oder stornieren lässt. |
| Buchungen über eine API anlegen | Die Integration benötigt einen eigenen Übergang. | Endpunkt, Authentifizierung, Feldzuordnung, Fehlerbehandlung und Umschaltung. |
| Historische Datensätze abrufen | Ein festgelegter Zugriffsweg ist erforderlich. | Verfügbare Datensätze, Abrufverfahren, Berechtigungen und geltende Aufbewahrungsrichtlinie. |
Die Tabelle verhindert, dass eine scheinbar kleine Ankündigung ein wesentlich größeres Versprechen enthält. Zugleich hilft sie dem Support, die Änderung zu erklären, ohne selbst Regeln erfinden zu müssen.
Planen Sie den Übergang nach Nutzeraufgabe statt nach Kundentarif
Ein Kunde kann den Browser nutzen, eine Integration betreiben und historische Daten abrufen. Behandeln Sie diese Nutzungswege als überlappend, nicht als voneinander getrennte Kundensegmente. Wenn Sie betroffene Organisationen zählen, müssen Sie diese Zahl gesondert von Mehrfachnennungen bereinigen. Die Summe der drei Nutzungswege könnte dieselbe Organisation mehrfach enthalten.
Der GOV.UK-Leitfaden zur Einstellung eines Dienstes setzt bei den Bedürfnissen nach dessen Ende an und unterscheidet direkte Nutzer von API-Nutzern. Für die Präsentation ergibt sich daraus eine hilfreiche Frage: Was muss jede Person weiterhin tun können?
| Bisheriger Weg | Künftiger Weg | Was vor der Wechselaufforderung belegt sein muss |
|---|---|---|
| Eine Empfangskraft legt Buchungen im alten Portal an. | Neue Buchungen im Nachfolgeportal erstellen. | Das betroffene Konto kann sich anmelden, eine Buchung erstellen und Hilfe finden; der Umgang mit bestehenden Buchungen ist separat erklärt. |
| Ein betriebliches Anwendungssystem übermittelt Buchungen über eine API. | Die unterstützte Nachfolgeintegration verwenden. | Der Integrationsverantwortliche hat erforderliche Felder und Verhalten zugeordnet, repräsentative Anfragen erprobt und die Umstellung abgestimmt. |
| Ein Nutzer sucht frühere Buchungsdaten. | Ein freigegebenes Archiv oder Abrufverfahren nutzen. | Ein berechtigter Nutzer kann den benötigten Datensatz finden und lesen; für Aufbewahrungs- und Zugriffsfragen gibt es einen Verantwortlichen. |
Ein Pfeil zu „Neue Plattform“ macht die Arbeit noch nicht vollständig. Zeigen Sie die konkrete Aufgabe am Ziel. Eine Nachfolgelösung kann neue Buchungen gut unterstützen und zugleich keine Antwort auf die Stornierung einer alten Buchung bieten. Diese Lücke gehört auf die Folie, auch wenn die neue Lösung mehr Funktionen hat.
Machen Sie die Zuordnung bei Integrationen konkret. Eine Buchungsreferenz im alten Dienst kann in der Nachfolgelösung einer anderen Kennung entsprechen. Dokumentieren Sie, ob das aufrufende System seine ursprüngliche Referenz behält, eine neue speichert oder eine Zuordnung abfragen muss. Die Namen sind hier beispielhaft; die tatsächliche Schnittstellenvereinbarung stammt aus Ihrer API-Dokumentation, nicht vom Folienautor.
Trennen Sie den Zeitplanentwurf von der Zusage an Kunden
Die interne Präsentation darf einen vorgeschlagenen Termin enthalten, obwohl noch eine Abhängigkeit offen ist. Eine Kundennachricht sollte nur den freigegebenen Umfang verbindlich ankündigen. Kennzeichnen Sie den internen Zeitplan entsprechend, damit ein vorläufiges Datum beim Weiterleiten einer Folie nicht zur vermeintlichen Zusage wird.
Im Buchungsbeispiel könnte der Browser-Zugang früher bereitstehen als die Integrationszuordnung. Der Datenzugriff kann eine dritte Abhängigkeit haben. Zeigen Sie drei Bahnen mit eigenen Meilensteinen: Ziel verfügbar, betroffene Nutzer informiert, erforderliche Nutzeraktion abgeschlossen und alter Weg eingestellt. Lassen Sie nicht alle Bahnen nur deshalb am selben Datum enden, weil das Diagramm dadurch ordentlicher aussieht.
Die Entscheidung in der Besprechung könnte daher eng gefasst sein: Die Kommunikation zur Browser-Umstellung wird freigegeben, während für die API noch kein Abschalttermin angekündigt wird. Das ist etwas anderes als die Freigabe zur Einstellung des gesamten Dienstes. Schreiben Sie den tatsächlichen Entscheidungsumfang neben den Zeitplan.
Wenn Verträge, Erstattungen, Barrierefreiheit oder Aufbewahrungspflichten den Übergang beeinflussen, gehören die jeweils freigegebene Regelung und der zuständige Verantwortliche in das Briefing. Eine allgemeine Nachrichtenvorlage kann diese Bedingungen nicht bestimmen. Benennen Sie die offene Frage konkret, etwa „Welches Team genehmigt den weiteren Datenzugriff?“, statt die Folie mit pauschalen Warnungen zu füllen.
Formulieren Sie drei Nachrichten für drei Aufgaben
Die folgenden Vorlagen gehören zum fiktiven Portalbeispiel. Ersetzen Sie die Angaben in eckigen Klammern vor der Verwendung durch freigegebene Informationen. Jede Nachricht beginnt mit der betroffenen Aufgabe und nennt anschließend die nötige Handlung sowie einen hilfreichen Kontaktweg.
Für Personen, die Buchungen im Browser anlegen
Ab [Datum, Uhrzeit und Zeitzone] legen Sie neue Buchungen unter [Link zum Nachfolgeportal] an. Das bisherige Portal nimmt ab diesem Zeitpunkt keine neuen Buchungen mehr an. Buchungen, die vor der Umstellung angelegt wurden, können Sie über [bestätigter Weg für bestehende Buchungen] ansehen, ändern oder stornieren. Melden Sie sich vor Ihrer nächsten Buchung mit [freigegebene Zugangsanleitung] im Nachfolgeportal an. Falls der Zugang nicht funktioniert, wenden Sie sich an [Supportkanal] und nennen Sie Ihre Organisation sowie die Aufgabe, die Sie erledigen möchten.
Der Satz zu bestehenden Buchungen ist wichtig. Ohne ihn weiß eine Person mit einer Buchung für den nächsten Monat nicht, ob sie handeln muss. Ist dieser Weg noch nicht geklärt, lösen Sie das Problem vor einer Nachricht, die scheinbar alle Browser-Nutzer abdeckt.
Für Integrationsverantwortliche
Ihre Integration verwendet [betroffene API oder Version] zur Übermittlung von Buchungen. Diese Schnittstelle soll ab [freigegebenes Datum, Uhrzeit und Zeitzone] keine Anfragen mehr annehmen. Die Dokumentation der Nachfolgelösung finden Sie unter [Dokumentationslink]. Prüfen Sie für Ihre Integration die Authentifizierung, Pflichtfelder, zurückgegebenen Kennungen und das Fehlerverhalten. Stimmen Sie anschließend die Umschaltung mit [technischer Kontakt] ab. Senden Sie den Namen Ihrer Integration und das vorgeschlagene Umstellungsfenster über [Supportkanal]. Der Wechsel der Browser-Nutzer aktualisiert diese Integration nicht.
Senden Sie diese Nachricht an die Personen, die die Integration betreuen, nicht nur an den kaufmännischen Ansprechpartner. Eine allgemeine Ankündigung erreicht womöglich nicht denjenigen, der die Software anpassen und die Arbeiten einplanen muss.
Für Personen, die historische Datensätze benötigen
Wenn Sie Datensätze aus dem bisherigen Buchungsportal benötigen, verwenden Sie [freigegebener Abrufweg]. Dort stehen [bestätigter Datenumfang und Format] für [berechtigte Nutzer oder Rollen] bereit. Der Zugang über das bisherige Portal ändert sich am [freigegebenes Datum, Uhrzeit und Zeitzone]. Bei Fragen zu Datensätzen außerhalb dieses Umfangs oder zu Zugangsvoraussetzungen wenden Sie sich an [Kontakt für Datenanfragen]. Die geltenden Informationen zur Aufbewahrung finden Sie unter [Link zur freigegebenen Richtlinie].
Ergänzen Sie nicht „Alle Ihre Daten werden automatisch übertragen“, solange genau dieser Umfang und dieses Verhalten nicht belegt sind. Ein herunterladbarer Bericht, ein durchsuchbares Archiv und eine bearbeitbare Buchungshistorie sind unterschiedliche Ergebnisse. Nennen Sie dasjenige, das Nutzer tatsächlich erhalten.
Bauen Sie eine kurze Präsentation um Wege und Nachrichten auf
Beginnen Sie mit einer präzisen Beschreibung der vorgesehenen Änderung: „Neue Browser-Buchungen ins Nachfolgeportal verlagern; API- und Datenzugriff separat klären.“ Danach folgen die Umfangstabelle und die drei Nutzungswege. So kann das Publikum zuerst die Folgen besprechen, bevor es den Zeitplan sieht.
Zeigen Sie im Mittelteil die vorgesehenen Meilensteine und eine repräsentative Nachricht. Die beiden anderen Vorlagen passen in den Anhang oder das begleitende Briefing, damit die eigentliche Besprechung übersichtlich bleibt. Auf die letzte Folie gehören die erbetene Entscheidung, die dazu befugte Person und die offenen Punkte außerhalb dieses Entscheidungsumfangs.
Geben Sie im Word-Briefing jedem Nutzungsweg eine eigene Überschrift. Fügen Sie die Umfangstabelle, die freigegebenen Nachrichtentexte und den Status jedes Meilensteins hinzu. Bitten Sie beim Erstellen des Entwurfs darum, die drei Wege getrennt zu lassen und offene Termine nicht zu ergänzen. Lassen Sie das Werkzeug keinen Migrationszeitplan allein aus einem Produktnamen erfinden.
Bei einer umfassenderen Kommunikation kann ein Stakeholder-Kommunikationsplan Zielgruppen, Kanäle und Nachrichtenverantwortliche um diese Mitteilungen herum organisieren. Die Präsentation zur Produkteinstellung liefert die konkrete Änderung, die jede Nachricht erklären muss.
Zeigen Sie, wer nach dem Ende des alten Wegs hilft
Der letzte Tag des alten Portals ist nicht zwangsläufig der letzte Tag der Übergangsarbeit. Jemand kommt über ein gespeichertes Lesezeichen, fragt nach einer alten Buchung oder entdeckt eine Integration, die in der Bestandsaufnahme fehlte. Geben Sie dem übernehmenden Supportteam einen klaren Weg für solche Fälle.
Im Beispiel kümmert sich der Browser-Support um den Zugang zur Nachfolgelösung, der technische Kontakt um Integrationsfragen und der Datenkontakt um Abrufanfragen. Sagen Sie den Mitarbeitern, welcher Weg für welche Anfrage zuständig ist und welche Informationen weiterzugeben sind. Ein gemeinsames Postfach ohne klare Zuständigkeit zwingt Nutzer dazu, ihr Anliegen wiederholt zu erklären.
Halten Sie zum Ende der Besprechung den freigegebenen Umfang und die noch offenen Entscheidungen getrennt fest. Eine gute Präsentation macht die nächste Nutzeraktion verständlich und versetzt das Team in die Lage, „Was passiert mit meiner Arbeit?“ zu beantworten, ohne etwas erfinden zu müssen.
