Quando o sistema nasce no financeiro, e não na TI: como áreas de negócio tiram um sistema interno do papel

Neste artigo6 partes

1. Por que o sistema nasce fora da TI e o que isso tem de bom e de arriscado
2. Como a área de negócio conduz sem atropelar a TI
3. Um padrão que a Pocket viu de perto: do financeiro para a rede
4. O pedido da área que nunca é prioridade
5. Por onde começar: um processo, um dono, um critério de sucesso
6. Quando não vale a pena
7. Perguntas frequentes

Por que o sistema nasce fora da TI e o que isso tem de bom e de arriscado

Muito sistema interno nasce na área que sente a dor: o financeiro que fecha o mês numa planilha de vinte abas, a operação que acompanha pedidos por e-mail, o comercial que consolida metas copiando e colando. Isso tem um lado bom. Ninguém conhece o processo melhor do que quem o executa todos os dias, e projeto que nasce de uma dor concreta tende a resolver um problema real.

O lado arriscado aparece quando a área resolve sozinha. Não por falta de vontade da TI, que costuma ter uma lista de prioridades maior do que a equipe disponível, mas porque decisões de segurança, acesso e arquitetura acabam tomadas por quem não responde por elas.

Se a sua área está nesse ponto e precisa de um fornecedor, vale ler antes as perguntas para fazer a uma software house antes de assinar. Este texto trata do passo anterior: como a área de negócio conduz o projeto sem atropelar ninguém.

O problema não é o sistema nascer fora da TI. É nascer sem ela.

Compartilhar esta frase

O sinal de que a planilha chegou ao limite

A planilha é uma ferramenta excelente até deixar de ser. Os sinais costumam aparecer juntos: mais de uma pessoa editando o mesmo arquivo, cópias com nomes como "final_v3" circulando por e-mail, conferência manual todo fim de mês, informação que nem todo mundo deveria ver na mesma aba, relatório refeito por erro de fórmula.

Nenhum desses sinais, sozinho, justifica um sistema. Juntos, indicam que o processo cresceu mais do que a ferramenta.

O risco do sistema paralelo

Sistema paralelo, ou shadow IT, é a solução que roda dentro da empresa sem que a TI saiba, aprove ou consiga manter. Começa com boa intenção: uma ferramenta contratada no cartão de crédito da área, um formulário que grava dados numa conta pessoal, um sistema feito por um fornecedor que só a área conhece.

O problema aparece depois. Dados da empresa fora do controle de segurança, logins que não são desativados quando alguém sai, integração improvisada com o ERP, nenhum responsável quando o sistema para. Na primeira auditoria ou no primeiro incidente, a área descobre que comprou um risco junto com a solução.

Como a área de negócio conduz sem atropelar a TI

A divisão que funciona é esta: a área define o problema e o que é sucesso, a TI aprova o que envolve segurança, acesso, hospedagem e integração, e o fornecedor documenta tudo de forma que os dois lados consigam acompanhar. Cada um responde pelo que sabe.

O que a área precisa trazer

O processo descrito como ele acontece de verdade, não como está no manual. Quem participa, que dado entra, que dado sai, onde estão as exceções. E uma definição escrita de sucesso: o que precisa mudar para o projeto ter valido a pena. Menos retrabalho no fechamento, informação disponível para quem precisa sem pedido por e-mail, histórico confiável para auditoria.

A área também precisa de um dono. Uma pessoa que decide as dúvidas de regra de negócio e responde pelo sistema depois que ele estiver no ar.

O que a TI precisa aprovar

Como as pessoas fazem login, quem acessa o quê, onde o sistema roda, como ele conversa com os sistemas que já existem e como os dados são protegidos. São decisões que a TI tem obrigação de conhecer, mesmo quando não constrói o sistema.

A forma de levar o assunto também conta. Chegar à TI com uma solução já escolhida tende a gerar resistência, com razão. Chegar com o problema descrito, o critério de sucesso escrito e um pedido claro de participação nas decisões técnicas muda o tom da conversa. A TI deixa de ser quem precisa ser convencido e passa a ser quem ajuda a decidir.

Trazer a TI cedo costuma acelerar o projeto, não atrasar. Uma objeção de segurança na primeira semana custa uma conversa. A mesma objeção na véspera do lançamento custa o cronograma.

O que o fornecedor precisa documentar

Arquitetura, integrações, regras de acesso, onde ficam os dados, como fazer backup e restaurar, quem atende quando algo quebra. Documentação não é cortesia. É o que permite que a TI assuma ou acompanhe o sistema, e que a empresa não fique refém de quem o construiu.

Um padrão que a Pocket viu de perto: do financeiro para a rede

Um padrão que a Pocket Lab acompanha de perto começou assim. Numa grande empresa com rede de parceiros, a necessidade não veio do marketing nem da TI. Veio da área financeira, que precisava fazer informação chegar à rede de forma organizada e confiável.

O que começou como portal interno para resolver essa necessidade virou, com o tempo, uma plataforma de publicação de dados para toda a rede de parceiros. Não foi um plano desenhado de uma vez. Foi um sistema que provou valor num problema concreto e passou a resolver outros.

O padrão ensina três coisas. A primeira: projeto que nasce de uma dor específica, com dono claro, tende a sobreviver melhor do que projeto que nasce de uma ideia ampla. A segunda: um sistema interno que funciona costuma ser descoberto por outras áreas, e a arquitetura precisa aguentar esse crescimento. A terceira: a área de negócio pode liderar um projeto de software do começo ao fim, desde que as decisões técnicas tenham quem responda por elas.

O pedido da área que nunca é prioridade

Em grandes empresas, o pedido de uma área de negócio raramente é prioridade para os grandes fornecedores. Um portal para o financeiro, um sistema de acompanhamento para operações, uma ferramenta de consolidação para o comercial. São projetos importantes para quem os pede e pequenos demais para entrar no topo da lista de quem atende a conta inteira.

O resultado é conhecido: o pedido entra numa fila que não anda, e a área volta para a planilha.

Na Software House da Pocket Lab, esse tipo de pedido não entra em fila. Sem fila não quer dizer prazo menor, nem promessa de entrega. Quer dizer atenção dedicada desde a primeira conversa, com quem gerencia o projeto, e flexibilidade para ajustar o caminho quando a área aprende algo novo sobre o próprio processo. É exatamente o tipo de projeto em que a conversa com a TI precisa acontecer cedo, e em que a área precisa de alguém do outro lado que entenda tanto o negócio quanto a arquitetura.

Por onde começar: um processo, um dono, um critério de sucesso

O primeiro passo é pequeno: escolher um processo de dor concreta, nomear o dono e escrever o que significa funcionar. Não é o momento de desenhar o sistema que resolve tudo. É o momento de escolher o problema que mais custa hoje.

1. Um processo. O que gera mais retrabalho, mais erro ou mais pedido parado. Um só.
2. Um dono. A pessoa da área que decide as regras e responde pelo sistema depois do lançamento.
3. Um critério de sucesso. Escrito antes de começar, em linguagem de negócio, e conhecido pela TI e pelo fornecedor.

Com isso em mãos, a primeira reunião com a TI e com o fornecedor rende. Estas perguntas ajudam a conduzir.

Onde a IA entra num sistema interno, e onde não entra

A IA costuma ajudar nas tarefas repetitivas que cercam um sistema interno: classificar documentos recebidos, consolidar dados de fontes diferentes, conferir se um lançamento bate com outro. Regra de negócio, controle de acesso e decisão continuam com a área e com a TI.

É a mesma divisão que aplicamos em todo projeto, descrita em o que a IA faz e o que continua humano num projeto de software. Num sistema interno, ela vale em dobro, porque o dado é da empresa e o erro aparece no fechamento.

Quando não vale a pena

Não vale a pena construir um sistema interno quando o processo ainda muda toda semana, quando uma ferramenta pronta atende, quando ninguém aceita ser dono ou quando o problema é de organização, e não de software. Recomendar não construir também é parte do trabalho.

• O processo ainda muda toda semana. Sistema congela regra. Se a regra não parou de mudar, a planilha ainda é a ferramenta certa.
• Uma ferramenta pronta atende. Se um sistema de mercado resolve a maior parte do problema com configuração, construir sob medida tende a ser excesso.
• Ninguém aceita ser dono. Sistema sem dono vira sistema abandonado, com dado desatualizado e acesso esquecido.
• O problema é de organização. Se a dor vem de responsabilidade mal dividida entre pessoas, um sistema só torna o problema mais rápido.

Se o processo passou por esses filtros e a sua área está pronta para conduzir, o próximo passo é escolher bem quem vai construir. O roteiro está em como contratar uma software house para um projeto com IA. E, se quiser ver como trabalhamos com áreas de negócio e TI no mesmo projeto, conheça portais e sistemas internos na Software House da Pocket Lab.

Perguntas frequentes

Quando vale trocar uma planilha por um sistema sob medida?

Quando o processo é recorrente, depende de mais de uma pessoa, exige controle de acesso ou histórico e a planilha já gera retrabalho e erro.

Uma área de negócio pode contratar um sistema sem a TI?

Pode conduzir o problema, mas segurança, acesso, hospedagem e integração devem passar pela TI para evitar sistema paralelo.

O que um fornecedor precisa entregar além do código?

Documentação, acesso aos dados e ao código acordado, monitoramento e alguém que responda quando algo quebrar.