BPM HOJE

Sempre que faço uma apresentação comercial, um dos primeiros slides analisados é uma adaptação de um conceito da Forrester Research, que divide os processos das empresas em diferentes categorias. Essa divisão não segue a separação tradicional entre processos de área fim X processos de área meio, mas sim propõe uma visão das características desses processos em relação a automação em ferramentas de BPMS. Por exemplo, algumas categorias poderiam ser: processos com alto fluxo de documentos, processos com alta interação humana, processos case management, processos “mecanicistas” (ou com alta integração), etc…

Após apresentar cada cluster, peço para o cliente identificar onde ele acredita que seus processos estão. É claro que uma empresa grande possui processos em todas as categorias, mas oobjetivo é identificar onde os processos que ele quer automatizar nesse momento estão. Dessa reflexão três caminhos podem surgir:

1. O cliente não sabe aonde estão: nesse caso, eu sugiro que ele pare imediatamente com o processo de seleção do BPMS, e contrate alguma consultoria para mapeamento dos processos, seleção de processos para automação e definição de objetivos de projeto. (radical, não?);
2. O cliente identifica que seus processos estão nas caixas A, B e C: nesse caso, a apresentação comercial prossegue;
3. O cliente identifica que seus processos estão nas caixas D, E e F: nesse caso eu paro com a apresentação e, às vezes, indico um ou outro BPMS que acredito que poderia ajudá-lo mais que o nosso;

De todos os casos, com certeza o mais polêmico é o primeiro. Prosseguir com o processo de compra nesse caso seria mais ou menos assim:

Selecionar a ferramenta -> Identificar o problema -> Corrigir o problema

Ora, a visão de software “canivete suiço”, que faz de tudo e mais um pouco e “resolve todos os seus problemas” é coisa do passado. A evolução dos padrões de integração permitem que pequenas soluções, especializadas, se integrem umas as outras e juntas, geram uma solução de maior valor. A abordagem mostrada acima é perigosa pois o risco da solução de BPMS comprada não conseguir resolver o seu problema é enorme. Álias, é isso que depois gera frustação e cases negativos em produtos de software. Na maioria dos casos, o software está sendo mal utilizado ou utilizado para coisas que ele não foi feito.

A abordagem correta com certeza seria:

Identificar o problema -> Selecionar a ferramenta -> Corrigir o problema

Nesse caso, o cliente possui uma visão clara de sua demanda, de seu escopo de projeto e de seus objetivos. Com base nessa informação, consegue montar um processo de seleção muito mais consistente e com maiores possibilidades de sucesso. E, é importante destacar, um projeto com escopo “queremos uma ferramenta corporativa para automatizar todos os processos da nossa empresa” ou “queremos uma ferramenta equilibrada que vai nos ajudar de alguma maneira em todos os nossos processos” está fadado ao fracasso. Não existe software “canivete suiço”.

Este conteúdo foi publicado em Sexta, 20 de Junho de 2008 às 10:49 e está arquivado em BPM e Workflow. Você pode acompanhar quaisquer comentários a esta publicação através do RSS 2.0. Você pode deixar uma resposta, ou link do seu próprio site.  | Enviar por e-mail  | Hits para esta publicação: 213