Esta desconexión entre la funcionalidad de creación de formularios en las suites de BPM y las necesidades de los usuarios del flujo de trabajo (generar documentos sofisticados y listos para su tramitación dentro del flujo de trabajo) es el resultado del enfoque centrado en los datos que adoptan los proveedores de BPM. El enfoque centrado en los datos (que, a efectos de este documento, se define como la información recopilada por motivos distintos a la generación de documentos y que luego se reutiliza para la generación de documentos) es eficaz para cualquier número de escenarios de flujo de trabajo.
Sin embargo, el enfoque basado en los datos tiene sus limitaciones en los flujos de trabajo que incluyen subprocesos para generar documentos legales complejos, como contratos, que pueden requerir cientos de elementos de datos discretos además de los que una empresa pueda tener almacenados en sus registros de datos existentes. Más allá del mero volumen de información específica de los documentos que puede ser necesario recopilar, existe la estructura inherente y basada en reglas de los propios documentos, que dicta cuándo y si es necesario recopilar elementos de datos discretos.
Para recopilar con precisión toda la información necesaria para un documento, establecer las condiciones en las que se recopila la información y, en última instancia, utilizarla para generar un documento (o conjunto de documentos) listo para la transacción, los arquitectos de flujos de trabajo deben adoptar un enfoque diferente: un enfoque que dé prioridad al documento. El enfoque que da prioridad al documento, como su nombre indica, requiere que el arquitecto de flujos de trabajo incorpore reglas de negocio en el documento o documentos antes de comenzar el proceso de creación de formularios de recopilación de datos.
El enfoque basado en documentos requiere el empleo de una clase adicional de tecnología: el software de generación de documentos, que no solo permite modelar los documentos (incorporando la lógica empresarial en ellos), sino que también permite el diseño interactivo de formularios basados en la estructura y los requisitos de datos de los documentos en cuestión. Las plataformas de generación de documentos de nivel empresarial proporcionan API para BPM y otras integraciones de aplicaciones web.
El enfoque centrado en los documentos
El proceso de creación de formularios de recopilación de datos con el fin de generar documentos comienza con los propios documentos. Un arquitecto debe primero incorporar la lógica empresarial en un documento, un proceso comúnmente conocido como modelado de documentos. Solo después de que el documento esté completamente modelado (automatizado), el arquitecto sabrá qué datos deben recopilarse y en qué condiciones.
La estructura basada en reglas de los documentos legales
La mayoría de los tipos de documentos legales tienen una estructura inherente: una combinación de texto estándar, texto condicional, texto repetitivo y variables simples/calculadas. Tomemos, por ejemplo, el contrato de venta representado en la figura 1.
El contrato, que obviamente no está destinado a un uso real, es muy sencillo y representa solo una pequeña parte de los tipos de estructura que podrían existir en un instrumento jurídico real. Aun así, el documento está muy estructurado, como se aprecia en la codificación por colores:
- Azul: texto estándar (incluido en el documento en todos los casos).
- Rojo: texto condicional (incluido en el documento solo si las partes acuerdan un pago estructurado).
- Morado: texto condicional (incluido solo si hay elementos adicionales).
- Verde: texto repetido anidado dentro de texto condicional (el texto repetido solo se incluye si se incluye el texto morado que hay encima).
Tenga en cuenta también que el texto en cursiva del documento de ejemplo representa variables simples (variables no calculadas) y que el texto subrayado representa variables calculadas, de las cuales hay tres: (1) el importe de la cuota mensual (el resultado de sumar el interés simple al precio de compra y dividirlo por el número de meses del pago), (2) la palabra «are» (forma plural de «is») y (3) la palabra «items» (forma plural de «item»). Por supuesto, ambas palabras plurales pasarían a ser singulares si solo se incluyera un artículo en la venta.
En la figura 2 se muestra una versión automatizada del contrato de venta simple.
Con las reglas de negocio aplicadas, la estructura inherente del documento es aún más evidente. El texto condicional se anida dentro de sentencias IF. El texto repetitivo (la lista de artículos incluidos en la venta) se anida dentro de una sentencia REPEAT, que a su vez se anida dentro de una sentencia IF. El texto repetitivo no se anida dentro de una sentencia IF, lo que significa que se incluirá en el documento en todas las condiciones.
Es importante señalar que varias variables se fusionan en el texto estándar y el texto condicional. En prácticamente todas las plataformas de generación de documentos, las variables utilizadas en el documento se convierten en preguntas en los formularios.
La estructura reflexiva de los formularios de recopilación de información
La premisa subyacente detrás de los formularios diseñados para la generación de documentos es hacer solo las preguntas que son necesarias para armar el documento o los documentos. En otras palabras, dada toda la programación condicional en documentos complejos, muchas preguntas (tal vez docenas o incluso cientos) serían irrelevantes para un asunto en particular, dado un conjunto de condiciones existente. Presentar tales preguntas en los formularios sería una distracción, llevaría mucho tiempo y podría confundir a los usuarios del flujo de trabajo. Es este concepto —formular solo las preguntas pertinentes— el que crea el vínculo inexorable entre la estructura del documento y la estructura de los formularios, cuya estructura debe reflejar la lógica de scripting incorporada en los documentos.
Texto estándar = Preguntas estándar
El texto estándar siempre se incluye en un documento. Por lo tanto, las variables fusionadas en el texto estándar deben mostrarse como preguntas en un formulario en todas las circunstancias. Por ejemplo, en el contrato de venta de ejemplo, el texto estándar incluye varias variables simples. Dado que todas estas variables se fusionan en el texto estándar, podrían agruparse en el mismo formulario, que se mostraría en todas las circunstancias cada vez que se generara el documento (véase la figura 3).
Texto condicional = Preguntas condicionales
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).
Repetición de texto
Las variables fusionadas en el texto dentro de una instrucción REPEAT son, en sí mismas, variables repetidas. Dada la forma en que se escribe la lógica de negocio en el contrato de venta de ejemplo, hay que plantearse una pregunta que determinará cuántos campos se mostrarán en el formulario para los elementos incluidos (véase la figura 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).
Aunque el contrato de venta de ejemplo es extremadamente sencillo, muestra dos puntos clave: que los documentos tienen una estructura basada en reglas y que la estructura del documento debe reflejarse en la estructura de los formularios para que solo se hagan las preguntas relevantes según las condiciones existentes.
Formularios avanzados para flujos de trabajo de generación de documentos
Debido a la naturaleza de muchos tipos de documentos legales (basados en normas, con grandes conjuntos de datos, complejos), a menudo se requieren varios formularios de recopilación de información para un documento o conjunto de documentos. Esta secuencia de formularios se conoce comúnmente como entrevista. Una entrevista bien diseñada debe ir más allá de simplemente hacer preguntas; en realidad, debe guiar y ayudar a los usuarios del flujo de trabajo a obtener la respuesta correcta a cada pregunta introducida. Algunas de las características que garantizan la calidad de las respuestas son las siguientes:
- Validación del rango
- Recursos
- Vista general
- Respuestas obligatorias
- Selección de respuestas
- Formularios interactivos
- Formas condicionales
Validación de rango
La validación de rango es un método mediante el cual un arquitecto puede garantizar que una respuesta se encuentre dentro de un rango aceptable. Por ejemplo, el plazo aceptable para un pago estructurado podría fijarse entre 12 y 48 meses, dependiendo de las condiciones negociadas. Una pregunta validada no aceptará una respuesta que se encuentre fuera del rango prescrito. La validación de rango es posible para cualquier variable numérica o de fecha y se utiliza con frecuencia para eliminar la posibilidad de exposición legal como resultado de un error tipográfico o una respuesta incorrecta.
Recursos
Un recurso es una pantalla de ayuda que se puede adjuntar a cualquier pregunta específica. Un recurso puede incluir una explicación sobre cómo responder correctamente a la pregunta, hipervínculos a recursos externos o ayudas técnicas, como una hoja de cálculo o una calculadora, para ayudar al usuario del flujo de trabajo a llegar a la respuesta correcta.
Vista general
En el contexto de una entrevista que consta de docenas de formularios sencillos, interactivos y condicionales, resulta extremadamente útil, si no imprescindible, que los usuarios del flujo de trabajo puedan visualizar un esquema de todos los formularios de una entrevista. Esta funcionalidad se conoce comúnmente como «vista de esquema» y debería ser una opción en las plataformas de automatización de documentos de nivel empresarial. Entre otras cosas, la vista de esquema permite a los usuarios del flujo de trabajo desplazarse fácilmente hacia atrás y hacia adelante entre los formularios de una entrevista.
Respuestas obligatorias
En el contexto de un formulario concreto, un diseñador de plantillas podría especificar que una pregunta debe responderse antes de pasar a la siguiente.
Selección de respuestas
Para las variables que requieren una respuesta que se encuentre dentro de una lista predefinida (por ejemplo, condados dentro de un estado), se puede crear una lista desplegable para la variable. En otras palabras, en lugar de escribir la respuesta, el usuario simplemente la seleccionaría de una lista.
Formularios interactivos
Un formulario interactivo incluye tanto preguntas estándar (creadas a partir de variables fusionadas en texto estándar) como preguntas condicionales (creadas a partir de variables utilizadas en instrucciones de scripting o fusionadas en texto condicional) (véase la figura 4). La interactividad del formulario se debe a que la respuesta a una pregunta hace que se muestren otras preguntas dentro del formulario.
Formas condicionales
Los formularios condicionales son formularios completos de preguntas que solo se muestran si se dan determinadas condiciones. Estos formularios se crearían en situaciones en las que un documento incluyera grandes bloques de texto condicional, que a su vez incluyera muchos elementos de datos. Por supuesto, los formularios condicionales pueden ser interactivos, y a menudo lo son, lo que significa que las respuestas proporcionadas a algunas de las preguntas del formulario hacen que aparezcan otras preguntas en el formulario.
Integración de entrevistas de automatización de documentos con un flujo de trabajo
En un flujo de trabajo documental que incluye la generación de documentos complejos, el enfoque más sencillo consiste en sustituir los formularios BPM por una entrevista de generación de documentos diseñada para reflejar la estructura y la lógica empresarial del documento. Los datos ya disponibles, almacenados en una base de datos existente, pueden transferirse al flujo de trabajo y rellenar previamente los campos de los formularios creados en el sistema de generación de documentos. El resto de las preguntas pueden ser respondidas por las partes pertinentes que tienen acceso y derechos dentro del flujo de trabajo.
Una entrevista completada puede enviarse para su aprobación antes de la generación de documentos, y luego los documentos pueden volver al flujo de trabajo para su envío y aprobación.
Resumen
Cabe señalar que no todos los sistemas de generación de documentos hacen hincapié en el diseño y la elaboración sofisticados de entrevistas. Muchos sistemas se centran, en cambio, en la facilidad de uso, un enfoque que resulta especialmente adecuado para organizaciones que solo tienen unos pocos documentos sencillos o cuyo objetivo es generar un buen borrador inicial.
Sin embargo, para las empresas que producen documentación legal compleja y necesitan instrumentos listos para la transacción generados dentro del flujo de trabajo que no requieran edición posterior, es fundamental contar con un sistema de generación de documentos de nivel empresarial. Dicho sistema debe permitir cualquier nivel de modelado de documentos, independientemente de su complejidad, y debe facilitar el diseño y desarrollo de entrevistas reflexivas. Por último, un sistema de nivel empresarial permitirá su implementación en múltiples entornos y debe incluir API altamente evolucionadas con el fin de integrar el flujo de trabajo y otros sistemas.
Nota de la Redacción: Este artículo se publicó originalmente en HotDocs.com. En junio de 2024, Mitratech adquirió la plataforma avanzada de automatización de documentos, HotDocs. El contenido ha sido actualizado desde entonces para incluir información alineada con nuestra oferta de productos, cambios en la regulación y cumplimiento.
