김희준
A3 문제 해결 보고서는 변경의 근거가 되는 사고 과정을 보여 줘야 합니다. 지금 무엇이 일어나고 있는가? 목표와의 차이는 왜 생기는가? 제안한 대책은 왜 도움이 되는가? 이 관계가 타당해야 완성한 한 장이 쓸모를 가집니다.
공유 문제 해결 회의 공간에 근거와 변경안을 나란히 놓고 논의하세요. 여기서는 필요한 정보가 없거나 불명확해서, 일정 담당자가 접수 담당자에게 요청을 반복해서 돌려보내는 교육팀을 예로 살펴봅니다.
양식 완성보다 문제 파악부터 시작하기
Lean Enterprise Institute는 A3를 종이 한 장 이상으로 설명합니다. 현재 상황, 분석, 대책, 책임, 결과의 근거를 공동의 문제 해결 과정에 모으는 방식입니다.
여러 부서의 요청을 받는 교육팀을 생각해 봅시다. 접수 담당자는 요청을 기록해 일정 담당자에게 전달합니다. 일정 담당자는 강사를 배정하고 날짜를 협의합니다. 그런데 제안한 날짜가 승인되었는지, 누가 교육을 받는지, 질문에 누가 답할 수 있는지 알 수 없어 일부 요청이 접수 단계로 돌아옵니다.
“더 나은 요청 양식이 필요하다”는 말은 이미 해결책입니다. 맞을 수도 있지만 문제를 설명하지는 않습니다. 대신 제출된 일부 요청의 교육 대상, 날짜 확정 상태, 결정권이 있는 연락 담당자가 불분명해 강사를 배정하지 못하고, 추가 인계가 발생한다고 정의하는 편이 유용합니다.
관찰할 수 있도록 범위를 좁히세요. 하나의 교육 서비스, 접수에서 일정 배정으로 넘어가는 인계, 정해진 기간을 대상으로 삼을 수 있습니다. ‘조직 전체의 소통 개선’은 A3에 실용적인 경계를 주지 못합니다.
간단한 요청 기록으로 현재 상태 보여 주기
현재 경로를 ‘요청 수신 → 접수 담당자의 세부 정보 준비 → 일정 담당자의 검토 → 강사 배정’으로 그립니다. 일정 담당자에서 접수 담당자로 돌아가는 화살표를 추가하고, 요청이 그 경로를 따라가는 이유를 기록하세요.
아래 예시 기록은 어느 수준까지 구체적으로 남길지 보여 줍니다. 대책을 고르기 전에 이 예시를 대상 서비스에서 실제로 관찰한 기록으로 바꾸세요.
| 요청 예시 | 일정 담당자가 받는 내용 | 되돌리는 이유 | 확인할 질문 |
|---|---|---|---|
| R01 | 날짜는 입력되어 있지만 승인 상태가 없다. | 강사를 확보해도 되는지 알 수 없다. | 날짜가 확정됐는데 기록하지 않은 것인가, 아직 승인 대기 중인가? |
| R02 | 대상자 없이 ‘팀 교육’이라고만 적혀 있다. | 적절한 강사를 선택할 수 없다. | 접수 담당자가 대상자 정보를 받았는가? 어디에 저장했는가? |
| R03 | 요청 내용은 갖춰졌지만 날짜 충돌을 해결할 사람이 지정되지 않았다. | 확인 요청이 접수 담당자를 거쳐 돌아간다. | 누가 결정할 수 있으며, 일정 담당자가 그 사람에게 직접 연락할 수 있는가? |
요청 건수와 추가 확인 횟수는 따로 셉니다. 한 요청이 세 번 돌아갔다면 영향을 받은 요청은 한 건이고, 되돌아간 사건은 세 번입니다. 둘을 합치면 보고서를 작성하는 사람에 따라 문제의 크기가 달라 보일 수 있습니다.
답변을 기다리는 시간과 요청을 검토하는 작업 시간도 구분하세요. 인계에 걸린 전체 시간이 길다고 일정 담당자의 작업 자체가 더 오래 걸린다는 뜻은 아닙니다. 불명확한 정보를 다루는 대책과 밀린 대기열을 다루는 대책은 다를 수 있습니다.
원인과 그럴듯한 설명 구분하기
팀은 요청자가 부주의하다거나 접수 담당자에게 교육이 더 필요하다고 쉽게 결론 내릴 수 있습니다. 실제 업무를 살피지 않았다면 너무 손쉬운 설명입니다. 되돌아온 요청을 최초 제출부터 복사본, 메시지, 인계 단계까지 추적하세요.
R01에는 두 가지 원인이 가능합니다. 날짜가 승인되었지만 접수 담당자가 일정 조율 메시지로 옮기면서 승인 정보를 빠뜨렸을 수 있습니다. 반대로 아직 승인이 나지 않았는데 날짜가 필수 항목이라 임시 값을 입력했을 수도 있습니다. 겉으로 같은 누락처럼 보여도 원인은 다릅니다.
| 가능한 원인 | 뒷받침할 근거 | 대응이 달라지는 이유 |
|---|---|---|
| 필요한 정보가 전달 과정에서 사라진다. | 원본 요청에는 세부 정보가 있지만 일정 담당자가 받은 버전에는 없다. | 요청자에게 다시 묻기보다 인계 과정에서 정보를 보존해야 한다. |
| 결정하기 전에 요청이 전달된다. | 원본 기록과 대화에서도 날짜가 아직 승인되지 않았다. | 준비 상태와 잠정 상태를 명확히 해야 한다. 필수 필드를 하나 더 넣는 것만으로는 해결되지 않을 수 있다. |
| 접수와 일정 담당자가 ‘준비 완료’를 다르게 이해한다. | 두 팀 모두 현재 지침을 따르지만, 각 지침이 요구하는 정보가 다르다. | 어느 팀을 탓하기보다 인계 조건에 합의해야 한다. |
Lean Enterprise Institute의 A3 사고 안내는 탐구와 사실·문제·대책 사이의 논리적인 연결을 강조합니다. 이 사례에서는 한 번의 회의로 모든 칸에 답을 채우는 것보다 인계 과정을 관찰하는 일이 중요합니다.
원인에 맞는 대책 선택하기
인계를 검토한 결과 두 팀의 준비 완료 기준이 다르고, 잠정 날짜와 확정 날짜를 구분할 수 없다는 사실이 드러났다고 가정해 봅시다. 이를 겨냥한 대책은 일정 배정에 필요한 정보를 정하고 날짜의 상태를 명시하는 것입니다.
시범 적용에서는 교육 대상, 희망 날짜와 확정·잠정 여부, 충돌이 생겼을 때 결정할 권한이 있는 사람을 인계 정보에 포함할 수 있습니다. 아직 준비되지 않은 요청은 처리 가능한 요청과 같은 대기열에 넣지 않고, 확인 중임이 드러나게 유지합니다.
이는 미완성 요청을 모두 거절한다는 뜻이 아닙니다. 날짜가 정해지기 전에 계획을 논의하는 일도 정상적입니다. 변경의 목적은 일정 담당자가 초기 문의와 배정 준비가 된 요청을 구분하도록 하는 것입니다. 양식을 제출하려고 요청자가 답을 지어내게 해서는 안 됩니다.
이 제안을 큰 시스템 교체안과 비교해 보세요. 새 시스템에서도 준비 완료 기준이 모호하면 같은 문제가 반복될 수 있습니다. 현재 도구가 필요한 인계를 막는다는 근거가 없다면, 소프트웨어 교체를 A3의 중심으로 삼기 전에 더 명확한 규칙을 시험합니다.
시범 적용과 측정 항목 구체화하기
누가 인계 규칙을 관리할지, 어떤 요청을 시범 적용할지, 언제 결과를 검토할지, 어떤 상황에서 변경하거나 중단할지 적습니다. 기준선과 같은 서비스 범위 및 집계 규칙을 사용하세요.
유용한 지표 하나는 인계 정보가 없거나 모호해 되돌아온 요청의 비율입니다. 분자와 분모를 명시하세요. 대상 그룹과 기간에서 영향을 받은 요청 건수를 전체 제출 요청 건수로 나눕니다. 반복해서 되돌아간 횟수는 따로 집계하고, 일정 결정까지 걸린 시간도 추적합니다.
인계 전 단계도 살펴보세요. 접수 담당자가 요청을 계속 붙잡고 있기 때문에 반송만 줄었다면 서비스가 나아진 것이 아닐 수 있습니다. 접수 단계의 대기 시간과 요청 준비에 추가로 필요한 작업을 기록하세요. 지연이 다른 곳으로 옮겨갔는데 한 지점의 지표만으로 성공을 선언하지 않아야 합니다.
시범 적용에서 관찰 결과가 나올 때까지 결과 영역은 비워 둡니다. A3에 ‘시범 적용안’이라고 적고 계획한 측정 항목을 표시할 수 있습니다. 예측은 제안한 대책 옆에 둘 내용이지, ‘결과’라고 표시한 칸에 넣을 내용이 아닙니다.
Boardmix에 A3 사고 과정 배치하기
Boardmix 캔버스 왼쪽에 현재 상태를 배치하세요. 인계 경로, 되돌아오는 화살표, 요청 기록을 놓습니다. 가운데에는 원인 분석을 두고, 각 설명을 이를 뒷받침하는 근거나 아직 없는 근거와 연결합니다. 오른쪽에는 선택한 대책과 시범 적용 계획을 놓습니다.
이 교육 예시에서는 불분명한 날짜 상태를 확정·잠정 구분안에 연결합니다. 서로 다른 준비 완료 기준은 공동 인계 조건에 연결하세요. 모든 원인을 모든 변경안에 연결하면 어떤 제안이 어떤 문제를 다루는지 알 수 없습니다.
Boardmix에서 보드를 열고 실제 접수 및 일정 조율 사례를 가져와 논의하세요. 필요하면 요청 정보를 익명화합니다. A3 담당자는 명확히 표시하되, 그 사람이 관련된 모든 팀을 지휘한다는 뜻으로 표현하지는 마세요.
나중에 시범 적용에서 요청이 명확해도 강사 일정 때문에 계속 기다린다는 사실이 드러나면 그 발견을 남기세요. 다음에 조사할 문제가 달라지기 때문입니다. A3는 근거를 희생하면서 최초 설명을 고수하는 문서가 아니라, 팀이 왜 이해를 바꾸었는지 보여 주는 문서여야 합니다.
