Fale sobre soluções, não sobre ferramentas
Tenho trabalhado nos últimos anos com alguns conceitos como SOA e BPM e desde então sempre tive a preocupação de estudar, pesquisar e me informar sobre esses assuntos. Entender os conceitos, o que está por trás, quando usar, acompanhar casos reais, a evolução, enfim, entender verdadeiramente os fundamentos de BPM e SOA.
Infelizmente, vejo que no mercado, pelo menos o nacional, as coisas não funcionam dessa maneira, onde a maioria dos profissionais estão preocupados muito mais com ferramentas do que com soluções, o que é muito preocupante, pois esse é o fator principal, no meu modo de ver, que faz a adoção de BPM e SOA quase sempre serem associadas ao insucesso dos projetos.
Recentemente, tive mais uma prova disso, onde participando de um treinamento em cima de uma ferramenta de BPM (BPMS) observei que os participantes estavam muito mais preocupados em entender a ferramenta, o que tem de novo, como fazer tal coisa, do que pensar no porque elas precisam daquela ferramenta e de todos aqueles recursos maravilhosos. Ouvi algumas coisas realmente impressionantes como “Fulano trabalha com SOA, desde que SOA chegou no Brasil”. Ahn?! Como assim?! SOA é um produto? É um software de caixinha para ter chegado no Brasil? Isso é realmente preocupante.
Os grande players vendedores dessas soluções, como Oracle, IBM, SAP, TIBCO, etc.. tem uma parcela de culpa nisso, pois vendem (e como é fácil vender!) as suas ferramentas como as novas maravilhas do mundo moderno, mas não explicam o principal: para usar SOA e BPM as organizações precisam mudar a sua maneira de pensar, a maneira de enxergar os seus negócios, pois sem isso, pode ser com a ferramenta que for, qualquer projeto estará fadado ao fracasso. E afirmo isso sem exagero algum. Já temos muitos casos no Brasil que comprovam isso, afinal, qual case de SOA ou BPM é realmente um exemplo por aqui? Dos que já tive a oportunidade de ver no Gartner, acho que não vi nenhum no Brasil.
Mas é óbvio que nós, profissionais do meio, somos os maiores culpados. Como profissionais, temos o dever de estudar e entender tudo que está por trás de SOA e BPM, precisamos ter claro na nossa cabeça, que ferramentas são apenas um dos meios para para viabilizar estratégias de SOA e BPM, mas não devem ser o fim. É perfeitamente possível, por exemplo, ter um projeto BPM de sucesso sem que necessariamente haja um BPMS envolvido.
Não quero dizer com tudo isso, que as ferramentas são desnecessárias, óbvio que não, muitas delas são úteis, bem úteis por sinal. Um BPMS é um grande aliado para modelagem de processos, simulação a partir de métricas e indicadores e monitoramento. Assim como um Service Bus, é necessário para um catálogo de serviços bem definido, para ajudar na questão de governança e para implementar padrões de integração (EAI patterns). Mas ferramentas são, mais uma vez, um meio de se conseguir implementar um bom projeto de BPM e SOA e não o fim, esse é o grande ponto chave.
Hoje, muito dos profissionais que trabalham com BPM por exemplo, não tem a menor noção do que é um ciclo de vida de um projeto BPM, o que é AS IS e TO BE, o que são KPI’s e o pior: não estão nem um pouco alinhados com o negócio das organizações. Por sua vez, as organizações gastam milhões e milhões nessas ferramentas caríssimas e não tem uma pessoa (ou um escritório) responsável pelos processos, além não terem pessoas que entendem do próprio negócio da empresa trabalhando nesses projetos. SOA e BPM tem tudo haver com negócio, não com software!
E no final, aquela velha pergunta sobre o ROI, fica sem resposta. O que de processos foi construído que realmente agrega valor ao negócio? O que foi melhorado na rotina dos funcionários da empresa? O que foi otimizado no dia-a-dia daquele usuário? Qual era o resultado esperado e qual foi o obtido? Nenhuma dessas perguntas tem resposta!
BPMS oferecem recursos interessantíssimos como papéis, onde os analistas de negócio deveriam implementar e desenhar seus processos e os desenvolvedores apenas implementar o que deve ser automatizado em cima até de uma arquitetura orientada a serviços (SOA). Mas o que vemos, na maioria dos casos por aí, são organizações usando um BPMS como um meio de se construir software e não como uma maneira de fazer o famoso (e sonhado) alinhamento entre negócio e TI, não como uma maneira de gerar valor ao negócio.
Da mesma maneira, empresas que usam SOA, sabem muito pouco sobre design de serviços, quase nada sobre governança e não utilizam um dos principais conceitos de SOA que é a composição de serviços para gerar resultados mais rápidos de acordo com a demanda e a rapidez do seu negócio.
SOA, assim como BPM, virou apenas uma maneira mais corporativa de se construir aplicações e fazer software. Só que virou também uma maneira muito mais cara de se fazer isso.
Se você gostou desse tópico, por favor considere deixar um comentário ou se inscreva no feed e tenha no futuro todos os tópicos entregues diretamente no seu agregador.
