↻ 프로세스당 한 사이클입니다. 병목은 이동하므로 그다음에는 다시 F부터 시작합니다.
Flowrefy 방법: 여덟 단계, 두 부분
브랜드명은 약어입니다. F, L, O, W는 측정합니다 — 이 절반에서는 무엇도 변경하지 않고 수치화합니다. R, E, F, Y는 세밀화합니다 — 여기서는 개입하며 측정이 지정한 것만 건드립니다. 이쪽은 순서를 설명합니다. 각 단계 아래에 절차, 인수 기준 및 그 단계에서 전형적으로 발생하는 오류를 담은 별도 페이지가 있습니다.
순서가 임의가 아닌 이유
실무에서 가장 흔한 순서는 반대입니다: 도구를 먼저 구매한 다음 그에 맞는 프로세스를 찾습니다. 결과는 누가 보기에도 이 작업이 이전에 비용이 많이 들었는지 알 수 없는 자동화된 흐름이며 따라서 나중에 더 저렴해졌는지도 알 수 없습니다.
FLOW의 네 단계는 바로 이 누락된 수치를 만들어냅니다. F는 후보를 모으고, L은 그것들을 금전으로 환산하고, O는 부하가 걸렸을 때 실제로 막히는 단계를 찾고, W는 개입의 비용 대비 효과를 계산합니다. 그제야 무언가를 해야 할지 여부가 결정됩니다. 이 시점에서 "아무것도 하지 않음"은 허용되는, 때때로 올바른 결과입니다.
REFY의 네 단계도 비용 순으로 정렬됩니다: R은 불필요한 부분을 제거하며 라이선스 비용이 들지 않습니다. E는 책임을 명확히 하며 역시 비용이 들지 않습니다. 기술을 다루는 것은 비로소 F입니다 — 정확히 하나의 기술적 지렛대를 건드려야 합니다, 그렇지 않으면 Y에서 어떤 조치가 효과를 낳았는지 구분할 수 없습니다. Y는 L이 측정한 동일한 계산으로 재측정하고 병목이 어디로 이동했는지 명명합니다.
그다음 다시 F에서 시작합니다. 수식이 아니라, 해결된 병목은 항상 새로운 병목을 드러내기 때문입니다: 개입 후 두 번째로 느린 단계가 가장 느린 단계가 됩니다. 프로세스당 한 사이클 실행 후 재평가합니다.
여덟 단계
먼저 측정합니다
숫자가 테이블에 놓이기까지 네 단계입니다. 여기서는 아무것도 변경하지 않습니다. 여기서는 이해합니다.
Find — 후보 찾기
- 질문
- 어떤 프로세스가 실제로 고려 대상에 해당합니까?
- 결과
- 유발 조건, 결과 및 연간 대략적 건수와 함께 다섯에서 열다섯 개의 프로세스 목록. 순서 없음, 평가 없음.
Lay bare — 현재 상태를 수치화합니다
- 질문
- 각 후보는 현재 연간 얼마의 비용이 드나요?
- 결과
- 후보별로 전체 비용으로 계산한 연간 유로 비용 범위가 하나씩 있고, 한 페이지에 추적 가능하게 계산되어야 합니다. F의 목록은 이렇게 정렬할 수 있습니다.
Observe — 스트레스 테스트에서 진짜 병목을 찾아내기
- 질문
- 빡빡해질 때 실제로 어떤 단계가 막히겠습니까?
- 결과
- 각 단계에 대한 병목 확률, 프로세스에 대한 처리시간 분포(P10, P50, P90)와 각 역할의 활용률을 구합니다. 정확히 한 단계가 병목으로 지정됩니다.
Weigh — 개입이 가치가 있는지 저울질하다
- 질문
- 그 개입이 가치가 있습니까 — 그리고 언제부터입니까?
- 결과
- 근거 있는 결정: 어떤 레버인지, 비용은 얼마인지, 얼마나 절약되는지, 언제부터 자체적으로 비용을 상쇄하는지. 또는 어떤 것도 비용을 상쇄하지 못한다는 판단입니다.
그다음 정교화합니다
개선이 입증되기까지 네 단계입니다. 바로 이 단계에서만 손을 대며 측정이 지목한 것만 다룹니다.
Reduce — 불필요 요소를 제거합니다
- 질문
- 무엇을 제거할 수 있을까요? 어떤 것을 만들기 전에 무엇을 없앨 수 있습니까?
- 결과
- 단계가 더 적고 시스템 전환이 적으며 대기열이 적은 프로세스 — 라이선스를 구매하지 않고도 가능합니다.
Enable — 역할을 명확히 하십시오
- 질문
- 누가 결정하고, 누가 실행하며, 누가 단지 통보만 받습니까?
- 결과
- 남아 있는 각 단계마다 정확히 하나의 책임 역할, 명시된 대리자와 결정 한계가 있어야 합니다.
Fit — 정확히 한 개의 레버, 깔끔하게 연결됨
- 질문
- 어떤 하나의 기술적 레버를 만들고, 어떻게 연결합니까?
- 결과
- 정확히 한 곳에 구현된 개입으로, 이미 운영 중인 시스템들과 연결되며, 장애 시의 동작이 문서화되어 있습니다.
Yield — 수익을 입증하세요
- 질문
- 개입이 무엇을 가져왔고 이제 병목이 어디에 있습니까?
- 결과
- L과 O와 동일한 계산으로 얻은 전후의 유로와 처리시간, W의 추정과의 편차, 그리고 명명된 새 병목입니다.
방법이 하지 못하는 것
- 01이 방법은 프로세스에 대한 전문 지식을 대체하지 않습니다. 수치는 그 프로세스를 수행하는 사람들과의 대화에서 나옵니다; 대화가 부실하면 측정도 부실합니다.
- 02이 방법은 단일 값(point estimate)을 제공하지 않습니다. 모든 결과는 범위입니다. 결정을 내리기 위해 소수점 둘째 자리까지의 숫자가 필요하다면, 그 결정은 어차피 직감에 따르는 것입니다.
- 03이 방법은 비용을 유로로 환산할 수 없는 프로세스에 대해 아무 말도 하지 않습니다. 평판, 법적 확실성 또는 주의가 수반되는 단계는 여기서 평가하지 않습니다 — 그것들은 그냥 유지됩니다.
- 04이 방법은 성숙도 모델도 인증서도 아닙니다. 한 사이클의 끝에는 단계와 표장이 아니라 이전/이후 계산이 붙은 변경된 프로세스가 있습니다.
절차에 대한 자주 묻는 질문
다음 순서로 진행합니다: 후보자를 수집하기(F), 각 후보자를 연간 유로로 금액화하기(L), 가장 비용이 큰 후보자를 부하 상태로 시뮬레이션하여 실제로 병목을 만드는 단계를 찾기(O), 그리고 개입이 비용을 정당화하는지 계산하기(W). 그다음에야 변경합니다: 불필요한 절차 제거(R), 책임 범위 명확화(E), 정확히 하나의 기술적 지렛대 구축(F), 동일한 계산으로 재측정하기(Y). 처음 네 단계는 아무것도 변경하지 않습니다 — 이후에 측정할 기준이 되는 수치를 생성합니다.
일반적인 세 단계인 분석, 구현, 검증은 실패가 발생하는 지점을 하나로 묶어 버리기 때문입니다. 분석과 구현 사이에는 두 번의 별도 결정이 있습니다: 어느 단계가 병목인가(O)와 개입이 비용을 정당화하는가(W). 결정과 기술 사이에는 비용이 들지 않으면서 기술보다 더 큰 효과를 내는 두 단계가 있습니다: 정리(R)와 책임 범위 명확화(E). 이를 '구현'으로 묶어 버리면 실제로 이 단계를 건너뛰게 됩니다.
프로세스가 너무 작아 병목이 명백한 경우에는 O를 생략할 수 있습니다 — 다만 그 가정은 Y에서 검증해야 합니다. R과 E는 생략할 수 없습니다: 비용이 들지 않으며 F에서 만든 지렛대가 정돈된 프로세스에 적용되는지, 아니면 얽혀 있는 프로세스에 적용되는지를 결정합니다. L을 건너뛰면 Y에서 비교 기준이 없어져서 개입이 효과가 있었는지 결코 알 수 없습니다.
이것은 방법이 아니라 그 프로세스를 수행하는 사람들의 가용성에 달려 있습니다. FLOW는 측정과 계산이며 대화가 성사되면 신속하게 진행할 수 있습니다. REFY는 실행에 달려 있습니다: R과 E는 결정이고 F는 구축이며 Y는 새 상태가 충분히 오랫동안 운영되어 일상이 되었을 때를 전제로 합니다 — 그 전에는 전환을 측정할 뿐 프로세스를 측정하지 않습니다.
FLOW는 아무것도 변경하지 않습니다. 수집하고, 금전화하고, 시뮬레이션하고, 계산합니다 — 끝에는 수치와 결정이 있습니다. REFY는 변경하고 입증합니다: 비용이 들지 않는 것들(불필요한 요소, 책임 소재)을 먼저 처리한 다음 정확히 하나의 기술적 지렛대를 건드리고 나서 재측정합니다. 분리는 이 방법의 핵심입니다: 둘을 한꺼번에 하면 비용을 알기 전에 무언가를 변경하게 됩니다.
귀사의 프로세스가 얼마 드는지 알고 싶으시면: 측정하십시오.
무료 진단으로 시작하거나 FlowVisual을 다운로드하세요. 이후에 누군가와 이야기하고 싶다면 저희에게 연락해 주십시오.
원격 · 고정가 · 결과를 유로로 제공됩니다