회사 프로세스 지도 — 지난 메일과 인계 기록으로 그리고, 들어온 건을 그 자리에서 실행하기

지난 90일 메일과 채팅 인계 기록을 읽어 회사 하나의 프로세스 지도(일 · 다음 일 · 확률 · 조건)를 Ontological DB에 그립니다. 들어온 건은 그 건이 시작되는 일부터 BPMN 스냅샷으로 실행합니다. 쓰이지 않는 길은 은퇴 후보로 올리고, 꼭 거칠 일은 고정하며 지도를 바꿔 갑니다.

마이닝과 무엇이 다른가#

19장의 프로세스 마이닝은 반복되는 흐름 하나를 정식 프로세스 하나로 등록했습니다. 등록한 프로세스는 늘 첫 단계부터 시작하고, 갈림길은 정의에 그려 둔 대로 갑니다.

그런데 실제 일은 그렇게 흐르지 않습니다. 달빛커피 한서윤 사장처럼 “설계안은 그대로, 견적만 다시”라고 중간에서 들어오는 건이 있습니다. 견적서 다음에 재무 검토를 거칠지는 금액에 따라 다릅니다. 지난달에 자주 가던 길이 이번 달에는 안 쓰이기도 합니다.

이 장에서는 프로세스를 여러 벌의 정의가 아니라 회사 하나의 지도로 남깁니다.

무엇을 읽고 무엇을 남기나#

같은 일을 다르게 부른 말(“견적 보냄”, “견적서 송부”, 에이전트에게 준 긴 지시문)은 회사가 이미 쓰는 일 이름 하나로 맞춥니다. 메일에서 시작한 일은 채팅 인계도 그 메일 스레드의 건으로 합칩니다.

따라 하기 1 — 지도 그리기#

이 장의 화면은 실내 설계 · 시공 회사 데모 테넌트에서 찍었습니다. 제안팀장 장진영(관리자), 영업 이도윤, 디자이너 김민지, 재무 담당 박서연이 등장합니다. 장진영의 데모 메일함에는 지난 90일 동안의 메일 483통(뉴스레터 · 자동 알림 · 일정 초대 포함)이 있습니다.

1. 장진영으로 들어가 주소 끝에 /process-map을 붙이거나 프로젝트 목록의 「회사 프로세스 지도」를 엽니다. 처음 화면에는 무엇을 읽고, 거르고, 남기는지 나옵니다.

   

2. 「지난 메일 읽기(90일)」를 누릅니다. 거른 메일은 곧바로 읽은 것으로 셉니다. 먼저 채팅 인계 기록의 일 이름을 맞춘 뒤(몇 분), 메일 스레드를 네 개씩 읽습니다. 창을 닫아도 계속 읽습니다. 실습에서는 다 읽고 지도를 그리기까지 약 13분 걸렸습니다.

   

3. 지도가 그려지면 채팅에 “메일 483통과 채팅 핸드오버를 읽어 일 20개, 흐름 3개를 찾았어요.”라는 요약 카드가 올라옵니다. 묶음마다 띠(굳은 길 · 열린 일 · 지켜보기)와 건수가 보입니다. 묶음을 누르면 그 묶음의 지도가 열립니다.

   

묶음은 함께 다니는 일들의 무리입니다. 공통 일(요청 접수 · 고객 회신) 하나 때문에 다른 흐름이 한 묶음으로 붙지 않습니다. 띠는 따로 떼어 둔 최근 건의 다음 일을 얼마나 잘 맞히는지로 정합니다. 잘 맞히면 「굳은 길」, 건이 적어 아직 잴 수 없으면 「지켜보기」입니다.

따라 하기 2 — 배운 조건 · 은퇴 후보 · θ · 자동 값 · 지난 시점#

1. 배운 조건 — 견적서 작성 다음의 두 갈래 가운데 「견적서 작성 → 재무 검토」의 비율 꼬리표를 누릅니다. 오른쪽 패널에 “조건 · 견적 합계(amount)가 10,000,000원 이상”이 보입니다. 메일에 적힌 합계 금액에서 두 갈래를 가장 잘 가르는 문턱을 찾아, 사람이 쓰는 값(1천만 원)으로 맞췄습니다. 하나씩 빼고 맞혀 본 정확도는 1.0입니다. 이 값이 늘 많은 쪽을 고를 때(0.62)보다 높아야 조건으로 씁니다.

   

2. 은퇴 후보 — 주황 점선 「요청 메일 접수 → 평면도 작성」(실측 없이 바로 평면도)을 누릅니다. “예전 빈도로는 최근 72일 동안 29.4건쯤 나왔어야 하는데 0건이에요.” 그 길이 마지막으로 쓰인 뒤에도 요청 메일 접수에서는 일이 계속 넘어갔습니다. 예전 비율이라면 나왔어야 할 건수가 3건을 넘지만, 그 길은 한 번도 쓰이지 않았다는 뜻입니다. 조용한 한 주나 아직 진행 중인 건 때문에 후보가 되지는 않습니다.

   

3. θ(입도) — 지도 위 「요약 · 기본 · 전체」와 막대로 문턱을 정합니다. 그보다 드문 길은 화면에서 빠집니다. 「전체」로 보면 한 번만 쓰인 길까지 다 보이고, 「기본」으로 돌아오면 빠집니다. 은퇴 후보와 고정한 길은 θ와 상관없이 그립니다. 여기서 θ를 바꿔도 화면만 달라지고, 실행에 쓰는 θ는 그대로입니다.
4. 자동 값 — 「값 보기」를 누르면 θ · 반감기 · 띠를 어떻게 정했는지 근거 그림이 나옵니다. 사람이 정하는 값은 없습니다(아래 표).

   

5. 지난 시점 — 오른쪽 위 시점 고르기에서 8월 28일을 고르고 같은 길을 누릅니다. 그때는 그 길이 45%로 자주 쓰였고 은퇴 후보도 아니었습니다(지금 9%). 처음 계산할 때 지난 기록을 주마다 다시 세고, 그 주를 효력일로 적었기 때문입니다. 「지금」을 누르면 돌아옵니다.

   

6. 이름 맞춘 기록 — 메일과 채팅에서 다르게 부른 말이 어떤 일 이름으로 모였는지 봅니다. 긴 지시문(“이 실측 치수로 평면도 초안 만들어 줘. …”)도 「평면도 작성」 하나로 맞춰져 있습니다.

자동으로 정하는 값 세 가지와 실습에서 나온 값입니다.

따라 하기 3 — 어디서든 시작: 「견적만 다시」 메일#

1. 묶음 채택 — 「요청 접수 · 실측」 묶음을 고르고 「이 묶음 채택」을 누릅니다(관리자만). 채택한 묶음이 있으면 들어온 메일은 19장의 정식 프로세스보다 먼저 이 지도로 갑니다.
2. 일 정의 — 지도에서 「견적서 작성」 상자를 누릅니다. 패널에 메일 · 채팅에서 이 일을 부른 다른 이름과 「메일에서 본 양식」(견적서_양식.xlsx, 메일 66통)이 보입니다. 「양식에서 초안 만들기」를 누르면 양식의 칸에서 뽑은 점검 항목을 담은 일 정의가 스킬(SKILL.md) 형식으로 나옵니다. 폼은 만들지 않습니다.

   ---
   name: 견적서 작성
   kind: task
   runner: agent
   skills: [xlsx]
   outputs:
     - name: 견적서
       format: xlsx
       template: 견적서_양식.xlsx
   checkpoints:
     - 고객명, 견적일, 프로젝트, 유효기간, 현장 주소, 담당을 기재한다.
     - …
   ---
   ## 하는 일
   1. …
   

   runner를 agent로, skills를 [xlsx]로 고쳐 저장합니다. 다음 스냅샷부터 이 일은 업무 에이전트가 합니다.

   

3. 메일 도착 — 달빛커피 한서윤이 “2호점 견적만 다시 부탁드려요”(좌석 32석 → 40석, 바닥재 원목)를 보냅니다. 장진영의 채팅에 카드가 생깁니다. 시스템은 묶음의 주 경로를 따라 일마다 “이 요청은 이 일부터 하면 되나요?”를 예/아니오로 묻습니다. 앞의 일들이 아니고 이 일이라는 확률이 가장 큰 일에서 시작합니다. 실습에서는 주 경로의 일마다 “예”의 확률이 현장 실측 1% · 평면도 작성 2% · 제안서 작성 38% · 견적서 작성 88%였습니다. 견적서 작성은 앞의 세 일이 모두 아니고 이 일이라는 확률(0.88 × 0.99 × 0.98 × 0.62 ≈ 0.54)이 가장 커 여기서 시작했습니다. 앞의 현장 실측 · 평면도 작성 · 제안서 작성은 건너뜀으로 남았습니다. 확률이 0.5보다 낮으면 시작하지 않고 후보를 보여 줍니다. 사람이 그중에서 고릅니다.

   

4. 스냅샷 실행 — 카드의 프로세스를 엽니다. 스냅샷은 맨 앞 「요청 접수」(장진영) 뒤에 견적서 작성을 두고, 지도에서 θ 이상인 길과 고정한 길만 따라 펼친 BPMN입니다(역할마다 레인, 배운 조건은 배타 게이트웨이). Process GPT 엔진이 그대로 실행합니다. 업무 에이전트가 일 정의에 맞춰 회사 견적서 양식으로 견적서를 만듭니다. 점검 항목마다 파일을 확인하고 메시지 아래에 ✓ · ✗ 로 남깁니다. 실습에서는 합계 97,680,000원으로 나왔고, 점검 항목 5개 가운데 4개가 ✓였습니다. 「품목 · 규격 · 수량 · 단가 · 금액 · 비고를 기재한다」는 주방 · 창고 · 전기 행의 비고 칸이 비어 ✗였습니다. 점검 항목을 보면 에이전트가 만든 파일을 사람이 어디부터 확인할지 알 수 있습니다.

   

5. 배운 조건대로 — 엔진이 게이트웨이의 조건(“견적 합계가 1천만 원 이상”)을 판단해 재무 검토를 엽니다. 이 건의 화면에서 「다이어그램」을 누르면 스냅샷의 BPMN에서 지금 열린 단계가 보입니다. 박서연의 홈에는 「입력 · 재무 검토」 카드가 생기고 앞 단계의 견적서가 붙어 있습니다. 1천만 원 미만이었다면 고객 회신(이도윤)으로 갔을 것입니다.

   

따라 하기 4 — 검토 안건: 은퇴와 앞날짜 고정#

1. 검토 안건 — 「검토 안건」을 누르면 은퇴 후보가 근거 숫자와 함께 모여 있습니다. 「은퇴시키기」를 누르고 이유(“실측 없이 진행하지 않기로 함”)를 적어 적용합니다. 관리자만 할 수 있습니다.

   

2. 은퇴한 길은 지도에서 회색 점선으로 보이고, 다음 스냅샷부터 그 길로 가지 않습니다. 지우지 않고 “이날부터 유효하지 않음”으로 적습니다. 그래서 「한 주 전」으로 돌리면 그 길은 아직 살아 있고, 「되살리기」로 되돌릴 수도 있습니다.
3. 앞날짜 고정 — 「재무 검토」 상자를 누르고 「고정」을 켭니다. 효력일을 다음 달 1일로, 이유를 “금액과 상관없이 재무 검토”로 적고 「고정하기」를 누릅니다.
4. 날짜별 스냅샷 — 「스냅샷 보기」에서 시작 일을 견적서 작성으로 고릅니다. 오늘 기준으로는 견적서 작성 뒤의 갈래가 아직 금액에 따라 나뉩니다. 「기준 날」을 다음 달 1일로 바꾸면 견적서 작성 뒤에는 늘 재무 검토가 옵니다. 고정한 일을 비켜 가는 갈래가 빠지기 때문입니다.

   

   

5. 결정 원장 — 검토 안건 아래 「최근 결정」에 “은퇴: 요청 메일 접수 → 평면도 작성”, “고정: 재무 검토 (다음 달 1일부터)”가 누가 · 언제 결정했는지와 함께 남습니다. 같은 결정은 Ontological DB의 이력에도 남습니다.

다음 장으로#

지도는 쌓인 메일 이력과 채팅 인계를 바탕으로 매주 다시 계산합니다. 다음 6부 「프로세스 개선」에서는 정식 프로세스와 스냅샷이 남긴 실행 기록으로 어느 단계에서 일이 쌓이는지(21장), 가치를 만드는 시간과 기다리는 시간이 얼마인지(22장), 전체 기간을 정하는 경로가 무엇인지(23장)를 찾아 고칩니다.