업무·역량·프로세스·정보 흐름 분석

미션·가치사슬·역량·외부환경의 활동 연결과 실제 능력이 선수 설명이다. 현재 업무는 정상·반려 흐름, 계산은 10건의 처리·대기와 별도 단계별 용량을 따라 확인한다.

업무·역량·프로세스·정보 흐름 분석

접수는 빨라졌는데 수리 완료는 왜 그대로일까

생활가전 수리센터가 접수 화면을 바꾸어 입력 시간을 줄였다. 접수 담당자는 편해졌지만 고객에게 제품을 돌려주는 시점은 거의 달라지지 않았다. 진단 대기가 길고, 진단에 필요한 정보가 부족하면 접수로 되돌아오는 일이 남아 있었기 때문이다.

이때 필요한 것은 더 빠른 화면을 한 번 더 사는 일이 아니다. 고객의 문제가 해결될 때까지 어떤 일이 이어지고, 어디에서 기다리거나 다시 일하며, 어떤 정보가 누구에게 전달되지 않는지 확인해야 한다. 업무와 정보의 흐름을 알아야 기술 개선을 정확한 지점에 적용할 수 있다.

이 장의 ‘한길수리센터’, 처리 기록·인원·시간·금액은 모두 자체 교육 사례다. 실제 수리업체의 운영 실적이나 제품별 수리 방법이 아니다. 이 절은 업무·정보의 근거를 만든다. 다음 애플리케이션·인프라 현황분석은 이를 지원하는 기술을 대조하고, 개선과제·대안·전환·효과는 실행과 효과 판단을 연결한다.

먼저 연결할 앞선 설명

가치사슬과 역량은 활동의 연결과 반복해서 결과를 만드는 능력을 구별했다. 아키텍처의 네 영역은 업무 약속을 자료·프로그램·운영 기반에 연결했다. 여기서는 새 목표를 먼저 그리지 않고 현재의 실제 흐름과 그 근거부터 확인한다.

1. 업무·역량·프로세스·조직도는 서로 다른 질문에 답한다

업무는 조직의 목적을 위해 수행하는 활동이다. 프로세스는 특정 사건이나 입력에서 출발하여 정해진 결과를 만들기까지 활동·판단·인계가 이어지는 흐름이다. 역량은 그 일을 반복해서 수행할 수 있는 능력으로, 특정 부서명이나 현재 처리 순서와 같지 않다.

한길수리센터에서 ‘고장을 판별한다’는 필요한 역량이다. 누가 어떤 정보를 받아 검사하고 반려·승인하는지는 프로세스다. ‘진단팀’은 조직의 배치다. 부서 이름이 같아도 실제 수행능력과 인계 방식은 다를 수 있다.

분석의 시작과 끝을 먼저 정한다. 이 사례의 범위는 ‘센터가 제품과 요청을 인수한 시점부터 수리 또는 반환 결과를 고객에게 인계한 시점까지’다. 고객이 방문하기 전의 탐색이나 외부 운송은 별도 경계로 표시한다. 센터 안의 처리만 측정했으면서 고객의 전체 소요시간이라고 보고하지 않는다.

정상 수리만 포함할지, 수리 불가·취소·부품 대기·재수리도 포함할지 정해야 한다. 어려운 사례를 제외한 분석이라면 제외 기준과 건수를 남긴다. 불편한 사례를 빼서 평균을 낮추는 것은 개선이 아니다.

2. 전체 경계를 먼저 잡고 세부 순서를 그린다

SIPOC은 공급자(Supplier), 입력(Input), 프로세스(Process), 출력(Output), 고객(Customer)을 한 범위에서 정리하는 도구다. ASQ는 이를 상세 흐름도 전에 관련 요소와 경계를 수집하는 높은 수준의 관점으로 설명하며 제약·측정도 함께 고려한다.¹

한길수리센터의 자체 경계표는 다음과 같다. 공급자와 고객은 외부 회사만을 뜻하지 않으며 같은 사람이 입력을 제공하고 결과를 받는 역할을 모두 맡을 수 있다.

이 표가 있다고 작업 순서가 검증된 것은 아니다. 경계를 합의한 뒤 실제 사례를 따라가며 담당자와 시스템의 행동을 확인한다. 작업 매뉴얼은 ‘해야 하는 방식’, 인터뷰는 ‘기억하는 방식’, 기록은 ‘남겨진 행동’이다. 세 자료가 다르면 어느 하나를 무조건 정답으로 삼지 않고 불일치를 조사한다.

정상 경로뿐 아니라 되돌아오는 경로를 그린다

정보 부족은 접수 보완 뒤 진단에서 재확인 · 상태 따라가기

제품 요청의 식별·필수 정보와 인수 자료를 확인한다. 모든 단계에서 같은 수리 사건·인수·처리 근거의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

화살표는 업무의 다음 행동과 반려 경로다. 접수번호·필수 자료를 인수한 진단에서 정보가 충분한지 확인한다. 부족하면 접수를 보완하고 다시 진단하며, 진단 결과가 확인된 뒤 수리 또는 반환을 결정한다. 전송 성공과 업무 인수, 처리 완료와 고객 인계를 구별한다.

이 예의 조건

• 화살표는 업무의 다음 행동과 반려 경로다. 접수번호·필수 자료를 인수한 진단에서 정보가 충분한지 확인한다. 부족하면 접수를 보완하고 다시 진단하며, 진단 결과가 확인된 뒤 수리 또는 반환을 결정한다. 전송 성공과 업무 인수, 처리 완료와 고객 인계를 구별한다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원 그림의 모든 대상과 설명

대상	원 설명
대상제품·요청 접수	원 설명식별·필수 정보 확인
대상진단	원 설명증상·인수 자료 확인
대상정보 충분?	원 설명진단 결과
대상접수 보완	원 설명같은 사건·자료 재확인
대상수리 또는 반환	원 설명처리 결정·확인
대상고객 인계·결과 기록	원 설명이후 문의의 근거

원 그림의 모든 관계와 조건

연결	원 라벨·방향
연결제품·요청 접수 → 진단	원 라벨·방향라벨 없는 연결 / 정방향 / 실선
연결진단 → 정보 충분?	원 라벨·방향라벨 없는 연결 / 정방향 / 실선
연결정보 충분? → 수리 또는 반환	원 라벨·방향충분·확인 / 정방향 / 실선
연결정보 충분? → 접수 보완	원 라벨·방향정보 부족 / 정방향 / 실선
연결접수 보완 → 진단	원 라벨·방향보완 후 재진단 / 정방향 / 점선
연결수리 또는 반환 → 고객 인계·결과 기록	원 라벨·방향라벨 없는 연결 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
접수·진단 제품 요청의 식별·필수 정보와 인수 자료를 확인한다.	값·보충 정보 같은 수리 사건: 접수→진단 인수·처리 근거: 정보 충분성 확인	변화·이유 보냈다는 사실과 담당자의 실제 인수는 다르다.
정보 부족 진단에 필요한 정보가 부족하면 같은 사건을 보완한다.	값·보충 정보 같은 수리 사건: 접수 보완 인수·처리 근거: 부족 원인 기록	변화·이유 부족 상태를 정상 수리 결정으로 넘기지 않는다.
재진단 보완한 자료를 다시 검사해 충분한 진단으로 잇는다.	값·보충 정보 같은 수리 사건: 같은 사건 재진단 인수·처리 근거: 보완 정보 확인	변화·이유 보완 완료 보고가 재확인을 대신하지 않는다.
수리·반환·인계 확인한 결과로 수리 또는 반환을 결정하고 고객 인계 근거를 남긴다.	값·보충 정보 같은 수리 사건: 처리→고객 인계 인수·처리 근거: 실제 결과 기록	변화·이유 이 그림은 프로그램 메시지 전송 순서를 보장하지 않는다.

정보 부족은 접수 보완 뒤 진단에서 재확인 · 상태 따라가기

제품 요청의 식별·필수 정보와 인수 자료를 확인한다. 모든 단계에서 같은 수리 사건·인수·처리 근거의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

화살표는 업무의 다음 행동과 반려 경로다. 접수번호·필수 자료를 인수한 진단에서 정보가 충분한지 확인한다. 부족하면 접수를 보완하고 다시 진단하며, 진단 결과가 확인된 뒤 수리 또는 반환을 결정한다. 전송 성공과 업무 인수, 처리 완료와 고객 인계를 구별한다.

이 예의 조건

• 화살표는 업무의 다음 행동과 반려 경로다. 접수번호·필수 자료를 인수한 진단에서 정보가 충분한지 확인한다. 부족하면 접수를 보완하고 다시 진단하며, 진단 결과가 확인된 뒤 수리 또는 반환을 결정한다. 전송 성공과 업무 인수, 처리 완료와 고객 인계를 구별한다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원 그림의 모든 대상과 설명

대상	원 설명
대상제품·요청 접수	원 설명식별·필수 정보 확인
대상진단	원 설명증상·인수 자료 확인
대상정보 충분?	원 설명진단 결과
대상접수 보완	원 설명같은 사건·자료 재확인
대상수리 또는 반환	원 설명처리 결정·확인
대상고객 인계·결과 기록	원 설명이후 문의의 근거

원 그림의 모든 관계와 조건

연결	원 라벨·방향
연결제품·요청 접수 → 진단	원 라벨·방향라벨 없는 연결 / 정방향 / 실선
연결진단 → 정보 충분?	원 라벨·방향라벨 없는 연결 / 정방향 / 실선
연결정보 충분? → 수리 또는 반환	원 라벨·방향충분·확인 / 정방향 / 실선
연결정보 충분? → 접수 보완	원 라벨·방향정보 부족 / 정방향 / 실선
연결접수 보완 → 진단	원 라벨·방향보완 후 재진단 / 정방향 / 점선
연결수리 또는 반환 → 고객 인계·결과 기록	원 라벨·방향라벨 없는 연결 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
접수·진단 제품 요청의 식별·필수 정보와 인수 자료를 확인한다.	값·보충 정보 같은 수리 사건: 접수→진단 인수·처리 근거: 정보 충분성 확인	변화·이유 보냈다는 사실과 담당자의 실제 인수는 다르다.
정보 부족 진단에 필요한 정보가 부족하면 같은 사건을 보완한다.	값·보충 정보 같은 수리 사건: 접수 보완 인수·처리 근거: 부족 원인 기록	변화·이유 부족 상태를 정상 수리 결정으로 넘기지 않는다.
재진단 보완한 자료를 다시 검사해 충분한 진단으로 잇는다.	값·보충 정보 같은 수리 사건: 같은 사건 재진단 인수·처리 근거: 보완 정보 확인	변화·이유 보완 완료 보고가 재확인을 대신하지 않는다.
수리·반환·인계 확인한 결과로 수리 또는 반환을 결정하고 고객 인계 근거를 남긴다.	값·보충 정보 같은 수리 사건: 처리→고객 인계 인수·처리 근거: 실제 결과 기록	변화·이유 이 그림은 프로그램 메시지 전송 순서를 보장하지 않는다.

화살표는 업무의 다음 행동 또는 반려 흐름이다. 실제 메시지 전송 방식이나 프로그램 호출 순서를 표현한 그림은 아니다. 접수에서 진단으로 넘길 때 무엇을 전달하고, 진단 담당이 무엇을 확인해야 인수한 것으로 보는지 정한다. 보완한 정보는 진단에서 다시 확인하고, 그 결과를 거쳐 처리 결정을 내린다.

‘진단으로 보냈다’와 ‘진단 담당이 필요한 자료를 받아 작업을 시작할 수 있다’는 다르다. 전달한 파일이 열리지 않거나 제품과 접수번호가 연결되지 않으면 시스템 전송은 성공했어도 업무 인계는 실패한 것이다. 이 차이를 보려면 인계 전후의 입력 조건과 수신 결과를 대조해야 한다.

GOV.UK의 전체 사용자 여정 안내는 화면 내부뿐 아니라 온라인·오프라인 접점과 뒤쪽 조직의 처리가 연결되는지를 보도록 한다. 여기서는 그 관점을 적용해 고객의 경험과 내부 처리를 함께 확인하되, 자체 흐름도를 영국 공공서비스의 의무 절차로 표시하지 않는다.²

3. 정보 흐름은 선만 그리는 것이 아니라 의미와 책임을 확인하는 일이다

같은 제품을 접수팀은 접수번호로, 진단팀은 임시 작업번호로, 출고팀은 고객 이름으로 식별하면 이력이 어긋날 수 있다. 고객 이름이 같다는 이유만으로 같은 사건이라고 결합해서는 안 된다. 한 처리 사건을 구별할 식별자와 변환·참조 관계가 필요하다.

정보를 복사한 곳을 모두 기준 원천으로 취급하지 않는다. 진단 결과를 받은 조회 화면이 늦게 갱신됐다고 원래 진단 결과를 임의로 덮어쓰면 안 된다. 필요한 자료의 의미·원천·갱신시각·권한과 수신처를 기록하고 정정이 어디까지 전달되는지 확인한다.

이 분석은 데이터베이스의 모든 열을 먼저 설계하자는 뜻이 아니다. 현재 문제에 필요한 사실과 상태를 찾되 개인정보·비밀정보를 불필요하게 분석 대장에 복제하지 않는다. 근거의 위치와 사건 연결을 기록하면 원자료 전체를 옮기지 않고도 판단을 추적할 수 있다.

4. 실제 기록으로 흐름을 확인하는 방법

최소한 사건 식별자, 활동, 시작·종료 시각, 상태, 담당 역할과 근거 위치를 맞춘다. 시계·시간대가 다른 시스템을 비교할 때에는 기준을 정하고 오차를 확인한다. 종료 시각이 비어 있다고 처리시간을 0으로 만들지 않는다. 누락인지 진행 중인지 구별해야 한다.

이벤트 로그는 어떤 사건에서 어떤 활동이 언제 일어났는지 남긴 기록이다. 이를 분석하면 매뉴얼과 다른 실제 경로, 반복 방문, 대기 구간의 후보를 찾을 수 있다. 다만 로그에 남지 않는 전화·수작업이 있거나 같은 사건의 식별자가 끊기면 관측된 경로가 전체 업무를 대표하지 못한다.

센터에서는 정상 처리, 반려, 취소, 부품 대기와 아직 끝나지 않은 사례를 나누어 본다. 특정 시간대·담당자·제품군만 선택했는지도 표시한다. 예외를 없애 보기 좋은 한 줄을 만드는 대신, 예외가 언제 왜 발생하며 누구에게 일이 돌아가는지 설명한다.

여러 자료가 같은 사건을 가리키는지 대조한 뒤 결론을 적는다. “직원이 입력을 잘못했다”는 설명이 있더라도 화면에서 필요한 항목이 무엇인지 알 수 없거나 단계마다 요구가 달라진다면 개인 교육만으로 해결되지 않을 수 있다.

5. 따라 계산: 처리시간 34분과 전체 소요 136분

자체 기록 IS-B1은 같은 분석 범위에 들어온 10건을 끝날 때까지 확인한 집단이다. 취소·부품 대기·동시 작업은 이번 단순 계산에서 없고, 한 사건의 단계는 겹치지 않는다고 가정한다. 처리시간은 실제 작업한 시간, 대기시간은 그 외 기다린 시간이며 전체 소요시간은 둘의 합이다.

표의 각 행은 같은 값을 가진 사례를 묶어 표시했다. 실제 평균을 구할 때에는 집단별 평균을 단순 평균하지 않고 건수로 가중한다.

총 처리시간은 8×30+2×50=340분, 총 대기시간은 8×90+2×150=1,020분이다. 합계 1,360분을 10건으로 나누면 평균 전체 소요는 136분이다. 평균 처리 34분과 평균 대기 102분의 합으로도 같은 값을 얻는다.

이번 집단의 전체 소요 중 대기 비율은 1,020/1,360=75%다. 그러나 ‘75%가 모두 제거할 낭비’라는 결론은 아니다. 승인 조건·부품·업무시간 같은 제약에 따른 대기와 전달 누락·일괄 처리 같은 개선 가능한 원인을 나누어 확인해야 한다.

첫 흐름에서 끝난 비율을 이 사례의 최초 통과율이라고 하면 8/10=80%다. 최종 완료는 10/10=100%이므로 둘은 다른 지표다. 재작업을 했어도 결국 완료했다는 이유로 첫 통과 실패를 지우면 반복 비용이 보이지 않는다.

정상 8건만 보고 평균 120분이라고 보고하면 전체 평균 136분보다 16분 낮게 보인다. 이는 새 기술의 효과가 아니라 어려운 두 건을 분석에서 빼서 생긴 차이다. 완료된 건만 남기고 미완료 사건을 제외할 때도 비슷한 선택 문제가 생길 수 있으므로 전체 유입과 미완료 상태를 함께 보고한다.

6. 따라 계산: 가장 빠른 단계가 전체 처리량을 정하지 않는다

IS-B2는 IS-B1과 별개의 단순 용량 모형이다. 각 단계에 전담 작업자 한 명이 있고 모든 사건이 네 단계를 한 번씩 순서대로 거친다고 하자. 단계 사이에는 필요한 대기 공간이 있고, 교대·고장·재작업·작업시간 변동은 없으며, 초기 채움이 끝난 정상 가동구간의 이론적 용량을 비교한다.

이 직렬 흐름의 용량 상한은 가장 낮은 진단 단계의 10건/시간이다. 이처럼 정한 조건에서 전체 흐름의 처리능력을 제한하는 지점을 병목이라고 한다. 실제 병목은 수요 구성·설비·인력·규칙이 바뀌면 달라질 수 있다.

접수를 3분에서 1분으로 줄이면 접수 용량은 20건에서 60건/시간으로 늘어난다. 그래도 진단 10건/시간은 그대로여서 전체 용량 상한은 10건/시간이다. 접수 담당의 부담 감소는 가치가 있을 수 있지만 전체 수리 처리량이 세 배가 됐다고 보고할 수 없다.

이 구간에 시간당 12건이 계속 들어오고 완료가 최대 10건이라면 미처리 건수는 시간당 적어도 2건씩 늘어난다. 일반적으로 기간 말 미처리는 기간 초 미처리+새 유입−완료−정의한 다른 종료로 대사한다. 이 보존 관계만으로 각 고객의 정확한 대기시간을 계산한 것은 아니다. 대기가 계속 쌓이는 상태를 안정된 정상상태라고 가정해서도 안 된다.

진단 작업자를 동일한 능력의 두 명으로 늘리고 서로 독립적으로 일할 수 있다면 그 단계의 용량은 20건/시간이 될 수 있다. 그다음 제한은 수리 15건/시간으로 옮겨간다. 실제로 병렬 처리가 가능한지, 장비·승인·자료가 또 다른 제약인지 확인해야 한다. 한 지점의 개선 후 전체 흐름을 다시 보는 이유다.

7. 증상·원인 가설·개선안을 분리한다

‘진단 대기가 길다’는 증상이다. ‘필수정보가 부족해서 반려된다’, ‘일괄 전달 때문에 특정 시간에 몰린다’, ‘진단 설비가 부족하다’는 서로 다른 원인 가설이다. ‘AI를 도입한다’나 ‘서버를 늘린다’는 그 뒤에 비교할 해법이며 원인 설명 자체가 아니다.

원인 질문을 반복하는 것은 도움이 되지만 횟수를 채웠다고 원인이 증명되는 것은 아니다. 다른 설명으로도 같은 현상이 생기는지 살핀다. 필요한 경우 한정된 범위에서 조건을 바꾸어 관찰하고, 그 변화가 다른 집단에 부담을 넘겼는지도 확인한다.

역량 관점에서는 ‘진단 프로그램이 있느냐’보다 ‘필요 정보를 받아 판단하고 예외를 처리하며 결과를 설명할 수 있느냐’를 묻는다. 사람의 숙련, 승인·인계 절차, 데이터 의미와 도구가 함께 작동해야 한다. 조직도를 바꾸거나 교육 횟수를 늘린 것만으로 능력이 확보됐다고 세지 않는다.

8. 현행 분석 결과를 실제 개선 질문으로 넘긴다

자체 분석안 IS-B3은 제품 인수부터 결과 인계까지의 범위를 유지한다. 정상·재작업·미완료를 분리하고 같은 사건 식별자로 업무·정보를 연결한다. 현재는 접수 화면 확대보다 진단에 도달하는 정보·인계와 작업 제약을 우선 조사한다. 전체 용량을 확인하지 않은 접수 자동화만으로 처리시간 목표 달성을 약속하는 안은 기각한다.

접수 담당은 입력과 반려를, 진단 담당은 인수 조건·작업·설비를, 수리·인계 담당은 후속 영향과 실제 종료를 확인한다. 분석 담당은 범위·시계·누락·분모를 점검하고 센터 책임자가 역할 충돌을 결정한다. 산출물은 경계표, 정상·예외 흐름, 정보·책임 대장, 사건별 시간과 미완료 대사, 원인 가설·반증 목록이다.

개선 후보에는 불필요한 중복 입력의 제거, 인계 기준의 일치, 처리 순서의 변경, 설명·교육 보완과 필요한 기술 변경이 모두 들어갈 수 있다. 기존 과정의 모든 단계를 그대로 자동화하는 것이 유일한 개선은 아니다. 다만 확인·승인 단계를 줄일 때 그 단계가 지키던 보호·품질 조건까지 사라지지 않는지 확인한다.

다음 절에서는 이 업무를 실제로 지원하는 프로그램·자료·인프라·계약을 대조한다. 현행 분석은 원인과 대안을 좁힐 근거이지 아직 새 시스템의 설계 승인이나 실제 효과의 입증이 아니다.

9. 자체 10점 문제와 완성 답안

IS-B1의 전체 소요시간과 최초 통과율을 계산하고, IS-B2에서 접수 단계 개선만으로 전체 처리량이 늘지 않는 이유를 설명하시오.

지표의 정의→가중 계산→병목→개선 해석의 순서로 답한다. 두 자료가 별도의 교육 모형임을 유지한다.

답안 목차·풀이·교정 근거 보기

목차: 대상·분모 → 처리·대기·재작업 → 단계별 용량 → 개선 조건.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

IS-B2는 전담 작업자 1명·직렬 처리 1회·변동/고장/재작업 없는 정상 가동을 가정한다. 단계별 용량 중 가장 작은 10건/시간이 전체 상한이다. 접수만 1분으로 줄여도 진단 용량 10건/시간은 유지된다. 진단 작업자가 2명으로 늘어 용량이 20건/시간이 되면 수리 용량 15건/시간이 다음 제한이다.

완성 답안

IS-B1은 같은 범위의 10건을 끝까지 관찰한 자료다. 처리 합계는 8×30+2×50=340분, 대기는 8×90+2×150=1,020분이므로 평균 전체 소요는 1,360/10=136분이다. 최초 통과는 8/10=80%이며 최종 완료 100%와 구별한다. 정상 8건만의 120분을 전체 평균으로 쓰지 않는다.

IS-B2의 접수·진단·수리·인계 용량은 각각 20·10·15·30건/시간이다. 변동·고장·재작업이 없는 직렬 정상 가동 가정에서 전체 상한은 진단 용량 10건/시간이다. 접수를 1분으로 줄여 용량이 60건/시간이 되어도 진단 제약은 남으므로 전체 처리량이 세 배가 되지 않는다.

대기 75%를 모두 제거 가능한 낭비로 단정하지 않고 입력·인계·규칙·설비 가설을 사건 기록으로 확인한다. 시간당 유입이 12건으로 계속되면 완료가 10건인 조건에서는 미처리가 쌓이므로 전체 흐름과 예외·자원 제약을 함께 개선해야 한다.

10. 자체 25점 문제와 완성 분석안

한길수리센터의 정보시스템 개선을 위한 업무·역량·프로세스·정보 흐름 분석안 IS-B3을 설계하시오. 범위·근거·예외·측정·원인 가설과 담당 산출물을 포함하시오.

조직도나 화면 목록을 나열하지 않는다. 무엇을 실제로 조사하고 어떤 결론을 아직 확정하지 않을지가 답안에 들어가야 한다.

답안 목차·풀이·교정 근거 보기

목차: 경계와 관점 → 사건·정보의 근거 → 계산·원인 → 책임·인계 산출물.

경계와 같은 사건·정보·예외를 정상·반려·재확인에 연결하는 관계를 관계 그림에서 함께 읽고, 아래 완성 답안에서 조건과 판단을 확인한다. 처리·대기·재작업의 계산과 별도 용량 모형을 대조한 뒤 원인 경쟁 가설과 담당·산출물로 다음 분석에 인계한다.

완성 분석 답안

분석 범위는 제품·요청 인수부터 처리 결과의 고객 인계까지로 정한다. 필요한 식별·진단·수리·인계 역량을 조직도와 구별하고, SIPOC 방식으로 입력·출력·공급자·고객·제약·측정을 정리한다. 정상 수리뿐 아니라 보완·재작업·취소·미완료의 포함 여부와 제외 건수를 남긴다.

매뉴얼·면담·현장·사건 로그를 같은 사건 식별자와 기준시각으로 대조한다. 접수번호·증상·진단 결과·처리 상태·인계 결과에 생성 책임, 사용하는 곳, 원천·사본과 갱신 조건을 연결한다. ‘보냄’과 ‘인수 가능’, ‘처리 완료’와 ‘고객 인계’를 구별하고 시계·식별자·기록 누락을 0이나 성공으로 바꾸지 않는다.

IS-B1은 평균 136분·최초 통과 80%·대기비율 75%이며 재작업 제외로 평균을 낮추지 않는다. 별도 IS-B2의 용량 상한은 진단 10건/시간으로 접수 자동화만으로 전체 처리량 개선을 약속하지 않는다. 필수정보 누락, 일괄 인계, 규칙 불일치, 설비·인력 제약을 경쟁 가설로 놓고 사건별 반려·전송·인수·작업 기록으로 확인한다. 대기시간 전체를 제거 가능한 낭비로 단정하지 않는다.

접수·진단·수리·인계 담당은 해당 입력·결과와 예외를 확인하고 분석 담당은 분모·누락·시각을 관리한다. 센터 책임자는 역할 충돌과 조사 범위를 결정한다. 경계표·예외 흐름·정보 책임 대장·사건 시간·미완료 대사·가설 목록을 다음 애플리케이션·인프라 분석에 넘긴다. 근거 없는 원인 확정과 접수 화면만의 자동화는 보류하고, 필요한 보호·품질 조건을 유지하는 업무·기술 대안을 비교한다.

11. 자기교정

조건 변경

재작업 없이 열 건 모두 120분에 끝났다면? 바뀐 조건과 유지할 분모·범위를 먼저 적는다.

조건 변경의 계산·교정 근거 보기

평균 120분·최초 통과 100%이며 원래 136분 대비 16분 감소다. 같은 범위·대상·완료 정의가 유지됐는지를 확인해야 개선 효과 비교가 가능하다. 시간 계산의 분모를 유지한다.

진단을 두 명이 수행할 수 있지만 수리가 한 명이라면? 바뀐 조건과 유지할 분모·범위를 먼저 적는다.

조건 변경의 계산·교정 근거 보기

다른 가정이 같을 때 진단 20·수리 15가 되어 다음 병목은 수리다. 이론적 상한 15와 실제 도착·고장·품질을 구별한다. 용량 모형을 전체 흐름에서 다시 적용한다.

한 사건이 다른 시스템에서 새 번호를 받으면? 바뀐 조건과 유지할 분모·범위를 먼저 적는다.

조건 변경의 계산·교정 근거 보기

원래 사건과 새 번호의 연결을 확인한다. 새 사건으로 중복 집계하거나 기록을 강제로 합치지 않고 변환 근거와 연결 실패를 남긴다. 정보 흐름의 의미·식별자부터 대조한다.

회독의 핵심

개선할 대상의 경계와 결과를 먼저 정하고 업무·역량·프로세스·조직을 구별한다. 정상과 예외를 같은 사건·정보로 따라가며 처리·대기·재작업·미완료를 나누어 본다. 부분 속도와 전체 용량, 증상과 원인 가설을 구별한 근거가 다음 시스템 분석과 개선안의 출발점이다.

근거와 사용 범위

IS-B1~B3의 시간·용량·대사·도식·답안은 명시된 가정에서 자체 작성·산술 대조한 자료다. 실제 프로세스 마이닝 도구 실행, 현장 조사, 통계적 인과효과 또는 사람 독립 승인을 수행한 결과가 아니다. 실제 적용에는 현장 범위·품질·기록의 추가 확인이 필요하다.

Footnotes

1. ASQ, SIPOC+CM Diagram, 정의·사용 시점·경계 및 구성요소 설명. 2026-09-20 공개 본문 대조. 원문 예제·도식을 복제하지 않았으며 한길수리센터 표는 자체 작성이다. https://asq.org/quality-resources/sipoc ↩

2. GOV.UK Service Manual, Map and understand a user's whole problem, 사용자 관점과 제공 조직의 관점, 온라인·오프라인 접점 및 연결의 설명. 2026-09-20 대조. 특정 공공서비스 사례나 영국의 운영 의무는 복제하지 않았다. https://www.gov.uk/service-manual/design/map-a-users-whole-problem ↩