SmartPrototyping: probar el proceso antes de construirlo

El mayor valor de prototipar un proceso no está en hacerlo más rápido. Está en descubrir que estaba mal diseñado antes de comprometerte a construirlo. Esta es la historia de SmartPrototyping.

Todo empezó cuando pasé al equipo de Transformación de Banco Pichincha Perú. El reto era inmenso: cambiar por completo tres pilares del negocio, en tiempo récord y sin margen de error.

Arrancamos como siempre, diseñando el proceso en papel. El mismo método de toda la vida. Pero enseguida nos dimos cuenta de que ese proceso había que comprobarlo de alguna manera, y con tan poco tiempo y un equipo tan pequeño, no encontrábamos cómo. Las técnicas clásicas, como un Mago de Oz, nos daban algo, pero sabíamos que no iba a alcanzar.

Había además un problema más difícil que el técnico. Para transformar un negocio también tienes que transformar la cabeza de quienes lo operan, y eso no se logra mostrando un flujo en una diapositiva. Las personas son emocionales: necesitan ver algo que funcione, algo que puedan tocar. Un testeo clásico no iba a convencer a nadie.

Así que empezamos a investigar qué más se podía hacer.

#El descubrimiento: un proceso también se puede describir

En el equipo ya usábamos Bizagi. Siendo honesto, nunca me pareció una herramienta amable para diseñar, y además la usábamos mal: como un FigJam glorificado, para dibujar cajas y flechas.

Hasta que miramos cómo funcionaba por dentro. Detrás del diagrama había un modelo muy parecido a BPMN 2.0: cada paso, cada decisión y cada rol estaban descritos en una notación que una máquina puede leer.

Ese fue el clic. El modelo de proceso no es solo visual; también es descriptivo, casi como código. Y si un proceso se puede describir así, entonces se le puede explicar a un builder cómo construir las pantallas y cómo moverse de una a otra.

De ahí salió la idea: usar el modelado de procesos para generar un prototipo que funciona, con data realista, que se puede probar y medir. Un golazo, la verdad. Por primera vez podíamos correr el flujo real, con personas reales, en sus estaciones reales. Y, sobre todo, ponerle delante a ventas, a riesgos, a negocio y a todos los stakeholders algo tangible: así queremos que funcione el proceso, úsalo.

#Qué es Smart Prototyping

Con el tiempo, eso que empezó como una solución de emergencia se convirtió en un método. Lo llamo Smart Prototyping, y es mi forma de validar ideas antes de invertir en ellas. Ninguna de sus piezas es nueva: el modelado de procesos, los prototipos funcionales y la experimentación existen hace años. Lo que propongo es el orden en que se combinan y para qué se usan.

La mejor manera que encontré de explicarlo es ubicarlo entre dos cosas que todos conocen. Un prototipo de pantallas es rápido y barato, y valida muy bien si una interfaz se entiende. Pero, por sí solo, no permite comprobar cómo funciona el proceso completo entre roles, reglas y decisiones. Un piloto en cambio funciona de verdad, pero es lento, caro y, cuando sale mal, ya invertiste. Smart Prototyping está en el medio: es más real que un prototipo, porque funciona y usa data realista, y mucho más rápido y barato que un piloto.

#Se arma en tres capas, cada una con la herramienta que sea más rápida:

#Las cinco etapas

Cada experimento sigue el mismo recorrido, con plazos cortos y una regla que no se negocia: todo termina en una decisión.

Para que esa decisión no dependa de opiniones, antes de construir dejamos definido:

• La métrica principal y su línea base.
• El umbral mínimo de mejora que justifica seguir.
• Los indicadores que no pueden empeorar: seguridad, calidad, riesgo.
• Los casos que se van a probar: normales, excepciones y límite.
• Quién toma la decisión final.

Con eso, las tres salidas quedan claras. Graduar, si se cumplen los umbrales y los requisitos de riesgo. Ajustar, si hay valor pero quedan fricciones concretas que se pueden corregir con otro experimento acotado. Cerrar, si la hipótesis no se sostiene, el riesgo no es aceptable o el valor no justifica seguir.

Y una distinción importante: validar que un proceso funciona no es lo mismo que demostrar su impacto en el negocio. El prototipo permite comprobar su funcionamiento y estimar su potencial de mejora. El impacto real se confirma después, en condiciones de operación.

La última etapa es la que más me importa. Muchos experimentos fracasan sin que nadie lo diga: se quedan abiertos, se extienden, nadie los cierra. Obligarse a decidir es lo que convierte un prototipo en evidencia.

#Lo que aprendimos al correr el flujo

Lo valioso de un prototipo que funciona es que te muestra cosas que en papel no ves. Dos ejemplos de los primeros procesos que corrimos.

Una etapa que no se aceleró como esperábamos. Había un paso que ya habíamos agilizado bastante, pero que todavía requería que el usuario redactara algo. Al correr el flujo varias veces, vimos que el tiempo casi no bajaba. El motivo no estaba en ese paso: la información que la persona necesitaba para redactar no aparecía completa en su estación, así que tenía que ir a buscarla. Ajustamos el flujo para que esa información estuviera siempre en el lugar y el momento correctos. En un diagrama, ese paso se veía perfecto.

Un control que dejamos de necesitar. Por seguridad operativa, el flujo tenía varios validadores que revisaban la veracidad de la información. Al ejecutar el proceso con distintos casos, encontramos evidencia de que una de esas validaciones era redundante. Contrastamos el hallazgo con los criterios de riesgo y ajustamos el flujo para eliminarla. Sin la simulación, esa conversación habría sido opinión contra opinión.

#DeltaFlow, la consecuencia

Para poder hacer todo esto terminé construyendo una herramienta: DeltaFlow. Pero el orden importa. Primero vino el método, y DeltaFlow apareció porque el método la necesitaba.

En DeltaFlow dibujas el proceso y ese mismo diagrama corre como un prototipo multiusuario: cada rol en su pantalla, el caso viajando de uno a otro como en la operación real, con data realista. Y del mismo archivo sale la documentación para desarrollo, así que lo que se entrega no puede quedar desfasado de lo que se probó.

Conviene ser preciso sobre qué tan real es ese prototipo. Corren de verdad el flujo, los roles, las reglas de decisión, los estados y las devoluciones. Lo que se simula son las integraciones: las consultas a otros sistemas responden con servicios simulados y data realista. Por eso sirve para validar cómo funciona el proceso, pero no reemplaza las pruebas de integración, seguridad ni desempeño que vienen después.

El método no depende de la herramienta. Hoy lo aplico con DeltaFlow para procesos y reglas, Figma para el diseño e IA para el código.

Sobre la IA, un límite claro: la uso para generar código de prototipo, y únicamente eso. Me permite que la capa de código tome horas en lugar de semanas. Lo que llega a producción pasa por ingeniería, que lo endurece y lo construye como corresponde.

#Cuándo usarlo, y cuándo no

Smart Prototyping vale la pena cuando se cumplen tres condiciones: hay incertidumbre sobre el proceso completo y no solo sobre una pantalla, el resultado depende de cómo interactúan varios roles, y equivocarse en producción sería caro.

No lo uso en mejora continua, cuando el producto ya existe y solo estamos puliendo. Tampoco en procesos que ya fueron probados, ni cuando hay tiempo para trabajar de la forma clásica. Ahí un prototipo de pantallas y una buena investigación alcanzan.

#Cómo encaja con lo demás

Este post cierra una serie. En el primero conté cómo mido si un flujo funciona con el EXP Index. En el segundo, cómo decido si un diseño está listo con cuatro preguntas. Smart Prototyping es donde las dos cosas se juntan: los pilares guían lo que construimos y, en la etapa de validación, el EXP Index es una de las formas en que medimos si funcionó.

Al final, lo que hace valioso a este método no es que construya prototipos más rápido. Es que te deja descubrir que un proceso estaba mal diseñado antes de comprometerte a construirlo. DeltaFlow y la IA solo lo hacen posible.

Si estás transformando procesos y tus stakeholders necesitan ver para creer, prueba a ponerles delante algo que funcione.