So funktionieren Genehmigungs-Workflows in SharePoint

Ein SharePoint-Genehmigungs-Workflow unterstützt die Geschäftsprozesse in Unternehmen, denn durch ihn werden alle zur Genehmigung verbundenen Aufgaben verwaltet und an die entsprechenden Personen weitergeleitet, z.B. das Senden eines Dokuments zur Freigabe an Kollegen oder Vorgesetzte. Wie sieht das Konzept dahinter eigentlich genau aus? Und welche Fragen sollten Sie sich unbedingt stellen, bevor Sie einen Genehmigungs-Workflow aufsetzen?

Stellen wir uns eine typische Ausgangssituation vor, die so oder in ähnlicher Form immer wieder angefragt wird: In einer SharePoint-Dokumentenbibliothek, ganz egal ob mit oder ohne Ordnerstruktur, werden Dokumente bearbeitet. Die Dokumente unterliegen einer Versionierung und sind vor Veröffentlichung zu genehmigen.

Eine fixe Gruppe von Mitarbeitern besitzt Genehmigungsrechte. Aber nicht jeder berechtigte Mitarbeiter ist tatsächlich für jedes Dokument zuständig. Oft sind sie nur für einen Teil der Dokumente verantwortlich und sollten auch nur diese genehmigen dürfen. Außerdem benötigen sie ggf. die Option, Ihr Dokument von mehreren Instanzen genehmigen zu lassen oder sie besitzen Dokumente, die nicht genehmigt werden müssen.

Zudem haben Mitarbeiter berichtet, dass der Standard-Genehmigungsprozess des SharePoint, den sie „Out of the Box“ einsetzen können, nicht gerade eine intuitive Bedienung im Sinne der Anwender darstellt.

Finden Sie sich wieder? Dann empfehle ich Ihnen, weiterzulesen.

Bevor Sie beginnen, verschaffen Sie sich zunächst einen Überblick über Ihre Anforderungen zum Genehmigungsprozess. Sie lassen sich wie folgt ableiten:

• Für alle Dokumente ist eine Versionshistorie mit Haupt- und Nebenversionierung erforderlich
• Alle Dokumente sind anhand von Metadaten einzugliedern (Abteilung, Dokumententyp wie beispielsweise Vertrag, Angebot, Arbeitsanweisung; Präsentation, etc.)
• Die Auswahlwerte für die Metadaten sollen separat verwaltet werden
• Je nach Dokumentengruppierung (Eingliederung in die Metadaten) soll
  • keine Genehmigung stattfinden (sofortige Veröffentlichung)
  • ein Genehmigungsprozess gestartet werden, der einen Mitarbeiter zur Freigabe für diese Dokumentengruppe berechtigt, wobei die verschiedenen Genehmigungsgruppen administrativ verwaltet werden müssen und sich täglich ändern können
• Entsprechend der Rolle eines Mitarbeiters am Genehmigungsprozess, müssen ihm diverse E-Mails zugestellt werden. Einerseits um über die Zuständigkeit einer Genehmigungsaufgabe und anderseits um über den Fortschritt des Genehmigungsprozesses per E-Mail zu informieren.
  

Natürlich lässt sich solch ein Katalog wesentlich genauer und mit weiteren Anforderungen füllen. Hierfür bieten sich beispielhaft folgende Anforderungen an:

• Vertreter Regelungen (Ersatzgenehmigungen)
• Eskalationsprozesse
• Automatische Anforderung von Lesebestätigungen nach genehmigter Veröffentlichung
• Change Request Management
• Ablauf- und Archivierung
• Parallele und/oder serielle Abarbeitung von Genehmigungsaufgaben

Ungeachtet Ihres Anforderungskataloges soll die Lösung:

• Mit Bordmitteln von SharePoint umgesetzt werden
• Ohne Einsatz von Tools von Drittanbietern umgesetzt werden können
• Für alle SharePoint-Versionen (Foundation, Standard, Enterprise) eingesetzt werden können
• Ohne Einsatz von InfoPath-Formularen möglich sein
• Mittels SharePoint-Designer Workflows realisiert werden

Die Wahl der Mittel ist technisch limitiert und umfasst daher folgende Bestandteile:

• SharePoint Infrastruktur mit E-Mail-Ausgang (fertig konfiguriert)
• SharePoint Webseite mit SharePoint-Dokumentenbibliothek, nebst prozessunterstützender SharePoint-Listen (hierzu gleich mehr)
• SharePoint-Designer Workflows (ohne „Out of the Box“ Workflows)

Es empfiehlt sich auf Basis der Anforderungen zwingend ein detailliertes Flussdiagramm des Prozesses zu erstellen, das die Ausgangsbasis der Planung und die Konzeption der technischen Implementierung darstellt. Auf die Darstellung eines exakten Flussdiagramms wird an dieser Stelle verzichtet, da der Fokus des Beitrags auf der technischen Implementierung liegt, der universell eingesetzt werden kann.

Zu Beginn der technischen Konzeptionsphase fließen die Informationen des Anforderungskatalogs sowie die des geplanten Flussdiagramms und ergeben sehr stark vereinfacht, folgenden schematischen Prozessablauf:

Unter Berücksichtigung der gewählten Plattform SharePoint, inkl. aller spezifischen Eigenheiten & Anforderungen, können nun erste Ableitungen getroffen werden:

• Ein Workflow-Start zu dem Zeitpunkt, wenn ein Dokument erstmalig hochgeladen wird (Trigger: Neues Element) ist obsolet, da ein Dokument nach dem erstmaligen Hochladen im Genehmigungsstatus „Entwurf“ (Nebenversion) verbleibt, auf den systembedingt kein Workflow-Start erfolgt (Eigenschaft von Haupt- und Nebenversionierung)
• Ein Workflow-Start erfolgt erst, wenn der Genehmigungsstatus „Ausstehend“ erreicht wird und der Anwender die Option „Hauptversion veröffentlichen“ ausgewählt hat (Eigenschaft von Haupt- und Nebenversionierung)
• Alle für den Genehmigungsprozess beteiligten Datenfelder überschreiten beim angedachten Vorhaben die Limitierung von Bibliotheken und würden eine intuitive Bedienung nicht ermöglichen (SharePoint-Limitierungen). Es ist daher erforderlich den angedachten Prozess über mehrere Listen zusätzlich zur Dokumentenbibliothek zu verteilen.

Ungeachtet weiterer möglichen Ableitungen, die hier nicht näher betrachtet werden, kann der Genehmigungsprozess, wie folgt auf SharePoint übertragen werden:

Um Dokumente anhand ihrer Eigenschaften (Metadaten) mit jeweils abweichenden Genehmigern steuern zu können, wird eine Liste dieser Personen benötigt, um die Zusammenhänge wiederspiegeln zu können. Sowohl die Bibliothek „Dokumente“, wie auch die Liste „Genehmiger“ greifen dabei auf einen speziellen Mix aus Metadaten zurück. Die sogenannte Metadatenquelle, kann dabei auch ganz einfach aus Spalten mit Dropdown-Werten bestehen, die in der Dokumentenbibliothek und der Genehmiger-Liste in gleicher Form verfügbar sind. Ziel ist es beispielsweise, die Dokumente der Niederlassung X vom Typ Y von den Personen A, B und C genehmigen zu lassen. Dokumente der Niederlassung Z vom Typ Y jedoch von den Personen M, N und H. In der Liste „Genehmiger“ wird also innerhalb eines Listenelements festgelegt, für welche Zusammenstellung aus Niederlassung und Typ, eine Person die Dokumente einer speziellen Eingliederung des Dokumentes in Metadaten, ein solches Dokument dann genehmigen. Der Workflow „Prozess“ kennt dann später die Metadaten des Dokumentes und sucht anhand dieser in der Liste „Genehmiger“ die benötigten Personen zusammen.

Wir ein Dokument vom Anwender veröffentlicht, befindet es sich im Genehmigungsstatus „Ausstehend“. Aufgrund der Änderung (durch Veröffentlichung) am Dokument, startet der Workflow „Genehmigung“ in der Bibliothek „Dokumente“ und erstellt ein Element in der Liste „Genehmigungsprozesse“. Danach verbleibt der Workflow „Genehmigung“ bis zum Ausgang des Prozesses in der Wartestellung. Hierfür existiert am Dokument ein Feld, auf dessen Änderung gewartet wird. Das Feld muss mit dem Start eines Genehmigungsprozesses initial gefüllt werden, so dass eine Änderung am Ende des Genehmigungsprozesses auch abgefangen werden kann.

Durch die Erstellung des Elementes in der Liste „Genehmigungsprozesse“, startet der Workflow „Prozess“ und schlägt in der Bibliothek „Dokumente“ die benötigten Metadaten des Dokumentes nach. Mit diesen Metadaten schlägt der Workflow die erforderlichen Personen in der Liste „Genehmiger“ nach. Daraufhin wird für jeden Genehmiger ein Element in der Liste „Genehmigungsaufgaben“ angelegt, dass die jeweilige Aufgabe für die entsprechende Person darstellt. In diesem Element werden der Name, der Genehmigungsentscheid und die Zuordnung (Bindung) zum Element abgespeichert. Weiterhin wird in diesem Element ein Feld für den gesamten Genehmigungsstatus vorgehalten und mit dem Inhalt „Ausstehend“ initiiert. Im, pro Genehmiger, neu erstellten Element der Liste „Genehmigungsaufgaben“ werden mindestens der Name, der Genehmigungsentscheid (Initial „Ausstehend“), die Zuordnung zum Dokument und die Zuordnung zum Genehmigungsprozess gespeichert. Der Workflow „Prozess“ endet danach.

Durch die Erstellung des jeweils neuen erzeugten Elements in der Liste „Genehmigungsaufgaben“, startet an diesem der Workflow „Aufgabe“. Er stellt den berechtigten Personen eine E-Mail mit seiner Genehmigungsaufgabe zu. Danach endet der Workflow „Aufgabe“.

Die E-Mail sollte eine kurze Anleitung enthalten, die dem Genehmiger kurz erklärt was er zu tun hat sowie einen Link zum Dokument, das er genehmigen soll und einen Link zur Genehmigungsaufgabe. Die Genehmigungsaufgabe sollte über die Inhaltstypverwaltung auf die Felder „Genehmigungsentscheidung“ (Ausstehend, Genehmigt, Abgelehnt) und „Genehmigungskommentar“ in der Edit-Ansicht beschränkt sein.

Ein Genehmiger erhält eine E-Mail und nutzt die enthaltenen Links um seine Entscheidung abzugeben. Üblicherweise geschieht dies bei mehreren Personen zu unterschiedlichen Zeitpunkten.

Hat ein Genehmiger seine Entscheidung abgegeben, so startet der Workflow „Aufgabe“ erneut und aktualisiert das in der Liste „Genehmigungsprozesse“ zugehörige Element, dem es untergeordnet ist. Danach endet der Workflow „Aufgabe“ wieder. Der in der Abbildung eingezeichnete rote Pfeil, der vom Workflow „Aufgabe“ auf das Element „Genehmigungsaufgabe“ zurück zeigt, ist optional und signalisiert, dass Sie die Möglichkeit haben, weitere Informationen zu speichern, wenn die Genehmigung eingegangen ist (z.B. Datum der Ablehnung).

Durch die Änderung, die am Element der Liste „Genehmigungsprozesse“ ausgelöst wird, startet der Workflow „Prozess“ wieder und prüft alle Entscheide aller Genehmiger seines Prozesses, auf noch ausstehende Genehmigungen. Existieren noch welche, endet der Workflow „Prozess“ und wartet auf den nächsten Trigger aus der Liste „Genehmigungsaufgaben“. Sind dagegen alle Entscheide eingegangen, hat sich ein Gesamt-Genehmigungsstatus ergeben, der entweder „Genehmigt“ oder „Abgelehnt“ zur Folge hat. Dieser Status wird daraufhin am Dokument (dort in dem Feld auf dessen Feldänderung der Workflow „Genehmigung“ wartet) eingetragen. Danach endet der Workflow „Prozess“.

Durch die Feldänderung am Dokument, das nun den Gesamt-Genehmigungsstatus trägt, setzt der Workflow „Genehmigung“ fort und ändert den Status für die Inhaltsgenehmigung für das Dokument auf „Genehmigt“, respektive „Abgelehnt“. Danach endet der Workflow „Genehmigung“.

Dieser Artikel soll Sie in die Lage versetzen, das aufgezeigte Grundschema in die Praxis umzusetzen und gemäß Ihren Anforderungen weiter auszubauen. Je nach Ihren ganz speziellen Anforderungen, können Sie die aufgezeigte Modellierung Ihren Bedürfnissen anpassen und erweitern. Danach empfiehlt sich, weitere Schritte durchzuführen:

• Erstellung eines Datenmodells, das die Details jeder Bibliothek und Liste auf Feldebene wiederspiegelt sowie die zum Einsatz kommenden Metadaten (ggf. in separatem Metadatenkonzept) und Sichten auf die im SharePoint liegenden Daten. Beachten Sie hierbei auch, dass es versteckte Felder gibt, die für die Funktionalität benötigt werden, aber dem Anwender nicht sichtbar sind / sein müssen.
• Erstellung eines Berechtigungskonzepts, aus dem hervorgeht, wer welche Dokumente, Genehmigungsprozesse, Genehmigungsaufgaben, Genehmiger, einsehen, bzw. neu erstellen und/oder ändern kann. Beachten Sie, dass auch Ansichten auf Daten in Web Part Views Berechtigungen einfordern können. Dieses technische Mittel lässt sich ebenfalls gewinnbringend einsetzen.
• Implementierung, Dokumentation, Test und Freischaltung zur Nutzung