Comment modéliser l'homme, la machine, les mesures et les processus dans un monde DevOps?

17

Dans The Phoenix Project, lors d'une des visites de l'usine, on nous dit que chaque poste de travail est une combinaison de personne, de machine, de mesure et de processus. Cela a beaucoup de sens, après tout, nous avons des personnes, des serveurs, des KPI et des instructions.

Cependant, chaque fois que je modélise un processus (le cycle de vie d'un ticket d'assistance par exemple), j'ai du mal à en tenir compte.

Mes états de workflow incluent généralement:

  • Assistance de première ligne
  • Assistance technique / développement / assistance technique supplémentaire
  • Examen du code
  • Essai
  • UAT
  • Déploiement

Je peux assez facilement mesurer les types de cycle, les débits et les temps de file d'attente de chacun de ces états, mais je ne pense pas que cela rende justice au concept Man, Machine, Method. C'est une idée qui est évoquée de manière frustrante dans le livre mais qui n'est pas développée ...

Nous savons que le temps d'attente est fonction de l'utilisation, il est donc essentiel de surveiller à quel point les personnes et les serveurs sont occupés (les ressources limitées). Existe-t-il un processus défini pour étendre mes mesures d'une simple machine à états finis à l'idée Man, Machine, Method, Process dans le livre?

Liath
la source

Réponses:

6

Ce dont ils parlent est Kaizen 5M (homme, machine, matériau, méthode, mesure). C'est une approche d'amélioration continue à chaque station du processus et les Ms sont des points d'amélioration possibles et auxquels il y a une question correspondante (5Q). Parfois, l'Environnement est ajouté pour la 6e, comme dans ce processus qui explique comment construire les questions en utilisant le diagramme d'Ishikawa . Ce sont à peu près les éléments essentiels du TPS / Lean Manufacturing . Mais les améliorations ne concernent pas l'utilisation, ce sont des améliorations de la qualité. Vous ne vous efforcez jamais d'utiliser car cela est contre-productif pour le débit du système .

Il est important de comprendre que l'homme, la machine, le matériau, la méthode et la mesure ne sont pas facilement séparés. Parfois, la machine, le matériel et la mesure se rejoignent d'un côté et l'homme et la méthode de l'autre. Comme vous pouvez remplacer un homme et une méthode sur ce poste de travail.

En termes de développement logiciel, vous avez le logiciel (machine), les problèmes (matériel), la qualité / acceptation du code (mesure), l'homme (programmeur) et la méthode (processus de développement). L'homme s'entraîne sur la machine et se familiarise avec celle-ci, avec le matériau à travailler, comprend la mesure requise, apprend le processus. Tous ceux qui vivent dans le cerveau de l'homme et ne sont donc pas facilement séparés une fois appris. Changer une méthode n'est possible que si l'homme ne l'a pas encore complètement internalisée, sinon il devient plus facile de changer l'homme et la méthode. La machine, le matériau et la mesure sont également souvent liés par l'automatisation et la configuration. C'est pourquoi ceux-ci sont dessinés sur les côtés opposés du diagramme.

Si vous lisez attentivement le livre, il ne parle pas vraiment d'utilisation autrement que dans le goulot d'étranglement d'une chaîne de valeur. Afin d'élever et d'exploiter le goulot d'étranglement. Plusieurs méthodes sont utilisées pour cela dans le livre, y compris Kanban .

Vous ne voulez pas optimiser les stations individuelles de votre processus (Client-> Support-> Développement-> Révision-> Test-> Acceptation utilisateur-> Déploiement-> Client), mais vous devez modéliser les transitions entre ces postes de travail , leurs dépendances et pour surveiller les travaux en cours (WIP) se déplaçant dans le système. Généralement via un logiciel de suivi des problèmes (ou système Kanban), qui équivaut au suivi des matériaux dans la fabrication. Là où le WIP s'accumule devant le poste de travail dans votre processus de chaîne critique, vous trouverez votre goulot d'étranglement et c'est l'endroit où vous souhaitez optimiser en utilisant Kaizan (5Ms, 5Qs)

Remarque: J'ai ajouté le client au début et à la fin de votre processus, car chaque chaîne de valeur doit commencer et se terminer avec un client, sinon elle ne représente pas de valeur pour l'entreprise.

Jiri Klouda
la source