크리티컬 패스와 개선 실행

전체 기간을 정하는 단계의 사슬(크리티컬 패스)과 늦어져도 되는 여유 시간을 BPMN과 간트로 보고, 진행 중인 건이 언제 끝날지 셈합니다. 그다음 단계를 바꾸면 리드타임이 얼마나 줄지 미리 계산하고, 마음에 드는 안을 새 버전으로 적용해 실제로 돌려 봅니다.

크리티컬 패스 — 전체 기간을 정하는 사슬#

21장에서 제약(재무 검토)과 개선 후보를 찾았습니다. 이 장에서는 전체 기간이 어떤 단계들로 정해지는지 보고, 후보를 미리 계산한 뒤 실제로 적용합니다.

프로세스에는 동시에 진행되는 단계가 있습니다. 「달빛커피 제안」에서는 요청을 접수하면 평면도 작성(김민지)과 견적 초안(견적 에이전트)이 함께 시작되고, 둘 다 끝나야 제안서 작성으로 넘어갑니다.

                 ┌─ 평면도 작성  4.2시간 ─┐
요청 메일 접수 ──┤                        ├── 제안서 작성 6분 ── 재무 검토 3.0일 ── 고객 회신 1.7시간
                 └─ 견적 초안    3분 ─────┘

견적 초안이 3분 만에 끝나도 제안서 작성은 평면도를 기다립니다. 전체 기간은 가장 오래 걸리는 사슬이 정합니다. 이 사슬이 크리티컬 패스(critical path, 주 경로)입니다. 크리티컬 패스의 단계가 1시간 늦어지면 전체가 1시간 늦어지고, 크리티컬 패스가 아닌 단계는 조금 늦어져도 전체에 영향이 없습니다.

이것을 계산하는 방법을 CPM(Critical Path Method)이라 합니다. 단계마다 네 시각을 셉니다.

여유 시간(slack, float) = LS − ES입니다. 견적 초안은 여유가 4.2시간이라, 그만큼 늦게 시작해도 전체가 늦어지지 않습니다. 여유가 0인 단계들이 크리티컬 패스입니다.

업무 프로세스의 CPM은 세 가지가 다르다#

공사 일정표의 CPM과 달리, 업무 프로세스에는 다음이 있습니다. Process GPT Lite는 BPMN 그대로 계산합니다.

단계 시간은 잰 시간입니다. 그 단계에 도달해 끝날 때까지, 대기를 포함한 실제 시간입니다. 「보통(중앙값)」과 「늦을 때(p80)」 두 가지로 볼 수 있습니다.

따라 하기 1 — 크리티컬 패스 보기#

개선 화면의 「크리티컬 패스」 탭을 엽니다.

아래 간트와 표에 단계마다 ES·EF·LS·LF·여유가 나옵니다. 빗금은 기다린 시간, 진한 막대는 작업 시간입니다.

크리티컬 패스 3.2일 가운데 재무 검토가 2.8일입니다. 재무 검토의 단계 시간 대부분이 빗금이라는 것이 20장·21장과 같은 이야기를 다른 각도에서 보여 줍니다.

오른쪽 위를 「늦을 때(p80)」로 바꾸면 각 단계의 p80 시간으로 다시 계산합니다. 기대 리드타임이 4.9일이 되고, 평면도 작성이 20시간으로 늘어납니다. 그래도 견적 초안은 여전히 여유가 있습니다.

진행 중인 건은 언제 끝나나#

진행 중인 건은 이미 끝난 단계의 실제 시간, 지금 하고 있는 단계의 남은 시간(보통 걸리는 시간 − 지난 시간), 나머지는 잰 시간으로 다시 계산합니다. 화면 아래 「진행 중인 건의 남은 크리티컬 패스」에 나옵니다.

사진의 광화문 53호점은 견적 에이전트가 실제로 견적 초안을 쓰는 중입니다. 지금 단계는 몇 분이면 끝나지만, 남은 3.3일의 대부분은 앞으로 거칠 재무 검토 앞에서 보통 기다리는 시간입니다. 예상 완료 시각은 지난 기록의 달력 시간(밤·주말 포함)으로 셈한 값입니다.

따라 하기 2 — 개선 실행, 바꾸기 전에 미리 계산하기#

「개선 실행」 탭에서 단계 하나를 바꾸면 리드타임·크리티컬 패스·흐름 효율·제약 가동률을 바로 다시 계산합니다. 프로세스는 아직 바뀌지 않습니다.

대기는 21장에서 본 두 종류로 나눠 계산합니다. 차례 기다림만 대기열 공식(가동률 ÷ (1 − 가동률)과 같은 모양, 여러 명이면 인원수를 반영한 공식)으로 늘고 줄며, 담당자 기다림(이 일을 하는 시간대를 기다린 시간)은 그대로 둡니다. 사람 수나 일의 양을 바꿔도 “다음 날 오전까지 기다리는” 구조는 그대로이기 때문입니다.

시험 1 — 평면도를 자동화하면?#

종류를 「에이전트로 자동화」, 단계를 「평면도 작성」으로 고르고 「담기」를 누릅니다.

평면도는 크리티컬 패스 위에 있으므로 그 몇 시간만큼 줄지만, 재무 검토 앞 대기는 그대로라 효과가 작습니다. 흐름 효율은 오히려 내려갑니다 — 사람이 1.6시간 하던 일을 에이전트가 4분에 하니 작업 합은 줄었는데, 리드타임은 거의 그대로이기 때문입니다. 흐름 효율은 “얼마나 덜 기다리나”를 보는 지표라, 기다림을 줄이지 않는 개선에는 좋아지지 않습니다. 21장 확인 문제 3의 답을 숫자로 확인한 셈입니다. 칩의 ×로 빼 둡니다.

시험 2 — 제약을 겨냥하기#

「제약 이론 5단계에서:」 버튼 중 「에이전트가 먼저 검토 초안을 만들고 담당자는 확인만」과 「견적 금액 4,000만 미만은 재무 검토 없이 진행」을 누릅니다. 두 안이 함께 담깁니다.

재무 검토가 1.5일 남는 이유도 보입니다. 박서연의 차례 기다림은 거의 사라졌지만, 검토를 오전에만 하는 담당자 기다림은 그대로이기 때문입니다. 다음 개선 후보(검토 시간대를 하루 두 번으로)가 여기서 나옵니다.

개선안 적용 — 새 버전 만들기#

「개선안 적용」을 누르면 확인 창이 뜹니다. 무엇이 바뀌는지와 예상 효과를 보고 「적용」을 누릅니다. 프로세스 담당자(소유자)와 관리자만 할 수 있습니다.

적용하면 다음이 일어납니다.

화면 위쪽의 버전 선택에서 「v2.0」을 고르면 새 버전의 BPMN과 그 버전으로 시작한 건만으로 계산한 결과가 나옵니다.

바꾼 뒤 — 버전별 비교#

실습에서는 적용 뒤 새 요청 두 건을 실제로 돌렸습니다.

연남 56호점의 재무 검토는 에이전트 초안 26초, 박서연의 확인 49초로 나뉘어 기록됐습니다(20장의 분해 그대로). 「개선 실행」 탭 아래의 버전별 비교가 두 버전을 나란히 보여 줍니다.

맨 아래 줄에는 적용할 때의 예측(기대 리드타임 3.2일 → 1.4일, 흐름 효율 3.8% → 7.1%)이 남아 있어, 건이 쌓인 뒤 예측과 실제를 맞대어 볼 수 있습니다.

다음 장으로#

여기까지가 6부 「프로세스 개선」입니다. 장진영 팀장은 채팅과 편집기, 개선 화면만으로 즉흥적으로 하던 일을 정식 프로세스로 만들고 고쳤습니다. 다음 7부에서는 이 시스템을 키우고 운영하는 쪽으로 시야를 넓힙니다. 첫 장은 에이전트가 일하는 작업 폴더를 직접 여는 에이전트 작업실입니다(23장).