Métodos para levantamento de informações na Modelagem e Análise de Processos – Parte 2

No primeiro artigo da série (veja aqui) falamos sobre os métodos Pesquisa, Entrevista e Observação Direta. Neste segundo e último artigo da série abordaremos o restante dos métodos utilizados para coleta de informações para o trabalho de modelagem.

WORKSHOP ESTRUTURADO

Workshop estruturado é um método utilizado para a coleta informações através de reuniões com os representantes dos papéis envolvidos no processo, reunindo diferentes pontos de vista, visando o detalhamento e a modelagem do processo de modo interativo.

photo credit: juhansonin via photopin (cc)

Agendamento do workshop

A escolha correta dos envolvidos é crucial para uma reunião produtiva, mas afinal como escolher as pessoas certas para a reunião?

  • Especialistas: Ninguém melhor para explicar um determinado processo do que as pessoas que trabalham nele. São os executores do processo, usuários do sistema ou membros de equipes operacionais com profundo conhecimento sobre certas funções ou operações de negócio. Quando em grande número são representados por usuários-chaves que se fazem presente no workshop. Representados normalmente pelos papéis de Representantes Funcionais ou Gestores Funcionais.
  • Liderança: Outro papel de importância na reunião é o do Dono do Processo, este é o responsável pelo processo ponta a ponta. Defende as prioridades e assegura que o processo atenda às expectativas de desempenho esperado pelo cliente. Não podemos esquecer também do Patrocinador, representado usualmente pela liderança executiva, gestores, diretor ou gerente da área responsável pelo processo. Apesar de não se envolver de forma integral, participa geralmente de reuniões estratégicas que determinam o caminho que o processo irá trilhar. Estes papéis possuem uma visão macro do processo.
  • Facilitador: Normalmente representado pelo Analista de Processos ou Designer de Processos. É o responsável pela condução adequada da reunião e por garantir que todos os participantes sejam ouvidos. Para isto deve ter a habilidade para lidar com pessoas, resolver conflitos e manter o foco no objetivo do workshop.

A divisão apresentada acima contendo especialistas, liderança e facilitador compreende uma abordagem mais estruturada e pode variar de empresa para empresa, levando em conta a sua maturidade em BPM. O mesmo vale para as convenções de nomenclaturas para os papéis descritos.

Outras questões que devem ser levadas em conta para escolha dos envolvidos:

  • O participante do workshop deve ter a competência e o conhecimento necessário para descrever suas atividades e se posicionar quanto suas divergências.
  • Os envolvidos devem ter bom relacionamento, para isto o facilitador deve se informar sobre conflitos de interesses e embates políticos entre gestores e equipes.
  • Disponibilizar uma agenda viável para todos os participantes.

Vantagens

  • Redução do tempo de desenvolvimento do modelo devido ao entendimento comum criado entre os participantes.
  • Resolução de conflitos no momento do workshop.
  • Redução do número de intermediadores evitando futuros problemas de comunicação.
  • Redução do tempo do acompanhamento das partes envolvidas na evolução do modelo final.
  • Facilitador com habilidades de técnicas de modelagem.
  • Facilitador com apoio de Designer de Processos (trabalho em dupla) na modelagem do processo; principais impactos na redução do tempo de execução e validação do modelo com processo aprovado na mesma reunião.

Desvantagens

  • Desgastes em deslocamentos / viagens – Participantes muitas vezes encontram-se em locais físicos distintos.
  • Altos custos de viagens.
  • Conciliar agenda dos participantes.
  • Custo com hora/homem  – 100% do tempo de todos ao mesmo tempo em reunião.
  • Evitar paralisia por análise – Seleção do escopo e escolha do processo e profundidade da análise devem ser definidos com muita clareza.

CONFERÊNCIA VIA WEB photo credit: JulianBleecker via photopin (cc)

A Conferência via web ou Videoconferência como também é conhecida, é um método semelhante ao Workshop Estruturado. Utilizado quando os participantes estão em locais físicos distintos e sem a disponibilidade para viagens.

Vantagens

  • Redução de custos de deslocamentos e viagens.
  • Redução no tempo de deslocamentos entre unidades.
  • Utilizado para se buscar um consenso sobre um mesmo processo desenvolvido em diferentes unidades.

Desvantagens

  • Não funcionam muito bem com grupos grandes.
  • Dificuldade de conduzir a participação individual dos participantes.
  • Baixa qualidade de áudio e vídeo.

Atenção para a infraestrutura tecnológica requerida que dependerá da necessidade de cada projeto/empresa. Alguns pontos devem ser observados:

  • Disponibilidades de equipamentos/periféricos de áudio e vídeo.
  • Qualidade de velocidade de banda da internet para transmissão, disponibilização de vídeo e eventuais imagens, acompanhamento em tempo real do processo que está sendo modelado.
  • Softwares apropriados para conferência.

FAZER EM VEZ DE OBSERVAR

photo credit: ColorTime via flickr (cc)

Método conhecido também como “aprendizado do aprendiz”, muito utilizado em tarefas repetitivas. Consiste em aprender o que é feito e então executar o processo.

Ao ensinar as atividades, podem surgir informações de tarefas e passos que ocorrem de forma inconsciente, isto permite que o observador tenha um conhecimento mais detalhado das tarefas realizadas.

A execução do processo pelo observador pode ajudar a coletar alguns detalhes das atividades que de outra forma não seriam observados. Sempre que possível, é interessante ter um segundo membro da equipe observando o processo de aprendizagem para auxiliar na identificação de detalhes das atividades.

ANÁLISE DE VÍDEO photo credit:  Flickmor via flickr (cc)

Similar à observação direta  (veja mais sobre o método Observação Direta no artigo anterior), a análise de vídeo auxilia na identificação de evidências à distância e permite que o executor realize suas atividades de forma mais natural.

A presença de um equipamento de gravação permite uma adaptação mais rápida do que a de um observador ao seu lado.

Outra vantagem é que os vídeos podem ser mais tarde assistidos pelo executor e este narrar suas atividades e ações executadas fora do campo da lente, isto auxilia na identificação de informações não vistas pelo observador.

SIMULAÇÃO DE ATIVIDADES

photo credit: Wonderlane via flickr (cc)

A simulação de atividades é utilizada para identificar possíveis falhas humanas e desvios na execução do processo. Uma forma de simulação seria, durante a entrevista ou workshop, a realização de uma análise apurada do comportamento de cada atividade do fluxo do processo. Esta análise consiste em avaliar o que dispara esta atividade (entradas), seu resultado (saídas) e regras estabelecidas para execução desta atividade.

 

Como falamos nos dois artigos, cada método tem suas vantagens, desvantagens e o esforço necessário para que possa ser realizado. Questões como tempo requerido, altos custos de viagens, conciliar agenda dos participantes, suporte à infraestrutura tecnológica e habilidades em técnicas de modelagem são apenas alguns pontos a serem observados antes de optar pelo método a ser utilizado no levantamento de informações.

Não há um método único que seja melhor, cada projeto de modelagem ou análise de processos deve considerar quais métodos de coleta de informações são mais apropriados e eficazes para o processo que está sendo estudado.


Conheça mais sobre estas e outras atividades relacionadas à modelagem de processos no curso de Modelagem de Processos de Negócio da iProcess Education.

A importância de avaliar a cultura e o medo da mudança na implementação de BPM

Neste artigo vamos abordar alguns dos aspectos mais críticos, e frequentemente ignorados, no que se refere a implementar BPM nas organizações: como a cultura organizacional e o medo da mudança são fatores que podem afetar consideravelmente o resultado desta iniciativa.

Durante a implementação de projetos de BPM, é muito frequente se deparar com obstáculos relacionados à cultura da organização, principalmente no que se refere à forma como as coisas costumam ser feitas. São procedimentos, padrões e ferramentas que se estabeleceram com o passar do tempo, e acabaram virando a única forma conhecida das pessoas de realizar o seu trabalho. Com a realização de um trabalho de análise e redesenho do processo através de uma iniciativa de BPM, então todos os gaps, ineficiências e problemas desta forma de trabalho podem vir à tona. Podemos citar como exemplo um caso clássico na automatização de processos: a substituição de formulários em papel que devem ser assinados manualmente pelos gestores, por formulários eletrônicos em que a aprovação é controlada por um processo automatizado e realizada através de uma lista de trabalho.

É do nosso conhecimento casos em que usuários de negócio ficaram receosos e resistentes pelo simples fato de que as aprovações necessárias não iriam mais ser em papel, ou seja, sem a assinatura “física” do seu gestor. São usuários que não foram suficientemente informados de todos os conceitos por trás de uma aprovação digital, e chegaram a exigir (já numa fase bem adiantada de uso do processo) que os participantes deveriam adicionalmente imprimir o histórico de aprovações e anexar junto a solicitação, para que fosse dado o encaminhamento para a próxima área envolvida. Temos aqui um caso em que um dos maiores benefícios da automatização de processos, que é a economia de papel, foi praticamente anulada simplesmente pelos receios de usuários mal informados.

Uma mudança na forma de como são feitas as coisas pode mexer ainda com questões comportamentais enraizadas na organização, e que podem passar despercebidas até para o mais experiente analista de processos. Podemos citar o exemplo de um solicitante que aproveitava o momento em que solicitava a aprovação do seu gestor (com o formulário em papel em mãos), para sentar com ele na sua sala, tomar um cafezinho e discutir com ele banalidades e o resultado do futebol no fim de semana. E que, de uma hora pra outra, teve esta rotina agradável e esperada (do ponto de vista dele) sendo substituída pela rápida, eficiente e distante aprovação eletrônica. O exemplo pode até parecer exagerado e cômico, mas é um tipo de percepção que de fato ocorre entre os usuários, e é preciso ficar atento.

A resistência a mudanças pode ser um grande impeditivo para o sucesso de projetos de BPM. Se os usuários não forem suficientemente informados e principalmente convencidos da necessidade da mudança, podem virar grandes opositores e chegar ao ponto de boicotar a iniciativa, levando muitas vezes o projeto ao fracasso. Em outro exemplo que ilustra esta situação, uma das pessoas envolvidas na execução de um processo chegou a temer pelo seu emprego, quando descobriu que a automação do processo iria realizar de forma automática muito dos procedimentos que esta pessoa executava de forma manual, procedimentos os quais tomavam boa parte do seu dia. Foi então necessário um trabalho de informação e conscientização com esta pessoa, informando que esta seria direcionada para atividades de maior valor agregado, para que a resistência e o medo da mudança fossem finalmente superados.

Se durante uma iniciativa de BPM as organizações optarem por ignorar a avaliação da cultura interna e não realizarem uma etapa de gerenciamento das mudanças com todos os envolvidos, certamente poderá se esperar como resultado uma resistência muito grande e, em casos extremos, até o cancelamento da iniciativa.

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

Nos dois primeiros posts (disponíveis em 1 e 2), tratamos particularidades da gestão/execução e práticas metodológicas para bons resultados em projetos envolvendo integrações.

Para fechar esta série de artigos, hoje descreveremos alguns riscos importantes e fatores críticos de sucesso (FCS) nestes projetos, para que recebam a devida atenção e, se necessário, tratamento.

Em resumo, grande parte dos riscos e FCS se referem à comunicação e à integração das equipes do projeto, dado que muitas das informações e necessidades de trabalhos desta natureza envolvem algum tipo de compartilhamento.

Desta forma, listamos abaixo alguns itens que consideramos relevantes:

  • O primeiro ponto quem sabe até não seja o mais importante, mas certamente é um dos mais frequentes. Durante testes do sistema, quando ocorrem problemas, costumamos dizer: “até que se prove o contrário, a ‘culpa’ é da integração”. E pode-se dizer que até é um fato lógico. Quando uma das equipes realiza algum teste e não vê o resultado esperado acontecendo na outra “ponta”, naturalmente a primeira desconfiança é de algum defeito ou inconsistência na integração, que justamente faz a “ligação” entre os dois sistemas. Porém, esquece-se que a integração não é uma peça de software isolada, e sim um pequeno sistema formado pela origem, destino e o meio, que é a integração em si. E em qualquer um destes componentes pode ocorrer erro. Assim, é importante tanto alinhar as expectativas das equipes (inclusive para evitar desgastes) quanto definir um processo de teste e avaliação de problemas tecnicamente adequado para o cenário do projeto e dos sistemas envolvidos.
  • Boa parte das etapas de desenvolvimento e testes será realizado de maneira simbiótica por todas as equipes envolvidas (equipe do sistema que será integrado, de integrações e dos legados). Desta forma, uma prática bastante importante é a apresentação destas equipes, visando sua aproximação e integração. Com isto, espera-se que todos se conheçam, saibam os papéis de cada um e a quais responsabilidades respondem, quais os conhecimentos de cada integrante quando precisarem de apoio, etc. Além disso, a própria integração pessoal da equipe auxilia na pró-atividade e facilidade da comunicação.
  • Apesar da metodologia de desenvolvimento normalmente contemplar e se adequar a boa parte do escopo, como as integrações são o meio e dependem da forma como as “pontas” são desenvolvidas e entregues, é fundamental avaliar as eventuais modificações necessárias na metodologia, bem como apresentá-las às equipes. As responsabilidades também devem ficar muito claras. Além disso, é mandatório registrar estas mudanças em algum local, para consulta. Esta preocupação é essencialmente importante pois é muito comum (para não dizer que acontece sempre) que se confundam sobre o que cada equipe deve fazer e até onde sua autonomia vai. Isto pode gerar conflitos e desgastes desnecessários, perda de produtividade ou até problemas mais graves, que se refletem apenas quando o projeto já está em um estágio mais avançado.
  • É comum em um projeto com integrações existirem documentações compartilhadas, nas quais uma equipe preenche parte do documento, e outra(s) o completa(m). Assim, é importante esclarecer com todos quais tópicos cada um é responsável e definir uma política de armazenamento e versionamento adequadas.
  • A comunicação entre as equipes durante a análise e os testes é outro fator crítico. É fundamental definir um fluxo adequado e claro de comunicação entre os integrantes das equipes, de acordo com as responsabilidades no projeto. E, claro, esta definição depende de uma avaliação criteriosa dos estilos e da disposição física das equipes, do ambiente de trabalho e dos recursos de comunicação disponíveis.
  • Por fim, um ponto bastante simples, mas que pode facilitar muito a identificação de problemas. À medida que integrações forem codificadas e estejam razoavelmente estáveis, podem ser disponibilizadas para uso pelas demais equipes. Claro, dependendo do planejamento do projeto e da metodologia utilizada, elas nem serão acionadas antes dos testes integrados. Mas, caso as equipes das “pontas” já estejam prontas para realizar testes com o uso das integrações, isto pode antecipar alertas relevantes sobre inconsistências e defeitos.

Com este artigo, fechamos esta série dedicada especialmente a dicas, boas práticas e cuidados com projetos envolvendo integrações, que possuem particularidades que os tornam especialmente desafiadores.

Fiquem à vontade para opinar e sugerir outras práticas interessantes.

Esperamos que tenham gostado!

Nos falamos em futuros artigos. Até lá!

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

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