O roteiro DMAIC na melhoria dos processos – Six Sigma – parte II

Continuando o post anterior sobre o roteiro DMAIC, onde tivemos a introdução de conceitos e as fases D (Define) e M (Measure), nesse aqui iremos abordar as fases seguintes que são A (Analyze), I (Improve) e C (Control).

4. Analyze

O objetivo da fase Analyze é desenvolver as mudanças e encontrar a causa raiz do problema. A análise é essencial para trazer conhecimento ao processo atual, por isso veremos técnicas que ajudam a criticar o processo atual e sugerir mudanças que resultarão em melhorias.

Evite procurar a perfeição (síndrome da utopia e da paralisia) e fazer mais do mesmo, pois são problemas conhecidos no desenvolvimento da mudança.

Comparação entre os dois tipos de mudança:

1ª ordem2ª ordem
SistemaNão é alteradoÉ alterado
Percepção do clienteSolução do problemaMelhoria
PrazoImediato, curtoMédio, longo

4.1. Diagrama de Causa e Efeito

Também conhecido como Diagrama Espinha de Peixe ou Ishikawa, o Diagrama de Causa e Efeito é uma técnica para descobrir, organizar e agrupar conhecimento a respeito das causas que contribuem para um determinado efeito. É muito usada no início do desenvolvimento de mudanças para alinhar o conhecimento da equipe a respeito do problema.

Há seis causas “comuns” (método, mão-de-obra, máquina, meio-ambiente, material e medição) proposta pela técnica. É claro que, ao aplicar na área de TI, pode haver outras causas necessárias a testar, coletando dados e realizando experimentos.

4.2. Lean

Enquanto o Six-Sigma está mais relacionado ao controle da qualidade, o Lean é uma filosofia de gestão inspirada nas práticas do Sistema Toyota, focada no controle da quantidade de produção para reduzir os desperdícios. Os sete desperdícios considerados são: superprodução, transporte, movimentação, excesso de processamento, estoque, defeito e tempo de espera.

A imagem abaixo resume os 4 P’s e os 14 princípios do TPS, além do JIT (Just in time) e Jidoka, pilares do Lean.

A análise de valor é percepção do cliente para determinar o que é desperdício:

  • Atividade que agrega valor (AV): atividade necessária p/ produzir um produto ou serviço e adiciona valor sob o ponto de vista do cliente
  • Atividade que não agrega valor (NAV): atividade realizada para produzir um produto ou um serviço, mas que não adiciona valor sob o ponto de vista do cliente.

4.2.1. A Casa do Lean

Assim como uma casa, que precisa ser construída apropriadamente para ter êxito, o Lean considera o uso adequado de estratégias para obtenção do sucesso.

A fundação inicia-se pela confiança, objetivos e o buy-in dos colaboradores e da liderança, sendo o suporte aos demais processos. As paredes, em geral, servem para otimizar os processos (eliminar desperdícios, melhorar a eficiência e a qualidade). O telhado é o foco no cliente e protege o resto da estrutura de encontrar problemas.

4.3. Sistema empurrado e puxado

No sistema empurrado, cada atividade entrega o resultado quando está pronto. Isso pode resultar em acúmulo de lotes com muitos intervalos.

Já o sistema puxado, cada atividade entrega o resultado apenas quando a próxima atividade precisa de sua entrada.

  • Disparado pelo cliente (externo e interno)
  • Minimiza o inventário e retrabalho devido a defeitos
  • Há poucos desperdícios
  • São ágeis em responder à demanda do cliente

4.4. VSM (Value Stream Mapping)

O Mapeamento do Fluxo de Valor é utilizado para apoiar os times a construir o fluxo de valor, que concretiza uma necessidade em um produto ou serviço para entrega de valor ao cliente. Facilita a identificação de desperdícios, gargalos, custos, etc.

É aplicável quando se busca oportunidade de melhoria em uma linha de produção, segundo a teoria dos desperdícios.

4.5. Poka Yoke

É uma ferramenta que ajuda a prevenir falhas humanas nos processos. “Tornar fácil fazer certo e difícil (quase impossível) fazer errado”. Muitas vezes é mais fácil alterar sistema do que o comportamento humano para prevenir os erros.

Os métodos Poka Yoke são: lembretes, diferenciação, restrições e exibições.

Tipos de Poka-Yoke

A prova de erro (preventivo)A prova de falha (detectivo)
Elimina a possibilidade de ocorrência da falha ou defeito específico, através do projeto   Detecta a falha ou defeito, caso ocorra, e previne que a não-conformidade continue no processo

5. Improve

A mudança como uma predição. Nessa fase, as soluções são criadas para resolver os problemas identificados na fase de Analyze (causa raiz de cada um). As principais ferramentas e praticas utilizadas são:

  • Plano de Ação – 5W2H
  • Kaizen
  • Matriz de Priorização
  • 5S

E verificar o grau de convicção da mudança: desenvolvendo, testando (em ciclos) e implementando as mudanças. Utiliza-se base de comparação histórica / simultânea e verificação de pontos vulneráveis.

Adicionar estágios para exibir mudanças no processo - Minitab

6. Control

O objetivo de monitorar os resultados obtidos é de perpetuar os conhecimentos e as melhorias conquistadas. Um plano de controle recomendado para manter as melhorias:

  • Realizar o plano de implementação com a abordagem 5W2H
  • Documentar o novo sistema
  • Treinar os envolvidos
  • Monitorar o sistema: manter o resultado e fonte de aprendizado. Existem técnicas simples, como a elaboração check-lists, e técnicas mais complexas, como o uso de controle estatístico de processos.
  • Estender o conhecimento e as melhorias conquistadas
  • Reconhecimento das pessoas envolvidas

O roteiro DMAIC na melhoria dos processos – Six Sigma – parte I

O roteiro DMAIC (Define-Measure-Analyze-Improve-Control) é um componente do Six-Sigma utilizado para melhorar os processos existentes da empresa, e assim apoiar as mudanças para que resultem em melhorias, tais como redução de problemas, defeitos e desperdícios.

Possui cinco etapas e um objetivo de conclusão para cada uma, afim de garantir a progressão do projeto de melhoria.

  • Define: definição do problema e prioridades
  • Measure: medição do estado atual
  • Analyze: encontrar a causa raiz do problema
  • Improve: mudança como uma predição
  • Control: perpetuar os conhecimentos e as melhorias conquistadas

1. Mudança e melhoria

Como é essa relação? Sabemos que a mudança nem sempre resulta em melhoria, mas a melhoria requer mudança. Por isso, os modelos de melhoria são utilizados para apoiar a realização da mudança, com análise de dados e entendimento de variabilidade.

Que mudanças podemos fazer que resultarão em melhoria? A mudança de fato somente é uma melhoria se ela é duradoura. A análise crítica sobre o processo atual, o uso de novas tecnologias e o pensamento criativo são alguns conceitos de mudança utilizados pelos modelos de melhoria.

Veja uma comparação (resumida) das fases do PDCA, DMAIC e MASP:

2. DMAIC – Define

É a fase de definição do escopo do projeto de melhoria. A elaboração do contrato do projeto declara o patrocinador / stakeholders envolvidos, contexto, objetivos, indicadores, prazos, restrições e o business case. As principais ferramentas que ajudam nas tarefas dessa fase:

  • SIPOC (suppliers – inputs – process – outputs – customers): uma representação dos aspectos relevantes do processo, onde será o foco de melhoria.
  • Diagrama direcionador: é uma ferramenta para organizar as ideias a respeito das possíveis mudanças.
  • Matriz RACI: definição de papeis e responsabilidades para as tasks do projeto

3. DMAIC – Measure

É imprescindível mensurar a mudança para determinar se houve uma melhoria significativa ou não. A confiabilidade da informação é essencial para apoiar as decisões e refletir a realidade. O time decide o que deve ser medido e como medi-lo. Alguns indicadores de aferição:

  • Medidas de resultado: as mudanças estão levando à melhoria?
  • Medidas de processo: estamos fazendo as coisas certas para atingir o nosso objetivo?
  • Medidas de equilíbrio: contra indicadores. A melhoria não pode gerar impacto em outros processos.

3.1. Ferramentas

3.1.1. Fluxograma

Identificar desconexões e oportunidades de melhoria no fluxo de trabalho. Inicia-se por um nível macro e verifica se já há oportunidades de melhoria, adicionando detalhes conforme necessário. Existe o fluxograma vertical e o multifuncional.

3.1.2. Gráfico de tendência e controle

O gráfico de tendência é uma ferramenta analítica simples para estudar a variação nos processos (eixo horizontal e vertical). O gráfico de controle é usado para analisar se um processo está ou não sob controle, e identificação das causas (comuns ou especiais) das variações.

Gráfico de tendência
Gráfico de controle

Exemplos de variações (observadas em gráficos de controle):

  • Um ponto muito afastado dos demais
  • Uma sequência de dez ou mais pontos acima da média

3.1.3. Gráfico de tendência

O Dot Plot é um gráfico que consiste em pontos de dados plotados em uma escala simples (conjuntos de dados de tamanho pequeno a moderado). O seu uso é para destacar clusters e gaps, além de discrepantes. A distância entre a média e os pontos máximo e mínimo são bons orientadores.

Dot plot
Histograma
Adding fitted distribution lines - Minitab

O histograma é usado para grande quantidade de dados (mais de 50 pontos) e checar a simetria dos dados. A diferença entre o ponto máximo e mínimo demonstra que este gráfico é pouco simétrico.

3.1.4. Gráfico de barras e setores

São ferramentas para estudar a distribuição de dados classificatórios (qualitativos).

Selecione as opções de exibição para Gráfico de barra - Minitab

3.1.5. Gráfico de pareto

Conhecida como regra 80/20, onde 80% das consequências provêm de 20% das causas. Também chamado de Vitais vs Triviais, onde a maioria dos problemas acontece muito pouco, e um pequeno grupo das categorias representa a maioria da frequência dos problemas.

Pareto se aplica
Exemplo de Gráfico de Pareto - Minitab
Pareto não se aplica
Fundamentos do gráfico de Pareto - Minitab

3.1.6. Estratificação

É a separação em grupos e classificação dos dados, de acordo com fatores ou variáveis selecionadas. O objetivo é encontrar padrões que auxiliem na compreensão dos mecanismos causais de um processo.

Quando utilizar? Sempre que houver interesse em estudar se o “comportamento” é o mesmo em todos os grupos definidos pelos fatores ou variáveis.

3.1.7. Gráfico de controle (Shewart)

Identificar a causa (comum e especial) das variações no processo. A partir de cálculos estatísticos estabelece três linhas: LC (limite central), LSC (limite superior de controle) e LIC (limite inferior de controle). Os tipos de variáveis são dados contínuos ou de classificação/contagem.

  • Gráfico U: usado para contar o número de defeitos. O indicador é uma taxa e pode ter valores maior que 1.
  • Gráfico P: usado para contar o número de unidades defeituosas. O indicador é uma proporção e precisa ser menor que 1.
  • Gráfico X: em dados contínuos com tamanho do subgrupo 1 e a distribuição dos dados é normal.
  • Gráfico X-barra/R ou X-barra/S: em dados contínuos coletados em subgrupos (amostras) de tamanho constante ou variável (/S).

3.1.8. Capabilidade

São medidas que indicam a capacidade de um processo atender às especificações de clientes. O Histograma é uma forma de representar graficamente a distribuição dos dados de uma amostra – capabilidade para variáveis contínuas.

Dentre as distribuições contínuas usadas em estatística, a distribuição normal (Gaussiana) é a mais usada. A distribuição normal possui dois parâmetros: a média (μ), ou seja onde está centralizada e a variância (σ ² > 0) que descreve o seu grau de dispersão. A dispersão ainda é referida em termos de unidades padrão, ou seja desvio padrão (σ).

Standard error - Wikipedia

No próximo post (parte II), continuaremos o roteiro DMAIC, detalhando as etapas de Analyze, Improve e Control.

AWS Cloud Practitioner – Preparação para o exame e simulados

Introdução

Para quem tiver interesse em fazer o exame AWS Certified Cloud Practitioner (CLF-C01), sugiro começar a leitura pelo Cloud Practitioner Learning Path para entender o caminho de aprendizagem em relação a Cloud AWS. Em seguida, acessar a AWS Certification que explica como as certificações podem ajudar na carreira, os benefícios e a aplicabilidade em diferentes níveis (Foundational, Associate, Professional e Specialty).

O exame AWS Certified Cloud Practitioner (CLF-C01) está no nível Foundational da AWS e por isso avalia conceitos básicos de Cloud:

  • Cloud AWS, serviços (core / integrated services) e infra global
  • Proposta de valor e princípios de arquitetura
  • Definição de preço e suporte
  • Segurança da conta e conformidade
  • Características para implantação e operação Cloud AWS

A AWS recomenda essa certificação a candidatos que tenham pelo menos seis meses de experiência com a nuvem da AWS (em qualquer função) e entendimento básico dos serviços de TI e seu uso na plataforma AWS Cloud. Alguns exemplos de perguntas que são abordadas no exame:

  • Which of the following is an AWS responsibility under the AWS shared responsibility model?
  • Which service would be used to send alerts based on Amazon CloudWatch alarms?
  • Why is AWS more economical than traditional data centers for applications with varying compute workloads?

Detalhes do exame

Formato: 65 questões de múltipla escolha, múltiplas respostas (mínimo de 70% de acerto para aprovação)
Duração: 90 minutos
Método de apresentação: Centro de testes ou exame supervisionado online
Custo: 100 USD
Idioma: disponível em inglês, japonês, coreano e chinês simplificado
https://aws.amazon.com/pt/certification/certified-cloud-practitioner/

Conteúdo do exame

O exame está dividido em quatro domínios principais, onde 26% das questões serão de Cloud concepts, 25% em Security and compliance, 33% em Technology (a maior parte) e 16% sobre Billing and Pricing:

Curso online

Por onde começar a estudar? Sugiro começar pelo curso online AWS Cloud Practitioner Essentials (segunda edição) e melhorar a compreensão dos conceitos exigidos no exame.

O AWS Cloud Practitioner Essentials é um curso gratuito (online) e possui 6 horas de duração. É muito recomendado para quem vai fazer a prova de certificação.

Aborda conceitos de Cloud, serviços, segurança, arquitetura, definição de preço e suporte da AWS.

Simulados

Após a realização do curso e a leitura dos conteúdos (mencionados acima), uma boa dica é fazer os simulados para ajudar a entender o formato das questões e o conhecimento esperado no exame. Compartilho aqui três links com simulados bem próximos ao conteúdo e formato do exame:

Resumo do conteúdo

Exame

O exame pode ser feito na sua própria casa (com verificação de alguns requisitos) ou em locais autorizados. O link para mais informações e agendar o exame é AWS Certified Cloud Practitioner (CLF-C01).

Why are Cloud services so important in digital strategy?

Voltando ao contexto da transformação digital, onde os modelos de negócio (business agility, inovação, etc.) e tecnologias são utilizados para alavancar o desempenho da empresa e a experiência do cliente, um enabler imprescindível nessa jornada (a ser abordado nesse post) é Cloud e por isso, tem sido a “fundação” que habilita a transformação do negócio e o foco estratégico (cloud-first) de muitas organização -avançar o uso de Cloud Services.

A estratégia cloud-first deve ser compreendida pela organização toda (não somente TI) e assim, buscar a obtenção dos benefícios de negócio, tais como redução do custo operacional, time to market e melhora na escalabilidade e segurança das aplicações. O objetivo das empresas pode variar, onde algumas buscam a migração completa de seus data centers, já outras apenas alguns subsets de aplicações para Cloud pública. Por isso, cloud-first não significa cloud-always.

Uma boa vantagem em utilizar Cloud Services é o uso sob demanda (otimização de recursos, sem grandes investimentos para começar a usar e sem desperdícios), escalabilidade e segurança, pois os recursos são gerenciados pelo provedor.  O desenho abaixo representa os principais Cloud Services que a AWS oferece:

aws-services

Inovação – Build, Buy e Borrow

Em geral, continuar com o recursos que você já domina, ampliando o uso da tecnologia existente é uma das opções consideradas. Evite a armadilha do resume-driven development, deixando as pessoas escolherem as tecnologias boas para o seu próprio currículo, e não para o problema.

Caso não seja possível ampliar o uso da tecnologia existente, então utilize os serviços do tipo pay-as-you-go. Esses serviços gerenciados (ou SaaS) reduzem a carga de trabalho em configuração e gestão de itens de infraestrutura, dedicando mais tempo a inovação e publicação de novas releases. A decisão build para novas tecnologias in-house pode gerar desperdício de custo, tempo e oportunidade. Avalie bem, pois o produto criado, em geral, é o diferencial competitivo, e não a tecnologia construída.

buy-build-borrow

Alguns elementos críticos para a inovação: cultura e pessoas, processos e organização, produtos e tecnologia. A estratégia Build, Buy or Borrow pode ser utilizada nesse contexto, e resumida da seguinte forma:

  • Build: quando já possui a expertise na empresa, core business, propriedade intelectual / patente ou pioneira no segmento.
  • Buy: quando é atividade core ao negócio, tem relação estratégia de mercado ou tempo crítico para lançamento.
  • Borrow: reduzir o risco, aumentar o time to market e customização em mercados específicos.

buy-build-borrow-matrix

Ao decidir a migração para Cloud Services, alguns benefícios comumente obtidos são:

  • Redução de riscos: capacidade de adaptar-se rapidamente as mudanças (por permitir testar com frequência e efetuar correções rápidas).
  • Escalabilidade: redimensionar seus recursos conforme necessário.
  • Confiabilidade: capacidade do sistema se recuperar de falhas de infraestrutura ou serviço ou adquirir recursos para atender à demanda e mitigar interrupções.
  • Segurança dos dados: propriedade total sobre seus dados.

cloud-benefits

 

Estratégias de migração Cloud

Uma das estratégias mais recomendadas para migração de aplicações em Cloud é o 6R’s da AWS, baseada no 5R’s de Gartner. Essa discussão, em geral, ocorre na segunda fase (Portfolio Discovery and Planning) do processo de migração, onde são determinados os ambientes, interdependências e o que será priorizado na migração.

A complexidade de migração varia, dependendo muito da arquitetura e do licenciamento existente. Enquanto uma arquitetura orientada a serviços possui baixa complexidade, um mainframe monolítico certamente trará uma alta complexidade. A figura abaixo resume os 6R’s:

6Rs-migration
Figura: AWS

  • Rehosting (“lift-and-shift”): não há mudanças na arquitetura. É a reimplantação do aplicativo em um ambiente de hardware diferente (em cloud). Isso altera a configuração da infraestrutura do aplicativo.
  • Replatforming: a arquitetura ainda não sofre alterações, mas há otimizações em Cloud para obter benefícios. Por exemplo, a migração do banco de dados para uma plataforma de banco de dados como serviço, como Amazon RDS.
  • Repurchasing : mudança para um produto diferente (geralmente em SaaS), tal como um CRM para SFDC.
  • Refactoring / Re-architecting: alterações nas práticas de desenvolvimento e arquitetura, usando recursos nativos em Cloud, que provê a infraestrutura para a execução do seu aplicativo.
  • Retire: descobrir o que não é mais utilizado em seu ambiente e que pode ser desativado, e assim, focar a atenção da equipe em aplicações que trazem benefícios ao negócio.
  • Revisit: não fazer nada (por enquanto). Isso acontece em aplicativos que foram atualizados recentemente ou que não fazem sentido migrar por enquanto.

 

Estágios de adoção

A AWS possui um conjunto de estágios que descrevem a postura associada as organizações na adoção Cloud. São quatro estágios:

  • Stage 1 – Project: inicia com alguns projetos para entender como a nuvem vai atender as necessidades do negócio. Utiliza experimentação em projetos early cloud, POCs, análise TCO/ROI e preparação a riscos/segurança.
  • Stage 2 – Foundation: com a percepção dos benefícios iniciais, a empresa pode escalar a adoção em toda a organização. A recomendação é criar um CCoE (Cloud Center of Excellence), responsável pelo treinamento/capacitação dos colaboradores, gestão de custos e ativos, estratégia de arquitetura híbrida, arquitetura de referência, entre outros.
  • Stage 3 – Migration: define-se então a estratégia de migração, geralmente iniciada com o processo de descoberta de aplicativos e um business case, seguido por migrações individuais (em várias estratégias de migração diferentes).
  • Stage 4 – Optimization: muitas empresas acham mais fácil otimizar seus aplicativos depois de migrá-los para a nuvem. Nesse estágio há infraestrutura automatizada e gestão própria do stack de soluções.

Targeted Business Outcomes - AWS Prescriptive GuidanceFigura: AWS

Processo de migração

A preparação e o planejamento para migração envolve work streams que atuam nas áreas de Landing Zone, Modelo Operacional, Governança, Security & Compliance, Pessoas (skills), Application Portfolio, Processo de Migração e Business Case.

Com o uso de metodologia, processos, ferramentas e recursos, define-se um objetivo de migração, geralmente avaliado em 3 à 4 meses de trabalho (estruturado em Sprints). Durante essa fase, as equipes realizam migrações iniciais para criar experiência e confiança através de quick wins. Os principais deliverables de preparação a migração são:

  • Landing Zones: configuração de ambiente seguro de várias contas.
  • CCoE (Cloud Center of Excellence) / Cloud Operations Model: treinamento e capacitação adequada aos times. Determinar as práticas operacionais para maximizar os benefícios de negócio.
  • Security and Compliance: resolução de gaps e implementação de práticas de segurança e compliance.
  • Portfolio Discovery and Migration: sequenciamento e planejamento das migrações.

 

Conclusão

Como vimos acima, a utilização de Cloud Services é um enabler muito estratégico a ser considerado no seu plano de transformação digital ou estratégia digital. Há diversas estratégias de migração, pois sabemos da dificuldade em manter os serviços core (nem sempre criados com as melhores práticas) em funcionamento e o custo que essa decisão pode acarretar na criação de novos produtos para a empresa.

A escolha de um bom parceiro é essencial para apoiar a jornada de adoção Cloud. Essa jornada exige skills especializados, tanto no conhecimento do negócio e aplicações da própria empresa, quanto em tecnologias Cloud. Além disso, uma boa governança é fundamental para habilitar o plano de migração e readiness e garantir em conjunto com a equipe que os objetivos serão atingidos.

Por fim, verifique os benefícios e aplicabilidade real em seu ambiente. As análises financeiras, tal como o TCO (Total cost of ownership), também são importantes para apoiar suas decisões. Quais são os custos de oportunidade e operacionais em manter aplicações ou serviços no ambiente atual? É possível ser inovador nesse cenário? Já avaliou alguma PoC? As features que mais geram receita para o negócio estão bem dimensionadas (custo x retorno)? Há insights com o uso de dados coletados? E o monitoramento e segurança das aplicações?

VSM (Value Stream Mapping) – do current ao future state

Após a introdução do Value Streams Mapping e seus benefícios, veremos aqui as etapas de criação, sequenciando as atividades que a empresa realiza para atender as demandas do cliente. O fluxo de valor percorre todas as áreas da organização, rompendo silos (entre áreas), em busca de oportunidades de melhoria e redução de desperdícios.

O mapeamento, em geral, envolve colaboradores experientes (e de áreas chaves) por ser um processo complexo e multifuncional. O cliente é a principal razão de acontecer o VSM. Por isso, verifique os benefícios e melhorias que podem ser feitas para os clientes. Quais os problemas que estamos resolvendo? Estamos melhorando a nossa capacidade de entregar valor e remover desperdícios?

O VSM é mais aplicável a processos repetíveis, especialmente quando houver handoffs (tempo de espera) entre os times, que é onde a maioria das demoras e desperdícios se encontram. O mapeamento possui três principais etapas: current state (estado atual; identificar os processos core business), future state (onde devemos estar em alguns dias com os recursos atuais) e next future state (visão estratégica “ideal” de onde poderia estar com recursos e automações ainda não disponíveis).

Um exemplo clássico, representado no desenho abaixo, demonstra todas as etapas de um processo para concluir a entrega do cliente. O value added time é tempo gasto em atividades que agregam valor ao produto. E o Lead Time é a soma de todos os tempos, do início ao fim do processo (inclui os tempos de espera entre as etapas). Percebe-se então a presença de gargalos no fluxo, devido a somente 15 minutos em atividades que agregam valor ao produto, e 68 dias para concluir o processo.VSM

Entre as principais métricas consideradas no VSM que ajudam a compreender os fluxos de entrega ao cliente estão: 

  • Lead Time: tempo decorrido entre o pedido e a entrega, medindo seu processo de produção da perspectiva do cliente.
  • Cycle Time: considera entre o tempo de inicio do trabalho e termina quando está pronto para entrega.
  • Takt Time: é a taxa de demanda do mercado (o ritmo do mercado), ou seja, o que precisa ser cumprido para atender à demanda do cliente.

lead-time-cycle-time

Current state
O desenho abaixo é um exemplo real de como era o ciclo de desenvolvimento em uma empresa, onde o Lead Time era de 19 horas – tempo médio entre o recebimento de uma demanda (via abertura de ticket) e o deploy em produção. Por questões de compliance, a empresa precisava de algumas aprovações e documentos durante o processo.

ALM-analise

Foram identificados alguns gargalos nesse fluxo:

  • Tempo de espera alto para validação do usuário e aprovação da mudança (change management). Causa: documentos preenchidos manualmente durante o processo geravam um checklist demorado.
  • Deploy manual demandava tempo de preenchimento do documento de publicação e do publicador em seguir as etapas.
  • A fase inicial (planning design) exigia a preparação de documentos que seriam utilizados no decorrer das etapas.


Future state

Ao reunir os colaboradores para discutir o future state do fluxo de valor, lembre-se de seguir alguns princípios Lean, tais como a criação do Flow (fluxo), processos vinculados aos clientes, eliminar os desperdícios, evitar super produção (seguir o takt time) e lotes grandes.

Existem diversas ferramentas que ajudam a mapear o fluxo de valor. O desenho abaixo é somente para ilustrar o fluxo to be com as principais mudanças (sem o uso de uma ferramenta específica para VSM), automatizando o deploy e simplificando o registro das informações das RDMs. Essas ações reduziram significativamente os tempos de espera entre trabalhos e o tempo que era gasto com preenchimento manual de documentos (documento de teste técnico, homologação e publicação).

change-management-process

VSM Symbols
Para conhecer melhor os símbolos que podem ser utilizados no VSM, recomendo assistir esse vídeo abaixo:


Playbook
Após ver todos esses conceitos importantes no VSM, como você planeja reunir as pessoas e conseguir mapear os fluxos de valor da sua organização? Um Workshop de VSM (2-3 dias) seria muito apropriado para isso, desde que considere alguns pontos:

  • Identificar um facilitador com experiência em VSM.
  • Identificar e priorizar Value Streams que tenham impacto no cliente e na estratégia organizacional. Escolha a que mais atenda a necessidade da empresa.
  • Envolver um Sponsor (ou champions) comprometido com o future state.
  • Empoderamento do time para realização das mudanças.
  • Na dinâmica, considerar o uso de Charter para discutir escopo, declaração do problema, objetivos e métricas.
  • Considerar a visão ideal future state (de longo prazo) com tecnologias e automações que ainda não estão disponíveis, mas que a visão estratégica deseja ter.
  • Levantar oportunidades e atribuir owners para as implementações.
  • Governança para acompanhamento das ações e planejamento de melhorias.

Também acordar uma reunião com o Sponsor e stakeholders para revisar os objetivos do Workshop, treinamentos (caso seja necessário), atividades Pre Workshop, facilities e a logística dos colaboradores.

VSM-agenda


Outcomes
Os resultados esperados com o VSM incluem melhorias nos tempos de entrega e percepção do cliente (lead time e cycle time), da qualidade e experiência de uso, além da redução de desperdícios no processo. Após a execução da agenda citada acima, os outcomes gerados são:

  • Mapa do fluxo current state
  • Mapa do fluxo future state (e ideal future state)
  • Métricas de performance
  • Plano de transformação para atingir o future state

VSM-outcomes

Entrega contínua de valor, mas o que é valor?

Muitas organizações vem investido na transformação ágil c/ a corriqueira reestruturação de times multifuncionais e “produtizados”, mudança de cultura, práticas DevOps, etc. para obter a tal a entrega contínua de valor. Mas o que é valor? Será que a sua organização compreende bem o value driven no ciclo de entrega e de fato, gera valor ao negócio?

Veremos mais adiante que o significado de valor pode variar para cada cliente, baseado na sua percepção em relação a aquisição, retorno financeiro, aderência compliance, posicionamento de mercado, entre outros. Esses conceitos iniciaram no Value-driven design (VDD), desenvolvido pela AIAA com a estratégia de realizar escolhas de design para maximizar o valor do sistema, em vez de atender aos requisitos de desempenho.

vdd

O Lean Startup aborda o trabalho em condições de extrema incerteza, com foco na descoberta de modelos de negócio disruptivos e valor gerado. A Values hypothesis verifica o valor gerado ao usuário pela resolução de um problema real. E a Growth hypothesis testa com que rapidez podemos adquirir novos clientes.

Também como identificar quando o product/market fit foi alcançado e como explorar o produto com o mercado identificado. E o uso de métricas para verificar se os resultados de negócio estão sendo obtidos, por exemplo, utilizando vanity metric e o correspondente actionable metric.

vanity versus actionable metrics

Ao utilizar o Scrum, por exemplo, certamente há o papel do Product Owner (PO) para maximizar o valor de negócio, priorizando as user stories de acordo com estudos e validações de hipóteses. Como o Scrum não prescreve uma definition of value, o PO fica como o responsável em decidir o que é valor ou não para o time. Claro, que em muitos casos alinhado com o  Product Manager.

organizacao-agil

Mas será que mesmo o time cumprindo a Sprint (ou outros ciclos de entrega) com produtos de qualidade e em ritmo sustentável, está entregando valor a organização? E o que acontece se não houver uma boa definition of value? Veja algumas perguntas reflexivas sobre a geração de valor na sua organização:

  • De que forma é verificado se todo o trabalho feito pelo time resulta em valor?
  • Há uma relação entre o esforço na construção das features e retorno?
  • Quais critérios são usados p/ verificar se uma feature tem mais valor que a outra?
  • Afim de maximizar o valor entregue, como são as decisões e comportamentos?
  • Plan Driven x Value Driven: como está o planejamento e aprendizado contínuo?

 

Geração de Valor

Embora haja inúmeras definições sobre a geração de valor e aplicabilidade em diferentes áreas, o nosso foco aqui é explorar a entrega de valor no contexto de desenvolvimento de software e produtos, utilizando métodos ágeis. Veja duas definições bem conhecidas:

Manifesto Ágil: um dos doze princípios ressalta a entrega de valor.

Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.

DevOps: definição da própria Microsoft sobre o propósito em adotar práticas DevOps.

É a união de pessoas, processos e produtos para permitir a entrega contínua de valor aos nossos usuários finais.

O termo business value é um dos meus preferidos, pois enfatiza o trabalho em prol da empresa ou do negócio como um todo de alguma forma. Acredito que tenham esses tipos diferentes de valor ao negócio (comentem caso utilizem algum outro):

business-value

  • Commercial Value: são as funcionalidades que geram receita ou saving para a empresa, tais como assinatura de serviço, versões ou módulos pago a usuários, aquisição de produtos e % attrition.
  • Market Value: tem mais relação com as ações de conversão/retenção de clientes e posicionamento da marca. Pode usar métricas de engajamento em redes sociais, taxa de conversão, custo de aquisição do cliente, entre outros. Também ser orientadas a inovação, criando novas funcionalidades que concorrentes não possuem.
  • Customer Value: a percepção de valor e experiência de uso dos clientes para aumentar as chances de continuar usando seus produtos. Testes A/B de usabilidade, interação, tempo de permanência, % retenção e NPS (Net Promoter Score).
  • Efficiency Value: melhorar a eficiência organizacional com a identificação dos fluxos de valor e automação de processos. A percepção de valor é na redução de erros em aplicações, lançamento frequente de novas funcionalidades (redução do time to market) e na redução de custos com suporte e manutenção.
  • Others: empresas regidas por compliance possuem percepção de valor em processos sob controle e auditáveis. Por isso, nesses casos, é muito importante construir funcionalidades que garantam a aderência as leis e regulamentações, por exemplo validação de passwords fortes, segregation of duties (SoD) e gestão de acesso.

Por fim, sabemos que o processo de Validated learning (muito abordado no Lean Startup) é descobrir empiricamente informações valiosas para o futuro e presente negócio da empresa. E que o modelo de experimentação contínua e validação de MVPs (Minimum Viable Product) é muito usado em Startups para criação de valor e evitar desperdícios.

Há nesse contexto o burn rate, adotado por muitas Startups para definir o valor gasto em um determinado produto, antes de começar a gerar receita. Ou então a decisão de pivotar para outra solução. Como a análise é muito investigativa (sobre estar construindo a solução correta a um mercado), a percepção de valor e métricas devem ser revisadas frequentemente.

 

 

 

 

O Lean Portfolio Management nas empresas

Afim de organizar melhor seu conjunto de projetos e alcançar os objetivos estratégicos, muitas empresas criavam o PMO (Project Management Office) para gerenciar o portfólio, priorizar projetos, facilitar a comunicação e o alinhamento estratégico. Essa abordagem tradicional não era bem voltada a disrupção digital, onde as empresas criam soluções inovadoras mais rapidamente em meio ao alto grau de incerteza.

Um resumo das principais diferenças entre a abordagem tradicional e Lean-Agile:

tradition-lean-agile-approach(adaptado do SAFe)

A competência em LPM (Lean Portfolio Management) é uma das sete core competencies para alcançar o Business Agility e alinha estratégia e execução, aplicando Lean e systems thinking. A gestão de portfólio inclui o desenvolvimento de value streams em domínios de negócio e visa a entrega de uma ou mais soluções para ajudar a empresa a alcançar os objetivos de negócio.

O SAFe (Scaled Agile Framework) considera três dimensões no Lean Portfolio Management:

LPM

  • Strategy & Investment Funding: assegurar que o portfólio e o budget das soluções estejam alinhados com a estratégia organizacional. Atuação de Business Owners, Enterprise Architects e Executives. Entre as principais responsabilidades:
    • Manter o backlog e visão do Portfólio: criação da Value Proposition e Value Streams.
    • Roadmap: uma visão das entregas previstas para os próximos períodos.
    • Lean budget e portfolio flow: o Portfolio Kanban system ajuda a visualizar e gerenciar o fluxo do Portfólio no nível de Epics.
  • Agile Portfolio Operations: coordenar as value streams, apoiar a execução do programa e promover a excelência operacional. Atuação do LACE (Lean-Agile Center of Excellence), CoPs (Communities of Practices) e RTEs.
  • Lean Governance: medir a performance do portfólio; ajustar o budget dinamicamente e aderência a compliance. Atuação do Enterprise Architect, Business Owners e APMO.

Os Temas Estratégicos são definidos no nível de Portfólio e representam os objetivos de negócios da empresa. Influenciam a estratégia do Portfólio e o fluxo de valor em todos os níveis: do mais estratégico (epics e features) até a execução das tarefas pelos times (detalhadas em user stories).

scaled-product

Métricas

As métricas são utilizadas para avaliar a performance do Portfólio organizacional em relação a estratégia de implementação, investimentos realizados, e a melhoria continua dos ARTs (Agile Release Train) e seus resultados. Entre as principais métricas recomendadas estão:

  • Nível Portfólio: Lean Portfolio Metrics e Value Stream KPIs.
  • Nível Programa: Feature Progress Report, Program Predictability Measure, CFD (Cumulative Flow Diagram) ou Burndown, DevOps Metrics e Program Performance Metrics.
  • Nível Time: Team Iteration Metrics e Team PI Performance.

metrics-nivel-programa

Em todos os níveis, também há métricas de self-assessment para realizar a autoavaliação e definir as melhorias que podem ser priorizadas em cada nível. A mudança nos três níveis habilita o Business Agility que é a capacidade da organização se adaptar rapidamente ao mercado e ao ambiente, priorizando a entrega contínua de valor ao cliente. O Business Agility Assessment apoia a avaliação da organização nesse sentido.

Por fim, um template que pode ser utilizado pelas Squads (nível de time) é algo como o relatório de fechamento por Sprint, que avalia o Team Iteration Metrics.

LPM-sprint