단계 3 / 8단계

FLOW · 먼저 측정합니다

Observe — 스트레스 테스트에서 진짜 병목을 찾아내기

O는 이 방법을 단순 비용 계산과 구별하는 단계입니다. L에서는 합산했지만 여기서는 부하가 걸린 상태에서 프로세스를 관찰합니다. 이 차이는 학문적 문제가 아닙니다: 평균 처리시간이 여유 있게 가용 용량에 들어맞는 프로세스도 80~90퍼센트 활용률에서는 규칙적으로 정지합니다. 대기열은 선형으로 증가하지 않습니다.

이 단계의 산출물은 흔히 정정입니다. 가장 크게 불평받는 단계가 처리시간을 제한하는 단계인 경우는 드뭅니다 — 그것은 가장 눈에 띄게 고통을 주는 단계입니다. 둘이 일치하면 모델에 대한 좋은 신호입니다; 둘이 어긋나면 바로 그 차이가 시뮬레이션을 하는 이유입니다.

질문에 답합니다
빡빡해질 때 실제로 어떤 단계가 막히겠습니까?
단계의 결과
각 단계에 대한 병목 확률, 프로세스에 대한 처리시간 분포(P10, P50, P90)와 각 역할의 활용률을 구합니다. 정확히 한 단계가 병목으로 지정됩니다.

단계 수행 방법

  1. L에서 모델을 가져오기

    같은 단계, 같은 기간, 같은 시간당 요율. 새로 만든 모델은 Y에서 전후 비교 계산을 불가능하게 합니다. 그 이유는 두 가지가 바뀌었기 때문입니다: 프로세스와 측정 방식입니다.

  2. 역할별 처리용량 입력하기

    이 역할이 프로세스에 실제로 얼마나 많은 시간을 제공하는지 — 그 역할이 얼마나 많이 일하는지가 아닙니다. 이 값으로 나중에 사람이 한계인지 시스템이 한계인지가 드러납니다. 두 경우는 완전히 다른 개입을 요구합니다.

  3. 프로세스를 수백 번 실행시키세요

    Monte Carlo: 각 실행에서 각 단계의 범위에서 기간을 하나씩 뽑습니다. 수백 번의 실행 후에는 단일 결과가 아니라 분포가 나타납니다 — 그 분포가 실제 결과입니다.

  4. 병목이 있는 곳을 세세요

    각 실행마다 어떤 단계가 그 실행을 제한했는지 기록합니다. 이 비율이 그 단계의 병목 확률입니다. 70퍼센트인 단계는 병목입니다; 세 단계가 각각 30퍼센트라면 모델이 너무 거칠다는 의미입니다.

  5. 예상과 대조해 검증하기

    참여자들에게 사전에 어떤 단계를 병목으로 생각하는지 묻습니다. 시뮬레이션이 동의하면 모델이 확인됩니다. 시뮬레이션이 반대하면 계속 계산하기 전에 그 차이를 설명합니다 — 아무도 설명할 수 없는 불일치는 모델 오류이지 발견이 아닙니다.

완료 기준

  • 한 단계가 다른 모든 단계보다 명백히 높은 병목 확률을 갖습니다.
  • 처리 시간의 P10, P50 및 P90이 제시되고 P90이 P50보다 눈에 띄게 높습니다 — 그렇지 않다면 L에서 수집한 범위가 너무 좁게 잡힌 것입니다.
  • 각 역할의 활용률이 알려져 있습니다.
  • “왜 이 단계인가”라는 질문은 도구에 의존하지 않고도 두 문장으로 답할 수 있습니다.

전형적인 실수

평균값으로 계산하기

각 단계에 평균 소요 시간을 할당해 더하면 실제로 거의 발생하지 않는 — 그리고 보통 훨씬 짧은 — 처리 시간이 나옵니다. 그 이유는 대기열입니다: 작업 도착이 변동하고 처리 시간도 변동하면 평균적으로 충분한 처리능력이 있어도 병목이 발생합니다. 가동률이 백퍼센트에 가까울수록 그 영향이 더 큽니다. 표는 각 단계마다 한 줄만 알기 때문에 이 현상을 표현할 수 없습니다.

기구

이 단계에는 계산기가 없습니다

이 단계에 대한 무료 계산기는 없습니다. 이것은 제공의 빈틈이 아니라 과제의 속성입니다: 설문지는 추정할 수 있지만 시뮬레이션은 할 수 없습니다. 그 역할을 하는 것이 FlowVisual입니다.

FlowVisual

FlowVisual은 설문지가 멈추는 지점에서 이 방법이 계속 작동하도록 하는 도구입니다: 프로세스를 그려 수백 번 실행하고 어떤 단계가 막히는지 읽어냅니다. 이것은 자체 도메인의 별도 제품입니다 — FLOWREFY는 방법이고 FlowVisual은 도구입니다.

FLOWREFYmessenverfeinernF찾으십시오L드러내십시오O관찰하십시오W저울질하십시오R줄이십시오E가능하게 하십시오F맞추십시오Y수율을 확인하십시오
ABB. 01시계 방향으로 여덟 단계입니다. 오른쪽 절반이 측정하고 왼쪽 절반이 세밀화합니다; Y 이후에는 사이클이 다시 F에서 시작합니다. 강조: 관찰하십시오.
FAQ

자주 묻는 질문

수백 번이면 병목의 순서가 안정되기에 충분하고, 신뢰할 수 있는 P90 값을 위해서는 수천 번이 더 적절합니다. 실용적인 기준은 간단합니다: 서로 다른 시작값으로 두 번 실행했을 때 동일한 순서와 유사한 분위수를 제공해야 합니다. 그렇지 않다면 실행 수가 부족한 것입니다.

그렇다면 모델이 너무 거친 것 — 단계가 너무 적고 범위가 너무 넓은 것 — 이거나, 프로세스에 단일 병목이 실제로 없고 전반적으로 균일하게 높은 기본 부하가 있는 것입니다. 두 번째 경우는 드물며 W에서는 대개 아무것도 하지 말라는 권고로 이어집니다: 여덟 곳이 비슷하게 부하된 상황에서 한 곳에 개입해도 처리 시간이 거의 개선되지 않습니다.

Process Mining은 실제로 무슨 일이 일어났는지를 읽고 이를 위해 시스템 흔적을 필요로 합니다. 시뮬레이션은 무엇이 일어날지를 계산하며 이를 위해서는 범위를 담은 모델만 필요합니다. 표와 메일함에서 실행되는 프로세스 — 즉 대부분 비용이 큰 프로세스 — 에는 읽을 흔적이 없습니다. 둘 다 가능한 경우에는 서로 보완합니다: Mining은 시뮬레이션이 필요로 하는 범위를 제공합니다.

귀사의 프로세스가 얼마 드는지 알고 싶으시면: 측정하십시오.

무료 진단으로 시작하거나 FlowVisual을 다운로드하세요. 이후에 누군가와 이야기하고 싶다면 저희에게 연락해 주십시오.

문의하기

원격 · 고정가 · 결과를 유로로 제공됩니다