BPM – Integrando Pessoas e Sistemas

1.    Perspectiva orientada a processo

As novas estratégias para redução dos problemas encontrados no ambiente organizacional, os novos modelos de gestão e as práticas aplicadas no ambiente operacional têm acelerado o nível de interesse por parte dos CEO’s, CIO’s, CFO’s e demais componentes do board executivo para o mercado de BPM. Motivada por fusões, aquisições, novas diretrizes, compliances legais, regulatórios ou competitivos, a complexidade dos ecossistemas empresariais evolui constantemente. Não sendo difícil encontrar fatores adicionais que influenciem o universo dos negócios.

Após o investimento de muitas empresas em esforços relacionados à reengenharia de processos na década de 80 e 90, alcançando resultados nulos ou até negativos nos projetos, as lições aprendidas e as armadilhas criadas pela má execução da reengenharia de processos geraram novos gaps dentro das corporações. Esse foi um dos gatilhos para que uma nova onda surgisse, trazendo para dentro das organizações uma miscelânea de sistemas especialistas, apoiada pela crescente força da Tecnologia da Informação. Naquele momento, o ERP standalone não era mais capaz de satisfazer todas as necessidades do negócio. Assim, a TI das organizações iniciava uma corrida contra o tempo, passando a adquirir, desenvolver e implementar, com baixo planejamento e com análises superficiais soluções complementares de produção e operação como CRM, SCM, SRM, MRP, Web-Enabled, Procurement, entre outros.

A implantação dos sistemas focados em processos específicos, com alta complexidade para customização das regras de negócio e fluxo do processo criou um guarda-chuva heterogêneo, sem padronização, para cobrir as necessidades do negócio. O foco das implementações eram aplicações data-centric, ou seja, o input e output das informações eram os requisitos dos sistemas para a TI, não o processo, com isso, qualquer necessidade de mudança no processo impactava em alto nível de codificação, fato esse que poderia ser mitigado com uma abordagem process-centric.

Com o surgimento do EAI (Enterprise Application Integration), uma nova perspectiva para os sistemas legados pôde ser empreendida. Ultrapassando os limites organizacionais, as soluções existentes em empresas parceiras podiam transacionar dados de forma segura. No entanto, qualquer mudança nas tecnologias empregadas, causava grande impacto para a integração desenvolvida, uma vez que essa era altamente acoplada e dependente das tecnologias presentes nas duas pontas.

Figura 1 – Exemplo ilustrativo do modelo de integração de alto acoplamento (ponto-a-ponto).

A integração pouco flexível era apenas um dos problemas a serem geridos. Existia (e existe ainda) a constante demanda gerada pelo negócio em busca da melhoria nos processos. Essa necessidade alavancou o uso das soluções de workflow, que garantiam a execução de processos menos complexos sem demandar esforço dos times de TI, de modo que, os gestores de negócio perceberam rapidamente o potencial dessas ferramentas na gestão de suas equipes.

A crescente utilização das ferramentas de workflow resultou no aumento da complexidade dos processos que estavam sendo automatizados, consequentemente gerando novas exigências aos times de TI. Dentre essas, surgiam necessidades como:  gerar e controlar documentos durante a execução dos processos, decisões automáticas baseadas em regras de negócio pré-definidas, padronização na representação visual dos processos, aderência às normas de qualidade, indicadores de desempenho dos processos, integração com os sistemas de gestão, simulação de processos, entre outras necessidades. Esses requisitos desencadearam uma nova onda no início dos anos 2000, chamada Business Process Management (BPM).

2.    BPMS – Integration e Human Centric

Definir uma solução de BPM pode não ser uma tarefa tão simples, principalmente, quando encontramos vários recursos pertinentes a esse contexto em ferramentas distintas, solucionando diferentes necessidades.

A confusão começa com processos que requerem grande interação entre pessoas (person-to-person), muitas dessas ferramentas, algumas nascidas na década de 90, “revestiram suas roupagens” e foram para a Web adicionando BPM ao nome. No entanto, um BPMS gerencia processos person-to-person, system-to-system, ou ainda, processos com combinação entre os dois termos (e.g. person-to-system). Além disso, uma solução de BPM deve incluir recursos avançados de modelagem de processos (e.g. BPMN-compliant), portabilidade (e.g. XPDL, BPEL), gerador de códigos (e.g. J2EE), formulários eletrônicos (e.g. Xforms), engine de execução de processos, BRE’s, BAM, ferramenta de análise (e.g. BI + OLAP), UI customizáveis, recursos para integração out-of-the-box agregado ao suporte para integração via Web Services, SOA-based e simulação de processos.

O conceito de simulação de processos tem alcançado um papel de destaque nas soluções de BPM por possibilitar a simulação de cenários de execução após a definição do modelo AS-IS, prevenindo a publicação de processos custosos, ou ainda, processos falhos. Além disso, algumas ferramentas permitem a otimização de processos já automatizados baseando-se em dados históricos. Tais ferramentas de simulação de  processos devem ainda permitir a associação de custos, recursos, executores e apresentar informações estatísticas dos eventos ocorridos em tempo de execução.

A figura abaixo ilustra o suporte do SoftExpert BPM ao conceito de simulação de processos. A ferramenta se utiliza de cálculos probabilísticos ou determinísticos para distribuição das rotas, além de incluir animação gráfica, controle de velocidade e informações estatísticas durante a execução da simulação.

Figura 2 – Processo sendo simulado no SoftExpert BPM.

Muitos players do mercado de BPMS mantêm sua herança no core competence da organização, dessa forma, para melhor avaliação dos recursos providos por cada solução e para que as reais necessidades de gestão de processos sejam atendidas, o mercado segmentou as soluções de BPM em duas categorias principais: human-centric e integration-centric. Pode-se afirmar que os human-centric BPMS (HC-BPMS) derivam-se

das soluções de workflow usadas para coordenação de atividades e tarefas humanas, que incluíam ou não, tramitação de documentos durante seus fluxos de execução. Já os integration-centric BPMS (IC-BPMS) têm suas raízes nos sistemas de EAI, os quais representavam um mercado dominado por frameworks proprietários, mas que hoje, de forma crescente, constituem soluções baseadas em padrões abertos, SOA-based e, nos últimos anos, vêm sendo aprimorados com recursos de ESB (Enterprise Service Bus).

NOTA: Alguns especialistas utilizam a definição front-office e back-office BPMS, para os conceitos de human-centric e integration-centric respectivamente.

Os IC-BPMS potencializam o desenvolvimento de aplicações compostas e focam na integração entre os sistemas, estendendo os processos de negócio além dos limites da organização. As ferramentas de IC-BPMS contemplam recursos do tipo model-driven para construção das aplicações baseadas em serviços, onde através da orquestração e coreografia de serviços disponíveis nos repositórios SOA, o reuso de componentes promove redução expressiva em codificação para novas implementações, reduzindo uma demanda de alto custo para a TI.

Através do desenvolvimento de aplicações compostas, as respostas para as necessidades apresentadas pelo negócio podem ser realizadas de forma dinâmica, seja, alterando o fluxo do processo de negócio, invocando serviços novos ou existentes no repositório, ou ainda, definindo novas regras de negócio para tratamento das informações pertinentes aos processos.

As soluções de BPM focadas na interação humana, os HC-BPMS, suportam a tomada de decisões e julgamentos realizados por pessoas durante a execução de seus fluxos. Geralmente, estas soluções trazem de maneira embutida, ferramentas para colaboração entre os usuários na realização de tarefas que requerem maior interação humana.

No contexto dos HC-BPMS, uma característica que deve estar muito visível aos patrocinadores e responsáveis pela escolha da ferramenta que será utilizada, é quais tipos de processos com interação humana serão alvos da automatização. Isso porque dentro desta grande categoria de soluções existem dois tipos muito relevantes e de alto impacto para o sucesso do projeto, que são os processos orientados a documentos e registros (document-centric) e os processos que envolvem vários níveis de decisão, rotas e aprovações por seus respectivos participantes.

Entre as várias funcionalidades baseadas em colaboração que um HC-BPMS deve oferecer, duas delas merecem atenção especial. A primeira seria suportar a criação de tarefas ad hoc durante o processo em execução, gerando novos ramos na instância, permitindo que sejam facilmente manipuladas e possuam o mesmo nível de rastreabilidade exigido para o fluxo principal, mapeado previamente. A outra funcionalidade diz respeito ao tratamento de exceções, onde várias situações comuns do ambiente organizacional não podem ser previstas no modelo AS-IS ou TO-BE do processo e requerem ações pontuais durante a execução das atividades. Alguns exemplos como: retorno de atividades durante a instância do processo, cancelamento de um determinado ramo da instância, definição de executores dinamicamente, escalonamento de pendências, alteração do executor designado afetando apenas a instância são alguns dos recursos essenciais para o tratamento de exceções.

Alguns BPMS oferecem ainda um dashboard operacional, que pode ser parte integrante de um BAM (Business Activity Monitoring) ou, simplesmente, funcionam como um cockpit para os usuários realizarem suas ações de maneira dinâmica.

O SoftExpert BPM possui um dashboard operacional que proporciona aos   usuários o acesso dinâmico aos processos e atividades dentro de um único ambiente, conforme ilustrado abaixo:

Figura 3 – Dashboard para acesso rápido e controle das instâncias no SoftExpert BPM.

Por fim, para alcançar um rápido ROI através de uma estratégia de BPM sustentada por um BPMS, seja esse orientado a pessoas ou a sistemas, comece desenvolvendo seu business case, mantendo o foco sobre os core processes e especificando claramente os requisitos e expectativas do negócio, a fim de estabelecer a melhor abordagem para a implementação corporativa de um BPM human-centric, integration-centric ou ambos.

Arquivado como:BPM - Business Process Management, Blogroll, IT Value , BPM, Human-centric, SOA, SoftExpert

BPMM – UM ROADMAP PARA MELHORIA CONTÍNUA NA GESTÃO POR PROCESSOS

1. O Paradigma da Maturidade Corporativa

A introdução de um modelo para avaliação da maturidade dos processos em uma organização, é algo ainda novo para grande parte dos analistas e gerentes de processos no mundo do BPM, inclusive para alguns admiradores mais antigos da famosa reengenharia de processos, discípulos de Michael Hammer.

Atualmente, existem vários “best practices”, metodologias e frameworks no mercado para execução destes “assessments”. No entanto, as práticas de avaliação (assessments) mais difundidas carecem ainda de padrões de facto para maior credibilidade em sua aplicação, somada à freqüente ausência de foco nos “core processes” da organização por tais metodologias.

Dessa forma, os executivos de muitas corporações acabam mantendo seu ceticismo quanto aos procedimentos de diagnóstico utilizados pelas consultorias especializadas. Porém, tornam-se reféns da competitividade estabelecida no mercado, obrigando-os a continuarem na sua busca interminável pela redução de custos, maximização de resultados e alcance de metas, ou seja, efetividade total nos negócios. O resultado disso são investimentos pesados em consultorias que nunca saem do papel, ou então, quando aplicadas, dependem de alta disponibilidade da TI, que inicia a peregrinação na busca de tecnologias para suportar as demandas geradas pelo negócio. Frequentemente as soluções disponíveis não possuem aderência suficiente aos requisitos gerados, ou seja, a batalha contra os gaps, que ocorrerão entre a expectativa da gestão e o que deverá ser implementado como suporte as novas estratégias, marca seu início.

Em virtude dos aspectos citados acima, complementados ainda pela carência de padrões para análise da maturidade de processos de negócio, algumas empresas buscam frameworks, normas e padrões como ITIL, COBIT, COSO, ISO 9000, SOX, OHSAS, FDAs, entre outros, para suprir suas necessidades de melhoria dos processos, compliance regulatórios e potencializar a sustentação do negócio. No entanto, devido ao dinamismo da atual economia,, as mudanças diárias nas estratégias e ações dentro das organizações, somadas a busca incessante por melhores resultados,, forçam os gestores, principalmente os visionários por processos, a buscar a solidificação de sua arquitetura de processos de negócio. Nesta busca, as empresas iniciam a implantação de um novo conceito, como os já citados, sem muitas vezes analisar a demanda tecnológica que será gerada, o skill das pessoas que farão parte dos processos, o resultado financeiro para a organização e principalmente a maturidade da organização relativa à gestão por processos. Com a inobservância destes fatores, a expectativa dos gestores com a estratégia de orientação aos processos, acaba sendo frustrada em virtude do corte de alguns passos importantes na fase de implantação do novo conceito. Essa questão poderia ser minimizada com uma análise preliminar de avaliação da maturidade dos  processos de negócio que estão em operação na organização.

2. A Necessidade dos Padrões Aplicados ao BPM

Na visão atual de gestão por processos, o BPM (Business Process Management) pode ser definido como o guarda-chuva para todo o ciclo de vida de um processo de negócio, cobrindo desde a descoberta do processo até sua implementação. Para tanto, os  conceitos e padrões existentes devem ser aplicados aos processos resultantes refletindo em melhorias com impacto no negócio.

Para sustentar a evolução do conceito de BPM, órgãos internacionais, amparados  por grandes fabricantes de soluções e componentes de BPM (BPMS), têm empreendido esforços na padronização de implementações dentro das soluções de BPM. Entidades mundiais como WfMC, OMG (BPMI.org), OASIS, W3C são responsáveis por prover os padrões mais utilizados hoje pela indústria de BPM, embora ainda existam muitos desenvolvedores com suas “black boxes”. O mercado tem forçado a adoção dos principais padrões como premissas para as soluções de BPM. Um exemplo proeminente é o caso do BPMN, hoje, considerado pela indústria, um padrão para modelagem de processos de negócio, sendo, inclusive, requisito explícito em RFPs no Brasil e no mercado externo, assim como, em editais de licitação lançados pela iniciativa pública. Os padrões evoluem baseados nas necessidades salientadas pelo mercado. Acompanhando essa perspectiva, pode-se observar na imprensa relacionada à TI, uma infinidade de casos de insucesso nas implementações de soluções de BPM, gerando milhões de dólares em gastos com projetos falhos, antes mesmo do término.

Nestas ocasiões, grande parte dos analistas culpa a tecnologia empregada, ou a falta de capacidade do fornecedor, como motivo do fracasso. Contudo, a maior parte dos casos de insucesso, tem como causa raiz, o estado de maturidade da organização em relação aos processos que estão sendo implementados. Os problemas detectados como causa de insucesso, em sua maioria, são justamente as fraquezas da organização frente aos processos de negócio que estão sendo implementados. Portanto, para potencializar a organização para um estado de prontidão, que permita a implantação de uma solução tecnológica de BPM, fabricantes como Adobe, Borland, Unisys, Lombardi, entre outros, uniram-se para a criação de um modelo de maturidade de processos de negócio, o BPMM (Business Process Maturity Model). Este foi submetido ao OMG, no formato de uma RFC (Request for Comment), para que seja adotado como padrão pelo mercado de BPM.

3. Gestão da Qualidade – A Evolução do CMM até o BPMM

O desenvolvimento do Business Process Maturity Model (BPMM) teve seu início em 2002, porém, o conceito de melhoria contínua e os graus de maturidade para processos podem ser identificados há mais tempo.

A gestão da qualidade, como se vê atualmente, teve seu início entre os anos de 1920 e 1930 através de Walter Shewart, com seus trabalhos de pesquisa na Western Eletric e Bell Telephone. O trabalho de Shewart foi continuado por W. Edwards Deming nos anos 70, criador do famoso ciclo de Deming ou ciclo PDCA em conjunto com Joseph M. Juran. Mais tarde, já nos anos 80, Watts Humprey, funcionário da IBM na época, explorou o tema de como melhor introduzir o conceito de gestão da qualidade em uma empresa de desenvolvimento de software. A sua abordagem, baseada em estágios de maturidade, foi base para a primeira versão do CMM (Capability Maturity Model), publicada em 1991.

No início de 2002, o Nedbank contratou a empresa TeraQuest Metrics para implantar o conceito de CMM for Software em seu processo de desenvolvimento. Em pouco tempo, o CEO do banco percebeu o valor agregado que haviam conquistado através da maturidade crescente em seu processo de desenvolvimento, por isso, solicitou à TeraQuest Metrics o desenvolvimento de um modelo semelhante ao CMM para outros  processos de negócio do banco, responsáveis por 80% das operações realizadas diariamente. Já no início, os stakeholders do projeto perceberam a importância dos estudos para a comunidade internacional. Com isso, definiram que não seria um projeto focado apenas às necessidades do Nedbank, mas que pudesse ser constituído na forma de um framework para o mercado, dando início ao Service Operations CMM. Com a nova visão do projeto, os autores decidiram migrar o Service Operations CMM para dentro do BPMM. Com isso alavancaram novas iniciativas, principalmente após a aquisição da TeraQuest pela Borland.

4. Desafios do BPMM

O BPMM é orientado a analistas e gestores relacionados aos processos de negócio da organização, seja de produtos ou serviços, internos ou externos. Pode ser aplicado de forma exclusiva ou complementar, atuando como um framework para os esforços de melhoria em outros modelos como, por exemplo, COBIT, ITIL e ISO 9000.

A especificação BPMM é dirigida a pelo menos cinco desafios para o sucesso das implementações de BPM nos ambientes empresariais atuais:

1. Atualmente, a gestão tem poucos padrões para avaliação do grau de maturidade dos workflows de processos de negócio e necessita de métodos provados para identificar riscos e fraquezas, antes de executar projetos de tecnologia para automação dos processos, a fim de alcançar os objetivos denegócio.
2. A gestão tem poucos métodos provados para avaliar o grau de fidelidade entre as representações descritas no modelo base do processo, e como, realmente as tarefas são executas na prática. Este problema compromete a validade dos requisitos do sistema, a acurácia dos casos de uso e a real eficiência e eficácia da aplicação durante seu uso.
3. Com freqüência, a gestão é inconsciente de que o crescimento orgânico e as aquisições/fusões têm resultado em múltiplos métodos de execução para tarefas similares. A criação de padrões e processos adaptáveis simplifica os requerimentos para as aplicações empresariais, reduzindo a complexidade dos sistemas de BPM.
4. As organizações possuem poucos métodos provados para avaliar a capacidade de entrega dos serviços contratados por meio de outsourcing, para qualquer tipo de serviço, dentro de parâmetros exigidos em uma proposta. É necessário uma base comprovada para especificar requerimentos de melhoria nos processos de negócio do fornecedor.
5. A gestão necessita de orientação sobre como implementar processos de negócio fundamentais e requeridos para agilidade organizacional e custos operacionais mais baixos.

5. Princípios do BPMM

O Business Process Maturity Model (BPMM) segue rigorosamente o CMMI, permitindo o mapeamento do BPMM para o CMMI, mantendo a relação de estágios de maturidade. No entanto, o BPMM é escrito para ser utilizado como um guia de melhoria contínua para processos de negócio. Dessa forma, tende a ser mais transacional, ou seja, focado em workflows de negócio que possuem atividades além dos limites organizacionais e que possam ser mapeadas. Já o CMMI assume uma visão mais orientada a projeto, onde as atividades podem se desdobrar em várias outras tarefas de execução exclusiva.

O Business Process Maturity Model (BPMM) possui alguns princípios, como:

• Atributos de um processo podem ser avaliados para determinar sua capacidade de contribuir para os objetivos da organização.
• Processos qualificados podem não sobreviver a menos que a organização possua maturidade suficiente para mantê-los.
• A melhoria contínua de processos é melhor introduzida como sendo um programa de mudanças organizacionais que busca sucessivamente aumentar a capacidade da organização.
• Cada estágio ou nível de maturidade traça fundamentos requeridos nos quais as futuras melhorias podem ser construídas.

6. BPMM – Os Níveis de Maturidade do Modelo

O BPMM é dividido em cinco níveis de maturidade, assim como todos os modelos  baseados no Process Maturity Framework. Cada estágio representa a maneira como a organização é transformada na medida em que seus processos e capacidades são aperfeiçoados.

Nível 1 – Initial
Processos executados de maneira ad hoc, gerenciamentoinconsistente e com resultados difíceis de prever.
Nível 2 – Managed
A gestão equilibra os esforços dentro das unidades de trabalho, assegurando que estes sejam executados de uma maneira que se possa repetir o procedimento e satisfazer os compromissos primários dos grupos de trabalho. No entanto, outras unidades de trabalho executando tarefas similares podem usar diferentes procedimentos.
Nível 3 – Standardized
Processos padrões são sintetizados com base nas melhores práticas identificadas pelos grupos de trabalho, e procedimentos de adaptação são providos para suportar diferentes necessidades do negócio. Processos padronizados fornecem uma economia de escala e base para o aprendizado através de meios comuns  e experiências.
Nível 4 – Predictable
As capacidades habilitadas pelos processos padronizados são exploradas e devolvidas às unidades de trabalho. O desempenho dos processos é gerenciado estatisticamente por todo o workflow para entender e controlar a variação, de forma que, os resultados dos processos possam ser previstos ainda em estados intermediários.
Nível 5 – Innovating
Ações de melhorias pró-ativas e oportunistas buscam inovações  que possam fechar os gaps entre a capacidade atual da organização e a capacidade requerida para alcançar seus objetivos de negócio.

Os níveis de maturidade (2 a 5) são compostos por áreas de processos que coletivamente habilitam a capacidade respectiva de cada nível. A área de processo é desenhada para alcançar metas específicas na criação, suporte e sustentação do estado organizacional característico de cada nível. Cada área de processo é constituída por uma coleção de melhores práticas integradas que indicam O QUE deve ser feito, mas não COMO deve ser feito. Assim, as organizações ficam livres para definir seus próprios métodos e abordagens para satisfazer as metas e objetivos de cada área de negócio.

Estabelecer conformidade para o BPMM é diferente do que para especificações técnicas. Ou seja, avaliar a conformidade ao BPMM, não é igual a verificar, se os requisitos que um sistema tem implementado, estão de acordo com as especificações e requerimentos de uma especificação, mas sim, se o sistema implementado satisfaz as necessidades atuais do cliente.

A conformidade é avaliada seguindo algumas evidências:

1. Análise crítica dos artefatos produzidos pela execução de um processo.
2. Análise crítica dos artefatos que suportam a execução de um processo.
3. Entrevistas com pessoas ou grupos que executam um processo.
4. Entrevistas com pessoas que gerenciam ou supervisionam o desempenho de um processo.
5. Entrevistas com pessoas que sustentam o desempenho do processo.
6. Dados quantitativos usados para caracterizar o estado da organização ou a postura e comportamento daqueles dentro dela.
7. Dados quantitativos descrevendo o desempenho de um processo, seus resultados, e os resultados de negócio.
8. Conformidade aos princípios do BPMM.

7. Avaliação de Compliance ao BPMM

O BPMM prevê quatro tipos de avaliação, que variam conforme a duração e detalhamento das análises:

1. Starter Appraisal (Avaliação Inicial)

Superficial, de baixo custo e com rápida duração. Realiza-se um overview sobre a conformidade com o BPMM, as evidências não são analisadas em profundidade e poucas entrevistas são conduzidas. Dados quantitativos são coletados.

2. Progress Appraisal (Avaliação de Progresso)

Avaliação de todas as áreas de processo e práticas dentro do escopo do nível de maturidade. Estabelece o progresso no alcance de um próximo nível ou antecipa os resultados de uma Avaliação Confirmatória. Esta avaliação é demorada. Dados quantitativos são coletados e comparados aos resultados obtidos em entrevistas e análises dos artefatos.

3. Supplier Appraisal (Avaliação de Fornecedor)

Esta avaliação é semelhante à Avaliação de Progresso, no entanto, nenhum colaborador da empresa avaliada faz parte do time de avaliação. Normalmente é executada no processo de seleção de fornecedores. Dados quantitativos são coletados e as descobertas podem ser usadas para desenvolvimento de compromissos contratuais de melhorias que podem ser verificadas através de Avaliações de Progresso, de Fornecedor ou Confirmatória.

4. Confirmatory Appraisal (Avaliação Confirmatória)

Uma avaliação completa de todas as áreas de processo e práticas dentro do escopo do nível de maturidade avaliado. Este tipo de avaliação envolve todos os tipos de evidências descritas anteriormente. As evidências são testadas de um modo geral pela organização para assegurar que o time de avaliação tem capacidade suficiente para determinar a amplitude da conformidade. Dados quantitativos são coletados para investigar o desempenho e resultados das práticas. O time de avaliação testa se cada prática está sendo implementada e se alcança seus objetivos. As organizações podem declarar o atendimento de um nível de maturidade, somente, se estabelecido por uma Avaliação Confirmatória.

8. Aplicação do BPMM

O BPMM será usado inicialmente em quatro direções, que devem gerar diferentes exigências para as avaliações:

Guia para programas de melhoria de processos de negócio

O BPMM é desenhado para guiar programas de melhoria e este deve ser o uso mais freqüente do modelo. Este caminho deve ser iniciado por uma avaliação das forças e fraquezas da organização, composto ainda de uma Avaliação Inicial para prover as descobertas necessárias para iniciar um programa de melhoria. Avaliações de Progresso são suficientes para análise interna do status do nível de maturidade, no entanto, se a organização deseja publicar seu nível de maturidade, será requerida uma Avaliação Confirmatória.

Avaliação de riscos para desenvolvimento e distribuição de aplicações empresariais

O BPMM será usado para identificar riscos nas implementações de sistemas e prover orientação nas ações a serem tomadas para melhoria dos sistemas antes da distribuição. As informações para redução dos riscos serão derivadas das Análises de Progresso ou Confirmatória, e deve constar em contrato às ações de responsabilidade do cliente para a distribuição bem-sucedida da solução.

Avaliação da capacidade de fornecedores

O CMM for software foi originalmente desenvolvido para ajudar o Departamento de Defesa Norte-americano (DoD) a avaliar fornecedores além de menor preço. De forma similar, as organizações privadas precisam de padrões abertos e confiáveis para avaliar a capacidade de seus fornecedores em satisfazer suas necessidades de níveis de serviço, qualidade, preço e compromissos de funcionalidade. Para isto, as empresas poderão executar Avaliações de Fornecedores durante o processo de seleção e posteriormente aferir o desempenho no progresso de eliminação dos gaps encontrados, realizando Avaliações de Progresso ou Avaliações Confirmatórias.

Benchmarking

A gestão pode avaliar o posicionamento de sua organização em relação ao nível de maturidade de seus processos frente ao segmento de sua indústria. Avaliações de Progresso podem gerar informações de benchmark aproximadas, enquanto, Avaliações Confirmatórias fornecem resultados e medidas mais detalhados para realização do benchmark.

Os níveis de maturidade de uma organização fornecem um caminho para conhecer o desempenho da organização frente aos processos que esta executa e fornece. Estudos realizados por vários institutos internacionais têm comprovado de forma prática que as organizações que aplicam esforços na gestão de seus processos e conseqüente institucionalização têm alcançado resultados melhores em relação aos concorrentes do mesmo segmento.

O sucesso previsto na aplicação do BPMM se deve ao embasamento nos princípios estabelecidos no process maturity framework, que tem o CMMI como modelo difundido com maior amplitude. Embora hoje sejam estimados em torno de 200 modelos de maturidade existentes no mercado, poucos tiveram êxito na utilização em escala, pois muitos falam de melhores práticas, no entanto, não fornecem a infra-estrutura necessária de práticas que constituem o roadmap de melhoria contínua.

9. PEMM – Outro Modelo de Maturidade

Existem modelos mais recentes, como o Process and Enterprise Maturity Model (PEMM) que merecem uma análise mais detalhada, principalmente por se tratar de uma divulgação do Harvard Business Review e ser um modelo desenvolvido por Michael Hammer, co-autor do best seller “Reengineering the Corporation” (mais de 2 milhões de cópias vendidas).

Como overview, destaca-se que o PEMM distingue entre maturidade do processo e maturidade da organização. O modelo analisa o desempenho do processo por meio de cinco perspectivas, denominadas facilitadores (“enablers”):

1) Desenho, 2) Executores, 3) Proprietários, 4) Infra-estrutura, 5) Métricas.

Já a análise da organização se baseia em quatro capacidades (“capabilities”):

1) Líderes, 2) Cultura, 3) Expertise, 4) Governança

A principal abordagem deste modelo, segundo Hammer, é a “ajuda para executivos planejarem transformações baseadas em processos, rastrear o progresso e identificar obstáculos no caminho”. No entanto, podem ser destacadas também, algumas fraquezas no modelo, como, carência de conexão entre nível de maturidade e resultados financeiros para o negócio, falta de alinhamento estratégico e ainda a TI que não é vista como capacidade da organização.

10. Conclusão

Conforme citado anteriormente, existem vários modelos para avaliação de maturidade da organização e de seus processos, assim como best practices, metodologias, frameworks, normas e leis para pressionar a adequação das empresas aos  requisitos de mercado e potencializar vantagens competitivas. Desta forma, o propósito deste material não é apontar qual deve ser a escolha para execução das avaliações de maturidade, nem mesmo o modelo que deve ser adotado pelas empresas. Um dos objetivos é esclarecer que existem modelos para avaliar a maturidade dos processos de negócio, e que estes, devem ser estudados e estratificados. Pois, antes de se tornarem modelos de referência, foram patrocinados e, principalmente, aplicados por grandes corporações, que contribuíram de forma ostensiva para o seu amadurecimento.

O BPMM se baseia em conceitos inovadores, que podem gerar grandes resultados organizacionais se aplicados de forma correta e contínua, exatamente, porque o propósito de qualquer disciplina focada em “improvement” é a melhoria contínua, onde a gestão de mudanças também terá um papel importante e deve ser muito bem planejada e implementada.

Referências

CMMI Product Team. CMMI for Development Version 1.2. Pittsburgh, USA. Ago. 2006.

CURTIS, Bill; GARDINER, Tony; WEBER, Charles V. Business Process Maturity Model – Request for Comment (RFC). USA. Mar. 2007. Disponível em: http://www.omg.org. Acesso em 10 de julho de 2007.

HINTZ, Marco Aurélio. Institucionalização. Joinville. Ago. 2007. Disponível em: <http://www.softexpert.com.br>. Acesso em 28 de agosto de 2007.

INSADI. FBP 14.06.07Sustentabilidade. São Paulo. Jun. 2007. Disponível em: <http://www.insadi.org.br>. Acesso em 28 de agosto de 2007.

POWER, Brad. Michael Hammer’s Process and Enterprise Maturity Model. USA. Jul. 2007. Disponível em: <http://www.bptrends.com>. Acesso em 28 de agosto de 2007.

Arquivado como:BPM - Business Process Management, Blogroll, IT Value , BPM, BPMM, CMMI, maturidade de processos, Maturity Model, Modelo de Maturidade