Más allá de Entrada, Proceso y Salida: pensamiento sistémico

¿Por qué la misma entrada enviada dos veces al mismo programa produce respuestas distintas un minuto después? Si todo sistema fuera únicamente Entrada → Proceso → Salida como una suma en una calculadora, enviar los mismos datos daría siempre el mismo resultado. En el software real no ocurre así porque los sistemas tienen memoria (estado), interactúan con otros componentes y sufren fallos parciales.

Objetivos y conocimientos previos

Partiendo de Datos, Estado y Persistencia, aprenderás por qué el modelo Entrada → Proceso → Salida es solo una aproximación inicial y cómo ampliarlo para razonar sobre sistemas reales mediante estado, transiciones, efectos secundarios, retroalimentación y límites del sistema.

El límite del modelo Entrada → Proceso → Salida

El esquema clásico Entrada → Proceso → Salida (E → P → S) resulta útil para describir un cálculo puro y aislado, como convertir grados Celsius a Fahrenheit:

Aquí no importa cuántas veces se haya ejecutado antes ni quién más lo esté usando: 20 °C siempre devuelve 68 °F.

Sin embargo, intenta explicar con ese esquema por qué una solicitud de reserva para la misma persona y la misma actividad:

• A las 10:00 devuelve: «Reserva confirmada».
• A las 10:01 devuelve: «Rechazada: ya tienes una reserva activa».
• A las 10:05, para otra persona, devuelve: «Rechazada: aforo completo».

La entrada de la solicitud es idéntica, pero el resultado cambió porque el primer proceso modificó el estado del sistema.

El modelo completo de un proceso dentro de un sistema

Para razonar con rigor sobre cualquier operación de un sistema, necesitamos examinar cinco elementos en lugar de tres:

1. Entrada: los datos suministrados por quien inicia la acción (usuario, sensor, reloj u otro sistema).
2. Estado previo: la información persistida o en memoria de la que depende la decisión (aforo actual, saldo, permisos, estado de la factura).
3. Transición de estado y efectos secundarios: qué registros cambian dentro del sistema y qué avisos o solicitudes se envían hacia afuera (por ejemplo, encolar un correo de confirmación).
4. Salida: la respuesta que recibe quien hizo la solicitud.
5. Modo de fallo: qué ocurre con el estado y qué se informa si una condición no se cumple o un recurso externo no responde.

Qué convierte a un conjunto de partes en un sistema

Un sistema no es una suma de pantallas o funciones sueltas, sino un conjunto de elementos interconectados cuyas relaciones determinan el comportamiento del conjunto:

• Límite del sistema: separa lo que está bajo el control directo de nuestras reglas (por ejemplo, nuestra base de datos de reservas) de lo que pertenece al entorno externo (el navegador del usuario, la red de internet o el servicio bancario de cobros).
• Acoplamiento entre procesos a través de los datos: el proceso de Facturación, el de Cobros y el de Acceso al servicio no necesitan llamarse entre sí a cada segundo para afectarse; basta con que compartan el estado del cliente. Si Cobros registra mal un pago, Acceso bloqueará indebidamente al usuario.
• Retroalimentación (Feedback): la salida o el resultado de una etapa se observa para ajustar el comportamiento siguiente. Por ejemplo, si el sistema detecta que el servicio de envío de correos está caído, deja los avisos pendientes en una lista de reintento en lugar de bloquear la creación de la reserva.

Dónde encajan los modelos de IA dentro de un sistema

Un error habitual hoy es pensar que «si el sistema usa IA, ya no sigue reglas de sistemas». Al contrario: cuando integras un modelo de lenguaje o un clasificador dentro de un producto, ese modelo es un componente más del sistema, con características específicas que debes acotar:

• Su salida ante una misma intención puede variar o contener errores de interpretación.
• No posee por sí mismo el estado actualizado ni las garantías transaccionales de tu base de datos.
• Por tanto, en un diseño sistémico sano, el componente de IA propone, resume, traduce o estructura borradores, mientras que las reglas deterministas del sistema validan las precondiciones y custodian el cambio de estado.

Practica

Un agente te explica cómo ha diseñado el proceso de cobro de una suscripción mensual: «Es muy sencillo: sigue el modelo Entrada → Proceso → Salida. La Entrada es el botón de pagar que pulsa el usuario, el Proceso llama a la pasarela de pago y manda un recibo por correo, y la Salida es mostrar en pantalla “¡Gracias por tu pago!”».

1. Identifica qué estado previo ha omitido comprobar ese proceso antes de intentar cobrar (piensa qué ocurre si la factura ya estaba pagada o anulada).
2. Indica qué cambio de estado interno falta especificar para que el sistema recuerde mañana que la suscripción está al día.
3. Distingue los dos efectos externos que menciona el agente (cobrar en la pasarela y mandar el correo) y explica qué debería ocurrir con el estado de la suscripción si el cobro tiene éxito pero el servidor de correo electrónico tarda o falla al enviar el recibo.

Criterio de comprensión: debes mostrar que el pago exitoso no puede perderse ni revertirse solo porque falle el envío del correo posterior, separando el cambio de estado crítico (factura pagada) del efecto secundario notificatorio (recibo por correo).

Profundiza con IA

Aquí tienes mi análisis del proceso de cobro de suscripciones más allá de Entrada → Proceso → Salida: [tu respuesta]. Revisa si he distinguido bien el estado previo, el nuevo estado, los efectos externos y los modos de fallo. Plantea qué pasaría si el usuario cierra la pestaña justo después de que la pasarela cobre pero antes de ver la pantalla de agradecimiento, y pídeme que explique cómo afecta eso a mi modelo.

Siguiente lectura

Acabamos de ver que un proceso de negocio toca interfaz, reglas, datos y avisos externos. ¿Por qué no debemos mezclar todo eso en un único bloque? Continúa con Componentes, responsabilidades y acoplamiento.