프로세스 부채

같은 문제, 매번 다른 대응

C사(정밀화학)의 한 분기를 들여다보자. 고객사로부터 "입고 원료의 수분 함량 규격 이탈" 클레임이 세 번 들어왔다.

• 1월 건: 영업 담당이 메일을 받아 품질팀장에게 전달했다. 팀장이 회의를 소집했고, 결과는 PPT 13장짜리 보고서로 정리되었다. 고객 회신까지 3주.
• 2월 건: 고객이 품질 담당자에게 직접 전화했다. 담당자가 생산팀과 메신저로 원인을 확인하고, 엑셀 한 시트에 원인과 대책을 적어 회신했다. 고객 회신까지 4일. 생산팀장은 이 건을 나중에야 알았다.
• 3월 건: 임원 보고가 먼저 이루어지면서 임시 TF가 꾸려졌다. TF는 자체 양식으로 8D를 썼다. 고객 회신은 빨랐지만 TF가 해산된 뒤 대책 이행 여부를 아무도 추적하지 않았다.

세 건 모두 "어떻게든" 해결되었다. 그러나 세 건의 원인과 대책을 나란히 놓고 비교할 수 없다. 보고서 형식이 다르고, 원인 분류가 다르고, 대책 이행을 확인한 기록이 있는 건도 있고 없는 건도 있다. 4월에 같은 클레임이 다시 오면, 담당자는 또 처음부터 시작한다.

AX 관점에서 프로세스 부채가 특히 치명적인 이유는 단순하다. AI에게 일을 맡기려면 "이 단계에서 무엇을 입력받아 무엇을 내놓는가"가 정의되어 있어야 한다. 매번 다른 흐름에는 맡길 단계가 없고, 매번 다른 산출물로는 AI가 과거 사례를 학습하거나 비교할 수 없다.

표준이 닿는 곳과 닿지 않는 곳

제조 조직은 표준이 부족한 곳이 아니다. 품질경영시스템과 문제 해결 기법은 오래전부터 잘 정리되어 있다.

그런데 이 표준들은 주로 공식적이고 반복되는 핵심 프로세스를 덮는다. 실제로 일이 무너지는 곳은 그 사이, 표준이 닿지 않는 회색지대다.

• 부서 간 인계: 품질팀이 원인을 찾아 생산팀에 대책 이행을 요청하는 순간, 요청은 메일 한 통이 된다. 수락했는지, 언제까지 하는지, 했는지 확인하는 절차가 없다.
• 임시 TF: 중대 이슈마다 TF가 꾸려지고 TF마다 자기 양식을 만든다. TF가 해산되면 산출물은 TF장의 PC에 남는다.
• 고객 대응 초기: 공식 8D가 시작되기 전 며칠간, 고객과의 첫 통화·첫 메일에서 중요한 사실과 약속이 오가지만 기록 위치가 정해져 있지 않다.
• 내부 보고: 같은 이슈를 팀장 보고용, 임원 보고용, 고객 회신용으로 각각 다시 만든다. 셋의 숫자가 미묘하게 다르다.

프로세스 마이닝: 로그로 실제 흐름 보기

프로세스를 개선하려면 먼저 실제로 일이 어떻게 흘러가는지 알아야 한다. 워크숍에서 화이트보드에 그린 흐름도는 "그래야 하는 흐름"이지 "실제 흐름"이 아니다. 프로세스 마이닝(process mining)은 시스템에 남은 기록으로 실제 흐름을 복원하는 기법이다. 필요한 것은 세 개의 열이 있는 이벤트 로그(event log)다.

같은 케이스 ID의 활동을 시간순으로 늘어놓으면 그 케이스가 지나간 경로가 된다. 수백 개 케이스의 경로를 겹치면 다음이 보인다.

• 변종(variant): 활동 순서가 똑같은 케이스들의 묶음. 표준이 잘 지켜지면 소수의 변종에 대부분의 케이스가 몰리고, 프로세스 부채가 크면 변종 수가 케이스 수에 가까워진다.
• 재작업 루프(rework loop): 같은 활동이 한 케이스에서 반복되는 것. 원인분석 → 자료요청 → 원인분석, 승인 → 반려 → 대책수립.
• 병목(bottleneck): 활동 사이의 대기 시간이 길게 쌓이는 곳. 대부분 부서 간 인계 지점이다.

제조 조직에서 이 로그를 얻는 것이 첫 번째 난관이다. 이슈 대응의 상당 부분이 메일과 메신저에서 일어나기 때문에 시스템에 타임스탬프가 남지 않는다. 그래서 프로세스 마이닝을 하려는 시도 자체가 "어떤 활동을 시스템에 남길 것인가"라는 표준화 질문으로 이어진다. 아래 시뮬레이터는 가상의 이슈 대응 로그를 생성해 표준화 수준에 따라 흐름이 어떻게 달라지는지 보여 준다.

8D를 다시 보기: 단계마다 무엇이 남아야 하나

8D는 제조 현장에 가장 널리 퍼진 문제 해결 절차다. 그런데 많은 조직에서 8D는 "고객에게 제출하는 보고서 양식"으로만 쓰인다. 고객이 요구할 때 칸을 채우고, 칸을 채우는 데 필요한 정보는 메일과 엑셀에서 긁어모은다. 이렇게 쓰면 8D는 프로세스가 아니라 문서가 된다.

8D를 프로세스로 쓰려면 단계마다 무엇이 데이터로 남아야 하는지를 정해야 한다. 그래야 다음 이슈 때 과거 8D를 검색하고 비교할 수 있고, AI가 각 단계를 도울 수 있다. 아래에서 단계를 하나씩 눌러 보자.

산출물 폭발: 양식은 어떻게 불어나는가

프로세스 부채는 산출물 양식의 수로도 드러난다. 이슈 유형(품질, 설비, 공급, 고객 클레임, 안전…)마다, 팀마다, 담당자마다 양식이 조금씩 다르다. 여기에 "이번 건은 임원 보고가 필요하니까" 새로 만든 일회성 양식이 더해진다. 양식이 많으면 세 가지 비용이 생긴다.

• 작성 비용: 담당자는 매번 "이번엔 어떤 양식이지?"부터 묻는다.
• 비교 불가: 서로 다른 양식으로 쓴 두 이슈는 같은 항목을 같은 이름으로 갖고 있지 않아 나란히 놓을 수 없다.
• AI 학습 불가: AI가 과거 보고서로 초안을 쓰려 해도 참고할 "같은 모양"의 사례가 적다.

해결책은 모든 것을 하나로 통일하는 것이 아니라 공통 핵심 + 유형별 확장이다. 모든 이슈가 같은 핵심 필드(무엇이, 어디서, 언제, 얼마나, 누가, 상태)를 갖고, 유형별로 필요한 필드만 덧붙인다.

표준 대응 흐름과 이슈 카드

프로세스 부채를 갚는 핵심 도구는 두 가지다. 하나는 표준 대응 흐름(어떤 순서로, 누가, 어떤 관문을 거쳐 처리하나), 다른 하나는 표준 산출물(무엇을 남기나)이다. 이 책은 표준 산출물의 기본 단위를 이슈 카드라고 부른다. 메일·PPT·엑셀에 흩어지던 이슈 정보를 한 장의 구조화된 기록으로 모은 것이다.

이슈 카드가 있으면 2장에서 메일 스레드에 묻혀 있던 결정·수치·기한·담당·근거가 처음부터 제자리를 갖는다. 그리고 "같은 문제는 같은 양식으로"라는 원칙이 지켜지면, AI는 과거 카드에서 유사 사례를 찾고(6장), 8D 초안을 같은 모양으로 쓰고, 미완료 대책을 추적하는 일을 맡을 수 있다(10장).

• 공통 핵심 필드는 10개 안팎으로 시작한다. 많으면 아무도 채우지 않는다.
• 불량 코드·설비 ID·품번은 자유 입력이 아니라 기준정보에서 고르게 한다(4장).
• 근거는 첨부가 아니라 원본 위치 링크로 남긴다. 첨부는 복사본을 만든다.
• 임원 보고·고객 회신 문서는 카드에서 생성한다. 숫자를 다시 타이핑하지 않는다.
• 카드의 상태 변경이 곧 이벤트 로그가 되도록 한다. 그러면 프로세스 마이닝이 저절로 가능해진다.

SIPOC, RACI, 프로세스 오너

표준 흐름과 이슈 카드를 만들려면 먼저 프로세스의 경계와 책임을 정해야 한다. 이때 쓰는 가벼운 도구가 SIPOC과 RACI다.

SIPOC: 프로세스의 경계를 한 장으로

SIPOC은 공급자(Supplier)–입력(Input)–프로세스(Process)–출력(Output)–고객(Customer)의 머리글자다. 프로세스를 5~7단계로만 요약하고, 무엇이 들어와 무엇이 나가는지를 적는다. 회색지대의 인계가 여기서 드러난다.

RACI: 누가 무엇을 책임지나

RACI는 활동마다 실행 담당(Responsible), 최종 책임(Accountable), 사전 협의(Consulted), 사후 통보(Informed)를 정하는 표다. 원칙은 활동마다 A는 정확히 한 명(한 조직)이다. A가 없거나 둘이면 그 활동이 회색지대다.

프로세스 오너

프로세스 오너(process owner)는 개별 이슈가 아니라 프로세스 자체를 책임지는 사람이다. 이슈 담당자는 이번 건을 해결하고, 프로세스 오너는 "이슈 대응 프로세스가 잘 돌아가는가"를 지표(리드타임, 재작업률, 변종 수, 재발률)로 보고 흐름과 양식을 고친다. 회색지대가 생기는 가장 흔한 이유는 부서마다 자기 부분의 오너는 있는데 부서를 가로지르는 흐름 전체의 오너가 없기 때문이다.

프로세스 부채 갚는 순서

모든 프로세스를 한꺼번에 표준화하려는 시도는 대개 두꺼운 절차서만 남기고 끝난다. 부채는 이자가 가장 큰 것부터 갚는다.

1. 가장 자주 반복되는 이슈 유형 하나 고르기빈도 × 건당 처리 시간이 가장 큰 유형. 대개 고객 클레임이나 설비 고장 대응이다.
2. 실제 흐름 보기최근 20~30건을 골라 메일·메신저·문서에서 활동과 날짜를 뽑아 간이 이벤트 로그를 만든다. 변종과 대기 구간을 센다.
3. SIPOC와 RACI 한 장씩경계와 책임을 정한다. A가 없는 활동부터 채운다. 흐름 전체의 프로세스 오너를 정한다.
4. 이슈 카드와 관문공통 핵심 필드 10개 안팎, 단계별 관문 조건을 정한다. 기존 양식은 카드의 뷰로 바꾼다.
5. 카드 상태 = 이벤트 로그카드를 시스템(또는 최소한 공용 목록)에 두어 상태 변경이 자동으로 기록되게 한다. 이제 프로세스 마이닝이 상시로 가능하다.
6. AI 넣기정의된 단계에 AI를 넣는다. 접수 분류 자동화, 유사 이슈 추천, 8D 초안. 효과는 카드 로그의 리드타임·재작업률로 잰다.