El motor que convierte un diagrama en algo que un auditor puede verificar.
Un proceso modelado y un proceso ejecutado son objetos distintos. Uno es una imagen de la intención; el otro deja constancia de quién hizo qué, cuándo, bajo qué regla y con qué evidencia. Workflow es el módulo donde el primero se convierte en el segundo.
Un motor, todos los tipos de registro.
Incidentes, solicitudes, problemas, cambios, despliegues y cualquier tipo de registro que usted defina corren sobre el mismo motor. No es un detalle de implementación. Es la razón por la que una encuesta definida una vez sirve para todos, por la que un indicador puede combinar datos de varias prácticas sin una capa de mapeo, y por la que un agente ve trabajo de distintos tipos en una sola consola en vez de saltar entre módulos aislados.
Es también la razón por la que el motor sostiene procesos que no tienen nada que ver con TI. Una fiscalización tributaria, una auditoría de cuentas médicas, una petición ciudadana y un plan estratégico tienen la misma forma que una solicitud de cambio: formularios, enrutamiento, aprobaciones, plazos, evidencia y un resultado del que alguien responde.
Qué hace
Ejecución, con los controles que exige un proceso regulado
Todo lo de abajo es configuración contra el registro vivo, no un requerimiento de desarrollo.
Enrutamiento condicional →
Bifurque por cualquier dato del registro: servicio, componente, ubicación, nivel de riesgo, atributos del solicitante, resultado de una aprobación o desenlace de una tarea anterior.
Trabajo secuencial y en paralelo →
Las tareas corren en secuencia o en paralelo, y una tarea hija puede tener reglas de asignación distintas a las de su padre — el área que coordina conserva el caso mientras identidad, puesto de trabajo, licenciamiento, compras y seguridad responden cada una por su paso.
Casos cuyo camino no está predefinido →
Gestión adaptativa de casos: tareas, participantes y datos relacionados se agregan mientras el caso corre —actividades hijas y hermanas desde el visor, un equipo del caso cuyos colaboradores lo ven y lo actualizan, casos que se unen— con la misma trazabilidad de una ruta modelada.
Aprobaciones con reglas de autoridad reales →
Un aprobador, varios en secuencia o en paralelo, grupos de aprobación y reglas de N de M. Los aprobadores se resuelven dinámicamente desde el registro: el jefe del solicitante, el dueño de la aplicación, el responsable de la sede, el revisor de seguridad. El rechazo cierra el registro con una clasificación de rechazo o lo devuelve a un paso anterior con los comentarios adjuntos.
Plazos que respetan el calendario →
Los objetivos corren como relojes vivos contra calendarios laborales, festivos, ventanas de servicio y horarios de grupo —turnos nocturnos y de 24 horas y el horario de almuerzo de cada grupo incluidos—, con el tiempo de desplazamiento de la sede sumado al plazo y excepciones configurables para períodos excluidos y ciclos del negocio. La prioridad sale de una matriz de impacto por urgencia. Los escalones de escalamiento se disparan por el porcentaje del tiempo de servicio consumido, antes del vencimiento y también después.
Reglas condicionales sobre los datos →
Cada tabla o campo de los datos del caso admite sus propias reglas —obligatorio solo si, visible solo si— sobre otros datos del caso, su estado, su prioridad o su tipo. El formulario las aplica en vivo y el servidor las hace cumplir al guardar y al cerrar, así que un formulario pide solo lo que aplica sin perder un solo control.
Proyectos sobre el mismo motor →
Los proyectos nacen de una plantilla y se planean y siguen en un Gantt editable: dependencias, ruta crítica, fecha de fin proyectada con el predictor de duración, sobreasignación por técnico y calendario laboral. Cada actividad del proyecto es un caso sobre el mismo motor de los tickets, con su responsable, su costo y su plazo.
Condiciones que detienen el avance →
El flujo puede inyectar una revisión adicional cuando el dato vivo cruza un umbral —tiempo de anticipación insuficiente, choque con una ventana de congelamiento, riesgo por encima de un límite— y retener el registro hasta que la condición se cumpla. La tarea inyectada es parte de la instancia gobernada, no una nota informal.
Detección de desviaciones
Un inicio que no ocurrió, un registro que pasó su fecha planeada de fin, una aprobación vencida, una ejecución que se extendió o una reversión activada pueden generar una marca auditable, una notificación, un escalamiento o una tarea, y alimentar la evaluación final del resultado.
Ausencias, suplencias y transferencias →
Las ausencias se registran por adelantado como ventanas de no disponibilidad con su motivo y su reemplazo, y mientras una está vigente la asignación automática y la agenda de citas entregan al reemplazo. Cuando alguien sale, sus casos abiertos pasan a otra persona en un paso, y un suplente temporal o permanente hereda su perfil, sus grupos, sus zonas y su experiencia.
La sobrecarga, a tiempo →
La carga de cada persona y grupo sobre el trabajo abierto se señala antes de convertirse en plazos incumplidos, y un reporte programado puede abrir por sí mismo las actividades que actúan sobre lo que encuentra, o notificar a otro sistema.
Escritura sobre los demás repositorios →
Un paso del flujo puede crear o actualizar activos, elementos de configuración, consumo de licencias y relaciones de servicio. El cambio queda trazable desde el proceso que lo causó y desde el registro que lo recibió, y cualquier evento del caso puede además ejecutar una integración o una llamada a otro sistema.
Historia de solo anexado →
Cada registro conserva quién cambió qué y cuándo, con el valor anterior y el nuevo. La historia la escribe el motor y no es editable desde la aplicación; se puede buscar, filtrar, reportar y exportar.
Gobierno
Qué hace el motor solo, y qué no hace sin usted
La automatización que no se puede auditar es un pasivo en una organización regulada. En cada punto de control existen ambos caminos, y el registro dice cuál se tomó, por quién o por qué proceso, y cuándo.
| Punto de control | Manual, y sistemático |
|---|---|
| Asignación | Un usuario asigna a un grupo o a una persona, y toda reasignación queda auditada — o las reglas deciden por categoría, servicio, componente, solicitante, ubicación, calendario y carga de trabajo |
| Aprobación | Un aprobador designado decide desde la consola, la vista web o el correo — o la autorización es sistemática, pero solo donde un modelo define explícitamente ese escenario |
| Escalamiento | Un usuario escala y deja dicho por qué — o las reglas de tiempo notifican, escalan o reasignan un paso vencido |
| Cierre | Un rol autorizado cierra y clasifica el resultado — o el cierre sigue las condiciones configuradas: tareas obligatorias completas, validación exitosa, evidencia adjunta |
| Registros relacionados | Un agente lanza un problema o un cambio desde el caso — o un umbral de densidad abre el registro padre y le adjunta los casos que lo dispararon |
Precisión
Las distinciones que este módulo preserva
Tres lugares donde confundir dos ideas produce un problema de gobierno que solo aparece en una auditoría.
En la hoja de ruta
Lo que llega, y cuándo
Cada capacidad está disponible para una demostración o una prueba de concepto desde el mes indicado.
Agentes de uso de interfaces invocados desde el proceso
Una actividad del proceso encarga a un agente externo de uso de interfaces la tarea en una aplicación sin API, con los mismos permisos, límites y bitácora de cualquier ejecutor.
La prueba
Doce procesos corrieron sobre este motor con un auditor mirando
Gestión de cambios, de incidentes, de problemas y de solicitudes son cuatro de los doce procesos ITSM que Pink Elephant certificó en Dexon BPM. No son cuatro productos: son cuatro configuraciones de este motor, distintas en sus plantillas, su enrutamiento y sus reglas de autoridad. Es la evidencia más económica que tenemos de que «ejecutable» es literal.
Ver los doce procesos certificados →Las demás capacidades de Dexon BPM
ETL e integración
API REST, intercambio programado y por eventos con bases de datos, archivos y servicios web, más directorio, correo y descubrimiento — con el origen autoritativo de cada atributo registrado.
Documentos
Árboles de versiones, permisos, búsqueda por contenido, firma con sello de tiempo — con requisitos documentales exigidos como condiciones que el flujo no pasa sin cumplir.
BI e indicadores
Tableros bajo objetivos estratégicos, metas por período, descenso del agregado al registro fuente, y proyección que nunca sobrescribe una medición.
Gestión de activos de TI
Inventario con el Agente Dexon, una CMDB que se mantiene sola, descubrimiento de red por SNMP, licenciamiento sobre uso real y control remoto registrado en el caso.
Traiga el proceso que nadie quiere modelar
El de la excepción que rompe todas las herramientas: la aprobación que depende del monto, el plazo que se detiene en los festivos, el paso que solo aplica en una regional. Lo modelamos en vivo.