A mineração de processos fornece às equipas DMAIC registos de eventos para examinar os caminhos dos processos e as atividades repetidas. O estudo Process Mining for Six Sigma, publicado no volume do jornal de 2021, desenvolveu uma diretriz que alinha estas técnicas com o DMAIC. Antes de extrair um registo, a equipa precisa de identificar a decisão de melhoria que esses registos irão apoiar.
Defina a fronteira DMAIC antes de extrair eventos
A prática do DMAIC coloca o âmbito do projeto e os requisitos do cliente no Define. Um SIPOC ajuda a equipa a concordar sobre a unidade de análise e os seus limites. O charter do projeto define então um caso e o seu ponto inicial de medição. Também especifica o resultado que conta como conclusão bem-sucedida.
O tempo decorrido excessivo e a saída defeituosa que exige correção precisam de definições operacionais separadas na descrição do problema do projeto. A revisão do Define do sponsor deve decidir qual o requisito do cliente que tem prioridade. Deve também identificar a medida de qualidade que tem de ser protegida quando a equipa altera o processo.
Measure: estabelecer o que o registo de eventos pode representar
Um registo de eventos convencional associa cada atividade a um caso e regista quando ocorreu. A informação sobre recursos é opcional, conforme descrito no artigo do PMSS. O plano de medição DMAIC precisa de uma definição para cada campo antes de a equipa calcular o desempenho:
- Identificador de caso: a instância do processo acompanhada ao longo da fronteira do SIPOC acordada.
- Atividade: o passo de negócio representado por cada evento registado.
- Carimbo de data/hora: o ponto registado pelo sistema, como o início ou a conclusão da atividade.
- Atributos adicionais: as caraterísticas do recurso ou do caso necessárias para as comparações planeadas.
A revisão da fase Measure também precisa de estabelecer quanto trabalho o registo captura. Num estudo de 2024 na Data & Knowledge Engineering, os investigadores observaram seis colaboradores numa empresa de serviços profissionais. Descobriram que um registo do sistema de transformação principal representaria cerca de 69% do tempo observado de transformação e validação de dados. A cobertura caiu para 32.5% quando avaliada em relação a todo o trabalho relevante relacionado com clientes. Essas percentagens aplicam-se à empresa estudada.
Para uma equipa de Lean Six Sigma, essa lacuna de cobertura levanta uma decisão de âmbito: o registo proposto captura o trabalho nomeado no charter? Um Gemba walk juntamente com a revisão de extração ajuda a identificar o trabalho em falta nos registos do sistema. O entregável do Measure deve nomear essas atividades omitidas e explicar como a sua ausência limita a análise.
A investigação de um gargalo precisa de mais do que um intervalo longo
Um intervalo longo entre carimbos de data/hora precisa de uma explicação antes que a equipa do Analyze o trate como um problema de capacidade. Um estudo de 2024 da Information Systems decompõe a espera entre atividades em cinco causas: agrupamento em lotes, disputa de recursos, priorização, indisponibilidade de recursos e fatores externos. Os investigadores avaliaram a sua abordagem com registos sintéticos e demonstraram-na num processo da vida real. Estas categorias fornecem às equipas de Lean Six Sigma causas específicas para investigar antes de proporem capacidade adicional.
O plano de análise DMAIC deve distinguir o tempo decorrido entre eventos registados da espera antes de uma atividade poder começar. Essa distinção depende do que os carimbos de data/hora registam e de como a análise lida com os calendários de trabalho. Assim que as categorias de atraso estiverem confirmadas, um Pareto ordena-as pelo tempo acumulado dentro da fronteira do projeto.
Explicações concorrentes pertencem a um Ishikawa. Se a equipa suspeitar de agrupamento em lotes, a revisão do Analyze precisa de evidências que relacionem as regras de libertação aos atrasos observados. Um piloto que altere essas regras testa uma causa diferente de um piloto que altere a disponibilidade de recursos.
Classificar o retrabalho antes de contar os defeitos
A demonstração de faturação do artigo do PMSS compara casos que contêm repetições de atividades com outros casos, examinando os seus caminhos e tempos de processamento. Essa comparação identifica casos para investigação. Contar repetições como defeitos exige uma regra de negócio, aprovada pelo Process Owner, que distinga o trabalho de correção da repetição permitida.
Para o DMAIC, uma medida proposta é a proporção de casos elegíveis que contêm pelo menos uma repetição corretiva confirmada. Uma contagem separada de repetições extra captura a carga de trabalho de correção. A medida de defeitos ao nível do caso tem então uma regra definida que a investigação dos 5 Porquês pode testar contra casos individuais.
Melhorar através de um piloto associado à causa suspeita
A avaliação da solução pertence ao Improve. A proposta de piloto deve ligar a alteração selecionada a uma descoberta do Analyze. Manter a definição de caso da linha de base dá à equipa uma base consistente de comparação; um resultado de aceitação declarado estabelece o teste para a alteração. Num projeto de retrabalho, o piloto deve testar uma proposta de poka-yoke em relação à categoria de correção confirmada antes de uma implementação mais ampla.
Na revisão do Improve, eu perguntaria como se comparam os grupos de casos do piloto e da linha de base, incluindo quaisquer diferenças na carga de trabalho ou na mistura de casos. O sponsor também precisa de ver a medida de qualidade protegida a par do tempo decorrido. Um intervalo mais curto no painel de controlo de process mining não é evidência suficiente para aceitação se a mistura de casos mudou ou se os defeitos aumentaram.
Os planos de controlo devem incluir o fluxo de dados de eventos
A fase Control inclui medição a longo prazo e planos de reação. O plano de controlo também deve nomear o responsável pelas definições de atividade da extração de eventos e estabelecer quem aprova as alterações de mapeamento. Os registos em falta precisam de um tratamento documentado. O retrabalho recorrente e a deterioração da cobertura do registo precisam, cada um, de uma resposta atribuída.
Definições de medição documentadas têm de ser levadas até às cartas de controlo. Se uma alteração no sistema alterar o que um carimbo de data/hora regista, o Process Owner precisa de uma revisão da medição antes de interpretar o próximo sinal de desempenho.
Fontes
- Business & Information Systems Engineering (2021), Process Mining para Six Sigma: https://link.springer.com/article/10.1007/s12599-020-00649-w
- Data & Knowledge Engineering (2024), Capturar e Analisar o Comportamento dos Colaboradores: Registo de um Dia de Trabalho Honesto: https://research-portal.uu.nl/ws/portalfiles/portal/239370240/1-s2.0-S0169023X24000740-main.pdf
