ETL para el análisis de costes y rentabilidad
Un modelo de rentabilidad nunca es mejor que los datos que se vierten en él. El ETL, la capa de extracción, transformación y carga, es el trabajo de sacar transacciones contables, datos maestros y drivers operativos de su ERP y darles la forma de los pools de recursos, actividades y drivers de coste sobre los que un motor TDABC o ABC puede realmente funcionar. Acierte en esa capa de entrada y todo el modelo se vuelve fiable, rápido de refrescar y defendible ante un consejo de administración.
En resumen. Un modelo de costes necesita tres tipos de entrada: dinero (saldos de la contabilidad general y de los centros de coste), estructura (el plan de cuentas, los centros de coste, los productos, los clientes y sus jerarquías) y comportamiento (los drivers operativos que dicen quién consumió qué). El ETL es cómo se pasa de un fichero SAF-T en bruto o de una exportación de SAP a un conjunto de datos limpio, mapeado y listo para los drivers. El paso de transformación es donde se concentran a la vez el valor y el riesgo: mapear los centros de coste a los pools de recursos, derivar las cantidades de actividad y reconciliar cada euro con el balance de sumas y saldos. Cost and Profitability construye estas tuberías en la herramienta que el cliente ya utiliza, ya sea Alteryx, Power Query, Talend, KNIME, dbt o SQL puro, y deposita el resultado en CostCtrl como motor de cálculo de costes. La herramienta es negociable; la disciplina de datos no lo es.
Lo que un modelo de rentabilidad necesita realmente de sus datos
Antes de que nadie hable de herramientas, conviene ser preciso sobre las entradas. Un modelo de cálculo de costes basado en actividades y orientado al tiempo necesita solo dos cosas en su núcleo, tal como lo formularon Kaplan y Anderson: el coste por unidad de tiempo de suministrar capacidad, y el tiempo que consume cada transacción, producto o cliente. Todo lo que hace el ETL está al servicio de producir esos dos números de forma limpia y repetible.
En la práctica, eso se resuelve en un pequeño número de dominios de datos. Cada uno tiene un sistema fuente natural y un modo de fallo distinto, que es justamente por lo que vale la pena separarlos a la entrada.
| Dominio de datos | Lo que aporta | Fuente típica | Grano que se busca |
|---|---|---|---|
| Saldos de contabilidad general y centros de coste | El dinero a asignar: salarios, amortización, ocupación, TI, servicios externos | Contabilidad general del ERP, fichero contable SAF-T | Cuenta x centro de coste x periodo |
| Datos maestros / jerarquías | La estructura: plan de cuentas, centros de coste, jerarquías de productos y clientes | Ficheros maestros del ERP, ficheros maestros SAF-T | Una fila por entidad, con claves de padre |
| Volúmenes de transacciones | Cantidades de actividad: pedidos, líneas, entregas, facturas, preparaciones, llamadas | Módulos de ventas, logística, servicio y CRM | Una fila por evento, con fecha y clave |
| Drivers operativos | Intensidad física: horas máquina, kilómetros, plantilla, metros cuadrados, SKU | MES, WMS, flota, RR. HH. y sistemas de inmuebles | Driver x objeto consumidor x periodo |
| Datos de RR. HH. y tiempo | Capacidad disponible y consumida: FTE, turnos, minutos prácticos | Nómina, planificación de turnos, partes de horas | Rol o equipo x periodo |
Observe que solo el primer dominio es estrictamente financiero. La señal de coste que separa un buen modelo de una hoja de cálculo vive en los tres últimos: sin volúmenes ni drivers puede repartir el coste, pero no puede explicarlo. Por eso un proyecto de ETL de costes es un ejercicio de finanzas y operaciones, no solo de finanzas.
Dónde viven los números: ERP, SAF-T y sistemas operativos
La mayor parte del dinero entra por el ERP. En SAP (ECC o S/4HANA) las extracciones útiles son los apuntes de centros de coste y órdenes internas de Controlling (tablas e informes en torno a CO-OM), más el balance de sumas y saldos de FI para la reconciliación. Oracle (E-Business Suite o Fusion) expone el detalle equivalente de contabilidad general y submayor, y Microsoft Dynamics 365 Finance ofrece asientos etiquetados por dimensiones que ya llevan buena parte de la estructura analítica que se necesita. En empresas de ingeniería, construcción y orientadas a proyectos, Primavera y sistemas de proyectos similares contienen los datos de mano de obra, equipos y avance que ningún libro mayor financiero captura.
Cuando una extracción directa del ERP no resulta práctica, el fichero SAF-T suele ser el punto de partida único más limpio. El estándar de la OCDE define cuatro secciones: una cabecera, los ficheros maestros (plan de cuentas, clientes, proveedores, códigos de impuestos, productos), los asientos de la contabilidad general y los documentos fuente como facturas y pagos. Al ser una exportación XML regulada y versionada, obligatoria en Portugal, Noruega, Polonia y una lista creciente de países, el SAF-T le da la contabilidad general y los datos maestros en un único paquete gobernado. Cost and Profitability construye con frecuencia un primer modelo directamente desde el SAF-T, lo que permite a un cliente empezar sin esperar a una integración completa del ERP.
Los sistemas operativos son más desordenados y más valiosos. Los sistemas de ejecución de fabricación, la gestión de almacenes, el transporte y la telemática de flotas, las plataformas de ticketing y de CRM contienen todas las cantidades de driver. Rara vez comparten claves con el ERP, que es precisamente el problema que la capa de transformación existe para resolver.
De los libros mayores en bruto a los pools de recursos y los drivers
Extraer y cargar son los verbos fáciles. La transformación es donde una tubería de costes se gana el sueldo, y se descompone en cuatro tareas que deben construirse y probarse en orden.
Limpiar y reconciliar. Eliminar duplicados, corregir tipos de datos, estandarizar fechas y monedas, y demostrar que la suma de lo que cargó es igual al balance de sumas y saldos hasta el céntimo. Si el coste extraído no cuadra con las cuentas auditadas, nada de lo que viene después es creíble. Esta compuerta de reconciliación es innegociable y debe automatizarse, no revisarse a ojo.
Mapear los centros de coste a los pools de recursos. Un pool de recursos agrupa costes que se comportan igual y que consume el mismo driver: un equipo de picking, una flota, un centro de llamadas, una celda CNC. Los centros de coste del ERP se diseñaron para el presupuesto y la responsabilidad, no para la causalidad, de modo que el mapeo rara vez es uno a uno. Algunos centros se reparten entre varios pools; algunos pools se nutren de varios centros. Esta tabla de mapeo, la correspondencia entre la estructura contable y el modelo de costes, es el artefacto más importante de toda la tubería y el que más merece control de versiones y aprobación formal.
Derivar los drivers de actividad. Convertir los eventos en bruto en las cantidades de driver que consume el modelo: contar líneas de pedido por cliente, sumar minutos máquina por producto, agregar entregas por ruta. En un modelo orientado al tiempo, aquí es también donde se alimentan las ecuaciones de tiempo, traduciendo las características de la transacción en minutos estimados para que el tiempo de procesamiento pueda flexibilizarse con la complejidad del mundo real en lugar de con una media plana.
Conformar claves y jerarquías. Dar a cada producto, cliente y objeto de coste una clave única y estable, y vincularla a las jerarquías sobre las que informa el negocio: coste de servir por canal, margen por segmento, contribución por mix de productos. Sin claves conformadas, un cliente que aparece tres veces con tres grafas mostrará tres márgenes engañosos.
La caja de herramientas ETL, elegida para el cliente y no para el consultor
No hay una única herramienta correcta, y cualquier consultor que insista en lo contrario está vendiendo su zona de confort en lugar de su resultado. Lo que importa es que la tubería sea transparente, repetible y mantenible por su equipo una vez terminado el encargo. Cost and Profitability es deliberadamente agnóstica en cuanto a herramientas y construirá dentro de aquella en la que su equipo de datos ya confíe.
| Herramienta | Modelo | Mejor encaje para el trabajo de costes | Aspectos a vigilar |
|---|---|---|---|
| Alteryx Designer | Visual, arrastrar y soltar | Mezcla rápida de ficheros de ERP y operativos por analistas financieros; potente con grandes conjuntos de datos locales | Coste de licencia; gobierno de muchos flujos de trabajo de escritorio |
| Power Query | En Excel / Power BI | Baja barrera cuando el cliente ya vive en Excel y Power BI; bueno para modelos más pequeños | Más débil con datos muy grandes y orquestación multifuente |
| KNIME | Visual, código abierto | Preparación basada en nodos, gratuita y flexible, con margen para crecer hacia la analítica y el aprendizaje automático | Navegación de nodos y uso de memoria en flujos grandes |
| Talend | ETL empresarial (Java) | Cientos de fuentes, trabajos programados de nivel empresarial que alimentan un almacén de datos | Construcción más pesada; requiere propiedad de ingeniería de datos |
| dbt | SQL, con control de versiones | El estándar para la transformación nativa de almacén sobre Snowflake, BigQuery, Redshift o Databricks; comprobable y auditable por diseño | Da por supuesto que los datos ya están cargados; es SQL primero, no una herramienta visual |
Una regla práctica útil: si los datos del cliente ya aterrizan en un almacén en la nube, dbt le da transformaciones comprobadas y con control de versiones que un auditor respetará. Si el trabajo es una mezcla de exportaciones y hojas de cálculo dirigida por analistas, Alteryx o Power Query llegan antes a un modelo. Si la integración abarca docenas de sistemas fuente de forma programada, Talend o una tubería empresarial comparable es la respuesta honesta. La lógica de costes es idéntica en todas ellas; solo cambia la sintaxis.
Errores frecuentes: basura a la entrada, exceso de granularidad, lógica de drivers rota
La mayoría de los modelos de costes que pierden a la sala lo hacen por razones de entrada, no por razones de método. Cuatro patrones de fallo se repiten con la frecuencia suficiente como para nombrarlos.
Basura a la entrada. Extracciones sin reconciliar, devengos mal contabilizados y centros de coste que cargan costes que pertenecen a otro sitio. Si la entrada no cuadra con el balance de sumas y saldos, el modelo hereda todos los errores y no añade ninguna de las culpas. Corrija esto en la compuerta de reconciliación, nunca después.
Exceso de granularidad. El instinto de modelar cada microactividad produce tuberías frágiles, lentas de refrescar e imposibles de explicar. Un modelo con 400 actividades suele ser menos preciso que uno con 40, porque las 360 adicionales se alimentan de datos adivinados. La granularidad debe detenerse donde los datos de driver dejan de ser fiables.
Lógica de drivers rota. Un driver que en realidad no causa el coste, un recuento de pedidos que hace de sustituto del esfuerzo de almacén cuando los artículos por pedido varían diez veces, redistribuye en silencio el beneficio entre clientes. Este es el error más peligroso porque el modelo sigue cuadrando; simplemente está equivocado de una forma que ninguna reconciliación detecta. La elección del driver merece el mismo escrutinio que el mapeo de costes.
Tuberías de un solo uso. Una construcción manual heroica que nadie puede refrescar el próximo trimestre es un informe, no un modelo. Si recargar los datos consume una semana de la memoria de un analista, la información se degrada antes de usarse. Automatice la extracción y la transformación para que un refresco mensual sea un botón, no un proyecto.
Alimentar un modelo limpio en CostCtrl
Cuando la capa de ETL se hace bien, el trabajo del motor de cálculo de costes se vuelve simple. CostCtrl consume entradas conformadas, pools de recursos con sus costes, objetos de coste con sus claves y cantidades de driver por periodo, y ejecuta encima el cálculo TDABC: tasas de coste de capacidad, consumo por ecuación de tiempo, informes de capacidad no utilizada y las vistas de rentabilidad y de curva de ballena sobre las que actúa la dirección. Una tubería limpia es lo que permite que ese motor se refresque mensualmente en lugar de anualmente, y lo que permite a un controller responder a una pregunta del consejo en minutos en lugar de en semanas.
La división del trabajo es deliberada. El ETL es dueño de la corrección y la repetibilidad de las entradas; CostCtrl es dueño del método de cálculo de costes y de las salidas. Como el motor se alimenta de datos conformados en lugar de hojas de cálculo a medida, la misma tubería se extiende de forma natural hacia la gestión basada en actividades y hacia los KPI de rentabilidad sin una reconstrucción. Cost and Profitability se posiciona como el socio de implementación a lo largo de toda esa cadena: construimos la tubería en sus herramientas, la probamos contra sus cuentas y le devolvemos algo que su equipo pueda operar sin nosotros. El cálculo de costes es riguroso; la fontanería es suya para quedarse con ella.
- ¿Qué datos necesito para construir un modelo de rentabilidad?
- Como mínimo: una contabilidad general o balance de sumas y saldos con detalle por centro de coste, los datos maestros que definen su plan de cuentas y sus jerarquías de productos y clientes, y las cantidades de driver operativo (líneas de pedido, horas máquina, entregas, FTE) que explican quién consumió qué. Los datos financieros por sí solos le permiten repartir el coste; los drivers son lo que le permite atribuirlo de forma causal.
- ¿Puedo arrancar un modelo de costes desde un fichero SAF-T?
- A menudo sí. El estándar SAF-T de la OCDE agrupa la contabilidad general, el plan de cuentas y los ficheros maestros de clientes, proveedores y productos en una sola exportación XML gobernada, por lo que con frecuencia es el punto de partida único más limpio. Aún necesitará datos de driver operativo de fuera del SAF-T para pasar del reparto de costes a una auténtica atribución basada en actividades.
- ¿Qué herramienta ETL es mejor para el análisis de costes y rentabilidad?
- La que su equipo pueda mantener. Alteryx y Power Query encajan con la mezcla de exportaciones dirigida por analistas; dbt es el estándar para transformaciones nativas de almacén con control de versiones; Talend encaja con la integración multifuente a escala empresarial; KNIME es una sólida opción de código abierto. La lógica de costes es idéntica en todas ellas, así que la elección es cuestión de su stack y sus competencias existentes, no del modelo.
- ¿Por qué mi modelo de costes no cuadra con el balance de sumas y saldos?
- Casi siempre es un problema de ETL: una extracción que se dejó un libro mayor, una moneda o un devengo tratado de forma inconsistente, o costes mapeados al pool equivocado. Por eso una compuerta de reconciliación dura, que demuestre que el coste cargado es igual al balance de sumas y saldos auditado hasta el céntimo, corresponde al inicio de cada tubería y debe automatizarse en lugar de comprobarse a mano.
- ¿Qué nivel de granularidad debe tener un modelo de costes?
- Tan granular como fiables sean sus datos de driver, y no más. Modelar cientos de microactividades sobre datos adivinados produce una tubería frágil que es menos precisa que una más ligera, no más. Deje de añadir detalle en el punto en que las cantidades de driver dejan de ser fiables, y dedique el esfuerzo ahorrado a la disciplina de refresco.
Kaplan, R. S. & Anderson, S. R., “Time-Driven Activity-Based Costing,” Harvard Business Review (2004) · OCDE, Guidance for the Standard Audit File - Tax (SAF-T), Version 2.0 · Documentación de producto de Alteryx, Talend, KNIME y dbt sobre preparación y transformación de datos · Literatura del IMA y de profesionales sobre los requisitos de datos del cálculo de costes basado en actividades