Essa é sem dúvidas uma das definições que debatemos todos os dias! O que é um serviço? A entrega de remédios em uma farmácia cidadã pode ser considerada um serviço? A emissão de uma carteira de identidade é um serviço? E o fornecimento de energia elétrica?

Encontramos muitas definições de serviços. Se você for no Wikipédia encontrará o termo da seguinte forma:

Um serviço é um produto da atividade humana que satisfaz a uma necessidade, sem assumir a forma de um bem material.

Pela definição, um serviço só é um serviço quando se atende a uma necessidade do cliente. O site investorwords.com, define a palavra como:

Um tipo de atividade econômica que é intangível, não armazenada e não resulta em propriedade.

Se consideramos que um serviço seja intangível, não vamos ter a possibilidade de sentir, estocar ou guardar, por exemplo. Consideremos ainda os serviços prestados por motoristas de aplicativos, professores particulares, e garçons, nenhuma destas atividades pode ser prestada sem que o cliente esteja presente. Neste caso são intangíveis e devem ser consumidos no ponto de venda, onde a atividade acontece.

Agora imagine a água de sai da sua torneira toda vez que você a abre. A empresa está prestando um serviço de levar a água até sua casa e você tem total controle sobre a quantidade de água que sai. Podemos medir e consequentemente pagar por ela. E mais ainda, podemos armazenar esta água. A pergunta que faço agora é: onde termina a empresa e em que ponto começa o serviço?

Se formos para a literatura científica, Grönroos (2001) e muitos outros estudiosos definem o termo como uma atividade ou série de atividades de natureza mais ou menos intangível que normalmente, mas não necessariamente, ocorrem na interação entre o cliente e:

os funcionários do serviço,  e/ou
recursos físicos ou bens,  e/ou
sistemas de o provedor de serviços

que são fornecidos como soluções para as necessidades dos clientes. Sendo que, para esta relação acontecer, as três dimensões principais são:

(1) atividades;
(2) interações (que poderíamos dizer que separam os serviços dos produtos físicos); e
(3) soluções para problemas do cliente.

Segundo Gummesson (1995), uma outra definição que gosto muito, ele diz que:

Os consumidores não compram bens ou serviços, mas compram ofertas que prestam os serviços, que criam valor. Ele usa valor em vez de soluções para os problemas dos clientes.

Precisamos responder também, o que o serviço faz pelo cliente e o que de fato o cliente compra. E como fica a experiência do cliente?

Em uma tentativa de responder a esta última pergunta, vou me ater a definição, ou as definições de serviços que uso e acredito que mais se aproxima do que faço hoje. Ela está descrita no livro: O Modelo Toyota e Excelência em Serviço do Jeffrey Liker. O autor é referência top 1 pra mim!

Liker descreve o termo serviço levando-se em consideração a complexidade do trabalho. E para classificar estes serviços em alta ou em baixa complexidade, adotamos duas variáveis chaves para esta construção: customização e intagibilidade.

O quanto o serviço é customizável? Padrão (baixo) versus customizado (alto),
O quanto o serviço é intangível? Produto tangível do sistema de serviço (baixo) versus experiência do cliente (alto)

Quando cruzamos as duas variáveis em uma matriz 2 x 2, temos as seguintes combinações:

1 – Distribuição de bens produzidos em massa: customização baixa e produtos tangíveis – são os itens que não dependem de muita complexidade e não há nada personalizado. A indústria produz de forma mecânica e se preocupa em distribuir ao mercado. Imagina por exemplo a Ambev quando produz a Brahma.

2 – Distribuição de bens personalizados: Também temos algo tangível aqui, entretanto de customização alta. São produtos restritos, geralmente mais caros e luxuosos. Alguém que crie softwares customizáveis ou uma atriz que compre um vestido exclusivo para a noite do Oscar são exemplos deste tipo de produtos. Outro bom exemplo são as customizações dos carros feitos para os ricos e famosos da música norte-americana.

3 – Experiência padrão: Esta é a definição que melhor se encaixa na definição de serviço como algo intangível. Não há produto tangível aqui, entretanto ele é padronizado. Imagina que você precise contratar uma TV por assinatura, por exemplo. Você vai até o site da operadora e lá existem os pacotes pré estabelecidos que você pode adquirir. Existe pouca ou nenhuma flexibilidade em alterá-los. São diversos cientes com experiência semelhantes.

4 – Experiência personalizada: Não há tangibilidade e a experiência é o diferencial. Geralmente também mais cara e para um público restrito. Imagina que você decide ir para a academia e lá você encontra o instrutor que passa geralmente o mesmo programa para pessoas que estão no mesmo nível que você. Caso não opte por este programa, é possível lançar mão de um personal trainer. Um serviço exclusivo, customizado para o seu objetivo.

Uma observação importante: nas organizações da manufatura os serviços estão em função da produção. Já nas organizações de serviços, vemos a relação com o cliente em primeiro plano e a manufatura em segundo plano. O paradigma da manufatura é focado em bens. Tecnologia, pesquisa e desenvolvimento são importantes, bem como o design, engenharia, manufatura em massa, marketing em massa, operações em larga escala, automação, computadores e especialização. A produtividade desempenha um papel importante e, consequentemente, há uma orientação em relação aos custos e capital empregado. Qualidade significa cumprir com as normas e especificações técnicas.

O paradigma de serviço cresceu principalmente na área de marketing, mas também é suportado pelo gerenciamento moderno da qualidade. O foco é o interesse no cliente e a interação do cliente com os próprios prestadores do serviço e é claro na criação de valor. O cliente é um parceiro e a criação de valor é um equilíbrio entre a intervenção humana e a tecnologia, entre custo e receita e entre a qualidade e a produtividade percebidas pelo cliente. O pensamento de processo está no centro da prestação de serviços.

E aí, o que achou das definições. Já sabe qual o tipo de serviço você presta? Qualquer coisa, escreve nos comentários! Minha intenção foi provocar mesmo alguns questionamentos!

Grande abraço e até a próxima!

Referências:

• Artigo: Dr. Evert Gummesson (1995) – Relationship marketing: its role in the service economy
• Livro: Marketing. Gerenciamento e Serviços do Christian Grönroos
• Livro: O Modelo Toyota e Excelência em Serviço do Jeffrey Liker

Muitos alunos me perguntam sobre as referências em relação ao Método Kanban. Nas aulas eu apresento o livro clássico do David Anderson, mas nós temos outros livros que servem de apoio para aprimorarmos nosso conhecimento no método.

Vou atualizar este post com frequência caso tenhamos novas referências.

Livros

Kanban: Mudança Evolucionaria de Sucesso Para Seu Negocio de Tecnologia

Autores: Donald G. Reinertsen, David J. Anderson, e outros.

Link para comprar

Quem quer começar com o método deve ler este livro. É leitura obrigatória! No livro, David Anderson explica os fundamentos do método, e como foi a transição do kanban da manufatura para nós, trabalhadores do conhecimento. O livro é repleto de cases e exemplos práticos. 

Fit for Purpose: How Modern Businesses Find, Satisfy, & Keep Customers

Link para comprar

Autores: David J Anderson e Alexei Zheglov

Este livro também apresenta muitos exemplos comerciais altamente acessíveis. Este livro ajudará você a encontrar novos clientes em novos segmentos de mercado, a satisfazer melhor seus clientes existentes e a mantê-los.

O livro destina-se a planejadores estratégicos, gerentes e planejadores de produtos, gerentes de portfólio, projetistas de serviços, gerentes de prestação de serviços e a qualquer pessoa que queira entender como lançar e manter produtos nos mercados complexos e voláteis do século XXI.

Kanban Maturity Model: Evolving Fit-for-Purpose Organizations

Autores: David J Anderson e Teodora Bozheva

Link para comprar

O Kanban Maturity Model (KMM) é uma ferramenta nova e poderosa para coaches e consultores que assessoram empresas de médio e grande porte na transformação e melhoria usando o Método Kanban. Este livro mapeia sete níveis de maturidade organizacional contra as seis práticas gerais do Kanban para assegurar a aplicação apropriada do Kanban e a adoção bem-sucedida da abordagem. O KMM descreve um roteiro e ações concretas que permitem que as organizações atinjam a agilidade de negócios adequada ao propósito.

Practical Kanban: From Team Focus to Creating Value

Autor: Klaus Leopold

Link para comprar

Neste livro o autor descreve em detalhes os princípios e funcionalidades do Kanban, que nem sempre são intuitivas. Ele discute problemas típicos que observou em seu trabalho com sistemas Kanban do mundo real. Klaus ilustra as possibilidades que existem quando toda a cadeia de criação de valor de uma empresa é levada em conta. Fica claro que o Kanban não é um método de equipe, mas sim um método de melhoria que considera toda a cadeia de criação de valor de uma empresa.

Lessons in Agile Management: On the Road to Kanban

Autor: David J Anderson, Alan Shalloway, Stephen Denning

Link para comprar

Esta coleção de mais de 150 artigos compilados do blog Agile Management e de várias outras fontes representa 12 anos de insights inestimáveis ​​de David J. Anderson no gerenciamento de desenvolvimento de software de 1999 até 2011. Cada artigo foi cuidadosamente selecionado e agrupado em 16 capítulos sobre temas como Liderança, Gestão, Teoria das Restrições, Políticas de Recursos Humanos, Agile, Lean e Leading Change Initiatives. Cada capítulo é apresentado com comentários contemporâneos, explicando sua relevância e contribuição para o Ágil e o Kanban.

Kanban Change Leadership: Creating a Culture of Continuous Improvement

Autor: Klaus Leopold, Siegfried Kaltenecker

Link para comprar

Este livro fornece uma compreensão do que é necessário para entender adequadamente o gerenciamento de mudanças com o Kanban, bem como como aplicá-lo de maneira ideal no local de trabalho. Os autores organizaram o livro em três seções. A primeira seção foca os fundamentos do Kanban, estabelecendo a base técnica e indicando os mecanismos necessários para promulgar a mudança. Na segunda seção, os autores explicam o contexto do gerenciamento de mudanças – as opções de mudança, como elas podem ser colocadas em movimento e suas consequências para um negócio. A terceira seção aborda os tópicos das seções anteriores e os relaciona ao sistema social de negócios – o objetivo é guiar os leitores no processo de construção de uma cultura de melhoria contínua, revisando estudos de casos reais e vendo como o Kanban é aplicado em várias situações.

Kanban from the Inside: Understand the Kanban Method, connect it to what you already know, introduce it with impact

Autor: Mike Burrows, Luke Hohmann

Link para comprar

Kanban from the Inside tem uma abordagem distinta do Método – usando um sistema de nove valores para explicar o que é o método. Também dá uma ideia de como seus praticantes pensam, e ainda apresenta algumas dicas sobre como aplicá-lo. Leitores novatos no Kanban entenderão por que e como funciona, enquanto aqueles com experiência apreciarão sua nova perspectiva e as conexões que ela faz com uma série de modelos relacionados.

Certificações

A principal certificação de Kanban hoje no mundo é a KMP. Ela é dividida em dois níveis: O KMP I e o KMP II. Para se certificar em Kanban Management Professional, os dois treinamentos são necessários. A principal certificadora é a Lean Kanban University.

Confira as certificações em Kanban da Lean Kanban University

Team Kanban Practitioner
Kanban Management Professional
Kanban Coaching Professional
Accredited Kanban Trainer

No Brasil temos excelentes treinadores de Kanban, com destaque para duas empresas: Aspercom e a Knowledge 21.

• Rodrigo Yoshima
• Rodrigo de Toledo

As duas empresas fornecem o treinamento oficial da Lean Kanban University!

Link para o meu perfil na LKU: Rodrigo Zambon

O Pensamento Sistêmico é uma forma de entender como o sistema se comporta como um todo, ao invés de de analisar componentes isolados. Entender o sistema é fundamental e vai influenciar na definição dos passos para introduzirmos o Kanban em uma organização. As etapas neste processo não são necessariamente sequenciais, mas são iterativas, usando o aprendizado de uma etapa para informar e influenciar as outras em um ambiente colaborativo. Os passos são:

Passo 0: Identificar os serviços

Para cada serviço:

Passo 1: Entender o que faz um serviço ser ajustado ao propósito do cliente

Passo 2: Entender a origem das insatisfações do processo atual

Passo 3: Analisar a demanda

Passo 4: Analisar a capacidade

Passo 5: Modelar o fluxo de trabalho

Passo 6: Descobrir as Classes de Serviço

Passo 7: Projetar o sistema kanban

Passo 8: Socializar o design e negociar a implementação

STATIK é aplicável a apenas um serviço. Quando tivermos mais de um serviço as práticas e cadências do Kanban são aplicadas para equilibrar a demanda e o fluxo através dos vários serviços, e melhorar continuamente. A ordenação das etapas podem variar na prática e é normal para revisar os passos em busca de melhorias.

Passo 1: Entender o que faz um serviço ser ajustado ao propósito do cliente

Esta primeira etapa é considerada um tópico mais avançado e em muitos casos em implementações iniciantes ou com baixa maturidade ele é ignorado.

Explore os critérios que definem a satisfação do cliente com a prestação dos serviços. Os critérios são geralmente relatados, mas não são limitados ao tempo de entrega, qualidade, previsibilidade, segurança ou marcos regulatórios. Estes critérios são conhecidos como critérios de adequação, porque determina como o cliente avalia se a prestação do serviço é aceitável, ou se servem ao propósito.

Explorar e estabelecer níveis de expectativa para cada critério. Estes são conhecidos como os limites aplicados aos critérios de adequação. Eles representam o “bom o suficiente” ou o ponto onde o desempenho é satisfatório. Essas métricas devem tornar-se indicadores chave de desempenho (KPIs) e ser usado para estabelecer Níveis de Expectativas de Serviços (SLEs) ou informar negociações dos Acordos de Níveis de Serviço (SLAs) onde apropriado. Os critérios limites de adequação são usados para conduzir melhorias e mudanças evolutivas.

Onde este passo é inicialmente ignorado, teremos que retroceder na para a implementação do Kanban. O aumento da maturidade organizacional e rigor quantitativo são necessários para futuras melhorias.

Passo 2: Entender a origem das insatisfações do processo atual

Esta etapa é feita em duas etapas: perguntar ao cliente porque eles não estão felizes; perguntar a organização que está prestando o serviço se eles têm fontes internas de insatisfação — levantar os itens que estão impedindo-os de fazer um trabalho bom e profissional e de satisfazer as expectativas dos clientes.

Frequentemente as fontes de infelicidade em cada lado, externas e internas, podem ser combinadas — consertando uma, você conserta a outra. Por exemplo, um cliente pode reclamar da entrega imprevisível e atrasada, enquanto que internamente, os trabalhadores podem se queixar de serem interrompidos e prejudicados com pedidos não planejados ou novas requisições em uma classe de serviço mais urgente.

Se pudermos identificar as fontes das demandas não planejadas e o que está prejudicando a equipe, podemos eliminar as interrupções, tornando nossa prestação de serviços mais previsível. Corrigindo um problema, pode-se fazer ambos os lados mais feliz — os trabalhadores não sendo interrompidos, eles podem se concentrar em fazer um trabalho profissional e consequentemente o cliente receberá a entrega dentro de um intervalo razoável em relação a sua expectativa inicial.

Fontes de insatisfação fornecem subsídios para desenharmos o Kanban. Vamos tentar projetar o Sistema Kanban, a capacidade alocada e as classes de serviços para eliminar o máximo de problemas possível. A julgar o quanto pode ser alcançado sem criarmos uma resistência significativa, estas alterações são consideradas um tema de treinamentos avançado e fora do âmbito do Kanban Essencial.

Passo 3: Analisar a demanda

A fim de criar um sistema kanban adequado, precisamos saber a natureza da demanda: quem são os clientes; o que eles pedem; como é a taxa de chegada; o padrão de entrada dos pedidos e quais são suas expectativas — seria uma versão mais light, mais qualitativa do passo 1. Se o passo 1 foi ignorado, por exemplo, “esperamos entregas mais previsíveis para a maioria dos pedidos”.

A primeira tarefa é identificar os tipos de itens de trabalho. Por exemplo, se nós operamos um café, nós estamos no negócio de servir café. O que é equivalente a um pedido de uma xícara de café no ambiente de análise? Quantos tipos diferentes de requisições existem?

Descobrir o tipo de trabalho pode ser um problema não tão óbvio e as pessoas muitas vezes lutam para chegar a um equilíbrio entre o os níveis de detalhes suficiente e um nível adequado de abstração. Por exemplo, uma xícara de café pode ser muito abstrato, mas cada item no menu como um tipo de item de trabalho separado remete a muitos detalhes.

O equilíbrio pode ser atingido ao separarmos café expresso, café filtrado,café por gotejamento, separar café de chá e outras infusões. Ter vários tipos facilita uma melhor gestão dos riscos e indica o fluxo e os recursos necessários, tais como a máquina de café expresso. Ter muitos tipos de trabalho não provê uma agregação suficiente de requisições similares que facilitem a abordagem probabilística para a gestão da natureza não-determinística da demanda.

Para cada tipo de item de trabalho identificado, queremos entender a taxa de chegada — o volume de demanda — o padrão de chegada — a taxa de demanda ao longo do tempo e em diferentes momentos do dia, das semanas, dos meses e do ano. Queremos entender o fluxo e o refluxo da demanda.

Por exemplo, um café pode reconhecer um aumento na demanda por xícaras de café das oito às nove da manhã, ou imediatamente depois do almoço.

Compreender o volume da demanda, a natureza de chegada e as expectativas ou os riscos do negócio associados aos pedidos, nos permitirá projetar um sistema kanban elaborado com a atribuição de capacidade para diferentes tipos e diferentes classes de serviço para gerir riscos específicos. Por exemplo, um demanda com data fixa, tais como eventos sazonais, feiras, grande eventos mundiais como Jogos Olímpicos ou mesmo datas impostas sem possibilidade de negociação. O quanto deste tipo de demanda existe? Qual a taxa de chegada deste tipo de demanda e quando chega? Com quanto tempo de antecedência ela chega? Este tipo de trabalho pode exigir sua própria classe se serviço para assegurar que receba um tratamento prioritário e seja sempre entregue no horário.

Em implementações maduras e avançadas, a demanda é analisada em categorias como valor versus falha, entrega versus demanda por informação, contestáveis versus incontestáveis, planejada versus demanda não planejada. Está análise adicional é informada no sistema kanban, mas também servirá para ações de melhorias que deverão ser tomadas mais tarde.

Passo 4: Analisar a capacidade

Analisar a capacidade é um passo que em muitas implementações é ignorado, principalmente em organizações com baixo nível de maturidade ao se criar um sistema novo.

Analisar a capacidade envolver estudar os dados históricos em relação ao que já foi entregue: tempo de atravessamento, qualidade funcional e não funcional, previsibilidade, conformidade com os requisitos ou normas regulamentares. A capacidade atual pode ser comparada com as expectativas de nível se serviço dos clientes.

Dado que existam fontes de insatisfação, é provável que exista uma lacuna, talvez uma das mais importante entre a capacidade atual e as expectativas dos clientes existentes. É comum um Diagrama de Fluxo Contínuo histórico ser utilizado na análise de capacidade e ainda podemos tentar alguns cálculos de eficiência de fluxo se os dados estiverem disponíveis saber o tempo de trabalho (esforço despendido) e a duração das atividades (tempo decorrido no calendário).

Passo 5: Modelar o fluxo de trabalho

A modelagem do fluxo de trabalho deve ser realizada para cada tipo de trabalho. É importante não confundir modelagem de fluxo de trabalho com o mapa da cadeia de valor, ou a ida ao Gemba do lean manufacturing e o Sistema Toyota. Mais uma vez, estamos trabalhando em serviços profissionais em ambiente de bens intangíveis. Kanban se adaptou a isso adotando técnicas de mapeamento de fluxo vindos do Desenvolvimento de Produto Enxuto. Ambos Reinertsen e Kennedy têm descrito técnicas de modelagem de fluxo de trabalho semelhantes, mas usando uma linguagem um pouco diferente. Em geral, nós preferimos a linguagem de Kennedy, mas a abordagem do Reinertsen nos leva ao resultado.

Você mapeia a série ou a sequência dos passos principais para descobrir novos conhecimentos. Nós estamos modelando o trabalho do conhecimento. Que atividade nos dá mais conhecimento? Em algum momento haverá retorno decrescente desta atividade e então teremos que nos mover para a próxima atividade dominante. Em um processo de desenvolvimento de software nós adquirimos conhecimento ao analisarmos um problema ou mesmo um domínio do negócio. Mais tarde nós poderemos utilizar o desenho do sistema para resolver problemas ou simular funcionalidade do negócio. Mais tarde nós desenvolvemos os códigos e os testes. Depois executamos os testes. Em cada fase temos mais conhecimento, mais detalhes da entrega final. È uma abordagem iterativa, onde mais conhecimento está na camada de cima onde existe menos conhecimentos específicos. Reinertsen usa a palavra “informações” em vez “conhecimento”, mas são equivalentes — definir a sequência de atividades dominantes utilizadas para descobrir informações sobre o produto acabado.

È importante mapearmos as atividades e não as transferências entre as pessoas. Ao contrário do mapa da cadeia de valor ou da ida ao gemba, nós não queremos um quadro Kanban que mapeia a transferência entre as pessoas, em vez disso, queremos o focar no trabalho e no que acontece com ele. Nós queremos nosso sistema kanban (e o quadro) para incentivar a colaboração em vez de evidenciar o engessamento dos setores ou especializações funcionais existentes.

A palavra “dominante” também é importante. A qualquer momento pode haver várias atividades acontecendo, mas uma delas é a atividade dominante para descobrir novos conhecimentos. Por exemplo, quando uma função de um software está sendo testada, dizemos que ela está em teste. É a atividade de teste que é a atividade dominante para a produção de novos conhecimentos. Os testes podem falhar e resultar em retrabalho no código, no design ou mesmo na análise. No entanto, é a falha no teste que produz novos conhecimentos. Neste exemplo, o uso da palavra informação pelo Reinertsen faz mais sentido. É a falha no teste que nos fornece a nova informação sobre o produto acabado.

Passo 6: Descobrir as Classes de Serviço

A classe de serviço é um conjunto de políticas que descrevem como algo deve ser tratado. Normalmente com os sistemas kanban, as classes de serviços descrevem a disciplina de enfileiramento ou prioridade dos tickets. Classes de serviços também podem descrever a política que afeta o fluxo de trabalho, tais como se um item precisa receber tratamento de um especialista ou ser testado com um nível específico de qualidade. Classes de serviço também podem fornecer informações sobre cronograma ou se determinado item pode exceder o WIP ou não.

Se houver classes existentes de serviço, elas devem ser declaradas explicitamente, e devem ser acomodadas pelo sistema Kanban. No entanto, é mais comum que estejamos lidando com classes de serviços ocultas ou implícitas. Por exemplo, se há a política de que um tipo de trabalho permite interromper um outro tipo, consequentemente interromper um desenvolvedor para dar prioridade a outro tipo de trabalho, essas políticas são descritas como classes de serviços implícitas. Queremos expor esse tipo de política, pois nos leva a perguntar: “Você realmente quer nos dizer que trabalho do tipo X tem prioridade sobre trabalhos do tipo Y?”

Classes de serviços ocultas existem quando não há política, mas alguns itens recebem o tratamento diferente dos outros. Muitas vezes isso acontece por causa da fonte de demanda ou o destino da entrega. É comum encontrar pedidos de um executivo sênior que não estejam passando pelo processo formal de governança e seleção formal e vão para o topo da priorização. Queremos identificar essa classe, atualmente oculta e serviço e torná-la explícita. Será importante que todo o nosso sistema Kanban seja projetado para lidar com as classes de serviço, ou que eles sejam expostas aumentando a transparência para facilitar uma discussão que nos permite incluí-las no quadro.

Passo 7: Projetar o sistema kanban

Um sistema kanban consiste em quatro elementos principais: o sistema e o kanban; os tickets, o quadro; ajustes as reuniões existentes, bem como a introdução de novas para acomodar os ciclos de feedback conhecidas como as Cadências do Kanban.

Para projetar o sistema kanban, precisamos de modelo de fluxo de cada tipo de trabalho, conhecer as atividades dominantes para descobrir novos conhecimentos e as classes de serviço.Vamos querer inventar limites (WIP) para cada fase, tipos e classes de serviços através do quadro.

Para incluirmos um ticket, vamos precisar entender quais as informações são requeridas em cada estágio do fluxo, a fim de tomarmos a decisão de puxar um item para o próximo estágio. Normalmente precisamos do tipo de item, da classe de serviço, datas de início e fim se aplicáveis, se será no fluxo do especialista ou não, e espaço para gravar o tempo decorrido desde do início, os bloqueios, tempo em cada etapa, riscos de negócio, técnico ou de entrega, associados a um determinado item que poderia afetar sua seleção, seu sequenciamento ou agendamento.

Para projetar o quadro, precisamos entender o fluxo de trabalho de cada item. Precisamos tomar a decisão de ter um único quadro para todos os tipos ou classes, ou ter dois ou mais quadros. Precisamos decidir como alocar as colunas — usualmente as fases do fluxo — as linhas — usualmente os tipos ou composições destes — e as cores dos tickets — geralmente para as classes de serviços.

É possível que haja trocas entre o sistema, o quadro e o fluxo e o ticket. Por exemplo, se termos um conjunto de atividades opcionais que podem acontecer em qualquer sequencia, mesmo que simultâneo, podemos optar por termos um quadro simples com uma única coluna , um fluxo simples e um sistema kanban com apenas um tipo de ticket para todas estas atividades, e usar um checkbox no próprio ticket com as etapas “requerido” — “pronto” a fim de lidar com o sequenciamento não determinado e potencial concorrência entre as atividades.

Como regra geral, quanto mais determinista nosso sistema, vamos esperar ter um quadro e um fluxo mais complicado, quanto menos determinista mais simples, porém com um cartão de ticket mais complicado.

Temos um total de 7 reuniões de cadência no método Kanban. É comum que em novas implementações comecemos com algumas delas. Também é comum redirecionarmos as reuniões existentes. Decida quais as reuniões serão implementadas. Decida quais as reuniões existentes serão redirecionadas. Você pode usar os exercicio da formação Kanban Management Professional para definir a cadência das suas reuniões: selecione quem será o facilitador, a frequência e a duração, quem deve participar e quais informações precisam trazer, quais as decisões serão tomadas nas reuniões e quais métricas e relatórios serão necessárias.

Passo 8: Socializar o design e negociar a implementação

O método STATIK incentiva oficinas colaborativas para análise e criação de sistemas Kanban e os quadros. Como consequência da natureza colaborativa dos workshops e dos exercícios seguindo os passos do STATIK, é comum para todos os envolvidos participarem da mudança e ficarem orgulhosos da implementação. Em outras palavras, nossa abordagem é ganhar adeptos e envolvê-los no projeto.

Ao selecionar os grupos para a construção do STATIK, é interessante contarmos com pessoas internas e externas à organização. Times multifuncionais, clientes, stakeholders externos e tomadores de decisão.

Dito isto, não é realista que todos os stakeholder terão um papel definido nas oficinas de STATIK. É necessário circular o produto da oficina, a fim de obter um grupo mais amplo para aderir ao projeto. Embora este seja um campo avançado, existem alguns princípios básicos:

Faz sentido se reunir com as partes interessadas em particular. Se eles são stakeholders externos, vale a pena começar com humildade. Explique como você entende a prestação de serviços e que está procurando fazer as alterações para melhor atender os clientes. Explique que as mudanças são principalmente internas, mas os que estão de fora poderão notar as mudanças de como interagimos, mudança na interface de como eles fazem novos pedidos, como aprovam ou selecionam os trabalhos para serem entregues, mudança nas métricas, relatórios e visibilidade do que eles tem no novo sistema, comparado com o anterior.

Caminhe com eles através do sistema, explicando como funciona do ponto de vista deles, ouvindo o feedback. Você vai obter algumas objeções que exigirão ajustes nas classes de serviços, nas atribuições de capacidades, nos desenho do quadro e nas exigências de relatórios. Quando for possível, faça as mudanças no quadro e nos istema. Procure pelo consenso ao mostrar que as alterações propostas irão atender as necessidades do stakeholders, assumindo que as mudanças serão adequadamente aplicadas.

Retrabalhar seu projeto para acomodar o que você aprendeu com a socialização. revisitar algumas partes interessadas para o ateste de que suas preocupações foram incorporadas.

Depois de ter feito isso, você está pronto para realizar uma reunião de kick-off para lançar a iniciativa Kanban e a introdução das mudanças. Convide todos os stakeholders.

Mais uma vez, comece com humildade. Você entende que a prestação de serviço não foi eficiente, você está procurando fazer mudanças para melhorar e satisfazer todos os envolvidos considerando que os recursos são limitados e não infinitos e alguns compromissos tem que ser aceitos. na medida do possível preserve o que está funcionando bem e foque apenas no necessário para melhorar a prestação do serviço. Os presentes podem notar mudanças na forma de como eles interagem com o grupo, mas por outro lado os papéis e responsabilidades não devem ser afetados. Agora apresentamos o detalhe do projeto explicando como cada parte interessada, os tipos de trabalho e as classes de serviços foram acomodadas. Para os agentes internos que são afetados pela mudança nas suas funções ou responsabilidades, explique o que estas mudanças significam. Forneça detalhes sobre a revisão das reuniões existentes para acomodar as cadências do Kanban. Explique onde os quadros ficarão situados ou onde o software está sendo implantado.

Você deve estar pronto para começar.

Tradução do artigo publicado por David Anderson

Assim que você assimilar algo que está escrito abaixo, considere, mas continue a desenvolver. Esta foi exatamente a forma que os Flight Levels foram construídos. Eles estavam sendo lançados no meu livro “Kanban in der Praxis”, e apesar de já terem sido discutidas muitas e muitas vezes, ao consultar clientes, nos treinamentos e nas apresentações, meu ponto de vista mudou – graça ao feedback dos leitores e da audiência dos participantes dos treinamentos.

O modelo Flight Model apresenta uma questão principal: quais níveis de organização oferecem qual alavanca para melhoria? Nesta linha, eu reorganizei o Flight Level porque a entrada ocorre ou não de forma controlada ou desordenada (até agora, esta é a característica que distingue o nível 1 do nível 2) e é uma questão de detalhes que confunde os fundamentos do modelo. Na maioria das empresas, existem mecanismos para decidir o que deve ser feito em seguida. Se esses mecanismos são eficientes ou não, este é um tema da melhoria, mas isto não importa muito para o modelo Flight Level. Como resultado a partir das mudanças, surgiu uma nova estruturação para o Flight Levels que vou descrever abaixo:

Flight Level 1 – Nível operacional

Flight Level 2 – Coordenação

Flight Level 3 – Gestão estratégica de portfólio

Embora o Flight Level aconteça através do Kanban, ele ainda é uma modelo de propósito geral para o desenvolvimento organizacional. Quando eu trabalho com os meus clientes, por exemplo, frequentemente o foco é implementar medidas nos níveis 2 e 3 para melhorar a coordenação e a direção estratégica, enquanto que o nível da equipe ou o nível operacional funcionam com Scrum. Como tal, não é importante qual o método é usado no nível individual. O importante é como a comunicação e a coordenação entre os níveis serão organizados. Se você pode fazer melhorias na comunicação e na coordenação, toda a criação de valor começará a ser otimizada – e isso é, em última análise, nosso objetivo.

Eu não escolhi aleatoriamente o nome “Flight Levels”. O nível de voo relaciona-se com a altitude e a analogia também deve ser feita no contexto organizacional: quanto mais alto você voa, sua visão geral aumenta, entretanto com menor nível de detalhes. Quanto mais baixo você voa, você pode ver mais detalhes, mas não verá a paisagem inteira.

O modelo Flight Level é um instrumento de comunicação que revela o efeito de etapas específicas de melhoria em diferentes níveis, e também ajuda a encontrar o ponto de partida mais eficaz dentro da organização para começar com estas melhorias.

Flight Level 1: nível operacional

O primeiro nível de voo pertence a equipe, que faz o trabalho diário. Muitas vezes os envolvidos são especialistas que encontram-se diariamente para fazer o trabalho, mais comum em ambientes de alta tecnologia. Este especialistas trabalham em uma parte de um sistema maior, tais como o sistema de injeção de combustível para automóveis, ou no processamento gráfico de um radar meteorológico para aviões. Outra característica dos nível 1 são as equipes multifuncionais, compostas por designer, desenvolvedor e testador, que trabalham juntas em um produto ou em um subsistema. Geralmente uma demanda grande é dividida em pedaços menores e é implementada passo-a-passo. Deste ponto de vista, o sistema de trabalho ajuda o time a visualizar, limitar e melhorar continuamente seu processo de trabalho. Quando uma empresa é composta de muitas equipes, e não apenas uma, os limites para a otimização ocorrem na interface de uma unidade para outra, e como já vimos no experimento de fluxo, isso pode acarretar a sub-otimização de todo o sistema. As melhorias são limitadas apenas dentro da equipe e pode causar dificuldades as demais equipes que compõem a organização.

A maior desvantagem é que os desejos dos clientes não são plenamente compridos, apesas de todo o empenho da equipe. Para explicar isso, vou usar o teclado como exemplo.

Vamos imaginar que o cliente deseje escrever uma carta. Vamos imaginar ainda que cada equipe da organização seja responsável por uma linha do teclado. Cada equipe é excelente em  desempenhar seu papel, mas sempre há margem para melhoria. Por exemplo, o time 3 pode otimizar-se até bater o novo recorde mundial para apertar a tecla “a” mais rápido. Seria fantástico! No entanto, a carta do cliente não será escrita mais rápido por causa disto. Quando estamos escrevendo a carta, não se trata apenas de poder apertar com rapidez apenas uma letra do alfabeto. É mais importante que a letra correta seja digitada no momento certo, a fim de alcançar um aumento real no desempenho. É por isso que o foco na melhoria deve envolver toda a organização. A organização deve ser aquela que se ajusta ao cliente em um processo evolutivo: o que deve ser feito para gerar o maior valor para o cliente? Se houver mais de uma equipe no nível operacional, é importante coordenar o trabalho. Não importa seu ramo ou a sua área: no caminho do “conceito ao dinheiro” existe como regra, dependências entre os times. Cada time, ou cada unidade completa apenas uma parte da criação do valor a ser entregue ao cliente, Para que a coordenação seja útil, precisamos primeiro identificar o caminho que o valor percorre até a entrega. Se uma organização é ágil ou não, isto não tem nada a ver com a quantidade de equipes ágeis atuando dentro da organização. A interação entre as equipes é que deve ser ágil.

Flight Level 2: coordenação

Observe como isso é típico no mundo dos negócios. A seguinte imagem mostra uma situação que vejo vez ou outra em empresas maiores (40 a 40.000 funcionários). Várias equipes são necessárias para gerar valor para o cliente.

Na maioria dos casos, o cliente não obtém valor quando o código testado é entregue. O valor é alcançado quando o código é integrado a um sistema maior dentro da empresa. Por outro lado, os clientes raramente especificam seus desejos claramente a ponto de poderem ser imediatamente implementados. Na verdade, é bem o contrário. Como regra, há muito a ser feito antes do trabalho de desenvolvimento real possa ser iniciado. É necessário o engajamento dos líderes, a formação das equipes, entender o que o cliente precisa, contratos devem ser assinados, etc. Assim que examinar as demais áreas do trabalho a ser desenvolvido, você vai perceber que o fluxo de valor é completamente diferente, tais como na manutenção do produto ou no gerenciamento de produtos. No entanto, a idéia por trás destes processos é a mesma: criar valor para o cliente é mais importante do que uma super produtiva.

No nível 2 de operação, a interação das equipes é otimizada. Na metáfora do teclado, no nível 2, asseguramos que a equipe certa esteja empurrando a alavanca certa no tempo certo, ou seja, executando o trabalho certo no tempo certo. Um sistema nível 2 coordena o trabalho de várias equipes, que juntas estão envolvidas no cumprimento dos desejos dos clientes e produzem serviços específicos na cadeia de criação de valor. O objetivo é otimizar o fluxo de trabalho além da borda da equipe. Os sistema de trabalho nível 2 conseguem melhorias de desempenhos massivas por dois motivos:

1 – Os funcionários trabalham nas coisas certas no momento certo porque o fluxo de trabalho é coordenado e vai além dos limites das equipes.

2 – O número de itens de trabalho é limitado, de modo que o sistema de trabalho como um todo pode ser otimizado.

Um vez que o fluxo de trabalho é otimizado ao longo de toda cadeia de valor, o tempo de espera entre uma equipe e outra é reduzido e o que é mais importante: os gargalos se tornam visíveis. Qualquer um que tenha conhecido organizações neste nível só pode achar engraçado quando os times de alta performance descobrem que o segredo para o sucesso é a integração entre eles. Quanto maior a empresa, maior a cadeia de valor. Assim, os quadro de coordenação podem ser estruturados de maneira hierárquica.

Se olharmos para o nível 2 com a perspectiva de gestão de mudanças, as iniciativas neste nível são mais fáceis do que no nível 1, mesmo que você coordena muitas pessoas. A decisão de implementar uma mudança para toda a equipe requer um nível de gerenciamento mais alto. Isso significa que o gerenciamento deve dar um bom exemplo e ser a mudança que eles querem ver. Ao mesmo tempo, não há necessidade imediata de mudar a forma como as equipes individuais trabalham no nível operacional. Se uma equipe usa kanban ou scrum, ou simplesmente faz o trabalho, isto é completamente irrelevante. A única mudança, se você quiser chamar assim, são os líderes das equipes começarem a fazer reuniões de rotina.

Isso é Waterfall?

Quando você olha para isso, você pode achar que a aplicação do nível 2 é do tipo waterfall. O que significa waterfall? Só porque as coisas são trabalhadas de forma sequencial, não significa necessariamente que você está método waterfall (à propósito, Winston Royce descreveu o modelo waterfall como um processo iterativo). No entanto, é um bom modelo – programar o software antes de entregá-lo.

Trabalhar de acordo com os princípios do método waterfall significa que os itens de trabalho são muito grandes, cada item é quase um projeto inteiro. Não é conveniente primeiro analisar um projeto inteiro, desenvolvê-lo e depois implementar.  Este não é o propósito aqui. Em vez disso, os itens de trabalho devem ser pequenos para que você possa o quanto antes definir a abordagem que irá utilizar. Isso requer obter feedback mais rápido e ser capaz de aprender com ele.

Flight Level 3: Gerenciamento Estratégico de Portfólio

Normalmente as organizações não trabalham em apenas um projeto ou produto. O portfólio da empresa é composto com uma variedade de projetos e produtos, bem como iniciativas estratégicas que preparam a organização para o futuro. O nível 3 gerencia exatamente esta mistura. Você precisa obter uma visão geral do que acontece na empresa. Você também quer saber a forma que os os projetos e iniciativas estratégicas estão fazendo efeito, e até que ponto a implementação evoluiu. Um novo projeto pode ser iniciado ou você deve esperar até que um outro projeto seja concluído? Que investimentos devem ser feitos? Um novo mercado deve ser conquistado ou uma parcela de mercado existente deve ser aumentada? Quais iniciativas de mudança estão atualmente em execução na empresa?

Esta última pergunta – o que está sendo executado atualmente em relação aos objetivos da empresa – é especialmente adequada para ser visualizada em um quadro de estratégia. Desta forma, a alta administração pode identificar se as ações estão alinhadas com o propósito da organização e se alguma iniciativa está impedindo outra de se desenvolver. Tais contradições ocorrem principalmente quando as empresas querem se tornar ágeis e há diversos consultores trabalhando internamente com diversas opiniões. Em um dia a auto organização é feita e no dia seguinte um relatório feito de maneira tradicional é solicitado. Neste nível, trata-se do gerenciamento estratégico de toda a organização e não do micro gerenciamento. Grandes empresas com escritórios em todo o mundo tem várias estratégicas devido às exigência de mercados locais.

Ter mais demanda do que capacidade de execução e fundamentalmente um bom problema, caso contrário sua empresa deveria reduzir a força de trabalho. Como resultado disto, vamos ter concorrência no nível de portfólio. Essa disparidade entre as opções aptas a implementação deve ser muito clara, caso contrário, poderá passar uma impressão de que os recursos são limitados. E este não é o caso aqui, na verdade este é o ponto chave do sistema nível 3: fazer escolhas prudentes, combinar projetos, desenvolver produtos e iniciativas estratégicas, reconhecer dependências e otimizar o fluxo através da cadeia de valor e dos recursos atualmente disponíveis.

No nível 3, os tipos de trabalhos a serem tratados são grandes itens, tais como: “entrada no mercado da Hungria”, ou “menos automóvel e mais aviação”. Neste nível, essas vastas funcionalidades competem entre si, de modo que a organização é forçada a tomar uma sólida decisão sobre o que deve ser feito em seguida. O foco não são os objetivos dos projetos individuais, e sim o resultado geral para a organização. A demanda e as possibilidades existentes devem ser equilibradas.

Resumo

O diagrama a seguir consolida os níveis em uma imagem completa:

O nível 3 de voo é o coração estratégico da organização. A gestão estratégica e as iniciativas da empresa convergem aqui. O nível 3 está conectado com os diversos sistemas nos níveis 1 e 2, onde o trabalho operacional é gerenciado. O exemplo “entrada no mercado da Hungria” só pode conter dois tickets, “preparar o grupo de produtos X” e “preparar o grupo de produtos Y”, mas no nível 2, estes itens serão divididos em itens menores e serão então entregues às equipes do nível 1.

Também acontece com frequência o trabalho fluir do nível 3 diretamente para o nível 1. Vamos assumir que nossa empresa é uma fornecedora de peças automotivas e a estratégia presente no nível 3 seja: “mais negócios de aviação”. Já existe na organização um produto sendo desenvolvido para o mercado automobilístico que com uma leve modificação, este produto poderia interessar também para a indústria de aviação. Uma equipe de especialistas de encarrega de testar a teoria. Desta forma o item de trabalho do nível 3 flui diretamente para uma equipe especializada no nível 1.

Os Níveis de Voo não são um modelo de maturidade ou avaliação. O problema de uma equipe não será resolvido com um quadro de estratégia, bem como uma estratégia não pode ser implementada através da iniciativa de uma equipe dispersa. No entanto, vejo processos de pensamento semelhantes com iniciativas ágeis. Existe um problema estratégico sobre a incerteza futura do mercado. Embora não saibamos que o futuro nos trará, as equipes estão se tornando ágeis como precaução. A agilidade é um tópico estratégico e não pode ser resolvido no nível operacional, especialmente onde as áreas não achem necessário. Se você quer fazer melhorias em uma organização, primeiro você deve deixar claro qual o nível necessário para que a mudança possa ocorrer. Os níveis de voo devem ajudar a identificar o nível necessário. Geralmente, podemos dizer que quanto mais alvo o nível de voo, maior é o efeito da alavanca. Se houve possibilidade de iniciar o processo no nível 3, você deve começar. A única equipe ágil que é necessária para a organização se tornar ágil é a equipe ágil que está no topo, é a que realiza o gerenciamento estratégico do portfólio, e é está equipe que deve dar o exemplo.

Traduzido do original: https://www.leanability.com/en/blog-en/2017/04/flight-levels-the-organizational-improvement-levels/
Tradução: Rodrigo Zambon

Apresentação feita em novembro de 2013, ainda com 4 níveis de voo!