Vous êtes sur la page 1sur 6

5 fatores de sucesso para enfrentar os problemas de integrações

na automação de processos
Carlos Eduardo Mortari - 4 de julho de 2018
(1) Comentário
Tendo participado de vários de projetos de automação de processos, se tem algo que podemos
afirmar como sendo um denominador comum a projetos de automação em empresas das mais
diferentes áreas, é dos problemas que surgem quando existe necessidade de integração do processo
automatizado com outros sistemas/organizações.

O fato é que problemas relacionados a integrações invariavelmente vão ocorrer, apenas variando de
acordo com o grau de complexidade do processo e das integrações em si. Por outro lado, existem
sim alguns fatores e cuidados que podem evitar problemas ou facilitar a sua resolução.
Ter conhecimento destes fatores no projeto vai prepará-lo melhor para o que vem pela frente.

Vamos a eles?

1. Ter uma boa governança dos serviços/integrações/funcionalidades disponíveis


Durante a automação do processo, é comum detectar uma ou mais necessidades de integração (ex:
salvar alguma informação digitada durante a execução do processo num banco de dados).

Em nossa experiência, boa parte dos problemas que ocorrem nestes casos se devem a falta de
governança da organização em relação aos serviços, integrações e sistemas existentes, ou seja, não
se sabe se aquela necessidade de integração do processo já se encontra disponível (ex: através de
um webservice).
A consequência disso é a necessidade de se discutir do zero esta integração, fazer orçamento e
incluí-la no escopo, o que leva a aumento do prazo e custo do projeto. Um fator que minimiza
bastante estes problemas é se a organização já trabalha numa Arquitetura Orientada a Serviços, ou
simplesmente SOA (mais informações aqui, aqui e aqui), bem como dispor de ferramentas de
governança/pesquisa de serviços.
2. Prever o modelo de dados do processo adequado as necessidades de integração
Quando um processo será automatizado, deve-se previamente fazer uma análise para definir o
“modelo de dados” do processo, ou seja, as informações que serão visualizadas e manipuladas ao
longo da execução do processo (veja aqui para mais informações).
A definição deste modelo de dados costuma ser mais transparente quando estamos falando de
informações que ficam visíveis no formulário eletrônico do processo, ou seja, as informações que os
usuários vão visualizar/editar ao acessar as tarefas. Mas infelizmente não é tão óbvio quando
falamos de integrações.

Por exemplo, se é necessário chamar uma integração para atualizar uma informação no ERP a partir
do processo automatizado, pode se descobrir que uma das informações obrigatórias para se chamar
esta integração é específica daquele sistema (ex: um determinado identificador), e esta informação
não foi prevista inicialmente no modelo de dados.

Com frequência, inclusive, ocorre a situação de que para obter a informação que você precisa para
chamar uma integração, é necessário chamar outra integração!

Este fator costuma gerar muitas dores de cabeça, em muitos casos não é fácil prever todas as
possibilidades.

3. Ter conhecimento das funcionalidades e limitações do framework de integração do BPMS


Mesmo que inicialmente a empresa tenha adquirido uma solução de BPMS para um processo
pontual ou para apenas gerenciar fluxo de trabalho sem integrações com outros sistemas, o fato é que
as necessidades da organização mudam. Quando chegar o momento em que as iniciativas de
automação de processos passarem a demandar mais inteligência, com integração de dados existentes
em outros sistemas, é importante conhecer as funcionalidades e limitações de integração do BPMS.

Por exemplo, alguns questionamentos comuns nestes casos:

 Posso chamar webservices através do BPMS?


 Consigo conectar diretamente num banco de dados através do BPMS?
 Existem adaptadores nativos que permitem conexões com sistemas conhecidos no mercado?
 O BPMS me permite realizar transformações complexas de dados ao chamar ou obter o
retorno de um webservice?
 Existe algum formato específico de assinatura do serviço para poder ser acionado?
 Com que tecnologias o BPMS permite fazer integração? Soap? Rest? Corba? EJB? .net?
Controle de arquivos no filesystem? Outros?
Este conhecimento é importante para detectar eventuais restrições da ferramenta, identificar a
necessidade de utilizar outras ferramentas em conjunto ao BPMS, ou no pior dos cenários até a troca
do próprio BPMS. Por exemplo: se o BPMS não é capaz de fazer transformações de dados
complexas ao chamar um webservice, então possivelmente será necessária outra ferramenta (ex: uma
ferramenta de barramento de serviços) que fará esta transformação no lugar do BPMS, expondo para
o BPMS uma versão simplificada do serviço. Neste mesmo exemplo, pode ser que esta ferramenta
adicional não exista na organização, e precisa ser previsto a sua contratação e implantação, dentro do
escopo do projeto de automação.
Entenda a importância de uma avaliação detalhada sobre recursos dos produtos ao adquirir uma
plataforma BPMS com esta coleção de artigos sobre Seleção de Plataformas de BPM.
4. Equipes dos sistemas disponíveis para apoiar o projeto
Parece chover no molhado, afinal se um processo automatizado precisa se comunicar com o sistema
X, então a equipe de apoio deste sistema tem que estar envolvida, certo? Bem, temos algumas
histórias de iniciativas de automação de processos aprovadas em nível executivo, mas que durante o
andamento do projeto as equipes dos sistemas estavam em uma das seguintes condições:
 Não estavam sabendo do projeto – o popular “cair de paraquedas” (sim, é comum);
 Sabiam do projeto e que em algum momento iriam se envolver, mas não tinham nenhum
contexto dos objetivos do projeto e o seu papel (tem na prática os mesmos efeitos nocivos da
situação anterior);
 Sabiam do projeto e tinham o contexto, mas não tiveram a alocação reservada para apoiar o
projeto (“Eu conheço o projeto e entendo o que devo fazer, mas não sei se vou conseguir
ajudá-los ainda neste mês…”).
Quando as equipes dos sistemas começam a se envolver no projeto, é comum surgirem problemas e
limitações que não se tinha noção, o que pode ocasionar necessidade de se rediscutir a solução. Aqui
o apoio da liderança executiva e da gestão de projetos é fundamental para minimizar os problemas,
reforçando a alocação das equipes dos sistemas envolvidos, para se envolverem no projeto de
automação o quanto antes, preferencialmente ainda durante as fases de análise e projeto.
5. Atenção à etapa de testes
Se existem integrações no processo, obviamente as mesmas precisam ser bem testadas, envolvendo
as equipes responsáveis pelos sistemas de origem/destino das informações.
Ocorre que na automação de processos, assim como no desenvolvimento tradicional de sistemas,
pode ocorrer a tendência de dar ênfase maior apenas a “interface” do processo, que no caso do
BPMS são os formulários das atividades enviadas para os usuários. Mas obviamente as integrações
que são feitas automaticamente pelo processo devem ser testadas com o mesmo cuidado, verificando
se estão retornando ou gravando as informações corretamente.

Isto comumente é realizado utilizando os recursos de rastreamento/auditoria presentes das próprias


ferramentas de BPMS (verificando o que está recebendo ou enviando de informações), bem como
acessando diretamente o sistema com o qual se tem a integração (para verificar se os dados sendo
obtidos/atualizados pelo BPMS estão corretos).

Estas verificações normalmente exigem um conhecimento técnico maior (ex: visualizar payloads em
XML, acessar as informações diretamente em tabelas do banco de dados do sistema em questão,
etc).

Sem dúvida existem outros fatores envolvidos, mas acreditamos que os


fatores citados acima dão um bom norte para a equipe do projeto se preparar e enfrentar os
problemas que podem ocorrer nas integrações durante a automação de processos.