Arquivos Mensais:junho 2012

Benefícios da Automação de Processos

-
(3) Comentários

A automação de processos procura definir e otimizar os processos de negócio para, em seguida, executá-los sobre uma arquitetura de sistemas informatizada. Esta automação não está limitada à mera execução de atividades automáticas por computadores; vai além, mantendo uma ampla intervenção humana e a participação dos diferentes participantes relacionados, como colaboradores, clientes e parceiros.

Um BPMS (Business Process Management System) oferece os seguintes controles de integridade de um processo:

  • A ordem das atividades é mantida e regulada pelo BPMS.
  • A realização das atividades previstas é garantida.
  • Garantia das condições necessárias para encerramento de cada atividade.
  • Controle de cadeias de responsabilidade (alçadas de decisão)
  • Controle de papéis e responsabilidade.

Ao automatizar, garantimos a execução do processo em sua forma, cumprindo-o fielmente da maneira como foi pretendido e eliminando as possibilidades de infringir as regras de integridade do processo, seja por fraude, desconhecimento ou negligência.

O rápido progresso da tecnologia também pode ajudar a economizar tempo e a dirimir os problemas da distância. Se em outros tempos essas eram barreiras à execução de um trabalho, isto já não é mais verdade. Um processo automatizado permite que os participantes realizem suas tarefas a partir de locais de trabalho virtuais, em que os funcionários operam remotamente entre si ou com a gerência.

A interação com um processo automatizado não está restrita a uma ferramenta ou um meio apenas. É possível implementar um processo com interação através de e-mails, sistemas legados, aplicações móveis (smartphones, pdas, celulares, tablets), portais e sistemas web.

Pode-se implementar um processo em ambientes de Intranet ou Extranet, permitindo a participação ativa de clientes, parceiros e fornecedores e possibilitando que equipes ou filiais trabalhem cooperadamente mesmo à distância.

Outra grande vantagem de se automatizar um processo de negócio reside na simples premissa de que nos casos em que a interação humana agrega pouco valor à realização da tarefa, estas atividades manuais podem ser automatizadas, poupando tempo e recursos.

Calcular Impostos

A atividade “Calcular Impostos” executa automaticamente uma atividade que dependia de decisão humana de acordo com uma série de regras pré-definidas.

Se em um processo as pessoas precisam interagir com diferentes sistemas para realizar suas tarefas, é possível desenhá-lo de forma que essas interações sejam feitas de automaticamente. Isto gera ganhos em produtividade, pois os participantes não necessitam mais inserir dados manualmente, reduz a possibilidade de erros humanos e assegura, pelo BPMS, o controle e tratamento das integrações com outros sistemas.

Gerar Pedido via EDI

"Gerar Pedido via EDI" é uma atividade de sistema que gera, automaticamente, um pedido no sistema EDI.

O tempo dedicado à transferência de uma atividade de um participante a outro pode, também, ser excessivamente longo. Por vezes é preciso levar documentos fisicamente a alguém para que o processo possa seguir seu caminho e é necessário que cada pessoa conheça o processo ou, ao menos, quem é a próxima pessoa a interagir com ele. Um conhecido caso deste tipo de situação são os processos judiciais, que até recentemente sempre tramitavam entre tribunais em grandes volumes de papéis impressos. Esta troca de mãos da informação agrega grande lentidão ao processo.

Neste sentido, o processo automatizado poupa tempo e recursos porque permite o tráfego eletrônico de documentos (ou informações). Também o BPMS envia a atividade ao próximo participante de forma praticamente imediata e, como é ele quem identifica o próximo participante, as pessoas podem se concentrar em executar suas tarefas diminuindo a necessidade de que conheçam o processo em sua totalidade.

E a proatividade de um processo automatizado não está limitada a repassar atividades, ele também controla os prazos de execução de tarefas e executa as ações definidas quando estes não são cumpridos, sem a necessidade de intervenção ou monitoramento.

Timeout de Prazo

A atividade “Aprovar Pedido de Férias” tem prazo definido. Quando este prazo expira, o BPMS automaticamente envia uma outra atividade informando sobre o atraso.

A automação de um processo permite obter uma enorme quantidade e variedade de indicadores extremamente úteis para a gestão. São meios que permitem saber, por exemplo, quanto tempo o processo está levando, se parou, quanto tempo parou e porque parou. Isto é possível porque o BPMS armazena todas as informações referentes às execuções das instâncias dos processos.

Com isto, é possível consultar o estado atual e histórico de cada processo ou atividade, identificando participantes, dados inseridos e resultados obtidos em cada uma das instâncias.

Dashboard de Monitoramento

Exemplo de dashboard de monitoramento dos processos em tempo real

Com as ferramentas incluídas na maioria dos BPMS, pode-se extrair relatórios para analisar as informações e indicadores medidos na execução das diferentes instâncias do processo. A consolidação e análise dessas informações oportuniza a melhoria contínua destes processos, dando ao gestor as informações que este necessita para tanto.

O controle de qualidade de um processo de negócio está necessariamente ligado a indicadores e estes são difíceis de se obter. A automação de processos permite obtê-los de forma facilitada em relação aos métodos tradicionais, possibilitando enormes oportunidades de medição e evolução do negócio.

A difícil tarefa de escolher uma plataforma BPM para uma organização

-
(2) Comentários

Nos mais de 10 anos da iProcess em que acompanhamos a movimentação do mercado na busca pela consolidação de um modelo de arquitetura de software que viabilze a gestão de processos em nível organizacional, percebemos que a escolha de uma plataforma de BPM passou a ser uma das decisões de compra de tecnologia mais difíceis atualmente.

Até novembro de 2011, a Business Modeling & Integration (BMI) Domain Task Force, grupo da OMG responsável pelos padrões relacionados ao tema BPM já havia contabilizado em sua BPM Vendor List (lista de fornecedores de BPM) 195 soluções de tecnologia para BPM disponíveis ao mercado.

Devido principalmente às diferentes origens de cada uma destas soluções, elas naturalmente possuem particularidades que as distinguem significativamente umas das outras, tais como foco específico em algum nicho de processo, melhor desempenho em tipos de processos mais ou menos manuais, integrações nativas ou complementares com outros produtos além das tecnologias de uma plataforma padrão BPM, ou são especializadas em atender uma ou outra etapa do ciclo de gestão de processo.

São estas particularidades que tornam inviável uma comparação através de simples requisitos técnicos ou funcionais entre os produtos, como em geral é realizado em um processos de escolha de software tradicional.

De fato, ao buscar uma solução de BPM, são diversos fatores que contribuem para a complexidade desta tarefa. Entre eles:

  • a arquitetura interna dos produtos, que faz com que cada solução seja mais adequada para determinados tipos de processos, e que é difícil de ser avaliada em apresentações convencionais de produtos;
  • as diferenças na usabilidade dos produtos, o que define como cada ferramenta atende às necessidades dos times de Negócios, de Processos e de TI;
  • a necessidade de integrar a avaliação de plataformas de BPM a iniciativas de SOA, ERP, ECM e BRM, entre outras, desenhando soluções globais para a organização;
  • o paradoxo que mostra que, muitas vezes, ter riqueza de funcionalidades não significa que o produto seja bom;
  • o variável nível de aderência aos padrões BPMN, XPDL e BPEL e o seu impacto na facilidade de uso, na produtividade ao implementar processos e na portabilidade da solução;
  • o grande número de fornecedores do mercado, exigindo o estabelecimento de critérios claros para a definição das ferramentas a serem analisadas;
  • a grande variedade de modelos comerciais para a venda de produtos por cada fornecedor, o que faz com que a comparação financeira precise levar em conta aspectos particulares de cada projeto;
  • os contínuos movimentos de fusões e aquisições, fazendo com que fornecedores e produtos sejam acrescentados ou excluídos do mercado a todo momento.

Então percebemos que um processo de seleção deve considerar não apenas uma enorme quantidade de fatores técnicos, mas também mercadológicos, financeiros, metodológicos e inclusive culturais, evitando o risco de aquisições inadequadas, que podem comprometer toda a iniciativa de adoção da gestão de processos pela organização .

 A seleção de plataforma de BPM para uma organização requer um processo bem definido, com etapas de:

Aqui comentamos superficialmente estas etapas, provocando uma discussão que certamente tomará corpo à medida que a organização define seu processo de seleção.

I. Definição de objetivos.
Antes da seleção, é preciso identificar e compreender quais os objetivos estratégicos da organização que a estão levando a buscar uma ferramenta de gestão de processos. Esta deverá ser a linha mestra do processo de seleção.

II. Levantamento de requisitos da ferramenta.
Ao definir os requisitos para avaliação, considere:

  • Aspectos de produtividade x flexibilidade
  • Tipos de processos da organização a serem automatizados
  • Alinhamento com outras iniciativas tecnológicas de ERP, SOA e BRM
  • Integração com frameworks de desenvolvimento já utilizados pela empresa
  • Facilidades para migração dos sistemas de workflow existentes
  • Necessidades de gestão de documentos vinculados aos processos
  • Características necessárias para o ambiente de execução e administração dos processos
  • Aderência ou requisitos de adequação à metodologia de processos da organização.

III. Pré-seleção de ferramentas.
A partir dos objetivos e requisitos definidos, é necessário restringir o universo de opções a serem avaliadas. Como critério de corte, pode-se utilizar os objetivos de negócio e requisitos identificados como obrigatórios.

IV.Obtenção de informação junto aos fornecedores.
Encaminhe aos fornecedores ou seus representantes a planilha com a lista de requisitos para que os mesmos a retornem preenchida com os requisitos atendidos, não atendidos, parcialmente atendidos ou ainda, que podem ser atendidos através de extensões ou conexões com outros produtos. Obtenha informações adicionais como planos de aquisição do produto, suporte e casos em que o produto já tenha sido aplicado em outros clientes.

V. Apresentação de ferramentas e provas de conceito.
Após a avaliação dos produtos e requisitos, reúna os fornecedores selecionados para que apresentem seus produtos e solicite apresentação de cases de aplicação do produto em outros clientes e prova de conceito para verificar na prática se o produto atenderá às necessidades da organização.

É importante lembrar que o sucesso da adoção de BPM com suporte de tecnologia não depende apenas da qualidade da ferramenta, mas também de uma cultura de processos aliada à uma mudança no paradigma da própria TI da organização, já que há, além da aquisição, a necessidade de executar projetos de automatização dos processos.

Adquirir a ferramenta apropriada para a organização é muito importante, mas é o primeiro passo para o sucesso de uma iniciativa de BPM.

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

-
(1) Comentário

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á!