Saltar al contenido Carlos Torres · Aprendizaje aplicado MÓDULO 06 Documenta un proceso y diseña una automatización Describe lo que ocurre, reconoce excepciones y prueba un diseño en papel antes de conectarlo a herramientas. Módulo gratuito · 60 minutos orientativos · Noviembre 2026 Un procedimiento breve y una especificación de automatización con control humano y pruebas simuladas. Imprimir o guardar como PDF Descargar texto editable Ver todos los programas Descargar solo ejercicios La impresión incluye las soluciones. Para practicar sin abrirlas, usa el texto de solo ejercicios. Antes de empezar Para quien repite una tarea sencilla y quiere entenderla antes de pensar en automatizarla. Qué necesitas Saber definir entregables y dependencias; recomendado el curso 03. No necesitas programar, crear cuentas, conectar aplicaciones ni usar una plataforma de automatización. Puedes usar una herramienta de IA que ya tengas disponible sin contratar un plan. Todos los ejercicios también se resuelven en papel o en un editor de texto, con las referencias incluidas. Ninguna lección requiere enviar mensajes, conectar cuentas ni hacer una publicación. Todos los casos, entidades, registros y fechas de práctica son inventados. Trabaja con ellos, sin incorporar datos privados, documentos de empresas ni información de terceros. Los prompts son propuestas de instrucciones, no garantías de resultado. Al terminar podrás Documentar entradas, pasos, salidas y excepciones sin inventar reglas. Separar el proceso actual de una automatización propuesta. Simular duplicados, errores y revisiones sin ejecutar acciones reales. Lee la explicación, resuelve el ejercicio y después abre la referencia. La redacción puede variar: comprueba reglas, evidencia y alcance. El texto editable sirve para conservar tus respuestas; este HTML no tiene campos ni guardado automático. La duración es orientativa; avanza a tu ritmo. Contenido 1. Describe el proceso actual y marca lo desconocido 2. Diseña un cambio pequeño con control humano 3. Ensaya rutas normales y fallos en papel Proyecto y autoevaluación Comprobación propia de este módulo Probar el diseño con estados y excepciones, manteniendo separadas la simulación, la revisión y cualquier ejecución futura. LECCIÓN 1 · 10 minutos orientativos 1. Describe el proceso actual y marca lo desconocido Automatizar un proceso confuso puede repetir sus errores más rápido. Primero escribe su propósito, inicio, datos de entrada, pasos, salida, roles y excepciones. Describe lo que está respaldado, no una versión ideal que parezca más ordenada. Distingue regla confirmada de propuesta. “La persona revisora confirma la categoría” puede ser una regla del caso; “si nadie responde se aprueba solo” añade una decisión que requiere autorización. Si el rol aprobador no se conoce, deja el dato pendiente en lugar de inventarlo. Un procedimiento debe indicar qué ocurre cuando falta información. Ese camino de excepción es parte del proceso, no un error de redacción. Explica también qué queda fuera de alcance para evitar que una instrucción de clasificación se convierta en una orden de compra o envío. Proceso ficticio documentado Notas: “Una persona revisa fichas de materiales educativos. Cada ficha debe tener un código y una categoría. Si falta categoría, la devuelve para aclarar. No compra ni publica”. Inicio: ficha disponible. Entrada: código y categoría. Paso 1: revisar campos. Si falta categoría, se devuelve para aclarar y puede anotarse el motivo; las notas no especifican qué se hace cuando están completos los campos. Ese siguiente paso y su salida quedan por confirmar. Rol: persona revisora. Fuera de alcance: comprar o publicar. No consta plazo ni regla para código faltante: ambos quedan por confirmar antes de cerrar el procedimiento. Prompt para una práctica opcional con IA Documenta únicamente estas notas ficticias: [notas]. Entrega propósito, inicio, entradas, pasos, salidas, roles, excepciones y fuera de alcance. Distingue regla respaldada, propuesta y dato por confirmar. No inventes aprobaciones, plazos ni acciones externas. No conectes herramientas ni ejecutes el proceso. Copiar prompt de la lección 1 Tu ejercicio Documenta las notas del ejemplo y escribe dos preguntas necesarias para completarlas. Señala dónde pondrías la excepción de categoría faltante. Referencia comentada del ejercicio La excepción va después de revisar campos: categoría ausente → devolver para aclarar. Preguntas: ¿qué hacer si falta el código? ¿qué paso y salida corresponden cuando los campos están completos? Tampoco consta plazo. No afirmar ficha revisada ni aprobada: las notas no describen una salida para el caso completo. Antes de avanzar La documentación separa los pasos confirmados, la excepción y la salida todavía desconocida; los huecos siguen visibles. LECCIÓN 2 · 10 minutos orientativos 2. Diseña un cambio pequeño con control humano Una especificación propuesta explica qué evento iniciaría el trabajo, qué condiciones comprobaría y qué salida produciría. En este módulo diseñamos un asistente que prepara borradores locales para revisión; no lo conectamos ni le damos credenciales. Distingue cuatro estados principales: recibido, por aclarar, borrador para revisar y revisado por una persona. Por aclarar equivale a requerir aclaración. Añade estados de excepción para duplicado, conflicto y error; en la lección 3 distinguirás también resultado incierto. Si falla una operación del diseño, usa error pendiente de revisión. Ninguno significa enviado o publicado. El estado revisado solo cambia cuando se registra la revisión humana definida. Piensa en duplicados antes de automatizar. Un identificador estable puede impedir procesar dos veces el mismo evento. Si llega el mismo identificador con datos diferentes, no lo descartes silenciosamente: marca conflicto y pide revisión. Define también qué información mínima se conservaría y quién podría verla en una implementación futura. Diseño pequeño, todavía sin ejecutar Propuesta para una ficha: comprobar primero que tiene código. Si existe una fila con ese código, comparar versiones: iguales → duplicado; diferentes → conflicto, aunque además haya un campo inválido. Si no existe fila, comprobar campos: incompleta → registro por aclarar sin fila; completa → fila de borrador. Solo esa fila es una salida del diseño. La persona revisora compara la fila con la ficha antes de marcarla revisada. Un registro de aclaración no es una fila de salida ni impide revalidar una corrección con el mismo código. El conflicto conserva la fila previa y los motivos de invalidez, sin sobrescribir ni crear otra fila válida. Son reglas propuestas, no deducciones del proceso incompleto de la lección 1. No enviar, publicar ni borrar registros. Prompt para una práctica opcional con IA A partir de este procedimiento [procedimiento], diseña una propuesta sin ejecutarla. Define evento de inicio, campos mínimos, condiciones, salida local, estados, control humano, duplicados, conflictos, error y registro mínimo. Separa reglas confirmadas de decisiones de diseño propuestas. No elijas ni conectes herramientas, no envíes datos y no solicites credenciales. Copiar prompt de la lección 2 Tu ejercicio Especifica el tratamiento de tres casos: ficha nueva completa, repetición exacta y mismo código con categoría distinta. Explica quién puede cambiar el estado a revisado. Referencia comentada del ejercicio Nueva completa → borrador para revisar. Repetición exacta → registro de duplicado, sin segundo borrador. Código igual con categoría distinta → conflicto para revisión, sin sobrescribir. Solo la persona revisora tras comparar entrada y borrador puede marcar revisado. Estas son reglas de la propuesta; el ejemplo original no las confirmaba como proceso existente. Antes de avanzar El diseño produce un borrador y distingue duplicado exacto de conflicto, sin convertir silencio en aprobación. LECCIÓN 3 · 10 minutos orientativos 3. Ensaya rutas normales y fallos en papel Una simulación consiste en recorrer entradas inventadas paso a paso y anotar la salida esperada. No demuestra que un sistema conectado funcione. Sí permite detectar reglas incompletas antes de invertir tiempo en herramientas. Cada prueba necesita entrada, estado previo, resultado esperado y explicación. Incluye un caso normal, un campo faltante, un duplicado, un conflicto y un fallo. Revisa también qué ocurre después de corregir un error: no debe reaparecer un borrador duplicado. Un fallo no autoriza un reintento ilimitado. Define un estado visible, conserva la evidencia necesaria y pide revisión para reintentar. Distingue un error confirmado de un resultado incierto: si no sabes si se creó la salida, compruébala antes de intentar de nuevo. Antes de una implementación futura harían falta elegir herramientas, validar permisos, probar almacenamiento, control de acceso y recuperación. Nada de eso se comprueba porque un diagrama esté bien escrito. Dejar esos límites registrados mejora la calidad de la propuesta. Ensayo comentado Entrada X1 con código y categoría; registro vacío → se simula un borrador X1. Segunda entrada idéntica X1 → duplicado, no otro borrador. Si al guardar X2 no sabemos si se creó la salida → estado resultado incierto, detener y comprobar registro/salida antes de reintentar. Resultado del ensayo: las reglas cubren estos caminos en papel. No se creó ningún archivo operativo ni se conectó una aplicación. Prompt para una práctica opcional con IA Revisa esta especificación propuesta [diseño]. Crea pruebas en papel con entrada, estado previo, recorrido, salida esperada y criterio de éxito para normal, campo faltante, duplicado, conflicto y error. Distingue error confirmado de resultado incierto. No ejecutes acciones y no presentes la simulación como prueba de integración. Copiar prompt de la lección 3 Tu ejercicio Añade una prueba para resultado incierto y otra para reintento después de confirmar que no existe salida. Identifica qué tendría que verificarse en una herramienta futura. Referencia comentada del ejercicio Incierto: salida no confirmada → detener y comprobar; no reintentar a ciegas. Si una revisión confirma ausencia de salida y el dato es válido, se puede proponer un reintento controlado usando el mismo código y comprobando duplicados antes. En una herramienta habría que verificar persistencia, errores de escritura y permisos: el papel no los acredita. Antes de avanzar Las pruebas muestran estados previos y resultados esperados, y reconocen qué no fue ejecutado. PROYECTO FINAL DEL MÓDULO Demuestra lo que aprendiste Caso ficticio: un taller comunitario ordena tarjetas de actividades. Reglas actuales confirmadas para este ejercicio: cada tarjeta contiene ID, título y categoría. Las categorías permitidas son exactamente lectura y dibujo en minúsculas; Lectura no es válida. La persona revisora comprueba los campos; si faltan o la categoría no pertenece a esas dos, deja la tarjeta por aclarar. Una tarjeta completa se copia como borrador de una fila local. Después la persona revisora compara con la tarjeta y, si coincide, la marca revisada. Nunca se envía, publica, compra ni elimina nada. Diseña una propuesta para preparar esas filas, con las siguientes reglas de diseño obligatorias para el proyecto: mismo ID y contenido idéntico = duplicado sin nueva fila; mismo ID con contenido distinto = conflicto sin sobrescritura, incluso si la nueva entrada tiene un título vacío o categoría no permitida; registra también esos errores de campo; error confirmado sin salida = detener, registrar y proponer reintento solo tras revisión; resultado incierto = detener y comprobar antes de decidir reintento. Las decisiones de revisión siguen siendo humanas. Definiciones para todas las reglas y pruebas: salida significa exclusivamente una fila de borrador o revisada. Registro es una anotación de estado y motivo; por aclarar, duplicado, conflicto o error no crean una salida nueva. Si el ID solo tiene un registro por aclarar y ninguna fila, una corrección se valida como entrada nueva, conservando el historial. Campos de comparación: título y categoría exactos después de quitar espacios al inicio y final; no se cambian mayúsculas ni espacios interiores; el ID es exacto, sin cambiar mayúsculas ni ceros; ID vacío o compuesto solo de espacios se considera ausente. Esta es una regla de diseño propuesta, no una deducción sobre datos reales. Un registro por aclarar no bloquea para siempre el ID: al llegar una corrección se vuelve a validar; no se considera revisada por haber sido corregida. Precedencia: si falta ID, por aclarar; si el ID tiene una salida existente, compara versiones antes de rechazar por campos y conserva el conflicto junto con los motivos de invalidez. Si no existe salida con ese ID, valida campos para decidir entre por aclarar y borrador. Para una salida ya existente, conserva siempre la comprobación de duplicado o conflicto. Entrega cinco piezas: 1) procedimiento actual, 2) especificación propuesta con estados, 3) tabla de doce pruebas con salida esperada, recorrido y criterio de éxito, 4) registro mínimo y propuesta de privacidad, 5) límites y siguiente validación. Usa las entradas y estados previos de la tabla siguiente; no necesitas inventar datos ni consultar la solución. Tiempo orientativo: 30 minutos. Si la tabla no cabe en tu pantalla, desplázala horizontalmente; con teclado, enfoca la región de la tabla y usa las flechas. Entradas y estados previos para tus doce pruebas Prueba Entrada ficticia Estado previo dado 1. Normal T01 / Ronda / lectura Sin salida ni registro. 2. Campo ausente y corrección T02 / título vacío / dibujo; después T02 / Trazo / dibujo Sin salida. Recorre ambas entradas y conserva la revisión humana. 3. Categoría inválida nueva T03 / Canto / música Sin salida. 4. Duplicado exacto T01 / Ronda / lectura Existe una fila T01 / Ronda / lectura en borrador para revisar. 5. Conflicto válido T01 / Ronda / dibujo Existe una fila T01 / Ronda / lectura. 6. Conflicto e invalidez combinados T01 / Ronda / música Existe una fila T01 / Ronda / lectura. 7. Error confirmado T04 / Líneas / dibujo Se simuló fallo al escribir; se comprobó que no existe salida. 8. Resultado incierto T05 / Relato / lectura Se simuló fallo sin saber si existe salida. Considera comprobación con salida idéntica, distinta o ausente. 9. Conflicto y título ausente T01 / título vacío / lectura Existe una fila T01 / Ronda / lectura. 10. Espacios exteriores ID T01; título « Ronda »; categoría « lectura » Existe una fila T01 / Ronda / lectura. Los espacios dentro de comillas forman parte de la entrada. 11. ID con distinta mayúscula t01 / Ronda / lectura Existe fila T01 / Ronda / lectura, pero no hay fila con ID t01. 12. Categoría con mayúscula T06 / Ronda / Lectura No hay fila con ID T06. Cada prueba es independiente y su estado previo se da como supuesto ficticio. No hay una salida real ni debes ejecutar una escritura para completarla. Ver solución completa y comentada 1. Procedimiento actual Propósito: ordenar tarjetas para revisión, sin distribución. Inicio: tarjeta disponible. Entradas: ID, título, categoría; categorías permitidas lectura/dibujo. Rol: persona revisora. Comprobar campos. Si falta alguno o la categoría no es permitida, estado por aclarar; registro: motivo de aclaración; no es una fila de salida. No copiar como borrador válido. Si cumple, copiar una fila local como borrador con los tres campos. La persona revisora compara fila y tarjeta; solo si coincide marca revisada. Si no coincide, la mantiene para corrección. Salida: borrador o fila revisada, sin envío, publicación ni borrado. No se proporcionan herramienta, plazo ni política de conservación. Son pendientes para una eventual implementación; no se inventan como reglas actuales. 2. Especificación propuesta, sin ejecutar Evento hipotético: recibir una tarjeta en un espacio local de prueba. No hay disparador instalado. Normalizar solo espacios iniciales/finales en título y categoría; conservar ID exacto. Comprobar que el ID no está vacío ni compuesto solo de espacios; conservar literalmente los demás ID. Si hay salida con ese ID, comparar versiones antes de tratar errores de otros campos. Si no hay salida, validar título y categoría antes de copiar. Estados: recibido → por aclarar si ID vacío o compuesto solo de espacios. Con ID, consultar primero si existe salida. Si no existe, validar campos: por aclarar si inválido, borrador para revisar si válido. Una aclaración corregida puede volver a validarse. No considerar como procesada una salida que nunca se creó. Si existe salida con mismo ID y título/categoría iguales: duplicado, sin nueva fila; si el contenido difiere: conflicto, sin sobrescribir, aunque el nuevo título falte o la categoría sea inválida. Registrar conflicto y el motivo de invalidez, sin crear otra fila válida. Mantener las dos versiones disponibles para revisión; la fila previa conserva su estado y no queda aprobada por este evento. Solo si no existe salida previa con ese ID y todos los campos son válidos: preparar una fila con ID, título, categoría y estado borrador para revisar. La persona revisora compara los tres campos con la tarjeta. Si coinciden, puede marcar revisada; si no, pedir corrección. Ningún paso conduce a enviado o publicado. Error confirmado sin salida: detener, registrar el motivo conocido del error (o “motivo por determinar” si no se conoce), sin marcar procesado; proponer reintento solo después de revisión humana. Resultado incierto: detener y comprobar si existe salida antes de cualquier reintento. Si existe, aplicar duplicado/conflicto; si no existe y una persona autoriza el reintento, volver a validar con el mismo ID. No hay acción de envío, conexión, publicación, compra ni eliminación. Las reglas de duplicados y error describen la propuesta solicitada, no un sistema ya funcionando. 3. Doce pruebas resueltas en papel Si la tabla no cabe en tu pantalla, desplázala horizontalmente; con teclado, enfoca la región de la tabla y usa las flechas. Resultados esperados de las doce pruebas simuladas Prueba y entrada Estado previo Salida esperada y criterio de éxito 1. T01 / Ronda / lectura Sin salida ni registro Validar → borrador para revisar. Solo tras comparación humana coincidente: revisada. Una fila, cero envíos. 2. T02 / vacío / dibujo Sin salida Por aclarar por título ausente: solo registro, cero filas de salida. La corrección T02 / Trazo / dibujo encuentra un registro, pero ninguna fila; se revalida y produce un borrador para revisión, no conflicto ni aprobación. 3. T03 / Canto / música Sin salida Por aclarar por categoría no permitida. No inventar una categoría sustituta ni crear fila válida. 4. T01 / Ronda / lectura Existe T01 / Ronda / lectura Duplicado. Se conserva una sola fila y su estado previo; no exige aprobar de nuevo ni crea otra. 5. T01 / Ronda / dibujo Existe T01 / Ronda / lectura Conflicto. No sobrescribir lectura ni crear una segunda fila válida; revisión humana pendiente. 6. T01 / Ronda / música Existe T01 / Ronda / lectura Conflicto y categoría no permitida. Comparar por ID antes de descartar por categoría; registrar ambos motivos. No sobrescribir, no producir otra fila válida. 7. T04 / Líneas / dibujo Escritura falló; ausencia de salida comprobada Error pendiente de revisión; no marcar procesado. Tras revisión y autorización simulada, revalidar y comprobar ausencia antes de un reintento; éxito esperado: una fila. 8. T05 / Relato / lectura Fallo con salida incierta Detener. Si comprobación encuentra la misma salida, duplicado; si encuentra contenido diferente, conflicto; si confirma ausencia, revisión antes de reintento. Nunca repetir a ciegas. 9. T01 / título vacío / lectura Existe fila T01 / Ronda / lectura Conflicto y título ausente. Conservar ambos motivos y la fila previa; ninguna nueva fila válida. 10. ID T01; título « Ronda »; categoría « lectura » Existe fila T01 / Ronda / lectura Quitar solo espacios exteriores de título/categoría → Ronda y lectura. Mismo ID y contenido normalizado: duplicado, una sola fila. 11. t01 / Ronda / lectura Existe T01 / Ronda / lectura; no existe t01 El ID es exacto: t01 es diferente de T01. Campos válidos → nuevo borrador con ID t01, sin alterar T01; requiere revisión humana. 12. T06 / Ronda / Lectura No existe fila T06 Por aclarar: Lectura no coincide con lectura ni dibujo. Crear solo registro de motivo, sin fila de salida ni conversión automática a minúsculas. Estos son resultados esperados derivados manualmente, no resultados de una aplicación. Todas las pruebas usan los estados previos ficticios del enunciado, sin depender de ejecutar otra. La prueba 6 fija la precedencia de conflicto sobre el rechazo aislado por campo inválido. En la prueba 2, corregir un campo no aprueba la fila: todavía exige comparación humana. 4. Registro mínimo y privacidad propuesta Propuesta de campos de registro: ID ficticio, estado, motivo breve (por ejemplo, título ausente o conflicto), existencia de salida y resultado de revisión. La fila borrador conserva solo ID, título y categoría. No guardar contactos ni transcripciones personales. Para comparar duplicados, consultar la fila existente y la entrada actual; un registro de eventos no sustituye esa comprobación. En una implementación futura, proponer acceso limitado al rol revisor y definir con la persona responsable conservación, corrección y eliminación antes de usar datos reales. No se fija un plazo inventado. En esta práctica todos los registros se escriben en papel con datos ficticios. 5. Límites y siguiente validación Se revisó la cobertura lógica de doce rutas y las salidas esperadas. No se probaron disparadores, cuentas, almacenamiento, permisos, concurrencia ni recuperación real. Siguiente paso propuesto: validar el procedimiento y la propuesta con el rol responsable; después, si se autoriza otra fase, crear un prototipo aislado con datos ficticios y comprobar duplicados y persistencia. Esta entrega no incluye ese prototipo ni autoriza acciones externas. Autoevaluación del proyecto · 10 puntos Procedimiento actual — 0: inventa reglas actuales o falta la ruta de aclaración; 1: describe pasos pero omite entradas, rol o salida; 2: documenta entradas, validación, aclaración, copia y revisión humana con límites. Diseño y estados — 0: marca aprobado por silencio o incluye una acción externa; 1: separa borrador/revisión pero deja un estado o transición ambiguo; 2: define validación, borrador, revisión, aclaración, conflicto y errores sin ejecución. Duplicados y recuperación — 0: sobrescribe conflicto o reintenta sin comprobar; 1: cubre duplicado pero deja corrección o error ambiguo; 2: distingue fila de registro, revalida T02, aplica normalización y conflicto antes de rechazar campos, y diferencia error confirmado e incierto. Pruebas — 0: no presenta pruebas o afirma integración real; 1: presenta parte de las doce sin estado previo o éxito observable; 2: incluye las doce, con ambos conflictos inválidos, espacios e ID/categoría con mayúsculas, entrada, estado previo, resultado esperado y criterio comprobable. Registro y límites — 0: incluye datos privados o declara funcionamiento real; 1: propone registro pero omite accesos, conservación o siguiente validación; 2: define datos mínimos, acceso/conservación pendientes y límites con siguiente validación. Asigna 0, 1 o 2 por criterio usando su descriptor y cita una parte de tu entrega para justificar cada nota. Un envío o publicación, aprobación automática, sobrescritura de conflicto o reintento ciego deja el diseño NO LISTO. Para considerar completa esta práctica, busca 8/10 o más, ningún criterio en 0 y ningún fallo crítico. Si no lo alcanzas, corrige las piezas afectadas y vuelve a evaluarlas; una nota no sustituye la corrección. Es un criterio orientativo de autoevaluación, no una certificación ni permiso de uso externo. Práctica opcional de transferencia · 5 minutos adicionales Variantes opcionales, independientes de las doce pruebas obligatorias. A) Entrada ID 01 / Ronda / lectura; existe fila con ID 1 / Ronda / lectura, pero ninguna con 01. B) Entrada ID de tres espacios / Ronda / lectura; no hay fila. C) Entrada T01 / Ronda / Lectura; existe fila T01 / Ronda / lectura. Para cada una indica estado, motivos, filas nuevas y revisión pendiente. Referencia de la práctica opcional A: 01 y 1 son ID distintos; no quitar el cero. Si todos los campos cumplen, un borrador nuevo con ID 01 y revisión humana pendiente; la fila 1 no cambia. B: ID compuesto solo de espacios se considera ausente según la regla anunciada. Por aclarar; registro de motivo, cero filas nuevas; necesita un ID válido antes de generar borrador. C: conflicto y categoría no permitida; cero filas nuevas. Mantener fila anterior y registrar ambos motivos, con revisión humana pendiente. No convertir Lectura a lectura para ocultar el conflicto. Cada variante distingue registro y fila, conserva el ID literal válido y documenta revisión pendiente. Transfiérelo a una práctica propia Documenta una tarea personal sencilla en papel, sin datos de otras personas. Mantén separados el proceso confirmado y la mejora propuesta. Simula las rutas con identificadores inventados; no conectes cuentas ni uses credenciales para completar este módulo. Siguiente paso Continúa con Crea un recurso educativo y comprueba su calidad para convertir un procedimiento claro en una práctica enseñable. Ir al módulo 07 Volver a la ruta de aprendizaje ← Programa anterior · Ruta de aprendizaje · Siguiente programa → Contenido original y casos ficticios. Las respuestas de IA requieren revisión humana. Las soluciones sirven para contrastar tu trabajo; la práctica no incluye certificación. hola@carlostorres.site