Un control es una regla o comprobación que debe garantizar que un punto de datos sea correcto: una conciliación entre dos fuentes, una aprobación antes de que una cifra avance, una comprobación de un rango. Sobre el papel, el control está descrito en un documento de proceso o un informe de auditoría. Pero un control que nadie ejecuta no es un control. Es una frase en un documento.
En un grupo con una sola entidad, ese problema suele ser pequeño. Hay un departamento de finanzas, un controller, una persona que sabe quién mira qué. En un grupo con múltiples entidades, esa evidencia desaparece. Cada entidad puede tener su propio sistema contable, su propio controller local, su propia manera de registrar el consumo energético o los datos de personal. El control diseñado a nivel de grupo debe ejecutarse en cada entidad por separado, o en ninguna.
La propiedad de un control se divide en dos partes que no siempre recaen en la misma persona. Está quien ha diseñado o aprobado el control, a menudo a nivel de grupo, desde sostenibilidad o finanzas. Y está quien lo ejecuta de facto por entidad, a menudo un controller local, un gestor operativo, alguien que mantiene la hoja de cálculo.
Si esos dos roles no se asignan explícitamente, ocurre algo predecible: el grupo cree que el control existe porque ha sido diseñado, mientras que a nivel de entidad nadie se siente responsable de ejecutarlo. Esto es precisamente lo que describe qué hace usted cuando nadie es propietario en un grupo con múltiples entidades: la pregunta no es solo quién debería poseer el control, sino qué falla estructuralmente cuando esa pregunta queda sin respuesta.
Una manera práctica de asignar la propiedad no empieza por la entidad sino por el punto de datos. Para cada punto de datos que aparece en el informe —emisiones de CO2 por ubicación, número de fte, consumo de agua— existe una cadena: una definición, un proceso en el que se registra, y un control que debe demostrar que es correcto. Quién posee la definición de un punto de datos determina qué se mide exactamente y según qué norma. Quién posee el proceso subyacente determina quién registra y entrega el punto de datos. Y por encima está la pregunta quién posee el control: quién comprueba si el resultado de ese proceso es plausible y correcto, y quién lo firma.
En un grupo con múltiples entidades, esto significa que cada uno de esos tres roles puede variar por entidad, mientras que la definición y el control en sí mismos deberían idealmente ser iguales en todo el grupo. Un control que en una entidad es una conciliación manual y en otra una comprobación automatizada genera datos que no son comparables, aunque en ambas entidades se llame «control sobre el consumo energético».
Un control solo vale algo si sabe qué resultado es aceptable y cuál no. Esto exige dos cosas que a menudo permanecen implícitas. Primero, una respuesta a qué es un valor válido: un rango, una unidad, un formato dentro del cual una cifra introducida es aceptable. Sin esa norma, un control solo puede comprobar si se ha rellenado algo, no si es correcto. Segundo, una manera de detectar desviaciones antes de que lleguen al informe final: cómo configura usted una desviación de alerta trata sobre umbrales que indican cuándo una cifra merece la mirada de una persona, en lugar de que cada control sobre cada punto de datos reciba la misma atención.
Con múltiples entidades, conviene fijar estos dos elementos —valor válido y desviación de alerta— a nivel de grupo y ejecutarlos localmente. Esto evita que cada entidad aplique su propia interpretación de «normal».
La tentación en un grupo con múltiples entidades es adquirir un paquete de software que haga conciliaciones automáticamente y señale desviaciones. Ese paquete hace lo que debe hacer en el momento en que se ha respondido la pregunta subyacente: quién es responsable de qué, por punto de datos, por entidad. Sin esa respuesta, una herramienta no organiza nada: ejecuta una lógica de control sobre datos de los que nadie sabe exactamente quién vela por ellos.
La propiedad del control, por tanto, no es una pregunta que se responda después, en la implementación. Es la primera pregunta, y la que determina si todo lo que viene después se apoya sobre algo sólido.
En cuanto la propiedad del control queda fijada por entidad y por punto de datos, también surge una visión de qué parte de ese trabajo es repetible: conciliar cifras, comprobar rangos, señalar desviaciones. Una parte de esos pasos es lo bastante fija como para dejarla en manos de un ordenador; otra parte requiere un juicio que debe seguir en manos de una persona. El escáner de trabajo de FTE TO AI calcula, por tarea, qué parte de ese trabajo puede asumir la IA, de modo que quede claro dónde la automatización refuerza el control y dónde, en cambio, erosionaría la propiedad.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.