Sicheres Implementieren von Formularen, Workflows, Daten und Governance

Enterprise-Lösungen mit Office 365
Keine Kommentare

Die SaaS-Lösung Office 365 bietet viele sogenannte Productivity-Lösungen, die den Anwendern im täglichen Einsatz die Arbeit erleichtern. Viele Funktionen wie Workflows, Formulare und Zusammenarbeit, die früher in komplexen Plattformen wie SharePoint oder Dynamics untergebracht waren, lassen sich nun einfach auf individuelle Anforderungen anpassen und überall nutzen. Wenn man aber nun Enterprise-Lösungen wie Line-of-Business-Prozesse oder anwenderübergreifende Abläufe mit diesen Tools abbilden möchte, gibt es diverse Herausforderungen in Bezug auf Governance und Compliance, die man beachten sollte.

Die Software as a Service (SaaS) Suite Office 365 bietet eine Menge nützliche Dienste und Anwendungen, die Unternehmen und Anwender für Productivity Solutions nutzen können, das heißt Apps oder Anwendungen, die die Produktivität der Anwender unterstützen beziehungsweise steigern. Wer sich noch keinen Überblick verschafft hat, welche Bausteine es gibt, der findet unter [1] mit dem Office-365-Periodensystem eine hilfreiche Übersicht (Abb. 1). Natürlich unterstützt diese Bandbreite an Tools, wenn man sie denn alle lizensiert hat, die Philosophie, dass der Anwender oder Poweruser für gängige Anwendungsfälle wie zum Beispiel Collaboration, Dokumentenverwaltung und Projektarbeit aus diesen Tools diejenigen auswählen kann, die ihm persönlich am besten helfen. Oftmals können diese Tools einfach auf die individuellen Bedürfnisse angepasst und kombiniert werden. Einen eindeutigen Weg gibt es hier aber nicht, da sich einige Tools in den Funktionen überschneiden. Ebenso können sie als Plattformen für Teams oder über Konnektoren mit einer großen Bandbreite von Drittanbieter-SaaS-Angeboten genutzt werden. Die Einstellung, dass die IT-Abteilung zentral die zu verwendenden Tools für die Fachanwender definiert, gilt als veraltet – jedenfalls für kleinere und mittlere Anwendungsfälle.

 Abb. 1: Das Periodensystem von Office 365 (<a href="https://app.jumpto365.com">Quelle: Office-365-Periodensystem</a>)

Abb. 1: Das Periodensystem von Office 365 (Quelle: Office-365-Periodensystem)

Dann ist doch alles gut, oder etwa nicht? Im Prinzip unterstützen diese Tools individuelle Arbeitsabläufe und Teamarbeit so wie es seit jeher klassische Tools wie Excel und Access tun. In Unternehmen gibt es allerdings verschiedene Ebenen, die unterschiedliche Anforderungen haben (Abb. 2). Auf der unteren Ebene der individuellen Anwender und Teams gibt es große Freiheiten in Bezug auf die Wahl der Tools, um ein Problem zu lösen oder einen Use Case abzubilden. Je weiter man aber auf der Pyramide der Unternehmensebenen nach oben steigt, desto stärker werden Governance- und Compliance-Regeln notwendig. Auf der höchsten Ebene der unternehmensweiten Prozesse und Anwendungsfälle braucht man unter anderem definierte Informationsarchitekturen, Verantwortlichkeiten, Regeln und Richtlinien zum Befolgen eben dieser, um zu vermeiden, dass jede Fachabteilung zum Beispiel ihr eigenes CRM-System implementiert, redundante Datenhaltung vermieden wird oder in Zeiten der DSGVO sensible personenbezogene Daten intransparent und dezentral von diversen Tools gehalten werden.

Abb. 2: Governance-Ebenen im Unternehmen

Abb. 2: Governance-Ebenen im Unternehmen

Dieser Gegensatz zwischen größtmöglicher Flexibilität für den Anwender auf der einen und dem sicheren Betrieb und Governance auf der anderen Seite ist im Grunde nicht neu, da auch in der Pre-Cloud-Ära genau dieselben Herausforderungen bestanden, allerdings ging es dabei in der Regel um On-premise-Tools und -Applikationen wie Excel und Access auf der einen Seite und Plattformen wie zum Beispiel SAP, Lotus Notes oder Microsoft SharePoint auf der anderen Seite. Der Unterschied besteht heutzutage oft darin, dass sowohl Infrastruktur als auch Software in der Cloud gehosted werden und die IT-Abteilungen gefühlt weniger Kontrolle darüber haben, wie die Anwendungen genutzt werden.

Das Lego-Prinzip

Wo man früher auf einer Middleware aufwendige Applikationen implementiert hat, verfolgt man bei den in der Cloud gehosteten SaaS-Diensten eher den No-Code-Ansatz und konfiguriert Anwendungen beziehungsweise Lösungen, statt zu programmieren. Wobei man im Zeitalter von JavaScript Frameworks und -Bibliotheken aktuell eher in Richtung Low-Code-Solutions geht; also Lösungen, die überwiegend zusammenkonfiguriert werden, aber an der einen oder anderen Stelle doch Daten über ein REST-Interface abfragen, Oberflächen mit JavaScript customizen oder eine Azure Function für Funktionen nutzen, die out of the box in den SaaS-Angeboten nicht verfügbar sind.

Für viele alltägliche Anwendungsfälle in Unternehmen, wie z. B. Beschaffungsprozesse, Team- und Projektzusammenarbeit, Intranetwebseiten oder Verwaltung von Stammdaten, kann man mit den Building Blocks PowerApps (für Formulare), Flow (für Workflows) und SharePoint (als Portal sowie für die Datenhaltung in SharePoint-Listen und -Bibliotheken) in überschaubarer Zeit Anwendungen umsetzen. Dank des „Mobile first, Cloud first“-Ansatzes von Microsoft sind solche im Prinzip direkt mobil nutzbar und zum Teil auch mit externen Anwendern teilbar, wenn man das möchte. Allerdings gibt es Beschränkungen und Governance-Gesichtspunkte, die man für solche Lösungen unternehmensweit berücksichtigen sollte.

Im Folgenden werden die wichtigsten (Governance)-Punkte exemplarisch an einem Beispiel für Abwesenheitsanträge beschrieben, und zwar für PowerApps, Flow, SharePoint und Teams; das bedeutet nicht, dass man sich nicht auch für die übrigen Office 365 Building Blocks wie Planner, Forms und Sway Gedanken machen und entsprechende Regeln und Standards definieren sollte.

Good old SharePoint

Als eins der ältesten Softwareprodukte der Office 365 Suite kommt SharePoint mit modernem UI aufgefrischt daher. Nach wie vor bildet SharePoint die Grundlage von vielen Anwendungen und Use Cases, wie beispielsweise Intranet oder Dokumentenmanagement. Im vorliegenden Beispiel zu Abwesenheitsanträgen dient eine SharePoint-Liste mit entsprechenden Metadaten zum Persistieren der Daten (Abb. 3). Ferner kann das SharePoint-Portal genutzt werden, um über angepasste Ansichten zum Beispiel offene Anträge oder zugehörige Aufgaben zu sehen. Grundlage für diesen Use Case ist eine SharePoint-Teamsite, die beim Anlegen so konfiguriert wurde, dass sie im Unternehmen jeder öffentlich nutzen kann. Für SharePoint-basierte Anwendungen, die unternehmensweit genutzt werden können, sollte man sich mindestens Gedanken über die folgenden Punkte machen:

  • Lifecycle der SharePoint-Website
  • Zugriff auf die Website, Erlauben von external Sharing
  • Datenklassifikation und Data Retention Policies
  • Site Quota
Abb. 3: Liste mit Abwesenheitsanträgen in SharePoint

Abb. 3: Liste mit Abwesenheitsanträgen in SharePoint

Dabei finden sich die Konfigurationen für diese Punkte an unterschiedlichen Stellen. Während einige Punkte in den Websitesettings einzelner Websites mehr oder weniger versteckt sind, wie z. B. das Aktivieren des Site-Retention-Policy-Features, sind andere Einstellungen zentral im SharePoint Admin Center für alle Websites zu finden, wie etwa Zugriffslevel und Sharing. Alle Punkte rund um Security und Compliance, wie beispielsweise die DLP oder Data Retention Policies, sind im zugehörigen Admin Center für Data und Compliance zu finden. Es empfiehlt sich, mehrere Policies und Regeln zu definieren, die mehr oder weniger strikt die (Daten-)Nutzung einschränken, je nachdem auf welcher Unternehmensebene man steht (Abb. 2).

Starke Formulare

PowerApps ist ein mächtiges Tool, um auf einfache Weise elektronische Formulare, aber auch ganze Apps, wie wir sie vom Smartphone kennen, zu erstellen. PowerApps kann sowohl eigenständig laufen als auch in SharePoint oder Teams integriert werden und ist grundsätzlich mobil nutzbar. Ferner können die Daten, die man über PowerApps ein- oder ausgibt, über diverse Konnektoren an nahezu jedes beliebige Drittsystem angebunden werden. Ähnlich wie früher mit Microsoft InfoPath lassen sich so für diverse Anwendungen Formulare konfigurieren statt programmieren. Dennoch gilt auch hier das Prinzip „Keep it simple“, denn bei komplexer Businesslogik kommt PowerApps schnell an seine Grenzen. Dafür muss man gegebenenfalls die Businesslogik auslagern, zum Beispiel in Flow-Workflows, Azure Logic Apps oder Azure Functions. Ähnlich wie bei Flow sollte man sich auch bei PowerApps Gedanken über Governance machen, etwa mehrere Environments konfigurieren und pro Umgebung die Daten festlegen, die genutzt werden können, um zu verhindern, dass Endanwender ihre ersten PowerApps-Gehversuche versehentlich an Produktivdaten ausprobieren. Einstellungen zu PowerApps kann man zentral im zugehörigen PowerApps Admin Center vornehmen.

Abb. 4: PowerApps-Formular für einen simplen Abwesenheitsantrag

Abb. 4: PowerApps-Formular für einen simplen Abwesenheitsantrag

Abbildung 4 zeigt ein simples PowerApps-Formular, das einen minimalistischen Abwesenheitsantrag darstellt. Im Gegensatz zu den reinen SharePoint-Standardformularen hat man hier mehr gestalterische Möglichkeiten und kann zum Beispiel auch Felder wie das Statusfeld, das durch den Workflow gesetzt werden soll, ausblenden.

Quo vadis Flow?

Microsoft Flow ist der Workflowbaustein, mit dem man sowohl individuelle Arbeitsabläufe als auch unternehmensweite Prozesse automatisieren kann. Ursprünglich lag der Fokus auf der Automatisierung von Abläufen einzelner Anwender, die ähnlich wie Regeln in Outlook simpel, aber effektiv sein sollen. Durch die enorme Anzahl von Konnektoren (aktuell über 200) sowohl zu Microsoft- als auch öffentlichen Dienste wie Dropbox, Twitter oder GitHub sowie der Möglichkeit einfach Workflows zu konfigurieren gewann Flow enorm an Popularität und wurde für immer mehr Use Cases eingesetzt. Allerdings gab es anfänglich einige Herausforderungen in Bezug auf die Enterprise Readyness. Oftmals wurden die Flows direkt mit Produktivdaten im Produktivsystem implementiert. Policies, granulare Berechtigungen und Testsysteme waren anfangs schwer zu realisieren. Inzwischen hat Microsoft nachgebessert und über das (Flow) Admin Center können sowohl Governance-, Security- und Compliance-Aspekte als auch Vorlagen, Projektmappen, und benutzerdefinierte Konnektoren definiert werden.

Insbesondere für das Testen und die Nutzung von Flow in besonderen Bereiche im Unternehmen empfiehlt es sich, mehrere sogenannte Environments zu erstellen. Für diese Umgebungen können individuelle Nutzergruppen berechtigt werden und man kann sowohl feingranulare Berechtigungen konfigurieren als auch Data Loss Prevention einrichten, um zu vermeiden, dass interne oder sensible Daten wie zum Beispiel Personalausweis- oder Kreditkartennummern einer Umgebung versehentlich über Flow-Konnektoren an öffentliche Dienste weitergeleitet werden.

Wenn man nun Flow für unternehmensweite Anwendungen und Prozesse nutzen möchte, sollte man ebenfalls die zum Teil lizenzabhängigen Beschränkungen im Hinterkopf haben (Auszug aus [2]):

  • Flow-Laufzeit: maximal 30 Tage
  • Genehmigungen: maximal 30 Tage
  • Maximale History zu Flow-Läufen (GDPR): 28 Tage
  • Maximale Actions pro Flow: 250
  • Je nach Lizenz Loop-Iterationen (zum Beispiel pro Item) zwischen 5000 und 100000

Für das vorliegende Beispiel der Abwesenheitsanträge sind beispielsweise die Laufzeiten möglicherweise ein Problem, wenn die Genehmigenden nicht schnell genug reagieren. Ansonsten lassen sich solche einfachen Genehmigungsworkflows, die einen Status in SharePoint umsetzen und eine entsprechende Benachrichtigung aussenden, mit wenigen Klicks realisieren (Abb. 5).

Abb. 5: Genehmigungsworkflow für Abwesenheitsantrag in Flow

Abb. 5: Genehmigungsworkflow für Abwesenheitsantrag in Flow

Teams

Microsoft Teams ist der Newcomer unter den SaaS-Angeboten von Microsoft und wurde in letzter Zeit extrem stark um Funktionen erweitert, vermutlich um Slack eine Konkurrenz entgegenzustellen. Gleichzeitig vereint Teams als Plattform Funktionen, die es vorher schon gab, wie zum Beispiel SharePoint Websites, Dokumentenaustausch, Instant Messaging und Einbindung von Drittanbieterinhalten über Konnektoren.

Überlegungen zu Governance, Policies und Lebenszyklen wurden daher im Grunde auch schon früher für SharePoint-Teamsites angestellt. In Office 365 sollte man daher die Governance für Teams genauso planen und definieren wie bei den anderen Produkten, um Wildwuchs, Datenmüll und mögliche Compliance-Probleme zu vermeiden. Die Dokumentation zur die Governance-Planung in Teams gibt als Startpunkt einen sehr guten Überblick über die relevanten Fragestellungen und wie man sie konfiguriert, unter anderem:

  • Namenskonvention für Teams (werden zugehörige Office 365 Groups im AAD sowie Mailadressen angelegt?)
  • Lebenszyklus von Teams (wann werden Teams wieder dekommissioniert?)
  • Data Retention Policies (sollen die Daten aufbewahrt werden?) und Data Loss Prevention
  • External Sharing (dürfen Gäste, also externe Anwender, dem Team hinzugefügt werden?)
  • Wer darf Teams erstellen und Mitglieder pflegen?

Über mindestens diese Punkte sollte man sich vor einer Einführung Gedanken machen und entsprechende Funktionen über das Teams Admin Center konfigurieren.

Nun kann man Teams aber nicht nur als Plattform für zeitlich begrenzte Zusammenarbeit in Projekten nutzen, sondern es kann wegen die reichhaltigen Funktionen wie Chat, Channels, Einbindung von SharePoint-Apps und Inhalten auch ein Portal beziehungsweise Hub oder Cockpit für Unternehmensprozesse sein.

Durch den integrierenden Ansatz von Teams kann man recht einfach auf bestehende Daten aus Backend-Systemen zugreifen und diese im Teams Frontend über Channels einbinden und zusammenführen. Wo man früher aufwendige Clientapplikationen bauen musste, können die Teams-basierten Applikationen im Webbrowser, mobil oder in einer Clientanwendungen auf dem Desktop-PC genutzt werden.

Auf gehts

Die Möglichkeiten von Office 365 sind vielfältig, insbesondere wenn man die bestehenden Tools mit Azure Services oder eigenem Code kombiniert. Die Herausforderung ist allerdings, eine Lösungsarchitektur im Rahmen einer unternehmensweiten Governance zu definieren. Hat man diese initial definiert, muss man sie regelmäßig überprüfen und verwalten. Dann stehen den Anwendern sowohl für individuelle Use Cases als auch für abteilungsübergreifende und unternehmensweite Prozesse umfangreiche Möglichkeiten zur Verfügung, um die Produktivität zu steigern und Arbeit effizienter zu gestalten.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -