Por qué el Process Design Document (PDD) es la base de una automatización sostenible
Un PDD no debería ser documentación creada para cumplir una formalidad. Es el contrato funcional que conecta negocio y tecnología: define alcance, reglas, excepciones, sistemas, entradas, salidas y criterios de aceptación. Cuando esa definición es débil, la ambigüedad termina trasladándose al desarrollo, al testing y finalmente a producción.
Muchas automatizaciones comienzan con una conversación aparentemente sencilla.
"El usuario recibe este archivo, revisa estos datos y después los carga en el sistema."
El proceso parece claro.
Comienza el desarrollo.
Entonces aparecen las preguntas.
¿Qué ocurre si falta información?
¿Qué fecha debe utilizarse?
¿Qué usuario puede aprobar?
¿Qué pasa si existen dos registros?
¿Qué sucede cuando el sistema está fuera de servicio?
¿Debe procesarse nuevamente?
¿Dónde se registra el error?
Cada respuesta modifica la solución.
Y cuando esas decisiones no fueron definidas antes del desarrollo, el proyecto empieza a diseñarse accidentalmente mientras se programa.
Ese es exactamente el problema que un buen Process Design Document (PDD) ayuda a evitar.
El PDD conecta dos mundos
El negocio conoce el proceso.
El equipo técnico conoce cómo automatizarlo.
El PDD crea un lenguaje común entre ambos.
Su función no consiste en escribir cientos de páginas.
Su función consiste en eliminar ambigüedad suficiente para que todas las partes comprendan:
- Qué debe ocurrir.
- Cuándo.
- Con qué información.
- Bajo qué reglas.
- Qué excepciones existen.
- Qué resultado se espera.
Sin esa definición, dos personas pueden afirmar que entienden el proceso y tener interpretaciones completamente diferentes.
El alcance comienza en el PDD
Uno de los mayores riesgos de cualquier iniciativa es el scope creep.
Durante el desarrollo aparecen nuevas solicitudes.
"Ya que estamos, agreguemos esta validación."
"También podríamos procesar este otro país."
"Falta este tipo de transacción."
Muchas veces estos requerimientos no son incorrectos.
El problema es no distinguir entre el alcance aprobado y una ampliación.
Un PDD claro permite identificar:
- Inicio del proceso.
- Final del proceso.
- Actividades incluidas.
- Actividades excluidas.
- Sistemas afectados.
- Unidades de negocio.
- Tipos de transacción.
Eso protege tanto al negocio como al equipo de entrega.
Documentar reglas de negocio evita decisiones implícitas
Las reglas son el corazón de una automatización.
Por ejemplo:
- Si el valor supera X, solicitar aprobación.
- Si la orden está cerrada, no procesar.
- Si el país es determinado, utilizar otro flujo.
- Si falta información, generar excepción.
Cuando estas reglas solamente existen en conversaciones o conocimiento de usuarios expertos, el desarrollador debe interpretar.
Y una automatización no debería depender de interpretación accidental.
Las reglas deben quedar explícitas.
Las excepciones son parte del proceso
Un documento débil describe solamente el flujo ideal.
Un buen PDD describe también qué ocurre cuando las cosas no salen como se espera.
Por ejemplo:
- Archivo inexistente.
- Dato obligatorio vacío.
- Registro duplicado.
- Aplicación indisponible.
- Credencial inválida.
- Respuesta inesperada.
- Transacción bloqueada.
Cada excepción necesita una decisión.
¿Reintentar?
¿Registrar?
¿Notificar?
¿Enviar a una persona?
¿Detener todo el proceso?
Estas decisiones son parte del diseño funcional.
Entradas y salidas deben quedar definidas
Toda automatización consume información y produce información.
Definir entradas significa conocer fuente, formato, estructura, frecuencia, volumen y condiciones de validez.
Definir salidas significa conocer resultado esperado, destino, formato, registro, notificación y evidencia.
Esta disciplina reduce problemas posteriores de integración y testing.
El PDD también mejora la estimación
Es difícil estimar correctamente algo que todavía no está definido.
Dos procesos aparentemente similares pueden tener niveles de complejidad completamente distintos.
Uno puede contener cinco reglas y dos excepciones.
Otro puede contener cuarenta reglas, múltiples aplicaciones y veinte escenarios excepcionales.
Un PDD permite evaluar la complejidad real antes de comprometer desarrollo.
Testing depende de una definición clara
¿Contra qué se prueba una automatización?
Contra el comportamiento esperado.
Por eso un PDD bien construido se convierte en una referencia directa para crear escenarios de prueba.
Si existe una regla, debe existir una prueba.
Si existe una excepción, debe existir una prueba.
Si existe un criterio de aceptación, debe validarse.
Eso conecta documentación y calidad.
También facilita UAT
Durante User Acceptance Testing, los usuarios deben confirmar que la automatización refleja correctamente el proceso acordado.
Sin una referencia documental, UAT puede transformarse en una discusión subjetiva.
"Yo pensaba que esto funcionaría de otra manera."
"Siempre hacemos una excepción aquí."
"Esto debería considerar otro escenario."
Un PDD aprobado reduce considerablemente estas diferencias.
El valor del PDD continúa después del go-live
La documentación no pierde utilidad cuando la automatización entra en producción.
Meses después puede necesitarse investigar un incidente, cambiar una regla, agregar una funcionalidad, migrar una aplicación, incorporar un nuevo desarrollador o evaluar una nueva versión.
Si el proceso está correctamente documentado, el equipo no necesita reconstruir el conocimiento desde cero.
Esto reduce dependencia de personas específicas.
Un PDD debe mantenerse vivo
La documentación debe evolucionar junto con la solución.
Si producción cambia y el PDD permanece congelado, eventualmente deja de representar la realidad.
Por eso Change Management debería contemplar también actualización documental.
Código y documentación deberían contar la misma historia.
Qué debería contener como mínimo
Contexto: por qué existe el proceso y qué objetivo empresarial cumple.
Alcance: qué entra y qué queda fuera.
Proceso As-Is: cómo funciona actualmente.
Proceso To-Be: cómo funcionará después de la mejora y automatización.
Sistemas: aplicaciones, fuentes e integraciones.
Reglas: condiciones que determinan el comportamiento.
Excepciones: escenarios alternativos y tratamiento esperado.
Entradas y salidas: información consumida y producida.
Criterios de aceptación: condiciones necesarias para aprobar la solución.
Documentar no significa burocratizar
Un PDD excesivamente largo que nadie utiliza tampoco genera valor.
El objetivo no es producir documentación por documentación.
El objetivo es reducir incertidumbre.
Debe contener suficiente detalle para diseñar, desarrollar, probar, aprobar, operar y mantener.
Ni más ni menos.
La automatización sostenible comienza antes del código
Una solución técnicamente excelente construida sobre requerimientos ambiguos sigue siendo una solución de alto riesgo.
El PDD obliga a transformar conocimiento informal en una definición compartida.
Y esa definición se convierte en la base sobre la cual pueden trabajar negocio, desarrollo, testing, deployment y soporte.
La documentación correcta no ralentiza un proyecto.
Evita que la ambigüedad lo ralentice después.
