Como manter a aderência ao modelo TO BE na automatização de processos

Num ciclo BPM típico, o processo TO-BE é desenhado em conjunto com a área de negócios.  A partir daí, de acordo com um conjunto de critérios e avaliações, pode-se optar por seguir o ciclo e efetuar a automatização deste processo numa ferramenta de BPMS.

Durante a implementação e testes de processos automatizados, um dos questionamentos mais recorrentes dos usuários de negócio é de como o fluxo do processo automatizado ficou diferente da visão TO-BE que foi desenhada com a participação deles. Frequentemente existe o questionamento de que o processo automatizado ficou mais “poluido” e com “muitas caixinhas a mais” em relação ao modelo TO-BE original.

Vejamos o processo fictício abaixo, desenhado em um nível mais genérico:

Modelo de Processo TO-BEO que podemos concluir deste processo?

  • Não existe a preocupação em detalhar em nível mais baixo/operacional as atividades, e sim mostrar uma visão de alto nível do processo, para auxiliar na compreensão do mesmo como um todo;
  • Algumas atividades podem estar ocultas, ou podemos ter uma atividade que encapsule outras (caso por exemplo da atividade “Geração e Envio da OC” – possivelmente 2 atividades separadas?);
  • Não está claro se as atividades são de responsabilidade de uma pessoa ou sistema;
  • Não fica claro qual exatamente é o responsável pela atividade, pois a divisão de roles foi feita em nível departamental, e não em papéis/funções (não entrando no mérito se esta seria a melhor abordagem de modelagem).

Este processo cumpre seu papel ao mostrar em um nível mais genérico qual o processo de execução de compras da empresa. Para fins de automação, no entanto, este processo não está no nível adequado. É necessário então um trabalho de levantamento no detalhe da execução deste processo, definindo todas as atividades, responsáveis, regras de negócio, automações, etc.

Vamos agora analisar o mesmo processo anterior, mas desenhado em um nível mais analítico, já em preparação para a automação:

Modelo de Processo TO-DOPodemos notar uma série de diferenças em relação ao processo anterior:

  • Atividades que na visão TO-BE eram uma só, agora foram separadas em atividades diferentes (atividades “Geração da OC” e “Envio OC fornecedor”). Percebam que o contrário também pode ser verdadeiro, ou seja: 2 ou mais atividades no modelo TO-BE podem virar apenas uma atividade no modelo automatizado;
  • O nível de granularidade do processo mudou: em vez de lanes em nível departamental, agora temos exatamente qual o papel/função que executa cada atividade;
  • Utilizando elementos visuais, foi especificado qual o tipo de cada tarefa (humana, automática, email);
  • Foi estabelecido um controle de tempo de execução das atividades, e envio de alertas por email caso as atividades não sejam executadas no seu prazo.

Assim, um processo que no nível TO-BE tinha apenas 3 atividades, virou um processo automatizado com 11 atividades. De certa forma, é fácil entender a perplexidade dos usuários, não?

Vamos tentar entender os motivos porque isso acontece. Durante o detalhamento do processo em preparação a automação, uma série de regras de negócio e de execução do processo são definidas, regras estas que não estavam visíveis no desenho do processo TO-BE. Isso acaba gerando necessidades adicionais na modelagem do processo automatizado, como por exemplo:

  • Buscar dados de apoio numa base de dados, para exibição nas atividades do processo;
  • Fazer transformação de dados entre atividades;
  • Buscar valores de parametrização utilizados pelo processo em sistemas de Back-Office;
  • Invocar procedimentos ou serviços específicos relacionados a regras do processo (ex: serviço institucional para calcular o prazo de uma atividade);
  • Etc.

A “multiplicação” de atividades no modelo automatizado em relação ao modelo TO-BE está ligado, principalmente, aos seguintes fatores:

  • Nível de detalhamento do modelo TO-BE. Em linhas gerais, quanto mais detalhado um modelo TO-BE, maiores são as chances do modelo automatizado ficar semelhante;
  • Recursos e possibilidades de automação da ferramenta de BPMS. Por exemplo, se a ferramenta de BPMS oferece mecanismos nativos para alertas por email, que estejam embutidas na própria configuração das atividades humanas, todas as atividades de alerta que temos no exemplo acima não seriam necessárias, como por exemplo a atividade “Alerta para enviar OC”.
  • O diagrama TO-BE que foi modelado numa ferramenta, mas implementado em uma ferramenta diferente, pode fazer com que uma tarefa que havia sido modelada de uma determinada forma tenha que ser, por restrições e características técnicas do BPMS, implementada de forma diferente.
  • perspectiva sob a qual o processo é modelado. Se o processo TO BE foi modelado unicamente sob a perspectiva de negócio (em que o controle do processo é executado por pessoas), ou se ele foi modelado já sob a perspectiva da automatização (em que o controle do processo é realizado pelo BPMS).

Percebemos, no mercado de ferramentas de BPMS, que existe um movimento no sentido de deixar a transição do modelo TO-BE para o modelo automatizado um pouco mais suave. Na última versão do Oracle BPM 11g, por exemplo, apenas 3 tipos de atividades (humana, serviço e regra de negócio) serão exibidas por padrão na trilha de auditoria dos processos, ocultando outras atividades mais técnicas (ex: adapters, scripts) que possam estar sendo utilizadas.

Podemos ver que não existe uma solução ou resposta simples para esta questão, em virtude da quantidade de fatores envolvidos que podem gerar esta diferença dos processos TO-BE em relação aos processos automatizados.

Uma forma de minimizar este impacto é que a equipe de tecnologia (analista de sistemas) se envolva no redesenho do processo, analisando juntamente com a área de negócio as melhorias tanto sob o aspecto de negócio quanto sob o aspecto tecnológico, de forma que o analista de sistemas traga para o TO BE a perspectiva do processo automatizado.

Avaliando o real custo-benefício de BPMS livres ou de baixo custo

No nosso último post falamos sobre os motivos que tornam a escolha de uma plataforma de BPMS tão difícil (veja aqui).

Aprofundando a questão da seleção de plataformas, um equívoco muito comum está no fato dos profissionais acreditarem que soluções de BPMS livres ou de baixo custo são sempre mais baratas do que as ferramentas pagas. Por vários fatores que veremos a seguir esta premissa nem sempre é verdadeira, sendo fundamental que os seguintes fatores sejam analisados:

  1. Investimento total na ferramenta no longo prazo: Nem sempre o custo de licenciamento é o maior custo na aquisição de uma solução BPMS, principalmente quando visto a médio ou longo prazo. Muitas vezes, o custo de um contrato de suporte e manutenção de uma ferramenta gratuíta é significativamente maior ao final de 3 ou 5 anos do que a soma dos custos de licenciamento e contrato de manutenção de outras ferramentas, de modo que este custo não pode ser analisado somente no primeiro ano.
  2. Requisitos disponibilizados pela ferramenta: Para evitar que o barato saia caro, analise o quanto a solução escolhida é aderente às necessidades da sua empresa. Caso existam requisitos obrigatórios ou opcionais que ela não atenda, verifique qual será o impacto da solução escolhida não ter estas funcionalidades.
  3. Benefícios (reais) de uma solução Open Source: A escolha de uma solução open source (quando o fabricante disponibiliza o acesso ao código fonte do produto) nem sempre traz o benefício esperado pela organização. Via de regra, fornecedores que dão suporte e manutenção às suas ferramentas não permitem, durante o período de vigência do contrato, que seus clientes alterem o seu código fonte, pois isso inviabilizaria o contrato de suporte.
  4. Características do suporte oferecido pelo fabricante: É fundamental verificar como é o nível de suporte fornecido pelo fabricante: Questões como a existência de suporte no país, a língua em que é prestado o atendimento, a possibilidade de se obter um atendimento no local, a disponibilidade 24×7, a existência ou não de um limite de abertura de chamados e o tempo de atendimento à produção devem ser analisados de modo a verificar se o suporte irá atender às expectativas.
  5. Existência de mão de obra qualificada: Uma ferramenta de BPMS, por si só, é uma caixa vazia: não tem nenhuma utilidade enquanto os processos não forem desenvolvidos. Assim, a disponibilidade de mão de obra capacitada para realizar este desenvolvimento torna-se um fator crucial.
  6. Esforço para a formação de um profissional apto a operar com a plataforma: Uma alternativa para uma eventual falta de mão de obra qualificada é a organização investir na formação de pessoal capacitado. Aqui, torna-se fundamental avaliar qual a complexidade desta formação: Quais os pré-requisitos mínimos de conhecimento de um profissional que venha a se capacitar? Como é a qualidade do material de capacitação fornecido pelo fornecedor? Existem instrutores disponíveis para realizar esta formação? Ou existe uma material de auto-estudo que permita esta capacitação? O quão rico é este material?
  7. Verifique o custo da mão de obra especializada: De nada adianta a organização economizar em licenciamento e gastar muito mais a cada projeto de automação que for realizar. Desta forma, é importante que se avalie qual o custo da mão de obra especializada em operar a ferramenta de BPM.
  8. Qual a produtividade oferecida pela plataforma: Finalmente, a produtividade também é um fator essencial na análise de custo entre plataformas distintas. Semelhante à questão do custo da mão de obra, uma plataforma que render uma produtividade significativamente superior às outras pode ter o seu custo de licenciamento pago rapidamente ao final de um primeiro ou segundo projeto de automação.

Particularidades na execução de projetos com integrações – Parte 1

Projetos envolvendo integrações, sejam elas o escopo completo ou apenas parte dele, possuem uma série de particularidades, do planejamento e gestão às mais específicas decisões técnicas.

Integrações são, em muitos casos, o calcanhar de aquiles dos projetos. Não apenas quando falamos dos pontos de contato entre dois ou mais sistemas, ou em projetos de orquestração de serviços (SOA), mas também quando temos equipes com entregas específicas, eventualmente falando idiomas diferentes, em locais distantes, com culturas distintas… mas que em determinado momento precisam literalmente juntar todo o código-fonte do projeto e fazê-lo “conversar” harmoniosamente. Dados devem ser transportados e transformados de acordo com as regras, formatos e tipos especificados. Um sistema deve entender o outro como se tivessem nascido juntos, filhos do mesmo pai. E o mais importante: os usuários devem ter a segurança de que as informações que compartilharam estão íntegras e disponíveis a todos os interessados, no tempo certo, no formato esperado.

Diante de tudo isto, gostaria de compartilhar, nesta série de artigos, idéias sobre gestão e execução de projetos com integrações. Na verdade, o principal objetivo aqui é levantar dúvidas. Sim, isto mesmo. Estes projetos em especial possuem, é claro, premissas, características, desafios e problemas comuns. Entretanto, cada um possui variáveis internas e de ambiente que tornam a avaliação e solução destes itens particular para cada caso. A simples discussão sobre estes pontos, bem como a citação de exemplos e experiências, faz com que nos forcemos a perguntar no início e no decorrer do projeto:

– Estou controlando adequadamente minhas dependências?

– Onde está o contrato das entradas e saídas dos dados deste sistema?

– Estou realmente comunicando a todos os interessados as informações necessárias?

Nesta primeira parte será abordado um tema que não inicia nem termina o projeto, mas que é crítico para sua execução: o controle de dependências técnicas e gerenciais.

Quando falamos de dependências, nos referimos a qualquer item, seja técnico, metodológico ou gerencial, que é gerado por um participante do projeto e que é insumo ou referência para outro. Exemplos? Temos vários:

  • Serviços ou APIs que precisam ser implementados (às vezes, eles até existem, mas precisam ser encontrados!).
  • Informações que devem ser buscadas com algum usuário e que será base para análise de negócio de algum ponto do sistema.
  • Documentações de produto que precisam ser repassadas, para viabilizar o desenvolvimento.
  • Profissionais com conhecimento em sistemas que devem ser integrados.
  • Disponibilidade do fabricante de produtos para repasse de conhecimento.

E assim por diante…

Integrações possuem um cenário padrão: temos uma origem, um destino e a integração em si, que pode ser implementada em inúmeros níveis de complexidade. Mas é nas duas “pontas” que residem os principais problemas com dependências.

Apesar de óbvia, a primeira preocupação nem sempre é lembrada: as dependências devem ser PLANEJADAS. Nesta etapa, alguns pontos parecem particularmente críticos:

  • Disponibilidade de recursos – Os responsáveis por fornecer as informações referentes a cada origem e destino de dados devem estar disponíveis no momento planejado para suas participações. Porém, geralmente são profissionais que não estarão disponíveis em tempo integral, provavelmente dividindo seu tempo de trabalho com as demandas de projeto. Assim, é importante antecipar suas necessidades.
  • Documentações de sistemas – Muitas vezes a análise pode ser muito facilitada a partir da disponibilização antecipada de documentações de sistemas ou suas camadas de integração já desenvolvidas. Com isto, diminuem-se também os riscos do projeto associados ao entendimento das origens e destinos de dados envolvidos nas integrações.
  • Participação de fabricantes de produtos – É comum a implementação integrações entre sistemas com fornecedores localizados fisicamente em regiões distantes da sede do projeto. Por vezes, o fabricante nem existe mais! Desta forma, é fundamental antecipar a participação deste stakeholder, a qual possivelmente envolverá custo e pode impactar significativamente o planejamento do projeto.
  • Definição clara de metodologia, formato de documentação e estrutura de informações da análise das interfaces – A definição de um procedimento e linguagem comuns entre as equipes e envolvidos no projeto auxilia muito a evitar ruídos de comunicação e perda de informações durante a análise das integrações.

Com as dependências identificadas e com planos de ação definidos, começa a execução. Porém, o planejamento em si não garante de forma alguma o sucesso na administração das dependências. Agora, elas precisam ser CONTROLADAS. Isto requer, dentre outras necessidades:

  • Um mecanismo comum de controle – Deve ser possível, mas é muito mais difícil controlar as dependências entre equipes e sistemas através de meios próprios de cada participante do projeto. Um sistema para isto auxilia de maneira bastante prática (um software de controle de issues é uma boa alternativa), mas uma planilha compartilhada e bem organizada já pode, dependendo do caso, resolver. A questão é: é fundamental ter algum mecanismo.
  • Comunicação centralizada, atualizada e disponível a todos – A situação, pendências e problemas de cada dependência deve ser controlada rigidamente, evitando assim complicações posteriores e agilizando a resolução de eventuais problemas.
  • Definição clara e compartilhada de responsabilidades – Um desafio clássico em projetos com integrações é definir de quem é a responsabilidade por levantar uma informação, entregar um artefato, dar um parecer técnico. Parece simples, mas definitivamente não é. E, é claro, não basta definir, tem que compartilhar. Não adianta termos o responsável, se quem precisa dele não o conhece.

Mesmo com todas as preocupações acima, controlar dependências sempre é delicado e trabalhoso. E é muito difícil, senão impossível, definir um processo isento de falhas. Assim, uma outra diretriz pode ser usada em projetos: buscar que as dependências sejam ELIMINADAS – ao menos o maior número possível delas.

Olhando para o desenvolvimento, um exemplo clássico é a utilização de componentes mock (ou fake) para simular o comportamento dos componentes definitivos que serão entregues posteriormente. Com isto, a implementação da integração em si e suas regras de negócio independem das entregas da origem e destino, com um custo geralmente baixo. Estes componentes podem ser implementados com diferentes níveis de simulação das regras de negócios. Podem tanto simular a simples troca de dados quanto ter diferentes retornos e emular as regras reais, dependendo da necessidade de implementação, testes e avaliação de qualidade em cada etapa do projeto.

No aspecto técnico, é claro que isto acarreta a necessidade de controle do “contrato” ou especificação dos componentes que se comunicam com as integrações – mas isto é assunto para mais adiante.

No próximo artigo, abordaremos algumas questões metodológicas que podem ajudar na execução de projetos com integrações, buscando eliminar riscos e controlar o andamento do trabalho. Até lá!