Diese Diskrepanz zwischen der Formularerstellungsfunktion in BPM-Suiten und den Anforderungen der Workflow-Benutzer (die innerhalb des Workflows komplexe, transaktionsfähige Dokumente erstellen möchten) resultiert aus dem datenorientierten Ansatz der BPM-Anbieter. Der datenorientierte Ansatz (der für die Zwecke dieses Artikels als Informationen definiert wird, die aus anderen Gründen als der Dokumentenerstellung gesammelt und dann für die Dokumentenerstellung wiederverwendet werden) ist für eine Vielzahl von Workflow-Szenarien effektiv.
Der Daten-First-Ansatz stößt jedoch an seine Grenzen, wenn es um Arbeitsabläufe mit Teilprozessen zur Erstellung komplexer Rechtsdokumente geht – beispielsweise Verträge –, für die möglicherweise Hunderte von diskreten Datenelementen zusätzlich zu den Daten erforderlich sind, die ein Unternehmen in seinen bestehenden Datensätzen gespeichert hat. Über die schiere Menge an dokumentspezifischen Informationen hinaus, die möglicherweise gesammelt werden müssen, gibt es die inhärente, regelbasierte Struktur der Dokumente selbst, die vorschreibt, wann und ob überhaupt diskrete Datenelemente gesammelt werden müssen.
Um alle für ein Dokument erforderlichen Informationen genau zu erfassen, die Bedingungen für die Erfassung der Informationen festzulegen und die Informationen schließlich zur Erstellung eines transaktionsbereiten Dokuments (oder einer Reihe von Dokumenten) zu verwenden, müssen Workflow-Architekten einen anderen Ansatz verfolgen – einen dokumentorientierten Ansatz. Der dokumentorientierte Ansatz erfordert, wie der Name schon sagt, dass ein Workflow-Architekt Geschäftsregeln in das/die Dokument(e) einbaut, bevor er mit der Erstellung von Formularen zur Datenerfassung beginnt.
Der dokumentorientierte Ansatz erfordert den Einsatz einer zusätzlichen Technologieklasse – Software zur Dokumentenerstellung, die nicht nur die Modellierung der Dokumente (Einbindung von Geschäftslogik in die Dokumente) ermöglicht, sondern auch die interaktive Formularerstellung auf der Grundlage der Struktur und der Datenanforderungen der betreffenden Dokumente. Dokumentenerstellungsplattformen für Unternehmen bieten APIs für BPM und andere Webanwendungsintegrationen.
Der dokumentorientierte Ansatz
Der Prozess der Erstellung von Formularen zur Datenerfassung zum Zweck der Dokumentenerstellung beginnt mit den Dokumenten selbst. Ein Architekt muss zunächst die Geschäftslogik in ein Dokument einbauen, ein Prozess, der gemeinhin als Dokumentmodellierung bezeichnet wird. Erst nachdem das Dokument vollständig modelliert (automatisiert) ist, weiß der Architekt, welche Daten unter welchen Bedingungen erfasst werden müssen.
Die regelbasierte Struktur von Rechtsdokumenten
Die meisten Arten von Rechtsdokumenten haben eine inhärente Struktur: eine Kombination aus Standardtext, bedingtem Text, sich wiederholendem Text und einfachen/berechneten Variablen. Nehmen wir zum Beispiel den in Abbildung 1 dargestellten Kaufvertrag.
Der Vertrag, der offensichtlich nicht für den tatsächlichen Gebrauch bestimmt ist, ist sehr einfach und stellt nur einen Bruchteil der Arten von Strukturen dar, die in einem tatsächlichen Rechtsinstrument vorkommen können. Dennoch ist das Dokument stark strukturiert, wie die Farbcodierung zeigt:
- Blau – Standardtext (in allen Szenarien im Dokument enthalten).
- Rot – bedingter Text (nur dann im Dokument enthalten, wenn die Parteien einer strukturierten Auszahlung zustimmen).
- Lila – bedingter Text (nur enthalten, wenn zusätzliche Elemente beteiligt sind).
- Grün – sich wiederholender Text, der in bedingten Text eingebettet ist (Der sich wiederholende Text wird nur angezeigt, wenn der violette Text darüber angezeigt wird.)
Beachten Sie auch, dass kursiv gedruckter Text im Beispieldokument einfache Variablen (nicht berechnete Variablen) darstellt und dass unterstrichener Text berechnete Variablen darstellt, von denen es drei gibt: (1) die Höhe der monatlichen Ratenzahlung (das Ergebnis der Addition der einfachen Zinsen zum Kaufpreis und der Division durch die Anzahl der Monate der Auszahlung), (2) das Wort „are” (die Pluralform von „is”) und (3) das Wort „items” (die Pluralform von „item”). Beide Pluralwörter würden natürlich in den Singular übergehen, wenn nur ein Artikel im Verkauf enthalten wäre.
Eine automatisierte Version des einfachen Kaufvertrags ist in Abbildung 2 dargestellt.
Durch die Anwendung der Geschäftsregeln wird die inhärente Struktur des Dokuments noch deutlicher. Bedingter Text ist in IF-Anweisungen verschachtelt. Der sich wiederholende Text (die Liste der im Verkauf enthaltenen Artikel) ist in einer REPEAT-Anweisung verschachtelt, die wiederum in einer IF-Anweisung verschachtelt ist. Boilerplate-Text ist nicht in einer IF-Anweisung verschachtelt, was bedeutet, dass er unter allen Bedingungen in das Dokument aufgenommen wird.
Es ist wichtig zu beachten, dass mehrere Variablen in Boilerplate-Text und bedingten Text zusammengeführt werden. Bei praktisch allen Plattformen zur Dokumentenerstellung werden die im Dokument verwendeten Variablen zu Fragen in den Formularen.
Die reflexive Struktur von Formularen zur Informationsbeschaffung
Die Grundidee hinter Formularen, die für die Dokumentenerstellung konzipiert sind, besteht darin, nur die Fragen zu stellen, die für die Erstellung des Dokuments bzw. der Dokumente erforderlich sind. Mit anderen Worten: Angesichts der vielen bedingten Skripte in komplexen Dokumenten wären viele Fragen (möglicherweise Dutzende oder sogar Hunderte) unter den gegebenen Bedingungen für einen bestimmten Sachverhalt irrelevant. Die Darstellung solcher Fragen in den Formularen würde die Benutzer des Workflows ablenken, Zeit kosten und möglicherweise irreführen. Es ist dieses Konzept – nur die relevanten Fragen zu stellen –, das die unaufhaltsame Verbindung zwischen Dokumentstruktur und Formularstruktur herstellt, wobei die Struktur die in die Dokumente integrierte Skriptlogik widerspiegeln muss.
Boilerplate-Text = Boilerplate-Fragen
Boilerplate-Text ist immer in einem Dokument enthalten. Daher müssen Variablen, die in Boilerplate-Text eingebunden sind, unter allen Umständen als Fragen in einem Formular angezeigt werden. Im Beispiel des Kaufvertrags enthält der Boilerplate-Text beispielsweise mehrere einfache Variablen. Da alle diese Variablen in Boilerplate-Text eingebunden sind, könnten sie in einem Formular zusammengefasst werden, das unter allen Umständen bei jeder Generierung des Dokuments angezeigt würde (siehe Abbildung 3).
Bedingter Text = Bedingte Fragen
Variables merged into conditional text must be displayed as questions in a form only if the appropriate conditions exist. For instance, in the example sales contract within the structured payout clause, a simple variable is merged (<NUMBER OF MONTHS OF PAYOUT>). A question for this variable would only be asked in a form if the answer to a previous question were yes (See Figure 4).
Wiederholender Text
Variablen, die innerhalb einer REPEAT-Anweisung in Text zusammengeführt werden, sind selbst Wiederholungsvariablen. Angesichts der Art und Weise, wie die Geschäftslogik in den Beispiel-Kaufvertrag geschrieben ist, muss eine Frage gestellt werden, die bestimmt, wie viele Felder im Formular für die enthaltenen Elemente angezeigt werden (siehe Abbildung 5).
Note, again, that the repeating text in the simple sales contract is, itself, nested inside an IF statement, meaning that the repeating text will only be included if a particular condition exists (IF <INCLUDED ITEMS> = YES).
Der Musterkaufvertrag ist zwar äußerst einfach, verdeutlicht jedoch zwei wichtige Punkte: Dokumente haben eine regelbasierte Struktur, und diese Dokumentstruktur muss sich in der Formularstruktur widerspiegeln, damit nur die relevanten Fragen auf der Grundlage der bestehenden Bedingungen gestellt werden.
Erweiterte Formulare für Workflows zur Dokumentenerstellung
Aufgrund der Beschaffenheit vieler Arten von Rechtsdokumenten – regelbasiert, große Datenmengen, komplex – sind für ein Dokument oder eine Reihe von Dokumenten oft mehrere Formulare zur Informationserfassung erforderlich. Eine solche Abfolge von Formularen wird gemeinhin als Interview bezeichnet. Ein gut konzipiertes Interview sollte über das reine Stellen von Fragen hinausgehen; es sollte die Workflow-Benutzer tatsächlich anleiten und dabei unterstützen, die richtige Antwort auf jede Frage einzugeben. Einige der Funktionen, die die Qualität der Antworten sicherstellen, sind folgende:
- Bereichsvalidierung
- Ressourcen
- Übersichtsansicht
- Erforderliche Antworten
- Auswahl der Antwort
- Interaktive Formulare
- Bedingte Formen
Bereichsvalidierung
Die Bereichsvalidierung ist eine Methode, mit der ein Architekt sicherstellen kann, dass eine Antwort innerhalb eines akzeptablen Bereichs liegt. Beispielsweise könnte die akzeptable Laufzeit für eine strukturierte Auszahlung je nach den ausgehandelten Bedingungen auf 12 bis 48 Monate festgelegt werden. Eine validierte Frage akzeptiert keine Antwort, die außerhalb des vorgegebenen Bereichs liegt. Die Bereichsvalidierung ist für jede numerische oder Datumsvariable möglich und wird häufig verwendet, um das Risiko rechtlicher Konsequenzen aufgrund von Tippfehlern oder anderen falschen Antworten auszuschließen.
Ressourcen
Eine Ressource ist ein Hilfebildschirm, der an jede beliebige Frage angehängt werden kann. Eine Ressource kann eine Erklärung zur richtigen Beantwortung der Frage, Hyperlinks zu externen Ressourcen oder technische Hilfsmittel wie eine Tabellenkalkulation oder einen Taschenrechner enthalten, die dem Benutzer des Workflows dabei helfen, die richtige Antwort zu finden.
Übersichtsansicht
Im Rahmen eines Interviews, das aus Dutzenden einfacher, interaktiver und bedingter Formulare besteht, ist es äußerst hilfreich, wenn nicht sogar entscheidend, dass Workflow-Benutzer sich einen Überblick über alle Formulare eines Interviews verschaffen können. Diese Funktion wird gemeinhin als Gliederungsansicht bezeichnet und sollte in Dokumentenautomatisierungsplattformen für Unternehmen als Option verfügbar sein. Unter anderem ermöglicht die Gliederungsansicht Workflow-Benutzern das einfache Vor- und Zurückblättern zwischen den Formularen eines Interviews.
Erforderliche Antworten
Im Rahmen eines bestimmten Formulars könnte ein Template-Architekt festlegen, dass eine Frage beantwortet werden muss, bevor zur nächsten Frage übergegangen werden kann.
Auswahl der Antwort
Für Variablen, deren Antwort aus einer vordefinierten Liste ausgewählt werden muss (z. B. Bezirke innerhalb eines Bundesstaates), kann eine Dropdown-Liste für die Variable erstellt werden. Das bedeutet, dass der Benutzer die Antwort nicht eingeben muss, sondern sie einfach aus einer Liste auswählen kann.
Interaktive Formulare
Ein interaktives Formular enthält sowohl Standardfragen (die aus Variablen erstellt werden, die in Standardtext eingefügt werden) als auch bedingte Fragen (die aus Variablen erstellt werden, die in Skriptanweisungen verwendet oder in bedingten Text eingefügt werden) (siehe Abbildung 4). Die Interaktivität des Formulars ergibt sich daraus, dass die Antwort auf eine Frage dazu führt, dass weitere Fragen im Formular angezeigt werden.
Bedingte Formen
Bedingte Formulare sind vollständige Fragebögen, die nur angezeigt werden, wenn bestimmte Bedingungen erfüllt sind. Solche Formulare werden in Situationen erstellt, in denen ein Dokument große Blöcke mit bedingtem Text enthält, der wiederum viele Datenelemente umfasst. Bedingte Formulare können natürlich interaktiv sein – und sind es oft auch –, was bedeutet, dass die Antworten auf einige der Fragen im Formular dazu führen, dass weitere Fragen im Formular angezeigt werden.
Integration von Dokumentenautomatisierungs-Interviews in einen Workflow
In einem Dokumenten-Workflow, der die Erstellung komplexer Dokumente umfasst, ist es am einfachsten, BPM-Formulare durch ein Dokumentenerstellungsinterview zu ersetzen, das so gestaltet ist, dass es die Struktur und Geschäftslogik des Dokuments widerspiegelt. Bereits vorhandene Daten, die in einer bestehenden Datenbank gespeichert sind, können in den Workflow übernommen werden und Felder in Formularen, die im Dokumentenerstellungssystem erstellt wurden, vorab ausfüllen. Die restlichen Fragen können von den entsprechenden Parteien beantwortet werden, die innerhalb des Workflows Zugriff und Rechte haben.
Ein abgeschlossenes Interview kann vor der Erstellung von Dokumenten zur Genehmigung weitergeleitet werden, und anschließend können die Dokumente zur Weiterleitung und Genehmigung wieder in den Workflow zurückgeführt werden.
Zusammenfassung
Es ist zu beachten, dass nicht alle Systeme zur Dokumentenerstellung Wert auf ein ausgeklügeltes Interviewdesign und eine komplexe Struktur legen. Viele Systeme konzentrieren sich stattdessen auf Benutzerfreundlichkeit, ein Ansatz, der besonders für Organisationen geeignet ist, die nur über wenige einfache Dokumente verfügen oder deren Ziel es ist, einen guten ersten Entwurf zu erstellen.
Für Unternehmen, die komplexe Rechtsdokumente erstellen und transaktionsbereite Instrumente benötigen, die innerhalb des Workflows generiert werden und keine nachträgliche Bearbeitung erfordern, ist jedoch ein Dokumentenerstellungssystem der Enterprise-Klasse von entscheidender Bedeutung. Ein solches System sollte jede Ebene der Dokumentenmodellierung ermöglichen, unabhängig davon, wie komplex die Dokumente sind, und sollte die reflexive Gestaltung und Entwicklung von Interviews erleichtern. Schließlich ermöglicht ein System der Enterprise-Klasse den Einsatz in mehreren Umgebungen und sollte hochentwickelte APIs für den Workflow und andere Systemintegrationen enthalten.
Anmerkung der Redaktion: Dieser Beitrag wurde ursprünglich veröffentlicht auf HotDocs.com. Im Juni 2024 erwarb Mitratech die fortschrittliche Dokumentenautomatisierungsplattform HotDocs. Der Inhalt wurde seither aktualisiert und enthält nun Informationen, die auf unser Produktangebot, Änderungen der Vorschriften und die Einhaltung von Vorschriften abgestimmt sind.
