Los datos del modelo de costes, campo a campo

Por qué la extracción decide el proyecto

Los modelos de costes rara vez fallan por la contabilidad. Fallan porque el diseño prometió un detalle que los sistemas de origen no podían alimentar, y nadie se dio cuenta hasta que la construcción estaba ya avanzada. Escribimos sobre esa brecha en del plano a un modelo que funciona.

Por eso empezamos con una petición de datos y no con un taller. Los ficheros suelen confirmar lo que todo el mundo creía. A veces muestran que las líneas de pedido están resumidas a nivel de factura, o que las paradas de entrega no quedan registradas contra el cliente, y el diseño del modelo cambia en la primera semana en lugar de en la sexta. Es un buen día, aunque no lo parezca.

Esta página es la especificación: qué pedimos, con qué detalle y por qué. Reenvíela a quien vaya a escribir la consulta. Si todavía está decidiendo si arranca, empiece por la guía para construir el primer modelo TDABC, que muestra qué van a alimentar estos ficheros.

Tres reglas que importan más que la lista de campos

1. A nivel de línea, nunca resumido. Una fila por línea de factura, línea de pedido, entrega, devolución o contacto. Una extracción resumida no vuelve a abrirse más tarde, y todas las diferencias interesantes entre dos clientes viven en el detalle que la media borró.
2. Claves que enlazan. Todos los ficheros de transacciones necesitan el código de cliente, el código de artículo y el número de documento, en el mismo formato que usan los datos maestros. Nombres en lugar de códigos cuestan más tiempo que todos los demás problemas de datos juntos.
3. El mismo periodo, en todas partes. Los ficheros de coste y los de transacciones tienen que cubrir los mismos meses. Un modelo que valora doce meses de trabajo con nueve meses de coste no cuadra con nada y se cae en una sola reunión.

Los cuatro ficheros que traen el coste

Los cinco ficheros que traen el trabajo

Tres ficheros para datos maestros y capacidad

La extracción no es papeleo previo al proyecto. Es la primera conversación honesta que el proyecto tiene.

Qué puede quedarse fuera

Las peticiones de datos se hinchan porque cada uno añade lo que quizá quiera más adelante. Cuatro cosas que dejamos fuera por rutina, y una que rechazamos.

Los salarios individuales. Coste por centro de coste y por puesto basta, y dejar los nombres fuera evita una conversación de protección de datos que no ayuda a nadie. Si un fichero de nómina llega con nombres, lo pedimos otra vez sin ellos.

El balance. Un modelo de rentabilidad trabaja sobre la base de coste operativo. El detalle del balance importa para la asignación de capital, que es otra pregunta, tratada en asignación de capital y ROIC.

Las versiones de presupuesto y previsión. Construya el modelo sobre datos reales primero. La comparación con el presupuesto es una capa de reporte que se añade después, y mezclar las dos pronto es como un proyecto de costes se convierte discretamente en un proyecto presupuestario.

Los datos perfectos. Campos que faltan, códigos inconsistentes y un conjunto de filas huérfanas son normales. Reconciliamos, cuantificamos lo que no enlaza y ponemos esa cifra en el informe en lugar de esconderla. Un modelo que dice cuánto ingreso no consiguió enlazar se gana la confianza. Un modelo que asegura haberlo enlazado todo, no.

Todo lo que necesitaría una revisión jurídica para enviarse. Si un campo es sensible y no sostiene nada, déjelo caer. Casi nada de esta lista son datos personales una vez agregada la nómina.

La prueba de reconciliación que lo decide todo

CSV o Excel vale. Parquet es mejor para ficheros de transacciones grandes. Lo que importa es que sean extracciones en bruto y no informes formateados: sin celdas combinadas, sin filas de subtotal, sin separador de miles dentro de los campos numéricos, una sola fila de cabecera, UTF-8, fechas en formato ISO.

El volumen rara vez es el obstáculo que la gente espera. El caso de estudio que publicamos sobre un operador logístico de Arabia Saudí se apoyó en 525.000 líneas de expedición, usadas íntegramente y sin muestreo. Si su fichero de líneas de factura tiene unos cientos de miles de filas, es un fichero corriente.

Sobre el histórico, doce meses es el objetivo de trabajo, porque cubre un ciclo estacional completo. Veinticuatro dejan ver si un patrón es estructural o solo un trimestre malo, y una vez escrita la consulta normalmente no cuesta nada más. Un trimestre basta para poner en pie un primer modelo que funcione.

Hay una prueba que decide si la extracción sirve, y conviene hacerla antes que nada. Sume los ficheros de coste del periodo y compare el total con el mayor para los recursos dentro del alcance. Sume las líneas de factura y compárelas con el ingreso reportado de esos mismos meses. Si alguno de los dos totales se desvía de forma material, la extracción está filtrada en algún punto y el modelo heredaría el filtro. Reconciliación primero, modelización después. Todo lo que hay en construir el primer modelo TDABC da por hecho que esta prueba ha pasado, y la fontanería que hay detrás está en ETL para el análisis de rentabilidad.

En un formato que puede reenviar

Copie el bloque de abajo en el correo que envía a quien lleva los sistemas. Es deliberadamente corto, porque una petición de cuatro páginas se lee una vez y se responde despacio.

En cuanto llegan los ficheros, la siguiente decisión es qué características de una transacción se convierten en términos de una ecuación de tiempo. De eso trata la biblioteca de inductores de coste, y la aritmética que hay detrás está en las ecuaciones de tiempo.

Preguntas justas.

¿Qué datos necesito para construir un modelo de coste de servir o de rentabilidad?

Doce extracciones. Cuatro traen el coste: las líneas de gasto del libro mayor por centro de coste y cuenta, la nómina y los equivalentes a tiempo completo, la amortización por clase de activo y la jerarquía de centros de coste. Cinco traen el trabajo: líneas de factura, líneas de pedido, entregas, devoluciones y abonos, y contactos de atención al cliente. Tres traen los datos maestros y la capacidad: el maestro de clientes, el maestro de artículos y el calendario laboral. Todo a nivel de línea, cubriendo los mismos meses y enlazable por código de cliente, de artículo y número de documento.

¿Cuánto histórico hace falta?

Doce meses es el objetivo de trabajo, porque cubren un ciclo estacional completo. Veinticuatro meses dejan ver si un patrón es estructural o solo un trimestre malo, y una vez escrita la consulta normalmente no cuesta nada extenderla. Un trimestre basta para poner en pie un primer modelo que funcione, pero no basta para revisar el precio de una cuenta, porque un único mes atípico puede cargar con toda la conclusión.

¿Los ficheros tienen que estar a nivel de línea?

Sí, y este es el requisito más importante de todos. Una extracción resumida no vuelve a abrirse más tarde, y todas las diferencias con sentido entre dos clientes viven en el detalle que el resumen borra: cuántas líneas tenía un pedido, cuántas paradas exigió una entrega, cuántos contactos generó una cuenta. Si la extracción a nivel de línea es realmente imposible, eso condiciona el diseño del modelo y debe saberse en la primera semana, no en la sexta.

¿Y si no tenemos los datos de entrega o de atención al cliente?

El modelo sigue funcionando, con una aproximación documentada en lugar del inductor que falta. El porte puede repartirse por peso o por zona, el coste de atención puede repartirse entre las cuentas, y ambos quedan marcados como repartidos y no como trazados. El resultado sigue siendo mucho más informativo que una media de toda la empresa, y los huecos se convierten en la hoja de ruta de lo que hay que empezar a registrar.

¿Son datos personales? ¿Necesitamos una revisión de protección de datos?

Casi nada lo es. Pedimos el coste de nómina agregado por centro de coste y por puesto, no por persona, y devolvemos cualquier fichero que llegue con nombres o salarios individuales. Los registros de clientes son registros de empresa. Si un campo es sensible y no sostiene el modelo, déjelo fuera.

¿En qué formato deben venir los ficheros?

Extracciones en bruto y no informes formateados. CSV o Parquet, UTF-8, fechas ISO, punto decimal, sin separador de miles dentro de los campos numéricos, una fila de cabecera, sin celdas combinadas y sin filas de subtotal. Después haga la prueba de reconciliación antes que nada: los ficheros de coste tienen que cuadrar con el mayor para los recursos dentro del alcance, y las líneas de factura tienen que cuadrar con el ingreso reportado de esos mismos meses.