Imagina que amanhã recebes uma notícia inesperada: o fornecedor do software mais importante da tua empresa fechou, foi comprado por um concorrente ou decidiu terminar o produto.
A partir desse momento:
- não consegues entrar na plataforma;
- o apoio ao cliente deixou de responder;
- as integrações começam a falhar;
- os dados continuam presos no sistema;
- a renovação anual aproxima-se, mas o preço duplicou;
- ninguém sabe ao certo como exportar tudo;
- e a operação fica dependente de uma decisão que já não controlas.
A pergunta não é se o fornecedor parece sólido hoje. A pergunta é outra:
Se o fornecedor desaparecer amanhã, quanto tempo consegues continuar a operar?
Este exercício revela um risco que muitas empresas só identificam quando já estão sob pressão: a dependência tecnológica.
Começa por identificar o que é realmente crítico
Nem todos os softwares têm o mesmo impacto. Se uma ferramenta de edição de imagens ficar indisponível durante um dia, podes encontrar uma alternativa. Se o sistema de faturação, o CRM ou a plataforma onde estão os pedidos dos clientes parar, o problema é muito maior.
Classifica cada sistema em três níveis.
Nível 1: crítico
A indisponibilidade interrompe directamente a operação, impede vendas, pagamentos, entregas ou obrigações legais.
Exemplos:
- faturação e contabilidade;
- gestão de encomendas;
- CRM com oportunidades comerciais;
- plataforma de reservas;
- sistema de produção;
- alojamento do website ou da aplicação principal.
Para estes sistemas, define quanto tempo podes estar parado e quantos dados podes perder. Não aceites respostas vagas como “temos backups” ou “o fornecedor é grande”.
Nível 2: importante
A empresa consegue continuar durante algum tempo, mas com atrasos, trabalho manual ou perda de produtividade.
Exemplos:
- ferramentas de automação de marketing;
- gestão de projectos;
- plataformas de propostas comerciais;
- sistemas de análise;
- ferramentas internas de comunicação.
Aqui, deves ter um procedimento alternativo e uma forma de recuperar os dados.
Nível 3: conveniente
A ferramenta melhora o trabalho, mas não impede a continuidade da actividade.
Exemplos:
- ferramentas de design;
- aplicações de produtividade individual;
- serviços de apoio não essenciais;
- plataformas usadas apenas por uma pessoa ou num processo secundário.
Mesmo nestes casos, evita guardar informação única que não consigas recuperar.
A classificação serve para definir prioridades. Não precisas de desenhar um plano de recuperação complexo para todas as ferramentas. Precisas, isso sim, de um plano sério para as que podem parar o negócio.
O teste dos cinco minutos
Escolhe agora o teu sistema mais crítico e responde, sem pedir ajuda ao fornecedor, a estas perguntas:
- Quem tem acesso administrativo?
- Como exportas todos os dados?
- Em que formato recebes essa exportação?
- Onde está a documentação das integrações e configurações?
- Qual é a alternativa se o sistema ficar indisponível durante 30 dias?
Se demorares mais de cinco minutos a perceber onde encontrar a resposta, já tens um sinal de risco.
O problema não está apenas na tecnologia. Está na ausência de preparação.
Ter exportação não é o mesmo que conseguir operar
Muitos fornecedores anunciam que permitem exportar os dados. Isso parece suficiente, mas raramente é.
Uma exportação pode incluir apenas uma parte da informação:
- contactos, mas não o histórico de interacções;
- facturas, mas não as configurações fiscais;
- produtos, mas não as relações com encomendas;
- ficheiros, mas não os nomes, versões ou permissões;
- registos, mas não os anexos;
- dados brutos, mas não a lógica que os transforma em processos úteis.
Um ficheiro CSV com milhares de linhas não é uma operação restaurada. É apenas matéria-prima.
Quando auditares a exportação, verifica se consegues recuperar:
- dados principais;
- históricos;
- anexos;
- relações entre entidades;
- utilizadores e permissões;
- configurações relevantes;
- modelos e templates;
- regras de automação;
- integrações;
- logs necessários para investigar problemas.
Confirma também se os formatos são abertos e utilizáveis sem o software original. CSV, JSON, XML e APIs documentadas oferecem mais liberdade do que formatos proprietários que só o fornecedor consegue interpretar.
Ter backup não é o mesmo que conseguir restaurar
“Está tudo salvaguardado” é uma frase perigosa quando nunca foi testada.
Um backup só é útil se:
- existe uma cópia acessível;
- a cópia não está no mesmo ambiente comprometido;
- os dados estão completos;
- as credenciais continuam válidas;
- o formato pode ser lido;
- o processo de restauro está documentado;
- alguém já fez o teste.
Faz uma restauração de teste num ambiente separado. Não precisas de esperar por uma catástrofe. Escolhe uma amostra real e confirma se consegues recuperar o processo completo.
Por exemplo:
- importar uma lista de clientes;
- recuperar uma encomenda;
- consultar o histórico de um contacto;
- reconstruir uma factura;
- repor uma configuração;
- reactivar uma integração;
- validar permissões de acesso.
O teste deve responder a uma questão simples: se perderes acesso ao fornecedor, consegues reconstruir uma operação funcional ou apenas recuperar ficheiros?
Define também dois valores:
- RPO: quantos dados aceitas perder;
- RTO: quanto tempo aceitas demorar a voltar a operar.
Se o teu RPO for de 24 horas, uma exportação mensal não chega. Se o teu RTO for de oito horas, uma migração que demora três semanas não é um plano de continuidade.
Os acessos administrativos não podem estar numa só pessoa
O fornecedor pode desaparecer. Mas também pode ficar inacessível a pessoa que geria a conta.
Audita:
- contas de administrador;
- endereços de email associados;
- autenticação multifactor;
- códigos de recuperação;
- chaves de API;
- domínios;
- contas de alojamento;
- repositórios de código;
- certificados;
- serviços de pagamento;
- contas de publicidade;
- integrações com terceiros.
Evita que tudo dependa do email pessoal de um colaborador, de uma agência ou de um técnico externo.
Deves ter pelo menos duas pessoas autorizadas, com acessos documentados e revistos periodicamente. Guarda os códigos de recuperação num local seguro e garante que a empresa controla os domínios, os dados e as contas principais.
A regra é simples: quem paga pelo sistema deve conseguir recuperar o controlo sobre o sistema.
Documenta o que normalmente fica escondido
A dependência aumenta quando o conhecimento está apenas na cabeça de alguém ou disperso em mensagens antigas.
Para cada fornecedor crítico, documenta:
- o que o sistema faz;
- que processos dependem dele;
- quem utiliza cada área;
- quais são as integrações;
- que dados entram e saem;
- quais são as configurações especiais;
- que tarefas são manuais;
- que erros aparecem com frequência;
- como contactar o suporte;
- como exportar os dados;
- como iniciar uma migração.
Não precisas de escrever um manual com 200 páginas. Precisas de uma documentação suficientemente clara para outra pessoa conseguir executar as tarefas principais.
Testa-a com alguém que não tenha configurado o sistema. Se essa pessoa não conseguir seguir o processo, a documentação ainda não está pronta.
Constrói uma arquitectura modular
A melhor defesa contra a dependência não é evitar todos os fornecedores. É impedir que um único fornecedor controle tudo.
Uma arquitectura modular separa:
- dados;
- lógica de negócio;
- interface;
- autenticação;
- pagamentos;
- automações;
- alojamento;
- análise;
- comunicação com clientes.
Assim, substituir um componente não obriga a reconstruir toda a empresa.
Por exemplo, o teu CRM pode comunicar com a faturação através de uma camada de integração documentada. O website pode utilizar uma base de dados que consegues exportar. As automações podem estar descritas fora da plataforma. Os ficheiros podem ter uma cópia independente.
Isto não significa complicar a arquitectura sem necessidade. Significa evitar que a lógica essencial do negócio fique escondida dentro de uma plataforma que não controlas.
Antes de escolher uma ferramenta, pergunta:
- consigo substituir este componente sem parar tudo?
- os dados ficam num formato utilizável?
- existe uma API documentada?
- posso manter a lógica de negócio fora da plataforma?
- consigo testar uma alternativa?
- o contrato prevê apoio à saída?
A arquitectura modular deve ser uma decisão empresarial, não apenas uma preocupação técnica.
O contrato também faz parte da continuidade
A prevenção começa antes da assinatura.
Analisa:
- prazos de aviso;
- renovação automática;
- aumentos de preço;
- custos de exportação;
- apoio durante a migração;
- prazo de retenção dos dados após o cancelamento;
- responsabilidades em caso de encerramento;
- acesso a backups;
- localização dos dados;
- subcontratantes;
- níveis de serviço;
- condições de recuperação.
Não assumes que “os dados são teus” significa que os consegues retirar facilmente. Pergunta exactamente como, em que formato, com que prazo e a que custo.
Uma cláusula genérica de portabilidade vale pouco se ninguém definiu o processo.
Faz uma auditoria de dependência
Usa esta checklist para cada fornecedor crítico:
Dados
- Sei exactamente que dados estão no sistema?
- Inclui históricos, anexos e relações?
- Consigo exportá-los sem intervenção extraordinária?
- O formato é aberto e documentado?
Acessos
- Existem pelo menos dois administradores?
- A empresa controla o email principal?
- As chaves de API e códigos de recuperação estão guardados?
- Os acessos são revistos regularmente?
Continuidade
- Existe uma alternativa manual?
- Sei quanto tempo posso ficar parado?
- Tenho RPO e RTO definidos?
- O procedimento de emergência está documentado?
Backups
- Tenho uma cópia independente do fornecedor?
- Já testei uma restauração?
- A restauração inclui dados, anexos e configurações?
- Consigo restaurar noutro ambiente?
Integrações
- Sei que sistemas dependem deste fornecedor?
- Tenho inventário de webhooks, APIs e automações?
- Sei o que acontece quando uma integração falha?
- Existem alertas para detectar falhas silenciosas?
Migração
- Existe uma alternativa real?
- Tenho um plano de migração?
- Já fiz um teste com dados reais ou anonimizados?
- Sei quanto tempo e recursos seriam necessários?
Se responderes “não” a várias perguntas, não estás perante um risco teórico. Estás perante uma dependência operacional concreta.
O plano prático para os próximos 90 dias
Não tentes resolver tudo numa semana. Trabalha por etapas.
Nos próximos sete dias
- lista os sistemas utilizados;
- identifica os fornecedores críticos;
- classifica cada sistema;
- confirma quem tem acesso administrativo;
- verifica as condições de exportação.
Nos próximos 30 dias
- cria cópias independentes;
- testa uma restauração;
- documenta integrações;
- guarda configurações importantes;
- define alternativas manuais;
- corrige contas controladas por uma única pessoa.
Nos próximos 90 dias
- escolhe alternativas para os sistemas de maior risco;
- executa um teste de migração;
- revê contratos;
- documenta o plano de saída;
- repete a auditoria com uma pessoa que não conhece o sistema;
- agenda testes periódicos de recuperação.
A preparação não elimina todos os problemas. Mas transforma um colapso inesperado num projecto de transição controlável.
O objectivo não é trabalhar sem fornecedores. É garantir que nenhum fornecedor consegue parar sozinho o teu negócio.