Как моделировать человека, машину, меры и процессы в мире DevOps?

17

В проекте «Феникс» во время одного из туров по заводу нам сообщили, что каждая рабочая станция представляет собой сочетание человека, машины, измерения и процесса. Это имеет большой смысл, ведь у нас есть люди, серверы, KPI и инструкции.

Однако всякий раз, когда я моделирую процесс (например, жизненный цикл поддержки), я стараюсь принять это во внимание.

Мои рабочие процессы обычно включают в себя:

  • Помощь первой линии
  • Tech / Dev / More Техническая поддержка команды
  • Обзор кода
  • тестирование
  • UAT
  • развертывание

Я могу довольно легко измерить типы циклов, пропускную способность и время очередей каждого из этих состояний, но я не чувствую, что это соответствует концепции «человек, машина, метод». Это идея, которая разочарованно намекается в книге, но не раскрывается ...

Мы знаем, что время ожидания является функцией использования, поэтому крайне важно отслеживать, насколько заняты люди и серверы (ограниченные ресурсы). Есть ли определенный процесс для расширения моих измерений от простого конечного автомата до идеи Человек, машина, метод, процесс в книге?

Liath
источник

Ответы:

6

То, о чем они говорят, это Кайдзен (Человек, Машина, Материал, Метод, Измерение). Это подход к непрерывному улучшению на каждой станции в процессе, и Ms являются возможными точками улучшения и к которым есть соответствующий вопрос (5Q). Иногда среда добавляется для 6-го, как в этом процессе, который объясняет, как построить вопросы, используя диаграмму Исикавы . Это в значительной степени основы TPS / Lean Manufacturing . Но улучшения не в использовании, а в улучшении качества. Вы никогда не стремитесь к использованию, так как это негативно влияет на пропускную способность системы .

Важно понимать, что человек, машина, материал, метод и измерение нелегко разделить. Иногда Машина, Материал и Измерение сходятся на одной стороне, а Человек и Метод - на другой. Как вы можете заменить человека и метод на этой рабочей станции.

С точки зрения разработки программного обеспечения у вас есть Программное обеспечение (Машина), Проблемы (Материал), Качество Код / Принятие (Измерение), Человек (Программист) и Метод (Процесс разработки). Человек тренируется на машине и знакомится с ней, с материалом, над которым работает, понимает необходимые измерения, изучает процесс. Все они живут в мозгу человека и поэтому их нелегко разлучить, когда их изучат. Изменение Метода возможно только в том случае, если Человек еще не полностью усвоил его, иначе легче изменить Человека и Метод. Кроме того, машины, материалы и измерения часто связаны друг с другом посредством автоматизации и конфигурации. Вот почему они рисуются на противоположных сторонах диаграммы.

Если вы внимательно прочитаете книгу, то в действительности речь не идет об использовании, кроме узкого места цепочки создания стоимости. Чтобы поднять и использовать узкое место. Для этого в книге используется несколько методов, включая Канбан .

Вы не хотите оптимизировать отдельные станции вашего процесса (Customer-> Support-> Development-> Review-> Testing-> User Acceptance-> Deployment-> Customer), но вам нужно смоделировать переходы между этими рабочими станциями , их зависимости и для мониторинга работы в процессе (WIP), проходящих через систему. Обычно с помощью программного обеспечения для отслеживания проблем (или системы Kanban), которое эквивалентно отслеживанию материалов на производстве. Там, где WIP накапливается перед рабочей станцией в процессе критической цепочки, вы найдете узкое место, и именно здесь вы хотите оптимизировать использование Kaizan (5Ms, 5Qs).

Примечание: я добавил Клиента как в начале, так и в конце вашего процесса, поскольку каждая цепочка создания стоимости должна начинаться и заканчиваться Клиентом, иначе это не представляет ценности для компании.

Иржи Клауда
источник