utilização da metodologia seis sigma no monitoramento do sistema

UTILIZAÇÃO DA METODOLOGIA SEIS SIGMA NO
MONITORAMENTO DO SISTEMA OPERACIONAL ENXUTO NA
ÁREA DE DESENVOLVIMENTO DE PRODUTOS
Cristiano Marques de Oliveira
Delphi Automotive Systems
E-mail: [email protected]
RESUMO
Os conceitos de manufatura enxuta são amplamente utilizados nas empresas, onde
ferramentas como controle visual de indicadores são muito comuns. Esse tipo de
monitoramento tem como um dos objetivos deixar evidentes os pontos fracos para direcionar
as ações preventivas e corretivas necessárias.
Na área de desenvolvimento de produtos esses conceitos também têm sido aplicados, porém
devido às diferenças entre os ambientes de desenvolvimento e a manufatura grandes desafios
têm sido encontrados.
Dentro desse cenário, a utilização da metodologia seis-sigma (DMAIC) pode aumentar a
consistência na construção de uma sistemática para monitoramento do sistema operacional na
área de desenvolvimento de produtos.
INTRODUÇÃO
Com a constante busca pelo aumento da competitividade, tornou-se mais evidente a
necessidade de expandir os conceitos do sistema de manufatura enxuta para todas as áreas e
processos da empresa, não somente na manufatura.
Podemos citar como principais focos do sistema operacional enxuto, aperfeiçoar o fluxo dos
processos através da eliminação dos desperdícios e gerenciar os processos conectados,
incluindo critérios de tomada de decisão para operar um fluxo e/ou uma área (funcional)
visando atingir os objetivos do negócio.
Conforme o sistema de manufatura enxuta, os sete principais tipos de desperdício são a
correção, superprodução, tempo de espera, transporte, processamento, estoque e
movimentação.
No processo de fabricação, costuma ser possível identificar a existência de alguns dos sete
principais tipos de desperdício, por exemplo, o excesso de estoque. A complexidade da tarefa
de identificação dos desperdícios pode aumentar muito quando se trata do processo de
desenvolvimento e criação de um novo produto.
Para direcionar a criação e implantação do sistema operacional enxuto em qualquer área da
empresa, alguns princípios foram definidos. São esses princípios: peça certa no tempo certo
na quantidade certa; tempo curto de execução; qualidade na fonte; alta utilização da
capacidade e alta utilização dos recursos.
Dentro do fluxo de desenvolvimento de produtos e processos, pode-se ressaltar como
principal foco executar e lançar projetos sem falhas, no prazo e com o custo adequado. Um
grande desafio tem sido utilizar os conceitos do sistema de manufatura enxuta, incluindo a
gestão visual do desempenho de cada etapa com relação aos tipos de desperdício, no ambiente
de desenvolvimento e gestão de projetos.
1. ELEMENTOS DO SISTEMA OPERACIONAL
Para a implantação do sistema operacional enxuto foram estabelecidos alguns elementos
necessários. A política/visão, os objetivos de desempenho e o mapa do processo (fluxos) com
as conexões entre as áreas foram definidos de forma padronizada e comum globalmente,
sendo os demais elementos, indicadores, painel de gestão visual, sistema de programação
(scheduling) e instruções, de responsabilidade local de cada área.
Os indicadores a serem monitorados pelos gerentes de projetos e pelos responsáveis das áreas
no painel de gestão visual podem ser referentes à qualidade, volume (prazo) e custo (QVC).
Estes estão atrelados a etapas específicas do fluxo, chamados de QVC Gates, que são pontos
de controle inseridos no processo utilizando critérios de QVC para determinar a conformidade
das saídas versus os requisitos clientes (internos/externos).
Primeiramente é necessário estabilizar a qualidade e o volume (prazo/qtde./entrega) dos
processos antes melhorar os custos. Também é necessário seguir e assegurar a conformidade
com os objetivos de custo dos processos e objetivos do modelo de custo (cost model) do
produto.
Alguns elementos culturais foram importantes para o claro entendimento em todas as áreas
envolvidas no fluxo de desenvolvimento de produto. Cultura de não passar defeitos: não passe
defeito para a próxima etapa, inclusive informações faltantes. Cultura de “parar”: não comece
o próximo processo se houverem inputs faltantes, escale, avalie o risco e determine se é
possível prosseguir. Cultura de “corrigir rapidamente”: feedback e resolução imediatos das
fontes de problemas. Cultura “visual”: utiliza controles visuais simples para gerenciamento
dos processos. Apropriação da cultura QVC: todos os funcionários devem estar dedicados a
atingir os objetivos de QVC assim como os modelos de custo.
De acordo com esses elementos culturais, é fundamental que todas as áreas instalem seus
indicadores QVCs e os tornem visíveis através de um painel de gestão visual. Como nesse
caso se trata de um processo novo no fluxo de desenvolvimento de produto, o grande desafio
foi evitar esforços duplicados no entendimento e definição de métodos de coleta, compilação
dos indicadores QVC e painel de gestão visual.
Nessas condições, a metodologia seis-sigma (DMAIC Green-belt) foi aplicada para estruturar
a definição dos métodos padronizados de coleta e compilação dos indicadores QVC.
2. APLICAÇÃO DA METODOLOGIA SEIS-SIGMA
Na fase Define, a principal ferramenta utilizada foi o SIPOC para entender o processo de
coleta e compilação dos indicadores QVC e a gestão visual requerida. Foram claramente
definidas as necessidades ao time do projeto, composto de representantes de todas as áreas
funcionais envolvidas.
Supplier
Inputs
Process
Outputs
Requisitos
Time do EOS
DCS Fluxo 4
Nível 2
Definições
Lean
Requisitos
•Com a conexão
entre as áreas
•Com os Inputs e
outputs
QVC
instalados
Glass Wall
disponível
•Com detalhes do
Glass Wall
•Com detalhes do
Scheduling
Liderança
Planejamento
estratégico
•Com detalhes da
necessidade nos
QVCs
Glass Wall
disponível
com dados
dos QVCs
•Com dados
atualizados
•Com gráficos por
área
Scheduling
System
•Com responsáveis
Swim lanes
•Com
periodicidade de
atualização
Instalar os
QVCs e
atualizar o
Glass Wall
•Com prazos
•Com coleta de
dados definida
•Com informações
dos responsáveis
Mapa dos
QVC Fluxo 4
DCS
•Com estratégia
para os QVCs
•Com detalhes do
Mgt Routines
Customer
•Com data
planejada para as
ações
Grupo PDP /
áreas
•Com nome do
responsável e área
•Com o projeto
•Com visibilidade
A fase Measure foi baseada na quantificação de elementos a serem implantados versus o
objetivo estabelecido. A estratégia de coleta foi utilizar o mapa de processo já definido
globalmente como base.
Com o uso das ferramentas espinha de peixe e 5 porquês na fase Analyze pode-se definir
como causa-raiz principal para o potencial de esforço duplicado a falta de uma sistemática
comum para implementação dos elementos indicadores QVC, gestão visual e programação
(Scheduling), que requer simultaneamente conhecimentos computacionais, manufatura enxuta
e conhecimento do fluxo de desenvolvimento de produto estabelecido.
Durante a fase Improve foi definida a melhor sistemática de coleta e consolidação de dados
para evitar esforços duplicados e utilizando a ferramenta Matriz de Decisão foram definidas
as ferramentas computacionais necessárias. A solução definida tem como base os documentos
gerados durante o desenvolvimento do produto que são as evidências que as atividades
necessárias foram executadas.
A principal dificuldade estava atrelada a conseguir interpretar os indicadores de qualidade,
pois a compilação poderia depender de análises específicas. Para eliminar essa dificuldade o
critério de quantidade de repetições foi adotado como medidor de qualidade comum, com
base no conceito fazer certo da primeira vez (FTQ, First Time Quality).
5-Excellence
4-OK
3-OK with comments
2-Not OK/No Info
1-PROBLEM
Q
V
Completed at first
time
Completed but not at
first time
Completed with
rework/revision
First time not
successful
Not completed and
revised
Document published
on time
On time but not
published yet
<= Target and
finished
C
Finished late
Pending document
No due dates (no
planning)
No target available
Late and not finished
> Target
<= Target on going
Na fase Control a nova sistemática foi devidamente documentada na forma de uma instrução
de trabalho dentro do sistema da qualidade que determina claramente as responsabilidades
para manutenção do sistema. Os gerentes de projeto têm como responsabilidade cadastrar os
prazos e responsáveis pela conclusão dos documentos requeridos para cada projeto e os
membros do time de projeto são responsáveis pelo carregamento da evidência da execução.
Área
PDP
Lista os registros e
documentos que
serão arquivados
Cadastra os
projetos na Master
List de Projetos
EOS/Área
PDP
Monta o
Declaration com
base nos registros
e documentos
Cadastra as datas
planejadas para
inclusão das
evidências
Área
O responsável pela
atividade inclui a
evidência
Monitores QVC
Todos atualizados
automaticamente
CONCLUSÃO
No curto prazo, o nível de utilização plena do sistema operacional enxuto no fluxo de
desenvolvimento de produto pode ser baixo, mas esse nível tende a aumentar com o
engajamento de cada gerente de projeto e responsáveis das áreas.
O principal desafio é a mudança cultural, devendo ser considerado que a saída desse processo
é um conjunto de especificações técnicas e ferramentais, não sendo peças fabricadas que
podem ser mais facilmente controladas. Sem dúvida cada novo desenvolvimento de
produto/processo é único em seu conteúdo, porém o trabalho realizado em cada projeto é
similar e pode se beneficiar com o uso de ferramentas e métodos de otimização aplicados na
manufatura.
Grandes melhorias nos resultados são esperadas no médio prazo, devido ao tempo necessário
para a incorporação da nova cultura. A utilização do sistema operacional enxuto aliada à
mudança cultural aumenta muito a visibilidade dos desperdícios na área de desenvolvimento
de produtos para que possam ser devidamente eliminados.
REFERÊNCIAS
[1] OHNO, Taiichi. O Sistema Toyota de Produção , Além da Produção em Larga Escala.
Bookman, 1997.
[2] MORGAN, James. Applying Lean Principles to Product Development. Disponível em
http://www.sae.org/manufacturing/lean/column/leanfeb02.htm. Acesso em: Nov/2008.
[3] DELPHI, Lean University. Lean Enterprise Operating System Training (EOS). Troy,
Michigan: Delphi, 2007.
[4] SANTOS, Claudia. Treinamento EOS. Delphi, 2008.