El orden habitual es: seleccionar una herramienta, configurarla y luego esperar que el proceso se adapte a ella. Eso no funciona en la práctica, porque una herramienta no trae consigo un proceso. Una herramienta trae campos, conexiones, paneles — pero no la pregunta de quién en su organización es responsable del consumo energético del edificio tres, o de si el gestor de instalaciones que aporta esa cifra sabe que terminará en el informe de alcance 2.
El orden correcto es el inverso: primero describir el proceso, y solo después elegir una herramienta en función de lo que ese proceso necesita. Suena como un desvío, pero es la ruta más corta, porque cada requisito funcional que plantea a una herramienta debe surgir de algún lugar dentro de su propia organización de datos. Sin ese punto de partida, seleccionará en función de las funciones que un proveedor considera importantes, no de las que resuelven su problema concreto.
Los costes del orden equivocado no son visibles de inmediato, porque una herramienta que no encaja funciona bien en un primer momento — para la parte del proceso que por casualidad coincide con lo que la herramienta espera. El resto se construye manualmente alrededor: un anexo en Excel aquí, un intercambio de correos allá, un empleado que sabe exactamente qué paso queda justo fuera del sistema. Eso funciona, hasta que ese empleado se marcha o el volumen de datos crece.
Lo que cuesta depende de cuántos puntos de datos quedan fuera de la herramienta y con qué frecuencia deben volver a recopilarse manualmente en cada ciclo de informes. Con un número reducido de puntos, ese desvío es aceptable. Con un número creciente — más ubicaciones, más categorías de alcance 3, más legislación que se añade — el desvío se convierte en la ruta principal, y usted paga de forma estructural por el desajuste entre la herramienta y el proceso. Es otra manera de decir lo mismo que también se expone en esta página: una herramienta colocada sobre un proceso desorganizado produce informes más pulcros sobre las mismas cifras poco confiables.
Un requisito funcional solo es un requisito si surge de algo concreto. "La herramienta debe poder mostrar la trazabilidad (lineage)" no es un requisito hasta que sabe que su controller tiene que averiguar manualmente tres veces al año de dónde procede una cifra. "La herramienta debe poder registrar la titularidad" no es un requisito hasta que ha visto que un punto de datos sin responsable no está en la lista de tareas de nadie.
Esto es precisamente por qué el registro de puntos de datos, la trazabilidad de origen a informe por cada punto de datos y la asignación de responsabilidad deben existir primero, independientemente de la herramienta que finalmente elija. En cuanto esas tres cosas estén sobre el papel — qué punto de datos, de dónde procede, quién lo valida — dispondrá de una lista de requisitos que no proviene de un proveedor, sino de su propia organización. Esa lista se utiliza para comparar herramientas, no para elegir una a ciegas. Cómo abordar esa comparación sin arrepentirse se describe en esta página sobre selección de herramientas.
El lugar donde residen los datos varía mucho según el sector, y eso también determina qué requisitos funcionales son relevantes. En una empresa de construcción, gran parte de los datos de sostenibilidad se encuentra en subcontratistas y en la propia obra, como se describe en esta página sobre fuentes de datos en la construcción; ahí, un requisito relacionado con múltiples fuentes externas por proyecto probablemente sea más importante que en otros sectores. En el sector de instalaciones, los datos suelen estar más dispersos entre partes de servicio y registros de materiales a nivel de proyecto, como puede leerse en esta página sobre el sector de instalaciones; ahí lo que más cuenta es si una herramienta puede consolidar puntos de entrada dispersos sin que alguien lo haga manualmente.
La pregunta general — organizar primero el proceso o comprar primero una herramienta — se desarrolla más a fondo en esta página, y la pregunta central de esta página, qué requisitos surgen exactamente de su propio proceso, se resume en esta página. Ambas páginas parten del mismo punto: el orden determina si un requisito es un requisito o simplemente una suposición.
El Data Readiness Scan registra el registro de puntos de datos, la trazabilidad y la titularidad antes de que se hable de ninguna herramienta. No es una herramienta de informes ni una solución de cuestionario — es el paso que determina qué debe poder hacer realmente una herramienta para su organización. Sin ese paso, compra funciones; con ese paso, compra una solución para un problema que puede señalar con precisión.
El escáner está en construcción. Quien desee que su proceso se mapee de esta manera antes de tomar una decisión sobre una herramienta, puede inscribirse en la lista de espera y será informado en cuanto el escáner esté disponible.
En cuanto exista el registro de puntos de datos y esté claro qué punto de datos proviene de qué fuente y quién es responsable de él, surge una segunda pregunta natural: qué parte del trabajo que lo rodea — la recopilación, el control y el traspaso de cifras — sigue siendo trabajo humano, y qué parte puede asumir un sistema sin que disminuya la fiabilidad. Esa pregunta la responde el escáner de trabajo de FTE TO AI, que calcula por tarea qué parte del trabajo puede asumir la IA. Es un escáner distinto del Data Readiness Scan, y una continuación lógica de este: primero saber cuáles son los datos y de dónde proceden, y solo después ver qué parte del trabajo manual que los rodea puede volverse innecesaria.
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.