By mariogarcia Hace unos días hice un informe interno de tiempos. Nada especial: horas invertidas en un proyecto durante los últimos dos meses, clasificadas por franja horaria. Lo típico que haces para justificar avances.
El resultado me incomodó.
El 65% del tiempo invertido fue fuera de horario laboral. De ese porcentaje, poco más del 30% fue en fines de semana. El otro casi 35%, en noches y madrugadas.
Cuando presenté esas cifras, la respuesta de mi empresa fue inmediata y contundente: “Esto no se debe hacer así”. No era un reproche por el proyecto. Era una preocupación genuina por mí. Y tenían razón.
Hoy no vengo a hablarte de herramientas (todavía). Vengo a hablarte del proceso. Porque creo que ahí hay una lección que vale más que cualquier tutorial de Orchestrator.
El 16 de mayo escribí una pregunta que empieza como empiezan casi todas las cosas interesantes en tecnología: “¿Qué tal si…?”
Una afirmación tímida. Sin presupuesto, sin encargo, sin nadie pidiéndolo. Solo una intuición de que había algo ahí, en la intersección de JD Edwards, Orchestrator e Inteligencia Artificial, que podía resolver problemas reales de una forma distinta.
Esa pregunta se convirtió en una posibilidad. La posibilidad se convirtió en un MVP que funcionaba. Y el MVP fue cogiendo forma hasta convertirse en varias herramientas que hoy están a las puertas de sus pruebas de concepto: implementación en un cliente final, con un proceso real, midiendo si lo resuelven satisfactoriamente. Si pasan ese punto, se expanden a más áreas y más procesos.
De las herramientas te hablaré pronto. Hoy toca hablar de lo que hay detrás.
Mirando el camino en frío, el proyecto siguió sin saberlo un embudo de innovación que cualquier empresa con JDE debería copiar:
1. La pregunta. “¿Qué tal si?”. Coste: cero. Riesgo: cero. Aquí muere el 90% de la innovación en la mayoría de empresas, porque nadie se atreve a formularla o nadie quiere escucharla.
2. La posibilidad. Unas horas de exploración. Validar que técnicamente no es una locura. Inversión mínima, aprendizaje máximo.
3. El MVP. Algo feo pero funcional. No busca impresionar a nadie, busca demostrar que el flujo completo funciona de punta a punta.
4. La herramienta. El MVP madura: manejo de errores, casos límite, arquitectura decente.
5. La prueba de concepto. Un cliente real, un proceso real, métricas reales. Aquí no valen las demos bonitas: o resuelve el proceso o no lo resuelve.
6. La expansión. Solo si la PoC pasa, se escala a más áreas.
¿Por qué te cuento esto? Porque este embudo tiene una lógica de negocio brutal: la inversión crece solo cuando la evidencia crece. Nadie apostó seis cifras a una idea. Se apostaron horas a una pregunta, días a un MVP, y solo cuando hubo resultados medibles se habló de clientes finales. Compara eso con el clásico proyecto big-bang de automatización que consume meses de presupuesto antes de demostrar nada. La diferencia en riesgo financiero es abismal.
Ahora, la parte incómoda.
Ese 65% fuera de horario no es una medalla. Es tiempo que dejé de estar presente con mi familia. Es salud descuidada. Es un ritmo que, sencillamente, no es sostenible. Y no lo digo por quedar bien: lo digo porque ya lo corregí, se lo prometí a mi esposa y a mis hijas, y hoy el proyecto avanza a un ritmo sano.
Pero sería deshonesto negarte la otra cara: hay un tipo de trabajo en el que se te pasa una noche entera y ni la sientes. Donde superas límites que ni sabías que existían. Donde los resultados son tan buenos que el cansancio llega después, nunca durante. Eso no lo produce un salario ni una fecha de entrega. Lo produce la pasión.
Y aquí viene la reflexión que de verdad importa.
Este tipo de proyectos solo nacen en un lugar concreto: uno donde te apoyan, te inspiran y te permiten crecer. Mi empresa no me pidió este proyecto. Pero cuando lo propuse, me escucharon. Cuando avancé, me dieron seguimiento. Y cuando vieron mis números de horas, me frenaron por mi propio bien. Eso, y no otra cosa, es cultura de innovación. Gracias, Broadpin.
Para un directivo, esto se traduce en algo muy medible: el coste de oportunidad de no escuchar. Cada “qué tal si” que un técnico se guarda porque sabe que nadie lo va a atender es, potencialmente, un proceso que seguirá consumiendo horas manuales durante años. La automatización con Orchestrator e IA no empieza en una licencia ni en un partner: empieza en una conversación que alguien se atrevió a tener y alguien se dignó a escuchar.
No escribo esto para motivarte a trabajar de más. Todo lo contrario. Escribo esto para que te hagas tres preguntas:
¿Puedes proponer ideas en tu empresa y te dejan trabajar en ellas, aunque al inicio haya incertidumbre? ¿Te escuchan cuando tienes algo que aportar, aunque no sea estrictamente tu trabajo? ¿Te dan espacio para desarrollarte personal y profesionalmente?
Yo estoy en un lugar así. Y créeme: se nota en los resultados.
En las próximas semanas empezaré a contarte qué son exactamente estas herramientas de JDE + Orchestrator + IA y qué procesos van a resolver en la prueba de concepto. Si trabajas con JD Edwards y quieres verlo de primera mano —o quieres explorar cómo montar este tipo de embudo de innovación en tu propia organización—, suscríbete a la newsletter o escríbeme directamente. Esto es solo el comienzo.