Skip to main content
Este documento puede incluir contenido traducido automáticamente.

Definición de los cost drivers

El tercer paso, una vez que hemos definido los centros empresariales y los hemos vinculado al plan de cuentas (o en general a las distintas entidades maestras disponibles), es analizar y definir las relaciones que existen entre los centros productivos/auxiliares y los centros generales, definiendo también el orden lógico de la aplicación en cascada. Para poder definir un Cost driver primero deberemos definir las Áreas de análisis (y por lo tanto también los Tipos de área) que necesitaremos en Controlling: será necesario crear obligatoriamente primero un Tipo y un área de Conjunto de reglas que contendrá todas las reglas estándar de distribución entre centros, y después también será obligatorio un Tipo y un área Resultados finales que será alimentada por los datos de cierre de periodo de los valores contables así como por las cantidades (horas hombre y máquina pero también cantidades producidas) de producción o de proyectos. También se podrá tener un área de Presupuesto, así como cualquier área alternativa que pueda ser útil para probar, por ejemplo, qué sucede si se aplican reglas de distribución diferentes de las oficiales del área 'Conjunto de reglas'.

Nota

La necesidad de definir los Cost driver está estrictamente ligada al uso de la Contabilidad de gestión en Controlling: es cierto que una versión simplificada de los Cost driver de distribuciones entre centros, a un solo nivel y solo con porcentaje fijo/anual y sin Áreas a vincular, está disponible también para las empresas sin el 'Controlling' activo, pero habilitar la versión completa permite obtener, con un mínimo esfuerzo adicional, el mismo tipo de resultado con el beneficio de dejar la puerta abierta a una progresiva extensión de la complejidad del modelo de análisis.

Un ejemplo sencillo puede aclarar mejor la lógica a seguir en la definición de los Cost driver. Supongamos que la empresa ha definido dos centros productivos "centro de torneado" y "centro de soldadura", con un centro auxiliar "centro de mantenimiento" y que está interesada en calcular la tarifa de coste por hora de los dos centros productivos considerando en el coste también una repartición del centro auxiliar. A su vez, el centro auxiliar tiene, como costes propios, los costes del personal asignado al propio centro, pero también, en parte proporcional, los costes generales de alquiler del pabellón donde están ubicados los propios centros. A su vez, las tarifas de los centros productivos se utilizan para valorizar los costes en los proyectos/órdenes de venta en producción.

En este escenario sencillo queda claro que el punto de partida será el coste del alquiler, que contabilizaremos al 100% en un centro virtual genérico al que luego vincularemos un cost driver (con ciclo de cálculo 1) para repartirlo entre el centro de torneado, centro de soldadura y centro de mantenimiento, quizás en función de los metros cuadrados asignados a cada centro (en la primera nota movimientos físicos). Después, el centro de mantenimiento, que habrá sido valorizado también con costes directos (como el coste del personal, que probablemente habremos recibido ya repartido desde la nómina para cada centro) pero también con estos costes indirectos del alquiler, se repartirá a su vez con un driver diferente (con ciclo de cálculo 2) sobre el centro de torneado y centro de soldadura, quizás de acuerdo con las horas máquina registradas en los reportes de producción (vinculando el centro a la máquina específica) del periodo. En este punto, para el centro de torneado o de soldadura, sobre los que se habrán cargado tanto costes directos como indirectos, se calculará la tarifa de coste del periodo (como total de costes dividido por total de horas de producción, por ejemplo) y este coste de periodo se aplicará, mediante otro driver con ciclo 3, a las horas del centro consumidas en cada proyecto/orden de venta trabajado en el periodo.

Cuanto mayor sea la complejidad de la estructura de centros que se quiera gestionar y el número de dimensiones de análisis, más delicada será la definición de los drivers apropiados y de sus ciclos de aplicación correspondientes.