Um fornecedor pergunta, tarde ou temprano: o que o sistema deve ser capaz de fazer? A resposta não está no fornecedor, nem numa lista de funcionalidades que outras empresas também já marcaram. A resposta está no seu próprio processo: quais pontos de dados recolhe, quem os fornece, de onde provêm, e o que corre mal quando ninguém verifica.
O caminho habitual é: selecionar uma ferramenta, configurar a ferramenta, e só depois descobrir de onde deve vir cada dado. Essa ordem funciona ao contrário, porque uma ferramenta não tem opinião sobre o seu processo. Ela pede dados de entrada, e esses dados têm de vir de algum lugar. Se esse algum lugar — o registo de pontos de dados, a responsabilidade, as fontes — ainda não existe, a configuração da ferramenta torna-se uma busca que ninguém tinha planeado.
A outra ordem começa pelo processo. Primeiro, mapear quais pontos de dados são necessários, quem os fornece, de que sistema ou folha de cálculo provêm, e quais regras de qualidade lhes correspondem. Só depois fica claro quais requisitos uma ferramenta realmente deve cumprir. Não requisitos abstratos como "fácil de usar" ou "escalável", mas requisitos concretos como: deve integrar-se com este sistema-fonte específico, deve conseguir distinguir três responsáveis dentro de um único ponto de dados, deve sinalizar um desvio quando um valor sair de uma margem predefinida.
A ordem não é uma preferência de método; decorre daquilo que, funcionalmente, precede logicamente a ferramenta. Uma ferramenta só pode ter requisitos quando existe algo de onde esses requisitos possam ser derivados. Esse algo é o processo: o fluxo de dados da fonte ao relatório, com todos os passos manuais, transferências e pressupostos que o acompanham. Sem essa visão geral, uma organização define requisitos com base no que uma ferramenta consegue fazer, e não no que o processo realmente precisa. Isto parece uma diferença subtil, mas determina se a ferramenta acabará por se alinhar com a realidade ou por ficar ao lado dela.
Isto liga-se à questão de como escolher uma ferramenta sem se arrepender depois: o arrependimento surge muitas vezes não por uma ferramenta má, mas por uma ferramenta que teve de adivinhar requisitos porque ninguém os tinha registado.
Se a ferramenta vem primeiro e o processo depois, surgem dois tipos de custos. O primeiro é a reconfiguração direta: funcionalidades que não se encaixam, integrações que ainda têm de ser construídas, campos que ficam vazios porque ninguém sabe quem os deve preencher. O segundo custo é menos visível, mas mais pesado: a ferramenta passa a gerar relatórios com aspeto mais organizado, enquanto os números por detrás continuam sem poder ser rastreados até uma fonte ou um responsável. Esse risco está descrito mais detalhadamente na página sobre o que custa colocar uma ferramenta acima de um processo desorganizado: a ferramenta esconde o problema em vez de o resolver.
A questão de qual ordem acaba por ser mais económica depende de quantos pontos de dados, sistemas e responsáveis já existem, e quantos deles ainda não estão registados. Num processo pequeno com poucas fontes, o dano da ordem inversa é limitado. Num processo distribuído por vários departamentos, sistemas e folhas de cálculo, esse dano cresce a cada ponto de dados que não foi esclarecido antes de a ferramenta o exigir. Esta análise está desenvolvida na página comprar primeiro uma ferramenta ou organizar primeiro o processo: o que essa diferença custa.
Antes de uma ferramenta poder ter requisitos, tem de existir uma visão geral de quais pontos de dados são necessários para o relatório, de onde vem cada ponto de dados, quem é responsável pela sua exatidão, e qual regra determina se um valor é plausível. Essa visão geral não é um documento técnico nem uma ferramenta em si; é um registo que serve de base para qualquer passo seguinte, seja esse passo seguinte uma ferramenta, um processo manual, ou uma combinação de ambos.
A questão de quais requisitos funcionais daí resultam é, portanto, na verdade a questão: o que está registado nesse registo, e o que ainda falta? Enquanto essa questão não for respondida, qualquer requisito atribuído a uma ferramenta continua a ser uma aposta. Esta ligação entre os requisitos e o processo subjacente está mais desenvolvida na página sobre quais requisitos funcionais decorrem do seu próprio processo e o que uma ordem errada custa nisso.
Uma vez em ordem o registo de pontos de dados e a responsabilidade, a questão desloca-se do que uma ferramenta deve ser capaz de fazer para o que acontece com as pessoas que atualmente realizam este trabalho: recolher, verificar e transcrever números de folhas de cálculo e sistemas. Parte dessas tarefas é repetitiva e segue regras fixas, e é exatamente esse o tipo de trabalho de que uma parte pode ser assumida pela IA. A [análise de trabalho da FTE TO AI](https://ftetoai.nl) calcula, por tarefa, qual parte pode ser automatizada, tornando claro onde as pessoas continuam a ser necessárias e onde o trabalho pode ser transferido para um sistema que verifica e fornece de acordo com regras fixas.
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.