IA para empresas · Guía práctica
Describe el fallo de forma que otra persona pueda investigarlo.
Un mensaje como «la automatización no funciona» deja muchas preguntas abiertas. Este ejercicio convierte un fallo ficticio en un registro que permite coordinar una investigación y comprobar después la recuperación.
El proceso, de un vistazo
Observación
Entrada recibida, borrador no localizado
Investigación
Separar evidencia e hipótesis
Recuperación
Comprobar trabajo nuevo y pendiente
01Registra primero lo que has observado
Ejemplo: la solicitud S-17 aparece recibida, pero no se encuentra su borrador en la bandeja de revisión. Esperado: un borrador asociado a S-17. Observado: entrada registrada sin resultado localizado.
Anota cuándo se observó, en qué entorno y con qué identificador. Si no sabes cuándo empezó, escribe «inicio desconocido». La primera observación no demuestra que el fallo empezara en ese momento.
Referencia [1]: GOV.UK Service Manual
02Distingue alcance conocido y pendiente
Comprueba algunas solicitudes cercanas sin modificar sus datos. Registra cuáles tienen resultado y cuáles no. No afirmes que el fallo afecta a todas solo porque una ha fallado.
Antes de repetir operaciones, averigua si hay efectos parciales: quizá el borrador existe en otro destino o el registro se actualizó. Define con la persona responsable cómo evitar duplicados mientras investiga.
03Separa evidencias e hipótesis
Evidencia: el historial muestra un error en el paso de creación. Hipótesis: podría faltar acceso al destino. Confirmación pendiente: comprobar los permisos de esa conexión. No escribas la hipótesis como causa hasta contrastarla.
Comparte solo los datos necesarios para investigar. Puedes sustituir el contenido de la solicitud por un ejemplo ficticio si reproduce el problema. Mantén claves y datos personales fuera del registro compartido.
04Define cómo sabrás que está resuelto
Prueba una solicitud ficticia nueva y comprueba su borrador. Después revisa el trabajo afectado con el procedimiento acordado. Recuperar entradas anteriores y aceptar entradas nuevas son verificaciones distintas.
Cierra con alcance confirmado, causa si se conoce, cambio aplicado, evidencia de recuperación y tareas pendientes. Si la causa sigue sin conocerse, indícalo; una recuperación observada no obliga a inventar una explicación.
Fuentes y lecturas para profundizar
Estas referencias amplían los conceptos indicados. Los ejemplos y ejercicios de la guía son elaboración propia.
[1] GOV.UK Service Manual
Monitoring the status of your service ↗
Detectar y registrar problemas del servicio.
Volver al apartado relacionado
Preguntas frecuentes
¿Debo reiniciar el flujo en cuanto falla?
Primero comprueba el estado y los posibles efectos parciales según el procedimiento del equipo. Un reinicio sin esa revisión puede dificultar la investigación o repetir trabajo ya completado.
Sigue leyendo
IA para empresas
Cómo documentar una automatización para poder mantenerla ↗
Prepara una ficha de operación con entradas, reglas, responsables, errores y recuperación. Incluye un ensayo de entrega para comprobar si falta información.
IA para empresas
Cómo comprobar que una automatización no duplica trabajo ↗
Ensaya eventos repetidos, respuestas perdidas y conflictos de datos. Define la identidad de una operación antes de permitir reintentos.
IA para empresas
Automatizar con reglas o con IA: cómo elegir para una tarea ↗
Descompón una tarea de negocio y decide qué resolver con reglas, dónde probar IA y qué revisar. Incluye un ejemplo de clasificación de solicitudes.