Como modelar homem, máquina, medidas e processos em um mundo DevOps?

17

No The Phoenix Project, quando em um dos passeios pela fábrica, somos informados de que cada estação de trabalho é uma combinação de Pessoa, Máquina, Medição e Processo. Isso faz muito sentido, afinal temos pessoas, servidores, KPIs e instruções.

No entanto, sempre que modelo um processo (o ciclo de vida de um tíquete de suporte, por exemplo), luto para levar isso em consideração.

Meus estados de fluxo de trabalho geralmente incluem:

  • Assistência de Primeira Linha
  • Tech / Dev / Mais assistência da equipe técnica
  • Revisão de código
  • Teste
  • UAT
  • Desdobramento, desenvolvimento

Posso medir com facilidade os tipos de ciclos, taxas de transferência e tempos de fila de cada um desses estados, mas não acho que isso faça justiça ao conceito Homem, Máquina, Método. É uma idéia que é frustrantemente sugerida no livro, mas não expandida em ...

Sabemos que o tempo de espera é uma função da utilização, por isso é fundamental monitorar o nível de ocupação das pessoas e servidores (os recursos finitos). Existe algum processo definido para expandir minhas medições de uma simples máquina de estados finitos para a idéia Homem, Máquina, Método, Processo no livro?

Liath
fonte

Respostas:

5

O que eles estão falando é o Kaizen 5M (Homem, Máquina, Material, Método, Medição). É uma abordagem para a melhoria contínua em todas as estações do processo e as Ms são possíveis pontos de melhoria e para as quais existe uma pergunta correspondente (5Qs). Às vezes, o ambiente é adicionado ao 6º, como neste processo que explica como construir as perguntas usando o diagrama de Ishikawa . Estes são basicamente os fundamentos do TPS / Lean Manufacturing . Mas as melhorias não estão em uso, são melhorias na qualidade. Você nunca se esforça para utilizar, pois isso é contraproducente para a taxa de transferência do sistema .

É importante entender que Homem, Máquina, Material, Método e Medição não são facilmente separados. Às vezes, Máquina, Material e Medição se juntam de um lado e Homem e Método do outro lado. Como você pode substituir um homem e um método nessa estação de trabalho.

Em termos de desenvolvimento de software, você possui Software (Máquina), Problemas (Material), Código Qualidade / Aceitação (Medição), Homem (Programador) e Método (Processo de Desenvolvimento). O homem treina na máquina e se familiariza com ela, com o material que está sendo trabalhado, entende a medição necessária e aprende o processo. Todos aqueles que vivem no cérebro do homem e, portanto, não são facilmente separados depois de aprendidos. Mudar um método só é possível se o Homem ainda não o internalizou completamente, caso contrário fica mais fácil mudar o Homem e o Método. Além disso, Máquina, Material e Medição são frequentemente interligados por meio de automação e configuração. É por isso que eles estão sendo desenhados em lados opostos do diagrama.

Se você ler o livro com atenção, ele não fala sobre utilização, a não ser no gargalo de uma cadeia de valor. Para elevar e explorar o gargalo. Vários métodos são empregados para isso no livro, incluindo o Kanban .

Você não deseja otimizar as estações individuais do seu processo (Cliente-> Suporte-> Desenvolvimento-> Revisão-> Teste-> Aceitação do usuário-> Implantação-> Cliente), mas precisa modelar as transições entre essas estações de trabalho , suas dependências e para monitorar o trabalho em processo (WIP) em movimento no sistema. Geralmente, por meio de um software de rastreamento de problemas (ou sistema Kanban), que é equivalente ao rastreamento de materiais na fabricação. Onde o WIP se acumula na frente da estação de trabalho em seu processo crítico da cadeia, você encontra seu gargalo e esse é o local onde você deseja otimizar usando o Kaizan (5Ms, 5Qs)

Aviso: Adicionei o Cliente no início e no final do seu processo, pois cada cadeia de valor precisa começar e terminar com um Cliente, caso contrário, não representa valor para a empresa.

Jiri Klouda
fonte