5장: 프로세스 설계 방법론 - 기계의 노예가 되거나 부패를 일으킴
문서개요
1. 프로세스의 성격
2. 프로세스의 요소
1. 구동력 모드
2. 업무 및 현황
3. 노드
(1) 검증 메커니즘
(2) 거부 메커니즘
4. 감독 메커니즘
3. 프로세스 설계 패턴
1. 지위지향적(누구나 할 수 있고, 일에 집중함)
시간2. 노드 중심(누구나 할 수는 없음, 사람 중심)
3. 국가 중심이냐, 노드 중심이냐, 이것이 문제로다.
4. 프로세스 모델
1. 화살표 모델
2. 스택 모델
(1) 스택 모델에는 두 가지 유형이 있습니다.
(2) 피드백 메커니즘
3. 풀 모델
4. 모델의 혼합 사용
5. 다층 공정 설계
1. 단일 작업, 다층 상태
2. 단일 주 작업, 여러 하위 작업
3. 다층 공정 설계의 두 가지 방법 모두 고유한 장점과 단점이 있습니다.
지난 몇 년 동안 저는 중국의 선도적인 인터넷 회사에서 근무했습니다. 당시 회사는 업무 협업을 위해 작업 주문 시스템을 사용했습니다. 그 당시에는 지금과 달리 선택할 수 있는 협업 도구가 많았습니다. 그래서 작업 주문 시스템을주의 깊게 연구했습니다.
그때부터 프로세스 설계와 관리에 집중하기 시작했습니다.
그 후 몇 년 동안 저는 많은 프로세스 제품과 심지어 프로세스 엔진까지 만들었습니다.
지난 몇 년 동안 나는 이러한 프로세스 기반 제품을 구체적으로 검토했으며 마침내 나만의 프로세스 설계 방법론 세트를 개발했습니다.
많은 방법론만큼 추상적이지는 않을 수 있지만 단순하고 실용적인 것보다는 낫습니다. 적어도 대부분의 프로세스 설계에서는 기본적으로 즉시 사용할 수 있습니다.
1. 프로세스의 성격
프로세스의 본질은 사물의 상태를 정렬하는 것입니다.
특정 표준에 따르면 무엇이든 일련의 상태로 표시될 수 있습니다. 이러한 상태의 순서는 프로세스를 형성합니다.
2. 프로세스의 요소
1. 구동력 모드
패시브 모드와 액티브 모드.
모든 프로세스의 작동에는 고유한 원동력이 있습니다.
패시브 모드의 원동력은 이전 프로세스 노드에서 나옵니다. 즉, 이전 노드가 다음 노드를 구동합니다. (간단한 이해: 이전 Executor에서 다음 Executor로 작업이 전달되고, 다음 Executor가 수동적으로 실행합니다.)
활성 모드의 구동력은 프로세스 노드 자체에서 나오거나 이를 자율 주행이라고 합니다.
다양한 추진력 모델은 프로세스 설계 중에 프로세스 모델을 선택하는 방법을 결정합니다.
프로세스 설계는 전체 프로세스의 추진력 모델을 고려해야 합니다. 그렇지 않으면 당신이 디자인한 프로세스가 "사용 불가능", "불합리", "너무 귀찮은" 일이 될 가능성이 높습니다. . . . . .
동일한 프로세스 내에서 활성 모드와 수동 모드를 혼합할 수 있습니다. 주로 특정 업무와 시나리오에 따라 다릅니다.
2. 업무 및 현황
프로세스의 흐름에는 전체 프로세스를 조정하기 위한 상태 저장이 필요합니다. 이것이 바로 작업입니다. 작업 상태의 순차적인 변화가 프로세스를 형성합니다.
작업은 문서, 티켓, 주문, 작업 주문, 카드 등이 될 수 있습니다.
프로세스에는 하나의 작업만 있을 수 있습니다. 또는 프로세스에서 실행하기 위해 여러 하위 작업으로 분할될 수 있는 하나의 기본 작업만 있을 수도 있습니다.
3. 노드
노드는 실행자입니다.
즉, 각 작업 상태의 특정 실행자입니다. 사람, 프로그램, 기계 등이 될 수 있습니다.
노드는 하나의 상태만 실행할 수도 있고 여러 상태를 실행할 수도 있습니다. 이는 주로 프로세스의 디자인 패턴에 따라 달라집니다(자세한 내용은 나중에 "3. 프로세스 디자인 패턴" 참조).
각 노드에 대해 상태의 전환이 반드시 노드의 전환을 수반하는 것은 아니지만, 노드의 전환은 반드시 상태의 전환을 수반하게 됩니다. 이는 프로세스 설계 원칙으로 간주됩니다.
각 노드 전환에는 해당 검증 메커니즘과 사용할 수 있는 거부 메커니즘이 필요합니다.
(1) 검증 메커니즘
노드가 변경될 때마다 검증이 수행됩니다.
- 사전 검증:
노드를 전환하기 전에 현재 노드의 실행 결과를 검증하는 경우도 있는데, 검증에 성공하면 다음 노드로 전환합니다.
- 사후 검증:
노드 전환 후 이전 노드의 실행 결과를 검증하고, 검증을 통과하지 못하면 거부 메커니즘이 실행됩니다.
(2) 거부 메커니즘
프로세스의 검증 메커니즘이 사후 검증인 경우 거부 메커니즘이 있어야 합니다. 거부 메커니즘은 이전 노드가 제출한 작업이 부적합한지 확인하고 이를 이전 노드로 반환하는 메커니즘입니다. 프로세스를 설계할 때 구체적인 검증 기준, 사양, 반품 방법, 거부 처리 방법 등을 모두 고려해야 합니다.
4. 감독 메커니즘
모든 프로세스에는 모니터링 메커니즘이 있어야 합니다. 규제 메커니즘에는 두 가지 주요 유형이 있습니다.
- 기록 관리 감독
가장 간단하고 기본적인 감독 메커니즘은 태스크의 실행 과정, 즉 태스크 상태의 변화와 각 상태의 속성 및 실행 결과를 기록하는 것이다. 문제가 발생하면 원인을 추적할 수 있습니다.
- 실시간 감독
프로세스의 각 상태 실행을 실시간으로 감독하고, 위반 사항이 발견되면 즉시 개입합니다.
3. 프로세스 설계 패턴
1. 지위지향적(누구나 할 수 있고, 일에 집중함)
이는 비교적 흔한 일입니다. 상태에는 무겁고 노드에는 가볍습니다. 우리가 보고 행하는 대부분의 프로세스가 바로 그러한 디자인 패턴이다.
먼저 뭔가를 한 다음 특정 상태를 얻고, 다시 뭔가를 한 다음 특정 상태를 얻고, 이미지 인식을 사용하여 특정 상태를 얻은 다음 다시 무언가를 수행하고 특정 상태를 얻습니다. . . . . .
프로세스의 모든 노드(사람, 프로그램, 기계 등)는 하나의 기계화된 단계를 중심으로 회전하며 정해진 규칙에 따라 자신이 담당하는 작업을 수행합니다.
"조립라인"이라고 생각하시면 됩니다.
2. 노드 중심(누구나 할 수는 없음, 사람 중심)
이것은 상대적으로 드뭅니다. 상태에서는 가볍고 노드에서는 무겁습니다.
누구에게 먼저 작업을 맡길 수 있는지, 어떤 결과를 얻을 수 있는지, 그 다음에는 누구에게, 어떤 결과를 얻을 수 있는지, 그런 다음 어떤 기계에 작업을 맡길 수 있는지, 어떤 결과를 얻을 수 있는지, 그다음에는 누구에게 어떤 결과를 얻을 수 있는지 얻어 질 수있는. . . . . . .
일반적으로 말해서, 노드 출력 결과가 크게 달라지는 일부 비표준 상황이나 일부 느슨한 조직 및 프로세스에서만 사용이 고려됩니다.
인터넷 상품 중 드물다. 현재 일부 협업 사무용품에 주로 사용됩니다.
3. 국가 중심이냐, 노드 중심이냐, 이것이 문제로다.
아마도 신이 존재하는 이유는 이 세상이 불완전하기 때문일 것입니다.
상태 지향이든 노드 지향이든 프로세스 설계는 절대적으로 완벽한 프로세스를 설계할 수 없습니다.
궁극적인 상태에 직면하면 인간은 결국 프로그램과 기계의 노예가 될 것입니다.
노드 중심은 권력 집중과 부패로 이어질 수 있습니다.
따라서 결국 프로세스에서 어떤 디자인 패턴을 사용해야 하는지는 구체적인 비즈니스 시나리오에 따라 다릅니다. 적합한 것이 가장 좋습니다.