Como escolher fornecedor para reestruturação de sistemas governamentais no SUS e em prefeituras
Um checklist decisório para CTOs, CEOs e gestores que precisam modernizar sistemas usados por municípios, unidades de saúde e equipes distribuídas sem colocar a operação em risco.
Fale com a OrbeSoft sobre sua reestruturação
Neste artigo9 seções
- O que avaliar antes de escolher um fornecedor para reestruturar sistemas governamentais
- Checklist de discovery para sistemas do SUS e de prefeituras
- Scorecard decisório para comparar fornecedores de reestruturação
- SLAs, SLIs e evidências de resiliência que você deve exigir
- Artefatos técnicos que precisam existir antes da assinatura
- Squad sênior, fábrica de software ou consultoria global: como decidir
- Como estruturar garantias contratuais e critérios de aceite
- Processo de seleção em 30 dias e erros que devem ser evitados
- Checklist final para a decisão do CTO e do CEO
O que avaliar antes de escolher um fornecedor para reestruturar sistemas governamentais
Escolher um fornecedor para reestruturação de sistemas governamentais exige mais do que comparar preço, quantidade de desenvolvedores ou prazo de entrega. Em ambientes do SUS e de prefeituras, a decisão precisa considerar continuidade do serviço, proteção de dados, operação em regiões distribuídas e capacidade de evoluir o sistema sem interromper usuários.
O primeiro filtro é separar uma empresa que apenas executa tarefas de uma parceira capaz de compreender o serviço público. Um sistema que atende centenas de prefeituras possui múltiplos perfis de usuário, regras locais, integrações, picos sazonais e diferentes níveis de maturidade tecnológica. Uma proposta genérica tende a esconder riscos que aparecem somente depois da contratação.
Antes de pedir uma estimativa, conduza um diagnóstico mínimo. Converse com gestores, operadores, equipe de suporte, usuários de unidades de saúde e responsáveis por infraestrutura. O roteiro de discovery de mercado antes de uma linha de código ajuda a organizar entrevistas e hipóteses, mas, em sistemas públicos, essas conversas também precisam revelar dependências operacionais que não aparecem no backlog.
A experiência da OrbeSoft mostra que a contratação direta de uma equipe, sem auditoria técnica prévia, costuma transferir o problema em vez de resolvê-lo. Em um projeto de reestruturação de uma plataforma que atendia aproximadamente 800 prefeituras no ecossistema do SUS, disponibilidade, suporte e previsibilidade operacional precisavam ser tratados como requisitos de negócio, não como detalhes posteriores.
O objetivo deste checklist é ajudar você a tomar uma decisão documentada. Ao final, a proposta vencedora deve demonstrar evidências de execução, governança e operação, não apenas uma lista de tecnologias conhecidas.
Checklist de discovery para sistemas do SUS e de prefeituras
- 1
Defina o serviço que não pode parar
Liste as funções críticas, como cadastro, regulação, agendamento, faturamento, prontuário, relatórios e integrações. Classifique cada uma pelo impacto de uma indisponibilidade de 15 minutos, 2 horas ou 1 dia.
- 2
Mapeie usuários, municípios e variações locais
Identifique perfis, permissões, fluxos por município, unidades com conectividade limitada e rotinas manuais. O fornecedor precisa entender se existe uma plataforma comum com configurações locais ou várias versões difíceis de manter.
- 3
Faça o inventário de integrações e dados
Registre APIs, bancos, filas, arquivos, sistemas legados, serviços de identidade e integrações com plataformas públicas. Para cada conexão, documente proprietário, frequência, formato, autenticação e comportamento quando o serviço externo fica indisponível.
- 4
Meça a situação atual
Colete indicadores de disponibilidade, tempo de resposta, erros, volume de chamados, tempo de recuperação e frequência de deploy. Mesmo que os dados sejam incompletos, registre a fonte e a confiabilidade de cada medição.
- 5
Identifique a dívida que ameaça o serviço
Priorize código sem testes, componentes sem responsáveis, credenciais compartilhadas, tarefas manuais, banco sem estratégia de restauração e partes do sistema conhecidas por apenas uma pessoa. Dívida técnica deve ser traduzida em risco operacional e custo de atraso.
- 6
Defina o que será preservado
Estabeleça quais regras, históricos, relatórios e integrações precisam permanecer compatíveis. Uma reestruturação não é bem-sucedida se melhora a arquitetura, mas quebra a rotina de uma unidade ou obriga municípios a refazerem dados.
- 7
Transforme descobertas em critérios de aceitação
Cada entrega deve ter comportamento observável, evidência esperada e condição de aprovação. Por exemplo, uma migração pode exigir reconciliação de registros, teste de rollback e validação por usuários de municípios com diferentes configurações.
Scorecard decisório para comparar fornecedores de reestruturação
- ✓Experiência em governo, saúde ou operações distribuídas, com referências verificáveis e descrição do problema resolvido. Não aceite apenas logotipos ou declarações genéricas de atuação no setor público.
- ✓Capacidade de discovery e auditoria técnica antes do desenvolvimento. A proposta deve explicar como o fornecedor vai entrevistar usuários, analisar arquitetura, identificar gargalos e converter achados em um plano priorizado.
- ✓Governança e comunicação executiva, incluindo responsáveis nomeados, rituais de decisão, registro de riscos, relatórios para CEO e CTO e mecanismo de escalonamento de incidentes.
- ✓Equipe realmente dedicada, com arquiteto, engenharia, qualidade, segurança e conhecimento de operação. Verifique nomes, senioridade, disponibilidade e regra de substituição antes de considerar o time como parte da proposta.
- ✓Experiência com prestação de contas e recursos de inovação. Projetos apoiados por FAPESC, FINEP ou BNDES exigem rastreabilidade de escopo, horas, entregáveis e evidências, além da execução técnica.
- ✓Plano de transição sem interrupção, com etapas reversíveis, migração progressiva, compatibilidade temporária e estratégia de comunicação com municípios e usuários.
- ✓Propriedade e portabilidade dos ativos. Código, infraestrutura como código, documentação, pipelines, testes, dados e credenciais operacionais devem permanecer acessíveis ao contratante.
- ✓Operação após a entrega. Runbooks, painéis, alertas, treinamento e suporte precisam aparecer como entregáveis mensuráveis, e não como uma promessa de disponibilidade futura.
- ✓Maturidade para dizer não. Um fornecedor confiável questiona funcionalidades de baixo valor, propõe encapsular partes do legado quando necessário e recomenda pausar uma mudança quando as evidências indicam risco excessivo.
- ✓Modelo comercial coerente com a incerteza. Discovery e diagnóstico podem ter escopo fechado, enquanto a execução de uma reestruturação complexa precisa de mecanismos para tratar descobertas sem transformar toda alteração em aditivo.
SLAs, SLIs e evidências de resiliência que você deve exigir
SLA é o compromisso contratual; SLI é a métrica observada que mostra se o serviço está cumprindo o compromisso. Para um sistema público de saúde, o contrato precisa conectar os dois. “Alta disponibilidade” é vago; já uma meta de disponibilidade mensal, tempo máximo de resposta para funções críticas e prazo de restauração pode ser monitorada e auditada.
Exija uma matriz por serviço. Ela deve informar disponibilidade, latência, taxa de erro, janela de manutenção, tempo de resposta a incidentes, tempo objetivo de recuperação e ponto objetivo de recuperação de dados. Os valores devem variar conforme a criticidade: consulta de agenda, por exemplo, pode ter prioridade diferente de uma tela administrativa usada uma vez por mês.
O fornecedor também deve apresentar evidências de testes de carga. Peça cenário, volume de usuários simultâneos, distribuição de requisições, massa de dados, duração, ambiente, gargalos encontrados e plano de correção. Um gráfico de desempenho sem metodologia não prova que a solução suporta a realidade de vários municípios acessando o sistema ao mesmo tempo.
Resiliência inclui comportamento durante falhas. A proposta precisa explicar o que acontece quando uma API externa cai, uma fila acumula mensagens, a rede de uma unidade oscila, o banco fica indisponível ou uma implantação precisa ser revertida. O guia prático de observabilidade para produtos digitais oferece uma referência útil para organizar métricas, rastreamento e runbooks.
Para dados pessoais e de saúde, solicite também controles de acesso, trilhas de auditoria, criptografia, gestão de segredos, retenção e descarte. A Lei Geral de Proteção de Dados Pessoais, disponível no portal do Planalto, deve ser considerada junto às responsabilidades do controlador, operador e demais envolvidos no tratamento.
O contrato deve prever créditos, correção prioritária, plano de ação e direito de auditoria quando as metas não forem atendidas. Penalidade isolada não recupera um serviço; por isso, a governança de incidentes e a obrigação de produzir evidências são tão importantes quanto a multa.
Artefatos técnicos que precisam existir antes da assinatura
- 1
Arquitetura atual e arquitetura alvo
Peça diagramas de componentes, fluxos de dados, integrações, zonas de confiança e dependências externas. A arquitetura alvo deve justificar cada mudança pelo risco ou resultado esperado, sem propor microsserviços apenas por preferência tecnológica.
- 2
Registro de riscos e decisões
O fornecedor deve listar riscos técnicos, operacionais, legais e de adoção, com probabilidade, impacto, responsável e mitigação. Decisões relevantes precisam ficar registradas com alternativas consideradas e motivo da escolha.
- 3
Plano de migração e rollback
Exija sequência de ondas, critérios de entrada, validação de dados, janela de mudança, responsáveis e procedimento de retorno. Em uma operação distribuída, o plano deve prever municípios piloto e expansão gradual.
- 4
Estratégia de testes
Inclua testes unitários, integração, contrato de API, regressão, segurança, carga, recuperação e aceite com usuários. Defina quais evidências serão entregues, como relatórios, logs, cobertura relevante e resultados reproduzíveis.
- 5
Runbooks operacionais
Cada incidente frequente precisa ter um procedimento simples para diagnóstico, contenção, comunicação e recuperação. O documento deve indicar comandos, responsáveis, pré-condições, alertas relacionados e forma de confirmar que o serviço voltou ao normal.
- 6
Plano de transferência de conhecimento
Inclua sessões gravadas, documentação atualizada, treinamento prático e período de operação acompanhada. A saída do fornecedor não pode deixar o órgão ou a empresa dependente de uma pessoa específica.
- 7
Matriz de critérios de aceitação
Associe cada marco a testes, evidências, aprovadores e consequência de reprovação. Evite aceitar uma entrega apenas porque o código foi publicado ou porque uma demonstração funcionou em ambiente controlado.
Squad sênior, fábrica de software ou consultoria global: como decidir
A melhor estrutura depende do risco e da natureza do trabalho. Uma fábrica de software pode funcionar quando o escopo é estável, as especificações são completas e a prioridade é produzir funcionalidades previsíveis. Ela tende a ser menos adequada quando o problema principal ainda precisa ser descoberto ou envolve decisões de arquitetura e operação.
Uma consultoria global pode oferecer capacidade ampla, metodologias maduras e cobertura geográfica. Em contrapartida, você precisa verificar quem realmente executará o trabalho, quantas camadas de aprovação existirão, quanto do orçamento será consumido por gestão e se a equipe terá contexto suficiente sobre a operação municipal.
Uma squad sênior dedicada costuma ser adequada quando há um gargalo crítico, backlog acumulado ou necessidade de reestruturar sem ampliar o quadro interno. O benefício não está apenas no número de pessoas, mas na combinação entre arquiteto, engenharia, qualidade e visão de produto, com responsabilidade por um resultado claramente definido.
A matriz prática para escolher entre alocação, staff augmentation e projeto fechado ajuda a organizar essa escolha. Em projetos governamentais, acrescente critérios de segurança, prestação de contas, continuidade e transferência de conhecimento.
A OrbeSoft trabalha com projetos fechados de ponta a ponta e squads dedicadas, mas não parte do modelo comercial antes de entender o problema. Essa postura é especialmente relevante quando a reestruturação precisa conciliar continuidade do serviço, modernização gradual e capacidade limitada do time interno.
O ponto de atenção para CEOs e CTOs é a tensão entre velocidade e sustentabilidade. O CEO precisa destravar entregas e reduzir risco de atraso; o CTO precisa evitar uma nova camada de complexidade. Uma boa governança dá espaço para as duas preocupações e mede sucesso por disponibilidade, adoção, incidentes evitados e entregas de negócio, não por quantidade de código.
Como estruturar garantias contratuais e critérios de aceite
O contrato deve separar diagnóstico, implementação, operação assistida e sustentação. Cada fase precisa ter escopo, premissas, dependências do contratante, entregáveis, critérios de aceite e procedimento para tratar mudanças. Essa separação evita que uma descoberta legítima seja confundida com falha de planejamento ou usada para justificar alteração de escopo sem controle.
Para cada marco, defina uma evidência objetiva. Uma entrega de migração pode exigir uma taxa acordada de reconciliação, validação por amostra, relatório de inconsistências, teste de restauração e aprovação de usuários representativos. Uma entrega de performance pode exigir um cenário de carga reproduzível, limite de erros e comportamento definido em caso de saturação.
Inclua cláusulas de continuidade e saída. O fornecedor deve entregar código-fonte, documentação, inventário de ativos, histórico de decisões, pipelines, configurações e conhecimento operacional em formato utilizável. O checklist de contrato de saída e code escrow para squads alocados pode apoiar a negociação de contingências e transição.
Defina responsabilidades de dados com precisão. Quem aprova acessos? Quem responde por classificação, retenção e restauração? Quem notifica incidentes? Quem mantém certificados e chaves? Sem uma matriz de responsabilidades, o contrato pode atribuir metas ao fornecedor sem conceder os acessos ou decisões necessários para cumpri-las.
Também considere a Lei nº 14.133/2021 quando a contratação estiver submetida ao regime de licitações e contratos administrativos. O texto oficial da Lei de Licitações e Contratos Administrativos no Planalto deve ser analisado pela assessoria jurídica e pela área de compras para adequar critérios, fiscalização e gestão contratual.
Em projetos apoiados por FAPESC, FINEP ou BNDES, alinhe o contrato aos marcos e evidências exigidos pelo instrumento de fomento. A experiência da OrbeSoft em mais de 17 projetos FAPESC e 3 projetos FINEP reforça uma lição prática: prestação de contas não deve ser montada no fim, mas incorporada ao fluxo de execução desde o primeiro marco.
Processo de seleção em 30 dias e erros que devem ser evitados
- 1
Dias 1 a 5: prepare o pacote de decisão
Reúna objetivos, arquitetura disponível, incidentes, integrações, restrições de dados, orçamento, prazo, usuários críticos e critérios de sucesso. Se os dados forem insuficientes, contrate ou solicite um diagnóstico inicial antes de comparar propostas definitivas.
- 2
Dias 6 a 12: faça uma triagem baseada em evidências
Elimine fornecedores que não apresentam equipe nomeada, casos comparáveis, plano de testes, estratégia de transição ou responsabilidades claras. Uma proposta bonita, mas sem artefatos verificáveis, deve perder pontos.
- 3
Dias 13 a 20: conduza uma prova de entendimento
Peça que cada finalista analise um fluxo crítico, aponte riscos e proponha uma sequência de intervenção. Você não está comprando uma solução gratuita, mas avaliando a qualidade das perguntas, a honestidade das premissas e a capacidade de priorização.
- 4
Dias 21 a 25: valide operação e referências
Converse com clientes de porte e complexidade semelhantes. Pergunte sobre incidentes, substituição de profissionais, qualidade da documentação, cumprimento de SLAs e comportamento do fornecedor quando o plano original precisou mudar.
- 5
Dias 26 a 30: negocie o contrato e o primeiro marco
Feche critérios de aceite, governança, segurança, propriedade intelectual, transferência e saída. O primeiro marco deve produzir conhecimento acionável, reduzir uma incerteza relevante e permitir uma decisão de continuidade.
Checklist final para a decisão do CTO e do CEO
- ✓O fornecedor identificou riscos que não estavam explícitos no briefing?
- ✓A equipe apresentada é a mesma que participará da execução?
- ✓Existe experiência comprovável com sistemas críticos, saúde, governo ou operações distribuídas?
- ✓A proposta mostra como medir disponibilidade, latência, erros, recuperação e qualidade de dados?
- ✓Há testes de carga, segurança, restauração e rollback previstos antes do aceite?
- ✓Os runbooks, painéis, alertas e treinamentos fazem parte dos entregáveis?
- ✓O plano mantém o serviço funcionando durante a migração?
- ✓O contrato protege código, dados, documentação, infraestrutura e transferência de conhecimento?
- ✓As responsabilidades entre contratante, fornecedor e terceiros estão explícitas?
- ✓Os marcos podem ser auditados e relacionados a uma prestação de contas de FAPESC, FINEP ou BNDES?
- ✓O modelo de equipe é compatível com a incerteza do projeto e com a capacidade do time interno?
- ✓A proposta mede resultado operacional e impacto no usuário, não apenas horas ou pontos de função?
Perguntas Frequentes
Quais SLAs e SLIs mínimos devo exigir de um sistema que atende serviços públicos de saúde?▼
Comece por disponibilidade, latência, taxa de erro, tempo de resposta a incidentes, tempo objetivo de recuperação e ponto objetivo de recuperação de dados. Não existe um valor universal: uma função de regulação pode exigir prioridade diferente de um relatório administrativo. O contrato deve definir a forma de medição, a fonte dos dados, as janelas de manutenção e as consequências quando a meta não for atingida.
Como comparar uma squad sênior dedicada com uma consultoria global em um projeto govtech?▼
Compare equipe real, governança, experiência em operações distribuídas, velocidade de decisão, capacidade de discovery e custo total de gestão. A consultoria global pode ter maior amplitude, enquanto uma squad dedicada pode oferecer proximidade e foco, mas isso só é vantagem se houver senioridade comprovada e responsabilidade clara. Peça uma análise do seu cenário, referências verificáveis e a identificação dos profissionais que estarão no projeto.
Quais artefatos técnicos devem constar na proposta antes de assinar?▼
Exija arquitetura atual e alvo, inventário de integrações, registro de riscos, plano de migração, rollback, estratégia de testes, critérios de aceite, runbooks, plano de observabilidade e transferência de conhecimento. Para sistemas críticos, inclua evidências ou plano formal de testes de carga, segurança, restauração e continuidade. A proposta não precisa detalhar tudo no mesmo nível, mas deve deixar claro quando cada artefato será produzido e aprovado.
Como reduzir o risco operacional ao reestruturar um sistema usado por muitas prefeituras?▼
Use ondas de migração, começando por municípios ou fluxos representativos e de menor risco. Mantenha compatibilidade temporária quando necessário, monitore indicadores antes e depois da mudança e defina critérios objetivos para avançar ou interromper a expansão. O plano também deve prever comunicação, suporte reforçado e retorno controlado para a versão anterior.
É melhor reescrever o sistema legado ou modernizá-lo gradualmente?▼
A resposta depende da criticidade, do estado do código, da qualidade dos testes, das integrações e da capacidade de manter duas soluções durante a transição. Reescrever tudo pode simplificar a arquitetura, mas concentra risco e prolonga o período sem valor entregue; modernizar por módulos reduz o raio de impacto, embora exija uma estratégia de convivência. Um diagnóstico técnico com mapa de dependências e custo de oportunidade deve preceder a escolha.
Como contratar um fornecedor para um projeto com recursos da FAPESC, FINEP ou BNDES?▼
Conecte o plano técnico aos objetivos, marcos, entregáveis e evidências previstos no instrumento de fomento. O fornecedor deve demonstrar experiência em documentação, rastreabilidade de horas, relatórios e prestação de contas, sem transformar a execução em burocracia desconectada do produto. Também deixe definidos propriedade intelectual, critérios de aceite, governança e responsabilidades por eventuais mudanças de escopo.
Quanto custa reestruturar um sistema governamental?▼
O custo depende do número de usuários, municípios, integrações, volume e sensibilidade dos dados, estado do legado, metas de disponibilidade e necessidade de operação assistida. Uma estimativa séria separa diagnóstico, construção, migração, testes, infraestrutura e sustentação, em vez de apresentar apenas um valor por desenvolvedor. Para reduzir incerteza, solicite primeiro um diagnóstico com entregáveis e preço próprios.
A OrbeSoft pode atuar sem substituir o time interno?▼
Sim. A OrbeSoft pode trabalhar em projeto fechado de ponta a ponta ou com uma squad sênior dedicada integrada à governança existente, conforme o problema e a capacidade interna. O objetivo é complementar o time, transferir conhecimento e assumir um resultado claro, sem criar dependência desnecessária. A recomendação deve partir do diagnóstico técnico e operacional, não de um modelo único de contratação.
Pronto para avaliar sua reestruturação com menos risco?
Solicitar diagnóstico com a OrbeSoftSobre o Autor
Felippe Sandrini é CEO da Orbe Soft e especialista em criação de produtos digitais, validação de MVPs e inovação tecnológica. Com experiência em startups, projetos corporativos e software sob medida, escreve sobre produto, UX, tecnologia e decisões estratégicas para quem quer crescer com menos risco e mais resultado.