A ordem habitual é: selecionar uma ferramenta, configurar a ferramenta e depois esperar que o processo se adapte a ela. Isso não funciona na prática, porque uma ferramenta não traz um processo consigo. Uma ferramenta traz campos, ligações, painéis — mas não a resposta à pergunta de quem, na sua organização, é responsável pelo consumo energético do edifício três, ou se o gestor de instalações que fornece esse número sabe que ele vai acabar no relatório de âmbito 2.
A ordem correta é o inverso: primeiro descrever o processo, só depois escolher uma ferramenta com base no que esse processo exige. Isto pode parecer um desvio, mas é o caminho mais curto, porque cada requisito funcional que impõe a uma ferramenta tem de vir, de alguma forma, da sua própria organização de dados. Sem esse ponto de partida, seleciona com base em funcionalidades que um fornecedor considera importantes, não em funcionalidades que resolvem o seu problema concreto.
Os custos da ordem errada não são imediatamente visíveis, porque uma ferramenta que não se ajusta funciona bem à primeira vista — para a parte do processo que, por coincidência, corresponde ao que a ferramenta espera. O resto é construído manualmente à volta dela: um anexo em Excel aqui, uma troca de e-mails ali, um colaborador que sabe exatamente qual passo fica fora do sistema. Isso funciona, até esse colaborador sair ou o volume de dados crescer.
O que isso custa depende de quantos pontos de dados circulam fora da ferramenta e da frequência com que precisam de ser recolhidos manualmente em cada ciclo de relato. Com um número reduzido de pontos, isso é um desvio aceitável. Com um número crescente — mais localizações, mais categorias de âmbito 3, mais legislação a acrescentar-se — o desvio torna-se o caminho principal, e a organização paga estruturalmente pela desadequação entre a ferramenta e o processo. É outra forma de dizer o que também consta nesta página: uma ferramenta sobreposta a um processo desorganizado produz relatórios mais bonitos sobre os mesmos números pouco fiáveis.
Um requisito funcional só é um requisito se decorrer de algo concreto. "A ferramenta tem de conseguir mostrar a linhagem" não é um requisito até saber que o seu controller tem de descobrir manualmente, três vezes por ano, de onde vem um número. "A ferramenta tem de conseguir registar a titularidade" não é um requisito até ter constatado que um ponto de dados sem responsável não está na lista de ações de ninguém.
É precisamente por isso que o registo de pontos de dados, a linhagem source-to-report por ponto de dados e a atribuição de titularidade têm de existir primeiro, independentemente da ferramenta que venha a escolher. Assim que essas três coisas estiverem definidas — que ponto de dados, de onde vem, quem responde por ele — terá uma lista de requisitos que não vem de um fornecedor, mas da sua própria organização. Essa lista serve para comparar ferramentas, não para escolher uma às cegas. A forma de fazer essa comparação sem arrependimentos está descrita nesta página sobre seleção de ferramentas.
O local onde os dados residem varia muito por setor, e isso determina também quais os requisitos funcionais relevantes. Numa empresa de construção, uma grande parte dos dados de sustentabilidade está junto de subcontratados e no próprio estaleiro, como descrito nesta página sobre fontes de dados na construção; aí, um requisito relacionado com múltiplas fontes externas por projeto é provavelmente mais importante do que noutros setores. No setor das instalações, os dados estão frequentemente dispersos por ordens de serviço e registos de materiais a nível de projeto, como se pode ler nesta página sobre o setor das instalações; aí, o que conta sobretudo é se uma ferramenta consegue reunir pontos de entrada dispersos sem que alguém tenha de o fazer manualmente.
A questão geral — configurar primeiro o processo ou comprar primeiro uma ferramenta — é aprofundada nesta página, e a questão central desta página, quais os requisitos que resultam exatamente do seu próprio processo, está resumida nesta página. Ambas as páginas partem do mesmo ponto: a ordem determina se um requisito é um requisito, ou apenas um palpite.
O Data Readiness Scan regista o registo de pontos de dados, a linhagem e a titularidade antes de se falar de qualquer ferramenta. Não é uma ferramenta de relato nem uma solução de questionário — é o passo que determina o que uma ferramenta realmente precisa de ser capaz de fazer para a sua organização. Sem esse passo, compra funcionalidades; com esse passo, compra uma solução para um problema que consegue identificar.
O scan está em desenvolvimento. Quem quiser que o seu processo seja mapeado desta forma antes de tomar uma decisão sobre ferramentas pode inscrever-se na lista de espera e será informado assim que o scan estiver disponível.
Assim que o registo de pontos de dados estiver criado e for claro que ponto de dados vem de que fonte e quem é responsável por ele, surge uma segunda pergunta natural: que parte do trabalho em torno disso — recolher, verificar e transferir números — ainda é trabalho humano, e que parte pode um sistema assumir sem que a fiabilidade diminua. Essa pergunta é respondida pelo scan de trabalho da FTE TO AI, que calcula, por tarefa, que parte do trabalho pode ser assumida pela IA. É um scan diferente do Data Readiness Scan, e uma continuação lógica deste: primeiro saber quais são os dados e de onde vêm, só depois analisar que parte do trabalho manual em torno deles se pode tornar redundante.
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.