Metodología

En ShenData no aplicamos marcos genéricos de consultoría. A lo largo de más de 120 proyectos en seis países, hemos desarrollado y refinado un proceso propio que equilibra el rigor de la ingeniería con la agilidad que exigen los negocios modernos. Lo llamamos PRISM: cinco fases iterativas que llevan a una organización desde el diagnóstico honesto de su situación actual hasta la operación autónoma y escalable de sus capacidades de datos.

Lo que distingue a PRISM de otros marcos es que nunca tratamos las fases como pasos lineales inamovibles. La realidad de los proyectos de datos es compleja: los requisitos evolucionan, los datos revelan sorpresas, las prioridades del negocio cambian. Por eso diseñamos el proceso para ser robusto ante la incertidumbre, con puntos de revisión explícitos y la flexibilidad de retroceder o iterar cuando tiene sentido.

Fase 1 — Prepare (Preparación y diagnóstico)

Todo proyecto comienza con una pregunta honesta: ¿dónde está realmente la organización hoy? Dedicamos las primeras semanas a un diagnóstico estructurado de madurez de datos que cubre la calidad y accesibilidad de las fuentes existentes, la arquitectura técnica actual y sus cuellos de botella, la organización del equipo y los roles de datos, los procesos de gobierno vigentes o ausentes, y la alineación entre las expectativas del negocio y lo que los datos pueden realmente entregar.

El resultado es un mapa claro del estado actual y una hoja de ruta priorizada por impacto y viabilidad, no por preferencias tecnológicas. En esta fase también definimos los KPIs de negocio que el proyecto debe mover, porque sin ellos no hay forma de medir el éxito real.

Fase 2 — Refine (Arquitectura y diseño de solución)

Con el diagnóstico en mano, diseñamos la arquitectura de datos que mejor se adapta al contexto específico del cliente: su stack actual, sus restricciones presupuestarias, su equipo técnico y su horizonte de crecimiento. No existe una arquitectura universalmente correcta; existe la arquitectura correcta para esta empresa en este momento.

En esta fase tomamos decisiones fundamentales sobre el modelo de datos, las herramientas de integración y transformación, las plataformas de almacenamiento y procesamiento, y el modelo de gobierno que garantizará la sostenibilidad de lo que construyamos. Documentamos cada decisión de diseño con su justificación, para que el equipo cliente comprenda el ‘por qué’ detrás de cada elección técnica.

Fase 3 — Integrate (Construcción e integración)

Es la fase de mayor intensidad técnica. Construimos los pipelines de datos, los modelos, los dashboards y los sistemas de ML siguiendo estándares de ingeniería de software: código versionado, pruebas automatizadas, revisiones de pares y documentación continua. No entregamos scripts que ‘funcionan en mi máquina’; entregamos código de producción.

Trabajamos en sprints cortos de dos semanas con demos al negocio en cada ciclo, de modo que los usuarios finales validan el valor del trabajo antes de que el proyecto avance. Esto reduce drásticamente el riesgo de llegar al final con algo técnicamente correcto pero irrelevante para el negocio.

Fase 4 — Scale (Escalabilidad y operación)

Una vez que el núcleo de la solución está validado, trabajamos en su escalabilidad técnica y organizacional. Técnicamente, esto significa optimizar el rendimiento, establecer monitoreo de calidad de datos y alertas operacionales, y preparar la infraestructura para crecer sin reescribir todo. Organizacionalmente, significa transferir conocimiento al equipo interno, documentar procesos y establecer los rituales de gobierno de datos que mantendrán viva la solución en el tiempo.

Muchos proyectos de datos fracasan en esta fase, no por problemas técnicos, sino porque nadie en la organización sabe cómo mantenerlos. Nosotros le dedicamos tiempo explícito y recursos reales.

Fase 5 — Measure (Medición de impacto)

Cerramos cada proyecto con una medición formal del impacto en los KPIs de negocio que definimos al inicio. Este ejercicio tiene dos propósitos: demostrar el valor real del proyecto (en términos que el CFO entienda, no solo el equipo técnico) e identificar las siguientes oportunidades de mejora.

El cierre de un proyecto es, en nuestra experiencia, el mejor momento para planificar el siguiente, porque es cuando el equipo cliente tiene la mayor claridad sobre lo que los datos pueden hacer por su organización.

Nuestros principios de delivery

Más allá de las fases, hay cuatro principios que guían la forma en que trabajamos en el día a día:

Valor antes que perfección

Preferimos entregar algo útil rápido que algo perfecto tarde. Cada sprint debe producir algo que el negocio pueda usar o aprender de él.

Equipo integrado, no equipo externo

Nuestros consultores trabajan codo a codo con el equipo interno del cliente, no en paralelo. El objetivo es que al final del proyecto, el equipo cliente sea más capaz que al inicio.

Arquitectura escalable desde el día uno

No tomamos atajos técnicos que funcionen hoy pero generen deuda insostenible mañana. El costo de refactorizar una arquitectura mal diseñada siempre supera el costo de hacerlo bien desde el principio.

Los datos como producto

Tratamos cada conjunto de datos, pipeline o modelo como un producto interno con usuarios, requisitos y ciclo de vida propios. Esta mentalidad cambia radicalmente la calidad y la adopción de lo que se construye.