7.3업무 흐름 다듬기

업무 흐름을 다듬을 때 가장 흔한 실수는 가장 눈에 띄는 단계만 개선하는 것입니다.

초안 작성이 12분에서 4분으로 줄었는데 전체 처리 시간이 그대로라면, 시간은 다른 곳에서 새고 있습니다. 대개 기다리는 시간입니다.

시간 종류	어디서 생기는가
작업 시간	실제로 손을 움직이는 동안
대기 시간	승인, 자료 요청, 다른 사람의 일정
전환 시간	도구를 옮기고 자료를 찾는 동안

많은 업무에서 대기 시간이 작업 시간보다 깁니다. 3일 걸리는 일에서 실제 작업은 2시간이고 나머지는 기다림인 경우가 흔합니다. 이럴 때 작업 시간을 1시간으로 줄여도 전체는 거의 그대로입니다.

세 번째 항목도 무시하기 어렵습니다. 자료를 찾고, 도구를 열고, 형식을 맞추는 데 드는 시간입니다. 이건 재사용 가능한 형태를 만들어 줄일 수 있습니다.

그래서 최적화의 첫 단계는 어디서 시간이 새는지 재는 것입니다. 재지 않고 개선하면 눈에 띄는 곳만 손대게 됩니다.

같은 일을 반복한다면 매번 처음부터 하지 않도록 만들 수 있습니다.

• 요청문 틀 — 바뀌는 부분만 비워 두고 나머지는 고정
• Projects 설정 — 배경과 형식을 대화 밖에 두기
• 확인 목록 — 매번 확인할 것을 목록으로
• 잘 된 결과 보관 — 다음에 예시로 붙일 수 있게

첫 번째가 가장 쉽고 효과도 큽니다.

[주간 보고 요청 틀]
아래 주간 실적 자료를 붙인다. (여기에 자료)
지난주 대비 변화가 큰 항목 세 개를 골라
각각 원인 추정과 함께 정리해 줘.
- 분량: 항목당 3줄
- 자료에 없는 추정은 "추정"으로 표시
- 형식: 지난주 보고서와 동일

이 틀이 있으면 매주 자료만 바꿔 넣으면 됩니다. 전환 시간이 거의 사라지고, 매번 조건을 다르게 쓰는 일도 없어져 결과가 일정해집니다.

네 번째도 유용합니다. 특히 잘 나온 결과는 다음에 예시로 붙이면 설명보다 정확하게 형식을 전달합니다.

최적화에도 그만둘 때가 있습니다. 다음이 신호입니다.

• 개선에 드는 시간이 절약되는 시간보다 클 때
• 한 달에 한 번 하는 일을 다듬고 있을 때
• 이미 전체에서 차지하는 비중이 작은 단계일 때
• 사람마다 하는 방식이 달라 표준화가 어려울 때

두 번째가 자주 간과됩니다. 빈도가 낮은 일은 개선 효과도 낮습니다. 분기에 한 번 하는 작업의 요청문 틀을 정교하게 만드는 데 두 시간을 쓰면 회수하기 어렵습니다.

세 번째는 계산해 보면 분명합니다. 전체 3일 중 10분짜리 단계를 절반으로 줄여도 전체는 5분 줄어듭니다. 그 5분을 위해 들이는 노력이 값어치가 있는지 따져야 합니다.

어디까지 최적화할지 미리 정해 두는 것도 방법입니다. "이번에는 가장 오래 걸리는 두 단계만 본다"고 정하면 끝없이 다듬는 일을 막을 수 있습니다.

개인이 만든 요청문 틀이나 설정은 팀에서 함께 쓸 때 값어치가 커집니다. 같은 일을 하는 사람이 다섯이면 효과도 다섯 배입니다.

나눌 때 함께 전달할 것이 있습니다.

• 무엇에 쓰는 것인지
• 어떤 경우에는 맞지 않는지
• 바꿔야 할 부분이 어디인지

두 번째가 중요합니다. 한계를 모른 채 받아 쓰면 안 맞는 상황에 적용하고 실망하게 됩니다. "이 틀은 정기 보고용이고 일회성 분석에는 안 맞는다"는 한 줄이 그것을 막습니다.

그리고 나눈 뒤에는 누가 관리할지 정해야 합니다. 여러 사람이 쓰는 틀을 아무나 고치면 다른 사람의 결과가 갑자기 달라집니다. 바꿀 때 알리는 규칙 하나면 충분합니다.