Avaliação de Produtos: Oracle Process Cloud Services (Oracle PCS)

No mercado de automação de processos há mais de 20 anos, a Oracle acaba de lançar uma solução para automação de processos simples, leve e que roda em ambiente na nuvem: o Oracle Process Cloud Service, ou Oracle PCS.
Com o foco na automação de processos, o produto possui recursos interessantes para a modelagem e execução de processos, todos disponibilizados em um ambiente simples de boa usabilidade que permitem tanto o usuário de negócios com a área de TI realizarem a automação de seus processos.

 

Na lista abaixo analisamos como a plataforma atende a alguns dos principais requisitos de BPMS:
  • Modelagem com BPMN: Possui suporte tanto a nível de modelagem como a nível de implementação e execução de grande parte dos recursos oferecidos pela notação BPMN.

    Modelagem do processo com BPMN

  • Modelagem de Formulários: Com o uso da tecnologia Webforms, permite o desenvolvimento de formulários em ambiente visual de forma fácil e rápida com os recursos de arrastar e soltar. É possível definir um formulário para cada atividade ou reaproveitar um mesmo formulário em várias atividades, agilizando o desenvolvimento da automação.

    Editor de formulário visual (WYSIWYG)

  • Regras de Negócio em Formulários: Possui uma linguagem nativa de script que manipulam as propriedades dos elementos dos formulários. A linguagem permite a configuração de regras de negócio básicas e avançadas, mas de acordo com o que se deseja fazer, um conhecimento e familiaridade com programação começa a se fazer necessário.
  • Integração com Sistemas: Possui nativamente a chamada de serviços. Contudo, como o ambiente está em ambiente cloud e não existe hoje formas de se estabelecer uma VPN ou um túnel privado com o cliente, faz-se necessário que os serviços estejam disponíveis em ambiente público na web.

    Configuração de acionamento de serviços pelo processo

  • Orquestração de Sistemas: Apesar de não ter recursos mais poderosos para a implementação de processos de natureza sistêmica, o PCS se integra naturalmente com outro produto da Oracle chamado ICS – Integration Cloud Service – que permite a configuração de um barramento de serviços em ambiente de nuvem, facilitando a orquestração deste tipo de necessidade.
  • Gestão de Conteúdo: De forma similar como resolve as necessidades de processos sistêmicos, o PCS se integra de forma nativa com o Oracle Documents, plataforma de gestão de documentos na nuvem da Oracle que permite o compartilhamento, colaboração, visualização, controle de versão e trâmite dos documentos ao longo dos processos.
  • Motor de Regras: Possui um ambiente próprio para a configuração de regras de negócio que são consumidas por atividades do processo através da configuração de tabelas de decisão.

    Criação de Regras de Negócio

  • Ambiente de Execução: Bastante prático e funcional, possui uma lista de trabalho onde são executadas as atividades humanas. Permite a criação de filtro para a seleção de atividades e a consulta de onde está um determinado processo e qual o seu histórico de execução.

    Ambiente de execução do processo

  • Mobile: Possui aplicativo próprio para iOS eAndroid para a execução de processos em ambiente mobile.
  • Indicadores e Relatórios: Disponibiliza uma série de relatórios e dashboards pré-prontos que permitem o acompanhamento de qualquer processo modelado na plataforma. Contudo, possui nativamente poucos recursos de customização destes indicadores.

    Indicadores e relatórios do Oracle PCS

Nesta solução de BPM, a Oracle provê todo o ambiente e infraestrutura do produto, tendo um modelo de licenciamento baseado na compra de créditos que podem ser utilizados o licenciamento por usuário, com valores distintos de acordo com o tipo de usuário: Administrador, Participante e Invocador.

 

Na avaliação da iProcess…

… o Oracle PCS chega como um bom produto para a implementação de processo de baixa e média complexidade, sendo uma plataforma bastante produtiva para o desenvolvimento dos processos a que se propõem e tendo um bom custo x benefício para empresas que querem rapidamente implementar muitos processos com predominância de atividades humanas na sua organização.
É uma solução de rápida adoção, visto que podem ser adquiridos poucos usuários a um custo acessível e que o ambiente em algumas horas já estará disponível para as áreas de Ti e negócios dada a facilidade da automação na nuvem.
Como pontos a melhorar está a necessidade dos serviços do cliente terem que estar expostos na web para serem evocados e pouca customização de relatórios e indicadores.

 

Para conhecer um pouco mais do Oracle PCS, assista aos vídeos abaixo.

 

Vídeo 1: Os benefícios da automação de processos com o Oracle Process Cloud Services

Vídeo 2: Demonstração de utilização do Oracle Process Cloud Services

Para mais informações, fale com a iProcess ou entre em contato com a gente no email contato@iprocess.com.br.

10 pontos chave a considerar na hora de estimar um projeto com BPMS

Com um largo know-how em automação de processos e já tendo realizado algumas centenas de implementações nas mais diversas ferramentas, a estimativa de esforço para a automação de um processo é quase que uma prática diária na iProcess.

Como somos muito questionados sobre como fazemos isso, e neste artigo indicamos algumas diretrizes para auxiliar nossos clientes a fazer avaliar a sua estimativa.

1. Estimativa de implementação é somente uma parte da Estimativa do Projeto

Falaremos neste artigo sobre o esforço direto de um programador para pegar um processo desenhado e detalhado funcionalmente e implementa-lo em uma ferramenta de BPMS. Contudo, isso costuma ser menos da metade do esforço de um projeto!
Um projeto de automação bem elaborado precisa que se faça o levantamento do processo, sua modelagem para automação, projeto técnico, roteiro de testes, preparação de dados de sistemas legados, execução e ajustes da sua validação, homologação com o usuário, elaboração de documentação, elaboração de planos de instalação, instalação em ambiente de homologação e produção, acompanhamento em produção, suporte dos primeiros dias, gerência de projeto, gerência de configuração, gestão de requisitos, entre outros!
Evidentemente que tudo isso é um mundo a parte, e dependerá das características do processo, da cultura da organização e do seu processo de desenvolvimento. Contudo, são atividades que não podem ser desprezadas, pois garante a qualidade do resultado da entrega da automação.

2. Estimativa de Processos não é Estimativa de Software

A estimativa de software convencional utiliza métodos como Pontos de função (PF) ou Unidades de Casos de Uso (UCP) para realizar a estimativa de esforço. São técnicas que utilizam como referência a complexidade da interface de usuário. Na automação de processos é diferente, pois a complexidade está ligada diretamente aos elementos BPMN que compõem o seu processo e a complexidade em implementá-los​ no BPMS adotado​. Logo, estas técnicas não tem aplicação direta para estimar esforço de automação de processos.

3. Você deve conhecer o seu processo (ou projetar como ele deveria ser)

Não tem jeito: você não tem como estimar um processo que você não​ o​ conhece. O esforço de implementação de um processo está ligado diretamente às suas características, elementos necessários e respectivas complexidades. Logo, você precisará levantar o processo.
Caso não haja esta possibilidade, você deverá inferir esta complexidade e assumir o risco no momento da automação de ter que realizar ajustes para mais ou para menos.

4. Cada ferramenta de automação possui uma produtividade diferente

Não existe um número mágico que traga o esforço de implementação de um processo em todas as ferramentas. Cada ferramenta possui suas peculiaridades: algumas são mais produtivas, outras são mais completas e outras são mais complexas. Em algumas uma atividade humana é feita com muita facilidade, mas uma integração com um webservice ou um banco de dados dá muito trabalho.
Por isso, você deve antes de mais nada escolher a ferramenta em que será feita a automação para somente depois avaliar o seu esforço.

5. Identifique o modelo de dados do Processo

O que diferencia uma instância de processo de outra em execução são os dados em que elas manipulam. Cada processo tem atrelado a si um modelo de dados específico, que determina quais informações são manipuladas, incluídas ou consultadas ao longo do processo.
A complexidade do modelo de dados de um processo está ligado diretamente ao número de informações que são manipuladas e as suas características: se existem dados mestre-detalhe, se é feita a manipulação de arquivos, entre outros fatores.
A estimativa de esforço deve levar em consideração este montante e complexidade para projetar o esforço de manipulação destas informações ao longo do processo.

6. Identifique os elementos de processo que são implementados na sua ferramenta

O esforço de automação de um processo está ligado diretamente aos elementos que ele possui. Um processo com 2 atividades humanas e 2 gateways tende a ser 4x mais rápido de ser desenvolvido do que um processo com 8 atividades humanas e 8 gateways por exemplo.
A estimativa de automação de processos está ligada diretamente ao número de elementos que o seu processo possui, e é por isso que você deve conhecê-lo para poder estimá-lo.

7. Identifique os fatores de complexidade de cada elemento

Contudo, somente identificar os elementos não é o suficiente, pois um mesmo elemento pode ter uma implementação fácil ou complexa. Por exemplo, você pode ter
um gateway que somente testa se na atividade anterior houve uma aprovação ou reprovação (simples) ou um gateway que valida uma complexa regra de negócio;
Uma integração que passa o número do CNPJ e recebe o nome do cliente ou o cadastro de uma nota fiscal ​e seus itens ​em um ERP;
Uma atividade humana que informa ao solicitante que seu pedido chegará em 20 dias ou uma atividade distribuída para o ator mais produtivo entre uma série​,​ que possui um SLA rígido, controle de prazos e alertas e escalonamento caso a mesma não seja realizada em até 3 dias úteis antes do prazo final do processo.
Para mapear estas condições, você deve criar critérios de complexidade e atribuir um esforço para cada nível de complexidade.

8. Classifique o seu processo de acordo com estes fatores

Uma vez entendido os fatores para a projeção de complexidade de implementação de um processo, o processo escolhido deverá ser classificado: seus elementos contados, a complexidade de cada elemento avaliada e o esforço da sua implementação calculado.

9. O desenvolvimento das telas das atividades são parte significativa do esforço

​Mesmo com estes cuidados, as coisas não são tão fáceis como parecem, e apesar de estarmos falando de desenvolvimento de processos, eles possuem um componente importante chamado de interface de usuário das atividades humanas.
Na iProcess estimamos que o desenvolvimento de interfaces exige em média um esforço de 40% a 70% do esforço de desenvolvimento de um processo e depende muito dos recursos visuais e da linguagem de programação que cada ferramenta disponibiliza para a implementação das suas interfaces.
Existem soluções de BPMS cuja interface é “engessada” (no sentido que você define poucas coisas em termos de layout e comportamentos) enquanto que outras você pode fazer tudo o que qualquer linguagem moderna de programação web permite.
Por isso, você deve também mapear a complexidade de desenvolver cada interface e realizar uma contagem exclusiva para as mesmas.

10. Elabore uma planilha para calcular o esforço

Se você chegou até aqui, deve ter visto que são muitas variáveis e informações a serem consideradas. Em processos de complexidade média ou alta, com dezenas de atividades e subprocessos, levantar e calcular todas estas informações à mão torna-se quase impossível.
Logo, sugerimos que você elabore uma planilha com todos estes cálculos e utilize-a como ferramenta para realizar a estimativa do seu processo.

Definindo o Escopo de Modelagem de um Processo de negócio

Uma definição essencial no início de um projeto de modelagem é o escopo do processo que será modelado. A definição clara dos limites em que será trabalhado o processo é um fator chave para a realização de qualquer projeto de modelagem.

Tomando como exemplo um processo de venda de uma fábrica de móveis: num primeiro momento, poderíamos imaginar que o escopo de um processo desta natureza  inicia com a chegada do cliente na loja e termina com o pagamento:

Contudo, extrapolando um pouco as atividades que se seguem ao pagamento, poderíamos questionar se não deveriam também estar contempladas as etapas de:

  • Entrega dos móveis;
  • Montagem, quando necessário;
  • Acompanhamento dos pagamentos parcelados; ou
  • Acompanhamento da garantia.

Onde efetivamente deveria começar e finalizar este processo?
Não existe uma resposta certa para esta pergunta, pois o escopo de um projeto de modelagem depende de diversos fatores, estando entre eles:

1. Os Resultados esperados do projeto: A motivação inicial pela realização do projeto é um fator primordial na definição do seu escopo. No exemplo acima, a modelagem pode ter sido demandada pela equipe comercial que tem como meta abrir mais 50 lojas nos próximos 12 meses e que precisa, portanto, unificar o processo de atendimento. Ou por uma necessidade desta mesma equipe em unificar o atendimento das suas lojas, tendo em vista que algumas unidades possuem um desempenho espetacular e em outras deixam muito a desejar. Nestes casos, a primeira versão do processo atende as expectativas.
Porém, digamos que a motivação seja garantir a melhor experiência de atendimento ao cliente. Neste caso, a empresa pode estar preocupada com o fato que o atendimento fora da loja, nas etapas de transporte e montagem, são os momentos em que ela menos tem condições de garantir a sua qualidade, criando assim uma necessidade de maior gestão e controle.

2. A Equipe envolvida no projeto: A modelagem de processos é uma atividade de natureza interfuncional que necessita para o seu sucesso da cooperação de todas as áreas envolvidas no processo. Desta forma, a amplitude do escopo da modelagem deve ser norteada também pelas áreas que estão engajadas no projeto de modelagem. A ampliação do escopo exigirá a sensibilização das novas áreas de negócio que serão afetadas.

3. As Expectativas de Prazo e Custos do Projeto: As variáveis clássicas de custo, prazo e escopo estão interligadas desde a concepção do projeto, e a mudança em uma delas tende a gerar reflexos nas demais. Desta forma, a reflexão sobre o escopo do processo deve levar em conta as expectativas de prazos e custos previstos para o projeto, de modo a garantir que a alteração não impactará a sua viabilidade.

Respeitando estes quesitos, podemos avaliar se determinadas partes do processo, devido às suas características, não poderiam ser modeladas separadamente. São exemplos destas situações as etapas de um processo que:

  • Aparentam ser mais independentes em relação a outras. Etapas com estas características costumam tem um bom nível de desacoplamento do restante. Por exemplo, uma etapa final de pesquisa de satisfação do cliente tende a ser a menos acoplada ao processo do que a etapa de pagamento, e poderia ser analisada separadamente.
  • Se repetem em outros processos. Por exemplo, o serviço de transportes pode ser necessário tanto num processo de venda como num processo de manutenção ou devolução do móvel adquirido.
  • São claramente de apoio, sem visibilidade para o cliente final.
  • Não podem retroagir a um ponto anterior do mesmo processo. Por exemplo, no nosso processo de vendas, não é razoável pensarmos que no momento em que o cliente está recebendo o montador do seu móvel ele possa voltar para a etapa de cadastro realizada antes da compra. Isso demonstra que a etapa de montagem e a etapa de cadastro possuem uma certa independência que permite que elas sejam analisadas separadamente.

Neste momento, algumas perguntas chaves muito comuns no início de um projeto de modelagem também podem ser fundamentais para definirmos o escopo mínimo e máximo de um processo, tais como:

  • Quem é o cliente do processo? Ele será atendido com o escopo que está sendo proposto?
  • Quem são os seus fornecedores? No escopo proposto eles interagirão com o processo?
  • Quais são as entradas e saídas do processo? As entradas previstas serão utilizadas no escopo proposto? Este escopo entregará as saídas esperadas?
  • Quais são os indicadores principais? No escopo proposto estes indicadores poderão ser medidos?

Finalmente, é importante que o escopo previsto para o projeto contemple alguns cuidados de modo a evitar que o mesmo não se limite a um escopo tão pequeno que não seja contributivo ou tão grande que se torne inviável. Desta forma, sugerimos sempre uma dose de atenção para que:

  • O processo não se limite a uma só área ou departamento, ou seja, preserve suas características interfuncionais. Processos departamentais tendem a não apresentar todos os benefícios da gestão por processos como aqueles transversais à organização.
  • Se evitem projetos que exigem 6, 10 ou 12 meses de trabalho. Projetos desta amplitude tende a já ter o seu resultado desatualizado ao seu final, além de gerar desmotivação devido a demora na entrega dos seus resultados.
  • No caso do processo ser muito extenso, seja verificada a possibilidade de que o seu escopo seja dividido em dois ou mais projetos, de modo a garantir entregas frequentes.
  • Se lembre que, quanto maior o escopo, mais complexa a sua gestão.
  • Se esteja, contudo, sempre atento para evitar que uma divisão excessiva que sacrifique a visão ponta a ponta do processo.

Finalizando, não podemos deixar de ressaltar que, tão importante quanto à definição do escopo é que estes limites fiquem sempre muito claros para os stakeholders e para as áreas de negócio. A falta de clareza sobre o escopo a ser trabalhado tende a gerar desmotivação e retrabalho nas reuniões de levantamento do processo.

Se você quiser saber um pouco mais sobre este assunto, conheça o nosso curso de modelagem de processo, http://www.iprocesseducation.com.br/ipe01.html, oferecido pela iProcess Education.

Desafios de Projetos: Mapeamento Conduzidos por Facilitadores das próprias Áreas de Negócio

Dando andamento ao assunto apresentado no artigo Vale a Pena Mapear Todos os Processos da Organização? gostaríamos de falar um pouco sobre uma iniciativa que tem aparecido como alternativa para as empresas que desejam mapear os seus processos sem a necessidade de realizar um investimento pesado em consultoria: a busca pela capacitação dos lideres funcionais de suas área de negócio com o objetivo de habilitá-los ao mapeamento de seus processos!

Não há dúvidas que esta abordagem tem um apelo bastante interessante sob vários aspectos, pois ela consegue com uma única iniciativa não só capacitar seus principais recursos como também economizar algumas centenas ou milhares de horas de consultoria com o uso da sua própria força de trabalho. Além disso, ninguém melhor do que os colaboradores das próprias áreas de negócio para saber quem deve ou não ser entrevistado, se o processo foi todo mapeado e se as informações que estão ali documentadas correspondem à realidade. Para completar, o projeto desta natureza tende a se tornar bastante ágil dado o paralelismo que podemos alcançar ao capacitar um recurso de cada área de negócio.

Mas nem tudo são flores, e este tipo de iniciativa está coberto de uma série de desafios muitas vezes desconhecidos ou ignorados pelos seus gestores. Longe de serem fatores de impedimento, tais desafios representam riscos significativos para o sucesso deste tipo de projeto, e se não forem corretamente mitigados, podem levar à perda de toda a iniciativa de processos dentro da organização. Confira a seguir alguns destes pontos de atenção:

  1. Capacitar as áreas de Negócio nas ferramentas e habilidades do mapeamento de processos: Este aqui é um dos maiores riscos deste tipo de projeto. Na maioria das vezes, vemos as empresas preocupadas em capacitar os seus colaboradores no uso das ferramentas e notações para o mapeamento de processos. Contudo, fazendo uma analogia, muitas vezes esquecemos que saber escrever é bastante diferente de saber redigir: uma pessoa que sabe escrever não tem, necessariamente, a habilidade de fazer uma redação. Na escola, levamos um ano aprendendo a escrever e passamos outros 8 anos aprendendo a redigir! A mesma situação ocorre com o mapeamento de processos: O aprendizado de uma notação não garante que este colaborador saberá expressar adequadamente a realidade dos processos de negócio. Assim, tão ou mais importante que o treinamento sobre a notação ou ferramenta deverá ser o treinamento das habilidades necessárias para que o colaborador possa expressar corretamente o seu processo de negócio!
  2. Garantir que todos os envolvidos descreverão os processos num mesmo nível de detalhe: Apesar de muito semelhante à questão anterior, este tópico merece uma atenção especial por ser complementar às habilidades necessárias. Mesmo em situações em que toda a equipe está capacitada para o mapeamento de processos, faz-se necessário garantir que todos irão documentar os seus processos no nível de detalhes esperado pelo projeto. Se tal preocupação já é fundamental com uma equipe de analistas de processos “profissionais”, torna-se ainda mais importante quando capacitamos uma série de pessoas com experiências profissionais e acadêmicas distintas que não estão habituadas a fazer este tipo de trabalho. O exemplo abaixo demonstra um pouco do que queremos dizer: o mesmo processo, documentado em níveis de detalhe diferentes.
  3. Evitar que as discordâncias do dia-a-dia de trabalho atrapalhem o mapeamento: À medida que envolvemos pessoas que estão inseridas dentro do próprio processo, é muito provável que este ganho de conhecimento seja acompanhando do que chamamos de perda da isenção. Esta perda pode se refletir de duas formas. A primeira está no risco do facilitador mapear uma única visão do processo, considerada por ele correta, em detrimento a outras visões. E a segunda é o risco de que conflitos históricos entre os envolvidos no processo apareçam de forma negativa, prejudicando ou inviabilizando o trabalho. Estas situações obviamente podem também aparecer com um facilitador externo ao processo, mas este costuma ter mais flexibilidade ao gerenciá-las à medida que esta pessoa está isenta do dia-a-dia e dos problemas do processo.
  4. Avaliar como será feito o mapeamento intra-departamental: Dada a natureza transversal dos processos, é natural que um determinado processo passe por diferentes áreas de negócio. Nesse sentido, deve-se evitar que a escolha de facilitadores por área de negócio acabe hierarquizando o processo de acordo com o organograma da organização. Para evitar estas situações, sugere-se adotar inicialmente uma abordagem top-down de mapeamento, de modo a identificar desde o início as áreas envolvidas, os responsáveis por cada etapa e como ocorrerá a unificação deste trabalho. Ou, numa outra abordagem, pode-se também delegar a um único facilitador a responsabilidade por mapear todo o processo, independente das áreas em que ele passe, mesmo que para isso ele tenha que contar com o apoio dos facilitadores de cada área de negócio envolvida.
  5. Garantir disponibilidade para o trabalho: Este é outro típico desafio de qualquer projeto de modelagem, mas que torna-se mais crítico quando os próprios usuários é que mapeiam os seus processos. Se muitas vezes já é difícil arranjar tempo para que os colaboradores descrevam o seu processo para um consultor externo, quem dirá em situações em que este consultor é um colega de trabalho! Neste quesito é importante que os gestores de cada área de negócio entendam a importância da iniciativa de mapeamento e se comprometam a exigir um prazo da sua equipe para evitar que este trabalho entre num ciclo de postergação infinita.
  6. Evitar que informações deixem de ser mapeadas: O que pode ser considerado um dos grandes benefícios do mapeamento de processos ser realizado por alguém de fora da área de negócio, na abordagem interna pode tornar-se um dos principais riscos: o de que, tendo a própria área de negócio o controle do que será ou não documentado, a mesma só represente no processo aquilo que, a seu critério, não compromete a análise sobre o seu desempenho. Para minimizar esta possibilidade é fundamental que a organização comunique claramente aos os seus colaboradores que o mapeamento não tem por objetivo achar culpados, mas sim alcançar o auto-conhecimento de modo que ela possa buscar maior eficiência e eficácia nas operações.
  7. Escolher adequadamente os Facilitadores: Para minimizar alguns dos desafios apresentados, a escolha adequada dos facilitadores de cada área de negócio é fundamental. Neste quesito, critérios como o conhecimento sobre o negócio tendem a ficar em segundo plano se comparados à capacidade de ouvir e negociar do facilitador. De igual importância deverá estar a habilidade deste facilitador em mapear estes processos, pois de nada adiantará um facilitador que entenda como o processo é feito e que não tenha habilidade de documentá-lo. Neste sentido, se desejável, uma boa prova pós treinamento é de grande valia para mitigar este risco.

Apesar dos inúmeros desafios, este artigo busca trazer à tona questões que devem ser acompanhadas por aqueles que buscam nesta forma de trabalho o sucesso para o mapeamento e documentação de seus processos de negócio.

Vale a Pena Mapear Todos os Processos da Organização?

Um dos temas mais polêmicos quando falamos em projetos de modelagem de processos são os projetos cujo objetivo é mapear todos os processos da organização. Projetos desta natureza exigem um envolvimento global de toda a organização, pois dada a natureza dos processos de negócio, toda as áreas e papéis existentes terão que contribuir para o sucesso deste trabalho.

As empresas possuem dentro da sua operação algumas centenas de processos de negócio relevantes. O esforço para mapear tantos processos é enorme, exigindo via de regra algumas milhares de horas de trabalho.

Este esforço não se deve tanto à complexidade técnica do trabalho que tem a ser realizado, mas sim ao volume de processos que devem ser tratados. Como consequência, o projeto acaba envolvendo um número elevado de analistas de processos, muitas vezes até um número maior do que a empresa possui nos seus quadros, fazendo assim da terceirização um meio para viabilizar o trabalho.

Apesar deste número elevado de horas, este tipo de trabalho traz como resultado uma descrição em alto nível destes processos de negócio. Isso porque, se estes consultores precisassem detalhar a nível de procedimento em cada um dos processos, o esforço cresceria exponencialmente, tornando o projeto impraticável. Desta forma, o resultado de tamanho esforço é uma documentação ampla e organizada que mostra a estrutura e hierarquia de cada processo, mas sem entrar em detalhes sobre como são executados os procedimentos de suas atividades.

Com tantas pessoas envolvidas e tanto trabalho a cumprir, projetos desta natureza acabam sendo projetos caros. Não só pelas milhares de horas dos analistas de processos, mas também (e principalmente) pelo tempo demandado das áreas de negócio e por toda mobilização que acaba se fazendo necessária.

Tal mobilização acaba gerando enorme expectativa dentro da empresa: todos esperam que, ao final deste trabalho, a empresa terá um repositório com todos os seus processos e suas respectivas atividades. E é justamente na viabilidade em atender estas expectativas que está o maior desafio.

Processos de negócio são elementos vivos dentro das organizações: diariamente, surgem novas necessidades ou requisitos que exigem a sua adaptação. Quando os processos são modelados ou redesenhados de forma gradativa e planejada, a implantação de uma política de governança que garanta a atualização desta base torna-se natural. Os envolvidos nestes processos possivelmente participaram de toda uma estratégia de mobilização e discussão sobre os processos, sendo assim mais fácil obter o seu comprometimento. Contudo, quando todos os processos da organização são mapeados em poucos meses numa estratégia de documentação em série, a manutenção desta governança e a criação deste comprometimento torna-se muito mais difícil.

Desta forma, a pergunta que fica é: “Como fazer para garantir que, ao final do projeto, toda e qualquer MUDANÇA em QUALQUER PROCESSO será corretamente identificada, analisada e documentada no repositório de processos?

A viabilidade da organização em oferecer esta garantia acaba se tornando o ponto mais crítico de sucesso, uma vez que:

  1. Se a empresa não conseguir manter a base de processos atualizada, em pouco tempo existirão inúmeros processos desatualizados;
  2. Se houverem processos desatualizados, as áreas de negócio começarão a perceber que o repositório de processos não serve como base de consulta;
  3. Se o repositório não servir como repositório de consultas, ele deixará de ser utilizado.
  4. Se ele deixar de ser utilizado, toda a iniciativa cairá em descrédito.

É claro que projetos desta natureza podem trazer inúmeros benefícios, e que as empresas terminando estes projetos se conhecem muito melhor do que quando começaram. Contudo, é importante que as organizações tenham em mente que existe um limite de detalhamento que é passível de manutenção, e que elas não devem investir na criação de uma documentação que elas não conseguirão manter.

 


Conheça mais sobre o Ciclo de Vida de Processos e Projetos de BPM e desenvolva seus conhecimentos nas atividades de mapeamento, análise e redesenho de processos com nossos instrutores!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br

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.

Qual o melhor BPMS do Mercado?

Frequentemente, clientes e prospects perguntam aos consultores da iProcess qual é a melhor ferramenta de BPMS existente hoje no mercado. Infelizmente não existe uma resposta única para esta questão e a dificuldade em respondê-la advém de inúmeros fatores.

Nesse post procuramos elencar alguns dos motivos pelas quais a escolha de uma plataforma de BPM é uma escolha tão difícil.

  1. Por ser uma escolha corporativa: soluções de BPMS não são soluções departamentais: assim como os processos, que possuem uma natureza transversal na organização, uma solução de BPMS tende a ser utilizada por toda a organização.
  2. Pela necessidade de atender diferentes necessidades: sendo uma escolha corporativa, a escolha da solução de BPMS deve atender a um conjunto amplo de demandas: caso contrário, corre-se o risco de se deixar alguma necessidade organizacional à descoberta. Isso exige que um amplo levantamento de expectativas deve ser realizado antes da sua seleção, de modo a evitar uma quebra de expectativa após a escolha da solução.
  3. Pelo enorme conjunto de funcionalidades disponíveis: Existem hoje mapeados na iProcess mais de 600 requisitos que podem ser avaliados na escolha de uma ferramenta de BPMS. Obviamente nenhuma ferramenta atende a estes 600 requisitos, e tão pouco é comum as empresas terem demandas tão complexas a ponto de necessitar todos estes requisitos sejam atendidos como obrigatórios. Desta forma, o casamento entre o que a empresa precisa e o que a plataforma disponibiliza é um fator crítico de sucesso na escolha da plataforma.
  4. Pelo número de alternativas que existem hoje no mercado: Existem hoje centenas de ferramentas de BPMS disponíveis no mercado. Só no Brasil são fabricadas dezenas, sem contar tantas outras que possuem escritórios de representação instalados no país.
  5. Pelo enfoque dado pelo fabricante ao conceber o seu produto: Via de regra os produtos de BPMS possuem categorias de funcionalidades que se destacam dos demais devido a forma como surgiu o produto. Produtos de BPMS se originaram de diferentes segmentos tecnológicos, tais como a gestão de conteúdo, a colaboração, a integração entre sistemas, a edição de formulários, …
  6. Pela enorme variação de valores financeiros envolvidos: Existem atualmente produtos para todos os bolsos e gostos: desde aqueles que são totalmente gratuítos (mas que possuem contratos de suporte e manutenção) até aqueles cujo o licenciamento pode chegar à centena de milhares de dólares. A forma de licenciamento também tem o impacto direto na sua precificação, sendo os tipos mais comuns as licenças por usuário ou processador.
  7. Pelas plataformas tecnológicas existentes na organização: As plataformas tecnológicas disponíveis dentro da organização podem facilitar ou inviabilizar a escolha de uma plataforma de BPM. Questões como, por exemplo, o sistema operacional utilizado nos computadores clientes e servidores (Windows, Linux, Unix, …); o banco de dados da organização (Oracle, DB2, Postgress, SQL Server, …); o servidor de aplicação disponível (IIS, Apache, WebLogic, Websphere, …); a linguagem de desenvolvimento utilizada (Java, .NET, PHP, …) podem ser fundamentais na análise de aderência de uma ferramenta de BPMS à plataforma atual.

A escolha certa de uma plataforma de BPM passa por uma análise detalhada de cada um destes fatores. É importante ter em mente que a escolha inadequada de uma solução de BPMS pode inviabilizar a execução de alguns processos de negócio da sua organização e, em última análise, até mesmo as suas iniciativas de gestão por processos.

[Atualizado] Leia também: ferramentas BPMS livres ou de baixo custo são sempre mais baratas do que as ferramentas pagas?

Até lá.

BPA (Business Process Analysis) – Indo além dos Desenhadores de Processos

Utilizados principalmente pelos usuários de negócio, o BPA (Business Process Analysis) é a principal ferramenta utilizada pelo analista de processos para mapear, documentar, analisar e redesenhar os seus processos organizacionais.

Diferentemente dos desenhadores de processos, que são utilizados quase que exclusivamente para o mapeamento e documentação de atributos do processo, os BPAs possuem funcionalidades que extrapolam as funções de desenho do processo e apoiam grande parte das iniciativas de gestão por processo da organização.

Apesar das funcionalidades disponíveis numa ferramenta de BPA dependerem da implementação de cada fornecedor, iremos citar abaixo algumas das principais características presentes na maioria destas plataformas.

  • Gestão do Repositório de Processos Organizacional. Os processos são armazenados em uma base de dados, centralizada, de forma controlada e estruturada. Todos os processos da organização são mantidos nesta base, com controle de acesso e segurança. Somente usuários autorizados podem acessar a esta base, e é possível configurar quem pode acessar cada processo e quais são estes direitos de acesso (leitura, alteração, exclusão, …)
  • Definição de Metadados dos processos. São definidos atributos que permitem a classificação e catalogação dos processos organizacionais. Estes atributos podem ser utilizados para auxiliar a navegação no repositório de processos ou a realização de pesquisas avançadas.
  • Visão top-down dos Processos da Organização. Podemos modelar num BPA o processograma da organização, que abrange desde a identificação da cadeia de valor até o detalhamento dos seus macro-processos e processos operacionais.
  • Definição dos Campos de Documentação. Os campos que documentam os processos e suas atividades podem ser definidos pela organização, bem como seus tipo e obrigatoriedade.
  • Customização de Templates de Documentação. As informações dos processos armazenados no BPA podem ser exportadas para documentos cuja estrutura pode ser definida pelo escritório de processos. A empresa pode definir templates de diferentes tipos de documentos e gerar estes documentos automaticamente para um determinado processo. A figura abaixo mostra uma tela de customização de relatórios do Aris.

  • Publicação dos Processos de Negócio. Os processos armazenados podem ser consultados por diferentes usuários da organização através da sua publicação em um portal de processos. Mais do que uma exportação em formato Web, disponível em muitos desenhadores de processo, esta publicação mantém as regras de segurança e controle de acesso, exigindo login e senha dos seus usuários e garantindo que eles só poderão acessar os processos em que estão autorizados.

  • Soluções de Colaboração. Ao longo do mapeamento e redesenho de processos, é muito comum a equipe de análise precisar de um feedback de pessoas da organização sobre o processo que está sendo analisado. Através das soluções de colaboração, é possível que usuários selecionados façam anotações no processo e proponham sugestões sem que o processo seja efetivamente alterado. Estas sugestões são então analisadas pela equipe de analistas que avalia a viabilidade da sua adoção.
  • Simulação de Processos. Complementar a modelagem de processos, a simulação permite que o analista verifique qual será o comportamento do processo numa nova configuração. Como resultado, são gerados relatórios que demonstram como foi o seu desempenho, quais os pontos de gargalo, quais as necessidades de recursos, entre outras informações. Além disso, diferentes simulações podem ser comparadas com o objetivo de avaliar o ganho obtido com cada configuração.

 Podemos citar como exemplos de soluções de BPA os softwares Aris da Software AG, Oracle BPA da Oracle, iGrafix da Corel e Websphere Modeler da IBM; e são exemplos de desenhadores de processo o Oryx, o BizAgi Modeler e o Microsoft Visio.