1. Descubrir un proceso
Nombrar el disparador, los pasos actuales, sistemas, responsable, volumen, tiempo de gestión y excepciones conocidas. Empezar por un proceso acotado, no por un objetivo amplio como automatizar ventas.
Preparar una implementación
Cómo llevaríamos una automatización de la idea a la operación
Una automatización útil necesita un proceso definido, evidencia representativa, accesos controlados, gestión explícita de fallos y un responsable después del lanzamiento. Estos son los pasos que proponemos para hacer visibles esas decisiones.
Acordar el alcance antes de empezar
Usa este enfoque para preparar el proyecto con nosotros. Antes de empezar, acordamos qué pasos se aplican, quién aprueba cada decisión, qué pruebas hacen falta y qué soporte incluye el servicio. La propuesta recoge esos compromisos para tu proyecto.
Siete etapas de trabajo
2. Confirmar datos mínimos y permisos
Pedir solo los registros de muestra y accesos necesarios para probar el proceso. Usar cuentas con privilegio mínimo, identificar campos sensibles, acordar retención y preferir un entorno de prueba cuando exista.
3. Definir límites antes de construir
Dejar por escrito qué puede hacer el sistema, qué no debe hacer nunca, qué casos requieren una persona y qué debe detener la ejecución. Una automatización sin límites no está lista para probarse.
4. Preparar una muestra representativa
Incluir casos normales, datos ausentes, duplicados, valores inválidos, fallos de sistemas externos y excepciones de riesgo. El tamaño debe responder a la variedad y al riesgo del proceso, no a una cifra universal.
5. Diseñar errores y derivación
Clasificar errores recuperables y no recuperables. Definir reintentos, registros, alertas, un responsable humano y la información que necesita para continuar con seguridad. Un fallo silencioso impide aceptar el sistema.
6. Aceptar con criterios escritos
Acordar resultados esperados y tolerancias antes de evaluar. Registrar cada prueba, resultado observado, evidencia, decisión y problema pendiente. La aprobación debe indicar quién aceptó qué versión y alcance.
7. Asignar mantenimiento
Nombrar responsables de credenciales, integraciones, costes, monitorización y cambios. Fijar una revisión según el riesgo y la frecuencia de cambios, y mantener una vuelta atrás o alternativa manual.
Mínimos antes de un piloto
- Proceso
- Disparador, estado final, responsable actual y mapa sencillo de pasos.
- Evidencia
- Ejemplos representativos de entrada y salida, incluidos casos problemáticos.
- Acceso
- Sistemas identificados, acceso de prueba con privilegio mínimo y responsable de credenciales.
- Límites
- Acciones permitidas, acciones prohibidas, condiciones de parada y derivaciones humanas.
- Decisión
- Criterios de éxito, evidencia necesaria y persona autorizada para aceptar.
Ejemplo de muestra de prueba
Esta tabla es una plantilla, no el registro de una prueba realizada a un cliente. Sustituye los ejemplos por el proceso real y registra los resultados observados durante el piloto.
| Prueba | Condición de entrada | Comportamiento esperado | Evidencia que conservar |
|---|---|---|---|
| EX-01 | Registro válido completo | Completar una vez la acción permitida y registrar el resultado | ID de entrada, hora, ID de salida y estado |
| EX-02 | Falta un campo obligatorio | No ejecutar la acción y derivar el caso al responsable | Error de validación y registro de derivación |
| EX-03 | Evento duplicado | Detectar el duplicado y evitar una segunda acción | Clave de idempotencia y estado de duplicado |
| EX-04 | Sistema externo no disponible | Reintentar solo lo acordado, detener y alertar a una persona | Intentos, error final y recepción de la alerta |
| EX-05 | Excepción de riesgo | Pausar para revisión humana antes de una acción irreversible | Decisión, revisor y hora |
Un registro práctico de aceptación
- Versión y alcance del proceso revisado
- Casos ejecutados y salidas observadas
- Fallos conocidos, límites pendientes y riesgo residual aceptado
- Vuelta atrás o alternativa manual comprobada
- Responsable de monitorización, alertas y credenciales asignado
- Responsable de la decisión y fecha de aceptación registrados para el proyecto real
Límites que deben seguir visibles
- Superar una muestra no demuestra que todas las entradas futuras se comporten igual.
- Las salidas generativas pueden variar y necesitan umbrales de revisión propios de la tarea.
- Las APIs, permisos, precios y comportamientos de terceros pueden cambiar después del lanzamiento.
- La automatización puede mover trabajo en vez de eliminarlo si se infravaloran la revisión o las excepciones.
- Seguridad, privacidad, normativa y requisitos sectoriales necesitan revisión cualificada cuando el proyecto lo requiera.
El mantenimiento forma parte del sistema
Un proceso en producción necesita a alguien que vigile fallos, rote credenciales, revise costes de uso, apruebe cambios y confirme que las reglas de negocio siguen siendo correctas. La frecuencia adecuada depende del volumen, el impacto y los cambios. Esta página no implica un retainer ni un intervalo universal de revisión.