El patrón detrás de casi todo lo que construyo

Durante un tiempo pensaba que mis proyectos eran extremadamente distintos entre sí.

Una plataforma para eventos.

Un sistema de localización de trabajadores.

Software financiero.

Logística de última milla.

Robótica.

IA.

Operaciones hoteleras.

Vistos superficialmente, no tienen demasiado en común.

Pero después de construir varios de ellos empecé a notar el mismo patrón una y otra vez.

Casi siempre estoy intentando convertir una operación difícil de observar en información estructurada.

Y una vez que existe esa información, empiezan a aparecer posibilidades.

Automatización.

Alertas.

Análisis.

Seguimiento.

Decisiones.

Ritmo: del WhatsApp a una operación estructurada

En eventos es extremadamente común encontrar operaciones repartidas entre:

• WhatsApp,
• hojas de cálculo,
• listas,
• transferencias,
• comprobantes,
• personas validando manualmente.

El problema no es que ninguna de esas herramientas funcione.

El problema aparece cuando intentas operar todo como un sistema.

Una misma persona puede aparecer escrita de formas distintas.

Un pago puede existir en una conversación pero no en una lista.

Una entrada puede validarse sin que la información vuelva al resto de la operación.

Con Ritmo, la tesis fue muy sencilla:

Convirtiendo el caos operativo de un evento en información estructurada.

Registro.

Pago.

Validación.

QR.

Acceso.

Datos.

Cuando todo forma parte del mismo flujo, dejan de existir muchos de los problemas que anteriormente requerían trabajo humano para reconciliar información.

ChiwiTracker: convertir movimiento en datos

Con ChiwiTracker, el dominio cambia completamente.

Ya no hablamos de eventos.

Hablamos de instalaciones físicas.

Personal.

Rutas.

Patrullaje.

Zonas restringidas.

Pero conceptualmente el problema es parecido.

Antes tienes una pregunta:

“¿El trabajador hizo la ruta?”

Después tienes información.

Posicionamiento.

Recorrido.

Tiempo.

Alertas.

Eventos.

Lo que anteriormente era una actividad física difícil de observar se transforma en algo medible.

Movimiento físico → información operacional.

Una vez que ocurre esa transformación, el sistema puede hacer mucho más.

Makifi: dinero como operación

Las finanzas suelen analizarse como números.

Pero cuando empecé a trabajar en Makifi me interesaba algo distinto.

Quería entender el dinero como flujo operacional.

Entradas.

Salidas.

Cuentas.

Wallets.

Monedas.

Conversión.

Registro.

Contexto.

Especialmente trabajando con múltiples monedas, el número sin contexto puede ser engañoso.

Por eso Makifi comenzó a evolucionar desde una aplicación personal hacia algo más parecido a un sistema financiero operativo.

La tesis volvió a ser similar:

Finanzas convertidas en información operacional.

El mismo patrón aparece en logística

En última milla ocurre exactamente lo mismo.

Una orden llega.

Alguien la asigna.

Un repartidor la recibe.

La entrega.

Existe evidencia.

Puede producirse una devolución.

Cuando cada parte del proceso vive en una herramienta distinta, el problema no es únicamente eficiencia.

Es visibilidad.

Nadie tiene una representación completa del estado real de la operación.

Un sistema unificado no solamente almacena órdenes.

Construye una fuente de verdad.

Incluso en robótica

Lo interesante es que este patrón terminó apareciendo también en un proyecto aparentemente completamente diferente.

Un robot autónomo.

Antes de navegar, un robot necesita convertir el espacio físico en datos.

Sensores.

Mapas.

Posición.

Obstáculos.

Rutas.

Después puede actuar.

La secuencia vuelve a ser parecida:

realidad → información → sistema → decisión.

El software empieza antes del código

Esta forma de pensar también cambió cómo abordo nuevos proyectos.

Antes de decidir:

• framework,
• base de datos,
• arquitectura,
• componentes,

prefiero hacer otras preguntas.

¿Cuál es la operación real?

¿Dónde vive actualmente la información?

¿Qué parte depende de memoria humana?

¿Dónde se duplica información?

¿Qué eventos deberían quedar registrados?

¿Cuál debería ser la fuente de verdad?

Muchas veces, cuando respondes correctamente esas preguntas, la arquitectura empieza a aparecer sola.

La automatización viene después

También existe una tentación muy grande actualmente de comenzar cualquier proyecto diciendo:

“Vamos a meter IA.”

Yo normalmente prefiero el orden contrario.

Primero:

estructura.

Después:

automatización.

Finalmente, donde realmente aporta valor:

inteligencia.

Si automatizas un proceso desordenado, muchas veces simplemente consigues producir desorden más rápido.

Si estructuras primero la operación, entonces sí puedes utilizar automatización e IA sobre una base fiable.

El patrón

Mirando todos esos proyectos juntos, terminé encontrando una frase que probablemente resume bastante bien cómo entiendo mi trabajo:

Convierto operaciones complejas en sistemas.

A veces esas operaciones ocurren en una pantalla.

A veces en una empresa.

A veces en una ciudad.

A veces dentro de un edificio.

Y otras veces las ejecuta un robot.

La tecnología cambia.

El patrón no demasiado.

Primero entender el mundo.

Después representarlo.

Después construir un sistema alrededor de esa representación.

Y solo entonces automatizarlo.