Você procura por
  • em Publicações
  • em Grupos
  • em Usuários
BACK

SaaS, you need to be more specific!

SaaS, you need to be more specific!
Diogo Machado
Jan. 30 - 13 min read
010

A maioria das empresas de tecnologia baseia seus negócios no modelo SaaS, enxergando nessa modelagem um grande trunfo na monetização e desenvolvimento de plataformas. Mas, mirando mercados de alta complexidade, o modelo SaaS começa a enfrentar alguns desgastes e está na hora de virar essa página.

Após alguns anos trabalhando com ecossistemas de inovação, estruturando novos negócios tecnológicos, repensando dinossauros do segmento e convivendo com a comunidade de startupeiros, posso dizer que algumas verdades sobre modelagem de negócios digitais precisam ser escancaradas.

Em qualquer hackathon visitado, qualquer proposta de consultoria montada ou qualquer novo direcionamento de negócio para empresas em transição, o modelo SaaS reina absoluto, principalmente os modelos com foco B2B. A maioria dos anjos, seeds, aceleradoras, venture capitals e private equities coloca essa modelagem como tese básica para oferta de aporte.

De fato, o SaaS resolve diversos problemas que os antigos softwares empresariais trazem. Estrutura física enxuta, ferramentas leves e mudanças ágeis, custos menores de aquisição e manutenção, dados em cloud e mais uma dezena de outros fatores que mataram modelos tradicionais de negócios digitais. Mas, agora, esses mesmos problemas que assolavam empresas desenvolvedoras de robustos ERPs, CRMs e TMAs engessados, estão sendo sentidos na modelagem SaaS para segmentos complexos. 

O principal empecilho do modelo SaaS para esse nicho é a busca incessante pelo generalismo de features. O mesmo generalismo que foi duramente combatido pelas empresas em nuvem no início dos anos 2000. Essa verdade absoluta entre empresas desenvolvedoras será a pá de cal necessária para enterrar esse modelo de negócio.

O SaaS possui pontos positivos que a maioria dos leitores irá concordar. Nuvem, mensalidade baixa, velocidade de desenvolvimento, exponencialidade, produtos focados no consumidor, UX, propósito, cultura dos desenvolvedores, facilidade de instalação e de manutenção. Mas, a busca pelo aumento de share de mercado e o aumento no churn tem colocado as empresas para focar em plataformas cada vez mais generalistas, com features que servem para todos, e é aí que mora o perigo.

Algumas empresas de SaaS podem e devem focar no generalismo, principalmente aquelas que escolhem um modelo B2C ou B2B com ticket baixo. Hangout, Gmail, Spotify, Netflix, Conta Azul e demais empresas criam plataformas extremamente fáceis de utilizar e que possam abranger a maioria das diversas demandas de utilidade. Contudo o problema está nas empresas B2B Enterprise, principalmente aquelas que estão trabalham com mercados complexos, como tributário, trade marketing, supply chain, dados.

A atual arquitetura de negócios das empresas de SaaS foca em atender uma vertical de mercado específica, com o mínimo de features possível ou com o máximo de features que atendem 100% da carteira. Já escutei de muitos PMs que uma relação de 1 demanda para cada 100 clientes é a taxa ideal de requisitos. Atualmente, a média dessas empresas está em 10 demandas para cada 100 clientes. Eu ainda acredito que essa média seja maior, se considerarmos algumas demandas para fechamento de negócios.

Ano passado, durante um projeto numa grande empresa de dados fiscais do Brasil, conversei com a equipe de desenvolvimento sobre suas principais dores. Senti um déjà vu no meio da conversa, porque foi a mesma reclamação da maioria das empresas que me envolvi com algum tipo de trabalho. O mesmo problema que uma das líderes em trade marketing da américa latina, o mesmo problema que uma das maiores empresas de cloud do Brasil enfrenta, o mesmo problema que inúmeras startups iniciando seus negócios sofrem: o foco no generalismo das features.

Quando falo generalismo, falo do mindset implementado pelas diretorias. De que todo feature ou todo desenvolvimento de front e backend precisa atender a totalidade dos clientes da empresa. É como se um feature solicitado pela multinacional X tivesse que ser pensado para atender também aquela empresa segmentada do interior do Paraná. Ou então que a solicitação de mudança de regra de banco fosse realizada em todos os mais de 10 mil clientes da base. A última moda agora é a construção de um guideline para frontend, onde todos os clientes precisam se adequar ao passo a passo construído pelos líderes de produto.

Nessa modelagem, a equipe de desenvolvimento sempre fica refém de duas áreas extremamente influentes dentro de uma empresa de tecnologia: o comercial e a diretoria. Por mais que a empresa possua um cronograma para o lançamento de novas features, novas versões e novos produtos, sempre tem aquele gerente comercial que fecha uma conta gigantesca, baseada no desenvolvimento da funcionalidade Y. Ou então pior, a cobrança e inserção no cronograma daquele novo módulo que será o novo “Salesforce” do mercado, segundo a visão esquizofrênica do fundador da empresa. Aquele mesmo que ainda pensa que Delphi é uma linguagem de programação robusta.

Ouvi de um CTO que 60% do trabalho de desenvolvimento da sua empresa, com mais de 100 desenvolvedores são para apagar incêndios, criar features de última hora ou resolver bugs criados por uma incorreta arquitetura de software. E esse é outro problema gigante de empresas de tecnologia: o legado. É incrível como os desenvolvedores mais antigos falam com sorriso no rosto que a empresa possui um legado de 15 anos. Que apenas alguns desenvolvedores seniores possuem o conhecimento necessário para destrinchar os frankensteins, formados por inúmeros desenvolvedores que odeiam documentações e processos. Refactoring é uma palavra que não sai da boca dos líderes de produtos. Foi nesse momento que tive outro déjà vu, na parte da refação.

Eu fico imaginando a dificuldade de estruturar uma arquitetura de negócios quando cada cliente exige uma necessidade específica, enquanto que o cerne do modelo de negócio SaaS é justamente generalizar as entregas, para atender o maior número de clientes possíveis. É justamente esse paradigma que desencadeará o enfraquecimento do modelo SaaS atual. É impossível atender grandes contas com total entrega de valor, quando a empresa possui apenas 3 grades de produtos específicos, incluindo o freemium.

Parametrizar entregas e colocar o custo de desenvolvimento na conta das mensalidades é menosprezar a complexidade das plataformas e pedir para que o modo frankenstein domine novamente. Grandes contas possuem o poder de exponencializar uma empresa, com seus tickets altos, o qual permite aumento de equipe e estrutura de mercado. Mas não podemos ter, ao mesmo tempo, um discurso generalista e uma atuação beneficiária para poucos. Esse modelo de formatação de negócio é um tiro no pé. É interessante ver o quão esquizofrênicas as novas empresas de SaaS estão se tornando, atendendo a necessidades de cada prospecção que entra em negociação, como se cada nova feature solicitada fosse o trampolim para o sucesso.

Com isso em mente, fico me perguntando qual o direcionamento correto. Para mim, o abandono do SaaS para modelagens B2B de alta complexidade. No lugar do SaaS, esse perfil de empresas precisa aderir a um submodelo que chamarei de CaaS, ou Cluster as a Service.

O termo Cluster é largamente utilizado no segmento de tecnologia. Um cluster é um conjunto de computadores interconectados que funciona como se fosse um só grande sistema. O objetivo é aplicar esse mesmo conceito para uma empresa desenvolvedora de softwares em nuvem, com diversos clientes com diversas demandas complexas.

Com esse conceito em mente, podemos desenhar a modelagem de negócio de uma empresa CaaS. Basicamente, ela se enquadra entre um SaaS, generalista nos features e uma Software House, generalista em conhecimento do segmento.

Uma Software House pode entregar um projeto extremamente complexo e personalizável, com equipe dedicada e alta capacidade técnica. Com recursos é possível inclusive que essa entrega seja realizada em tempo recorde. O problema das Software Houses é que elas são generalistas no entendimento de cenário. Enquanto produzem software para um LMS, também fornecem soluções para uma plataforma de marketplace e também para uma fintech. Essa falta de conhecimento técnico especializado no segmento gera uma infinidade de retrabalho e tornam as entregas extremamente comoditizadas. As Software Houses acabam indo para uma diferenciação por capacidade de desenvolvimento e não por entendimento de demandas.

Assim, um modelo de negócio CaaS é, ao mesmo tempo, especialista no seu segmento de mercado, entendendo as complexidades, tendências e regras de negócio, mas também estrutura a entrega parametrizada para cada cliente, formando clusters de desenvolvimento e entrega.

Assim, teríamos uma grande base de desenvolvimento nas verticais de negócio em que a empresa atua, mas entregamos uma parametrização para cada cliente na sua necessidade, obedecendo suas regras de negócio e características específicas.

Na realidade, isso muitas vezes é realizado de forma empírica. Grandes contas absorvidas pelo modelo SaaS sempre pedem adequações na plataforma para encaixar com os processos internos. De modo geral o custo dessa parametrização é absorvida pela mensalidade, que acaba possuindo ticket maior. O problema é que essa adequação acaba se tornando uma feature para todos os clientes, mudando o cronograma de desenvolvimento e criando uma demanda que não funciona para os outros 90% dos clientes.

Isso gera muita dificuldade com as versões, treinamento da feature, abandono dessa funcionalidade, dor de cabeça para o suporte e um legado de desenvolvimento cada vez mais robusto.

As empresas necessitam de soluções específicas para suas especificidades. O número de aplicativos implantados por grandes empresas em todos os setores do mundo aumentou 68% nos últimos quatro anos, atingindo uma média de 129 aplicativos por empresa até o final de 2018, de acordo com uma análise da Okta Inc.

Num modelo CaaS, dividimos o desenvolvimento em duas frentes, com foco em desenvolvimento em bloco. Os Clusters Managers, cuidando daquilo que é estritamente necessário como base para a totalidade dos clientes, tanto back ou front end. Eles também cuidam para que toda a arquitetura de desenvolvimento em blocos se una ao final do processo. E os Client Managers, que substituem os gerentes de produto baseados em features, para atender demandas de clientes específicos. Um mesmo Client Manager pode atender diversos clientes, conforme volume de demanda de desenvolvimento e gerenciamento.

No campo da monetização podemos estruturar o modelo comercial em duas estruturas. A mensalidade continua atuando, baseadas em features, usuários, volume de dados e as infinitas variáveis que o antigo modelo SaaS utilizava. Mas, agora, como novo modelo de negócio, alinhando expectativa e realidade desde o momento zero, os negócios CaaS podem estruturar uma proposta de desenvolvimento específica, nos mesmos moldes de uma Software House, porém com custos menores, uma vez que a base de desenvolvimento está pronta.

Nesse novo modelo CaaS, as empresas de tecnologia podem abrir mão do posicionamento generalista de features, podem abrir mão de absorver os custos de parametrização e podem absorver clientes que entrariam na carteira apenas se pudessem ter uma versão própria do software.

Os players desse modelo podem se posicionar de forma única. Em 2018, as empresas SaaS possuíam, em média, nove competidores e esse número vai crescer muito mais. O aparecimento de novos players se torna mais latente e competir com essas novas empresas se torna uma dor de cabeça para posicionamentos generalistas. Os novos entrantes chegam absorvendo novas demandas e regras de mercado, se tornando atrativas para aqueles clientes cansados de não serem escutados.

Acredito que a partir desse insight, profissionais das áreas relacionadas às empresas de tecnologia possam contribuir aqui para o amadurecimento da concepção CaaS e, em conjunto, criar uma nova modelagem de negócio que toda e qualquer empresa de tecnologia possa se apropriar.

 


Diogo Machado possui 12 anos de experiência em estratégias de negócios. Especializado no desenvolvimento e validação de novos produtos e serviços. Estruturou mais de 50 projetos de posicionamento para grandes empresas do Brasil, incluindo os segmentos bancário, trade marketing, agrotech, fundos de investimentos, healthtech, retail, cloud e documentos eletrônicos.

 


Report publication
    010

    Recomended for you