Ce décalage entre les fonctionnalités de création de formulaires des suites BPM et les besoins des utilisateurs de workflows (qui souhaitent générer des documents sophistiqués et prêts à être traités dans le workflow) résulte de l'approche axée sur les données adoptée par les fournisseurs de BPM. L'approche axée sur les données (qui, dans le cadre du présent document, est définie comme les informations collectées à des fins autres que la génération de documents, puis réutilisées à cette fin) est efficace pour un grand nombre de scénarios de workflow.
Cependant, l'approche axée sur les données présente des lacunes dans les flux de travail comportant des sous-processus pour la génération de documents juridiques complexes, tels que des contrats, qui peuvent nécessiter des centaines d'éléments de données distincts en plus de ceux que l'entreprise a déjà stockés dans ses enregistrements de données existants. Au-delà du volume considérable d'informations spécifiques aux documents qui peuvent devoir être collectées, il faut tenir compte de la structure inhérente et basée sur des règles des documents eux-mêmes, qui dicte quand et si des éléments de données distincts doivent être collectés.
Pour recueillir avec précision toutes les informations nécessaires à un document, définir les conditions dans lesquelles ces informations sont recueillies et, enfin, utiliser ces informations pour générer un document (ou un ensemble de documents) prêt à être traité, les architectes de flux de travail doivent adopter une approche différente, à savoir une approche axée sur le document. Comme son nom l'indique, l'approche axée sur le document exige que l'architecte de flux de travail intègre des règles métier dans le ou les documents avant de commencer à créer des formulaires de collecte de données.
L'approche axée sur les documents nécessite l'utilisation d'une technologie supplémentaire : un logiciel de génération de documents, qui permet non seulement de modéliser les documents (en y intégrant la logique métier), mais aussi de concevoir des formulaires interactifs en fonction de la structure et des exigences en matière de données des documents concernés. Les plateformes de génération de documents d'entreprise fournissent des API pour l'intégration de BPM et d'autres applications web.
L'approche axée sur les documents
Le processus de création de formulaires de collecte de données dans le but de générer des documents commence par les documents eux-mêmes. Un architecte doit d'abord intégrer la logique métier dans un document, un processus communément appelé modélisation de document. Ce n'est qu'une fois le document entièrement modélisé (automatisé) que l'architecte saura quelles données doivent être collectées et dans quelles conditions.
La structure fondée sur des règles des documents juridiques
La plupart des types de documents juridiques ont une structure inhérente : une combinaison de texte standard, de texte conditionnel, de texte répétitif et de variables simples/calculées. Prenons, par exemple, le contrat de vente représenté dans la figure 1.
Le contrat, qui n'est évidemment pas destiné à être utilisé dans la réalité, est très simple et ne représente qu'une fraction des types de structures qui pourraient exister dans un instrument juridique réel. Néanmoins, le document est très structuré, comme le montre le code couleur :
- Bleu — texte standard (inclus dans le document dans tous les scénarios).
- Rouge — texte conditionnel (inclus dans le document uniquement si les parties conviennent d'un paiement structuré).
- Violet — texte conditionnel (inclus uniquement si des éléments supplémentaires sont concernés).
- Vert — texte répétitif imbriqué dans un texte conditionnel (le texte répétitif n'est inclus que si le texte violet situé au-dessus est inclus).
Notez également que le texte en italique dans l'exemple de document représente des variables simples (variables non calculées) et que le texte souligné représente des variables calculées, dont il existe trois : (1) le montant du versement mensuel (résultat de l'ajout des intérêts simples au prix d'achat et de la division par le nombre de mois du versement), (2) le mot « are » (forme plurielle de « is ») et (3) le mot « items » (forme plurielle de « item »). Ces deux mots pluriels deviendraient bien sûr singuliers si un seul article était inclus dans la vente.
Une version automatisée du contrat de vente simple est représentée à la figure 2.
Une fois les règles métier appliquées, la structure inhérente au document est encore plus évidente. Le texte conditionnel est imbriqué dans des instructions IF. Le texte répétitif (la liste des articles inclus dans la vente) est imbriqué dans une instruction REPEAT, qui est elle-même imbriquée dans une instruction IF. Le texte standard n'est pas imbriqué dans une instruction IF, ce qui signifie qu'il sera inclus dans le document dans toutes les conditions.
Il est important de noter que plusieurs variables sont fusionnées dans le texte standard et le texte conditionnel. Avec pratiquement toutes les plateformes de génération de documents, les variables utilisées dans le document deviennent des questions dans les formulaires.
La structure réflexive des formulaires de collecte d'informations
Le principe sous-jacent des formulaires conçus pour la génération de documents est de ne poser que les questions nécessaires à l'assemblage du ou des documents. En d'autres termes, compte tenu de tous les scripts conditionnels présents dans les documents complexes, de nombreuses questions (peut-être des dizaines, voire des centaines) seraient sans rapport avec un sujet particulier, étant donné un ensemble de conditions existantes. Présenter ces questions dans les formulaires serait source de distraction, prendrait du temps et pourrait induire en erreur les utilisateurs du flux de travail. C'est ce concept, qui consiste à ne poser que les questions pertinentes, qui crée le lien inextricable entre la structure du document et la structure du formulaire, laquelle doit refléter la logique de script intégrée dans les documents.
Texte standard = Questions standard
Le texte standard est toujours inclus dans un document. Par conséquent, les variables fusionnées dans le texte standard doivent être affichées sous forme de questions dans un formulaire en toutes circonstances. Par exemple, dans l'exemple de contrat de vente, le texte standard comprend plusieurs variables simples. Comme toutes ces variables sont fusionnées dans le texte standard, elles pourraient être regroupées dans le même formulaire, qui serait affiché en toutes circonstances à chaque fois que le document serait généré (voir figure 3).
Texte conditionnel = Questions conditionnelles
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).
Répétition de texte
Les variables fusionnées dans le texte au sein d'une instruction REPEAT sont elles-mêmes des variables répétitives. Compte tenu de la manière dont la logique métier est écrite dans l'exemple de contrat de vente, il convient de poser une question qui déterminera le nombre de champs qui s'afficheront dans le formulaire pour les éléments inclus (voir figure 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).
Bien que l'exemple de contrat de vente soit extrêmement simple, il illustre néanmoins deux points essentiels : les documents ont une structure basée sur des règles et cette structure doit se refléter dans la structure des formulaires afin de ne poser que les questions pertinentes en fonction des conditions existantes.
Formulaires avancés pour les flux de travail de génération de documents
En raison de la nature de nombreux types de documents juridiques (basés sur des règles, contenant de grands ensembles de données, complexes), plusieurs formulaires de collecte d'informations sont souvent nécessaires pour un document ou un ensemble de documents. Une telle séquence de formulaires est communément appelée « entretien ». Un entretien bien conçu doit aller au-delà de la simple pose de questions ; il doit en fait guider et aider les utilisateurs du flux de travail à obtenir la réponse correcte à chaque question saisie. Voici quelques-unes des fonctionnalités qui garantissent la qualité des réponses :
- Validation de la plage
- Ressources
- Vue schématique
- Réponses obligatoires
- Sélection de réponse
- Formulaires interactifs
- Formes conditionnelles
Validation de plage
La validation de plage est une méthode permettant à un architecte de s'assurer qu'une réponse se situe dans une plage acceptable. Par exemple, la durée acceptable pour un versement structuré pourrait être fixée entre 12 et 48 mois, en fonction des conditions négociées. Une question validée n'acceptera pas de réponse qui se situe en dehors de la plage prescrite. La validation de plage est possible pour toute variable numérique ou de date et est fréquemment utilisée pour éliminer le risque d'exposition juridique résultant d'une erreur typographique ou d'une réponse erronée.
Ressources
Une ressource est un écran d'aide qui peut être associé à une question spécifique. Une ressource peut inclure une explication sur la manière de répondre correctement à la question, des hyperliens vers des ressources externes ou des aides techniques, telles qu'un tableur ou une calculatrice, afin d'aider l'utilisateur du flux de travail à trouver la bonne réponse.
Vue d'ensemble
Dans le cadre d'un entretien composé de dizaines de formulaires simples, interactifs et conditionnels, il est extrêmement utile, voire essentiel, que les utilisateurs du flux de travail puissent visualiser un aperçu de tous les formulaires d'un entretien. Cette fonctionnalité, communément appelée « vue d'ensemble », devrait être disponible dans les plateformes d'automatisation de documents destinées aux entreprises. Entre autres choses, la vue d'ensemble permet aux utilisateurs du flux de travail de naviguer facilement entre les formulaires d'un entretien.
Réponses obligatoires
Dans le contexte d'un formulaire particulier, un architecte de modèles pourrait désigner qu'une question doit être répondue avant de passer à la question suivante.
Sélection de la réponse
Pour les variables nécessitant une réponse figurant dans une liste prédéfinie (par exemple, les comtés d'un État), une liste déroulante peut être créée pour la variable. En d'autres termes, plutôt que de saisir la réponse, l'utilisateur la sélectionne simplement dans une liste.
Formulaires interactifs
Un formulaire interactif comprend à la fois des questions standard (créées à partir de variables fusionnées dans un texte standard) et des questions conditionnelles (créées à partir de variables utilisées dans des instructions de script ou fusionnées dans un texte conditionnel) (voir figure 4). L'interactivité du formulaire résulte du fait que la réponse à une question entraîne l'affichage d'autres questions dans le formulaire.
Formes conditionnelles
Les formulaires conditionnels sont des formulaires complets qui ne s'affichent que si certaines conditions sont remplies. Ces formulaires sont créés lorsque le document contient de grands blocs de texte conditionnel, qui comprennent eux-mêmes de nombreux éléments de données. Les formulaires conditionnels peuvent bien sûr être interactifs, ce qui est souvent le cas. Cela signifie que les réponses fournies à certaines questions du formulaire entraînent l'apparition d'autres questions dans le formulaire.
Intégration des entretiens automatisés avec un flux de travail
Dans un flux de travail documentaire qui inclut la génération de documents complexes, l'approche la plus simple consiste à remplacer les formulaires BPM par un questionnaire de génération de documents conçu pour refléter la structure et la logique métier du document. Les données déjà disponibles, stockées dans une base de données existante, peuvent être transférées dans le flux de travail et préremplir les champs des formulaires créés dans le système de génération de documents. Les autres questions peuvent être répondues par les parties concernées qui ont accès et disposent des droits nécessaires dans le flux de travail.
Une fois l'entretien terminé, il peut être soumis pour approbation avant la génération des documents, puis les documents peuvent être renvoyés dans le flux de travail pour être acheminés et approuvés.
Résumé
Il convient de noter que tous les systèmes de génération de documents ne mettent pas l'accent sur la conception et la construction sophistiquées d'entretiens. De nombreux systèmes se concentrent plutôt sur la facilité d'utilisation, une approche qui convient particulièrement aux organisations qui ne disposent que de quelques documents simples ou dont l'objectif est de produire un bon premier jet.
Cependant, pour les entreprises qui produisent des documents juridiques complexes et ont besoin d'instruments prêts à l'emploi générés dans le cadre du flux de travail et ne nécessitant aucune modification a posteriori, un système de génération de documents de niveau entreprise est essentiel. Un tel système doit permettre tous les niveaux de modélisation de documents, quelle que soit leur complexité, et faciliter la conception et le développement d'entretiens réflexifs. Enfin, un système de niveau entreprise doit pouvoir être déployé dans plusieurs environnements et inclure des API hautement évoluées à des fins d'intégration dans le flux de travail et d'autres systèmes.
Note de la rédaction : Ce billet a été publié à l'origine sur HotDocs.com. En juin 2024, Mitratech a acquis HotDocs, une plateforme avancée d'automatisation des documents. Le contenu a depuis été mis à jour pour inclure des informations alignées sur nos offres de produits, les changements de réglementation et la conformité.
