업무를 관제하기까지 — 조각에서 E2E로
앞선 글에서 설비는 관제하는데 업무는 관제하지 않는다고 썼습니다. 그러면 어떻게 거기까지 갈 수 있는지가 남습니다.
화면부터 만들 수는 없습니다. 순서가 있습니다.
부서별 조각 → L4 흐름 정의 → E2E 드러남 → E2E 흐름 감시
지금은 조각으로 있습니다
프로세스 문서가 없는 회사는 드뭅니다. 대개 있습니다. 문제는 부서별로 따로 있다는 것입니다.
설계 부서에는 설계 프로세스가 있고, 구매에는 구매 프로세스가 있습니다. 각각은 잘 정리되어 있습니다. 그런데 이것들을 나란히 놓아도 전체 흐름이 나오지 않습니다.
이유는 문서가 부실해서가 아닙니다. 각 문서가 자기 부서 안에서 완결되게 쓰여 있기 때문입니다. 설계 프로세스는 "설계 완료"로 끝나고, 구매 프로세스는 "소요량 접수"로 시작합니다. 그 사이에 무엇이 어떤 형태로 넘어가는지는 어느 문서에도 없습니다.
그리고 문제는 대개 그 사이에 있습니다.
L4까지 내려갑니다
프로세스는 계층으로 봅니다. 큰 덩어리에서 시작해 실제 작업 단위까지 내려가는 구조입니다.
- L1 — 수주, 설계, 구매, 생산 같은 대분류
- L2 — 설계 안에서 기본설계, 상세설계, BOM 작성
- L3 — BOM 작성 안에서 표준품 BOM, 신규 BOM, 변경 반영
- L4 — 실제로 사람이 하는 작업 단위
단계 수는 회사마다 다릅니다. 중요한 것은 더 쪼갤 수 없는 작업 단위까지 내려가는 것입니다. 앞서 AX 수준을 판정하려면 업무를 쪼개야 한다고 썼는데, 그 쪼개기의 끝이 여기입니다.
여기서 하나를 더 적습니다
보통 프로세스 문서에는 순서와 담당자와 산출물 이름이 들어갑니다. 그것으로는 부족합니다.
L4에 프로세스 흐름과 데이터 흐름을 함께 정의해야 합니다. 이 작업이 무엇을 받아서 무엇을 내놓는지, 그 데이터가 어느 시스템의 어느 항목인지까지 적는 것입니다.
"BOM 작성" 옆에 이렇게 붙습니다. 받는 것은 확정된 사양서(어느 시스템의 어느 필드), 내놓는 것은 품목별 소요량(어느 시스템의 어느 테이블). 이렇게 적어놓으면 조각을 이을 수 있게 됩니다.
성공 조건은 연결성입니다
여기가 가장 중요한 부분입니다.
L4를 정의하는 일을 빈칸 채우기로 접근하면 실패합니다. 업무 목록을 만들고 항목마다 칸을 채워나가는 방식입니다. 이렇게 하면 몇 년이 걸리고, 대개 끝나기 전에 멈춥니다. 그리고 다 채워도 관제가 안 됩니다.
기준은 다른 것이어야 합니다.
앞 단계의 출력이 뒤 단계의 입력이 되는가.
이것만 봅니다. 이 기준으로 보면 판단이 빨라집니다.
설계가 내놓는 것이 "BOM 엑셀 파일"이고 구매가 받아야 하는 것이 "시스템의 소요량 데이터"라면, 여기는 연결이 끊긴 것입니다. 사람이 파일을 보고 시스템에 다시 입력하고 있다는 뜻입니다. 이 구간은 관제할 수 없습니다. 무엇이 언제 넘어갔는지 기록이 없기 때문입니다.
반대로 어떤 구간은 항목이 몇 개 비어 있어도 앞뒤가 데이터로 이어져 있습니다. 이 구간은 관제가 됩니다.
빈칸이 있어도 연결되면 관제가 되고, 다 채웠는데 연결이 안 되면 관제가 안 됩니다. 그래서 채우는 순서를 연결성이 정해야 합니다. 끊긴 곳부터 봅니다.
뼈대와 연료
프로세스를 정의해도 그것만으로는 그림입니다. 살아 있는 것이 아닙니다.
구조를 이렇게 나눠 봅니다.
뼈대는 프로세스입니다. L4까지 정의된 프로세스가 척추 역할을 합니다. 무엇이 어떤 순서로 흐르는지의 골격입니다.
연료는 실제로 흐른 데이터입니다. ERP와 PLM에 실제로 찍힌 기록입니다. 이것을 프로세스 위에 얹으면 그림이 움직이기 시작합니다. 어느 건이 지금 어디에 있고 어디서 며칠 멈춰 있는지가 보입니다.
연료를 잘못 넣으면 안 됩니다
여기에 원칙이 하나 있습니다. 이것을 어기면 앞의 모든 것이 무의미해집니다.
관제의 입력은 관리 도구의 숫자가 아니라 실제로 흐른 데이터여야 합니다.
무슨 뜻인지 예로 보면 분명합니다.
진척률 80%라는 숫자가 있습니다. 이것은 담당자가 관리 화면에 입력한 값입니다. 사람의 판단이고, 보고를 의식한 값이며, 어제 입력한 것일 수도 있습니다.
반면 ERP에 찍힌 발주 일시가 있습니다. 이것은 일어난 사실입니다. 누가 어떻게 느끼든 그 시각에 발주가 나갔습니다.
대시보드를 만들었는데 아무도 믿지 않는 상황의 원인이 대개 여기 있습니다. 관리용으로 입력된 숫자를 모아서 화면을 만들면, 그 화면은 사람들이 보고한 상태를 보여줍니다. 실제 상태가 아닙니다. 그리고 사람들은 자기가 입력한 숫자라는 것을 압니다. 그래서 안 믿습니다.
안 이어진 구간은 어떻게 하는가
현실적으로 모든 구간이 기간계로 이어져 있지 않습니다. 엑셀로 하는 구간, 메일로 넘기는 구간, 수작업 구간이 반드시 남아 있습니다.
여기에 커넥터를 만듭니다. 그 구간을 잇는 작은 도구입니다. 완전한 시스템을 만드는 것이 아니라 데이터가 넘어간 기록이 남게만 만드는 것입니다.
이것이 앞선 글들에서 쓴 바이브 코딩이 쓰이는 자리입니다. 예전에는 이런 작은 연결 하나를 만드는 것도 개발 요청을 올려야 했습니다. 지금은 며칠에 만들 수 있으니, 끊긴 구간을 하나씩 이어갈 수 있습니다.
다만 조건이 있습니다. 커넥터 목록을 관리해야 합니다. 어느 E2E의 어느 구간을 잇고 있는지, 지금 살아 있는지를 기록해야 합니다. 이것을 안 하면 앞선 글에서 쓴 난립 문제가 그대로 재현됩니다. 연결한 것이 무엇인지 아무도 모르는 상태가 되면, 관제 화면의 숫자를 다시 믿을 수 없게 됩니다.
만드는 층과 감시하는 층은 다릅니다
마지막 원칙입니다. 프로세스를 정의하고 관리하는 층과, 실시간으로 흐름을 감시하는 층을 분리합니다.
섞으면 문제가 생깁니다. 같은 화면에서 프로세스를 관리하고 실적을 보게 만들면, 관리용으로 입력한 값이 자연스럽게 관제 입력으로 흘러들어갑니다. 위에서 말한 그 문제입니다.
정의하는 일은 사람이 합니다. 느리고 신중해야 합니다. 감시하는 일은 시스템이 합니다. 빠르고 자동이어야 합니다. 두 가지는 성격이 다르니 층을 나눕니다.
정리
순서는 이렇습니다.
- 지금 — 부서별 조각. 전체가 안 보입니다.
- 정비 — L4에 프로세스와 데이터 흐름을 함께 정의합니다. 빈칸이 아니라 연결성 기준으로.
- 연결 — 조각이 이어지면서 E2E가 드러납니다. 크든 작든 하나의 흐름이 보입니다.
- 관제 — 그 흐름 위에 실제 흐른 데이터를 얹어 실시간으로 봅니다.
이 순서에서 세 번째가 결과이고 두 번째가 일입니다. 대부분의 노력은 L4를 정의하는 데 들어갑니다. 그리고 그 일은 AI가 대신해줄 수 없습니다. 우리가 무슨 일을 어떤 순서로 하는지는 우리만 압니다.
도구가 싸진 덕에 마지막 단계는 예전보다 쉬워졌습니다. 화면을 만드는 일, 끊긴 구간을 잇는 일은 며칠에 됩니다. 그래서 병목은 다시 앞쪽으로 옮겨왔습니다.
댓글
댓글 쓰기