Freigeben über

Digitalisierung der Unternehmensanwendungen Gruppe

Um eine große Organisation wie die Digital Transformation Platform (DTP) bei Microsoft ganzheitlich zu digitalisieren, müssen wir alle vier Aspekte des digitalen Feedbackschleife automatisieren.

Digitale Feedbackschleife

  • Transformieren von Produkten zur Erweiterung unseres Angebots – zum Beispiel Veröffentlichen von Versionshinweisen zu kommenden Veröffentlichungszyklus-Liefergegenständen.
  • Zusammenarbeit mit Kunden und Partnern, um das Geschäftswachstum anzukurbeln – zum Beispiel durch Kundeninteraktionen und die Entgegennahme von Feedback und Ideen von Kunden.
  • Wir befähigen unsere eigenen Mitarbeiter, die Leistung unseres Unternehmens zu verbessern.
  • Optimieren Sie Geschäftsabläufe, um eine höhere Effizienz zu erreichen, beispielsweise durch die Automatisierung von Geschäftsüberprüfungen.

Hier ein Beispiel für Apps, die auf Success Hub entwickelt wurden; die digitale Feedback-Schleife in unserer Organisation in die Realität umsetzen.

Digitales DTP transformieren

Workstreams und Personas

Um alle vier Aspekte der Feedback-Schleife zu digitalisieren, unterteilen wir unsere Apps in verschiedene Workstreams. Jeder Workstream ist auf eine bestimmte Persona fokussiert, wie in der folgenden Abbildung gezeigt.

Diagramm mit fünf Persona-fokussierten Workstreams: DevOps, ProductOps, Customers & Partners, Community, und BizOps

Das folgende Bild zeigt, wie 35 Apps in diesen fünf Workstreams modelliert sind.

Apps über Workstreams hinweg modelliert

Apps fügen Daten in Microsoft Dataverse hinzu und nutzen die von anderen Apps freigegebenen Daten, um das App-Erlebnis durch Automatisierung und Intelligenz zu verbessern. Daten können auch verwendet werden, um Kalkulationsszenarien für die Verwendung der Daten durch verschiedene Apps zu erstellen.

Produktentwicklungsszenario

  1. Microsoft bindet den Kunden ein und interagiert mit ihm. Es gibt zahlreiche Apps im Workstream Customers & Partners, z. B. Customer Engagement, Executive Engagement, FastTrack-Apps und Power CAT. Jede dieser Benachrichtigungen ist auf eine bestimmte Persona fokussiert.
  2. Microsoft sammelt Feedback von Kunden. Es gibt zahlreiche Apps in den Workstreams Customers & Partners und Community, zum Beispiel Ideas, Pulse und Heartbeat (für FastTrack).
  3. Aggregieren und priorisieren von Feedback und Anfragen mit Hilfe der Fusion/One Feedback App im ProductOps Workstream.
  4. Implementieren der Funktion „Feedback“ und „Fragen“ mit Hilfe von Apps für die Produktplanung im ProductOps-Workstream.
  5. Ankündigen des Plans für die Kunden über App „Release Plan“ im ProductOps Workstream „Executive Reviews“. Dies wird durch die Verwendung des Bedrock-Portals automatisiert, das Teil des BusinessOps-Workstreams ist.

Supportability-Szenario

  1. Ein Debitor erstellt eine Support-Anfrage. Dies geschieht mit dem D4M-Teil des DevOps-Workstreams.
  2. Ein Techniker überprüft den Fall, um zukünftige Fälle zu verhindern. Dies geschieht mit der App „Case Review“, die Teil des DevOps-Workstreams ist.
  3. Das Produktteam plant die zu erledigenden Arbeiten. Dies geschieht mit der Produktplanungs-App im Product Ops-Workstream.
  4. Schließen Sie die Schleife mit Kunden, die das Problem mit Apps im Workstream Customers & Partners haben.
  5. Schließen Sie die Schleife mit Kunden, die das Feedback gegeben haben, indem Sie Apps im Workstream „Customers & Partners“ verwenden.

Success Hub Mitentwicklungsmodell

Die Herausforderung des Co-Development-Modells besteht darin, dass jeder in großem Umfang mitentwickeln kann, ohne andere Apps zu stören. Um dies skalierbar zu machen, unterteilen wir das Problem nach Workstreams. Für jeden der fünf Workstreams, die sich auf die Entwicklung von Apps konzentrieren, ernennen wir Workstream-Leads. Ihre Aufgabe ist es, sicherzustellen, dass alle Apps in diesem Workstream den Governance-Prozess einhalten und außerdem die richtige Unterstützung vom Success Hub Team erhalten.

Wann immer größere Änderungen für eine App angefordert werden, muss sie die folgenden fünf Schritte durchlaufen, um in Produktion zu gehen.

  1. Anpassung des Umfangs: Überprüfung der Benutzerfreundlichkeit auf hoher Ebene und Schemaänderungen.
  2. Update Microsoft Azure DevOps: Fügen Sie Funktionen und User Stories hinzu und aktualisieren Sie sie mit Schemaänderungen.
  3. Genehmigung von Partnern: Genehmigungsmail wird an die betroffenen Stakeholder gesendet.
  4. Abzeichnung durch Workstream-Leads: Abzeichnung der Änderungen durch die Workstream-Leads.
  5. Änderungen werden bereitgestellt: PR prüft und verifiziert Schema-Änderungen und Work Items.

Da wir etwa 35 Apps auf der Plattform betreiben, ist es für uns nicht skalierbar, alle Änderungen zu überprüfen. Einige Änderungen, wie z. B. das Hinzufügen eines Symbols für eine angepasste Tabelle oder das Ändern der Sortierung in einer angepassten Ansicht für eine angepasste Tabelle, wirken sich möglicherweise nicht auf andere Apps aus, und diese sind als kleiner Umfang gekennzeichnet; es ist den Teams der Apps freigestellt, sie mit dem Success Hub-Team zu überprüfen. Unser Hauptaugenmerk liegt auf der Bewertung von Änderungen, die mit Tabellen verbunden sind.

Wir sind daran interessiert, zu erfahren, wann Teams die folgenden Arten von Änderungen an Tabellen vornehmen:

  • Erstellen einer neuen Tabelle: Häufig möchten App-Teams ihre eigene Tabelle erstellen und unabhängig mit den Daten arbeiten. Wenn wir das zulassen, können mehrere Tabellen für dieselbe Arbeit erstellt werden, was zu Verwirrung führt. Das Abstimmen dieser Tabellen erfordert einen erheblichen Zeit- und Arbeitsaufwand, verglichen mit der Aufforderung an App Teams, bereits vorhandene Tabellen zu adaptieren oder aktuelle Tabellen zu modifizieren, um ihre und die Bedürfnisse aller App Teams zu erfüllen.

  • Änderungen an einer freigegebenen Tabelle: Es gibt zwei Arten:

    • Ändern des Schemas: Hierzu ist Ausrichtung in allen Apps erforderlich, die die Tabelle bereits verwenden.
    • Ändern der Daten (z. B. Taxonomie): Da Apps die Daten in der Tabelle gemeinsam nutzen, ist es erforderlich, dass ein einzelnes Team diese Daten verwaltet oder zumindest Governance-Regeln dafür erstellt.

Bereitstellen und Live-Site

Success Hub folgt einem wöchentlichen Bereitstellungszyklus, bei dem Microsoft Dataverse-Komponenten in einem Partner-Meeting überprüft und anschließend jeden Mittwoch in einer Testumgebung bereitgestellt werden. Partner-Teams haben zwei Tage Zeit, ihre Apps und Lösungsänderungen in der Testumgebung zu validieren. Nach der Validierung holen wir die Freigabe von den Partnerteams ein und stellen diese Komponenten am nächsten Montag in einer Produktionsumgebung bereit.

Microsoft Power Platform ermöglicht es uns auch, unseren Support-Prozess zu automatisieren, wobei E-Mails an den Support alias in einem Ticketing-System verfolgt werden. Diese Elemente werden jede Woche in einem Live-Site-Review überprüft, um den Zustand des Success Hubs zu verstehen und Reparaturen und Trends bei Benutzeranfragen zu erkennen.

Um den Zustand von Komponenten zu überwachen, verwenden wir Folgendes:

  • Ein Application Lifecycle Management (ALM)-Modell, das aus Folgendem besteht:
    • Entwicklungsumgebung (pro App)
    • Testumgebung (einzelne Umgebung)
    • Umgebung für Benutzerakzeptanztests (UAT) (Einzelumgebung)
    • Produktionsumgebung (einzelne Umgebung)
    • Proof-of-Concept-Umgebung für Teams zum Ausprobieren ihrer Apps
  • Die Build- und Release-Pipelines werden über Azure DevOps mit Hilfe von Power Platform Build Tools verwaltet.
  • Entwicklungs- und Testumgebungen werden jede Woche automatisch durch wöchentliche Builds aktualisiert.
  • Automatisierte Tests werden in Testumgebungen und UAT-Umgebungen ausgeführt. Dies trägt zu einer reibungsloseren Co-Entwicklung bei.
  • Jede App ist eine Lösung und befindet sich im Prozess, eine verwaltete Lösung zu werden.

Integration von Sicherheit und Compliance

Nachdem die Sicherheits- und Compliance-Integration abgeschlossen ist, kann sie von jeder App in der Entwicklung verwendet werden. Diese Integration hat die folgenden Eigenschaften:

  • Ein hohes Volumen an schreibgeschützten Daten: In einigen Fällen benötigen wir in Success Hub nur Daten zu Referenzzwecken , z. B. die täglichen, monatlichen und wöchentlichen aktiven Benutzermetriken für einen Mandanten. Diese Daten werden verwendet, um die Nutzung zu verstehen, aber nie in Success Hub geändert. Wir verwenden virtuelle Tabellen, um solche Daten darzustellen, die oft sehr umfangreich und schreibgeschützt sind.
  • Ein hohes Volumen an Lese- und Schreibdaten: Während Power Automate-Flows die meisten unserer Integrationsanforderungen erfüllen, werden in einigen Szenarien erweiterte Funktionalitäten von Azure benötigt, zum Beispiel der Aufruf von Azure Functions. Für diese verwenden wir Azure Logic Apps.
  • Einfache Integration: Flows werden in unserem Unternehmen ausgiebig verwendet, um neben der Geschäftslogik auch Integrationen zu erstellen.
  • Spezifische Rollen werden erstellt, um die Sicherheit zu honorieren.
  • Wir führen regelmäßige Compliance-Prüfungen auf Success Hub-Ebene durch, da Success Hub viele sensible Daten speichert.
  • Apps-Teams müssen keine Compliance-Prüfungen durchführen, wenn sie vorhandene Datentabellen und Integrationen verwenden.

Integration mit anderen Datenquellen

Für Business Apps benötigen wir oft Daten aus verschiedenen Datenquellen. Microsoft Dataverse bietet eine großartige Möglichkeit zur Integration mit anderen Datenquellen durch die Verwendung virtueller Tabellen. Wir integrieren mit den folgenden Arten von Datenquellen:

  • Microsoft Kunden-, Vertriebs- und Partnerdaten (z. B. Microsoft Sales Experience, Lifecycle Services, Kundenservice)
  • DevOps und Wartungsfreundlichkeit (z. B. Azure DevOps und IcM Incident Management)
  • Organisationshierarchie und Benutzerprofile (Microsoft Entra und Microsoft Diagramm)

Support- und Wartungskanäle

Über die folgenden Kanäle kann jede App entwickelt, unterstützt und gewartet werden:

  • Wiki, Anleitung und wöchentliche Office-Sprechstunde für Fragen
  • Wartung (Warnung und Überwachung) durch ein einziges Team (Microsoft Power Platform-Workstream)
  • Telemetrie-Dashboard zur Verfolgung von Leistungs- und Zustandsmetriken