Servicios compartidos: repartidos por headcount, pagados por la unidad equivocada
TI, recursos humanos, finanzas y compras se cobran a las unidades de negocio con claves gruesas como cantidad de empleados o ventas. Así, la unidad liviana que apenas usa el servicio subsidia a la que lo usa intensivamente, el chargeback parece arbitrario y el centro de servicios no recibe ninguna señal para volverse más eficiente. Costeamos los servicios compartidos por actividad y transacción con TDABC, para que cada unidad pague por lo que realmente consume y el cobro interno sea algo que ambos lados pueden defender.
El chargeback basado en actividades es el método de cobrar a cada unidad de negocio por lo que realmente consume del centro de servicios compartidos, tickets, transacciones, nóminas procesadas, horas de soporte, con cada actividad costeada por TDABC. El costo total no cambia; quien paga pasa a coincidir con quien lo causa. El reparto deja de ser un impuesto interno y se convierte en un precio interno, que las unidades pueden cuestionar línea por línea y que el centro puede usar para compararse y mejorar.
Una clave gruesa esparce el costo, no lo asigna
En América Latina, los centros de servicios compartidos se consolidaron en los grandes grupos y en las multinacionales con operaciones regionales como respuesta natural a la escala: es más barato operar TI, recursos humanos, finanzas y compras una vez para todos que varias veces en paralelo. El problema aparece a la hora de repartir la cuenta. Dividir el costo por cantidad de empleados, ventas o un porcentaje fijo supone que cada unidad consume el servicio en proporción a su tamaño, lo que casi nunca se cumple. Una unidad registra unos tres mil tickets al año; otra registra unas decenas. Las dos reciben la misma factura.
El resultado lo conoce cualquier controller de grupo: el usuario liviano subsidia en silencio al usuario intensivo, el reparto parece un impuesto y no un precio, y finanzas pasa todo el ciclo presupuestario defendiendo un número en el que nadie cree. Peor aún: el centro de servicios no ve ninguna relación entre lo que hace y lo que cobra, así que no tiene razones para volverse más eficiente.
La distorsión no es menor. En servicios compartidos, el costo de servir a una unidad de negocio puede ser dos o tres veces el de otra del mismo tamaño, porque el volumen de facturas, la complejidad de los tickets, las excepciones y la mezcla de servicios caen de forma despareja. La clave de headcount esconde exactamente esa desigualdad.
Mismo headcount, uso opuesto
- Cobradas igual: dos unidades de negocio tienen la misma cantidad de empleados, así que el servicio compartido de TI les cobra el mismo monto. En el reporte de costos parecen consumidoras idénticas del soporte central.
- Consumen muy distinto: la unidad A es estable y autosuficiente, con pocos tickets y ningún sistema a medida. La unidad B opera tres aplicaciones customizadas, genera el triple de tickets y concentra la mayor parte del trabajo de integración.
- El costo real las separa: costee la actividad que cada una consume y la unidad A está pagando muy por encima de su costo real, mientras la unidad B paga muy por debajo, financiada por todas las demás.
- Es un ajuste de precios internos: cobre por actividad, publique las tasas unitarias y deje que las unidades vean las transacciones detrás de la factura. El costo no se mueve; quién lo paga finalmente coincide con quién lo causa.
La misma factura en el reporte, una unidad financia a la otra
Cifras ilustrativas para mostrar el mecanismo. Las unidades A y B tienen 200 empleados cada una. Por la clave de headcount, cada una recibe un cargo de US$ 480 mil al año del centro de TI. Pero la unidad A genera unos tres mil tickets al año y no tiene sistemas a medida, mientras la unidad B genera más de nueve mil tickets y mantiene tres aplicaciones customizadas.
Costeadas por TDABC, las actividades que consume la unidad A suman US$ 280 mil, y las de la unidad B suman US$ 680 mil. Es decir: la unidad A paga US$ 200 mil más de lo que causa, y la unidad B paga US$ 200 mil menos, financiada por la otra. Con la clave de headcount, las dos eran líneas idénticas en el reporte. Por consumo, una paga casi el doble de lo que debería y la otra, apenas el 70 por ciento de su costo real. Solo la vista por actividad hace visible el subsidio, y discutible.
El costo cae en la actividad, después en la unidad
- Mapear el catálogo de servicios: las actividades que el centro realmente ejecuta, tickets, contrataciones, nóminas procesadas, órdenes de compra, soporte de aplicaciones, el trabajo que el presupuesto paga.
- Costear cada actividad por unidad de trabajo: el TDABC define un costo por ticket, por nómina, por hora de soporte a partir de la capacidad práctica, así la capacidad ociosa queda visible en lugar de enterrada en el reparto.
- Atribuir a la unidad que consume: cada unidad de negocio carga con el costo de lo que efectivamente consumió, transacción por transacción, y no con una fracción del total según su tamaño.
- Publicar las tasas: tasas unitarias y una factura clara convierten el reparto en un precio interno, contra el cual unidades y centro pueden planificar y mejorar.
Un chargeback que se sostiene en la sala de reuniones
Cuando el cobro interno refleja el consumo, la conversación de presupuesto deja de ser sobre justicia y pasa a ser sobre demanda. Los usuarios intensivos ganan una razón para consumir de forma más inteligente, los usuarios livianos dejan de subsidiarlos, y el centro de servicios puede comparar sus tasas unitarias contra el mercado y justificar su plantilla con un número, no con una historia.
El modelo se construye sobre sus datos y se transfiere a su equipo, así el chargeback se mantiene actualizado a medida que la demanda cambia. No es un estudio puntual: es un mecanismo de gestión que el área de control mantiene sola después de que nos vamos.
Cuando los robots procesan las transacciones, el chargeback tiene que seguirlos
La IA y la automatización están entrando justo en el trabajo que un centro de servicios compartidos cobra: la RPA procesa las transacciones de alto volumen, los agentes de IA absorben los tickets de primer nivel y la captura inteligente recorta el tiempo de toque de una factura. Eso baja el costo por actividad y desplaza la mezcla hacia excepciones y criterio, lo que cambia la cara de un chargeback justo.
Nada de eso puede evaluarse sin una línea base de costo por actividad. Los centros que ganan son los que ya conocen su costo por transacción antes de que la automatización lo reescriba.
Preguntas frecuentes
¿Por qué repartir los servicios compartidos por headcount es un problema?
Headcount, ventas o un porcentaje fijo suponen que cada unidad consume el servicio en proporción a su tamaño, lo que rara vez es cierto. La unidad liviana que apenas usa el servicio termina subsidiando a la intensiva, el reparto parece arbitrario y el centro no recibe ninguna señal sobre qué impulsa realmente su costo.
¿Qué es el chargeback basado en actividades?
Es cobrar el servicio compartido por lo que cada unidad consume de verdad: tickets, transacciones, proyectos, horas de soporte, costeados por actividad con TDABC. Cada unidad paga por su uso real, así el cobro es transparente y puede cuestionarse línea por línea.
¿Esto no va a crear peleas internas?
Normalmente las termina. Las peleas nacen de repartos que nadie puede explicar. Cuando una unidad puede ver las transacciones detrás de su factura, la conversación deja de ser sobre si el cargo es justo y pasa a ser sobre cómo consumir el servicio de manera más eficiente.
¿Aplica más allá de TI?
Sí. El mismo enfoque funciona para cualquier función compartida: recursos humanos, finanzas, compras, facilities y legal. Dondequiera que un costo central se divida entre unidades con una clave gruesa, el costeo por actividad hace la división defendible.
Vea también
El Profit Check toma cinco minutos y no pide envío de datos. Señala dónde sus cobros internos probablemente están fuera de línea con el consumo, y cuánto vale ponerlos en orden. Si prefiere hablar directamente, escríbanos por la página de contacto y agendamos 30 minutos con un consultor.