Poner Software de Datos Sobre un Proceso Roto Solo Produce Informes Más Bonitos, Mientras las Cifras Subyacentes Siguen Siendo Poco Fiables

Construya primero un registro de datapoints, y luego diseñe un proceso source-to-report por datapoint con definiciones consistentes entre unidades, en lugar de dejar que cada unidad desarrolle su propio enfoque de recogida de forma independiente. Las definiciones inconsistentes entre unidades suelen ser invisibles hasta que alguien intenta sumar los números a nivel de grupo, momento en el que el total resultante combina en silencio cifras que nunca medían realmente lo mismo.

Arregle el proceso, propiedad, definiciones, controles, antes de introducir cualquier herramienta; una herramienta sobre un proceso roto solo produce informes poco fiables más ordenados que parecen más creíbles de lo que realmente son. Las hojas de cálculo no son realmente el problema; la ausencia de propiedad clara, definiciones consistentes, y cualquier control sobre qué cuenta como cifra válida es el problema, y ninguna compra de software resuelve eso por sí sola.

Diseñe cada proceso de recogida con controles, agregación, normalización, cálculo y estandarización, para que cada cifra se remonte hasta una fuente en lugar de llegar al informe final como un número sin explicar que nadie puede defender si se le pregunta. Un proceso auditable se parece mucho a cómo finanzas ya gestiona los datos financieros, simplemente esa misma disciplina tradicionalmente no se ha aplicado a las cifras de sostenibilidad, precisamente la brecha que este enfoque cierra.

Documentar, por datapoint, de dónde procede, qué procesamiento sufre, y dónde acaba en el informe final, para que todo el recorrido desde la fuente en bruto hasta la cifra publicada sea explícito y verificable en lugar de algo que solo una persona de la organización entiende realmente. Sin este mapeo, una cifra en el informe final es en la práctica una caja negra que nadie puede verificar de forma independiente ni reconstruir si se le pregunta.

Asigne un RACI por datapoint y proceso, propiedad de definición en sostenibilidad, propiedad de proceso y control en finanzas, en lugar de dejar la propiedad implícita y asumir que alguien asumirá responsabilidad de forma natural. Los datos de sostenibilidad tienen una tendencia específica a acabar sin propietario, ya que caen entre departamentos que cada uno asume que el otro es responsable, precisamente lo que un RACI explícito está diseñado para evitar.

Determine qué datapoints exigen realmente sus temas materiales y el estándar de reporting, y registre qué ya existe frente a qué hay que construir, en lugar de intentar recoger cada datapoint concebible que el estándar permite teóricamente. Un registro acotado a lo genuinamente requerido, basado en sus temas materiales concretos, es una fracción del tamaño de uno construido intentando cubrir cada posible disclosure sin importar su relevancia.

Estandarice la definición en la fase de registro de datapoints, antes de diseñar ningún proceso de recogida, ya que intentar reconciliar definiciones inconsistentes después de que cada unidad haya construido ya su propio proceso es considerablemente más disruptivo. Lograr acuerdo sobre una definición compartida pronto, aunque lleve más tiempo al principio, evita el coste mucho mayor de desmontar procesos incompatibles después.

Defina cómo es un valor válido por datapoint y qué desviación dispara una alerta, la misma disciplina que ya tienen los datos financieros, extendida a cifras de sostenibilidad que históricamente se han recogido con mucho menos rigor. Un marco de control no necesita ser elaborado para ser eficaz; necesita especificar, para cada datapoint, cómo es un rango plausible y qué ocurre cuando una cifra cae fuera de él.

Asegúrese de que cada cifra tiene una fuente trazable y un propietario nombrado desde el primer día, reconstruir esto a posteriori es mucho más caro, en particular una vez que la persona que originalmente compiló una cifra ha cambiado de rol o dejado la organización por completo. Los proveedores de assurance buscan específicamente este tipo de trazabilidad, y su ausencia es una de las razones más comunes por las que un informe de sostenibilidad no logra una opinión de assurance limpia.

Arregle el proceso primero. Los requisitos funcionales de una herramienta deberían venir del proceso diseñado, no al revés, ya que elegir software antes de que exista el proceso significa adivinar requisitos en lugar de definirlos a partir de un flujo de trabajo real y testado. Las herramientas elegidas así frecuentemente resultan carecer de capacidades que el proceso realmente necesita, o incluir una larga lista de funciones que el proceso nunca usa.

Defina los requisitos funcionales basándose en su proceso de recogida diseñado, y luego haga la selección, nunca antes de que exista el proceso, porque una demo de proveedor es mucho más persuasiva que una evaluación clara de lo que su recogida de datos concreta realmente necesita. Los requisitos definidos a partir de un proceso real suelen ser más específicos y útiles durante la evaluación de proveedores que una checklist genérica de funciones copiada de un informe sectorial.

La propiedad de la definición corresponde a sostenibilidad; la propiedad del proceso y el control corresponde a finanzas, que ya tiene los sistemas y la disciplina para ello, ya que finanzas ha pasado décadas construyendo el rigor que el reporting de sostenibilidad ahora necesita igualar. Esta división evita el error común de que sostenibilidad sea propietaria tanto de las definiciones como del proceso, sin los sistemas que finanzas ya tiene para ejecutar ese proceso de forma fiable a escala.

Use el mismo registro de datapoints y diseño de proceso como plantilla, adaptado por unidad pero nunca redefinido por unidad, para que la agregación a nivel de grupo siga teniendo sentido en lugar de convertirse en un mosaico de enfoques reinventados localmente. La adaptación al contexto local está bien y a menudo es necesaria; redefinir el datapoint subyacente o su definición a nivel local es lo que rompe la comparabilidad a nivel de grupo.

Semanas para un solo tema; un despliegue completo a nivel de grupo con gobierno se mide en trimestres, impulsado principalmente por el número de unidades y partes implicadas más que por la complejidad técnica de los propios datos. El plazo escala mucho más con la coordinación organizativa que con la dificultad de la medición subyacente, por lo que un piloto de un solo tema puede avanzar mucho más rápido que un despliegue completo.

Mantenga el source-to-report mapping y el marco de control como la propia documentación, está construido para estar listo para auditoría por diseño, en lugar de tratar la documentación como una tarea separada que completar cuando el proceso ya está en marcha. Añadir documentación a posteriori sobre un proceso ya existente suele ser tanto más lento como menos preciso que construir la documentación como subproducto natural de diseñar bien el proceso desde el principio.