실행, 결과, 경험의 축적: 한 번의 일이 조직 역량이 되려면

일을 하나 해내고 나면, 팀은 다음에도 같은 방식으로 할 수 있도록 과정을 기록하곤 합니다. 그런데 시간이 지나면 문서는 그대로인데도, 같은 문제 앞에서 다시 그 일을 했던 사람을 찾게 됩니다.

그 사이에 무엇이 빠진 걸까요?

저는 몇 가지를 더 물어봐야 한다고 생각합니다. 그때는 왜 해낼 수 있었는지, 어떤 방법을 다시 시험해 볼 만한지, 다른 사람도 쓸 수 있는지, 사용한 뒤에는 누가 돌아와 확인할지 말입니다. 이 과정이 이어져야 한 번의 경험이 조직이 앞으로 의지할 수 있는 역량이 될 가능성이 생깁니다.

‘실행, 결과, 경험의 축적’을 생각의 흐름으로 삼을 수 있습니다. 어떤 경험을 남길지는 선택과 검증을 거쳐야 합니다. 남긴 뒤에도 누군가 계속 관리해야 합니다.

1. 이번에 무슨 일이 있었는지 확인한 뒤, 무엇을 남길지 논의하기

업무를 마치면 먼저 세 가지를 나누어 볼 수 있습니다.

실행은 실제로 무엇을 했는지에 답합니다. 누가 어떤 조건에서 어떤 자료와 자원을 사용했는지, 어떤 순서로 일했고 예외가 생겼을 때는 어떻게 처리했는지를 봅니다.

결과는 무엇이 달라졌는지에 답합니다. 산출물이 요구사항에 맞는지, 다음 단계에서 이어서 일할 수 있는지, 시간과 비용은 얼마나 들었는지, 아직 이행하지 못한 책임은 무엇인지 확인합니다. 고객과 경제적 결과에 관련된 업무라면, 해당 사업의 성과가 만들어지는 흐름으로 돌아가 수요, 계약 성사, 약속 이행, 대금 회수 등의 결과도 확인해야 합니다.

경험의 축적은 그중 무엇을 다음 업무에 가져갈 만한지에 답합니다. 더 분명한 판단 규칙일 수도 있고, 반복해서 쓸 수 있는 방법일 수도 있습니다. 피해야 할 조건을 알아낸 것일 수도 있습니다.

이 세 가지를 곧바로 같은 것으로 볼 수는 없습니다. 고객이 한 번 견적을 받아들인 데에는 급한 수요, 경쟁 상황, 기존 관계 등이 영향을 미쳤을 수 있습니다. 책임자가 임시로 자원을 동원해 납기를 맞췄다고 해서 기존 절차가 이미 믿을 만해졌다고 볼 수도 없습니다.

반대로 한 번의 실패에서도 쓸 만한 배움을 얻을 수 있습니다. 특정 공급 조건에서는 기존 일정을 약속하면 안 된다는 것, 어떤 자료가 없으면 일단 멈추고 확인해야 한다는 것 등입니다. 먼저 사실을 분명히 확인하고, 그 판단이 적용되는 상황을 함께 남겨야 합니다. 하나의 설명을 서둘러 보편적인 결론으로 만들지 않아야 합니다.

성과가 기대에 미치지 못했다면, 먼저 성과가 만들어지는 흐름에서 문제를 찾고 어느 수준의 업무를 바꿀지 결정해야 합니다. 점검표를 늘리거나 실행 단계를 세분화하는 일도 실제 문제와 맞닿아 있을 때 추진할 가치가 있습니다.

2. 경험을 네 가지 상태로 구분해 보기

업무 중 판단을 돕기 위해, 경험을 아래 네 가지 상태로 기록해 볼 것을 제안합니다. 이 글에서 제시하는 사용 방법이며, 상태의 이름 자체가 검증 결과를 뜻하지는 않습니다.

앞의 상태에서 다음 상태로 넘어가려면 새로운 근거가 필요합니다. 문서를 올렸거나 교육을 마쳤다는 이유만으로 조직이 이미 갖춘 역량이라고 기록해서는 안 됩니다.

특히 주의해서 볼 상황이 있습니다. ‘방법’이라고 부르지만, 실제로는 원래 일을 잘하던 사람이 많은 판단을 보충해 주고 있는 경우입니다. 시험 적용할 때는 그 사람이 곁에서 계속 알려 주어 결과가 좋아 보입니다. 그런데 그 사람이 빠지면 업무가 다시 멈춥니다. 이럴 때는 필요한 경험적 판단을 설명하고, 훈련이나 보조 도구, 예외 대응 지원을 마련해야 합니다. 숙련자의 개입이 여전히 필요한 범위도 사실대로 남겨야 합니다.

조직 역량이 형성되었는지는 실제 업무에서 봐야 합니다. 기록, 절차, 도구, 훈련은 이를 뒷받침합니다. 그와 함께, 정해진 조건에서 팀이 업무를 계속 완수하고 예외를 처리할 수 있는지 검증해야 합니다.

좌우로 스크롤하거나 큰 그림을 열어 확인하세요.

큰 그림 열기 ↗편집 가능한 SVG 다운로드 ↓

3. 회고에서 나온 판단을 시험 적용할 수 있는 방법으로 바꾸기

회고에서 ‘다음에는 미리 소통하자’고 말해도 다음번에 실행하기는 여전히 어렵습니다. 언제가 ‘미리’인지, 누구와 소통할지, 무엇을 확인해야 하는지, 의견이 다르면 누구에게 맡길지가 아직 분명하지 않기 때문입니다.

시험해 볼 만한 경험이라면 적어도 여섯 가지를 설명할 수 있어야 합니다.

1. 문제와 상황: 어떤 종류의 업무에서 어떤 문제가 반복되는지, 어떤 조건이 판단을 바꾸는지.
2. 근거와 설명: 무엇을 기록했는지, 아직 무엇이 불확실한지, 이 변경이 왜 도움이 될 것이라고 보는지.
3. 시험할 방법: 어떤 조건에서 시작하고, 구체적으로 무엇을 하며, 무엇을 넘겨주고, 완료 여부를 어떻게 판단할지.
4. 예외와 적용 한계: 어떤 상황에서는 그대로 쓰면 안 되는지, 언제 멈추고 누구에게 처리를 맡길지.
5. 시험 적용 계획: 누가 어느 범위에서 시험할지, 누가 자원을 제공하고 언제 재검토할지.
6. 관찰 방법: 무엇이 나아질 것으로 예상하는지, 어떻게 비교하고 어떤 추가 비용과 영향도 함께 살펴볼지.

자료를 길게 쓸 필요는 없습니다. 업무를 넘겨받는 사람이 이해하고 시험 적용할 수 있으며, 재검토하는 사람이 근거를 다시 찾아볼 수 있다면 일단 시작할 수 있습니다.

여기서는 계획·실행·연구·행동(PDSA)의 학습 방식을 참고할 수 있습니다. Deming Institute는 PDSA를 설명하면서 실제 결과를 예상과 비교하고, 그에 따라 방법과 기존 설명을 바꿀 수 있어야 한다고 강조합니다.[1] IHI의 시험 적용 지침은 실행 가능한 작은 범위에서 시작해 예상 밖의 영향을 관찰하고, 다른 조건에서도 계속 검증할 것을 제안합니다. 개선을 가져오지 못하는 방법은 시험 적용을 중단할 수 있다고 설명합니다.[2]

이 자료들은 시험 적용을 설계할 때 참고가 됩니다. 이 글의 방법이 이미 여러 종류의 기업에서 효과를 냈다는 증거는 아닙니다. 기업은 자신의 사업과 실패에 따르는 비용을 고려해 어떤 검증이 필요한지 정해야 합니다.

4. ‘견적 전 공급 일정 확인’에 적용해 보기

아래는 실행 방법을 설명하기 위한 가상의 예시입니다. 실제 기업의 성과 데이터는 없습니다.

어느 설비 서비스 팀이 고객이 요청한 시각 전에 제안서를 제출했습니다. 나중에 확인해 보니 최종 공급 일정은 책임자가 임시로 조율해 확보한 것이었습니다. 영업 담당자가 견적을 준비할 때 가진 정보는 공급 협력사가 이전에 제공했던 참고 일정이었습니다.

이번 결과는 확인할 수 있지만, 방법에는 여전히 의문이 남습니다. ‘책임자의 조율’을 매번 거쳐야 하는 절차로 만들면, 책임자가 새로운 대기 지점이 됩니다. 공급 조건도 매번 같은 방식의 조율을 허용하지는 않을 수 있습니다.

먼저 작은 개선 가설을 세워 볼 수 있습니다. 납기를 약속해야 하는 맞춤 주문이라면, 견적 전에 이번 주문의 공급 조건을 확인하고 확인 날짜, 유효 범위, 미해결 사항을 표시합니다. 이렇게 하면 이후의 납기 조정을 줄일 가능성이 있습니다.

이어서 시험 적용 계획을 분명히 합니다.

시험 적용 전에는 비교 기준도 정해야 합니다. 주문 유형, 복잡도, 공급 조건의 차이가 크다면 전후의 변화를 모두 이 확인 기록 덕분이라고 볼 수 없습니다. 업무량이 적을 때 문제가 잠시 다시 발생하지 않았다고 해서 검증이 끝났다고 선언할 수도 없습니다.

‘몇 번 성공하면 정식으로 고정해도 된다’는 공통 횟수는 없습니다. 영향 범위가 넓고 실수의 결과를 되돌리기 어려울수록 확인과 시험 적용을 더 충분히 해야 합니다. 실제 업무에서 시행착오를 허용할 수 없는 조건이라면 과거 업무, 모의 상황, 전문적인 검토로 먼저 검증할 수 있습니다.

이 예시에서 남기려는 것은 적용 범위가 정해져 있고 계속 확인할 수 있는 방법입니다. 그것이 계약 성사나 경제적 결과를 개선하는지는 고객 수요, 가격, 경쟁 조건 등의 요인과 함께 계속 관찰해야 합니다.

5. 문제의 성격에 따라 무엇으로 남길지 결정하기

시험 적용 결과가 그 방법을 뒷받침하면, 어떤 형태로 남길지도 결정해야 합니다.

이 구분은 사용하기 쉽게 하려는 것입니다. 실제 문서는 업무 필요에 맞게 구성하면 됩니다. 간단한 문제는 설명 한 문장이나 양식 한 항목만 바꿔도 될 수 있습니다. 권한과 책임을 바꾸는 일에는 그에 맞는 권한에 따른 결정이 필요합니다. 모든 경험을 제도로 만들 필요는 없습니다.

채택하기로 한 방법은 사람들이 실제로 사용하는 곳에 넣어야 합니다. 해당 표준작업절차(SOP), 가치 기여 역할의 업무 매뉴얼, 훈련 과제, 보조 도구 등이 될 수 있습니다. 사용자는 어디서 시작하고 어떤 상황에서 이를 참고해야 하는지 알아야 합니다.

AI는 기록 취합, 버전 비교, 단계 정리, 누락 점검을 도울 수 있습니다. 사실, 적용 조건, 채택 결정은 업무를 이해하고 해당 책임을 맡은 사람이 여전히 확인해야 합니다. AI 실행 지침(Skill)으로 만들 내용은 안정된 방법을 바탕으로 더 설계하되, 입력과 출력, 적용 한계, 사람이 수행하는 검수 요건을 분명히 해야 합니다.

6. 현행 버전에는 관리자가 필요하며, 사용 중단도 가능해야 하기

채택 이후에 가장 빠뜨리기 쉬운 것은 후속 계획입니다.

각 현행 방법에는 적어도 적용 범위, 버전과 시행일, 관리 책임, 관련 업무에서 접근하는 경로, 다음 재검토 시점이나 재검토를 시작할 조건을 명확히 둘 것을 제안합니다. 업무 조건의 변화, 같은 유형의 예외가 반복되는 상황, 비용의 뚜렷한 증가는 모두 예정일보다 일찍 재검토할 이유가 될 수 있습니다.

재검토 후에는 세 가지 결정을 할 수 있습니다.

계속 사용: 현재 근거가 기존 범위에서의 사용을 여전히 뒷받침합니다. 재검토 기록을 남기고 다음 점검 계획을 분명히 합니다.

수정 후 재시험: 문제는 여전히 해결할 가치가 있지만 조건, 단계, 예외 처리에는 조정이 필요합니다. 새 버전은 먼저 시험 적용 범위를 표시하고, 검증 후 채택 여부를 결정합니다. 전환 기간에는 어떤 업무에 어떤 버전을 쓸지 분명히 해야 합니다.

사용 중단: 방법이 예상한 개선을 가져오지 못하거나, 추가 비용을 감당하기 어렵거나, 적용 조건이 사라진 경우입니다. 일상 업무의 사용 경로에서 제거하고 중단 이유와 효력 발생 시점을 표시해 영향을 받는 역할의 담당자에게 알립니다. 계속 처리해야 할 업무에는 대체 방법이나 상위 책임자에게 넘기는 경로를 제시합니다.

이전 버전은 실제 관리 필요에 따라 보관해 당시의 근거를 추적할 수 있도록 합니다. 보관 위치에는 더 이상 유효하지 않음을 분명히 표시해야 합니다. 과거 자료가 다시 현행 요구사항으로 쓰이지 않도록 하기 위해서입니다. 이미 한 약속과 발생한 책임은 별도로 인계를 마련해야 합니다. 문서의 사용을 중단한다고 함께 없어지는 것은 아닙니다.

좌우로 스크롤하거나 큰 그림을 열어 확인하세요.

큰 그림 열기 ↗편집 가능한 SVG 다운로드 ↓

7. 누가 경험을 일상 업무로 가져올 것인가

자원, 운영·관리, 고객, 자본의 네 생태계에서 여러 역할은 스스로 개선을 제안할 수도 있고 실제 수요에 대응할 수도 있습니다. 누가 어떻게 참여할지는 구체적인 업무 안에서 분명히 해야 합니다.

실행과 협업을 맡은 역할은 실제 작업, 어려움, 예외를 설명합니다. 산출물을 받는 역할은 그것을 이어서 쓰기 편한지 확인합니다. 고객과 협력사의 의견은 변경이 외부에 주는 영향을 파악하도록 돕습니다. 소수 정예의 운영·관리 조직은 해당 의사결정, 규칙, 자원 배치를 맡고 가치 생산, 판매 채널, 고객 관계 사이를 조정합니다. 전문 지식이 필요한 사안은 그에 맞는 사람에게 재검토를 맡겨야 합니다.

관리 담당자는 내용을 정리하고 시험 적용을 추적하며 업데이트를 추진할 수 있습니다. 하지만 한 사람이 모든 역할을 대신해 판단할 수는 없습니다. 변경으로 내부 업무가 줄었더라도 고객의 작성 부담이나 협력사의 확인 부담이 커졌다면 재검토할 때 함께 봐야 합니다.

기여 기록도 남길 수 있습니다. 누가 문제를 발견했고, 누가 근거를 제공했으며, 누가 시험 적용에 참여했고, 누가 효과적인 개선을 완수했는지 기록합니다. 평가나 권익이 관련되면 실제 업무에 맞춰 사전에 명확히 정한 제도로 처리합니다. 경험 기록 하나가 자동으로 어떤 권익을 만들어 내지는 않으며, 수익을 약속하는 것도 아닙니다.

미국 GAO는 2002년 NASA의 경험 학습 체계를 검토하면서, 경험을 수집하고 공유하는 절차가 있어도 이후 임무에 경험이 쓰인다는 보장으로는 충분하지 않다고 지적했습니다.[3] 특정 시기의 역사적 검토이지만, 경험 저장소의 구축과 실제 사용을 따로 확인해야 한다는 점을 떠올리게 합니다.

따라서 경험의 축적을 점검할 때는 남긴 문서 수만 볼 것이 아니라 실제 업무 하나를 골라 살펴봐야 합니다. 사용자가 현행 방법을 찾았는지, 적용 조건을 아는지, 업무를 완수할 수 있는지, 예외가 생긴 뒤 관리와 의사결정 단계로 돌아왔는지를 확인합니다.

반복해서 발생하고 영향이 분명한 문제 하나에서 시작할 수 있습니다. 이번 사실을 확인하고, 적용 한계가 있는 변경안을 제시한 뒤, 적절한 사람에게 시험 적용을 맡기고 다시 돌아와 결정합니다. 다음 업무에 무엇을 쓸 수 있는지, 어디에는 여전히 사람의 판단이 필요한지, 어떤 방법을 거둬야 하는지 모두 분명한 답을 남깁니다.

참고 자료

1. The W. Edwards Deming Institute: PDSA Cycle. 예측, 관찰, 설명의 수정 사이의 관계를 설명하는 자료입니다. 이 글의 네 가지 상태와 여섯 가지 기록 항목은 이 글에서 제안한 방법입니다.
2. Institute for Healthcare Improvement: Testing Changes. 품질 개선 방법 자료입니다. 이 글에서는 작은 범위의 시험 적용, 다른 조건에서의 검증, 효과 없는 시험 적용의 중단이라는 접근을 참고했습니다.
3. U.S. GAO: NASA — Better Mechanisms Needed for Sharing Lessons Learned, GAO-02-195, 2002-01-30. 이 글은 당시의 검토 결론만 인용하며, NASA의 현재 상황을 설명하지 않습니다.

더 읽어 볼 글(선택)

1. 한 번의 거래가 끝난 뒤, 기업에는 무엇이 남을까? — 중국어: 거래 이후의 관계, 협업, 역량 축적을 이해하는 글입니다.

2. 기업 콘텐츠 체계의 표현을 통일하고 계속 업데이트하려면? — 중국어: 지식을 채택한 뒤 관련 자료를 관리하는 문제를 더 살펴보는 글입니다.

연구 설명: 이 글은 초기의 ‘실행–결과–경험의 축적’ 연구 흐름을 이어 갑니다. 《SOP 정리·설계 방법론》에 있는 시험 적용, 피드백, 반복 개선, 버전 관리에 관한 구상을 참고해 실제 업무에서 검증할 방법을 제안합니다. 예시는 가상이며, 그림은 제안하는 구조입니다. 이 글의 방법을 기업에서 직접 검증한 데이터는 아직 없습니다.