Cómo diseñamos un sistema DEX para una multinacional de energía sin que nadie se entendiera
TL;DR
El Problema: Multinacional de energía necesitaba diseñar la experiencia digital de empleados (DEX) para su nueva sede corporativa. Equipos de RRHH sin conocimiento técnico, equipos IT hablando en jerga, y tecnología en medio sin que nadie se entendiera.
Nuestra Solución: Actuamos como "traductores" entre ambos mundos, creando un lenguaje común y una metodología de co-diseño que permitió alinear expectativas.
Resultado: Sistema DEX implementado en 9 meses (vs. 18 meses estimados), con adopción del 87% en los primeros 3 meses y reducción del 40% en tickets de soporte IT.
El Contexto
Una empresa multinacional del sector energético estaba construyendo su nueva sede corporativa en Madrid. El edificio sería un showcase de sostenibilidad y tecnología, con capacidad para 2.500 empleados. Pero había un problema: nadie sabía cómo debía funcionar la experiencia digital de los empleados.
Los Actores del Drama
"Queremos una experiencia fluida y moderna para nuestros empleados"
Traducción: No sabemos qué significa eso técnicamente
"Necesitamos definir la arquitectura de microservicios y el stack de integración"
Traducción: No entendemos qué quiere RRHH realmente
"El edificio tiene IoT, sensores, y sistemas BMS integrados"
Traducción: Tenemos tecnología pero nadie sabe para qué usarla
Las reuniones eran un desastre. RRHH pedía "una app intuitiva para reservar espacios". IT respondía con diagramas de arquitectura. Facilities hablaba de protocolos BACnet. Nadie se entendía.
El Problema Real
Después de 3 meses de reuniones circulares, el proyecto estaba paralizado. Habían gastado €180K en consultoras que entregaron documentos de 200 páginas que nadie leía. La junta directiva amenazaba con cancelar todo.
Los Síntomas del Caos
- •12 proveedores tecnológicos con soluciones incompatibles entre sí
- •47 requisitos funcionales escritos en lenguaje ambiguo ("debe ser fácil de usar")
- •Zero prototipos - todo era PowerPoint y documentos Word
- •Expectativas desalineadas - RRHH esperaba "algo como Airbnb", IT había diseñado un ERP
Nos llamaron porque el CTO había trabajado con nosotros en otro proyecto. Su brief fue directo: "Necesito que alguien traduzca entre mi equipo y el resto de la empresa. Y que lo haga rápido."
Nuestra Estrategia
En lugar de escribir más documentos, hicimos algo radical: creamos un lenguaje común que todos pudieran entender.
Fase 1: User Journey Mapping (Semana 1-2)
Organizamos talleres con empleados reales (no managers) para mapear su día típico en la oficina. Desde que llegaban al parking hasta que se iban.
7:45 → Llego al parking → ¿Dónde hay sitio?
8:00 → Subo a planta 3 → ¿Dónde se sienta mi equipo hoy?
9:30 → Necesito sala de reunión → ¿Cuáles están libres?
14:00 → Comida → ¿Qué hay en el menú del día?
16:00 → Hace calor → ¿Puedo ajustar la temperatura?
Resultado: 23 "momentos de fricción" identificados. Todos entendibles por RRHH, IT y Facilities.
Fase 2: Traducción Técnica (Semana 3-4)
Para cada "momento de fricción", creamos una ficha con 3 columnas:
| Lenguaje RRHH | Lenguaje IT | Tecnología Necesaria |
|---|---|---|
| "Reservar espacios fácilmente" | API de gestión de recursos + UI mobile-first | Sistema de reservas + Sensores de ocupación |
| "Saber dónde está mi equipo" | Servicio de localización + Permisos GDPR | Beacons Bluetooth + App móvil |
| "Ambiente confortable" | Integración con BMS + Preferencias de usuario | IoT sensores + Sistema HVAC inteligente |
Resultado: Por primera vez, todos entendían qué se iba a construir y por qué.
Fase 3: Prototipado Rápido (Semana 5-8)
En lugar de especificaciones técnicas, construimos prototipos funcionales en 2 semanas. No código de producción, solo UX/UI real que la gente pudiera tocar.
- • Reserva de salas con un tap
- • Mapa interactivo de la oficina
- • Notificaciones de eventos
- • Control individual de temperatura (muy caro)
- • Localización en tiempo real (privacy concerns)
- • Gamificación (nadie la pidió realmente)
Resultado: Ahorramos €400K al descartar features que sonaban bien en PowerPoint pero nadie usaría.
El Resultado
Pero lo más importante: los equipos aprendieron a hablar el mismo idioma. Seis meses después del lanzamiento, RRHH e IT seguían usando nuestro framework de "traducción" para nuevos proyectos.
Lecciones Aprendidas
1. Los documentos no resuelven problemas de comunicación
Escribir más especificaciones técnicas solo empeora el problema. La gente necesita ver y tocar lo que se va a construir.
2. El Owner's Engineer es un traductor, no un dictador
Nuestro trabajo no era imponer soluciones, sino facilitar que los equipos se entendieran y tomaran decisiones informadas juntos.
3. Prototipar es más barato que especificar
Construir un prototipo funcional en 2 semanas nos ahorró 6 meses de debates sobre requisitos ambiguos.
4. La tecnología es el medio, no el fin
El proyecto no era sobre IoT, APIs o microservicios. Era sobre hacer que 2.500 personas tuvieran un mejor día en la oficina.
¿Por Qué Funciona Este Enfoque?
La mayoría de proyectos tecnológicos fallan no por problemas técnicos, sino por problemas de comunicación. Los equipos hablan idiomas diferentes:
Equipos de Negocio piensan en:
- • Experiencia de usuario
- • Objetivos de negocio
- • ROI y métricas
- • Plazos y presupuestos
Equipos Técnicos piensan en:
- • Arquitectura y escalabilidad
- • Deuda técnica
- • Seguridad y compliance
- • Mantenibilidad del código
Un Owner's Engineer efectivo traduce entre ambos mundos, asegurando que las decisiones técnicas estén alineadas con los objetivos de negocio, y que los requisitos de negocio sean técnicamente viables.