Mejoramiento continuo

<< Click to Display Table of Contents >>

Navigation:  Bizagi Engine > Administración del Sistema Bizagi > Deployment de procesos y nuevas versiones >

Mejoramiento continuo

Introducción

Como parte de la mejora continua en los Procesos, Bizagi ofrece la posibilidad de realizar ajustes sobre los Procesos que les permitan su evolución a medida que el mismo negocio evoluciona.

A menudo, estos ajustes involucran cambios a los datos y reglas del negocio, las interfaces predefinidas o incluso el mismo flujo del Proceso.

 

Dependiendo de los cambios requeridos, se recomienda generar una nueva versión del Proceso que ya se encuentra ejecutándose en producción.

Esto obedece a una manera segura de implementar cambios sin comprometer la información de los casos existentes (instancias de Proceso) en el ambiente de producción.

 

Por otro lado, en escenarios donde se requieren solamente cambios menores a los Procesos existentes, también es posible optar por que los casos existentes tomen ese ajuste en producción.

 

Esta sección ilustra a manera de guía, cuándo deben crearse nuevas versiones de Proceso y cuándo se pueden manejar los cambios menores dentro de las versiones de Proceso ya existentes.

 

 

Mejora continua

Antes que nada, recuerde que cualquier cambio estructural que se desee hacer a un Proceso en producción, debe hacerse en el ambiente de desarrollo y actualizarse por medio del Deployment.

 

 

Tipos de cambios estructurales son: nuevas transiciones y Actividades en el flujo, nuevas formas o cambios en ellas, ajustes en las reglas de negocio, nuevas asignaciones a participantes o definiciones de integración, entre otras.

 

Model_Automate_ExecuteEN1

 

 

Tales cambios estructurales no incluyen las tareas administrativas, las cuales si se pueden llevar a cabo directamente sobre el Portal de Trabajo en producción. Tales tareas son por ejemplo: editar políticas del negocio, la administración de usuarios y sus configuraciones de autorización, o la administración de la configuración del Servidor SMTP o de sistemas externos como ECMs, entre otras.

 

Tenga en cuenta que de igual manera se debe seguir el ciclo recomendado del Deployment, donde se utiliza primero el ambiente de pruebas para verificar que los Procesos se comportan adecuadamente y están listos para ser llevados a producción.

 

 

Deployments incrementales

Para Deployments posteriores al primer Deployment a Producción, y para realizar cambios enfocados en el mejoramiento de Procesos que se encuentran operativos, tenga en cuenta las siguientes recomendaciones:

 

 

1. Los objetos en producción deben conservarse siempre

Una vez que un Proceso haya sido llevado al ambiente de producción (aplica también cuando un Proceso está marcado como Release Candidate en pruebas), no es posible eliminar en el ambiente de desarrollo cualquier objeto que sea utilizado por este Proceso.

 

Entre tales objetos, se consideran: entidades, atributos y relaciones, formas, reglas de negocio y definición de participantes (reglas de asignación), definición de sistemas y de elementos de la organización.

 

De manera similar, no es posible modificar el nombre de estos objetos en producción (la propiedad Nombre). Esto es una restricción para garantizar la estabilidad del ambiente de producción en Deployments posteriores.

 

LockedObjects

 

 

2. Versionamiento de Procesos

Una vez que un Proceso haya sido llevado al ambiente de producción (aplica también cuando un Proceso está marcado como Release Candidate en pruebas), no es posible editar su flujo. Dicho Proceso queda bloqueado en desarrollo, de manera que si se requiere un cambio en el flujo (una nueva tarea, una nueva transición, etc), se requiere crear una nueva versión de ese Proceso.

 

Esto significa que a partir del primer Deployment de un Proceso, no se puede utilizar el Paso 1 del Asistente de Proceso (para la adición o edición de elementos BPMN en el flujo) para la versión del Proceso que está en producción. Para ello, se debe crear una nueva versión del Proceso y de los Subprocesos que utilice.

 

NewVersion

 

 

Por otro lado, los siguientes cambios no requieren que se cree una nueva versión del Proceso:

 

Adicionar un nuevo atributo o entidad.

Adicionar o editar una regla de negocio (sea como acción de Actividad, regla de asignación, o para la invocación de servicios Web o REST).

Crear una nueva forma de consulta a nivel de aplicación o entidad.

 

En otras palabras, no se requiere una nueva versión del Proceso si se van a hacer cambios que se realizan desde el paso 2 en adelante del Asistente de Proceso. Más información sobre este tema se detalla en la siguiente sección.

 

note_pin

Los cambios que se hagan sobre la versión de Proceso actual (sin crear una nueva), aplicarían directamente sobre los casos existentes del ambiente de producción.

Por lo tanto, en este escenario es muy importante tener en cuenta las medidas, pruebas y consideraciones necesarias que garanticen que no se presenten problemas de consistencia en los casos nuevos y existentes.

 

Para más información sobre las recomendaciones en este aspecto, consulte la guía para nueva versión de Proceso.

 

 

3. Posibilidades de edición de los objetos en producción

Una vez que un Proceso haya sido llevado al ambiente de producción (aplica también cuando un Proceso está marcado como Release Candidate en pruebas), Bizagi Studio controlará en el ambiente de desarrollo, las posibilidades para editar los objetos usados por ese Proceso.

Esto es una restricción para garantizar la estabilidad del ambiente de producción en Deployments posteriores.

 

Por lo tanto, para un Proceso que esté en producción, es recomendado crear una nueva versión de Proceso para realizar cambios que no sean ajustes menores.

Ajustes menores se pueden realizar a la versión actual del Proceso si involucran cambios puntuales sobre ciertos objetos que se usan por esos Procesos, como se detalla en la siguiente tabla:

 

 

Objeto

Opciones

Entidades y atributos

No será posible editar las siguientes propiedades de las entidades y atributos (incluye relaciones) : nombre, tipo o fuente.

Solo se puede editar su nombre para mostrar.

Formas

No será posible editar las formas (adicionar, modificar o eliminar controles, o sus expresiones, validaciones o acciones asociadas).

Sin embargo, las formas pueden clonarse o versionarse de por si, de manera que se puede cambiar la forma que se usa en cierta Actividad.

Expresiones (booleanas y de tipo scripting)

Su código podrá ser editado (junto con otras propiedades como el nombre de mostrar o su descripción).

Al hacerlo, se debe tener cuidado en no alterar el buen funcionamiento de los casos existentes.

Funciones personalizadas

Su código podrá ser editado (junto con su descripción).

Widgets de Bizagi

Su código podrá ser editado (junto con su descripción).

Definición de participantes (reglas de asignación)

Todas sus propiedades y condiciones podrán ser editadas. Esto implica las definiciones del criterio y reglas de asignación.

Definición de la organización

Solo el nombre de mostrar podrá ser editado para los elementos de la organización previamente definidos (áreas, Roles, habilidades, grupos de usuario).

Esquemas de festivos (en el esquema de horario de trabajo)

Solo la descripción del esquema de días no laborales podrá ser editado.

Seguridad

Cambios en la configuración de Autenticación y LDAP, deberán hacerse directamente en el ambiente de producción con el Management Console.

Los cambios realizados en el ambiente de desarrollo para la configuración de autorizaciones serán siempre actualizados por el Deployment hacia producción.

Notificaciones por correo (e-mails)

Nuevos mensajes (cuando se utiliza la posibilidad de múltiples correos) se pueden incluir en la configuración de notificaciones.

Los mensajes existentes no se podrán eliminar.

Dentro de la definición del mensaje, su asunto, destinatario ("Para", "CC", y "BCC"), y contenido del cuerpo, podrán ser editado.

Las condiciones de envío de los correos podrán ser editadas también pero no eliminadas.

Cartas

Su contenido podrá ser editado.

Invocaciones de interfaces

La configuración de la invocación a un servicio Web o REST puede cambiarse tal como lo permite el asistente de interfaces en Bizagi.

Los ajustes de parámetros (por ejemplo, de conexión, y demás que no requieran un nuevo mapeo de datos), podrán realizarse directamente sobre producción con el Management Console.

Dimensiones

Todas sus propiedades podrán ser editadas (excepto el nombre).

Componentes en la Librería de componentes

 

Será posible cambiar el archivo o ensamblado asociado al componente.

Trabajos personalizados

 

Se podrán adicionar nuevos Pasos  y Programaciones a los trabajos personalizados.

 

Cualquier otro cambio que no se encuentre listado en la tabla anterior, requerirá crear una nueva versión de Proceso que utilice otro objeto diferente al que ya exista en producción.

 

 

4. Nuevas llaves de negocio

Cuando se definen nuevas llaves de negocio, se recomienda revisar que los datos en producción son compatibles con las nuevas características o restricciones (constraints).

De lo contrario, si se aplican llaves de negocio en desarrollo que no se dan con los datos en producción, se tendrá un error de integridad advertido por Bizagi durante el Deployment.

 

Para ilustrar lo anterior, supongamos que se tiene una entidad llamada Producto, la cual ya fue llevada al ambiente de producción sin definición de llaves de negocio. Entonces, no se debe redefinir posteriormente en la entidad Producto que su llave de negocio es el atributo NombreProducto si se detecta: que hay más de un registro en producción con NombreProducto=Crédito (más de un producto con el mismo nombre)..

 

Para más información sobre estas definiciones, consulte predefiniendo llaves de negocio.

 

 

5. Las configuraciones previas deben permanecer compatibles

No se deben alterar las configuraciones que ya se tenían anteriormente a nivel de infraestructura.

Esto significa que las características de los prerrequisitos técnicos del Deployment no deben cambiarse.

 

Lo anterior incluye no cambiar la intercalación de la instancia de Base de datos (si es SQL Server), o de manera similar no cambiar la configuración del set de caracteres en una instancia de Oracle.

 

Si requiere cambiar su Servidor de producción, asegúrese de utilizar las opciones del Management Console.