병목이 설비도 인력도 아니었던 경우
출하가 느리고 진행 상태를 알 수 없다는 문제로 진단했습니다. 기간계와 창고 시스템은 이미 자동으로 연동돼 있었고, 상태를 확인하려면 그 어느 쪽도 아닌 일정 캘린더를 봐야 했습니다. 단계마다 담당자가 손으로 색을 바꿨기 때문입니다.
결과
개선 대상이 아니라 제거 대상으로 규정 — 출하 건당 수기 갱신 5회를 세어 근거로 삼았습니다.
서비스
네 영역, 그리고 각 영역에서 실제로 한 것.
할 수 있는 일을 나열하고 사례를 따로 두면 둘의 관계를 읽는 사람이 맞춰야 합니다. 그래서 영역마다 그 영역에서 진행한 것을 바로 아래 적었습니다.
Start Here
지금 상황과 같은 이름이 있으면 그 자리부터
프로젝트 이름이 아니라 문제 이름으로 적었습니다. 누르면 그 문제를 다루는 영역으로 이동합니다.
- 같은 숫자를 두 번 입력한다한 곳에 넣은 값이 다른 곳에서 다시 타이핑됩니다.
- 진행 상태를 물어봐야 안다「지금 어디까지 됐죠?」에 답하려면 회의를 잡아야 합니다.
- 승인은 있는데 기록이 없다결정은 내려졌는데 누가 언제 승인했는지 남지 않습니다.
- 엑셀이 사실상 시스템이다구조를 제대로 아는 사람이 한 명뿐입니다.
- 요청이 메신저와 메일로 흩어진다무엇이 들어왔고 무엇이 남았는지 세어볼 수 없습니다.
- 같은 보고서를 매달 다시 만든다다 만들 즈음이면 이미 지난 숫자입니다.
- 시스템 사이를 사람이 잇는다연동은 자동인데 그 사이를 사람이 옮겨 적습니다.
- 처리 방법이 사람마다 다르다숙련자가 없는 날에는 속도가 달라집니다.
Readiness
시작점을 정하는 두 축
프로세스가 정의돼 있는지, 그리고 핵심 업무 데이터가 별도 시스템에 있는지. 이 두 축이 시작점을 만들고, 시작점이 첫 프로젝트를 정합니다.
| 지금 상태 | 흔한 모습 | 첫 프로젝트 |
|---|---|---|
| 프로세스도, 데이터를 담을 시스템도 없다 | 요청이 메일과 메신저로 흩어지고, 기록은 엑셀에 남는다 | 접수와 이력부터. 공용 접수함을 만들어 요청이 번호를 받게 한다 |
| 시스템은 있는데 프로세스가 정의되지 않았다 | 본사가 내려준 시스템이 있지만 현지 업무와 맞지 않아 우회 처리가 늘어난다 | 프로세스 정의. 시스템을 더 사는 것이 답이 아니다 |
| 둘 다 갖춰져 있다 | 시스템이 데이터를 만들고 있고, 단계별 입출력이 분명하다 | 자동화와 AI를 바로 붙인다 |
두 번째 줄이 미국에 진출한 한국 기업의 현지 법인에서 가장 자주 보이는 모습입니다. 본사는 현지 사정을 모르고, 현지에는 그 간극을 메울 인력이 없습니다. 16년 동안 그 자리에 있었습니다.
01
진단과 요구정의
무엇을 먼저 할지 정하는 단계. 요건을 정리해 오지 않아도 됩니다.
업무가 정의되지 않은 상태에서 도구를 더하면 우회 경로가 하나 늘어납니다. 먼저 무엇이 들어오고 무엇이 나가는지, 어디서 몇 번 사람 손이 가는지를 세어 적습니다. 대부분의 프로젝트가 여기서 시작하고, 여기서 끝나도 남는 것이 있습니다.
이럴 때
- 무엇부터 해야 할지 정해지지 않은 경우
- 요건을 글로 쓸 수 없는 상태인 경우
- 같은 업무를 부서마다 다르게 설명하는 경우
남는 것
- 현재 상태 판정서 — 준비도 두 축 위의 위치와 근거
- 병목 목록 — 상위 세 개, 각각 손이 가는 횟수까지
- 즉시 · 후속 · 제외 목록 — 하지 말 것과 그 이유
- 프로세스 정의서 — 단계별 입력 · 출력 · 담당 · 완료 조건
- 예외 목록 · 데이터 계보
실제로 한 것
02
업무 시스템 구축
접수·승인·수납처럼 매일 돌아가는 업무를 시스템 안으로.
규칙이 사람 머릿속에 있으면 매달 다시 계산해야 하고, 어긋나도 그 달에는 알 수 없습니다. 규칙을 데이터로 옮겨 계산을 조회로 바꾸고, 사람이 판단하는 지점을 필요한 곳 하나로 줄입니다. 웹 화면과 모바일 앱, 스토어 배포까지 같은 범위 안에 있습니다.
이럴 때
- 조건이 대상마다 달라 매번 손으로 계산하는 업무
- 승인이 메신저와 구두로 이뤄져 기록이 남지 않는 업무
- 멈추면 그날 영업이 멈추는 업무
남는 것
- 동작하는 시스템 — 프로세스 한 건을 처음부터 끝까지
- 판정 기준 설정 — 임계값을 코드가 아니라 값으로
- 장애 대응 절차 — 수동 우회 경로를 기능보다 먼저
- 운영 인계 문서 — 권한 · 변경 방법 · 되돌리는 방법
실제로 한 것
회비가 대상마다 다른데 계산은 사람이 하던 경우
등록일·계약기간·형제 할인·중도 변경이 겹쳐 청구액이 회원마다 달랐습니다. 규칙을 코드 분기가 아니라 컬럼 세 개로 흡수했습니다 — 등록일 · 정기청구일 · 계약만료일.
결과
사람이 판단하는 지점이 매달 전원 → 첫 회 1건. 결제수단 미등록 건은 자동 처리에서 빠져 조용한 실패가 생기지 않습니다.
승인은 있었지만 승인 기록이 없던 경우
영수증이 메일로 오고 같은 숫자가 엑셀과 회계로 옮겨 적혔습니다. 수집에서 회계 전기까지 아홉 단계로 고정하고, 검증 게이트를 승인 앞에 두었습니다.
결과
재입력 구간 제거. 예외가 하나라도 열려 있으면 승인 단계에 도달하지 못하므로, 이미 승인된 건을 되돌리는 일이 생기지 않습니다.
03
연동과 운영 가시성
이미 있는 시스템에서 읽어, 현장과 사무실이 같은 데이터를 봅니다.
상태를 이미 알고 있는 시스템이 있는데 사람이 옮겨 적고 있는 경우가 많습니다. 그 층은 개선 대상이 아니라 제거 대상입니다. 첫 연결은 읽기 전용으로 시작하고, 지표별로 어느 소스에서 읽을지 먼저 고정합니다.
이럴 때
- 진행 상태를 확인하려면 담당자에게 물어야 하는 경우
- 같은 지표가 화면마다 다른 값을 보이는 경우
- 거점이 여러 곳이고 시간대가 다른 경우
남는 것
- 현장 화면과 사무실 화면 — 같은 데이터, 다른 층위
- 데이터 계보 문서 — 지표별 소스 고정
- 읽기 전용 연결 — 기존 시스템에 쓰지 않는 단계부터
실제로 한 것
시스템 사이를 사람이 잇고 있던 경우
수기 일정 캘린더를 더 좋게 만드는 대신 없앴습니다. 상태는 이미 시스템이 알고 있었으므로 시스템을 직접 읽어 현장 보드와 사무실 화면에 공유했습니다. 트럭 배차 시 타임테이블에 자동 등록되고, 슈퍼바이저가 준비할 스테이지를 지정합니다.
결과
출하 건당 수기 갱신 5회 → 0회. 도크에 상주해 중복 입력하던 3명 → 슈퍼바이저 1명이 스테이지 지정. 5개 거점 · 3개 시간대를 공통 간격으로 실시간 집계. 상차 순서가 지게차 운전자의 경험이 아니라 화면을 따릅니다.
04
자동 판정 도입
판정 로직은 고정하고, 실행 권한만 단계적으로 올립니다.
「잘못 판단하면 어떻게 되나」에 보증으로 답할 수는 없습니다. 순서로 답합니다. 같은 로직을 그대로 두고 기록만 → 유예 후 확정 → 즉시 확정으로 권한을 올립니다. 켜는 시점은 합의가 아니라 사람 결정과의 일치율이 정합니다.
이럴 때
- 같은 기준으로 사람이 매번 반복해서 승인하는 업무
- 그 기준을 글로 쓸 수 있는 업무
- 잘못된 판정의 되돌리기 비용이 큰 업무
남는 것
- 판정 로직 — 세 단계에서 동일하게 유지
- 기준 설정 파일 — 담당자가 개발자 없이 변경
- 변경 관리 — 유예 시간 · 효력일 · 배포 전 영향 건수 · 즉시 복귀
실제로 한 것
심사를 사람이 전건 처리하던 경우
판정 로직을 먼저 완성하고, 실행 권한만 세 단계로 나눠 올렸습니다. 1단계는 기록만 남기며 사람 결정과 나란히 비교하고, 2단계는 정해진 시간이 지나면 자동 확정되며 그 사이 사람이 막을 수 있습니다.
결과
켜는 결정이 데이터로 정해집니다. 기준은 설정 파일에 있어 담당자가 바꾸고, 변경에는 유예와 효력일이 붙고, 배포 전에 몇 건이 달라지는지 먼저 셉니다.