Cómo trabajamos
Nuestro principio de colaboración
kōdōkalabs trabaja con un sistema de transformación en seis fases (Diagnose, Architect, Build, Enable, Measure y Scale) y persigue una propiedad gobernada por parte del cliente, no una dependencia operativa permanente. Cada proyecto se diseña como un único sistema conectado que abarca estrategia, implantación, gobernanza, capacitación, medición y transferencia de la propiedad, y no como una serie de entregables sueltos que se pasan de mano en mano. Esta distinción importa porque es el fallo más habitual en el trabajo de transformación del marketing en general: un proveedor entrega un documento de estrategia, un rediseño de flujos de trabajo o una implantación tecnológica como un artefacto aislado, y el cliente se queda solo con la gobernanza, la formación y la medición o, peor aún, sigue dependiendo del proveedor para operar lo que se construyó. kōdōkalabs trata la instalación, la capacitación y la transferencia de la propiedad como un único sistema diseñado desde el principio, y no como un añadido cuando termina el trabajo «de verdad».
Las seis fases del kōdōkalabs Transformation System
El kōdōkalabs Transformation System recorre seis fases:
- Diagnose (evaluar la madurez, los flujos de trabajo y la gobernanza actuales)
- Architect (diseñar el modelo operativo de destino y la estructura de los flujos de trabajo)
- Build (implantar los flujos de trabajo, la infraestructura de conocimiento y los controles de gobernanza)
- Enable (formar y certificar al propio equipo del cliente en el nuevo sistema)
- Measure (establecer puntos de partida y seguir los resultados frente a ellos)
- Scale (extender los flujos de trabajo que han demostrado su valor al conjunto de la organización, manteniendo la gobernanza y la capacidad)
Cada fase produce un conjunto concreto de entregables y un traspaso concreto a la siguiente; en la página del framework encontrará el detalle completo de lo que abarca cada una.
Cómo empieza un proyecto
La mayoría de los proyectos empiezan con el Executive AI Marketing Assessment, que valida si hay encaje y ofrece una primera visión de la madurez actual de la organización en estrategia, flujos de trabajo, conocimiento, tecnología, gobernanza, capacidad y medición. A partir de ahí, un proyecto suele avanzar con la alineación del patrocinador ejecutivo, la confirmación del acceso a las fuentes y a los datos, la definición del alcance, el establecimiento de un punto de partida de medición y el acuerdo sobre los criterios de éxito, antes de que comience cualquier trabajo de diseño de flujos o de implantación.
Establecer un punto de partida de medición antes de cualquier implantación es una decisión deliberada, no un trámite. Sin un estado «previo» documentado, cualquier afirmación posterior sobre mejoras es imposible de sostener con credibilidad, un patrón que kōdōkalabs evita repetir tanto en su propio trabajo con clientes como en lo que recomienda hacer internamente a las organizaciones, según la guía del AI Marketing Maturity Model.
Funciones y responsabilidades
La ejecución implica un conjunto definido de funciones, aunque las personas concretas que las desempeñan varían según el tamaño y el alcance del proyecto:
| Función | Responsabilidad |
|---|---|
| Patrocinador ejecutivo (cliente) | Responde en última instancia del éxito del proyecto dentro de la organización del cliente |
| Responsable de negocio (cliente) | Define el resultado de negocio que debe lograr el proyecto |
| Responsable del flujo de trabajo (cliente) | Es dueño, en el día a día, del flujo de trabajo concreto que se rediseña |
| Experto en la materia (cliente) | Aporta conocimiento especializado y valida la exactitud de los datos y afirmaciones |
| Responsable de kōdōkalabs | Se encarga de la metodología de transformación, del diseño de los flujos de trabajo y de la calidad de la entrega |
| Recursos técnicos o de implantación | Construyen y configuran el flujo de trabajo, las herramientas y la infraestructura de conocimiento |
| Revisión legal, de privacidad o de seguridad (cliente) | Revisa el tratamiento de los datos, la gobernanza y las decisiones con implicaciones de cumplimiento |
| Aprobador final (cliente) | Tiene la última palabra en cada una de las tres puertas de decisión humana descritas más abajo |
No se trata de un contrato universal: el reparto concreto de responsabilidades se confirma y se documenta en cada proyecto por separado.
Cómo usamos la IA
La IA se utiliza a lo largo de todo el kōdōkalabs Transformation System para acelerar la investigación, la redacción, el análisis y el diseño de flujos de trabajo, siempre dentro de la estructura de gobernanza que describe la guía AI Governance for Marketing y la AI Ethics & Safety Statement. Lo que produce la IA pasa por la misma revisión humana basada en el riesgo que kōdōkalabs recomienda a sus clientes: el trabajo de mayor riesgo y mayor exposición recibe más revisión, no menos, y la responsabilidad final del trabajo entregado recae siempre en una persona con nombre y apellidos, nunca en un sistema de IA.
Revisión humana y puertas de decisión
En todos los proyectos, tres puntos concretos exigen una aprobación humana explícita antes de que el trabajo continúe:
- Aprobación de fuentes y evidencias: antes de que la investigación, los datos o la información aportada por el cliente sirvan de base para la estrategia o el diseño de flujos de trabajo, se confirma que son exactos y adecuados.
- Aprobación estratégica y editorial: antes de que avance un modelo operativo, un diseño de flujo de trabajo o un contenido por publicar, se revisa frente al resultado de negocio fijado para el proyecto y frente a los estándares editoriales.
- Aprobación de publicación, puesta en producción o escalado: antes de que algo salga a producción, se publique o se extienda más allá del alcance inicial del piloto, un aprobador final da su visto bueno.
Ningún entregable se salta estas tres puertas, por mucha ayuda de la IA que haya habido en su elaboración.
Estas puertas existen precisamente porque, de otro modo, la velocidad que aporta la IA puede dejar atrás la disciplina de revisión: un flujo de trabajo que genera un primer borrador en minutos no merece automáticamente una revisión de minutos. El rigor de las puertas se ajusta a lo que está en juego: los borradores internos de trabajo las atraviesan con rapidez, mientras que todo lo que llega a la audiencia, a la marca o a la exposición regulatoria del cliente recibe el peso completo de la revisión para el que está concebida cada puerta.
Evidencias y gestión de fuentes
Las decisiones de estrategia y de diseño de flujos de trabajo se remiten siempre a fuentes identificables (datos aportados por el cliente, investigación documentada o aportaciones verificadas de expertos en la materia), en lugar de afirmarse sin una base trazable. Cuando de verdad no hay evidencias disponibles, esa laguna se explicita en lugar de rellenarla con un supuesto presentado como un hecho. Esto vale tanto para el proceso interno de kōdōkalabs como para los contenidos y flujos de trabajo que se construyen para los clientes.
Gestión del alcance, de los cambios y de los riesgos
Una vez acordado, el alcance del proyecto se gestiona mediante un proceso de cambios definido y no dejando que se desvíe de manera informal: se documenta la solicitud de cambio, se evalúa su impacto y se aprueba antes de que el alcance cambie realmente. Los riesgos que se detectan durante el proyecto se registran y se elevan a la persona que debe decidir, en lugar de absorberse en silencio dentro del plan existente.
Documentación y propiedad intelectual
Los flujos de trabajo, la lógica de decisión y la infraestructura de conocimiento que se construyen durante un proyecto se documentan como parte del entregable, y no se dejan como conocimiento tácito sin documentar. Es lo que hace posibles las fases Enable y Scale.
Capacitación del equipo
Los equipos de los clientes se forman trabajando con flujos de trabajo reales y en vivo, y no con sesiones de formación genéricas desconectadas del proyecto. La fase Enable vincula específicamente a las personas del equipo del cliente con los flujos de trabajo que se están construyendo, con documentación, práctica por funciones y comentarios estructurados a lo largo del proceso. Esto refleja el marco de transferencia de capacidades que se aplica en todo el trabajo de kōdōkalabs y que se plasma de manera más directa en la AI Capability Academy.
Medición y mejora
Todos los proyectos establecen un punto de partida de medición desde el principio, durante la fase Diagnose, para que las afirmaciones posteriores sobre mejoras tengan algo concreto con lo que compararse. La medición abarca métricas operativas (eficiencia de los flujos de trabajo, coherencia, plazos), de calidad (exactitud, tasas de aprobación en la revisión) y de contribución al negocio (los resultados que el proyecto debía mover), y sus conclusiones alimentan un perfeccionamiento continuo en lugar de tratarse como un informe puntual.
Traspaso y apoyo posterior
El objetivo de todo proyecto es que el cliente asuma una propiedad gobernada: que su equipo pueda operar, mantener y ampliar los flujos de trabajo y la gobernanza construidos durante el proyecto sin depender de kōdōkalabs indefinidamente. El traspaso se evalúa con criterios de aceptación documentados (acordados de antemano) y no con una vaga sensación de que todo está «probablemente bien». Si el cliente lo desea, puede seguir habiendo asesoramiento o apoyo especializado después del traspaso, pero es una opción, no una dependencia estructural que el modelo requiera.
Qué necesitamos del cliente
Los proyectos que salen bien requieren aportaciones concretas del cliente: acceso y atención del patrocinador ejecutivo en los puntos de decisión clave; conocimiento especializado para validar la exactitud; acceso puntual a los datos de origen y a los sistemas; revisión a tiempo en cada una de las tres puertas de decisión humana; una cooperación técnica razonable del departamento de TI o de ingeniería cuando haya que integrar sistemas; y una responsabilidad de decisión clara, para que las aprobaciones no se queden bloqueadas esperando a un proceso interno confuso. Los proyectos avanzan al ritmo de la aportación necesaria más lenta, que suele ser el plazo de revisión del lado del cliente y no el ritmo de entrega de kōdōkalabs.
Preguntas frecuentes
¿Cuánto tiempo tendrá que dedicar mi equipo?
Depende del alcance y de la fase del proyecto: la atención del patrocinador es más necesaria al principio (Diagnose y Architect) y en las tres puertas de aprobación, mientras que los responsables de los flujos de trabajo y los expertos en la materia son más necesarios durante Build y Enable. Las expectativas concretas de dedicación se fijan al definir el alcance, no se dan por supuestas de antemano.
¿Qué parte del trabajo hacen las personas y cuál la IA?
La IA acelera la investigación, la redacción, el análisis y el diseño de flujos de trabajo; las personas conservan la estrategia, la aprobación final, la responsabilidad y cualquier decisión delicada o que exija criterio. Para un desglose más completo de lo que la IA apoya, de lo que ejecuta y de lo que nunca toca, véanse Cómo encajan nuestras soluciones y la guía AI Governance for Marketing.
¿Quién es el propietario de los flujos de trabajo y de la documentación que crean para nosotros?
Las condiciones de propiedad y de licencia se establecen en el contrato firmado de cada proyecto.
¿Cómo tratan nuestros datos y fuentes sensibles?
Con la misma clasificación de datos basada en el riesgo y los mismos controles de acceso que describe la guía AI Governance for Marketing: es la sensibilidad la que determina el nivel de revisión exigido y el entorno de tratamiento aprobado, no una regla única para todos los casos.
¿Qué hacen cuando faltan evidencias?
La laguna se explicita y se señala en lugar de rellenarla con un supuesto sin verificar presentado como un hecho; esto vale tanto para el proceso interno de kōdōkalabs como para los entregables dirigidos al cliente.
¿Pueden trabajar con nuestras agencias y equipos de tecnología actuales?
Los proyectos se diseñan para integrarse con la tecnología y las relaciones con agencias que el cliente ya tiene, sin exigir que se sustituyan, y las funciones y responsabilidades se aclaran al definir el alcance para evitar trabajo duplicado o contradictorio.
¿Qué ocurre después del traspaso?
Una vez cumplidos los criterios de aceptación del traspaso, el equipo del cliente opera de forma independiente los flujos de trabajo transformados; el asesoramiento o el apoyo especializado siguen disponibles si el cliente los quiere, pero el modelo está diseñado para acabar con la dependencia estructural, no para crearla.