Clique aqui para ler a primeira parte deste artigo, caso não o tenha feito ainda

 

Na coluna passada, iniciei uma análise pessoal sobre o futuro do mercado de aplicativos empresariais. A principal conclusão foi a distinção necessária entre “sistemas” e “produtos”: um aplicativo foi caracterizado como “sistema” quando sua customização para implantação nas empresas requer a execução de atividades de programação na mesma linguagem usada no desenvolvimento original do aplicativo.

Observamos que este modelo de negócios, usado igualmente por um número significativo de empresas nacionais de software, assim como por grandes empresas internacionais (como por exemplo, SAP e Siebel), resulta em uma limitação no número de clientes que podem ser atendidos, altos custos de implantação e grandes dificuldades para a realização de “upgrades”.

Propus então que as empresas produtoras de aplicativos, independentemente da origem de seu capital, nacional ou estrangeiro, deveriam apostar no mesmo modelo de negócio usado no software horizontal: nenhum fornecedor de sistemas operacionais, bancos de dados ou software de produtividade pessoal adapta seu código-fonte às necessidades de um usuário específico. Em vez disto, os próprios produtos contêm recursos que permitem aos usuários expressar suas necessidades específicas em uma linguagem de nível mais alto, e a um custo menor (por exemplo, as linguagens de comandos dos sistemas operacionais, ou a linguagem SQL nos bancos de dados).

Um efeito colateral e positivo desta estratégia é a garantia de que a migração dos clientes para as novas versões dos produtos será possível.

A pedido de vários leitores gostaria de detalhar mais algumas características dos aplicativos-produto: se o código-fonte não é modificado para nenhum cliente, então ele também deve ser único no caso de o aplicativo estar disponível em vários idiomas ao mesmo tempo, ou para execução em vários ambientes, ou em uma versão completa e outra de demostração, ou, provavelmente, em todas estas situações juntas! Se estas situações não forem atendidas por um código-fonte único, as dificuldades dos sistemas reaparecem.

É preciso admitir que para viabilizar uma estratégia como esta, o nível de conhecimento técnico da equipe de desenvolvimento precisa ser superior ao dos desenvolvedores de sistemas (talvez seja esta uma das razões pelas quais poucas empresas adotaram esta estratégia).

Outra característica importante para aplicativos projetados como produtos é a disponibilidade de documentação: além de manuais, é necessário dispor de materiais para marketing e material para o treinamento de parceiros, revendas e usuários, entre outros possíveis.

Finalmente, todo produto deve possuir uma tabela de preços. Muitos desenvolvedores de sistemas, nacionais e estrangeiros, tem o hábito de fazer o preço “conforme a cara do freguês”; em outras palavras, o preço é diferente conforme quem está vendendo e quem está comprando. Já no caso de produtos, é preciso ter preços definidos, usados por desenvolvedores e revendedores igualmente, evitando assim o desgaste resultante, por exemplo, de oferecer um mesmo aplicativo a um cliente em potencial por dois preços diferentes.

Pessoalmente, acredito neste modelo de negócios para o software aplicativo ao ponto que, além de apostar o futuro dos aplicativos desenvolvidos pela nossa empresa neste modelo, estamos trabalhando para criar uma rede de empresas de desenvol¬vimento que adotem este modelo.

 

Clique aqui para ler a terceira parte deste artigo