Webinar – Do Modelo TO BE para a Automação – o que é preciso repensar sobre o processo

Neste webinar, apresentado por Kelly Sganderla em 25/08/16, compartilhamos nosso expertise e experiência sobre a importância de realizar um redesenho tecnológico do TO BE, considerando aspectos importantes sobre a visão de processo e visão sistêmica da Solução.

Aos que participaram da transmissão ao vivo, um muito obrigado em nome do time da iProcess!

Os slides utilizados na apresentação também estão disponíveis no SlideShare:
http://www.slideshare.net/iProcessBPMeSOA/webinar-iprocess-do-modelo-to-be-para-a-automao-um-repensar-sobre-o-processo

Confira abaixo as respostas para perguntas enviadas por nossos participantes durante o evento:

Pergunta: Para automatizar processos e adotarmos um BPMS, temos uma etapa que é a escolha da ferramenta BPMS. Devemos ter ações paralelas para definir junto ao cliente qual BPMS a ser adotado, caso o cliente não tenha definido qual a ferramenta a utilizar? Que dificuldades afetam o projeto (redesenho e automação) na escolha da ferramenta?
Certamente uma etapa importante na automatização de processos é a escolha de uma da suíte de BPM (BPMS). Dificilmente, porém, a organização irá adquirir um BPMS para automatizar um processo específico, pois este tipo de ferramenta é uma plataforma para automação e controle dos processos da organização. A escolha da plataforma para a gestão de processos é uma decisão corporativa. Cada solução disponível no mercado tem seus pontos fortes e fracos, e seus recursos precisam ser avaliados em relação às necessidades da organização, como sua estrutura, cultura organizacional e planos atuais e futuros para os processos da empresa. A escolha da ferramenta pode impactar diretamente no projeto de automação, pois de acordo com os recursos e funcionalidades disponíveis no produto, o redesenho tecnológico do processo pode mudar.
A iProcess Education lançou recentemente um Kit de Avaliação de plataformas de BPM com vídeo aulas e planilhas de templates para comparação e avaliação de aderência de produtos a centenas de requisitos que precisam ser considerados nesta avaliação, entre as quais os recursos que o produto disponibiliza para o desenvolvimento da automatização do processo.
Para saber mais, visite a página: www.iprocesseducation.com.br/avaliacao_plataformas_BPM

 

Pergunta: Trabalhar o TO-BE significa custo, para empresa como o todo, ainda mais como o TO-Be tecnologico que aparentemente gera mais custo. Tem algum valor de beneficio entre o TO-BE e o TO-BE tecnologico?
A melhoria de processos não deve ser vista como um custo, mas como um investimento. Assim, não devemos avaliar o valor e os benefícios do redesenho de processos pelo custo deste trabalho, e sim pelo seu potencial de retorno do investimento. O redesenho tecnológico possibilita criar uma nova visão de futuro (TO BE) que ao ser comparada com a situação atual nos apresentará que ganhos teremos no processo em termos de redução de custos da sua execução, redução da duração do processo e melhoria na qualidade e produtividade. Isto é fundamental para o cálculo do ROI do projeto – um tema que trabalhamos muito fortemente nos nossos treinamentos do Ciclo BPM.

 

Pergunta: Se a TI não conhece a ferramenta a empresa auxilia neste trabalho a 4 mãos?
Se a equipe que fará o desenvolvimento para a automação do processo não conhece a ferramenta, há um risco bastante elevado de definições sobre o processo não serem viáveis de automação com o produto escolhido, ocasionando necessidades de mudança do processo e do escopo de trabalho durante o projeto – o que no final das contas poderá aumentar o seu custo de implementação. Neste caso, o ideal é contar com um apoio do fabricante ou de consultoria especializada que conheça bem o produto, para realizar este redesenho tecnológico do TO BE.

 

Pergunta: Eu gostaria de rever os slides que falam sobre analista de negócio e de TI agora do final da apresentação.
Os slides utilizados na apresentação estão disponíveis no link do slideshare acima e você também pode rever esta parte da apresentação no vídeo gravado!

Como documentar funcionalmente o processo de negócio como requisito de software

Na automação de processos, os processos de negócio são definidos e otimizados a fim de serem executados sobre uma arquitetura de sistemas informatizada.

No artigo Benefícios da Automação de Processos do blog da iProcess, tratamos dos benefícios e vantagens da automação de processos, estabelecendo uma visão dos ganhos obtidos quando se automatiza um processo. Porém, alguns cuidados devem ser tomados para escolher um processo a ser automatizado e estabelecer o nível de detalhamento necessário do processo para tal, tendo como objetivo automatizar processos com tarefas que possam efetivamente demonstrar bons resultados. Em Estudo de Caso: Automatizar o processo (ou não)? Eis a questão! exploramos esta questão através de um estudo de caso.

As etapas de modelagem na transformação de um processo

Nos projetos de implementação de BPM, o ciclo BPM a ser seguido inclui a análise (AS IS) e o redesenho (TO BE) dos processos, antes de seguir para a etapa de implementação (TO DO). Desta forma, garante-se que o cenário atual do processo na organização foi adequadamente estudado e todas as necessidades de melhoria no processo foram devidamente contempladas.

O artigo BPMS: como as etapas do ciclo BPM geram segurança no processo automatizado aborda este tema, incluindo aí os riscos envolvidos em um projeto em que se parte diretamente para a etapa de implementação (TO DO), sem passar pelas demais. Isto porque é na etapa de TO BE, em que há a proposição de melhorias no processo e são definidos os requisitos de software que irão compor a solução automatizada. Já falamos sobre esta ligação no artigo O que BPM tem a ver com requisitos de software? Tudo!, enfatizando que os requisitos de software são identificados a partir do processo.

Documentando a modelagem do processo para automação (TO DO)

Passadas todas estas fases, chega a hora da implementação do processo. O processo e os requisitos de software complementares serão detalhados funcionalmente (TO DO) e implementados pela equipe de desenvolvimento. E aí entra em cena a Especificação Funcional do processo. Ela especifica o fluxo a ser automatizado no BPMS e sua estrutura de dados, regras para identificação de participantes e comportamento de cada componente.Resumidamente, a Especificação Funcional deve atender aos seguintes objetivos:

  • Concentrar as informações do processo de negócio necessárias para a automação do processo;
  • Utilizar linguagem que deve ser de fácil compreensão pelo público-alvo;
  • Fornecer informações suficientes para que o projetista possa desenvolver a especificação técnica do processo;
  • Servir de referência para o desenvolvimento e homologação da solução.

Temos encontrado, ao longo dos projetos de automação de processos em que a iProcess atua, alguns clientes que já possuem uma metodologia, utilizam ferramentas e templates para documentar processos automatizados, enquanto outros não possuem nada definido. Nas organizações que já tenham adotado uma metodologia de desenvolvimento com documentação funcional dos requisitos, é comum encontrarmos documentos como Casos de Uso, Especificações de Interface, Especificações de Serviço ou de Regras de Negócio. Nos projetos de automação de processos, é comum que os requisitos se estendam além da programação do fluxo no BPMS, envolvendo o desenvolvimento ou customização de componentes adicionais ao processo, como aplicações de apoio, cadastros de backoffice e serviços de integração com outros sistemas. Para estes requisitos, os documentos já adotados pela TI continuam sendo bastante apropriados. 

 Assim, a Especificação Funcional do Processo (o modelo TO DO) vem para complementar a documentação do sistema definindo funcionalmente o processo de negócio, e requer um detalhamento de como o fluxo do processo se comportará ao ser automatizado. São informações importantes neste modelo:

  • Diagrama do processo automatizado;
  • Modelo de dados do processo;
  • Identificação de usuários ou grupos de usuários participantes do processo (Papéis);
  • Formulários do Processo;
  • Especificação dos componentes do processo, que são eventos, tarefas humanas e automáticas, notificações/envios de email, controles de tempo, gateways, subprocessos, regras de negócio e sensores de indicadores;
  • Definições de interface para as atividades humanas;
  • Referências a serviços de outros sistemas;

Esta especificação deve ser realizada por um Analista de Processos e Sistemas, ou um analista de sistemas que tenha desenvolvido uma visão de processos, horizontal aos sistemas, e que conheça as capacidades de implementação do BPMS adotado pela empresa

O Analista de Processos e de Sistemas, pode encontrar alguma dificuldade em estabelecer a melhor forma de como escrever utilizando uma linguagem de fácil compreensão pelo usuário e ainda assim fornecer informações suficientes para que sirva de referência para a elaboração da especificação técnica e o posterior desenvolvimento da solução. Uma sugestão nesta situação é o alinhamento com os responsáveis pela aprovação do documento no cliente, para estabelecer qual será o nível de detalhamento da Especificação Funcional do processo, a fim de definir se haverá necessidade de utilizar documentos complementares mais técnicos para a equipe de desenvolvimento, ou em mais alto nível para a equipe de negócio.

Temos observado que, às vezes, o cliente opta por realizar uma “tradução” da especificação para a área de negócio ou absorver para si a aprovação do documento. Quanto mais precisa for a Especificação Funcional do processo, menos problemas de entendimento tendem a ocorrer entre a expectativa do cliente e o que está sendo desenvolvido. Isto porque as etapas de desenvolvimento e homologação dos processos vão utilizar estas informações, garantindo assim, que o que foi definido e aprovado pelo cliente seja entregue.

Cabe aqui salientar que a Especificação Funcional do processo, assim como de sistemas, não fica “congelada”, sem receber as atualizações que ocorrerem no escopo do projeto durante o seu ciclo de vida. Ajustes na documentação funcional podem ser necessários após a finalização da etapa de especificação funcional por diversos motivos e devem ser realizados, sempre que necessário, para que se mantenha a consistência entre o que foi especificado e o que foi desenvolvido. E neste caso, a gestão de mudanças do projeto é que tratará desta atualização.

Se este assunto lhe interessou, no nosso curso iPE03 – Modelagem de Processos para Automação, reservamos um capitulo inteiro para tratar deste assunto, inclusive com exercícios práticos.

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.

Muito prazer, o CLIENTE! (Visão Outside in e Inside out)

Começamos com uma pergunta direta: QUEM É O CLIENTE?
Parece ser uma pergunta um tanto obvia, mas saber exatamente quem é (ou quem são) os seus clientes é fundamental para atender as suas necessidades.

Poderíamos afirmar que:

“Na perspectiva de BPM, cliente é somente aquele que se beneficia da geração de valor e está externo à organização.” (BPM CBOK 3.0, pag.47)

Mas, de uma forma geral, todos nós somos clientes, pessoas comuns que levantam pela manhã para trabalhar, que fazem compras no mercado, utilizam os serviços da rede bancária, que pagam contas, cidadãos que dependem do transporte público para chegar ao seu destino, ou seja, consumidores!

Todos nós, como cidadãos, por exemplo, somos clientes que dependem dos serviços públicos como o acesso à água e a luz, saneamento, limpeza pública e segurança.

Clientes que muitas vezes não têm as expectativas atendidas!

Ao mesmo tempo, quantas vezes, como cidadãos, somos questionados pelo prestador de serviços para saber o que achamos do serviço prestado?

Organizações estão empenhadas em oferecer o melhor valor agregado aos seus produtos e serviços, só que nesta tentativa, trabalham muito mais focados em otimizar e reduzir custos dos seus processos internos e esquecem de avaliar as expectativas dos consumidores destes produtos e serviços.
Assim, saber quem são seus clientes é o caminho para entender suas necessidades, expectativas e o que eles valorizam, e poder produzir e entregar aquilo que seus clientes esperam.

COMO ERA ANTES

Durante décadas organizações determinaram o que seus clientes necessitavam e definiam como seus produtos e serviços seriam disponibilizados. Até então, o cliente era pouco exigente. O foco era: aumento da eficiência na produção.

Esse cenário, de foco na otimização do processo em detrimento às expectativas do cliente, se percebe concretamente nesta célebre frase de Henry Ford, sobre a fabricação do modelo Ford T:

“O carro é disponível em qualquer cor, contanto que seja preto.”

O objetivo de Henry Ford era tornar o carro acessível a todos, aumentando a procura mas ao mesmo tempo reduzindo custos.

Conforme as empresas foram crescendo, foram surgindo novas oportunidades. As empresas foram criando novos planos de expansão e com isto os clientes começaram a impor o que queriam e como queriam. Sendo assim, as estruturas organizacionais e modelos de negócios começaram a tomar novas formas, mas persistia a visão de “dentro para fora”, ou seja, a busca pela eficiência na entrega de valor ao cliente.

OLHAR DE DENTRO PARA FORA OU DE FORA PARA DENTRO?

“Olhar de dentro para fora”: visão conhecida também por Inside out ou ainda por Foco NO Cliente.

É a visão sob o ponto de vista da organização. Se preocupa com o “de dentro”, com foco em seus produtos e serviços. É a organização que determina o que agrega valor para seus clientes e cria a cadeia de valor idealizado por Michel Porter.

Este modelo fazia sentido em sua época, onde a interação com o cliente não era algo comum, pois este ficava em segundo plano. A preocupação das organizações era em fazer as coisas certas. O foco era a eficiência, o controle de custos e a redução de erros.

Atualmente, as organizações estão focadas muito mais na eficácia, ao grau em que os resultados de uma organização correspondem às necessidades dos seus clientes.
Hoje a exigência está muito maior, principalmente no que se refere não apenas a qualidade ou preço dos produtos, mas principalmente ao atendimento real às suas necessidades.

“Olhar de fora para dentro”: visão conhecida também por Outside in ou ainda por Foco DO Cliente.

É a visão sob o ponto de vista do cliente, se preocupando com o que vem de fora, onde o foco é sempre o cliente. É o cliente que determina através de suas experiências aquilo que é importante para a empresa, o que gera valor para concepção dos seus produtos e serviços. A visão do cliente consiste em conhecer a organização pelo lado de fora, tem a ver com o valor percebido, se o cliente está ou não satisfeito.

O gerenciamento de processos consiste na experiência do cliente como ponto de partida para o desenho e implementação de processos. Os processos são desenhados em torno deste relacionamento do cliente com os produtos, serviços e pontos de contatos (momentos da verdade) que devem ser conhecidos pela organização para alcançar a real necessidade e satisfação de seus clientes.

Mas você pode estar se perguntando, como entender de fato as necessidades do cliente? Existe uma fórmula mágica para isto?

O que existe hoje são técnicas e métodos utilizados para “trazer o cliente” para análise e redesenho dos processos, através de coleta de informações como pesquisas de opinião, avaliação dos comentários e reclamações do SAC, comentários enviados por pessoas através de sites como o “Reclame aqui”, e até mesmo workshops e entrevistas envolvendo o cliente. Redesenho é um repensar sob a ótica do cliente, é uma nova visão do negócio. Isso é transformação (construir processos com foco do cliente).

Não se trata mais de apenas oferecer um produto para um cliente, mas de entender a sua real necessidade. O foco assim é a percepção de valor do cliente, o que ele acha que é importante. Esta experiência de consumo leva o cliente a participar da criação do processo ponta a ponta, e permite a organização identificar atividades, que pela visão de “dentro para fora” (inside out), não seriam identificadas.

Vejamos o exemplo da tão conhecida IBM. Empresa de 103 anos de vida, que já passou por altos e baixos em sua história e ainda está no topo das empresas de TI. Mas como explicar sua longevidade? Como ela pode estar viva e próspera em um setor caracterizado pela inovação e a mudança? Dois pontos nos chamam a atenção: a cultura e a mudança.


Thomas Watson
, fundador da IBM, criou sua empresa baseado em três crenças básicas. Achamos relevante destacar uma delas: “Prestar o melhor serviço ao Cliente”. Tinha por base a satisfação e desejo do cliente, ou seja, a crença é direcionada ao cliente e as suas necessidades.

O segundo ponto relevante e mais significativo foi à busca pela mudança, pela transformação.
Em 1991 foi apresentada como a “Nova IBM”, voltada para a visão do mercado atual e obcecada pela qualidade. Segundo a própria IBM, a mudança foi causada pelo aumento do nível de exigência dos seus clientes, o que gerou a necessidade de criar valor para seus clientes.

A IBM de hoje não se considera uma empresa de tecnologia, mas uma empresa que resolve business problems usando a tecnologia. Segundo a IBM, ela não vende “brocas”, vende ferramentas para produzir “buracos na parede”, a IBM é focada nos trabalhos que seus clientes precisam que sejam realizados.

Quem já assistiu o filme “Quero ser Grande” (Big, 1988) estrelado Tom Hanks, percebe uma ligação da história com a visão “outside in”.

No filme, Josh (Tom Hanks) se torna adulto da noite para o dia, e conhece o Sr. MacMillan, dono de uma empresa que fabrica brinquedos (naquela clássica cena do The Big Piano). Confira aqui a cena do filme.

O dono da empresa comenta com ele sua preocupação de que não estão obtendo boas vendas, e Josh acaba ganhando o emprego porque começa a expor para a empresa a visão do cliente (ele como criança em corpo de um adulto).

Com o foco do cliente, os produtos desenvolvidos pela empresa se tornam muito mais atraentes aos consumidores, e a empresa volta a gerar crescimento.

O foco hoje não pode ser mais o produto ou o lucro que este lhe proporciona, mas a experiência vivida pelo cliente ao consumi-lo. O cliente de hoje procura ser compreendido e ter suas expectativas atendidas. Para a organização fica a responsabilidade de conhecer seu cliente e entender porque ele procura pelo seu produto ou serviço. Conhecer o cliente e atender suas necessidades é um desafio, e deve ser encarado como uma grande oportunidade de crescimento para a empresa e para a geração de novas soluções inerentes ao mercado atual.

Na hora de escolher a plataforma de BPM…

"Mas o que é mesmo que nós precisamos?"

O fato da iProcess ser uma consultoria com longa história, construída no estudo e implementação de soluções para processos através de tecnologias como workflow e BPMS, nos coloca em uma posição bastante interessante em relação ao mercado: entendemos como as soluções de automação funcionam, como é a sua arquitetura, o que as faz iguais e diferentes.

Isso possibilita dizermos então que nossa ferramenta favorita é, na verdade, a solução que mais se encaixa nas necessidades organizacionais, financeiras, culturais e tecnológicas dos nossos clientes.

É por isso que, quando as pessoas nos comentam que estão testando as soluções X, Y e Z e nos perguntam qual indicaríamos, ou qual é o melhor, a nossa resposta é “depende”. Depende porque, em nossos anos de experiência automatizando processos, chegamos à seguinte conclusão: não é uma questão de qual software é melhor comparado a outro software, mas qual é o software que melhor se encaixa às reais necessidades da organização.

Descobrir a solução que apresenta a melhor relação de custo e benefício em BPM requer uma análise que vai além de verificar funcionalidades que uma tenha e a outra não. Ela passa por questões como:

      • “Qual o tamanho da organização em termos de usuários e sistemas que integram os processos de negócio, e qual a perspectiva de crescimento para os próximos anos?”
      • “Como a companhia está estruturada – ela existe em um local centralizado ou se espalha por diferentes locais e regiões? Qual o impacto disso nos usuários dos processos automatizados? Precisamos de um software que suporte multi-línguas e multi-moedas?”
      • “A infraestrutura de TI da organização já tem um direcionador de plataforma tecnológica que pode impactar nesta decisão?”
      • “O que mais a organização precisa deste software além da simples automação dos passos a serem executados no processo automatizado? Monitoramento e ação em tempo real? Arquitetura dos processos de negócio? Ferramentas e metodologias de análise de processos? Posso ter isto em apenas um software ou precisarei de múltiplas ferramentas para cobrir meu ciclo de melhoria contínua de processos?”
      • “Que tipo de processos planejamos automatizar? Quantos? Com que frequência eles são executados, e o software está preparado para gerenciar a quantidade de instâncias?”
      • “O processo que modelamos é o processo que será executado, ou precisa ser transformado em outras linguagens antes de rodar, como do EPC para BPMN, ou do BPMN para BPEL, ou ainda de uma notação gráfica para algo que só o BPMS entende? Consideramos isto aceitável?“
      • “Que outras soluções de software precisarão ser integradas: ERP, BRM, BAM, ECM, etc?”
      • “Que tipo de suporte o fornecedor da solução está preparado para oferecer enquanto desenvolvemos a automatização do processo e após a implantação?”
      • “Onde encontramos profissionais que conheçam o software com a profundidade suficiente para implementar as complexidades naturais dos processos, que vão além do simples workflow de sequência de atividades?”
      • “O quão sólida é a empresa por trás do software – quais os riscos do mesmo ser adquirido por outra empresa gerando mudanças e mais mudanças na plataforma?”

Você percebe que dependendo da organização, o peso e a resposta a essas perguntas podem gerar avaliações bem diferentes?

São tantas questões que precisam ser consideradas neste processo de escolha – e que vão além da simples comparação de funcionalidades, que já consolidamos uma planilha de avaliação com centenas de critérios a avaliar (e que inclusive faz parte do nosso treinamento e pacote de consultoria em Seleção de Plataformas de BPM).

É claro que boas opiniões de quem já usa a ferramenta são essencialmente importantes. É parte do processo de escolha de uma plataforma, mas pode não ser a resposta para a organização.

Há tanto software de BPM sendo oferecido no mercado, que recomendamos sempre que antes de escolher uma ou outra solução para “testar”, por sorte ou porque alguém disse que era boa, considere as reais necessidades da organização – e então escolha aquelas sobre as quais realmente vale a pena investir tempo na avaliação.

Nossa equipe já atuou em projetos utilizando diferentes soluções de BPM. Todas elas são muito boas. É apenas uma questão de entender quais as verdadeiras necessidades da empresa.

Veja mais artigos sobre o tema da escolha de plataforma de BPM publicados aqui mesmo no blog da iProcess:

 


O que BPM tem a ver com requisitos de software? Tudo!

Muitas organizações estão buscando adotar BPM (Gestão por Processos de Negócio) como disciplina gerencial. Isto quer dizer que a empresa começa a se organizar e ter seus negócios gerenciados com base em processos de negócio bem estabelecidos, que definem o quê a organização realiza para transformar matéria prima (ou informações) em produtos e serviços.

Conhecer os processos leva a uma série de benefícios para a gestão da organização, mas de forma especial:

  • Possibilita ter uma visão mais clara de como os clientes participam do negócio da empresa
  • Possibilita que a empresa se organize ajustando seus processos para atender os objetivos do planejamento estratégico
  • Possibilita olhar para o quê e como as áreas da empresa interagem para entregar produtos e serviços, de ponta a ponta (do recebimento de materiais/informações, passando por todas as etapas de transformação e agregação de valor até que o produto/serviço seja entregue).

Com isso, torna possível também à organização identificar situações onde pode gerar grande inovação, destacando-se no seu mercado por um produto de muito mais qualidade, ou muito menor custo – tendo como meta atender à expectativa dos clientes.

Então o processo de negócio bem definido nos ajuda a entender o quê a organização faz, não apenas dentro das áreas, mas também como o processo passa de uma área para a outra.

E o que isto tem a ver com requisitos de software?

Sabendo o quê é preciso fazer (e eliminando aquilo que é feito sem necessidade), a organização pode definir melhor como faz. E o como passa pelos recursos utilizados, inclusive, de software. Como uma pessoa realiza uma determinada atividade de um processo? Usando o sistema X. E o que é necessário para ela interagir com os sistemas nesta etapa do processo? Isso é que determina, da forma mais assertiva, os reais requisitos de software que o sistema precisa ter para que as pessoas façam o que precisa ser feito e como deve ser feito!

As integrações entre sistemas, as interfaces e casos de uso para a interação do usuário com o sistema, quais informações o usuário precisa obter, gerar, editar para poder concluir aquela atividade – tudo isso pode ser identificado e definido com maior clareza se temos a visão do processo.

Pense só: com a visão de processo, é possível identificar claramente que informações um participante de processo precisa gerar, para que os participantes das próximas etapas (que estejam por exemplo em outras áreas) possam fazer a sua parte. E com isso, conseguimos definir de forma assertiva tudo o que (e nada mais que) o usuário precisa fornecer em termos de dados no sistema para que o trabalho continue sendo realizado nas áreas seguintes com o menor risco de falta de informações e de erros possível.

Nós da iProcess (junto com muitos profissionais de processos que atuam na frente de tecnologia) acreditamos que o processo de negócio deve guiar a identificação dos requisitos de software. Esta abordagem se reflete na qualidade e aderência do software às necessidades do negócio quando a solução é implantada.

Veja resultados efetivos dessa abordagem nos cases implementados da iProcess.