Quando um processo acumula exceções, a escolha deixa de ser simplesmente assinar um SaaS ou programar tudo do zero. Se as diferenças são raras e o produto as resolve por configuração, manter o SaaS tende a exigir menos operação própria. Se o problema é a passagem de dados entre ferramentas, a integração pode ser suficiente. Quando as regras excepcionais se tornam parte recorrente e estratégica do trabalho, uma camada própria sobre serviços existentes pode preservar o que já funciona sem recriar todo o sistema.
A unidade de análise deve ser o fluxo de negócio, não a empresa inteira: cadastro, aprovação, faturamento e suporte podem exigir soluções diferentes. A matriz abaixo é uma ferramenta editorial de comparação, não uma norma nem uma promessa de resultado automático.
Primeiro descubra se a exceção é real ou um contorno
Reúna casos reais do fluxo, do pedido à conclusão, com volume, frequência, tempo gasto, risco e responsável. Diferencie uma regra obrigatória de uma preferência individual; uma lacuna do produto de uma integração ausente; e uma falha de processo de uma necessidade legítima de diferenciação. Teste recursos nativos, permissões, automações e API antes de classificar o SaaS como incapaz.
Para cada desvio, registre:
- Gatilho e frequência: qual evento cria a exceção, quantas vezes ocorre e se a ocorrência cresce com o negócio.
- Impacto: retrabalho, atraso, erro, perda financeira, exposição de dados ou quebra de rastreabilidade.
- Tratamento atual: planilha paralela, cópia manual, customização do fornecedor, script ou decisão humana.
- Limite verificável: função demonstrada pelo fornecedor, integração realmente disponível, obrigação contratual e evidência dos testes.
As quatro rotas que precisam entrar na comparação
Não compare apenas compra contra construção. Considere quatro arquiteturas com fronteiras distintas:
| Rota | Serve quando | Ponto de atenção |
|---|---|---|
| Manter e configurar o SaaS | O fluxo principal cabe no produto e os desvios são controláveis por configuração, extensão suportada ou ajuste de procedimento. | Mensurar exceções e evitar processos paralelos invisíveis. |
| Integrar ferramentas | A regra já existe nos produtos, mas dados e eventos não atravessam os sistemas de forma confiável. | Definir dono do dado, falhas de sincronização, limites de API e suporte entre fornecedores. |
| Adicionar camada própria | O SaaS cobre funções comuns, enquanto decisões, orquestração ou regras estratégicas exigem controle particular. | Evitar duplicar o cadastro mestre e transformar o adaptador em um novo monólito. |
| Construir sistema completo | O domínio central não cabe nas ofertas disponíveis e a organização tem capacidade contínua de desenvolver e operar. | Assumir também segurança, disponibilidade, manutenção, atendimento e evolução. |
A opção híbrida é uma decisão arquitetural válida: SaaS para capacidades padronizadas e software próprio somente onde há necessidade demonstrada de controle. Ela não significa acumular integrações sem governança.
Matriz ponderada: seis critérios para comparar as opções
Use os pesos abaixo como exemplo ajustável. A equipe deve pactuar os pesos antes de pontuar fornecedores ou propostas. Para cada rota, atribua de 0 a 3 com base em demonstração, protótipo, cláusula contratual ou medição: 0 = não atende; 1 = depende de contorno frágil; 2 = atende com esforço conhecido; 3 = atende com evidência testada.
| Critério | Peso ilustrativo | Pergunta para verificar | Sinal favorável a SaaS | Sinal favorável a integração ou código próprio |
|---|---|---|---|---|
| Exceções do processo | 25% | A solução executa as variantes relevantes sem trabalho paralelo? | Exceções raras ou cobertas por configuração. | Regras frequentes, necessárias e não suportadas nativamente. |
| Integrações | 20% | APIs, eventos, limites e tratamento de falhas sustentam o fluxo? | Conectores suficientes e fluxo já consistente. | Múltiplos sistemas exigem tradução ou orquestração controlada. |
| Lock-in e portabilidade | 15% | É possível extrair dados, anexos, histórico e relações em formato utilizável? | Exportação contratual e substituição comprováveis. | Dependência proprietária alta pede desacoplamento ou domínio próprio. |
| Custo de mudança | 15% | Quanto custa alterar regra, trocar fornecedor e treinar usuários? | Configurações e suporte evoluem dentro do prazo necessário. | Cada mudança gera projeto caro, espera ou retrabalho. |
| Governança de dados | 15% | Quem controla acesso, qualidade, retenção, auditoria e fonte da verdade? | Controles e responsabilidades atendem aos requisitos. | Há lacunas que pedem camada de domínio ou controles adicionais. |
| Criticidade operacional | 10% | Qual é o impacto da falha e quem responde por recuperação e suporte? | SLA e contingência comprovados para o fluxo. | Dependências exigem controle especial, observabilidade ou recuperação própria. |
Cálculo por alternativa: nota ponderada = soma(peso × nota) ÷ 3, com os pesos em pontos percentuais; o resultado fica entre 0 e 100. Não transforme a maior nota em autorização automática: um requisito eliminatório, como exportação inviável, acesso indevido ou recuperação incompatível com a operação, precisa ser resolvido antes da escolha. Registre incertezas em vez de atribuir nota máxima a promessas comerciais.
Compare custo total e custo de mudar, não só assinatura e projeto
Compare as opções no mesmo horizonte, por exemplo 12, 24 e 36 meses, usando cotações reais e hipóteses explícitas. A orientação de custo da Microsoft diferencia implantação mais rápida e cobrança recorrente da compra frente a investimento e manutenção do desenvolvimento; a AWS recomenda incluir operação e gestão no custo total de propriedade. Isso fundamenta a comparação, mas não fornece um preço universal para SaaS ou software próprio.
Monte três estimativas sem contar o mesmo item duas vezes:
- SaaS: licenças ou uso, implantação, módulos, integrações, suporte, trabalho manual residual, reajustes e saída.
- Próprio: descoberta, construção, testes, infraestrutura, segurança, observabilidade, suporte, manutenção, evolução e substituição de pessoas-chave.
- Híbrido: contratos existentes, camada própria, operação das integrações, reconciliação de dados e responsabilidade por falhas entre componentes.
Faça sensibilidade para número de usuários, transações de API, crescimento de exceções, reajustes, mudança de fornecedor e indisponibilidade. O ponto decisivo é quanto a arquitetura custa para operar e adaptar, não apenas para estrear.
Como desenhar a opção híbrida sem criar outra coleção de exceções
Defina qual componente é a fonte da verdade de cada entidade e onde vive cada regra. Uma camada de adaptação pode traduzir modelos e contratos entre produtos sem contaminar a lógica central, como descreve o padrão Anti-Corruption Layer da Microsoft. Ele adiciona serviço, latência e obrigações de monitoramento: não deve ser criado só para passar dados de um lado ao outro quando uma integração simples basta.
Se partes do processo precisarem ser substituídas progressivamente, o padrão Strangler Fig descreve a convivência temporária entre funcionalidades antigas e novas; não exige reescrever tudo de uma vez. A portabilidade também deve ser demonstrada na prática, pois, segundo o NIST, interfaces e padrões influenciam a capacidade de mover dados e aplicações.
- Estabeleça identificadores, proprietário de cada dado, mapeamentos e rotina de reconciliação.
- Documente autenticação, autorização por objeto e função, escopos, segredos e limites das APIs; a OWASP identifica riscos específicos dessas interfaces.
- Projete repetição segura de operações, filas quando pertinentes, reprocessamento, alertas e trilha de auditoria.
- Teste exportação, restauração, contingência e encerramento de contrato antes de depender da integração.
Teste uma fatia do processo antes da decisão definitiva
O piloto deve reproduzir as exceções mais relevantes, e não apenas o caminho feliz de uma demonstração. Uma sequência prática é:
- Selecionar o fluxo e documentar critérios obrigatórios, variantes e estado atual.
- Solicitar demonstração com casos reais e comprovar APIs, permissões, exportação e condições contratuais.
- Executar a mesma amostra em SaaS configurado, integração e protótipo de camada própria, quando viáveis.
- Medir tempo de ciclo, intervenções manuais, erros, custo operacional, rastreabilidade e recuperação de falhas.
- Registrar responsáveis, orçamento, plano de migração, retorno ao estado anterior e data de reavaliação.
Se nenhuma rota satisfaz os requisitos obrigatórios, revise escopo e processo antes de contratar ou iniciar uma reescrita. Uma solução híbrida pode ser temporária ou estável; explicite qual papel ela terá.
Como interpretar o resultado sem forçar uma resposta binária
Depois de aplicar requisitos eliminatórios, evidências e custos:
- Permaneça no SaaS quando os desvios forem limitados, recursos nativos resolverem os casos e a saída contratual estiver clara.
- Integre ferramentas quando a perda ocorrer entre etapas, não dentro das regras de cada produto.
- Construa uma camada própria quando a diferenciação estiver em decisões, exceções e coordenação, mas os serviços comuns já funcionarem.
- Considere sistema integralmente próprio quando o domínio exigir controle amplo e houver equipe, orçamento e governança para sustentá-lo após o lançamento.
O sinal de mudança não é a quantidade de planilhas em si: é a combinação comprovada de exceções recorrentes, impacto operacional, limites de integração e custo para evoluir. Reavalie a matriz quando esses fatores mudarem.
Fontes e escopo da matriz
Os pesos, a escala de 0 a 3 e as rotas de decisão são proposta editorial de análise, não uma metodologia oficial das instituições citadas. A fundamentação técnica e de custos está em:
