Clase 36 · Comunicación, piloto y medición

Clase independiente 36 de 66 · Nivel: Avanzado-Producción · Fuente base: informes del BIS y el WEF, casos públicos documentados y The Blockchain and the New Architecture of Trust (Werbach)

⬅️ Clase anterior · 📚 Índice de las 66 clases · 🗂️ Mapa del tema · ➡️ Clase siguiente

Punto de partida

Pregunta guía: ¿Cómo se prueba valor sin prometer una transformación completa?

Caso que abre la clase: Una PoC exitosa no contempla integración, soporte ni responsabilidad legal.

Una PoC técnica enfrenta preguntas de adopción, soporte, legal y operación. El piloto se diseña para invalidar hipótesis, no para confirmar entusiasmo.

Fundamentos que sostienen la respuesta

1. hipótesis y alcance. En esta clase delimita qué objeto o relación estamos observando antes de sacar conclusiones. Localízalo explícitamente en «Una PoC exitosa no contempla integración, soporte ni responsabilidad legal.» y anota qué dato faltaría para refutar tu lectura.
2. PoC, piloto y producción. En esta clase explica el mecanismo que conecta la situación inicial con el cambio observable. Localízalo explícitamente en «Una PoC exitosa no contempla integración, soporte ni responsabilidad legal.» y anota qué dato faltaría para refutar tu lectura.
3. KPIs técnicos y de negocio. En esta clase permite contrastar el resultado y formular el límite de la evidencia. Localízalo explícitamente en «Una PoC exitosa no contempla integración, soporte ni responsabilidad legal.» y anota qué dato faltaría para refutar tu lectura.

El caso de negocio, con la cuenta hecha

Un comité no aprueba "innovación": aprueba un número. Hagamos la cuenta de un caso concreto —conciliación de facturas entre una empresa y sus 40 proveedores— porque el método sirve para cualquier otro.

Paso 1 — cuantificar el dolor actual. Sin esto, no hay conversación:

40 proveedores × 300 facturas/mes    = 12 000 facturas
Discrepancias que exigen intervención humana (3 %)  =    360 casos/mes
Tiempo medio por caso                =     25 min
                                       ─────────────
                                        150 h/mes  ≈  1 persona a tiempo completo
Coste cargado (~35 €/h)              ≈  5 250 €/mes  ≈  63 000 €/año

Paso 2 — el coste total, no el del desarrollo. Aquí es donde mueren los casos mal hechos:

Paso 3 — la comparación honesta. El ahorro son 63 000 €/año y el coste recurrente 67 000 €/año. El caso no se sostiene: nunca se amortizan los 227 000 € iniciales, porque ni siquiera cubre su propia operación.

Y esa es la conclusión correcta. Un análisis que siempre dice que sí no es un análisis.

Qué habría cambiado el resultado:

• Más volumen. Con 400 proveedores en vez de 40, el ahorro sube a ~630 000 €/año y el coste apenas se mueve. Los proyectos de conciliación se justifican por escala.
• Un beneficio adicional cuantificable, como reducir el plazo de pago y con ello el capital circulante inmovilizado.
• Una alternativa más barata que funcione igual. Y aquí la pregunta incómoda: una API compartida con registros firmados y un tercero neutral resolvería buena parte del problema por una fracción del coste. Si la respuesta es que sí, el caso honesto es no usar blockchain.

💡 En una frase: el caso de negocio no lo decide la tecnología, lo decide la escala. Y un análisis serio tiene que poder terminar en "no".

Gráfico pedagógico

Recorre el gráfico en voz alta: identifica supuestos, transformaciones y el punto exacto donde aparece evidencia.

sequenceDiagram
  participant E as Estudiante
  participant S as Sistema
  participant R as Revisor
  E->>S: aplica hipótesis y alcance
  S-->>E: expone PoC, piloto y producción
  E->>R: contrasta KPIs técnicos y de negocio
  R-->>E: acepta, cuestiona o pide evidencia

Demostración de aprendizaje

Entregable: Pitch y tablero de decisión go/no-go con riesgos explícitos.

Comprobación formativa: Define una condición concreta que obligaría a detener el piloto.

Para aprobar debes conectar el hecho observado con el concepto correcto, descartar al menos una interpretación alternativa y redactar una conclusión cuyo alcance no exceda la prueba.

Trabajo práctico

Método propio: audiencia de inversión simulada.

Actividad: Convertir una demo en plan de piloto con usuarios y métricas reales.

Trabaja en entorno local, regtest, signet o testnet según corresponda. Conserva entradas, comandos, salidas y bloque o instante de corte. Una captura aislada no demuestra reproducibilidad.

Errores que esta clase corrige

• Tratar hipótesis y alcance como una etiqueta suficiente, sin identificar actores, dato y frontera.
• Usar PoC, piloto y producción como explicación aunque el caso no aporte la evidencia necesaria.
• Dar por respondido «¿Cómo se prueba valor sin prometer una transformación completa?» sin contrastar KPIs técnicos y de negocio.

Vuelve al caso inicial, elige el error más peligroso y describe una comprobación concreta que lo detectaría.

Fuentes para comprobar y ampliar

• BIS — informes sobre tokenización y dinero digital: https://www.bis.org/
• World Economic Forum — informes de adopción blockchain: https://www.weforum.org/
• MiCA — Reglamento (UE) 2023/1114: https://eur-lex.europa.eu/eli/reg/2023/1114/oj

Consulta además la bibliografía razonada, que declara procedencia y uso.

Cierre de la clase

Responde otra vez la pregunta guía sin mirar notas. Si tu respuesta no menciona evidencia, supuesto y límite, todavía describe el tema pero no lo domina. Continúa solo cuando otra persona pueda reproducir tu entregable.