Business Process Management ProcessMaker AGPLv3 - Diseño de la arquitectura general del sistema. ProcessMaker se encuentra orientado a trabajar bajo plataforma Linux / Windows, desarrollado con software abierto como PHP para la programación del código fuente y como Servidor de aplicaciones Apache Server para el funcionamiento del sistema en un entorno Web; a continuación detallaremos los diferentes componentes del sistema: Cross Browser PDAs Arquitectura del Sistema ProcessMaker SOAP WS Reliable WS Security WSO2 MAIL SendMail PHP Mailer Open Mail LDAP Active Directory Rbac 3rd Party Libraries Gulliver PROPEL PHP Apache MySQL Postgres SQL Server, Oracle, etc Linux / Windows La arquitectura de ProcessMaker se encuentra sustentada con los siguientes componentes: 1.- WSO2, para el encriptamiento de información SSL de 128 bits para asegurar la confidencialidad e integridad de los datos que forman parte del flujo o al momento de establecer comunicación con otros sistemas a través del Web Services 2.- MAIL, para establecer la comunicación de correos a través de cuentas estándares como cuentas SMTP 3.- Rbac, para el manejo de Base de Datos de administración de cuentas de usuarios y con la capacidad de integrarse al directorio activo de Windows 4.- Incorporación de librerías plug in para la integración con otros sistemas 5.- GULLIVER, Framework de desarrollo. Gulliver está compuesto de una serie de clases que permitirán desarrollar nuestras nuevas funcionalidades de ProcessMaker.
6.- Cross Browser, permitiendo que el acceso a ProcessMaker sea desde cualquier browser como Internet Explorer, Netscape, Mozila y otros. Con lo que se garantiza que se puedan trabajar en cualquier tipo de plataforma como Windows 2000/ XP Professional / Linux / Web, etc. 7.- PROPEL, técnica de programación ORM (Object Relational Mapping) para convertir datos entre diferentes tipos de sistemas en Base de Datos Relacional orientado a Objetos. Esta técnica nos permitirá tener preparado el sistema para manejar Base de Datos Virtual orientado a Objetos y poder ser usado por cualquier lenguaje de programación y permitir de una manera más eficiente intercambiar información con cualquier Base de Datos (Oracle, SQL Server, Postgress, MySQL, etc.) Con el desarrollo de una interface API nos permitirá entrar a las tablas de las diferentes Base de Datos del mercado como Oracle, MySQL, SQL Server, Postgress, etc. 8.- Lenguaje de Programación PHP v5.1.6, que incluye todas las ventajas que provee el nuevo Zend Engine 2 como:
8.1.- Mejor soporte para la Programación Orientada a Objetos, que en versiones anteriores era extremadamente rudimentario, con PHP Data Objects. 8.2.- Mejoras de rendimiento. 8.3.- Mejor soporte para MySQL con extensión completamente reescrita. 8.4.- Mejor soporte a XML ( XPath, DOM, etc. ). 8.5.- Soporte nativo para SQLite, sistema de gestión de bases de datos relacional compatible con ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad), y que está contenida en una relativamente pequeña (~500KB) librería en C. A diferencia de los sistemas de gestión de base de datos cliente-servidor, el motor de SQLite no es un proceso independiente con el que el programa principal se comunica. En lugar de eso, la librería SQLite se enlaza con el programa pasando a ser parte integral del mismo. El programa utiliza la funcionalidad de SQLite a través de llamadas simples a subrutinas y funciones. Esto reduce la latencia en el acceso a la base de datos, debido a que las llamadas a funciones son más eficientes que la comunicación entre procesos. El conjunto de la base de datos (definiciones, tablas, índices, y los propios datos), son guardados como un sólo fichero estándar en la máquina Host. Este diseño simple se logra bloqueando todo el fichero de base de datos al principio de cada transacción. 8.6.- Soporte integrado para SOAP., protocolo estándar que define como dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML, el componente WSO2 del sistema ProcessMaker viene incluido con esta funcionalidad 8.7.- Iteradores de datos. En diseño de software, el patrón de diseño Iterador define una interfaz que declara los métodos necesarios para acceder secuencialmente a un grupo de objetos de una colección, Algunos de los métodos que podemos definir en la interfaz Iterador son: Primero (), Siguiente (), HayMas() y Elemento Actual () Este patrón de diseño permite recorrer una estructura de datos sin que sea necesario conocer la estructura interna de la misma 8.8.- Manejo de excepciones, que es una estructura de control de los lenguajes de programación diseñada para manejar condiciones anormales que pueden ser tratadas por el mismo programa que se desarrolla.
Por ejemplo, un programa puede admitir cierto número de errores en el formato de los datos y continuar su proceso para producir el mejor resultado posible en lugar de producir una salida aparatosa llena de mensajes de error probablemente incomprensibles para el usuario. Muchas veces la acción asociada a una excepción es simplemente producir un mensaje informativo y terminar, otras veces, es sólo indicación de la necesidad de un cambio en la estrategia de resolución del problema. PHP, incluyen soporte para el manejo de excepciones. Al producirse una excepción se desciende en la pila de ejecución hasta encontrar un manejador para la excepción, el cual toma el control en ese momento. - Capa de Aplicación La capa de aplicación se encuentra constituida por los siguientes componentes: Process Mapper, este módulo permite la creación de flujos de procesos, definición de propiedades a las tareas que componen cada proceso, configuración de tipos de mensajes, alertas, tiempos asignados a cada tarea, reglas de derivación, asignación de usuarios, creación de reportes y configuración de tableros de comandos con el perfil de cada usuario, sin programación adicional para convertir en ejecutables los procesos modelados. Es escalable en el manejo de procesos y tiene la capacidad de manejar indicadores DynaForms, este módulo permite la creación de formularios sin programación adicional para convertir en ejecutables los formularios. DocuMaker, este módulo permite la generación de documentos pre establecidos invocando campos específicos desde los formularios para la generación de los documentos, sin programación adicional. - Diseño y especificación de la arquitectura de navegación ProcessMaker será accesible a través de un acceso Web, que permite el ingreso de usuarios y administradores en forma descentralizada para realizar tareas periódicas de uso y mantenimiento como son: registro de datos, emisión de consultas y reportes, administración de catálogos y administración de usuarios y privilegios. El acceso a la aplicación se realiza a través de Internet Explorer, Netscape, Mozila y otros. ProcessMaker tiene incorporado dentro de su arquitectura de navegación un motor AJAX, acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML), el cual es una técnica de desarrollo Web para crear aplicaciones interactivas o RIA (Rich Internet Applications). Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas, lo que significa aumentar la interactividad, velocidad y usabilidad en las aplicaciones. Ajax es una tecnología asíncrona, en el sentido de que los datos adicionales se requieren al servidor y se cargan en segundo plano sin interferir con la visualización ni el comportamiento de la página. JavaScript es el lenguaje interpretado (scripting language) en el que
normalmente se efectúan las funciones de llamada de Ajax mientras que el acceso a los datos se realiza mediante XMLHttpRequest, objeto disponible en los navegadores actuales. En cualquier caso, no es necesario que el contenido asíncrono esté formateado en XML. Ajax es una técnica válida para múltiples plataformas y utilizable en muchos sistemas operativos y navegadores dados que está basado en estándares abiertos como JavaScript y Document Object Model (DOM). A continuación presentamos la arquitectura interna de navegación del sistema: DISEÑO Y ESPECIFICACION DE LA ARQUITECTURA DE NAVEGACION NAVEGADOR INTERFAZ DE USUARIO llamada javascript Datos HTML MOTOR AJAX Solicitud HTTP transporte http Datos XML servidor web base de datos, procesamiento, sistemas legados Servidor Ajax no es una tecnología. Es realmente muchas tecnologías, cada una floreciendo por su propio mérito, uniéndose en poderosas nuevas formas. AJAX incorpora: presentación basada en estándares usando XHTML y CSS;
exhibición e interacción dinámicas usando el Document Object Model ; Intercambio y manipulación de datos usando XML and XSLT ; Recuperación de datos asincrónica usando XMLHttpRequest ; y JavaScript poniendo todo junto. El modelo clásico de aplicaciones Web funciona de esta forma: La mayoría de las acciones del usuario en la interfaz disparan un requerimiento HTTP al Servidor Web. El servidor efectúa un proceso (recopila información, procesa números, hablando con varios sistemas propietarios), y le devuelve una pagina HTLM al cliente. Una aplicación AJAX elimina la naturaleza arrancar-frenar- arrancar-frenar de la interacción en la Web introduciendo un intermediario -un motor AJAX- entre el usuario y el servidor. Parecería que sumar una capa a la aplicación la haría menos reactiva, pero la verdad es lo contrario. En vez de cargar un pagina Web, al inicio de la sesión, el navegador carga al motor AJAX (escrito en JavaScript y usualmente sacado en un frame oculto). Este motor es el responsable por renderizar la interfaz que el usuario ve y por comunicarse con el servidor en nombre del usuario. El motor AJAX permite que la interacción del usuario con la aplicación suceda asincrónicamente (independientemente de la comunicación con el servidor). Así el usuario nunca estará mirando una ventana en blanco del navegador y un icono de reloj de arena esperando a que el servidor haga algo. El patrón de interacción sincrónica de una aplicación Web tradicional (arriba) comparada con el patrón asincrónico de una aplicación AJAX (abajo).
Cada acción de un usuario que normalmente generaría un requerimiento HTTP toma la forma de un llamado JavaScript al motor AJAX en vez de ese requerimiento. Cualquier respuesta a una acción del usuario que no requiera una viaje de vuelta al servidor (como una simple validación de datos, edición de datos en memoria, incluso algo de navegación) es manejado por su cuenta. Si el motor necesita algo del servidor para responder (sea enviando datos para procesar, cargar código adicional, o recuperando nuevos datos) hace esos pedidos asincrónicamente, usualmente usando XML, sin frenar la interacción del usuario con la aplicación. - Diseño y especificación de la arquitectura de la interface. La metodología de trabajo que empleará ProcessMaker para la automatización de los procesos se empieza con la construcción del mapa del proceso y definición de las propiedades que componen las tareas del proceso, administración de datos y auditoria del status de cada una de las tareas, y reportes y análisis de datos a través de tablas dinámicas con la que cuenta el sistema. A continuación se presente un esquema de la metodología de trabajo del sistema: Metodología de Trabajo del Sistema Construcción n Mapa del Proceso Administración n y Auditoria del status de las tareas Análisis de reportes
A continuación se describirá paso a paso la construcción de un proceso de negocios: 1.- Mapeo de los procesos de negocios mediante flujogramas 1. Construcción del Mapa del Proceso con ProcessMaker 1. El sistema esta desarrollado para que usuarios avanzados puedan manejar la herramienta de una manera intuitiva (click botón derecho) y la herramienta guiará al usuario en desarrollo los flujogramas, desarrollo de formularios, asignación de reglas de derivación, asignación de usuarios, duración de tareas y manejo de datos. El primer paso es el mapeo de un proceso de negocios a través de un flujograma. Para ello el Sistema propone lo siguiente: Identificar el inicio y término de los flujogramas de negocios mapeado Identificar los puntos de decisión
2.- Desarrollo de formularios que se encuentran involucrados en cada tarea de un proceso que se va a automatizar Los usuarios avanzados con el uso de nuestro sistema se encontrarán en capacidad de crear formularios sofisticados para el input de los datos en el sistema : 1. El sistema cuenta con un set de herramientas que permitirán crear los formularios de acuerdo a las necesidades del usuario 2. Uso de cliente Windows para crear formularios 2. Creación de Formularios para ser usado en el mapeo del proceso de negocio 3. Vista de un formulario después que ha sido creado a través de la librerias Dynaform de nuestro sistema que será asignado a una tarea del proceso de negocio.
3.- Definición de las propiedades que tendrá cada una de las tareas de los procesos a automatizar Una vez que el usuario ha creado el mapa del proceso de negocio que es la estructura básica del trabajo a desarrollar, se procede a asignarle propiedades a cada una de las tareas: 1. Asignar Usuarios o Grupo de Usuarios a cada tarea 2. Crear mensajes entre tareas 3. Adicionar Web Services y Scripts para llamar a los servicios de otros sistemas, información,o funciones de sistemas de terceros, o a otros procesos de ProcessMaker 3. Definición de propiedades a las tareas de los procesos de negocios
4.- Creación de reglas de derivación a las tareas que forma parte del proceso a automatizar 4. Creación de reglas de derivación para el proceso del negocio El usuario asigna elementos a cada tarea que permitirá al sistema derivar de acuerdo a criterios pre establecidos en el formulario 1. Se crea la regla de derivación entre tareas basado en valores que vaya tomando los campos de los formularios 2. Generación de documentos, el cual incluye la generación automática de inserción de datos de un formulario en el documento 3. Asignación de Formularios en cada tarea
5.- Generación de reportes y gráficos a través de las tablas dinámicas con las que cuenta el sistema 5. Generación de Reportes y Gráficos El sistema cuenta con el manejo de tablas dinámicas que permitirán al usuarios crear cualquier tipo de gráficos: 1. Seleccione los campos de una lista de campos que fueron creados a través de Formularios de un proceso 2. Configure el tipo de gráficos deseado 3. Ejecute los reportes y tipos de gráficos deseado
6.- Capacidad de configurar la interface de cada usuario de acuerdo a sus requerimientos 6. Configuración de interface de usuario El Administrador puede crear reportes para ser puestos en el ambiente de cada usuario para una fácil vision de su ambiente 1. Vista de un diseño de ambiente de usuario 2. El Administrator otorga permisos a los usuarios para determinados gráficos 3. Capacidad de exportar gráficos al panel de control de los usuarios de acuerdo a la Configuración deseada
7.- Administración de usuarios 7. Adminsitración de usuarios. 1. Cada usuario de la compañia contará con un usuario y password 2. Cada usuario tendrá un registro de casos de tareas pendientes y atendidas 3. Cada usuario podrá iniciar un proceso que ha sido autorizado para iniciar 4. Cada usuario configura su propio panel de control
REQUERIMIENTOS Los requerimientos mínimos para la instalación y correcto funcionamiento de ProcessMaker son los siguientes: Servidor - Tipo de Procesador: Intel Xeon de 3.0G - Memoria RAM de 2.0GB - Tarjeta de red 10/100 Base TX - Tarjeta de Video de 32MB - Tape Back Up de 40GB DDS/4 4 mm - Unidad de CD - 03 Discos duros de SCSI de 100GB Hot Swappble RAID 5 - Fuente de Poder Redundante - Monitor ProcessMaker puede ser instalado también en un equipo multiprocesador, el cual puede compartir recursos con otras aplicaciones Red LAN La configuración de la red LAN o Intranet debe tener un ancho de banda como mínimo de 10/100Base TX 5. CRECIMIENTO ProcessMaker es modular y escalable, que permite crecer en el tiempo de una manera ordenada, incluyendo las dos líneas de acción de soporte del componente SAE. En este caso presentamos la forma de crecimiento de ProcessMaker que permitirá a la Institución contar con un horizonte tecnológico bastante amplio para un escenario de 1,000 usuarios concurrentes con la opción de ir creciendo en el futuro con mayor cantidad de usuarios:
CRECIMIENTO FUTURO DE PROCESSMAKER 1000 USUARIOS La restricción no esta en cuanto a cantidad de procesos ni de usuarios sino al dimensionamiento que se haga respecto a la cantidad de información a almacenar en la base de datos y el hardware sobre el cual se implemente la solución Para mas usuarios se puede aumentar servidores Web hasta 10 servidores según sea la arquitectura. Para mas información se incrementan servidores de bases de datos Los tiempos de Acceso dependen de la conexión de Internet la cantidad de usuarios conectados a la vez. En condiciones normales es casi instantánea. $ BALANCEO DE CARGA 1000 USUARIOS Los servidores utilizan Load Balancing y están configurados de la siguiente manera : 3 servidores WEB, 1 servidor exclusivo para la Base de Datos, 1 servidor de Balanceo de carga Balanceo de carga LVS es (Linux Virtual Server) es un servidor altamente escalable y altamente disponible construido en un racimo (cluster) de servidores verdaderos, con el balanceador de la carga funcionando en el sistema operativo de Linux. La arquitectura del racimo de servidores es completamente transparente a usuarios finales, y los usuarios interactúan como si fuera un único Servidor Virtual de alto rendimiento.
BALANCEO DE CARGA 1000 USUARIOS El balanceo de carga se realiza a nivel de transporte, llamado también «Layer4 switching». Para esto se utiliza el programa IPVS (IP Virtual Server) que corre en un servidor y actúa como Balanceador de carga antes del racimo de servidores reales. En particular estamos usando el modo de operación LVS/DR (Direct Routing) que encamina directamente los paquetes al servidor final (back end) al reescribir la dirección hardware (MAC). Tiene la mejor escalabilidad porque la sobrecarga de reescribir la MAC es bastante baja, pero requieren que el balanceador de carga y los servidores back end estén en una misma red física. El siguiente gráfico muestra una arquitectura empleando LVS para balanceo de carga
ESTRUCTURA DE LOS SERVIDORES 1000 USUARIOS 1 SERVIDOR DE BASE DE DATOS 3 SERVIDORES DE PROCESSMAKER 1 SERVIDOR DE WEB
FUNCIONALIDADES Contiene Ítem Característica 1. Características Generales 1.1. Funcionalidad 1.1.1. 1.1.2. 1.1.3 Módulo para el modelado de los procesos. Múltiples espacios de trabajo o workspaces Subir archivos Generación de ejecutables de procesos en forma automática Comentarios Cada espacio de trabajo es independiente de los demás ya sea en términos de proceso, usuario y caso. Es escalable en el manejo de procesos y con capacidad de manejar indicadores. El módulo para modelado de procesos permite plasmar gráficamente la estructura y diagrama de los flujos de los procesos Subida de archivos para casos, procesos, definiciones y plantillas de documentos. ProcessMaker no requiere programación adicional para convertir en ejecutables los procesos modelados ProcessMaker regula los inicios y finales de los procesos que funcionan concurrentemente controlados por las reglas de negocio definidas en la Organización y que activarán los workflows de los usuarios para que cada uno reciba el encargo de realizar la tarea del que es responsable, usando los formatos y formularios que han sido definidos previamente 1.2. Arquitectura 1.2.1. Arquitectura basada en Web 1.2.2. Soporte de base de datos relacional 1.2.3. Soporte al balance de carga Usuarios finales llegaran a interactuar con la plataforma ProcessMaker a través de una versión estándar de JavaScript en un entorno de explorador Web. El acceso a ProcessMaker es a través de cualquier browser como Internet Explorer, Netscape, Mozila y otros El diseño final de la base de datos es una herramienta veloz, Multi - tarea, Multi-usuario servidor de base de datos relacional SQL.. ProcessMaker soporta una configuración de clúster de nivel dos: Clúster de servidor de base de datos y clúster de servidor Web..
1.2.4. 1.2.5. 1.2.6. Integración con otras aplicaciones ya existentes a través de Servicios Web. Integración con otras aplicaciones ya existentes vía Propel Aplicación de la arquitectura de Proveedor de servicios. 1.3. Atención al cliente 1.3.1. Plataforma de atención al cliente 1.3.2. Actualización de las nuevas versiones de BPMS para solucionar inconvenientes o para adicionar nuevas características. 1.3.3 Servicio de Soporte 1.3.3. Programa de entrenamiento para Arquitectos de Negocio. 1.4. Características Multi - Usuario 1.4.1. Interfaz del usuario administrador 1.4.2. Apoyo de acuerdo a los estados de usuario 1.4.3. Grupo de usuarios, roles y cargos ProcessMaker expone un creciente numero de métodos de servicios Web permitiendo así una completa interacción con existentes casos de negocio. ProcessMaker se integra con otras aplicaciones interactuando de forma nativa con la mayoría de RDBMS como ser: MySQL, PostgreSQL, Microsoft SQL Server y Oracle a través de la interpretación de las estructuras de la data de las RDBMS a formato XML o también a través de ODBC. Permite exportar información a almacenamiento externo y Base de Datos SQL. Permite recuperar datos de fuentes externas y Base de Datos SQL El acercamiento de una aplicación recibida permite el despliegue instantáneo de nuevos lanzamientos. Nuestro equipo de atención al cliente provee atención on site, vía telefónica y/o vía Chat de hrs. 8:30 a.m. a hrs. 18:00 p.m. de Lunes a Viernes, con un tiempo máximo de atención de dos (02) para el inicio de la solución de alguna incidencia. La arquitectura de aplicación distribuida provee una plataforma natural para actualizaciones simultáneas de espacios de trabajo ya desarrollados y existentes. ProcessMaker viene con un módulo de ayuda en línea, lo que permite al usuario resolver de una manera rápida las consultas que puedan presentarse Un set completo de módulos de entrenamiento permite a los usuarios finales alcanzar las habilidades necesarias para diseñar y desplegar procesos de negocio de forma eficiente. La Interfaz de administrador de ProcessMaker provee las herramientas necesarias para administrar cuentas de otros usuarios. El estado de una cuenta usuario puede ser configurada como activo o inactivo, así como estados adicionales, procesos para permisos temporales y sustitutos Los grupos han sido desarrollados para tareas de asignación. Los roles están destinados para cambiar sus privilegios, roles pre - desarrollados corresponden para los mas comunes
1.4.4. 1.4.5. Privilegios diferentes de acuerdo a usuarios, grupos y roles. Cualquier cuenta de usuario puede pertenecer a varios grupos. 2. Administración de casos de negocio 2.1. Nuevos casos 2.1.1. Nuevos casos abiertos por usuarios internos, proveedores, afiliados y usuarios anónimos. 2.1.2. Creación simultanea de varios casos 2.1.4. Registro de los comentarios del usuario 2.1.5. Mensajes condicionales 2.1.6. Capacidad de adjuntar documentos 2.2. Asignación de casos de negocio 2.2.1. Asignación de tareas de acuerdo al diseño del flujo de trabajo (workflow) y reglas de negocio. 2.2.2. Transferencia arbitraria de casos 2.2.3. Historial de mensajes 2.2.4. Notificaciones vía Email para derivación de tareas perfiles de usuario. Los roles y cargos se encuentran estrechamente relacionados para la ejecución a una siguiente tarea La ejecución de tareas puede ser asignada a usuarios y grupos, los privilegios diferenciados corresponden a roles nuevos o pre - definidos. La ejecución de tareas es simplificada con una asignación de grupo. Cualquier usuario puede pertenecer a 0, 1 o mas grupos. Nuevos casos pueden ser abiertos ya sea desde adentro o desde afuera de ProcessMaker. En caso de que el inicio de un caso sea desde afuera, los usuarios podrán crear una cuenta o utilizar formularios anónimos para lanzar un nuevo caso. Un existente caso de negocio es capaz de disparar nuevos casos de acuerdo a una definición diferente del proceso. Un existente caso de negocio puede ser alimentado por el registro de los comentarios del usuario ingresado, guardando automáticamente el nombre de usuario, y la fecha. Esta característica requiere una previa configuración en el diseño del proceso. Dependiendo de las configuraciones que el usuario haya realizado, es posible realizar notificaciones vía E - mail a los usuarios seleccionados. Es posible adjuntar varios documentos para cada caso de negocio (por ejemplo: procesadores de texto, imágenes escaneadas, hojas de cálculo, etc.). Adicionalmente puede generar documentos RTF o PDF basados en plantillas como parte de la definición de un proceso determinado. La asignación de tareas depende de las n variables del caso, posiciones de usuarios, lugar de trabajo o ubicación geográfica. Un caso de negocio, diseñado de forma apropiada, puede ser transferido a un usuario diferente al usuario original. Un registro de mensaje, que es guardado para todos los casos de negocio, detalla todos los mensajes enviados entre derivaciones. Existen dos tipos de notificaciones: notificaciones por defecto y
notificaciones condicionales. 2.2.5. Gantt Chart 2.2.6. Mapa del proceso 2.2.7. Información referente a la actividad actual 2.2.8. Información al usuario final referente a las posibles acciones que se pueden realizar 2.2.9. Derivar un caso a un usuario diferente 2.2.10. Administración de documentos 2.2.11. Clasificación de los casos de negocio 2.2.12. Un usuario a cargo para cada caso de negocio 2.3. Monitorización de los casos de negocio 2.3.1. Revisar el estado de los casos existentes. 2.3.2. 2.3.3. 2.3.4. Representación grafica del estado actual de un caso de negocio. Representación grafica de la trayectoria del flujo de trabajo Notificaciones vía Email a usuarios asignados. Todos los casos de negocio pueden ser rastreados en tiempo real con Gantt Chart. Cada caso puede ser representado mediante la definición del mapa del proceso permitiendo una fácil identificación de tareas pendientes y de tareas completadas. Antes de comenzar una nueva actividad, el usuario final puede revisar la documentación asociada a la definición de la tarea relacionada. Cada paso junto a una instancia de tarea dada puede ser documentado con instrucciones detalladas. Una definición de tarea puede ser configurada para permitir una transferencia arbitraria de un caso actual a un diferente usuario. Cualquier tipo de documento puede ser actualizado a un caso de negocio. ProcessMaker permite centralizar, organizar y controlar la documentación relacionada a cada flujo de trabajo Todos los casos de negocio son clasificados de acuerdo a un criterio predefinido (por ejemplo el estado del caso), o a específicos valores La propiedad es definida para cada nuevo caso de negocio. Un caso de negocio dado, puede tener más de un dueño. Los casos existentes son automáticamente agrupados de acuerdo a su estado (pendiente, completado, en pausa, etc.). Los casos pendientes son agrupados en zonas de alerta (verde, amarillo y rojo), y con un caso dado, cualquier usuario puede desplegar la posición actual en la definición del flujo de trabajo. ProcessMaker permite registrar y mostrar a los responsables de los procesos y a la gerencia de la Organización en situaciones reales los tiempos, retrasos o adelantos de los procesos mientras estos se ejecutan El mapa del proceso utiliza un intuitivo y colorido esquema permitiendo una fácil identificación de trayectorias a través de la definición del proceso. Alertas vía Email pueden configurarse para que sean enviadas cada vez que una derivación de tarea
es realizada. 2.3.5. Filtración del historial de casos 3. Administración de procesos de negocio 3.1. Diseño de un flujo de trabajo 3.1.1. Interfaz grafica para el diseño de un workflow 3.1.2. Definición de pasos 3.1.3. Soporte de scripts 3.1.4. Entrada externa de datos 3.1.5. Documentos de salida 3.1.6. Documentación de un proceso 3.1.7 Reglas de derivación 3.1.8 Derivación de tareas 3.1.9 Interfaz de presentación 3.1.10 Un caso cerrado siempre puede ser encontrado utilizando el formulario de filtrado rápido. ProcessMaker provee ambos, una interfaz Web y una aplicación de software para facilitar el diseño de procesos de negocio. Cada tarea esta compuesta de uno o varios pasos, permitiendo, en algunos casos realizar saltos entre los flujos de acuerdo a específicas condiciones de los pasos. ProcessMaker WebBots soporta evaluaciones condicionantes gracias a su muy bien equipado set de funciones permitiendo un fácil acceso a las variables del sistema, variables de casos, y depósitos externos de datos.(odbc, Web Services). Usuarios externos pueden iniciar nuevos casos mediante: 1. Creación de una nueva cuenta externa, o 2. Llenando un formulario de forma anónima. La plataforma puede crear rápidamente, documentos imprimibles de alta calidad (formatos PDF y RTF) aplicando atractivas plantillas pre - diseñadas. La documentación completa de un proceso puede ser generada (si así se desea) en formato PDF. ProcessMaker tiene incorporado reglas de derivación o reglas de negocios que podrán interactuar con los procesos a través de ProcessMaker ProcessMaker a través de sus reglas de derivación y las variables que se definen previamente en los DynaForms o Formularios permitirá la delegación automática o manual de tareas ProcessMaker establece tiempos mínimos máximos para la ejecución de una tarea emitiendo alertas para que se facilite su cumplimiento ProcessMaker posee una interfaz de presentación tipo Digital Dashboard ProcessMaker soporta un ambiente multi-workspace. Ya que es posible configurar muchos espacios de trabajo en adición al ambiente de producción
3.2. Ambiente de testeo Mantenimiento de los procesos existentes 3.2.1. Modificaciones de un Workflow 3.3. Formularios 3.3.1 Diseño de Formularios 3.3.2 Modificación de formularios existentes 3.3.3 Información adicional en formularios 3.3.4 Campos requeridos de procesos. La optimización se realizará analizando los resultados registrados en la monitorización determinando los cambios que conviene realizar en los procesos para su mejora. Un usuario con privilegios de administrador puede realizar modificaciones a cualquier proceso definido. ProcessMaker permite la creación de formularios sin la necesidad de programación Un usuario con privilegios de administrador puede realizar modificaciones a cualquiera de los denominados "DynaForms" o formularios y agregar nuevos parámetros y relacionarlos con otras variables del proceso Existen ciertos tipos de DynaForms para crear espacios informativos, de tal manera que los usuarios pueden realizar comentarios Una definición de campo dentro de un DynaForms puede ser diseñado a requerimientos del usuario 3.4. Definición de tareas 3.4.1 Definición del inicio y final de un proceso 3.4.2 Asignación de tiempos 3.4.3 Texto enriquecido 3.5. Módulos de administración 3.5.1. Cambiar el estado de un caso existente 4. Alertas 4.1. Alertas Preventivas 4.1.1. Alertas Preventivas ProcessMaker orienta al usuario a definir el inicio y final de un proceso ProcessMaker define el tiempo que asignara el arquitecto a las tareas de los procesos ProcessMaker permite definir texto enriquecido en cada tarea del proceso Dependiendo de la definición de la tarea, un caso de negocio dado puede ser: cancelado, congelado o puesto en pausa.. ProcessMaker incluye notificaciones para casos pendientes que se desplieguen en las zonas de alerta amarilla o roja. 5. Reportes 5.1. Por caso de negocio 5.1.1. Por definición de proceso Reporte pre definido 5.1.2. Por etapa de la actividad Modificable por el administrador