Caso de datos / 05 · Evolución: modelo de importes V1 → V2

Evolucionar la analítica comercial de una sola divisa a varias

Un caso ficticio de evolución de arquitectura: llevar un modelo analítico de una sola divisa a varias sin romper el histórico, los objetivos ni los segmentos.

Escenario ficticio

Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.

01El resultado

Cada importe lleva su valor y divisa originales, el tipo y la fecha de tipo utilizados, y un importe de reporting calculado una sola vez en la plataforma de datos, reproducible para cualquier versión pasada.

La realidad

La primera versión informaba en una sola divisa. Las filiales que venden en otras amenazan ahora cada total, cada umbral y cada informe histórico.

Pregunta de arquitectura

¿Qué importe es el hecho, cuál es una vista, y se puede seguir reproduciendo el informe del año pasado?

Decisión clave

Guardar importe original, divisa, tipo, clase de tipo y fecha del tipo con cada importe convertido, y convertir una sola vez en la plataforma de datos, nunca en el CRM ni en un informe.

ContextoLa analítica comercial arrancó para sociedades que facturan solo en euros. Los importes se guardaban como un número sin más. Las nuevas filiales facturan en otras divisas, los objetivos se planifican de forma centralizada y los segmentos de rendimiento disparan acciones, así que un movimiento del tipo de cambio no debe cambiar un segmento por sí solo.

Sistemas y actoresERPServicio de tipos de cambioPlataforma de datosCRM

02La realidad · situación actual

Qué hacen hoy los datos.

  • Los importes se guardan sin divisa
  • Convertir en el momento del informe da totales distintos en informes distintos
  • Objetivos y datos reales se convertirían a tipos distintos
  • Un tipo de cambio corregido reescribiría en silencio las cifras del año pasado
  • Los umbrales de los segmentos presuponen una sola divisa

03Flujo objetivo

De dónde vienen los datos, adónde van… y cómo.

Cada traspaso se nombra con su modo. El modo sigue la tolerancia del negocio a la espera, a la inconsistencia y a la pérdida.

  • 01 · ERPImportes del ERP

    Importes de facturas y pedidos en la divisa de la transacción.

    Alimenta por Batch
  • 02 · Servicio de tipos de cambioTipos de cambio

    Tipos medios mensuales y de planificación, versionados.

    Alimenta por Batch
  1. 03 · Plataforma de datosConversión

    Una conversión por importe, con el tipo guardado a su lado.

    Traspasa por Batch
  2. 04 · Plataforma de datosImportes de reporting

    En la divisa de reporting, reproducibles por versión de tipo.

    Traspasa por Batch
  3. 05 · CRMSeñales en el CRM

    Rendimiento en la divisa de reporting, indicando la política de tipos.

04Contratos

Qué significa una fila o un mensaje.

Significado, granularidad, clave, frescura y responsable, por escrito antes de mapear nada.

Contrato

Importe convertido

Un importe en su divisa original y en la de reporting, con el tipo que los relaciona.

Granularidad
Línea de origen × versión de tipo
Clave
Clave de la línea de origen + versión de tipo
Frescura
Diaria
Responsable
Finanzas (política) · equipo de datos (cálculo)
Contrato

Tipo de cambio

Un tipo de una clase declarada para una fecha o un mes.

Granularidad
Par de divisas × clase de tipo × fecha
Clave
Par + clase + fecha + versión
Frescura
Mensual; correcciones versionadas
Responsable
Tesorería

05Dimensión clave · Evolución: modelo de importes V1 → V2

V1 → V2: de un número a un modelo de importes

La V1 guardaba un número. La V2 guarda un hecho y una vista de ese hecho, con todo lo necesario para reproducir la vista más adelante.

V1 · una sola divisa
  • ImporteUn número, implícitamente en euros
  • DivisaNo se guarda: se da por hecha
V2 · modelo de importes multidivisa
  • Importe originalEl hecho, tal como se facturó
  • Divisa originalNuevoTal como se facturó
  • Tipo de cambioNuevoEl tipo utilizado
  • Clase y fecha del tipoNuevoMedio mensual, de planificación o al contado, y para qué fecha
  • Versión del tipoNuevoPara que una corrección nunca reescriba el histórico
  • Importe de reportingNuevoDerivado, en la divisa de reporting
  • Divisa de reportingNuevoDeclarada, no supuesta
  1. ¿Divisa de la transacción o de reporting?

    Ambas: el original es el hecho; el importe de reporting es una vista derivada.

  2. ¿Qué fecha de tipo?

    Las facturas, a fecha de contabilización; los pedidos, a fecha de pedido.

  3. ¿Tipo diario, mensual o de planificación?

    Medio mensual para los datos reales; el tipo de planificación corporativo al comparar con objetivos.

  4. ¿Dónde se hace la conversión?

    En la plataforma de datos, una sola vez; nunca en el CRM ni en un informe.

  5. ¿Qué pasa cuando se corrige un tipo?

    Una nueva versión del tipo recalcula hacia delante; los informes publicados conservan la versión que usaron.

  6. ¿Qué divisa rige los umbrales y los segmentos?

    La de reporting, al tipo de planificación, para que un movimiento del tipo de cambio no pueda cambiar un segmento por sí solo.

El histórico de la V1 se migra como importes originales en euros con un tipo de identidad: sin reexpresar cifras, y los mismos informes se reproducen exactamente.

06Autoridad del dato

Quién puede crear, cambiar, leer o derivar cada concepto.

Resaltar
Autoridad sobre los datos por concepto de negocio: qué sistema puede crear, modificar, leer o derivar cada concepto
Concepto de negocioERPServicio de tipos de cambioPlataforma de datosCRM
Importe y divisa originalesEl hecho. Una conversión nunca lo sobrescribe.CrearSin autoridadLeerSin autoridad
Tipo de cambioLo publica tesorería. Una corrección es una versión nueva, no una edición.Sin autoridadCrearLeerSin autoridad
Importe de reportingSe deriva una vez, con la versión del tipo guardada a su lado.Sin autoridadSin autoridadDerivarLeer
Umbral de segmentoLo fija operaciones de ventas en la divisa de reporting, al tipo de planificación.Sin autoridadSin autoridadCrearModificarLeer

Aquí ningún sistema posee un registro completo. La autoridad reside en cada concepto y, a veces, cambia de manos cuando avanza el ciclo de vida.

07Fallo y recuperación

Diseñar el camino del fallo antes que el camino feliz.

  • Todavía no hay tipo para un mesFalta el tipo para el par y el mesMantener los importes como provisionales; nunca convertir a un tipo supuestoTesorería
  • Se corrige un tipo después del cierreNueva versión del tipoRecalcular con la nueva versión; los informes cerrados conservan la suyaFinanzas
  • Objetivo y dato real en divisas distintasControl de divisa al compararComparar solo en la divisa de reporting, al tipo de planificaciónOperaciones de ventas
  • Se vuelve a ejecutar el informe del año pasadoParámetro del informe: versión del tipoReproducir con la versión de tipo guardadaEquipo de la plataforma de datos

08Arquitecturas candidatas

Opciones creíbles, evaluadas frente a estas premisas.

Descartada

Convertir en la entrada, en el origen o en el CRM

Una única divisa de reporting para siempre

Coste: Se pierden los importes originales; cada cambio de política obliga a reexpresar cifras
Descartada

Guardar solo los importes de reporting

Una política de tipos única y estable

Coste: No se puede reconvertir, auditar ni cambiar de política
Elegida

Guardar original + tipo + reporting; convertir una vez, versionado

Varias divisas, objetivos y umbrales

Coste: Más columnas y disciplina en el versionado de tipos

09La segunda capa

Preguntas que cambian el diseño.

Importes

  1. ¿Divisa de la transacción o divisa de reporting?
  2. ¿Debe conservarse el importe original?
  3. ¿Dónde se hace la conversión?

Tipos

  1. ¿Qué fecha de tipo de cambio?
  2. ¿Tipo diario, mensual o de planificación corporativo?
  3. ¿Qué pasa cuando se corrigen los tipos?

Comparaciones

  1. ¿Cómo se convierten los objetivos?
  2. ¿Cómo se reproducen los informes históricos?
  3. ¿Qué divisa se usa para umbrales y segmentación?

10Decisiones y entregables

Qué produce el trabajo.

  1. 01Modelo de importes V2
  2. 02Política de tipos
  3. 03Ubicación de la conversión
  4. 04Versionado de tipos y regla de reproducibilidad
  5. 05Regla de conversión de objetivos
  6. 06Migración de la V1 sin reexpresar cifras