Next WrldLa frase aparece en una reunión, casi siempre igual.
Alguien que sostiene la operación dice: "necesitamos un sistema". Todos asienten. Nadie pregunta qué significa. La reunión sigue, pero el pedido ya quedó flotando.
Nace del cansancio de corregir errores, de perseguir información, de coordinar por mensajes lo que debería fluir con orden.
El problema es que "necesitamos un sistema" describe una sensación, no un problema. Con una sensación no se puede evaluar, priorizar ni construir.
Este artículo propone traducir el síntoma a un problema observable, con fricción medible y resultado esperado.
Un pedido genérico no se puede cotizar ni decidir
Cuando alguien pide "un sistema", cada persona imagina algo distinto.
Para uno es una planilla más ordenada. Para otro, avisos que salen solos. Para otro, controlar lo que hoy no se ve. Misma palabra, cosas diferentes.
Por eso ese pedido es incomprable e incotizable. Ningún proveedor puede ponerle precio sin inventar supuestos. Ningún responsable puede priorizarlo. Ningún equipo puede construirlo sin adivinar.
¿Y si cuesta poco y resuelve mucho? ¿Y si cuesta mucho y resuelve poco? Sin definición, ambas opciones parecen iguales.
Un buen problema, en cambio, permite comparar. Permite decir qué cuesta hoy en tiempo, errores y retrabajo. Y decidir si conviene actuar ahora o después.
La pregunta es qué problema merece atención.
Dónde duele, cuándo, a quién y qué cuesta hoy
Todo síntoma se aclara con cuatro preguntas simples.
¿Dónde duele? ¿Cuándo aparece? ¿A quién afecta? ¿Qué cuesta hoy seguir así?
¿Dónde duele obliga a ubicar el proceso, no "la empresa", sino un lugar concreto como armar turnos, cubrir ausencias, registrar asistencia o cerrar la liquidación.
¿Cuándo aparece obliga a ubicar el momento. ¿Duele siempre o en picos? ¿Con los cambios de último momento? ¿Al cierre de mes, sin margen para corregir?
¿A quién afecta obliga a poner roles. ¿A quien arma los turnos? ¿A los responsables de cada sede? ¿A quien liquida y debe reconstruir lo ocurrido?
¿Qué cuesta hoy obliga a describir la fricción. Coordinación constante, errores repetidos, verificaciones a mano, decisiones sin información.
Ninguna pide tecnología. Piden observación, y observar con calma suele valer más que cualquier demostración.
El problema no es la solución que se pidió
Acá se desvían muchos pedidos.
Alguien dice "necesitamos una aplicación para los turnos". Eso es una solución supuesta. Puede ser correcta o no, pero todavía no hay elementos para saberlo.
Separar problema de solución exige preguntar qué cambiaría si esa solución funcionara. ¿Qué dejaría de doler? ¿Qué se vería distinto en la semana?
Si la respuesta es "nadie tendría que llamar a tres personas para cubrir un turno", el problema es coordinar reemplazos. Si es "cerrar la liquidación no llevaría días", el problema es la falta de información confiable sobre asistencia.
La solución pedida suele rozar el problema real, pero no lo nombra.
Una empresa madura pregunta primero "¿qué está pasando y por qué nos cuesta?".
Un problema bien escrito se puede evaluar
Un problema definido tiene una forma reconocible. Dice cuál es el proceso, cuál es la fricción, cuál es el impacto y cuál es el resultado esperado.
Proceso observable: qué parte del trabajo miramos, de inicio a fin. Quién participa, qué información entra, qué decisión sale.
Fricción medible: qué se rompe hoy. Información tardía, reglas en la memoria de una persona, cambios sin registro, controles a mano.
Impacto: qué cuesta esa fricción. Horas de coordinación, errores al liquidar, turnos mal cubiertos.
Resultado esperado: cómo se vería si funcionara, en lenguaje de operación. Menos improvisación, asistencia a tiempo, liquidación sin reconstruir la historia.
Cuando eso está escrito en lenguaje simple, cualquiera puede evaluarlo. Se puede discutir, priorizar o postergar.
Un problema que no se puede explicar sin tecnicismos todavía no está listo.
El camino se elige después, no antes
Solo con el problema definido tiene sentido elegir cómo resolverlo.
Ordenar, integrar, automatizar, comprar o construir no son lo mismo, y no todo problema necesita software nuevo.
Ordenar es acordar reglas. Quién arma los turnos, con cuánta anticipación, cómo se comunica un cambio, quién lo aprueba, dónde queda registrado. Muchas fricciones bajan solo con esto.
Integrar es usar mejor lo que ya existe. A veces la información ya está, pero en lugares separados.
Automatizar es quitar trabajo repetitivo donde el criterio ya está claro. Avisos, resúmenes, controles que hoy se revisan a mano.
Comprar o construir viene al final. A veces una herramienta existente resuelve bien. A veces hace falta crear algo a medida. Construir es válido, pero es la última opción.
La regla es simple. La menor complejidad necesaria para resolver correctamente el problema. Un buen problema definido a veces concluye "no hace falta construir".
Antes y después: turnos, asistencia y liquidación en una empresa con varias sedes
Veamos la transformación en control de personal y turnos en una empresa con varias sedes.
El antes suena así:
"Necesitamos un sistema para los turnos. Cada sede se maneja distinto, hay cambios todo el tiempo por teléfono, nadie sabe bien quién vino y quién faltó, y a fin de mes liquidar es un caos."
Todo eso puede ser cierto. Pero así no se puede decidir nada. ¿Qué duele más: armar los turnos o controlar la asistencia? ¿Los cambios o la liquidación?
El después exige observar el circuito completo.
El circuito es este: cada semana se arman los turnos por sede. Durante la semana aparecen cambios por ausencias o picos. Cada sede registra a su manera quién asistió. A fin de mes, administración reconstruye lo ocurrido para liquidar.
El problema definido podría escribirse así:
Cada semana, los responsables arman los turnos por sede en planillas separadas, sin regla común de anticipación ni aprobación. Los cambios se coordinan por mensajes y llamadas, y muchas veces no quedan registrados. La asistencia se anota en papel o de memoria, distinto en cada sede. A fin de mes, liquidar exige llamar, comparar versiones y corregir.
La fricción es visible: información dispersa, cambios sin registro, criterios distintos, verificación manual al final. El impacto es operativo: coordinación constante y errores al liquidar.
El resultado esperado se dice en lenguaje de operación: turnos publicados con anticipación conocida, cambios registrados con responsable y hora, asistencia anotada el mismo día con igual criterio, liquidación cerrada sin reconstruir la historia por teléfono.
No dice qué pantallas debe tener, qué herramienta comprar ni qué automatizar primero.
Con esto, la decisión cambia. Tal vez alcance con ordenar reglas y unificar el registro. Tal vez alcance con integrar lo existente. Tal vez convenga automatizar avisos. Tal vez haya que construir algo a medida. Cada opción se compara contra el mismo problema.
Esa es la diferencia entre pedir un síntoma y definir un problema.
Cómo saber si ya está definido
Hay una prueba simple. Si está definido, responde sin dudar a estas preguntas.
¿Se puede observar en la operación real? ¿Se sabe en qué proceso ocurre y cuándo duele más? ¿Se sabe a quién afecta? ¿Se puede describir lo que cuesta seguir así? ¿Se puede describir cómo se vería si funcionara, sin hablar de funciones?
Si alguna respuesta es vaga, falta definición. Lo vago no es poco importante, solo indica que todavía no se puede priorizar ni construir con responsabilidad.
Otra prueba: pedir a dos personas que lo expliquen. Si cuentan historias distintas, sigue abierto. Si cuentan la misma, hay base para avanzar.
Definir es no mover recursos hasta entender la operación.
Tres errores que devuelven todo al inicio
El primero es definir la solución en vez del problema. "Queremos una aplicación con tales funciones" cierra la conversación antes de entender.
El segundo es pedir cotización del síntoma. Se envía el pedido vago, llegan precios incomparables, cada uno supone algo distinto, y decidir se vuelve imposible.
El tercero es sumar pedidos de todos al definir. Cada sede agrega su deseo y el problema crece hasta volverse inabarcable. Definir también es recortar. Un proceso, una fricción, un resultado.
Evitar estos tres errores ahorra meses y evita construir algo que nadie termina de usar.
Si no se puede evaluar, priorizar y construir, todavía falta definir
Volvamos a la reunión del inicio.
La frase "necesitamos un sistema" era el aviso honesto de alguien que ve el costo en la operación. El error sería tomarla literal y salir a comprar o construir.
El trabajo serio es traducirla y convertir la sensación en proceso observable, la queja en fricción describible y el deseo en resultado esperado.
Si el problema se puede evaluar, se puede priorizar y decidir, y entonces se puede construir (o decidir no construir) con tranquilidad.
Esa es la vara. Lo que no llegue a eso, todavía es síntoma. Todo síntoma merece ser escuchado, pero ninguno debería cotizarse.