SaaS Sprawl: o problema das 50 ferramentas

SaaS sprawl é o que acontece quando uma empresa de médio porte acaba pagando mais ferramentas de software do que qualquer pessoa em TI ou financeiro consegue nomear de memória, geralmente acima de 40 a 50 ferramentas, com várias fazendo o mesmo trabalho, assentos que ninguém lembra de ter atribuído, e nenhum responsável único pela lista completa. A solução não é uma limpeza geral. É uma contagem com três fontes cruzadas, um responsável por ferramenta, e uma rotina trimestral que mantém a lista atualizada em vez de reconstruí-la uma vez por ano durante uma auditoria.

O que é exatamente o SaaS sprawl?

O SaaS sprawl não é apenas um número alto de ferramentas. É o ponto em que ninguém na empresa, nem TI, nem financeiro, nem um líder de equipe, consegue listar todas as assinaturas pagas sem antes fazer uma auditoria. Duas empresas podem usar ambas 40 ferramentas SaaS; a que já mantém uma planilha com as 40 e um responsável por cada uma não tem sprawl. A que precisa reconstruir a lista a partir de extratos de cartão e suposições, tem.

O número importa menos do que a falta de responsável. Sprawl é a ausência de uma resposta única, atualizada e confiável para a pergunta sobre o que a empresa paga e por quê, e essa lacuna costuma aparecer a partir de 40 a 50 ferramentas numa empresa de médio porte, porque é aproximadamente o ponto em que a memória de uma única pessoa deixa de bastar.

Como uma equipe de médio porte chega a 50 ferramentas ou mais?

O sprawl quase nunca vem de uma única decisão ruim. Ele se acumula a partir de várias decisões individualmente razoáveis.

• Cadastro por autoatendimento com cartão da empresa. Qualquer funcionário com cartão pode ativar um plano pago em minutos, sem nenhuma etapa de compra que registre isso em algum lugar.
• Testes gratuitos que viram assinatura. Um teste iniciado para experimentar um recurso vira um plano pago que ninguém lembra de ter aprovado, porque o cartão renovou automaticamente antes de alguém verificar.
• Prestadores e equipes adquiridas. Um prestador traz sua própria ferramenta de projetos, ou uma aquisição traz toda a sua pilha de software, e ambas seguem em uso muito depois do ponto em que alguém deveria ter revisado se ainda faziam sentido.
• Soluções pontuais por departamento. O marketing compra uma ferramenta que o financeiro nunca vê, o comercial compra outra que a TI nunca provisiona via SSO, e cada uma se justifica isoladamente.
• Nenhum responsável único no momento da compra. Sem uma regra que exija um nome de responsável antes de o cartão ser cobrado, ninguém é responsável por revisar depois.

Quanto o SaaS sprawl custa de verdade além da linha de assinatura?

O total das assinaturas é o custo visível, e quase nunca o maior.

O gasto duplicado é o primeiro custo escondido: duas ferramentas de design, três de acompanhamento de projetos, ou um chat rodando ao lado do que todo mundo realmente usa, cada um cobrado separadamente porque ninguém os agrupou pela função que cumprem em vez do nome do fornecedor.

O acesso sem controle é o segundo, e o mais sério. Cada ferramenta é mais um login, e um login que ninguém revisa sobrevive à pessoa que o solicitou. O risco de conformidade de um login compartilhado ou esquecido cresce com o número de ferramentas, não com o preço da assinatura, e é o primeiro item que um auditor encontra.

O terceiro custo é o poder de negociação na renovação. Um fornecedor que negocia com uma empresa incapaz de dizer quantos assentos estão realmente em uso não tem motivo para oferecer um preço melhor, já que a própria empresa não consegue justificar um número menor.

Como encontrar todas as ferramentas que a empresa realmente paga?

Nenhuma fonte sozinha dá a lista completa. Três fontes, cruzadas entre si, chegam perto.

No workspace de demonstração da InventorIA, o registro tem 24 licenças em 6 fornecedores, um tamanho ainda pequeno o bastante para uma única pessoa manter toda a lista de cabeça. O sprawl costuma começar quando a empresa ultrapassa duas ou três vezes esse número, e com 50 ferramentas nenhuma memória individual mais cobre isso, motivo pelo qual o cruzamento de três fontes precisa substituir a memória, não só complementá-la. Abra a demonstração ao vivo para ver como fica um registro desse tamanho quando cada licença tem um responsável e um número de assentos ao lado.

Como cortar ferramentas duplicadas sem causar uma revolta?

Cortar uma ferramenta da forma errada gera mais resistência do que o próprio sprawl. Uma ordem de cinco passos evita a maior parte disso.

• Agrupar por função, não por nome de fornecedor. Listar o que cada ferramenta realmente faz, não como se chama, e sinalizar qualquer função que três ou mais ferramentas afirmem cobrir.
• Perguntar primeiro ao usuário mais assíduo. Antes de a TI decidir qual duplicata sobrevive, perguntar a quem mais usa qual manteria e por quê; o motivo costuma revelar uma dependência real de fluxo de trabalho, não uma simples preferência.
• Dar 90 dias e um guia de migração. Um corte da noite para o dia é o que provoca a revolta. Um aviso com data e um passo a passo para a ferramenta substituta, raramente.
• Manter a ferramenta perdedora como reserva por um ciclo de faturamento, não um ano inteiro, para que quem encontrar uma dependência esquecida tenha tempo de avisar sem que a decisão seja revertida por padrão.
• Cancelar a licença, não só os assentos, quando o uso ficar em zero por um ciclo completo; remover só os assentos deixa a assinatura e a data de renovação ativas.

Como evitar que o número de ferramentas volte a crescer?

Uma limpeza sem uma rotina posterior é só temporária. Três hábitos evitam a repetição.

Primeiro, nenhuma cobrança no cartão sem um responsável nomeado. Uma regra de compra que exija o nome de uma pessoa para qualquer nova cobrança SaaS, revisada no mesmo dia, fecha a brecha que deixou o sprawl começar; veja o guia de detecção de shadow IT para a versão desse controle que age depois da compra em vez de no momento.

Segundo, uma revisão trimestral, não anual. O guia de taxa de utilização de licenças cobre o número de assentos comprados versus usados que vale a pena checar a cada trimestre; uma ferramenta com taxa de utilização perto de zero por dois trimestres seguidos é uma candidata forte ao cancelamento.

Terceiro, um único registro que todos consultam antes de comprar, para que a primeira pergunta antes de qualquer compra nova seja se uma ferramenta existente já cumpre essa função. Crie seu próprio registro antes das próximas renovações do trimestre, para que o número seja um dado conhecido em vez de um palpite na próxima auditoria.

Relatórios de tendência do setor como o estudo anual Businesses at Work da Okta acompanham quantos aplicativos de nuvem as organizações conectam via SSO a cada ano, um dos sinais externos mais claros de que o número de aplicativos continua subindo independentemente do tamanho da empresa. A Cloud Security Alliance publica orientações de governança para o lado de segurança desse mesmo crescimento, vale a pena conferir assim que a lista em si estiver sob controle.

Perguntas frequentes

A partir de quantas ferramentas SaaS se fala em sprawl?

Não existe um número fixo, mas acima de cerca de 40 a 50 assinaturas ativas, a maioria das empresas de médio porte perde a capacidade de nomear cada ferramenta de memória, o que é a definição prática de sprawl, não um número exato.

O SaaS sprawl é só um problema de TI?

Não. O financeiro carrega o gasto duplicado, a segurança carrega a superfície de login que cada ferramenta soma, e a conformidade carrega a trilha de auditoria; uma correção que envolve só a TI deixa os outros dois sem resposta.

Qual a forma mais rápida de encontrar ferramentas SaaS escondidas?

Cruzar a lista de logins do SSO com os extratos de cartão e despesas. Uma ferramenta que aparece no extrato mas não no SSO está sem gestão ou está sendo acessada com login pessoal, ambos os casos merecem uma olhada mais atenta.

É preciso um software especial para corrigir o SaaS sprawl?

Não, uma planilha cruzando as três fontes acima resolve uma primeira passada. Um registro dedicado passa a valer a pena quando a lista fica longa o bastante para que mantê-la manualmente comece a falhar, geralmente o mesmo ponto em que o sprawl virou um problema real.