En cuanto los datos de sostenibilidad proceden de más de una unidad de negocio, el problema surge antes de que exista el registro. Cada unidad tiene sus propios sistemas, sus propias hojas de cálculo, sus propias definiciones de lo que significa un punto de datos. Un registro que no ordena eso terminará contando el mismo flujo tres veces o se le escapará por completo.
Un registro de puntos de datos no es una lista de temas de informe, sino un registro a nivel del punto de datos individual: las emisiones de alcance 2 del centro A, el número de FTE con contrato temporal en la unidad B, el consumo de agua del emplazamiento C. Por cada punto de datos debe estar registrado qué mide exactamente, en qué unidad, durante qué periodo y para qué entidad. Sin esos cuatro elementos, un punto de datos no es rastreable y, por tanto, no es verificable.
Además, el registro contiene por cada punto de datos la fuente: el sistema, el archivo o la persona de donde procede la cifra. Eso no siempre es tan sencillo como parece. Con múltiples unidades de negocio ocurre con regularidad que se rellena un punto de datos sin que nadie pueda señalar de dónde procede; qué hacer con un punto de datos sin fuente identificable es entonces una pregunta que el propio registro debe poder responder, no algo que se averigüe a posteriori.
La tentación con múltiples unidades de negocio es dejar que cada unidad entregue una lista por separado y fusionar después esas listas. Eso no funciona, porque las unidades raramente utilizan las mismas definiciones. Una unidad informa del consumo energético por centro, otra por línea de producción. Una cuenta a los trabajadores temporales dentro de la plantilla, otra no. Cuando esas listas se fusionan sin antes homogeneizar las definiciones, surgen duplicados que no son reconocibles como tales.
El orden que sí funciona: primero determinar qué puntos de datos importan realmente para la organización en su conjunto, independientemente de qué unidad los aporte. Esa es una pregunta sobre necesidad, no sobre disponibilidad — qué puntos de datos necesita realmente es una pregunta distinta de qué puntos de datos ya están en alguna hoja de cálculo. Solo después se determina, por cada punto de datos, qué unidad, qué sistema y qué persona es la fuente. Así surge un único registro con una única definición por punto de datos, en el que varias unidades aportan la entrada sin que el propio punto de datos se duplique.
La detección de duplicados sigue siendo necesaria después, porque incluso con buenas definiciones dos unidades pueden registrar sin saberlo el mismo hecho subyacente bajo un nombre distinto. Cómo se detecta eso — cómo reconocer un punto de datos duplicado entre unidades de negocio — es un control que se realiza sobre el propio registro, no sobre el informe que resulta de él más adelante.
Un error frecuente es asignar la propiedad a nivel de unidad: la unidad A es responsable de todos los datos de la unidad A. Eso funciona mientras las unidades se mantengan manejables, pero con múltiples unidades de negocio con procesos superpuestos — un departamento de compras compartido, un parque de vehículos centralizado — esa asignación pronto se vuelve confusa. Es mejor asignar la propiedad por punto de datos: un nombre que pueda explicar de dónde procede la cifra, cuál es la unidad y cuándo se actualizó por última vez. Ese nombre no tiene que ser quien introduce la cifra, pero sí quien conoce la fuente.
Cuántos de los puntos de datos existentes ya tienen una fuente identificable de este tipo suele ser la primera pregunta que surge en cuanto esto se revisa de forma sistemática. Cuántos de sus puntos de datos tienen una fuente es precisamente la pregunta que debe responderse por separado en cada unidad de negocio, porque la respuesta puede variar considerablemente entre unidades.
Con múltiples unidades de negocio, la tentación es esperar a que todas las unidades tengan el mismo nivel de profundidad antes de considerar terminado el registro. Ese no es un criterio realista. Un registro está terminado cuando, por cada punto de datos, queda claro quién es el propietario, cuál es la fuente y qué regla de calidad se aplica — incluso si esa respuesta es, para algunos puntos de datos, por el momento "fuente desconocida, acción pendiente en la unidad X". La incompletitud que es visible y está asignada es manejable; la incompletitud que permanece oculta detrás de una cifra rellenada, no lo es. Lo que implica exactamente ese criterio está desarrollado en cuándo está terminado un registro con múltiples unidades de negocio.
Cuánto tiempo cuesta elaborar un registro de este tipo depende del número de unidades de negocio, del número de sistemas por unidad y del grado en que las definiciones ya coinciden entre sí. En una organización con pocas unidades y fuentes manejables, eso supone considerablemente menos trabajo que en una organización con decenas de unidades en distintos sistemas ERP. Una indicación de dónde procede ese trabajo se encuentra en cuánto tiempo se tarda en poner en orden un tema.
La elaboración y el mantenimiento de un registro de puntos de datos con múltiples unidades de negocio consiste en una serie de tareas reconocibles: solicitar definiciones, averiguar fuentes, asignar propietarios, detectar duplicados. Parte de ese trabajo es suficientemente repetible como para automatizarlo; otra parte requiere una valoración que debe seguir recayendo en una persona. El escáner de trabajo de FTE TO AI calcula, por cada tarea, qué parte de ese trabajo puede asumir la IA, de modo que quede claro dónde siguen siendo necesarias las horas humanas y dónde no es así.
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.