Resposta direta
A desativação começa antes de qualquer decisão técnica. O primeiro passo é listar quem usa o sistema, quais dados entram e saem dele e o que deixa de funcionar se ele parar. A partir dessa lista, define-se um responsável pela decisão, um critério de saída e uma data de referência. Sem isso, o sistema continua ativo por inércia. A desativação não é um evento único: é um processo com etapas registradas, revisão periódica e autoridade definida para interromper o que já não se sustenta.
- Objetivo
- Organizar um processo
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata o encerramento como processo com dono e registro, não como decisão pontual da área de tecnologia.
O custo de manter um sistema sem data de fim
Sistema ativo consome licença, suporte, integração e atenção de quem opera. O custo raramente aparece em uma linha de orçamento: fica distribuído em horas de manutenção, em exceções tratadas à mão e em conferências feitas para reconciliar dados entre sistemas.
Quando não existe data de encerramento, a decisão de desligar nunca entra na pauta. O sistema se mantém por hábito, por receio de perder histórico ou porque ninguém quer assumir a interrupção. Nomear esse custo é o que permite discutir a saída.
Quem responde pela decisão
Desativação exige um responsável nomeado, com autoridade para interromper o uso mesmo quando outra área ainda depende do sistema. Sem essa definição, cada tentativa de desligar vira negociação sem fim, e o sistema permanece no ar por falta de quem decida.
O registro do que cada área usa e do que deixaria de receber ao desligar torna a conversa concreta. A decisão deixa de ser sobre preferência e passa a ser sobre o que será feito com o processo que dependia daquele sistema.
O que esse processo não resolve
Organizar a desativação não substitui a decisão de negócio sobre encerrar ou manter um processo. Também não corrige dados inconsistentes que já circulam nem consolida cadastros duplicados: apenas expõe dependências que estavam invisíveis.
Em operações com exigência de retenção legal ou auditoria, o desligamento pode não ser possível de imediato. Nesse caso, o processo serve para registrar por que o sistema continua ativo e sob quais condições, não para encerrá-lo.
Recurso prático
Fluxo de desativação de um sistema em uso
- Listar quem usa o sistema, para que ele serve e qual processo fica parado sem ele.
- Registrar as dependências: entradas, saídas, relatórios e integrações ligadas a ele.
- Definir o responsável pela decisão de desligar e o critério que autoriza o encerramento.
- Acordar com as áreas o destino dos dados em retenção e o período de guarda.
- Marcar a data de referência e revisar a lista a cada ciclo, registrando o que ainda justifica manter o sistema.
O erro comum é tratar a desativação como projeto de tecnologia e não como decisão de operação. Enquanto nenhuma área assume o custo de manter o sistema vivo, ele permanece ativo por inércia.
Sobre o que está escrito aqui
Conceitos relacionados: inventário de sistemas em uso · critério de desligamento · dependências entre sistemas · dados em retenção · responsável pela decisão. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Projeto de implementação, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- Integrações, sistemas e qualidade de dados — Página central do tema
- Planilhas divergentes: alternativas para conf… — planilhas divergentes
- Planilhas divergentes: como alinhar bases par… — planilhas divergentes
Páginas relacionadas
O mesmo problema em outro objetivo
- Sistemas que ninguém desliga: como avaliar o custo — Diagnosticar
- Sistema que ninguém desliga: como comparar alternativas — Comparar alternativas
- Sistema sem desativação: como medir o que ele custa — Explicar medição
- Sistema novo sem desligar o antigo: o que decidir antes — Orientar implementação
- Sistema sem plano de desativação: o que fica no contrato — Orientar avaliação e contratação
Outras leituras em Integrações, sistemas e qualidade de dados
- Contratar arquitetura: o que fica definido e por quem — O que precisa estar definido em um contrato de arquitetura: decisão, entregável, responsável e critério de aceite, antes de comparar propostas.
- Teste de integração em ambiente controlado: o que medir — O que medir em teste de integração feito só em ambiente controlado, quais sinais ele não cobre e como separar aprovação de teste de confiança em produção.
- Duas fontes para o mesmo indicador: qual delas é oficial — Como definir, indicador por indicador, qual sistema é a fonte oficial, quem responde por ela e o que fazer com as demais fontes.
- Sistema antigo mantido só pelo histórico: o que exigir — Critérios para decidir entre manter, congelar ou substituir um sistema legado guardado apenas por histórico, e o que registrar no contrato de manutenção.
- Dados desatualizados: o que exigir ao contratar atualização — Critérios de escopo, validação e precificação para contratar serviços de enriquecimento e higienização cadastral sem pagar por dados sem uso operacional.