Sichere kundenorientierte digitale Workflows planen

Was es ist

Ein kundenorientierter Workflow kann ein Portal, einen Webdienst, ein mobiles Erlebnis, ein Backend, eine API, einen Zahlungsanbieter, einen Supportprozess und ein Administrationsteam umfassen. Die Planung sollte Benutzerrollen und Zugriffsgrenzen benennen; Authentifizierung und Wiederherstellung; Formulare, Dateien, Nachrichten, Dashboards und Status; Pfade für Zahlung, Abonnement, Rechnung, Erstattung, Kündigung und Berechtigung; Zuständigkeit für Daten und Aufbewahrung; Integrationen von Drittanbietern sowie betriebliche Verantwortung. Sie sollte außerdem entscheiden, ob Mobile oder Web angemessen ist, ob das bestehende Backend und die APIs bereit sind und wer für Protokollierung, Support, Änderungen und Übergabe verantwortlich ist. Sicherheitsprüfung und Softwarelieferung können separate Scopes sein.

Für wen es gedacht ist

Dieser Leitfaden hilft Teams bei der Planung von:

• einem Kunden- oder Partnerportal, einem Aufnahme-Workflow, einem Dashboard, einer Zahlungs-Journey, einem Web-to-Mobile-Übergang oder einem Anwendungs-Launch
• rollenbasiertem Zugriff, Wiederherstellung, Dateien, Statusinformationen, Support und administrativen Verantwortlichkeiten
• einer Produktänderung mit bestehenden Backends, APIs, Drittanbietern, Abrechnungszuständen oder Kundendaten
• einer klareren Grenze zwischen Discovery, Design, Lieferung, Härtung, Prüfung und späterer betrieblicher Verantwortung

Was es zu klären hilft

Die Planungsfragen helfen aufzudecken:

• Ob Nutzer, Rollen, Zugriffsregeln, Kontowiederherstellung, Zuständigkeit für Daten und Aufbewahrung verstanden sind, bevor die Lieferung beginnt
• Welche Formulare, Dateien, Nachrichten, Dashboards, Statusansichten, Zahlungszustände und Berechtigungsentscheidungen Systemgrenzen überschreiten
• Ob Integrationen, Backend/APIs, mobile Lieferung, Launch-Phase, Protokollierung, Support und Zuständigkeit für Änderungen für einen abgegrenzten nächsten Schritt bereit sind
• Ob das Team einen Portal-Sprint, eine Zahlungsprüfung, einen Web-to-Mobile-Übergang, eine Prüfung der Launch-Reife, Website-Härtung oder vorab Discovery-/Blueprint-Arbeit benötigt

Was ist enthalten

• Eine Checkliste für Auftraggeber zu Journeys, Rollen, Zugriff, Authentifizierung, Wiederherstellung, Formularen, Dateien, Nachrichten, Dashboards, Status, Zahlungen, Abonnements, Rechnungen, Erstattungen, Kündigungen, Berechtigungen, Daten und Integrationen
• Planungsfragen zu administrativer Zuständigkeit, Bereitschaft von Backend/API, Mobile versus Web, Launch-Phase, Protokollierung, Support, Änderungssteuerung und Übergabe
• Ein Vergleich, wann Secure Client Portal Sprint, Subscription & Payment Infrastructure Security, Secure Web-to-Mobile Launch, App Launch Readiness und Website Performance & Security Hardening relevant sein können
• Ein Hinweis darauf, dass unklare Workflows, Rollen, Integrationen oder Zuständigkeiten vor der Lieferung Discovery- oder Blueprint-Arbeit erfordern können

Was nicht enthalten ist

• Eine Zusage von Sicherheit, regulatorischer Eignung, Genehmigung von Zahlungen, Betrugsprävention, Umsatz, Store-Freigabe, Launch-Erfolg, Verfügbarkeit, Performance oder unterbrechungsfreiem Betrieb
• Die Behauptung, dass ein Portal-Sprint eine vollständige SaaS-Plattform ist, dass eine Zahlungsprüfung eine PCI-Zertifizierung oder Betrugsabwehr darstellt oder dass mobile Lieferung ein Produkt automatisch launch-reif macht
• Die Andeutung, dass Härtung Anwendungsdesign, Lasttests, Incident-Response oder laufenden Betrieb ersetzt
• Die Annahme, dass Softwarelieferung, Sicherheitsprüfung, Freigabe durch Anbieter und laufende Zuständigkeit automatisch einen gemeinsamen Scope bilden

Wann man es wählt

Nutzen Sie diesen Leitfaden, bevor eine kundenorientierte Änderung zu einer Liste unverbundener Funktionen wird. Er ist nützlich, wenn ein Team entscheidet, ob es ein Portal baut, den Zugriff ändert, Abonnements einführt, einen Webdienst auf Mobile erweitert, einen Anwendungs-Launch vorbereitet oder eine Website verbessert. Bleiben der grundlegende Workflow, die Zuständigkeit, Integrationen oder Benutzerrollen unklar, ist Discovery- oder Produkt-Blueprint-Arbeit meist wertvoller als eine frühe Umsetzung. Eine abgegrenzte Prüfung kann dann folgen, wenn eine konkrete Sicherheits- oder Betriebsfrage reif ist.

Unser Ansatz

Bilden Sie die Journey ab, bevor Sie die Liefermethode wählen. Beginnen Sie mit dem Nutzer, seiner Rolle, der Zugriffsentscheidung, den Daten, die er angibt oder sieht, dem System, das den nächsten Zustand verantwortet, und dem Team, das zuständig ist, wenn sich etwas ändert. Verfolgen Sie Zahlungs- und Berechtigungszustände ebenso sorgfältig wie Oberflächen. Identifizieren Sie dann Abhängigkeiten von Anbietern und Backend, Anforderungen an Support und Protokollierung, mobile Einschränkungen, Release-Verantwortung und Anforderungen an die Übergabe. So wird sichtbar, ob die nächste Entscheidung Portal-Lieferung, Zahlungslogik, Web-to-Mobile-Arbeit, Launch-Reife, Website-Härtung oder eine vorgelagerte Discovery betrifft. Es verhindert außerdem, dass ein abgegrenzter Service mit einer unbegrenzten Verantwortung für Produkt, Betrieb oder Compliance verwechselt wird. Eine schriftliche Workflow-Karte kann zudem die regulären und außergewöhnlichen Pfade festhalten: ein neuer Nutzer, eine fehlgeschlagene Zahlung, eine Kündigung, ein verlorenes Konto, eine fehlende Datei, ein Ausfall eines Dienstleisters oder eine Supportanfrage. Sie gibt Produkt-, Betriebs-, Engineering- und Supportteams einen gemeinsamen Ort, um Zuständigkeiten zu klären, bevor ein Kunde betroffen ist. Diese Klarheit kann eine schleichende Ausweitung des Scopes in späteren Lieferarbeiten verringern. Überprüfen Sie die Karte im Laufe der Planung immer dann, wenn sich ein Anbieter, Zahlungsmodell, eine Rolle, Zugriffsregel, API, ein Release-Kanal oder Supportprozess ändert. Ein Workflow, der in einem Diagramm einfach aussah, kann in der Produktion wichtige Ausnahmen haben. Diese Ausnahmen festzuhalten, erleichtert die Entscheidung, ob der nächste Scope Design, Lieferung, Prüfung, Härtung, Tests oder betriebliche Vorbereitung ist. Zudem hilft es einem Auftraggeber, vor einer Entscheidung die richtigen Nachweise von Dienstleistern anzufordern. Nutzen Sie die Karte schließlich, um festzulegen, was nach der Lieferung gemessen wird und wer auf ein Ergebnis, eine fehlgeschlagene Zahlung, ein Supportsignal oder eine Änderungsanfrage reagiert. Eine Übergabe ist stärker, wenn sie einen Verantwortlichen, einen Prüfzeitpunkt und eine vereinbarte Grenze benennt, statt nur Funktionen aufzulisten.

Häufig gestellte Fragen

Verwandte Artikel