Pida a un modelo de lenguaje que redacte un modelo de costes TDABC y lo hará sin dudar: cost pools, drivers candidatos, una tasa de coste de capacidad, incluso una ecuación de tiempo con aspecto plausible. El resultado se lee como algo escrito por un analista competente. El problema no es que esté mal de forma evidente - un modelo con un número claramente erróneo se detecta enseguida. El problema es que está mal de la misma forma en que se equivoca un recién licenciado brillante sin experiencia en el sector: fluido, bien estructurado y apoyado, sin que nadie lo note, en supuestos que nunca se confirmaron en su empresa.
¿Puede un LLM redactar un modelo de costes, y dónde se equivoca?
Un LLM puede esbozar rápidamente la estructura de un modelo de costes: cost pools, drivers candidatos, una organización plausible sobre la que trabajar. Ese primer borrador es realmente útil. Se equivoca allí donde el modelo necesita hechos sobre su empresa que nunca estuvieron en sus datos de entrenamiento - su capacidad práctica real, los volúmenes reales de los drivers, qué costes son verdaderamente fijos a su escala y cuáles son solo fijos por escalón. Utilícelo para esbozar el esqueleto, nunca los números que van dentro.
En qué es realmente bueno
Dada la descripción de una empresa, un LLM produce una lista razonable de cost pools candidatos y un primer corte de drivers que rara vez resulta embarazoso. Conoce el vocabulario del custeo, ha leído una cantidad considerable de literatura contable y es rápido convirtiendo una descripción vaga en un punto de partida estructurado. Para un equipo que mira una hoja de cálculo en blanco, ese primer borrador puede ahorrar una tarde realmente útil. También es bueno explicando el método a alguien no especialista, y generando la documentación que nadie quiere escribir a mano.
Dónde se agotan los datos de entrenamiento
Un modelo de costes solo es correcto si sus números describen su operación, y ninguno de esos números estuvo en ningún conjunto de entrenamiento. Su capacidad práctica - los minutos que un equipo tiene realmente disponibles una vez contabilizadas las vacaciones, la formación y los tiempos muertos - existe solo en sus cuadrantes y en su ERP. Los volúmenes de sus drivers, el número de setups, líneas de pedido o tickets de soporte que su empresa produjo de verdad el último trimestre, existen solo en sus propios sistemas. Un LLM al que se le pida estimar cualquiera de estos valores producirá un número que suena específico y es, en realidad, una suposición disfrazada de hecho. No tiene forma de señalar la diferencia, porque los modelos de lenguaje están construidos para sonar seguros, no para señalar incertidumbre sobre un hecho que no pueden comprobar.
La trampa de la asignación de overhead, en particular
Pida a un modelo que sugiera un driver para el overhead de TI y a menudo propondrá el número de empleados, porque es el driver que más se menciona en los manuales y casos de estudio con los que fue entrenado. El número de empleados es cómodo y casi nunca es causal: dos departamentos con el mismo número de personas pueden consumir cantidades muy distintas de soporte de TI, según cuántos sistemas utilicen y cuán compleja sea su tarea. Un modelo ha leído miles de ejemplos en los que el número de empleados se usó como driver y muy pocos en los que alguien explicó por qué esa era la elección equivocada para esa empresa en concreto. Reproduce la respuesta popular, no la correcta para usted.
Un reparto de tareas que funciona
El reparto útil es estructura frente a hecho. Deje que el modelo esboce la lista de cost pools, proponga drivers candidatos sobre los que reaccionar, y escriba la primera explicación del método para quienes no estuvieron en la sala. No le deje inventar una cifra de capacidad, un volumen de driver o un reparto porcentual entre actividades - esos datos solo salen de su ERP, de los partes de horas, de los cuadrantes o de un estudio de tiempos genuino. Un modelo puede acelerar las partes del trabajo que consisten en organizar hechos ya conocidos. No puede fabricar los hechos en sí, por muy convincente que sea la frase que los contiene.
Un LLM puede escribir una frase muy convincente sobre un número que nunca ha visto. Ese es exactamente el modo de fallo que un modelo de costes no se puede permitir.
Qué comprobar antes de confiar en un modelo redactado por IA
Antes de que cualquier asignación redactada por IA se acerque a una decisión de precios o de consejo, siga cada número hasta su origen. Si un volumen de driver no puede señalarse hacia un informe o sistema concreto, es un supuesto y debe etiquetarse como tal, no publicarse como hecho. Pregunte si duplicar el driver duplicaría de forma plausible el coste - la prueba de causalidad sigue aplicándose, tanto si el driver lo propuso una persona como un modelo. Y pregunte si alguien en la empresa que realmente hace ese trabajo defendería el número delante de todos. Si la respuesta a cualquiera de estas preguntas es no, el borrador necesita a una persona con los datos reales antes de convertirse en una decisión.
El Profit Check es gratuito, tarda pocos minutos y está construido sobre sus datos reales, no sobre una suposición de IA. Le dice dónde está ganando y perdiendo dinero.
Lectura relacionada: dónde se equivocan los LLM en la asignación de overhead y pasar de hojas de cálculo a un modelo de costes real.