Wie modelliere ich Mensch, Maschine, Maßnahmen und Prozesse in einer DevOps-Welt?

16

Im Phoenix-Projekt erfahren wir auf einer Werksbesichtigung, dass jeder Arbeitsplatz eine Kombination aus Person, Maschine, Messung und Prozess ist. Das macht sehr viel Sinn, schließlich haben wir Leute, Server, KPIs und Anweisungen.

Wenn ich jedoch einen Prozess modelliere (z. B. den Lebenszyklus eines Support-Tickets), kann ich dies nur schwer berücksichtigen.

Zu meinen Workflow-Zuständen gehören normalerweise:

  • Erste Hilfe
  • Tech / Dev / More Technische Teamunterstützung
  • Code-Review
  • Testen
  • UAT
  • Einsatz

Ich kann die Zyklustypen, Durchsätze und Wartezeiten jedes dieser Zustände ziemlich leicht messen, aber ich glaube nicht, dass dies dem Konzept Mensch, Maschine, Methode gerecht wird. Es ist eine Idee, die im Buch frustrierend angedeutet, aber nicht erweitert wird ...

Wir wissen, dass die Wartezeit eine Funktion der Auslastung ist. Daher ist es wichtig zu überwachen, wie beschäftigt Personen und Server (die begrenzten Ressourcen) sind. Gibt es einen definierten Prozess für die Erweiterung meiner Messungen von einer einfachen Finite-State-Maschine auf die Idee Mensch, Maschine, Methode, Prozess im Buch?

Liath
quelle

Antworten:

5

Worüber sie sprechen, ist Kaizen 5M (Mensch, Maschine, Material, Methode, Messung). Es ist Ansatz zur kontinuierlichen Verbesserung an jeder Station im Prozess und die Ms sind mögliche Verbesserungspunkte und zu denen gibt es eine entsprechende Frage (5Qs). Manchmal wird Environment für 6 hinzugefügt, wie in diesem Prozess, in dem erklärt wird, wie die Fragen mithilfe des Ishikawa-Diagramms erstellt werden . Dies sind so ziemlich alle Grundvoraussetzungen für TPS / Lean Manufacturing . Die Verbesserungen werden jedoch nicht genutzt, sondern sind Qualitätsverbesserungen. Sie streben niemals nach einer Nutzung, da dies dem Durchsatz des Systems entgegenwirkt .

Es ist wichtig zu verstehen, dass sich Mensch, Maschine, Material, Methode und Messung nicht leicht trennen lassen. Manchmal kommen Maschine, Material und Maß auf der einen Seite zusammen und Mensch und Methode auf der anderen Seite. Wie Sie einen Mann und eine Methode auf dieser Arbeitsstation ersetzen können.

In Bezug auf die Softwareentwicklung verfügen Sie über Software (Maschine), Probleme (Material), Codequalität / -akzeptanz (Messung), Mensch (Programmierer) und Methode (Entwicklungsprozess). Der Mann trainiert an der Maschine und macht sich mit dem zu bearbeitenden Material vertraut, versteht die erforderliche Messung, lernt den Prozess. Alle, die im Gehirn des Mannes leben, sind nicht leicht zu trennen, wenn sie erst einmal gelernt haben. Das Ändern einer Methode ist nur möglich, wenn der Benutzer sie noch nicht vollständig verinnerlicht hat. Andernfalls wird es einfacher, den Benutzer und die Methode zu ändern. Auch Maschine, Material und Messung sind oft durch Automatisierung und Konfiguration miteinander verbunden. Deshalb werden diese auf entgegengesetzten Seiten des Diagramms gezeichnet.

Wenn Sie das Buch sorgfältig lesen, spricht es nur über den Engpass einer Wertschöpfungskette. Um den Engpass zu heben und auszunutzen. In diesem Buch werden verschiedene Methoden angewendet, einschließlich Kanban .

Sie möchten nicht die einzelnen Stationen Ihres Prozesses optimieren (Kunden-> Support-> Entwicklung-> Überprüfung-> Testen-> Benutzerakzeptanz-> Bereitstellung-> Kunde), sondern müssen die Übergänge zwischen diesen Arbeitsstationen modellieren , ihre Abhängigkeiten und zum Überwachen von In Arbeit (WIP), die sich durch das System bewegen. In der Regel über eine Issue-Tracking-Software (oder ein Kanban-System), die der Materialverfolgung in der Fertigung entspricht. Dort, wo sich der WIP in Ihrem Prozess der kritischen Kette vor dem Arbeitsplatz stapelt, finden Sie Ihren Engpass und an dieser Stelle möchten Sie mit Kaizan optimieren (5Ms, 5Qs).

Hinweis: Ich habe den Kunden sowohl zu Beginn als auch am Ende Ihres Prozesses hinzugefügt, da jede Wertschöpfungskette mit einem Kunden beginnen und enden muss, da sie sonst keinen Wert für das Unternehmen darstellt.

Jiri Klouda
quelle