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

No primeiro post (disponível aqui), iniciamos uma avaliação de particularidades da gestão e execução de projetos envolvendo integrações, com foco nas dependências técnicas e gerenciais.

Hoje, a ideia é “conversarmos” sobre algumas práticas metodológicas importantes para minimizar riscos e conduzir o trabalho de maneira organizada.

Apesar de podermos citar um grande número de práticas, algumas são especialmente relevantes para o sucesso deste tipo de projeto, a saber:

  • Definição de uma arquitetura do projeto. O básico do básico, mas por vezes esquecido. É fundamental definir uma arquitetura de comunicação, tecnologias a serem utilizadas e padrões de implementação no projeto, especialmente para as integrações. Outro ponto muitas vezes negligenciado – não adianta ter, tem que comunicar. Se for necessário, imprima a arquitetura e cole no monitor dos integrantes da equipe. Cada um precisa ter a arquitetura na cabeça, sem exceções. Criar uma página tipo wiki também pode ser simples e eficiente.
  • Implementação de mocks na etapa inicial de desenvolvimento ou arquitetura. Como citado no primeiro post, a definição e construção de mocks é uma prática que facilita a formalização da comunicação entre os componentes do sistema (principalmente quando estes estão divididos entre vários fornecedores) e auxilia o paralelismo de atividades. Uma outra avaliação é bastante importante – o comportamento interno do mock. Se por um lado um artefato que simplesmente devolve “vazio” é fácil e rápido de implementar, por outro ele não auxilia os testes unitários, por exemplo. Se implementarmos algumas regras, os testes unitários podem ser mais efetivos, mas é um trabalho que posteriormente será descartado. Assim, é fundamental avaliar qual a complexidade e conteúdo dos mocks a ser desenvolvido para cada caso e requisitos do projeto.
  • Testes unitários com componentes já desenvolvidos. Conforme o segundo item, a validação das regras de negócio das integrações não depende apenas das interfaces (assinaturas, contratos, etc) dos componentes chamados por estas, e sim principalmente de sua implementação interna. Desta forma, assim que possível é importante a substituição dos mocks pelos componentes definitivos, o que já ajuda, e muito, na avaliação de eventuais problemas de integração dos dados e até de análise. Porém, um alerta. Caso os componentes ainda estejam em uma fase incipiente de desenvolvimento, podem conter bugs que mais prejudicarão do que ajudarão durante a implementação das integrações. Assim, é necessário avaliar a qualidade dos componentes das “pontas” quando estes forem usados.
    • Revisão periódica de serviços ou componentes que vão ficando prontos. Item relacionado ao tópico anterior. Defina um meio de acompanhar e comunicar quais componentes das “pontas” da integração (serviços que serão chamados, por exemplo) estão prontos e disponíveis para uso no decorrer do projeto. É bastante comum esquecermos disto por vários dias e perdermos a oportunidade de aproveitar os ganhos do tópico acima.
  • Teste de arquitetura com “integração piloto”. Uma prática que resolve várias dores de cabeça e antecipa problemas do desenvolvimento é validar a arquitetura definida para o desenvolvimento das integrações com a implementação de uma “integração piloto”. Aproveite este momento para questionar e validar as diretrizes arquiteturais para o restante do projeto. Claro, nem sempre isto é simples, visto que muitos projetos incluem integrações com “n” formas de implementação e utilização de recursos. Mas, na medida do possível, é uma prática muito vantajosa.
  • Mapa de dependências entre componentes. Prática simples e muito útil. Organize um mapa com todos os componentes do projeto e quem depende de quem. Não use textos – faça o mapa de forma gráfica. Aí temos uma vasta gama de ferramentas que podem ser usadas – aplicativos de mind mapping, de desenho, de modelagem, etc. E use a criatividade. Pinte componentes de cada tecnologia com uma cor diferente, separe-os por equipe responsável, por desenvolvedor, e assim por diante.
  • Repositório único de contratos. É realmente muito importante definir um repositório que armazene a versão oficial de contratos de serviços e demais componentes que são dependência para outros no projeto. Assim, todas as equipes sabem onde consultar a versão a ser utilizada, evitando ruídos de comunicação. Claro, se alguma alteração é feita, deve ser comunicada a todos – e isto deve estar contemplado no Plano de Comunicação do projeto. Este repositório deve estar sempre atualizado.
  • Organizar a análise e desenvolvimento das integrações por assunto. É bastante comum em projetos envolvendo integrações que estas estejam separadas por assuntos de negócio tratados pelo sistema. Por exemplo: ao desenvolver integrações de um ERP com sistemas legados, organizar os profissionais que vão analisar e implementar as integrações por cada módulo do ERP. Nem sempre isto é possível – alguns processos são transversais e passam por vários módulos – mas claramente auxilia o entendimento das integrações pelo conhecimento de negócio que cada profissional adquire. Claro, isto incide em alguns riscos bastante relevantes. Se um profissional, seja analista ou desenvolvedor, sai da equipe, um grande conhecimento pode ir com ele. Uma forma de contornar isto é envolver o líder técnico e um analista líder em pontos-chave da análise e desenvolvimento de todas as integrações, a fim de que possa responder pelo conhecimento destas.
  • Definição de cenários de testes entre as equipes. Um ponto chave do projeto, difícil de gerenciar e que frequentemente enfrenta grandes problemas, é o teste integrado do sistema, principalmente quando existem diferentes equipes envolvidas. Uma sugestão muito interessante é a reunião dos responsáveis das equipes para elaboração de cenários de teste integrados. Veja, a ideia não é detalhar cada cenário neste momento, e sim definir quais são os cenários a serem executados para validar a integração dos sistemas de ponta a ponta. Após, cada equipe detalha seus cenários individualmente, que são validados ao final, novamente entre todos.

No próximo post, que encerra esta série, trataremos de riscos e pontos de atenção em projetos com integrações, visando auxiliar principalmente seu planejamento e gestão. Até lá!

Benefícios da Automatização de Processos – Automatização de Atividades

Já discutimos os objetivos e Benefícios da Automação de Processos. Conversamos também sobre se vale a pena automatizar todo e qualquer processo neste estudo de caso e o que é preciso levar em conta ao tomar a decisão.

Hoje, no entanto, vamos – através de casos práticos onde isso foi utilizado – nos aprofundar um pouco mais sobre aquele que é, talvez, o benefício da automatização de processos mais evidente de todos: A Automatização de Atividades em processos automatizados com a ajuda de um BPMS.

As candidatas ideais são aquelas atividades onde a interação humana agrega pouco valor à realização da tarefa. Vejam, por exemplo, os casos abaixo:

  • Integração com Sistemas Legados:
Incluir Dados de Nova Vaga

Suprocesso de Aprovação de Abertura de Nova Vaga.

A atividade representada aqui é parte de um subprocesso onde todos os envolvidos aprovaram a criação de uma nova vaga para contratação pela organização. Deste modo, resta apenas a atividade de incluir a vaga solicitada no sistema de recrutamento e seleção.

No nosso exemplo, é o processo que irá transferir, automaticamente, ao sistema legado, todas as informações da vaga. E é aqui que temos claro o benefício da automatização desta atividade: as características da vaga já estão todas incluídas e formalizadas no processo, tendo sido avaliadas pela Direção e Departamento de RH; não há a necessidade de um colaborador realizar o cadastro manualmente, proporcionando ganho de produtividade e redução do tempo necessário para conclusão do processo. Mais do que isso, evitam-se erros na transposição de quaisquer um dos dados relativos à vaga.

  • Identificação de aprovadores ou hierarquia de aprovação
Subprocesso de Aprovação de Crédito

Subprocesso de Aprovação de Crédito

No subprocesso representado acima, a busca por um novo aprovador é automatizada. Ou seja, quaisquer regras que existam para determinar quem deve ser o próximo a aprovar o crédito (e até mesmo se é necessária outra aprovação) podem ser automatizadas buscando a informação em um cadastro existente na empresa. Não é preciso que um colaborador seja responsável pela tarefa de identificar o próximo aprovador.

  • Mudança de fluxo do processo
Identifica Vaga

Supprocesso de Aprovação de Abertura de Nova Vaga

Em um processo de negócio, torna-se bastante trabalhoso que as diferentes pessoas responsáveis por atividades chave tenham de determinar a quem dirigir o resultado do seu trabalho. A automatização destas tarefas podem evitar a existência de papéis cuja única responsabilidade é o roteamento da informação e, também, protegendo a organização dos possíveis erros e atrasos por um direcionamento inadequado.

Calcular Custo da Viagem

Subprocesso de Aprovação de Solicitação de Viagem

No fluxo acima, o processo foi automatizado para identificar o custo total de uma Solicitação de Viagem e, por consequência, realizar ações diferentes de acordo com uma regra. Em casos como este, é totalmente desnecessário que um colaborador realize tarefas que podem ser integralmente automatizadas, executando-as com maior eficiência e rapidez.

De modo geral, ao decidir por automatizar atividades, é preciso encontrar aquelas que estão perfeitamente definidas e/ou são repetitivas o suficiente. Sem a intervenção humana, pode-se reduzir drasticamente os tempos necessários, custos e erros.

No entanto, sem a tecnologia adequada ou se realizado de forma incorreta, podemos ter casos onde a automatização é muito complexa, resultando em custos mais altos e menor flexibilidade e adaptabilidade às mudanças. É preciso, portanto, perguntar-se que atividades devem ser automatizadas e não somente quais podem se tornar automáticas, além de encontrar sempre os meios de menor custo possível para essa automatização.

BPMS: como as etapas do ciclo BPM geram segurança no processo automatizado

A automatização de processos através de BPMS (Business Process Management Suites) tem sido frequentemente adotada nas organizações num esforço para otimizar seus processos. No post Benefícios da Automação de Processos do nosso blog, já discutimos os principais benefícios intrínsecos à automatização de processos.

Neste post, iremos falar de uma situação recorrente no mercado em projetos de automatização de processos: a automatização que é feita sem uma etapa de análise e redesenho e processos efetuada previamente.

Idealmente, em qualquer projeto de implementação de BPM, o ciclo BPM a ser seguido inclui a análise (AS IS) e o redesenho (TO BE) dos processos, antes de seguir para a etapa de implementação (TO DO). Desta forma, garante-se que o cenário atual do processo na organização foi adequadamente estudado, e todas as necessidades de melhoria no processo foram devidamente contempladas. Porém, é comum encontrar empresas que investem em projetos que simplesmente “pulam” as etapas de análise e redesenho, seguindo diretamente para a etapa de implementação.

Na maioria das vezes em que isso ocorre, tratam-se de processos de negócio razoavelmente definidos que estão sendo ativamente executados dentro da organização. Para estes processos são identificadas necessidades de melhoria, e aqui está o grande diferencial em relação a um processo que está passando por um ciclo típico de BPM: as necessidades de melhoria identificadas, ao menos na percepção dos responsáveis por aquele processo, estão relacionadas diretamente aos sistemas que apoiam a execução do processo. Ou seja, em tese os processos estão bem definidos, mas não estão sendo apoiados adequadamente por um sistema. Abaixo alguns dos motivos mais frequentes que levam a automatização direta dos processos:

-O processo é executado em papel, que é um dos casos mais comuns. Com a automatização, busca-se então substituir os formulários em papel por formulários eletrônicos melhorando o fluxo e o gerenciamento da informação;

-O processo é executado com suporte de sistemas, porém são diversos sistemas que precisam ser utilizados. Isto força os usuários a precisar alternar entre os sistemas para executar o processo. Com a automatização, busca-se a integração destes sistemas de maneira automática, passando até mesmo pela criação de um front-end único para a execução do processo pelos usuários (desta forma desativando alguns ou todos os sistemas existentes);

-O processo é executado com suporte de sistemas, porém em diversos pontos os usuários são requisitados a manter documentos/planilhas em repositórios na rede da organização, dificultado a manutenção e auditoria dos mesmos. Com a automatização, busca-se a integração automática destes documentos ao BPMS, controlando o seu ciclo de vida, utilizando o repositório nativo do BPMS ou uma solução de ECM (Enterprise Content Management).

Embora “economize” etapas (e consequentemente custos) do ciclo BPM, a abordagem de automatizar o processo diretamente tem seus riscos. O mais intangível, e não menos importante, é o desperdício de oportunidade: não aproveitar que está sendo direcionado tempo e recursos para melhorar o processo pode prover uma visão míope do mesmo durante a análise para automação, focando única e exclusivamente nas necessidades de sistema. Desta forma, corre-se o risco de deixar passar outras oportunidades de melhoria importantes e impactantes para o processo como um todo.

Outro risco bastante frequente desta abordagem é a possibilidade de “automatizar o erro”, ou seja, pegar um processo que não está bem documentado (conhecimento na cabeça das pessoas), pouco otimizado, por vezes definido incorretamente, com várias lacunas e desperdícios, e simplesmente automatizá-lo. Neste caso, a automatização de processos está longe de ser a solução mágica para todos os problemas: ao se automatizar um processo com erros, o que normalmente se obterá é… um processo com erros automatizado. :-)

Esta situação é muitas vezes alimentada por uma necessidade de provar a tecnologia dentro da organização. Como a aquisição de um BPMS por si não soluciona o problema – é necessário implementar a automatização do processo para que então o produto se faça provar como bom investimento para a empresa, o projeto acaba sendo “um piloto, mas que vai à produção”. A estratégia é arriscada e o tiro pode sair pela culatra: se o processo com problemas for automatizado as is, as falhas continuarão existindo e poderão ser potencializadas, gerando rejeição do uso do sistema pelos participantes do processo e outros resultados insatisfatórios, que poderão desacreditar a adoção do BPMS como solução.

É como construir uma casa sem um projeto arquitetônico, em que se possa analisar a ideia do imóvel e planejar melhorias antes de começar a levantar as primeiras paredes. Pode ser rápido, e pode dar certo, mas as chances de desperdiçar material e chegar ao final com um resultado insatisfatório são bastante elevadas.

O caminho mais seguro é investir em um ciclo completo, porém em partes, gerando quick wins e demonstrando que a gestão por processos com apoio de um bom BPMS pode resultar em excelente retorno para o investimento da organização.