Metas

O problema e as restrições

O Metas existe pra transformar os próprios números financeiros e operacionais de uma empresa-cliente numa nota única e comparável, mês a mês, em toda área do negócio e em toda empresa de um grupo. O cliente define uma meta e um peso pra cada indicador; uma pessoa ou um sistema reporta o que de fato aconteceu; a plataforma transforma isso numa nota que a gestão consegue comparar entre dezenas de áreas e, num cliente com várias empresas, entre toda subsidiária ao mesmo tempo.

A primeira restrição era que “pegar o número” significa uma coisa diferente pra cada cliente, porque nenhum cliente roda os mesmos sistemas nem concede o mesmo acesso. Alguns clientes têm uma API moderna e não têm problema em entregar uma chave. Alguns rodam software antigo, on-premises, sem API nenhuma, mas permitem uma conta de banco somente leitura atrás de uma VPN. Alguns, por razão regulatória ou de infraestrutura, não abrem porta nenhuma além do que uma pessoa já vê na própria tela. Uma plataforma que só soubesse chamar API simplesmente não conseguiria atender uma fatia relevante dos clientes pra quem esse produto existe.

A segunda restrição era que a organização de um cliente raramente cabe numa lista plana de “empresas”. Uma holding é dona de subsidiárias, uma subsidiária tem as próprias unidades de negócio, e cada nível precisa dos próprios indicadores, da própria meta e do próprio fechamento pro nível acima, enquanto uma única pessoa gerenciando o grupo inteiro precisa ver tudo isso de uma vez, sem trocar de login pra cada entidade.

A terceira restrição era que uma nota alimenta decisão real que a própria gestão do cliente toma sobre desempenho de time e, em alguns clientes, sobre a remuneração desse time, bem além de um número cosmético de dashboard. Errar uma fórmula sutilmente, ou deixar passar sem perceber um número velho ou manualmente maquiado, não só fica feio num gráfico, produz uma decisão real errada lá na frente.

A última restrição era o próprio acesso, no sentido mais literal. Chegar aos números reais de um cliente às vezes significa trabalho de software normal (chamar um endpoint), às vezes significa agir como engenheiro de rede (subir e manter um túnel VPN pra dentro de uma infraestrutura que ninguém do lado do cliente consegue explicar por completo), e às vezes significa agir como arqueólogo de dado (reconstituir o que as próprias telas de um sistema legado de fato mostram, quando o sistema em si não conta)

Arquitetura

A organização de um cliente vive como uma árvore autorreferente de linhas Company: uma holding, suas subsidiárias e as unidades de negócio delas são todas o mesmo tipo de registro, distinguidas só por um campo de categoria e um ponteiro de pai, então o mesmo schema atende um cliente com uma entidade legal só e um cliente com um grupo de quatro níveis, sem nenhum caso especial. Usuários se ligam a uma ou mais empresas por uma tabela de junção, e o acesso de um usuário comum fica estritamente restrito às empresas às quais ele de fato está ligado. Um papel fica inteiramente fora desse escopo: um administrador cross-company que vê a estrutura de todo cliente de uma vez, o papel que um consultor gerenciando várias relações de cliente de fato usa no dia a dia.

Debaixo de toda empresa fica um conjunto de Areas, e debaixo de toda área um conjunto de Indicators, cada um com um peso e uma de cinco fórmulas de pontuação (uma razão crescente simples, uma decrescente, uma variante de economia em despesas, e duas fórmulas de desvio pra estourar ou ficar abaixo de uma meta). O valor mensal de um indicador pode chegar de um de dois jeitos, rastreado por uma única flag is_manual: alguém digita no dashboard na mão, ou é escrito por qualquer mecanismo de integração que aquele cliente específico usa. Os dois caminhos alimentam exatamente o mesmo motor de fórmula lá na frente, então a plataforma nunca precisa saber nem se importar, na hora de pontuar, de onde um número veio originalmente.

Esse segundo caminho, a própria integração, é onde mora a maior parte do custo real de engenharia, e são três mecanismos separados, escolhidos por cliente conforme o que os próprios sistemas daquele cliente de fato permitem que um terceiro faça. Onde um cliente expõe uma API, a integração é uma chamada agendada direta. Onde um cliente permite acesso ao banco mas não tem API, a integração é uma consulta somente leitura rodando por um túnel VPN construído especificamente pra aquele cliente. Onde nenhum dos dois existe, e a própria equipe do cliente só vê número pelas telas do próprio software, a integração é RPA: operando aquele software do jeito que uma pessoa operaria, pra extrair os mesmos números que um operador humano teria digitado na mão de qualquer forma.

Assim que um valor chega, a própria nota de uma área segue uma regra deliberadamente direta: o resultado ponderado só conta alguma coisa se o resultado agregado da área bater 80% da meta; abaixo disso, a nota da área é exatamente zero, em vez de uma fração de um. Esse zero, ou essa nota, sobe pela árvore de empresas do mesmo jeito que a própria estrutura de empresa sobe, então o dashboard de uma holding reflete desempenho real de toda subsidiária debaixo dela, além do que por acaso foi digitado mais recentemente.

Uma meta perdida também não fica só num número seco. Quem é dono de um indicador que ficou abaixo anexa uma justificativa escrita pra aquele mês específico, e pode sustentar com evidência de apoio, um documento, uma captura de tela, uma planilha, enviada e ligada àquele mesmo indicador e mês. Nem a justificativa nem a evidência mudam a nota em si; a fórmula e o piso de 80% rodam exatamente igual dos dois jeitos. O que mudam é o que um revisor vê ao lado de um número vermelho: não só que uma meta foi perdida, mas a explicação específica e datada que o próprio dono da área deu pro motivo, registrada no mesmo mês em que aconteceu em vez de reconstituída de memória depois.