Translate

Mostrar mensagens com a etiqueta Melhoria Contínua. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Melhoria Contínua. Mostrar todas as mensagens

quinta-feira, 10 de maio de 2018

Lean vs Kaizen vs Six Sigma : O Que Todo Programador COBOL Padawan

 

Bellacosa Mainframe lean kaizen e six sigma 

☕ Um Café no Bellacosa Mainframe

Lean vs Kaizen vs Six Sigma

O Que Todo Programador COBOL Padawan Precisa Saber Sobre as Três Filosofias que Mantêm Bancos, Mainframes e Grandes Empresas Funcionando Há Décadas

"Qualidade não acontece por acaso. Ela é construída todos os dias, medida continuamente e aperfeiçoada infinitamente."

Quando alguém começa a estudar melhoria contínua, normalmente encontra três nomes que parecem sinônimos:

  • Lean

  • Kaizen

  • Six Sigma

Mas eles não são a mesma coisa.

Na verdade, eles atacam problemas completamente diferentes.

É como administrar um IBM Z.

Você pode:

  • eliminar processamento desnecessário;

  • melhorar continuamente seus procedimentos;

  • ou reduzir erros críticos em produção.

Cada abordagem resolve um tipo específico de problema.

A grande descoberta das empresas mais eficientes do mundo foi perceber que não existe competição entre Lean, Kaizen e Six Sigma. Existe complementaridade.

Toyota, IBM, GE, Amazon, Boeing, Intel e praticamente toda empresa de classe mundial utiliza uma combinação dessas filosofias.

Vamos entender por quê.


Antes de tudo...

Imagine um sistema bancário rodando em COBOL.

Durante um processamento batch noturno existem três problemas possíveis.

Problema 1

O processamento demora 8 horas.

Não existem erros.

Tudo funciona.

Mas demora demais.

Esse é um problema de...

Lean.


Problema 2

O processamento funciona hoje.

Mas amanhã alguém encontra uma pequena melhoria.

Depois outra.

Depois outra.

Todos colaboram.

Esse é um problema de...

Kaizen.


Problema 3

O processamento termina em 2 horas.

Mas a cada 5 dias aparece um ABEND diferente.

Ou registros inconsistentes.

Ou valores incorretos.

Esse é um problema de...

Six Sigma.

Observe que são problemas completamente diferentes.


Lean

A arte de eliminar desperdícios

Lean nasceu no Sistema Toyota de Produção.

Seu objetivo é extremamente simples.

Fazer mais utilizando menos.

Menos:

  • tempo

  • estoque

  • movimentação

  • espera

  • retrabalho

  • burocracia

  • custo

Lean pergunta constantemente:

"Existe alguma atividade aqui que não agrega valor ao cliente?"

Se a resposta for sim...

Ela deve ser eliminada.


O que é desperdício?

No Lean, desperdício recebe o nome japonês:

Muda (無駄)

Taiichi Ohno identificou sete desperdícios clássicos, depois ampliados para oito.

1. Superprodução

Produzir antes da hora.

Exemplo Mainframe:

Gerar dezenas de relatórios que ninguém lê.


2. Espera

Jobs aguardando recursos.

Exemplo:

Batch esperando dataset.


3. Transporte

Mover informações desnecessariamente.

Exemplo:

Transferências repetidas entre ambientes.


4. Processamento excessivo

Fazer mais do que o necessário.

Exemplo:

Executar SORTs redundantes.


5. Estoque

Acumular trabalho.

Exemplo:

Milhares de requisições aguardando aprovação.


6. Movimentação

Pessoas gastando energia desnecessária.

Exemplo:

Operadores alternando entre dezenas de painéis.


7. Defeitos

Retrabalho.

Exemplo:

ABENDs.

Correções.

Reprocessamentos.


8. Talento desperdiçado

Talvez o maior desperdício moderno.

Ter profissionais excelentes realizando tarefas mecânicas.


Lean no Mainframe

Imagine um batch.

JOB A

↓

SORT

↓

SORT

↓

SORT

↓

COPY

↓

COPY

↓

REPORT

Após análise...

Descobre-se que dois SORTs são desnecessários.

Resultado:

  • menos CPU

  • menos I/O

  • menos tempo

  • menos custo

Isso é Lean.


Kaizen

A filosofia do "sempre um pouco melhor"

Kaizen significa literalmente:

改善

Kai = mudança

Zen = melhor

Ou seja...

"Mudança para melhor."

Mas existe um detalhe importante.

Kaizen não busca revoluções.

Busca pequenas melhorias.

Todos os dias.


O poder das pequenas melhorias

Imagine melhorar um processo apenas 1% por dia.

Parece insignificante.

Mas ao longo do tempo...

A melhoria composta torna-se gigantesca.

É exatamente isso que tornou a Toyota uma referência mundial.


Kaizen não depende da chefia

Esse é um dos maiores erros de interpretação.

Muitos acreditam que melhoria depende do gerente.

Kaizen diz justamente o contrário.

Todo colaborador deve sugerir melhorias.

Desde:

  • estagiário

  • operador

  • analista

  • desenvolvedor

  • arquiteto

  • diretor

Todos participam.


Exemplo Mainframe

Um desenvolvedor COBOL percebe que:

Todos os programas repetem o mesmo código de validação.

Ele cria uma COPYBOOK.

Agora:

Antes:

200 linhas repetidas

Depois

COPY VALIDA-CPF.

Pequena melhoria.

Grande impacto.

Isso é Kaizen.


Six Sigma

A ciência da redução da variabilidade

Enquanto Lean pergunta:

"Existe desperdício?"

Six Sigma pergunta:

"Por que o processo produz resultados diferentes?"

A palavra-chave aqui é:

Variabilidade.


Imagine um caixa eletrônico.

Ele deve entregar exatamente:

R$100

Sempre.

Não:

R$99

Nem:

R$101

Nem:

Erro de leitura.

Nem:

Travamento.

Nem:

Falha ocasional.

Processos críticos precisam ser previsíveis.

É isso que Six Sigma busca.


O significado de Sigma

Sigma (σ) representa o desvio padrão.

Quanto menor a variação...

Mais previsível o processo.

Six Sigma significa atingir um nível extremamente alto de qualidade.

Na prática, a meta clássica é cerca de 3,4 defeitos por milhão de oportunidades (DPMO) sob premissas específicas do método.


DMAIC

Six Sigma utiliza um roteiro muito conhecido.

D — Define

Definir o problema.


M — Measure

Medir.

Sem dados...

Não existe Six Sigma.


A — Analyze

Descobrir a causa raiz.


I — Improve

Implementar melhorias.


C — Control

Garantir que o problema não volte.


Six Sigma no Mainframe

Imagine um sistema financeiro.

De cada

10 milhões

de transações...

120 apresentam erro.

O objetivo é descobrir:

Por quê?

Em qual módulo?

Qual horário?

Qual banco?

Qual rotina?

Qual variável?

Six Sigma vive de estatística.

Não de opiniões.


Lean x Kaizen x Six Sigma

LeanKaizenSix Sigma
Remove desperdíciosMelhoria contínuaRemove variabilidade
Mais velocidadeMais evoluçãoMais qualidade
FluxoCulturaEstatística
EficiênciaPessoasDados
CustosEngajamentoPrecisão

Uma analogia perfeita

Imagine uma rodovia.

Lean:

Retira congestionamentos.

Kaizen:

Melhora a estrada diariamente.

Six Sigma:

Garante que nenhum carro saia da pista.

São problemas diferentes.


Como IBM Mainframe utiliza essas filosofias?

Embora muitas vezes associadas à indústria automotiva, essas abordagens são extremamente relevantes em ambientes IBM Z.

Lean

  • redução de consumo de CPU

  • otimização de JCL

  • eliminação de etapas redundantes

  • redução de I/O

  • tuning de SQL no Db2

  • consolidação de jobs


Kaizen

  • padronização de COPYBOOKs

  • melhoria contínua de procedimentos operacionais

  • revisão de convenções de nomenclatura

  • documentação viva

  • automação incremental com REXX, Ansible ou Zowe


Six Sigma

  • redução de ABENDs

  • análise estatística de falhas

  • monitoramento de SLAs

  • controle de incidentes

  • melhoria da confiabilidade em sistemas financeiros

  • uso de métricas de qualidade em testes e produção


Onde entram os Core Quality Tools?

As três filosofias utilizam diversas ferramentas de apoio.

Por exemplo:

  • Lean: Value Stream Mapping (VSM), Kanban, 5S, SMED, Heijunka, Takt Time.

  • Kaizen: PDCA, 5W2H, Brainstorming, A3 Report, Gemba Walk, Círculos de Qualidade.

  • Six Sigma: DMAIC, Controle Estatístico de Processo (SPC), Cartas de Controle, Histograma, Diagrama de Pareto, Análise de Capabilidade, DOE, MSA e FMEA.

Os 7 Core Quality Tools (Fluxograma, Folha de Verificação, Pareto, Ishikawa, Histograma, Diagrama de Dispersão e Carta de Controle) são amplamente utilizados em Kaizen e Six Sigma, fornecendo dados para análise e melhoria.


A falsa competição

Muitas empresas perguntam:

"Devemos implantar Lean ou Six Sigma?"

A pergunta correta é:

"Qual problema queremos resolver?"

Se há desperdício...

Use Lean.

Se falta cultura de melhoria...

Use Kaizen.

Se há muitos defeitos...

Use Six Sigma.


Lean Six Sigma

Foi justamente por perceber que as metodologias se complementavam que surgiu o Lean Six Sigma.

Lean acelera.

Six Sigma estabiliza.

Kaizen garante que a evolução nunca pare.

É por isso que organizações maduras combinam as três abordagens em seus programas de Excelência Operacional.


A grande lição para um Programador COBOL Padawan

No universo IBM Mainframe, não basta escrever programas que funcionem. É preciso escrever programas eficientes, evolutivos e confiáveis.

Pense nessas três filosofias como três lentes complementares:

  • Lean pergunta: "Posso fazer isso com menos recursos e menos desperdício?"

  • Kaizen pergunta: "O que posso melhorar hoje, mesmo que seja apenas 1%?"

  • Six Sigma pergunta: "Como garantir que esse processo produza o mesmo resultado correto, todas as vezes?"

Os sistemas bancários, de seguros, telecomunicações e governo executados em IBM Z permanecem relevantes há décadas porque incorporam esses princípios. A combinação entre eficiência operacional, melhoria contínua e controle rigoroso da qualidade é o que permite processar milhões de transações diariamente com alta disponibilidade e confiabilidade.

No fim, a verdadeira excelência operacional não surge da escolha entre Lean, Kaizen ou Six Sigma, mas da capacidade de aplicar cada abordagem no momento certo. Empresas que fazem isso constroem processos mais rápidos, equipes mais engajadas e sistemas mais robustos — exatamente as características esperadas dos ambientes críticos onde o Mainframe continua sendo referência mundial.

quarta-feira, 9 de maio de 2018

Os 5 Core Quality Tools na Stack IBM Mainframe

 

Bellacosa Mainframe e as 5 core quality tools

☕ Um Café no Bellacosa Mainframe

Os 5 Core Quality Tools na Stack IBM Mainframe

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Como Construir Sistemas Bancários que Não Podem Falhar

"A qualidade não nasce durante o teste. Ela nasce muito antes da primeira linha de código ser compilada."

Quando um desenvolvedor COBOL inicia sua jornada no mundo do IBM Mainframe, normalmente acredita que qualidade significa apenas "o programa compilou sem erro" ou "o teste passou".

Essa visão funciona para pequenos projetos.

Mas desaparece completamente quando você entra em uma instituição financeira, seguradora, empresa aérea ou governo.

Ali, uma única linha de COBOL pode movimentar bilhões de reais diariamente.

Uma alteração aparentemente simples em um programa de cálculo de juros pode impactar milhões de clientes.

Uma mudança em um COPYBOOK pode afetar centenas de programas.

Um campo alterado em um registro VSAM pode quebrar integrações com CICS, DB2, MQ, IMS e dezenas de aplicações.

É por isso que grandes empresas não dependem apenas da habilidade do programador.

Elas dependem de processos.

Esses processos são conhecidos mundialmente como Core Quality Tools.

Embora tenham surgido na indústria automotiva através da AIAG (Automotive Industry Action Group) e hoje façam parte da IATF 16949, seus princípios são universais.

Na prática, eles representam exatamente aquilo que faz um ambiente IBM Z operar durante décadas com níveis de disponibilidade próximos de 99,9999%.

E talvez você nunca tenha percebido...

Grande parte da cultura de desenvolvimento Mainframe já segue esses princípios há décadas.

Vamos descobrir como.


O verdadeiro significado de qualidade

Existe uma diferença enorme entre:

"Meu programa funciona."

e

"Meu sistema continuará funcionando pelos próximos vinte anos."

Essa diferença chama-se engenharia de qualidade.

O Mainframe sempre foi pioneiro nisso.

Enquanto muitas plataformas modernas seguem o famoso:

"Deploy rápido e corrige depois."

O Mainframe tradicionalmente segue outra filosofia:

"Planeje tanto que quase não seja necessário corrigir."

Parece exagero?

Pense em um banco.

Imagine que durante o fechamento financeiro do mês:

  • um JOB falha

  • uma transação CICS trava

  • um cálculo de imposto gera valores incorretos

  • um débito é executado duas vezes

Agora multiplique isso por:

  • dez milhões de clientes.

A qualidade deixa de ser uma característica técnica.

Ela passa a ser um requisito de sobrevivência.


A fábrica de software também é uma fábrica

Quando olhamos para uma montadora, vemos:

  • matéria-prima

  • máquinas

  • operadores

  • inspeções

  • manutenção

  • produção

Agora olhe para um ambiente Mainframe.

Temos praticamente a mesma estrutura.

Na indústriaNo Mainframe
Matéria-primaRequisitos
ProjetoArquitetura
Linha de produçãoPipeline DevOps
MáquinasLPARs IBM Z
FerramentasCOBOL, JCL, DB2, CICS
InspeçãoTestes
Controle estatísticoMonitoramento SMF/RMF
Produto finalAplicação em produção

Mudam os nomes.

A engenharia continua exatamente igual.


APQP

Planejamento Avançado da Qualidade

O primeiro erro de um desenvolvedor júnior é acreditar que programação começa no editor COBOL.

Não começa.

Começa muito antes.

Imagine que o banco deseja criar uma nova modalidade de PIX internacional.

Antes de alguém escrever:

MOVE VALOR TO WS-TOTAL.

centenas de decisões já foram tomadas.

Será utilizado DB2?

VSAM?

MQ?

CICS?

Batch?

Online?

REST?

z/OS Connect?

Quais campos serão adicionados?

Quem fará rollback?

Como será a auditoria?

Qual será o SLA?

Como será a recuperação após desastre?

Tudo isso faz parte do equivalente Mainframe do APQP.


O APQP na prática

Em grandes empresas essa etapa envolve:

  • levantamento de requisitos

  • arquitetura corporativa

  • análise de impacto

  • padrões COBOL

  • convenções JCL

  • segurança RACF

  • definição de índices DB2

  • planejamento de backup

  • definição de monitoramento

  • cronograma

Observe algo interessante.

Nenhuma linha de código foi escrita.

Mesmo assim já existe enorme trabalho.

É exatamente isso que reduz defeitos.


Um exemplo real

Imagine alterar um programa responsável pelo cálculo do FGTS.

Sem planejamento:

"É só incluir um campo."

Na prática:

Esse campo pode existir em:

  • COPYBOOK

  • DB2

  • VSAM

  • MQ

  • CICS

  • telas BMS

  • APIs REST

  • batch noturno

  • relatórios

  • ETL

  • Data Warehouse

Uma alteração pode atingir centenas de programas.

O APQP identifica isso antes.


FMEA

Failure Mode and Effects Analysis

Se existe uma ferramenta que todo desenvolvedor deveria aprender, é esta.

O FMEA faz uma pergunta simples:

"O que pode dar errado?"

Mas a resposta nunca é simples.


Exemplo COBOL

Programa:

PAGTO001

Função:

Efetuar pagamento.

O programador pensa:

"O código está certo."

O FMEA pergunta:

E se o arquivo VSAM estiver cheio?

E se ocorrer DEADLOCK no DB2?

E se o MQ estiver indisponível?

E se o cliente enviar CPF inválido?

E se faltar espaço no SORTWK?

E se ocorrer S0C7?

E se houver rollback?

E se duas transações atualizarem o mesmo registro?

Percebe?

O FMEA obriga a pensar como um arquiteto.


Exemplo prático

Modo de falha

Registro duplicado.

Efeito

Cliente recebe pagamento em dobro.

Consequência

Prejuízo financeiro.

Severidade

10

Ocorrência

4

Detecção

3

Risco elevado.

Ação recomendada

Implementar chave única.

Controle transacional.

Logs.

Rollback.

Auditoria.


O FMEA e os ABENDs

Os ABENDs representam excelente fonte para alimentar um FMEA.

Por exemplo:

S0C7

Pode indicar:

dados inválidos.

S806

Programa inexistente.

SB37

Dataset sem espaço.

S322

Timeout.

Cada um desses eventos deveria gerar perguntas:

Como evitar?

Como detectar antes?

Como recuperar automaticamente?


MSA

Measurement System Analysis

Imagine um gerente perguntar:

"Nosso sistema está rápido?"

Resposta:

"Mais ou menos."

Isso não serve.

No Mainframe tudo precisa ser medido.

Mas...

Quem garante que a medição está correta?

Esse é exatamente o papel do MSA.


No mundo IBM Z

O equivalente do MSA inclui:

SMF

RMF

OMEGAMON

IBM Z IntelliMagic

IBM Instana

Grafana

Prometheus

Z APM Connect

Todos precisam fornecer dados confiáveis.


Imagine.

Uma ferramenta informa:

CPU 95%.

Outra:

CPU 52%.

Qual está correta?

Sem confiabilidade na medição não existe gerenciamento.


Gage R&R aplicado ao Mainframe

Na indústria mede-se paquímetro.

No Mainframe mede-se observabilidade.

Por exemplo:

Tempo CICS.

Tempo DB2.

Tempo MQ.

Tempo Batch.

Latência API.

Precisamos validar:

  • consistência

  • repetibilidade

  • precisão


SPC

Statistical Process Control

Esta talvez seja a ferramenta mais próxima do universo dos operadores Mainframe.

Imagine acompanhar diariamente:

Quantidade de JOBs.

Tempo médio Batch.

CPU.

IOPS.

Locks DB2.

Tempo CICS.

Uso DASD.

Uso de memória.

Esses indicadores possuem comportamento normal.

Quando começam a fugir do padrão...

Algo está acontecendo.


Exemplo

Um JOB sempre executa em:

7 minutos.

Durante semanas.

Depois:

8

9

10

11

13

15 minutos.

Ainda termina.

Mas existe tendência.

SPC detecta.

O operador investiga.

Descobre:

Novo índice DB2.

Plano alterado.

RUNSTATS desatualizado.

Sem SPC isso só seria descoberto quando o batch atrasasse horas.


PPAP

Production Part Approval Process

Agora imagine o momento mais temido.

Deploy em produção.

O desenvolvedor diz:

"Funciona na homologação."

O gerente pergunta:

"Você tem evidências?"

Entra o equivalente Mainframe do PPAP.


Antes do Go Live

São revisados:

Código COBOL.

Resultados dos testes.

Testes unitários.

Testes integrados.

Performance.

Planos DB2.

EXPLAIN.

SCAN de segurança.

Revisão RACF.

Validação CICS.

JCL.

Rollback.

Documentação.

Plano de retorno.

Checklist CAB.

Aprovação do negócio.

Somente depois ocorre o deploy.


O PPAP moderno

Hoje muitas empresas automatizam esse processo.

Ferramentas:

Git

Jenkins

UrbanCode Deploy

Endevor

Changeman

ISPW

SonarQube

Zowe CLI

Ansible

Cada etapa produz evidências.

O pipeline torna-se um PPAP digital.


A relação entre os cinco

Observe como cada ferramenta depende da anterior.

Sem planejamento...

não existe análise de risco.

Sem análise de risco...

não sabemos o que medir.

Sem medição...

não sabemos controlar.

Sem controle...

não existe aprovação.

É uma cadeia.


Os Core Tools dentro do ciclo de vida do software

Imagine um projeto para modernizar um sistema COBOL de empréstimos.

Durante o planejamento (APQP), arquitetos definem requisitos, integração com APIs via z/OS Connect, impactos em DB2, VSAM e CICS, requisitos de segurança RACF e critérios de desempenho.

Na sequência, realiza-se o FMEA, identificando riscos como indisponibilidade de serviços externos, deadlocks em tabelas DB2, falhas de comunicação com IBM MQ, concorrência entre transações CICS, erros de conversão de dados e possíveis ABENDs. Para cada risco são propostas ações preventivas.

Com o projeto definido, entram em cena as práticas equivalentes ao MSA. Ferramentas como SMF, RMF, OMEGAMON, Instana e Grafana são configuradas para garantir que CPU, I/O, tempos de resposta e utilização de recursos sejam medidos de forma consistente e confiável.

Durante testes e homologação, aplica-se o conceito de SPC. A equipe monitora métricas como tempo médio de execução de jobs, consumo de CPU, quantidade de locks DB2, latência de transações CICS e volume de mensagens em filas MQ. O objetivo é identificar tendências antes que se transformem em incidentes.

Por fim, o PPAP se materializa no processo de aprovação para produção. Revisões de código, testes automatizados, análise estática, validação de planos DB2, documentação, plano de rollback, aprovação da CAB (Change Advisory Board) e conformidade com normas corporativas garantem que o software esteja apto para operar em produção com segurança.


A Qualidade como Cultura

O maior ensinamento dos Core Tools não é preencher formulários.

É desenvolver uma forma de pensar.

Um bom programador pergunta:

"Como faço isso funcionar?"

Um excelente engenheiro pergunta:

  • Como isso pode falhar?

  • Como detectarei a falha?

  • Como evitarei que ela ocorra novamente?

  • Como monitorarei esse comportamento ao longo do tempo?

  • Como demonstrarei, com evidências, que o sistema é confiável?

Essa mudança de mentalidade transforma desenvolvedores em arquitetos de soluções resilientes.


O que Todo COBOL Padawan Deve Levar para a Carreira

Se existe uma lição que atravessa décadas de evolução tecnológica, do COBOL ao DevOps, do batch ao cloud híbrido, é que qualidade nunca é um evento; é um processo contínuo.

Os 5 Core Quality Tools mostram que sistemas robustos não são fruto de sorte ou de programadores "geniais". Eles são resultado de planejamento disciplinado, análise de riscos, medições confiáveis, monitoramento estatístico e processos rigorosos de aprovação.

No universo IBM Mainframe, essa filosofia sempre esteve presente. É por isso que aplicações escritas há 30 ou 40 anos continuam processando milhões de transações diariamente com níveis extraordinários de disponibilidade e confiabilidade.

Ao estudar APQP, FMEA, MSA, SPC e PPAP, o COBOL Padawan percebe que essas ferramentas não pertencem apenas à indústria automotiva. Elas representam uma forma universal de construir sistemas críticos: pensar antes de programar, prevenir antes de corrigir, medir antes de decidir, controlar antes que o problema aconteça e liberar para produção apenas quando houver evidências objetivas de que o software está pronto.

No fim das contas, o maior legado da Stack IBM Mainframe talvez não seja apenas sua tecnologia, mas sua cultura de engenharia. Uma cultura em que cada linha de código, cada JCL, cada tabela DB2, cada transação CICS e cada job batch fazem parte de um ecossistema projetado para entregar confiança. E confiança, em sistemas que movimentam bilhões de reais todos os dias, é a mais valiosa das qualidades. Afinal, como costumo dizer aos novos Padawans do Mainframe:

"No IBM Z, qualidade não é um departamento. É uma característica da arquitetura, do processo e da mentalidade de quem escreve cada linha de código."