Maturidade de Processos de Engenharia: diagnóstico e roadmap

Entenda como avaliar a maturidade de processos de Engenharia com critérios, evidências, níveis e roadmap, sem confundir documentação, automação ou maturidade de PMO.

Confira!

Maturidade de processos é a capacidade de uma organização executar, controlar, medir e melhorar seus processos com consistência, reduzindo dependência de pessoas específicas e variabilidade desnecessária. Em Engenharia, avaliar maturidade não significa contar quantos procedimentos existem: significa verificar se os processos realmente produzem resultados previsíveis, se possuem responsáveis claros, critérios de entrada e saída, indicadores, controles proporcionais ao risco e mecanismos de melhoria.

Uma organização pode ter centenas de procedimentos e ainda operar de forma imatura se as decisões dependerem de conhecimento tácito, se diferentes áreas interpretarem o mesmo fluxo de maneiras distintas, se o retrabalho for recorrente ou se os dados não permitirem explicar por que prazos e resultados variam. O diagnóstico de maturidade deve, portanto, observar evidências do processo real e construir um roadmap de evolução coerente com a criticidade e com os objetivos do negócio.

O que é maturidade de processos?

Maturidade de processos descreve o grau de desenvolvimento de um processo ou de um sistema de processos em relação à sua capacidade de entregar resultados de modo estável, mensurável e passível de melhoria. Quanto maior a maturidade, menor a dependência de improvisação e maior a capacidade de aprender com dados, controlar riscos e sustentar desempenho ao longo do tempo.

A abordagem de processos da ISO 9001 trata os processos como partes inter-relacionadas de um sistema e associa seu controle à definição de entradas, saídas, responsabilidades, recursos, monitoramento, medição e melhoria. A maturidade acrescenta uma pergunta gerencial: com que consistência essas capacidades estão realmente implementadas e sustentadas?

Na Engenharia, essa pergunta pode ser aplicada a fluxos como:

entrada e qualificação de demandas;
desenvolvimento e revisão de projetos;
gestão documental;
análise e aprovação de documentos de fornecedores;
procurement técnico;
controle de mudanças;
RFI e esclarecimentos técnicos;
inspeções, RNCs e ações corretivas;
medição e aceite;
comissionamento e entrega;
gestão de interfaces entre disciplinas e organizações.

Maturidade de processo não é maturidade de PMO

O site já possui um conteúdo específico sobre diagnóstico de maturidade em Gestão de Projetos e PMO. A fronteira entre os dois temas é importante.

Maturidade de PMO observa capacidades ligadas à gestão de projetos, portfólio, governança, controles, metodologia, reporting, recursos e realização de benefícios. Maturidade de processos observa fluxos recorrentes, independentemente de estarem dentro de um projeto específico.

Um processo de aprovação documental pode existir em dezenas de projetos. Um fluxo de qualificação de fornecedor pode ser repetido por diferentes áreas. Uma rotina de tratamento de RNC pode atravessar projetos, contratos e unidades. É esse tipo de capacidade transversal que este artigo avalia.

Pergunta	Maturidade de processos	Maturidade de PMO
Objeto principal	fluxo recorrente	capacidade de gerir projetos/portfólio
Unidade de análise	processo e suas interfaces	projetos, programas, portfólio e PMO
Indicadores típicos	lead time, FPY, retrabalho, WIP, aging, SLA	SPI, CPI, forecast, governança, benefícios
Responsável central	process owner	sponsor, gerente, PMO/EPMO
Resultado esperado	estabilidade e melhoria do processo	previsibilidade e valor dos projetos

Processo documentado não significa processo maduro

Documentação é apenas uma das evidências possíveis. Um processo pode estar muito bem descrito e ser pouco aderente à prática. Também pode ocorrer o contrário: uma equipe experiente pode executar bem uma rotina, mas depender excessivamente de pessoas-chave e não conseguir escalar, transferir conhecimento ou manter desempenho quando há mudanças.

Sinais de falsa maturidade incluem:

procedimento atualizado, mas pouco utilizado;
fluxograma que não representa exceções reais;
controles executados fora do sistema formal;
aprovação que depende de mensagens paralelas;
indicadores produzidos apenas para reporte;
treinamento sem verificação de competência;
padronização excessiva sem relação com risco;
processo que funciona apenas porque uma pessoa experiente intervém constantemente.

A avaliação deve confrontar documento, prática, dados e resultado.

Maturidade do processo e maturidade da gestão de processos

A APQC diferencia maturidade de um processo específico e maturidade da gestão de processos como capacidade organizacional. Essa distinção ajuda bastante em Engenharia.

Um processo isolado pode ser maduro porque possui owner, critérios claros, indicadores e rotina de melhoria. Ao mesmo tempo, a organização pode ter baixa maturidade de gestão de processos se outros fluxos não seguem a mesma disciplina, se não existe arquitetura de processos ou se cada unidade define seus próprios modelos sem coordenação.

O contrário também pode ocorrer. A empresa pode possuir uma política corporativa de BPM, governança e ferramentas, mas certos processos críticos continuarem imaturos por falta de dados, competências, decisões ou integração com fornecedores.

Por isso, o diagnóstico deve definir previamente qual objeto está sendo avaliado:

um processo específico;
um grupo de processos relacionados;
uma cadeia ponta a ponta;
a capacidade corporativa de gerir processos.

Quais dimensões devem ser avaliadas?

Um modelo de maturidade útil precisa evitar uma nota única sem explicação. O resultado deve mostrar em quais capacidades o processo é forte ou fraco e quais gaps realmente afetam seu desempenho.

Uma estrutura aplicável à Engenharia pode avaliar pelo menos oito dimensões.

1. Propósito e fronteiras

O processo possui resultado esperado claramente definido? O início e o fim são reconhecidos pelas áreas envolvidas? Entradas, saídas e clientes do processo estão claros?

Processos imaturos costumam ter fronteiras ambíguas. Uma área considera que sua responsabilidade termina na emissão; outra entende que termina no aceite. A divergência aparece depois como atraso, devolução ou conflito de responsabilidade.

2. Ownership e governança

Existe um process owner ou uma função equivalente com mandato para acompanhar desempenho e promover melhorias?

Devem ser avaliados:

responsabilidade ponta a ponta;
direitos de decisão;
alçadas;
critérios de escalonamento;
tratamento de exceções;
mecanismos para resolver conflitos entre funções.

3. Padronização e método

A execução segue critérios minimamente consistentes? Existem instruções, checklists, modelos ou regras proporcionais à criticidade?

A maturidade não exige que tudo seja rigidamente padronizado. O objetivo é reduzir variação que não agrega valor e preservar espaço para julgamento técnico onde ele é necessário.

4. Competência e capacidade

As pessoas que executam ou aprovam o processo possuem competência adequada? A capacidade disponível é compatível com a demanda?

Um processo pode parecer imaturo por excesso de filas quando, na verdade, a principal restrição é de capacidade. Também pode aparentar falta de capacidade quando grande parte da carga é retrabalho provocado por entradas ruins.

5. Dados e rastreabilidade

É possível reconstruir o histórico de um item, identificar quem decidiu, quando ocorreu cada transição e qual informação sustentou a decisão?

Sem rastreabilidade, o diagnóstico fica dependente de percepção. Processos maduros preservam evidência suficiente para medir e aprender.

6. Indicadores e desempenho

O processo possui indicadores ligados ao resultado e às causas que explicam sua variação?

O artigo de Indicadores de Processos de Engenharia aprofunda lead time, waiting time, WIP, aging, throughput, first pass yield e retrabalho. Em um diagnóstico de maturidade, interessa saber se essas métricas existem, se possuem definição estável e se geram decisão.

7. Interfaces e integração

Os handoffs entre áreas, disciplinas, fornecedores e sistemas possuem critérios claros? As informações necessárias chegam completas à etapa seguinte?

A maturidade de um processo não pode ser avaliada apenas dentro das fronteiras de cada departamento. Muitas perdas aparecem justamente nos processos ponta a ponta.

8. Melhoria e aprendizado

Problemas recorrentes são tratados como eventos isolados ou alimentam melhoria estrutural? O processo possui mecanismos para analisar causas, revisar padrões e verificar eficácia das mudanças?

A maturidade cresce quando melhoria deixa de ser reação eventual e passa a integrar a rotina de gestão.

Maturidade não é quantidade de procedimentos. O diagnóstico precisa confrontar processo definido, prática real, dados e resultado para identificar onde a organização ainda depende de improvisação e quais capacidades precisam evoluir primeiro.

Conheça o Diagnóstico e Otimização de Processos de Engenharia

Um modelo prático de cinco níveis

Modelos de maturidade não precisam ser universais. O importante é que cada nível tenha critérios observáveis. Uma escala de cinco níveis pode ser útil para estruturar diagnóstico e roadmap.

Nível	Característica dominante	Situação típica
1 — Reativo	execução dependente de pessoas	cada caso é tratado de forma diferente
2 — Definido	existe método básico	processo está descrito, mas aderência varia
3 — Controlado	responsabilidades e controles funcionam	processo possui owner, critérios e rastreabilidade
4 — Gerenciado por desempenho	decisões usam indicadores	fluxo é medido e causas de variação são investigadas
5 — Adaptativo e melhorado	aprendizado contínuo	melhorias são priorizadas por evidência e risco

A escala não deve virar um rótulo simplista. O mesmo processo pode estar em nível 4 em rastreabilidade e nível 2 em governança. O valor do diagnóstico está justamente nessa decomposição.

Nível 1 — processo reativo e dependente de pessoas

No primeiro nível, o processo existe porque as pessoas fazem o trabalho, mas suas regras são pouco explícitas. A qualidade depende fortemente de experiência individual e relações pessoais.

Sinais frequentes:

ausência de fronteiras claras;
decisões caso a caso;
informações circulando por e-mail ou mensagens;
pouca rastreabilidade;
retrabalho tratado como normal;
prazos altamente variáveis;
dificuldade para substituir pessoas-chave;
indicadores inexistentes ou baseados apenas em volume.

Em Engenharia, esse cenário aparece quando uma revisão técnica funciona porque todos sabem “quem costuma resolver”, mas a organização não possui critérios consistentes de submissão, revisão, aprovação e retorno.

Nível 2 — processo definido, porém ainda instável

Aqui já existe alguma formalização. Procedimentos, fluxos e responsáveis foram definidos, mas o comportamento real ainda varia bastante.

É comum encontrar:

documentação parcial;
diferentes interpretações entre áreas;
controles manuais;
indicadores produzidos sem rotina de análise;
exceções frequentes;
desvios tratados fora do processo;
treinamento inicial sem reciclagem;
melhoria baseada principalmente em reclamações.

A principal evolução deste nível é fazer o processo sair do papel e se tornar executável no cotidiano.

Nível 3 — processo controlado e governado

No terceiro nível, o processo já possui estrutura suficiente para sustentar desempenho com menor dependência de indivíduos.

Evidências esperadas incluem:

fronteiras e resultado claros;
owner definido;
critérios de entrada e saída;
alçadas coerentes;
documentos e dados rastreáveis;
exceções registradas;
indicadores básicos;
rotina de revisão;
integração com processos correlatos.

Esse é um ponto importante porque muitas organizações tentam automatizar antes de chegar aqui. Digitalizar um processo de nível 1 ou 2 pode apenas transformar desorganização em workflow.

Nível 4 — processo gerenciado por desempenho

No nível 4, a gestão deixa de perguntar apenas se o procedimento foi seguido e passa a analisar o comportamento do sistema.

A organização acompanha tendências de:

lead time;
waiting time;
WIP e aging;
throughput;
retrabalho;
qualidade na primeira passagem;
exceções;
capacidade;
desempenho de fornecedores;
tempo de decisão.

Quando um indicador piora, existe uma rotina para investigar causa e tomar decisão. A medição é segmentada por criticidade e evita comparar objetos diferentes como se fossem iguais.

Nível 5 — processo adaptativo e orientado à melhoria

O último nível não significa perfeição. Significa capacidade institucional de aprender e evoluir de maneira contínua.

O processo é revisto com base em:

desempenho histórico;
mudanças de demanda;
riscos emergentes;
lições aprendidas;
feedback de clientes internos e externos;
evolução tecnológica;
alterações regulatórias;
benchmarking quando pertinente.

A melhoria não ocorre apenas porque alguém “teve uma boa ideia”. Existe governança para priorizar mudanças, testar impacto, padronizar o que funcionou e evitar que a organização perca controle durante a transformação.

Como diagnosticar maturidade sem cair em questionários genéricos

Questionários são úteis para orientar entrevistas, mas não devem ser a única fonte. Avaliação exclusivamente declaratória tende a superestimar maturidade porque as pessoas descrevem como o processo deveria funcionar.

Um diagnóstico robusto combina quatro tipos de evidência:

documentos: procedimentos, fluxos, matrizes, formulários, políticas e instruções;
dados: volumes, tempos, filas, devoluções, exceções, indicadores e históricos;
casos reais: amostra de itens concluídos, atrasados, devolvidos e críticos;
entrevistas: percepção de executores, gestores, clientes do processo e funções de interface.

A comparação entre essas evidências revela gaps relevantes. Se o procedimento diz que uma revisão deve ocorrer em três dias, os registros mostram oito e os usuários relatam que documentos incompletos entram na fila, o problema não é “falta de aderência” de forma abstrata; existe uma hipótese concreta de qualidade de entrada e capacidade a investigar.

Evidência vale mais do que percepção

A maturidade deve ser sustentada por evidências verificáveis. Isso evita diagnósticos excessivamente subjetivos e permite repetir a avaliação no futuro.

Exemplos de evidências:

Dimensão	Evidência possível
Governança	owner, matriz de decisão, atas de revisão
Padronização	procedimento vigente, checklist, critérios de aceite
Fluxo	registros de entrada e saída, timestamps
Qualidade	devoluções, RNCs, FPY, rejeição de entrada
Capacidade	demanda, throughput, backlog, carga por função
Rastreabilidade	histórico de revisões e aprovações
Melhoria	ações concluídas e verificação de eficácia

O diagnóstico deve registrar também evidências contraditórias. Um processo pode apresentar ótimo SLA agregado e, ao mesmo tempo, alto aging em itens críticos.

Não existe maturidade máxima necessária para todos os processos

Nem todo processo precisa chegar ao nível mais alto. O nível-alvo depende de risco, frequência, impacto, variabilidade e necessidade de rastreabilidade.

Um processo simples, de baixo risco e baixo volume pode operar adequadamente com controles básicos. Já um processo de aprovação técnica crítica, gestão de mudanças, inspeção ou liberação para comissionamento pode exigir rastreabilidade e governança muito maiores.

O erro é transformar maturidade em corrida para “nível 5”. O objetivo é estabelecer a capacidade necessária para produzir o resultado com risco aceitável.

Como definir o nível-alvo

O nível-alvo pode ser definido a partir de cinco perguntas:

qual o impacto de uma falha do processo?
qual a variabilidade de demanda e complexidade?
quantas interfaces e organizações participam?
qual rastreabilidade é necessária?
quanto desempenho precisa ser previsível para suportar decisões do negócio?

Quanto maior a criticidade e a interdependência, maior tende a ser a necessidade de governança, dados e controles.

Maturidade e gargalos

Baixa maturidade frequentemente se manifesta por gargalos, mas os conceitos não são iguais. Um processo pode ter um gargalo de capacidade mesmo sendo maduro. Também pode não apresentar fila aparente e continuar imaturo porque retrabalho e exceções estão escondidos.

O artigo de Gargalos em Processos de Engenharia aprofunda a análise de filas, capacidade, WIP, lotes e aprovações. Na avaliação de maturidade, esses sintomas ajudam a identificar quais capacidades ainda precisam evoluir.

Maturidade e arquitetura de processos

Uma empresa pode melhorar processos isolados e continuar com baixa maturidade sistêmica. Isso acontece quando não existe visão de cadeia de valor, quando macroprocessos se sobrepõem ou quando interfaces importantes não têm owner.

A Arquitetura de Processos de Engenharia ajuda a definir onde cada processo se encaixa e quais relações precisam ser consideradas no diagnóstico.

A maturidade corporativa aumenta quando melhorias locais são coerentes com essa arquitetura.

Maturidade e padronização

Padronização é uma capacidade importante, mas não deve ser confundida com maturidade inteira. Procedimentos rígidos podem coexistir com baixa capacidade de medir, governar ou melhorar.

O próximo estágio do cluster aprofunda justamente como padronizar processos de Engenharia sem burocratizar. No diagnóstico de maturidade, a pergunta correta não é “existe um procedimento?”, mas “o padrão ajuda a produzir resultado consistente e é ajustado quando as condições mudam?”.

Maturidade e automação

Automação costuma aparecer como símbolo de modernidade, mas tecnologia não define maturidade sozinha. Um workflow sofisticado pode executar regras ruins com grande eficiência.

Antes de automatizar, o processo deveria possuir ao menos:

objetivo claro;
fronteiras definidas;
critérios de entrada;
responsabilidades;
alçadas;
tratamento de exceções;
dados mínimos;
indicadores relevantes.

A solução de Gestão de Processos, Workflows e Aprovações Técnicas faz mais sentido quando a tecnologia materializa um processo já compreendido.

Automatizar um processo imaturo pode apenas tornar o problema mais rápido e menos visível. Ownership, critérios, alçadas, exceções e indicadores devem estar minimamente estabilizados antes de transformar o fluxo em workflow.

Veja como estruturar workflows e aprovações técnicas

Como construir um roadmap de maturidade

O diagnóstico só gera valor quando se transforma em decisões priorizadas. Uma lista extensa de gaps sem sequência cria outro problema de gestão.

Um roadmap pode ser estruturado em seis passos.

1. Relacionar gap e impacto

Cada gap deve estar ligado a um efeito observável: atraso, retrabalho, risco, perda de informação, custo, baixa previsibilidade ou dependência de pessoa-chave.

2. Identificar capacidades habilitadoras

Algumas melhorias desbloqueiam várias outras. Definir ownership pode vir antes de criar dashboards. Melhorar qualidade de entrada pode vir antes de aumentar capacidade. Estabilizar critérios pode vir antes de automatizar.

3. Separar quick wins de mudanças estruturais

Quick wins são úteis para demonstrar resultado, mas não devem substituir reformas necessárias em governança, dados ou arquitetura.

4. Definir estado-alvo

O roadmap precisa declarar qual capacidade se espera alcançar e como ela será reconhecida por evidência.

5. Vincular indicadores

Cada iniciativa deve possuir uma medida de resultado. Se a ação busca reduzir devoluções, acompanhe FPY ou taxa de rejeição. Se busca reduzir espera, acompanhe lead time e aging.

6. Reavaliar periodicamente

Maturidade não é certificação permanente. Mudanças de demanda, pessoas, sistemas e organização podem degradar capacidades anteriormente estáveis.

Exemplo de roadmap para um processo de aprovação técnica

Considere um fluxo com alto aging, devoluções frequentes e decisões concentradas.

Horizonte	Iniciativa	Evidência esperada
curto prazo	definir critérios mínimos de submissão	queda da rejeição de entrada
curto prazo	separar alçadas por criticidade	redução do tempo de decisão
médio prazo	formalizar owner e rotina de revisão	decisões registradas e recorrentes
médio prazo	medir lead time, aging e FPY	baseline confiável
médio prazo	redesenhar handoffs	menos retornos entre áreas
longo prazo	automatizar workflow estável	rastreabilidade e escalonamento automático

Esse tipo de sequência evita começar pela ferramenta e atacar sintomas antes das causas.

Como medir evolução de maturidade

O progresso não deve ser medido apenas por quantidade de ações concluídas. O objetivo é observar se capacidades e resultados melhoraram.

Indicadores possíveis incluem:

percentual de itens com dados completos na entrada;
aderência aos critérios de decisão;
redução de exceções manuais;
redução de aging;
aumento de FPY;
estabilização de lead time;
redução de dependência de pessoa-chave;
percentual de melhorias com eficácia verificada;
qualidade da rastreabilidade;
satisfação dos clientes do processo.

Um roadmap pode estar 100% concluído e o processo continuar ruim. A verificação de eficácia é indispensável.

Erros comuns em diagnósticos de maturidade

Atribuir nota sem explicar evidência

Uma nota “3 de 5” sem critérios claros dificilmente orienta decisão.

Copiar um modelo sem adaptar ao contexto

Modelos são referências, não substitutos para análise da organização.

Avaliar apenas gestores

Executores e clientes do processo frequentemente enxergam problemas diferentes.

Confundir ferramenta com capacidade

Ter BPMN, workflow ou dashboard não demonstra que o processo está governado.

Premiar excesso de documentação

Mais documentos podem aumentar burocracia sem melhorar resultado.

Ignorar interfaces

A maturidade local pode esconder problemas severos entre áreas.

Criar um roadmap impossível

Centenas de ações simultâneas diluem recursos e reduzem accountability.

Quando vale a pena contratar um diagnóstico de maturidade de processos?

A contratação faz sentido quando a organização percebe sintomas recorrentes, mas não consegue determinar se a causa principal está em método, governança, capacidade, interfaces, dados ou padronização.

Também é útil antes de iniciativas maiores de transformação, como implantação de BPM, revisão de workflows, digitalização, integração entre áreas, estruturação de governança ou programas de melhoria contínua.

Um diagnóstico consultivo deve entregar mais do que uma nota. O resultado esperado inclui:

escopo e arquitetura dos processos avaliados;
critérios de maturidade;
evidências coletadas;
gaps e forças por dimensão;
riscos associados;
nível atual e nível-alvo;
prioridades;
quick wins;
roadmap de evolução;
indicadores para verificar eficácia.

O serviço de Diagnóstico e Otimização de Processos de Engenharia foi estruturado para conectar essa análise à melhoria real do processo, evitando diagnósticos que terminam apenas em apresentação executiva.

Um roadmap de maturidade precisa ligar cada gap a impacto, evidência, responsável e indicador de eficácia. Sem essa conexão, a avaliação vira apenas uma fotografia da organização e não um instrumento de transformação.

Estruture um diagnóstico consultivo de processos

Considerações finais

Maturidade de processos de Engenharia não é quantidade de procedimentos, nível de automação ou nota obtida em um questionário. É a capacidade real de transformar entradas em resultados de forma consistente, governada, mensurável e adaptável.

O diagnóstico precisa combinar evidência documental, dados, amostras reais e percepção dos envolvidos. A leitura por dimensões permite distinguir problemas de ownership, padronização, capacidade, qualidade de entrada, rastreabilidade, indicadores e interfaces.

O roadmap deve priorizar capacidades habilitadoras e medir eficácia, não apenas conclusão de tarefas. Dessa forma, maturidade deixa de ser um exercício abstrato e se torna instrumento para reduzir risco, retrabalho e variabilidade nos processos de Engenharia.

Referências técnicas

[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). The process approach in ISO 9001:2015. Geneva: ISO, 2015. Disponível em: https://www.iso.org/files/live/sites/isoorg/files/archive/pdf/en/iso9001_2015_process_approach.pdf

[2] APQC. Business Process Management Maturity Benchmarks. Houston: APQC, 2025. Disponível em: https://www.apqc.org/resource-library/resource-collection/business-process-management-maturity-benchmarks

[3] APQC. What's the Difference Between Process Maturity and Process Management Maturity? Houston: APQC, 2024. Disponível em: https://www.apqc.org/resource-library/resource-listing/whats-difference-between-process-maturity-and-process-management

[4] APQC. APQC's Process Maturity Model. Houston: APQC, 2024. Disponível em: https://www.apqc.org/resource-library/resource-listing/apqcs-process-maturity-model

Perguntas frequentes

O que é maturidade de processos?

É o grau de desenvolvimento de um processo em relação à sua capacidade de produzir resultados de modo consistente, governado, mensurável e passível de melhoria, com menor dependência de improvisação e pessoas específicas.

Maturidade de processos é a mesma coisa que maturidade de PMO?

Não. Maturidade de processos avalia fluxos recorrentes e suas interfaces; maturidade de PMO avalia capacidades de gestão de projetos, portfólio, governança, controles e serviços do escritório de projetos.

Ter processos documentados significa ter alta maturidade?

Não. Documentação é uma evidência possível. Um processo pode estar bem documentado e ter baixa aderência, pouca rastreabilidade, alto retrabalho ou decisões informais.

Quais dimensões devem ser avaliadas em um diagnóstico de maturidade?

Entre as dimensões mais úteis estão propósito e fronteiras, ownership, padronização, competência e capacidade, dados e rastreabilidade, indicadores, interfaces e melhoria contínua.

Todos os processos precisam chegar ao nível máximo de maturidade?

Não. O nível-alvo depende de risco, criticidade, frequência, complexidade, necessidade de rastreabilidade e impacto de falhas. O objetivo é atingir a capacidade necessária, não perseguir uma nota máxima.

Quando contratar um diagnóstico de maturidade de processos?

Quando problemas recorrentes atravessam áreas, quando a organização não consegue distinguir causas de método, governança, capacidade ou dados, ou antes de iniciativas relevantes de BPM, digitalização, workflows e melhoria contínua.