Plataformas y flujos
Workflows y reglas de negocio
Cualquier solicitud muestra en qué estado está, quién la tiene pendiente y con qué versión de las reglas se decidió cada paso.
En muchas organizaciones el procedimiento existe en un documento, pero el proceso real circula por correos, hojas de cálculo y conversaciones de pasillo. Nadie sabe con certeza en qué estado está una solicitud ni quién la frenó. Un workflow bien diseñado hace visible ese recorrido: define los estados posibles, quién puede mover cada expediente de uno a otro, qué comprobaciones se hacen antes y qué ocurre cuando alguien no responde. Las reglas de negocio dejan de estar en la cabeza de una persona y pasan a estar escritas, versionadas y probadas. El punto de partida no es la herramienta, sino sentarse con quienes ejecutan el proceso y acordar cómo funciona de verdad, incluidas sus excepciones.
- Entrada de datos
- Solicitud con datos y adjuntos
- Jerarquía desde el directorio
- Validación
- Campos obligatorios y presupuesto
- Transiciones permitidas
- Procesamiento
- Reglas versionadas por expediente
- Temporizadores de escalado
- Control humano
- Aprobación por cada nivel
- Devolución con motivo
- Trazas
- Quién, cuándo y con qué regla
- Tiempo de cada fase
- Sistemas de salida
- Pedido o alta en el ERP
- Eventos para otros sistemas
Antes y después
Qué cambiaría en la operación
Ejemplo hipotético: una organización que tramita solicitudes de viaje y gastos de representación mediante un formulario y correos sucesivos.
01 · Antes
La solicitud se reenvía por correo entre jefes, se pierde en vacaciones y administración no sabe quién la autorizó ni con qué límite vigente.
02 · Sistema propuesto
Un circuito con estados define aprobadores según importe y centro, comprueba campos y presupuesto, sustituye ausentes y escala cuando vence el plazo interno.
03 · Después
El solicitante ve el estado en todo momento, administración consulta la cadena de aprobaciones y los tiempos por fase permiten detectar cuellos de botella.
Alcance
Qué resuelve y qué no
Qué puede resolver
- Modelar circuitos de solicitud, revisión y autorización con estados claros y transiciones permitidas.
- Aplicar validaciones antes de que un expediente avance: campos obligatorios, importes, documentos adjuntos o incompatibilidades.
- Asignar tareas según reglas (importe, departamento, centro, tipo de solicitud) y escalar cuando vence un plazo interno.
- Registrar quién hizo qué, cuándo y con qué versión de las reglas, para que una decisión pueda reconstruirse después.
- Separar las reglas del código de pantalla para poder cambiarlas con control de versiones y pruebas.
Qué no resuelve
- No arregla un procedimiento mal definido: si los responsables no se ponen de acuerdo sobre las reglas, el sistema solo automatiza la confusión.
- No sustituye el criterio de las personas en decisiones que requieren juicio; las reglas preparan y filtran, pero la aprobación sigue siendo de quien firma.
- No convierte por sí mismo un circuito en conforme con una norma o un procedimiento regulado: esa evaluación corresponde a la organización y a sus auditores.
Escenarios operativos
Cómo funcionaría en la práctica
Ejemplos de lo que se podría diseñar. No describen proyectos realizados.
01
Aprobación de compras por niveles de importe
- Entrada
- Solicitud de compra con importe, centro de coste, proveedor y presupuesto disponible consultado en el ERP.
- Procesamiento
- Las reglas determinan cuántos niveles de aprobación necesita según importe y tipo de gasto, comprueban si hay presupuesto y bloquean la solicitud si falta información obligatoria.
- Salida
- Tareas asignadas a cada aprobador, avisos de vencimiento, estado visible para el solicitante y pedido generado en el ERP solo tras la última firma.
02
Alta de proveedor con revisión documental
- Entrada
- Datos fiscales y bancarios del proveedor, certificados aportados y área que solicita el alta.
- Procesamiento
- El circuito reparte la revisión entre compras, administración y, si procede, calidad; cada área valida su parte y puede devolver el expediente con un motivo.
- Salida
- Proveedor activado en el sistema maestro con el historial de revisiones, o expediente devuelto con los documentos pendientes señalados.
03
Gestión de cambios en un documento técnico
- Entrada
- Propuesta de modificación con descripción, documentos afectados y justificación del solicitante.
- Procesamiento
- Se evalúa el impacto con los responsables designados, se registran comentarios y se exige la aprobación de las funciones que el procedimiento interno establezca.
- Salida
- Cambio aprobado o rechazado con traza completa, nueva revisión del documento liberada y notificación a quienes lo usan.
04
Escalado de incidencias sin respuesta
- Entrada
- Incidencia abierta con prioridad, responsable asignado y plazo interno de atención.
- Procesamiento
- Un temporizador vigila el plazo; al vencer, la regla reasigna o avisa al siguiente nivel y anota el motivo del escalado.
- Salida
- Incidencia escalada con aviso al responsable superior y registro de los tiempos de cada fase para revisar cuellos de botella.
Integración
Cómo se conecta con lo que ya existe
Un workflow casi nunca vive aislado: necesita leer datos maestros, usuarios y presupuestos de otros sistemas y escribir el resultado cuando el expediente termina. Se define qué sistema es la fuente de cada dato, qué eventos inician o cierran un circuito y cómo se comporta el proceso si un sistema externo no responde. Las reglas se guardan versionadas para que un expediente iniciado con una versión se resuelva con ella aunque las reglas cambien después.
- Usuarios, departamentos y jerarquías desde el directorio corporativo
- Datos maestros y presupuestos leídos del ERP mediante API o conector
- Eventos de inicio y fin publicados para otros sistemas
- Firma electrónica o aprobación con credenciales según el alcance acordado
- Registro de auditoría consultable y exportable
Modalidades de despliegue que suelen plantearse
Se elige en cada proyecto tras evaluar requisitos y sistemas existentes.
Antes de desarrollar
Datos, validaciones y permisos
- Un responsable por proceso con autoridad para validar las reglas y sus excepciones.
- Inventario de estados, transiciones, plazos internos y casos especiales, contrastado con expedientes reales.
- Jerarquía de aprobadores actualizada y criterio para sustituciones por ausencia o vacaciones.
- Conjunto de casos de prueba que recoja tanto el camino habitual como las excepciones conocidas.
- Acuerdo sobre quién puede modificar reglas, cómo se prueban y cuándo entran en vigor.
Supervisión
Riesgos, límites y mantenimiento
- Modelar demasiadas excepciones desde el principio complica el sistema; conviene empezar por el flujo principal y añadir casos con datos de uso.
- Si la jerarquía de usuarios no se mantiene, las tareas llegan a personas que ya no ocupan el puesto.
- Un circuito con demasiadas firmas puede volverse más lento que el proceso manual; los tiempos por fase deben revisarse.
- Cambiar reglas sin pruebas puede bloquear expedientes en curso; las versiones y su despliegue se controlan.
Sectores, servicios y lecturas relacionadas
Sectores donde se aplicaría
Cómo se contrata
Preguntas frecuentes
¿Conviene un motor de workflow comercial o desarrollarlo a medida?
Si el proceso es estándar y la herramienta ya está en la organización, configurarla suele ser razonable. El desarrollo a medida tiene sentido cuando las reglas son propias, el circuito debe integrarse a fondo con otros sistemas o las licencias no encajan con el número de usuarios.
¿Qué pasa con los expedientes en curso si cambiamos una regla?
Se decide expresamente. Lo habitual es que cada expediente conserve la versión de reglas con la que empezó y que la nueva versión se aplique a los siguientes, salvo que el responsable del proceso indique otra cosa.
¿Pueden los usuarios de negocio modificar las reglas sin programar?
Parte de ellas sí: umbrales, aprobadores o plazos pueden ser parámetros editables con permisos. Los cambios estructurales, como añadir estados o transiciones, conviene que pasen por pruebas antes de publicarse.
Cuéntanos qué procedimiento quieres llevar a un circuito verificable
Cuéntanos qué datos y sistemas intervienen en tu proceso. Estudiaremos qué puede automatizarse, cómo se integraría y qué convendría validar antes de desarrollar. Ver todas las capacidades.
Sin compromiso de aceptación: estudiamos cada caso antes de proponer nada. Cómo tratamos la información que compartes.